Jアラートとサイバー攻撃

2017年8月29日の朝になされた北朝鮮のミサイル発射を契機とするJアラートには、本当に驚かされました。ところで、このJアラートは、「弾道ミサイル情報、津波警報、緊急地震速報など、対処に時間的余裕のない事態に関する情報を国(内閣官房・気象庁から消防庁を経由)から送信し、市町村防災行政無線(同報系)等を自動起動することにより、国から住民まで緊急情報を瞬時に伝達するシステム」ということです。

ところで、このJアラートが法的には、どのように位置づけられるのかというのを調べてみました。
法的な根拠は、国民保護(Civil Defense 民間防衛ともいわれる)に関する法律である「「武力攻撃事態等における国民の保護のための措置に関する法律」」(国民保護法)ということになります。国全体として万全の態勢を整備し、もって武力攻撃事態等における国民の保護のための措置を的確かつ迅速に実施することを目的としている法律になります。そのために国、地方公共団体等の責務、国民の協力、住民の避難に関する措置、避難住民等の救援に関する措置、武力攻撃災害への対処に関する措置その他の必要な事項を定めています(同法1条)。国民保護については、内閣官房の国民保護ポータルサイトがあり、よくまとまっています。

この「国民の保護のための措置」には、「 警報の発令、避難の指示、避難住民等の救援、消防等に関する措置・二  施設及び設備の応急の復旧に関する措置・三  保健衛生の確保及び社会秩序の維持に関する措置・四  運送及び通信に関する措置・五  国民の生活の安定に関する措置・六  被害の復旧に関する措置」が含まれるので、その「警報の発令」がJアラートということになります。

具体的には、同法44条で、「対策本部長は、武力攻撃から国民の生命、身体又は財産を保護するため緊急の必要があると認めるときは、基本指針及び対処基本方針で定めるところにより、警報を発令しなければならない。」と定められています。そして、同45条で、指定行政機関の長、所管する指定公共機関その他の関係機関、都道府県知事に通知がなされます。都道府県知事は、さらに、その内容を当該都道府県の区域内の市町村の長などに通知します(46条)。そして、市町村長は、前条の規定による通知を内容を、住民及び関係のある公私の団体に伝達するとされています(47条)。そのときに、「サイレン、防災行政無線その他の手段を活用」して伝えるということになるわけです。

ところで、そうだとすると、いわゆるサイバー攻撃の時に、国民保護というのは関係しうるの?という問題がおきるわけです。警報の発令、住民の保護、社会秩序の維持などが、サイバー攻撃による情報処理の停滞等についても求められるのは、同様にも思えます。果たして、このような国民保護的な考え方が、サイバー攻撃との関係で、どのように考えられるのか、というのは、問題になりそうです。

この点について、検討すると、国民保護法のこれらの規定が発動されるのは、武力攻撃事態等(32条「政府は、武力攻撃事態等に備えて、国民の保護のための措置の実施に関し、あらかじめ、国民の保護に関する基本指針(以下「基本指針」という。)を定めるものとする。」)と緊急対処事態ということになります(同法172条)。武力攻撃事態等というのは、「武力攻撃事態及び武力攻撃予測事態」と定義されています。緊急対処事態というのは、「武力攻撃の手段に準ずる手段を用いて多数の人を殺傷する行為が発生した事態又は当該行為が発生する明白な危険が切迫していると認められるに至った事態」(事態対処法22条)と定義されています。そして、国民保護法については、武力攻撃事態等に関する国民保護についての規定が準用されています(183条)。

サイバーの手法を用いたとしても、その被害が一定のレベルに達した場合においては、そのアトリビューションとも相まって、武力攻撃事態と認定しうる可能性があるということは、このブログでもふれているとおりです

そうだとすると、むしろ、被害に注目するときに、甚大さ、迅速、直接性、侵略性などの観点から、武力攻撃事態が予測されるのであれば、当然に、そのレベルに至らない、緊急対処事態というのも想定されていいのではないか、と考えてしまいます。

