ネット事業者が防御で連携」という記事がでています。「総務省とNTTコミュニケーションズなど国内のインターネット接続業者は2018年度をめどに、サイバー攻撃を一⻫に遮断する仕組みを作る。不正アクセスの発信源となるサーバーを即座にネットから切り離す。この仕組みのために、「DDoS攻撃が発生した直後に、接続業者が発信源のサーバーを特定。その情報を業者間で共有し、犯人のサーバーからの攻撃指令を一⻫に遮断する。国内の有力な接続業者が連携して実効性を高める。」というのが、その手法ということになります。通信の秘密の保護がうたわれており、攻撃を起こすサーバーの情報の業者間での共有は進んでいなかった。」のですが、ガイドラインを年明けにまとめて、電気通信事業法などの法改正も検討する、ということだそうです。電気通信事業者の取扱中に係る通信の秘密は、侵してはならない。取扱中に係る通信に関して知り得た他人の秘密を守らなければならない。その職を退いた後においても、同様とする。DDoS攻撃が発生した直後に、接続業者が発信源のサーバーを特定した場合に、このサーバーの情報は、上の「他人の秘密」ということになるわけですが、現在の解釈では、「電気通信事業に従事する者に関する第1項の適用関係を明らかにするとともに、電気通信事業に対する利用者の信頼保持の観点から、電気通信事業に従事する者に対し、第1項よりも広い範囲の守秘義務を職務上の義務として課したもの」という趣旨になります。どちらにしても、このサーバーの情報は、具体的な通信を識別しうる情報なので、通信の秘密とてし保護されるデータとして、この4条の保護のもとにあるということになります。(よく、通信の構成要素をなすデータといわれますが、多分、そういうことだとおもいます)ところで、このような保護されるデータについては、「「積極的な取得の禁止・窃用の禁止・漏えいの禁止」を意味するものと考えられています。実務的には、「窃用」が、単に「用いること」と同義であると解釈されています。これは、法的な解釈本では、「窃用」とは、自己または他人の利益のために用いることをいう、とされており、公共の利益のために利用することは含まれないと解釈される余地があるのですが、実務(というか、担当課的には)そのような余地を認めない、むしろ、そのような行為は正当業務行為の解釈で対応する、というようにされていました。もって、ちょっと時代を遡ってみる(このごろ、こればっかり)、2004年3月にコンピュータソフトウェア著作権協会(ACCS)にDos攻撃が仕掛けられたわけですが、これがわかるのに、プロバイダーは、通信を届けて、攻撃に加担しなければならないのですか、という問題が出てくるわけです。正当業務行為でもって、問題が起きるごとに、プロバイダーで法的許容性について議論したり、場合によっては、担当課に相談したりするということでは、とてもじゃないけど、実務的には回らなくなります。そこで、事前に許容される行為が検討されるといいねという感じに思えます。そのときには、「そうはいっても、結局、憲法の「通信の秘密」が同じ内容だとして、鎮座しているからねえ」ということで、実務規範的なものを事前に鼎立するというのは、不可能な感じでした。月))という論考にまとめさせていただきました。weekで議論されています。日(非公開)とつながったと理解しています。そのような議論の提起から、既に10年以上が経過しています。いまでは、いわゆる大量通信等ガイドラインも「電気通信事業者におけるサイバー攻撃等への対処と通信の秘密に関するガイドライン」と名前を変えており、「通信の秘密」の解釈についても、かなりの程度、柔軟に対応されるようになってきました。DDos攻撃に際して、プロバイダーがどのように対処をなすことができるかについては、サイバー攻撃等への対処ガイドラインに記載がなされています。サイバー攻撃等に係る通信の遮断については、被害者から申告があった場合、事業者設備に支障が生じる場合、送信元設備の所有者の意思と関係なく送信されるサイバー攻撃等の場合に遮断が認められています。サイバー攻撃等への共同対処においても「情報提供を受けた電気通信事業者において当該特性に合致する通信を遮断してよいとされています。今回の記事は、仕組みとしては、このガイドラインで許容されている枠組みをむしろ、公認し、積極的に推進しようという位置づけであるように思えます。すると、このようなセキュリティのための活動にも、予算とかがきちんと付くのでしょうか。非常に賢明な判断ということになるかもしれません。法改正も検討する」ということですと、どのような改正になるのでしょうか。興味しんしんというところでしょうか。私が「いいだしっぺ」であることは、みなさん、認めてくれるでしょうから、フォースの力で論文を書いたということを認めてもらえるかもしれません。国民のための情報セキュリティサイトにおいて、「脆弱性」を「コンピュータのOSやソフトウェアにおいて、プログラムの不具合や設計上のミスが原因となって発生した情報セキュリティ上の欠陥のことを言います」と定義がなされています。いうエントリで、脆弱性をめぐるこの15年間の変遷について触れました。ある意味で、このキャンペーンは、、「脆弱性」という言葉をめぐって、正確に理解してもらうための動きだったような気がします。「きじゃくせい」じゃなくて、「ぜいじゃくせい」とよびます、から始まって脆弱性と欠陥は、区別しましょうあたりは、すごく長期のキャンペーンをしました。このキャンペーンにあたって、「脆弱性と瑕疵の間に」という論考も記しました。備わっていないこと」をいうとされており、法的なセンスのある人は、瑕疵修補請求権を思い浮かべるので、それ自体、何らかの行為を求めることができるのではないか、ということになります。2条2項)となります。ともに、「あるべき」安全性(もしくは機能・品質等)を欠いている状態を指し示す用語になります。すると、研究者等が、脆弱性を発見して、開発者に伝えても、何か、製品に「あるべきものが欠けている」、いわば、クレームをつけているのですか、という対応になってしまうことになりやすいわけです。脆弱性という用語と欠陥・瑕疵という用語は、きちんと峻別して、「脆弱性」という用語を用いるばあいには、これは、別に開発者が「悪いわけではない」のですよ、というメッセージを伝えるべきであろうと考えます。そのような考えに基づいて用語を選んできました。アクセスできる状態を含む。」とされており(これは、当初の平成16年告示も同様)、早期警戒パートナーシップの取り組みにおいて、「脆弱性」の定義から、この点について留意がなされていることをわかっていただけるかとおもいます。ある意味で、現代社会において、脆弱性をいかに取り扱うのか、というのは、もっとも繊細な配慮が必要になる分野であるような気がします。そのために国民に呼びかけるサイトにおいて、このような基本的概念について、配慮にかける表現があるのは、きわめて残念なことといわざるをえないとおもいます。IkuoIPA「脆弱性届出制度に関する説明会」が開催されました。そこで、この制度の利用者(?)の方から、いろいろな感想が「つぶやかれています」。この点については、「脆弱性届け出制度に関する説明会のつぶやきまとめ」でまとめられています。私(高橋郁夫)個人としては、いわゆる「中の人」になりますので、具体的なこの制度の変更にいたった議論の経緯その他についてコメントすることは避けます。この制度について、常にウワォッチし、あるべき制度を考えていた一法律家としてのコメントをさせていただければ、以下のとおりになるかと思います。この制度が構築されたのが、2002-2003年の時期であったということは、さけて通ることができないと思います。その当時までに、時計を巻き戻してみましょう。研究者・実務家の方が、脆弱性を見つけた、それを企業に対して、これ、脆弱性になるから直したらいいんじゃないの?と届けたときにどうなっていたでしょうか。何か、脅迫・恐喝つもりなのですか?という態度で開発者がまともにとなりあわないということになっていたのではないでしょうか。(その端境期において、「脆弱性に警鐘?」という報道がされた事件もありました)理屈から考えると、脆弱性が少ないこと、もし、見つかった場合には、真剣に、その届出に対応してもらって、できるかぎり、脆弱性のないソフトウエアを提供しましょう、というのが望ましいというのは、誰もが、合意してもらえるかと思います。現実は、「絶望的なぐらいに」そのありうべき姿と乖離していたのです。この段階において「責任ある開示」という概念を中心にして、どのようにして脆弱性の報告をとりあつかうべきかということが議論されていたのがわかるかと思います。実際に、IPA/JPCERT/CCにおいて早期警戒パートナーシップの構築にいたっていくわけです(2003年10月頃から2004年3月まで)。「脆弱性」に対する基本的なスタンスということになりますが、この報告書をよんでいただけると、脆弱性の報告書については、まさに「責任ある開示」のスタンスを積極的に採用し、その意味で、そのスタンスがどこまで、実際のセキュリティのコミュニティで支持されるのか、まずは、やってみましょう、というものであったのがわかるかと思います。望外なことに、この脆弱性の早期警戒パートナーシップは、わが国において、非常に、共感をもって受け入れられました。報告数は、着実に増えていきましたし、また、特に、実際の研究者・実務家の方々が、脆弱性を発見したら、まずは、この早期警戒パートナーシップの枠組みで報告しましょうと考えるにいたったように感じられたのは、非常に、ありがたく思えます。この制度の考えていたことは、世界的にも、早期的なチャレンジに成功したものであったということは、特筆すべきものであったように思えます。disclosure」が制定、公表されているのに至ったというのは、私たちのチャレンジが、世界的にみて、先進的な試みであって、また、そのチャレンジを成功させた日本のセキュリティコミュニティに対する極めて高い評価であったということもできるのではないかとおもいます。私たちは、この試みとこの結果を誇りに思っていいとおもいます。この仕組みは、如何せん、きわめて広範な「脆弱性」の定義に該当するものについて、その重要性についてなんら評価をせずにすべて「脆弱性」の有無を調査化した上で、あると判断したものについて調整を図ろうとした点で、制度としての致命的な問題点を有していたと考えるべきではないかとおもいます。processes」が、そのプロセスで明らかにするように、ベンダは、CSIRT/PSIRTのような仕組みを設けて、その製品について、脆弱性が見つかった場合には、そのような仕組みが、脆弱性に対して対応するのが、まさに標準であるという思考を前提に構築されているものです。現代社会においてあるべき姿を考えるときに、ベンダ(開発者)がみずからの責任であって、セキュリティ的にも問題がないソフトウエアを開発して、その態度等が、ソフトウエアの性能と評価されて、市場において、もし、そのような態度にかけるソフトウエアがあれば、そのようにソフトウエアは、市場から、退出を迫られるという姿を前提としているように思えますし、また、そうであるべきかとおもいます。そもそも、IPAないしJPCERT/CCのリソースといえども、有限なわけで、そのリソースを、「広範な脆弱性」の定義に該当する場合に、「脆弱性というのは、攻撃者が悪用するものであって、その攻撃によって発生する問題点の重要性を事前に評価することはできない」という理屈でもって、ふんだんに使っていいということにはならないと考えます。現在においては、脆弱性のもたらすセキュリティ上の脅威が社会においても許容しうるものではないという認識が一般化しつつあるかとおもいます。開発者が、積極的に、脆弱性の届出受け付けの窓口をもうけるようになってきている。バグバウンティ制度を導入する企業も増加しているなどの事情を考えたときに制度が構築された時期と比較して、セキュリティの重要性の認識/脆弱性解消の努力の正当な評価という観点からするとき、非常に良い方向に進展していると評価することができるのではないか、と個人的に考えます。関与するのが、許容されるような重要度の高いものに限って関与するという制度にすべきなのではないか、と考えます。私としては、そのような考え方に基づいているのが、今回の制度改変なのではないかと考えます。確かに、いままでの、「脆弱性」について、これを発見したのであれば、IPAに届出て、これを前提として脆弱性の認定がなされて、調整がなされるという制度が当然であるという考えを前提とするのであれは、どういう改正なのかという思いが生じるのは、わからないでもないです。そもそも、開発者が対応すべき「脆弱性」に対して、IPA/JPCERT/CCがリソースを避くことが当然であるという考え方のほうが、今となっては、あるべき姿からは遠ざかっているというように考えます。一定のスタンスを押し出して、脆弱性の対応については、「開発者」がなすべき重要な責務であるという大原則を前提とした制度にしたほうが、結果としては、更に日本におけるセキュリティ・コミュニティの成熟をみれるような気がします。私としては、このチャレンジの結果は、むしろ、開発者さんにおいて、どれだけ私たちのメッセージをきちんと受け止めるかにかかっているかとおもいます。このチャレンジも成功することを期待しています。2017年11号は、特集が「IoT時代のセーフティとセキュリティ」になります。)こともあり、興味深く読ませていただきました。それらしき記述はありますが、「セーフティとは○○である」これに対して「セキュリティは、××である」という定義に該当する記載がないので、締まりが悪く感じてしまいます。セキュリティの関係についての議論もありません。情報処理学会だからといって、社会的なアプローチが軽視されているのではないでしょうか、というちょっとした感想をもってしまいました。発展と企業法務の未来」(1)が掲載されています。この論文は、人工知能技術とは何か、ということをきちんと理解していることを前提に、具体的な企業法務への展開にふれてようとしている点で、他にない論考かとおもいます。高橋が、今年の11月29日に「人工知能は法務を変える?」としてシンポジウムで問いかけようとしている論点とまさにシンクロするものといえるでしょう。「「昔のAI」については、論理式などによる関連知識の情報を与えることで解いていた」としています。これは、前にふれた私のチャットボットって人工知能なの、という話ででてくる、昔ながらのエキスパートシステムということになるかとおもいます。これに対して、「今のAIでは、ルール不要である。つもり、専門知識を参照しない。大量のデータを統計的に観測することで、問題に対する解のパターンを導く(モデルを学習する)のである」としています。この違いについて、角田は「ルールを考案する速度に比べて、驚異的な速度でデータ量は増えてしまうので、人間がルールを作成して解を得るより、コンピュータがデータから直接に解を導いたり、自動でルールを作成したりするほうが得策という時代に入ったのである」と述べています。昔のAIに基づいた研究・活動を「レガシー法律AI」と読んで、問題点を列挙しています。ないと困る法律学はそもそも統計的・定量的ではない。分野ごとのパラメータの調整が必須ホスピタリティや責任は人の担当AI法務自体の法的問題となっていて、そのあとの続編となっています。ちなみに、脚注も充実しています。(あと不動産)あたりに限って、例外を無視して、とりあえず、人間の補助として「昔のAI」を使う仕組みを発展させていくのが合理的ではないか、と考えています。説明がないと困る(伝統的な解法は、人間が考えるので問題なし)などの問題は、無視できるようになります。「言葉」をつかったコミュニケーションから切り離せないので、宿命ですけど、人間の生活のなかで、言葉のかかわるものってそんなものなので、そんなもののレベルでもいいかとおもいます。AIの基礎となっている統計学だって、20年に1回は、収穫の予測がはずれるので、そんな年は、許してね、という話で始まっているはずなので、それに比べれば、分野を絞って、古典的なAIをリファインするというのは、おもしろいのではないかと考えています。(たとえば、破綻という言葉の解釈に、いろいろな事例をぶち込んで、データを分析すると、その判断に影響を与えている特徴量がわかるよねなんてのもおもしろいような気がします。みんなのAIブログで「チャットボットを作るときに気を付けるべき唯一つのこと」という記事がでています。非常に勉強になる記事です。「あなたがアプリ、ウェブサイト、電話、その他の特定のニーズに対処する他の方法よりもユーザーにボットを選んでほしいと願っている」すなわち、ボットが望ましいと思っているのは、なぜですか、ということになるかと思います。ボットというのは、ユーザが、システム提供者よりも、情報をあまり有していないときに、ユーザみずからが、情報を検索するのが困難なときに、システム側で、決定木に基づいて選択を与えて、一定の結論を提供するのに適したシステムだと考えます。法律相談支援ボットというのは、まさに、このような目的にフィットしています。交通事故の過失割合がいくらになるか、これは、弁護士であれば、赤本という本を見ていけば、過失割合が出てくるのは、だれでも知っているのです。ところが、ユーザは、どこに、どう書いてあるかは、わからないということになります。その間をつなぐのにもっとも適した手段ということがいえるかと思います。ノーかで、クリックさせていってもかまわないわけですが、自分の答えをいれていくと回答にたどり着くのは、自然だし、ユーザにとっては、容易であると考えることになると思います。スマート度合い・自然言語の量・ボイスが成功を保証するものではないというのもそのとおりです。(脳)?でふれました。自然言語対ボタン式でもいいです。上の目的に達するのに、何が合理的なものなのか、という判断になります。ユーザエクスピリエンスが重要であるというのは、そのとおりですね。詳しくは、「人工知能が法務を変える?」の会議で報告しますが、人間は、ボットが相手になると、我慢できなくなりそうです。その意味で、短い受け答えが必要になります。法律相談だと少ない情報で、法律相談の示唆までたどり着くことはできないので、このバランスというのは、一つの課題になりそうです。IkuoTorの法的位置づけをまとめておきたいと思います。この問題について、2014年3月段階で、いったんまとめていたことがあったのですが、そのときには、法的な問題については、ほとんど議論されていなかったのですが、現在は、いくつか議論がなされているような状態になったからです。日本においては、遠隔操作ウイルス事件において犯人が、当該ウイルスをアップロードするのに、Torネットワークを利用しており、その点が新聞報道などで注目されたりということがありました。そこでは、「現在、アメリカ合衆国は、Torを規制する法律を有していない。