それこそ、原子力発電所が一斉に異常運転し暴走する、将来、つながる自動車が一斉に動き出して、まわりにいる人間にぶつかる、などは、考えうるシナリオな様な気がします。この場合に、この緊急対処事態の「武力攻撃の手段に準ずる手段を用いて多数の人を殺傷する行為が発生した事態又は当該行為が発生する明白な危険が切迫していると認められるに至った事態」というのは、適用されうるの?という問題が起きるわけです。

理屈からいうと、「武力攻撃の手段に準ずる手段」というのがサイバー的な手法による有体物の誤動作等から生じるハザードを含むのかという論点がありそうです。この解釈は、国連憲章の2条に関する攻撃の性質か結果か、という解釈論を思い浮かばせます。

また、「多数の人を殺傷する行為が発生した事態又は当該行為が発生する明白な危険が切迫している」ということなので、財産の損失は、含まれないことになります。それで、いいのかという問題もあるかもしれません。

緊急対処事態は、攻撃対称施設等による分類、攻撃手段による分類から検討されています

このうち、攻撃手段による分類だと、多数の人を殺傷する特性を有する物質等による攻撃が行われる事態と破壊の手段として交通機関を用いた攻撃等が行われる事態が紹介されています。

有体物が電気情報通信手段によって接続さている場合において、その通信を用いて、「多数の人を殺傷する行為が発生した事態又は当該行為が発生する明白な危険が切迫していると認められるに至った事態」については、その手段は、「武力攻撃の手段に準ずる手段を用いて」といえるのでしょうか。

また、その場合に、どのような「警報の発令」が望ましいのでしょうか。脆弱性が悪用されている場合だったら、パッチの適用をアラートしたほうが望ましいので、そのようなパッチのアラートがなされるのかなあ、とか、ちょっと考えてみました。

 

 

 

デジタル・ニッポン2017 とセキュリティクリアランス

情報共有のエントリでもふれたデジタル・ニッポン2017の73ページ以下でふれられているセキュリティ・クリアランスについて考えていくことにしましょう。

クリアランスとは、機密情報(classified information)等の情報に対してアクセスしうる地位やその地位を付与する制度そのもののことをいいます。
米国においては、「アメリカ合衆国政府におけるセキュリティクリアランスの目的は、職員に機密区分された情報を保全する意思及び能力があるか否かを、その忠誠心、性格、誠実さ、信頼性に基づき判断することにある 」とされています(合衆国政府公式ウェブサイト:セキュリティクリアランス)。
一般的に、機密区分には3つのレベルがあります。それらは秘密性の低い順に、Confidential(秘密)、 Secret(極秘)、Top Secret(機密)になります。省庁によってはこれらの区分をさらに細分化する場合もあるが、一般的な枠組みは相当程度標準化されています。

米国においては、管轄省庁ごとに適用されるプログラムが準備されていますが、そのなかでもっとも一般的なものは、アメリカ合衆国国家産業安全保障計画 (NISP) です。
これは、異なるセキュリティ・クリアランス・プログラムを統一化し、その誤用・濫用を防止する目的のために、1993年、大統領令(EO) 第12829号 によって確立されました。NISPの規則・規制は、アメリカ合衆国国家産業安全保障計画実施マニュアル (NISPOM) において詳述されています。

さらに、2009年12月には、国家安全保障にかかる機密情報(Classified National Security Information)に関する大統領令第13526号によって、合衆国政府のセキュリティ・クリアランス手続が拡充されています。

民間企業の従業員に対しても、セキュリティクリアランスが求められることが非常に多いのが実際です。たとえば、国防総省契約業者は、職員のセキュリティクリアランス(Personnel (Security) Clearance (PCL))を経なければならないです。一般論としては、政府職員および政府契約企業従業員が、機密情報にアクセスするには、セキュリティクリアランスを保持していること、「need to know」を満たしていること、機密区分情報秘密保持契約(Classified Information Non Disclosure Agreement )を締結すること(SF312) とされています。
その結果、米国で、510万人もの人がクリアランスを保有しておりノルウェーの人口よりも多いといわれています

わが国においても、秘密情報を取り扱う政府職員の人的管理制度としてのクリアランス制度は存在し、平成21年4月から、政府統一基準に基づき、国の行政機関の職員を対象に秘密情報(「特別管理秘密」)の取扱者に対し適性の評価を実施するという形で行われています。
これは、「カウンターインテリジェンス機能の強化に関する基本方針」(平成19年8月9日カウンターインテリジェンス推進会議決定 による。)第2部I3(1)に定められたもので、「秘密取扱者適格性確認制度」と呼称される。しかしながら、政府情報にアクセスする民間企業の職員に関して定めた一般的なクリアランス制度は存在せず、それにより、外国政府機関が日本政府機関等と情報共有しようとする場合に、どの範囲の民間企業職員にどのような情報が提供され、秘密が暴露された場合にどのような対応措置がなされるのかについての予測可能性が保障されておらず、外国政府機関がわが国との情報共有を躊躇するという萎縮効果のおそれが生じていると言われていました。

これらについて統一的な仕組みを構築したのが、特定秘密保護法の枠組みということになります。デジタルニッポンの提案内容について、特定秘密保護法との関係で位置づけをなしてみていくことにしましょう。なお、特定秘密保護法の逐条解説は、こちらです。

同法は、「我が国の安全保障(国の存立に関わる外部からの侵略等に対して国家及び国民の安全を保障することをいう。以下同じ。)に関する情報のうち特に秘匿することが必要であるものについて、これを適確に保護する体制を確立した上で収集し、整理し、及び活用することが重要であることに鑑み、当該情報の保護に関し、特定秘密の指定及び取扱者の制限その他の必要な事項を定めることにより、その漏えいの防止を図り、もって我が国及び国民の安全の確保に資することを目的」とする法律です。

でもって、この1条の解説で、サイバー関係については、「例えば、サイバー攻撃に より金融システムや水道等の重要インフラが機能しなくなるような事態 が発生すれば「国家及び国民の安全」が害されたと言い得るが、個々の 国民や企業が経済的な利益を逸失したり、犯罪行為の被害に遭ったりし たからといって、直ちに「国家及び国民の安全」が害されたことにはな らない。 」と解説がなされているのが興味を引きます。

また、民間企業との関係でみるときには、第5条「特定秘密の保護措置」の適合事業者の定め(4項)、従業者の定め(5項、6項)と第8条「適合事業者への特定秘密の提供」が興味を引きます。そして、同法11条は、取扱者の制限を定めています。

特定秘密の取扱いの業務は、当該業務を行わせる行政機関の長若しくは当該業務を行わせる適合事業者に当該特定秘密を保有させ、若しくは提供する行政機関の長又は当該業務を行わせる警察本部長が直近に実施した次条第一項又は第十五条第一項の適性評価(略)において特定秘密の取扱いの業務を行った場合にこれを漏らすおそれがないと認められた者(略)でなければ、行ってはならない

適正評価は、行政機関の長による適性評価の実施(12条)によって定められている手続きに従い、評価対象者に告知の上で、その同意を得て(同条3項)、実施がなされます。評価の対称となる事項は、特定有害活動との関係、犯罪及び懲戒の経歴に関する事項、情報の取扱いに係る非違の経歴に関する事項、薬物の濫用及び影響に関する事項、精神疾患に関する事項、飲酒についての節度に関する事項、信用状態その他の経済的な状況に関する事項になります(同2項)。

このような枠組みになっているので、特定秘密保護法のもとで、民間事業者に関していえば、「公務員以外の民間企業の職員も広く適性評価の 対象となるのではありませんか?」という質問に対しては、「民間企業の職員が適性評価の対象となるのは、防衛装備品を製作等する業者が、行政機関と契約し、特定秘密の提供を受けたときのみです。
また、当該業者においても、特定秘密を取り扱う職員の範囲を明確に定めます。適性評価の対象となるのは、限られた範囲の人です。」
という回答になるわけです。(特定秘密の保護に関する法律Q&A Q14以下 )

特定秘密保護法については、立法に際して、いろいろな議論があったかと思いますが、民間への適用についての懸念というのは、あまりなかったように思えます。

デジタルニッポン73ページ以下では、セキュリティクリアランスについて、日本にはないという表現をしていますが、あまり正確な表現ではないように思えます。それはさておいて、サイバーセキュリティサービス企業やユーザ企業に対して、クリアランスの付与を考えて、情報の提供を考えるべきという提案かと思います。

この提案の狙いは、方向性としては、妥当なのだろうと判断はしていますが、そもそも、防衛装備品の情報を狙っているサイバーキャンペーンがあるというように、生の攻撃データから、情勢分析を踏まえてのインテリジェンスに、どの組織が昇華させるのかという根本的なところが認識されていないのではないかというように思えます。そのような情報を特に、防衛秘密と指定すべきものかという問題もありそうです。

その一方で、経営者がクリアランスを持っていない場合に従業員のみがクリアランスに基づいて経営者に対して、レスポンスの必要性をどのように説明するのかという問題も生じそうです。簡単な問題ではないということはいえるでしょう。

法律用チャットボットの作り方(8) repl-aiでLINEボットに挑戦 その4

repl-aiで、シナリオを作成したら、実験をすることができます。
マイプロジェクトページから実験(シミュレーター)できます。

 

これで、うまくいけば、LINEのアカウントと接続します。具体的な接続の仕方は、このページ(作ったボットとLINEで話そう)にでています。

ところが、私の場合は、どうしてもエラーがでて、立ち往生してしまいました。エラーというのは、以下の画面で、1. Channel IDを入力する 2. Channel シークレットを入力する 3. Channel トークンを入力する という作業をして、webhookのアドレスをコピーを押して、「コピーいたしました。LINE Developers にてご利用ください」の文字がでても、一つもアドレスが生成されませんでした。

でもって、ドコモデベロッパーズで、質問をしたのですが、すぐには返事が返って来ないので、しつこく催促したところ、結局、webhookのアドレスを教えてもらって、手で、LINEのほうに入力して実験しました。なんとかうまく接続されました。

ただ、実験すると、すぐに、理解の範疇を越えて、返事が返って来なくなります。まだ、一般公開というレベルには、たどり着けていません。ただ、実験目的で、公開しています。具体的には、事務所のページを訪問ください

なお、repl-aiは、横浜のゴミ分別の紹介サイトに採用されています。自然言語のレベルは、結構、高いみたいです。「「旦那を捨てたいんですけど…」 横浜市のごみ分別ボットの答えが的確すぎる」という記事がでています。このボットのエンジンは、repl-aiなので、うまく作れると、発展性があるのかもしれません。 repl-aiは、 「連携ボットを活用しよう」というように作成すると、docomoの準備している対話ボットと連携することができます。

まだ、LINEのボットは、改良をしないと恥ずかしいレベルです。が、どうも、仕事の広告として、有効なのかなという感じもするので、とりあえずは、ここで、いったん、開発は、止めて、マイクロソフトのAzureのボットフレームワークを使いだしてみようかと考えています。

あと、実際の開発が、パーツを組み合わせていくというのを体感したので、それをもとに、システム開発契約についての、いまの一般の解説が時代に対応していないのを論文にするのもいいなあ、と考えています。

法律用チャットボットの作り方(7) repl-aiでLINEボットに挑戦 その3

repl-aiで、LINEボットを作っていきます。まずは、トップページです。基本的には、ドコモのデベロッパーアカウントを作成ということになります。

 

デベロッパーアカウントの作成は、こちらですね。

デベロッパーサポートですが、いろいろとみていくと、いろいろな機能があります。

特にAPIのところででてくる種々の機能は、魅力的に思えます。

 

ただ、ドキュメントや開発者コミュニティが貧弱なのではないか、という風に見えるのですが、本当は、どうなのでしょうか。(FBでのページは、更新も少ないし、?がつきますね)

あと、デベロッパーアカウントだといろいろいと問い合わせる機能があります。

 

むしろ、デベロッパーのコミュニティとか、そのBBSとかで聞けるといいのになとか思いました。

アカウントを作成したら、repl-aiにもどってログインしていきましょう。マイプロジェクトになります。

 

 

プロジェクトを作成しましょう(上の矢印)。

このプロジェクトをもとにいろいろなことができますね。詳しくはあとで。

でもって、いよいよシナリオの作成になります。

新規作成を押して、シナリオを作っていきます。

まずは、ユーザが、何か、お話をしたら、「初めまして」と答えていくのにしましょう。それで、「法律関係でお手伝いしましょうか」というシナリオにします。それまでいけば、次のシナリオに移動するようにします。

Chatfuelと、比べると、自然な対話を狙っています。Chatfuelのところでふれたように、ボタンによる入力というのは、ありません。

法律相談支援チャットボットというのは、チャット相手からえられる正確な知識をもとに、ある程度の道筋を提供するという性格になるので、ボタンを組み合わせるというのが有効なように思えます。

なので、ボタン式の入力をまったくもってツールとして選べないのは、ツールとしては、評価しにくいなあというのが判断になります。

あと、とりあえず、人工知能というか、自然言語認識をさせるというのが、売りなのかと思います。そうだとすると、「何の法律相談ですか」というシステム発話に対しては、「○○です」と答えさせて、その○○に応じて、シナリオを展開するのが、なにかツールみたいなので揃っているといいのになあとか考えたりします。

普通のツールだと、自然言語処理のお約束とのことですが、intentとentityで、覚え込みをさせているのに対して、repl-aiだと、そこら辺の仕組みがよくみえないです。Azureのここら(LUIS)辺は、詳しくできていますね

あと、いろいろな繰り返しのパターンがあるのですが、それをコピーするとかが前はなかったりしていました。

正直、ツールとしては、なじみにくかったということになります。趣味で、何かを使うのであれば、他のツールかな、という感じです。

そうはいっても、一応、それなりのシナリオを作って、形にしました。(まだ、交通事故は、完成していません)

で、次は、実際のLINEのアカウントに接続しましょう(続く)

 

 

 

 

 

 

 

 

法律用チャットボットの作り方(6) repl-aiでLINEボットに挑戦 その2

repl-aiでLINEボットに挑戦なわけですが、まさに挑戦という感じでした。

シナリオ自体は、Facebookメッセンジャーチャットボットを作っていたので、オーサリングツールをいじって、そのまま、実験することはできるので、むしろ、どうすれば、LINEチャットからアクセスできるのか、というところが問題でした。

でもっ、ちょうど、この頃に、出たのが、前でもふれた立花翔著「LINEBOTを作ろう」の本です。この本を見ながら、実際に、簡単なチャットボットを作って、確認していきました。

この本の第2章を見ながら、Heroku の使い方を覚えておきました(超初心者ですね)。もっとも、そのあとで、実際には、repl-aiのサーバで作ってデプロイするので、Herokuを使ってデプロイしなくていいわけですが、そのような原理の勉強には、ちょうどよかったです。

実際に設定していくのは、第3章以降になります。デベロッパ登録・チャンネル設定、Line business Centerの登録などが必要になります。

このあたりについては、repl-ai の「作ったボットとLINEで話そう」とを見ながら、実際にアカウントを作りながら、進めます。

まずは、LINE BUSINESS CENTERにログインですね。ログインするとこんな感じです。

 

とか、いっていたら、LINE BUSINESS CENTERのサービス終了だそうです。

でもって、アカウントを設定です。LINE@をクリックしましょう。

 

 

とこうなって、認証アカウントを申し込みます。

認証がとれるまで数日かかりました。開設までに審査が必要なアカウントが認証アカウントということになります。法律事務所ですと、やっぱり、きちんと認証をとっておくべきでしょう。

フリーなのも含めて、こんな感じです。

 

認証済みのアカウントの全体の設定は

 

こんな感じで

基本設定は、こんな感じになります。

Mesdsaging APIの設定は、こんな感じで、webhook送信(あるアプリケーションから別のアプリケーションに対してリアルタイムな情報提供を実現するための仕組みだそうです)を利用するとします。

ということで、ここまでが一応の準備ということになります。

 

 

法律用チャットボットの作り方(5) repl-aiでLINEボットに挑戦 その1

6月以降は、ラトビア・エストニア訪問やら、ネット中立性のエントリをまとめたりして、なかなか、チャットボット関係をいじることができなかったのですが、ネット中立性の分析も一段落したので、チャットボットに戻りましょう。

戻るといっても、実際は、5月にいろいろといじっていたものですが、今回は、repl-aiで、LINEチャットボットを構築した経験をメモしていきましょう。

Messengerチャットボットは、Chatfuelというツールで作りました。前にもふれましたが、ボタン式で、どんどん進めていける点、プログラミングをしないで済むというので、本当に、便利なツールでした。

ただ、なんといっても、チャットボットといえば、LINEでしょう。国内アクティブユーザー数が、7000万人以上(?)というほとんどプラットフォーム・アプリになります(独禁法上は、どういう市場画定するんだろ?とか考えているのはさておき)。ところが、Chatfuelは、LINEに対応していません。

プログラミングでもって、Messaging APIでもって、組んでいくのであれば、それはそれでいいのですが、実際にやりたいのは、法律相談を、ダイアログ式の応対に組み込むことなので、どう考えても、単純な仕組みの繰り返しが増えるのは、目に見えているので、ツールを使わざるを得ません。

ちなみに、「LINE BOTを作ろう! Messaging APIを使ったチャットボットの基礎と利用例 」という本を購入して、いろいろと遊ばせていただきました。ちゃんとHerokuも使ったし、ライン公式アカウントを作成して、いろいろとやりとりをできるレベルまでには、持っていきました。
おすすめの本かと思います。

その前に、LINEのアカウントを作成して、APIを利用するのを登録して、設定を行わないといけません。このあたりの設定については、「わずか5分。新LINE Messaging APIでbotを作ってみた手順全公開」と上の本を参照しながら、作成していきました。

ツールの選択が、一番の課題になります。で、具体的に、「チャットボット作成ツールまとめ(国内海外)」などをみながら、LINE対応しているツールを洗い出してみました。

国内だと、repl-ai、hachidori 国外だと reply-ai、smoochくらいしかないようです。

その一方で、
Chatfuel
Botsify
Microsoft Bot Framework
motion.ai
chatbots.io
wit.ai(FBの子会社でしたよね)
gupshup
converse
meya.ai
は、LINEへのエクスポートができません。
Messengerチャットボットを作ったときに、チャットボット(というか、ダイアログの仕組み)については、非常な可能性を感じたのですが、もっとも重要なのは、開発のためのいいツールがあることことと感じました。その意味では、LINEは、位置づけとしては、微妙なのではないのと感じたりする結果ですね。

さて、具体的なツールの評価になります。

hachidoriについては、ドキュメント不足ですので、パスということは前に書きました。

reply-aiですが、

英語サイトでもって、アカウントの作り方を探したのですが、見つかりません。ボットで、アカウントを作りたいけどというと、個人では、アカウントを作るのには、対応していませんと回答してきたので、これまたパスすることにしました。

smoochは、まだ試していません。ということで、日本におけるチャットボット導入ツールの代表的な存在?であるrepl.aiを試してみることにしましょう。詳しくは、次のエントリで。