HOME > 活動報告 > イベント報告 > JaSST'18 Shikoku
2018年12月14日(金) 於 香川大学研究交流棟5階 (香川大学教育学部キャンパス内)
11回目となるJaSST'18 Shikokuが香川大学にて開催された。四国のプログラムは講演とワークショップの構成を固定としており、今回はIoTに対するセキュリティに関する講演と、D-Caseを用いたワークショップが行われた。開催場所が大学であることもあり、毎年学生の参加が多い点もJaSST Shikokuの大きな特徴である。
始めに、実行委員長の高木氏から「少しでも業務に役立つことを持ち帰ってほしい」という開会の挨拶があった。
IoT(Internet of Things)には、企業向けのように管理する仕組みがあるものと、一般個人向けのように管理する仕組みが無いものと、大きく2種類に分けられる。一般個人向けのIoTを利用したシステムでも管理する仕組みがあれば管理は可能になる。
管理する仕組みが無い、つまり、管理することを前提としていない商品をIoT化させると、想定していなかった問題が発生することがある。実際に、子供の遊具である人形の販売を促進するためにクラウド上のスピーチエンジンを用いて人形のキャラクターと会話できるシステムを作ったところ、顧客の子供が家族の話題を話しかけてしまい、個人情報漏洩問題が起こり販売中止になった事例がある。
NIST(アメリカ国立標準技術研究所)では、標準化により技術力を高める活動が行われているため、IoTに関連したアメリカ国内標準が存在する。管理可能なIoTのアーキテクチャについてはNIST SP 800-183を参照するとよい。また、IoTのセキュリティについてはNIST SP 800-160に掲載されているセキュリティフレームワークを参照するとよい。
日本にもセキュリティの標準がある。セキュリティの品質特性についてはJIS X 25000シリーズの品質モデルを参照するとよい。
IoTのセキュリティに関する日本の取り組みとして、JNSA(NPO日本ネットワークセキュリティ協会)のIoTセキュリティWGの活動がある。このWGのリーダーは登壇者の松岡氏である。このWGから機器メーカーを対象にした、『コンシューマ向けIoTセキュリティガイド』が2016年6月に公開されている。管理されていないコンシューマ(一般個人)向けIoTを対象にした理由は、管理されたIoTのセキュリティについては経済産業省がIoTセキュリティガイドラインを策定しているためである。『コンシューマ向けIoTセキュリティガイド』では、セキュリティを気にかけないユーザーのために開発者が考えておくべきことの例を提示している。このガイドを作成する過程で役に立ったのが欧州のIoT-A(Internet of Things - Architecture)プロジェクトによるIoTのアーキテクチャ参照モデルだった。また、ガートナーの調査レポートでIoT普及台数予測の半数超はコンシューマ向けであるということが掲載されていたこともガイド作成の後押しをしてくれた。
セキュリティの世界で「テスト」というと「ペネトレーションテスト(ペンテスト/侵入テスト)」である。アセスメントの一部でもあり、脆弱性を見つけてリスク評価することが目的である。ほとんどが人海戦術であり、侵入口となる「穴をみつける」ためにコード解析からブラックボックステストまで様々なテストのしかたがある。ハッキングとの違いは、攻撃ではなく観察することに主体を置くことである。システム全体にとどまらず周囲も含めてテスト対象とするため、当然お金がかかる。そこで部分的に切り出すことはあるが、そのときは対象から外した範囲に対して脆弱性が残る可能性に対して「こういうリスクがあるよ」ということも示す。
特にIoTのテストは複合的なシステムとして評価するため、つながっている先の更に先を、果てまで考慮する。サプライチェーンやライフサイクルも全部考慮するため、キリがない。従って現実的には不可能なので、調整しながらスコープを決めてどのレベルの深さまで見るか(例えばOSまで見るか?基盤まで見るか?など)の切り分けを顧客と決める。
ペンテストのガイドや標準についてはNISTをはじめ複数の組織が公開している。英語の書籍もあるが、日本語のドキュメントはまだ少ないのが現状である。
カスペルスキー社の取り組みで、OPC UAプロトコルの実装における脆弱性の検索のレポートが公開されている。17個のゼロデイ脆弱性を発見しOPC Foundation に報告したが、サードパーティ製品の脆弱性の原因の多くは、OPC Foundation の提供するOPC UAスタックのAPIを不適切に使用していたことによるものだった。例えば、サンプルコードには問題がなかったのだが、サンプルコードをみたエンジニアが「ここは手間がかかるから端折っていいや」と判断して実装しなかったことで問題が起きている。エンジニアは、端折った箇所が悪用される脆弱性のもととなるか?までは判断できないことがわかる。
また、カスペルスキー社では、国内の新しい取り組みとして、JPCERT/CC、⻑崎県立大と共同でIoTセキュリティ評価のためのチェックリストを現在作成している。
上記講演内容の他に、IIC(Industrial Internet Consortium)や4.0RU(INDUSTRIE4.0RU)の紹介など、盛りだくさんの講演内容であった。その中で「(プロダクトがそれぞれ)単独で信頼性やセキュリティを確保していてもだめ」という話が一番印象的だった。筆者はシステム全体を考慮したテストを考える立場にいることが多いため、「その先まで考える」ということは普段から行っているものの、セキュリティの面から考えると「更にその先まで果てしなくなる」という奥深さがあることを感じた。また、セキュリティの脅威を考えると、連続稼働の要件はOSや利用しているシステムのアップデート頻度を考慮したうえでかなり慎重に決める必要があるし、セキュリティの面からも基本的にシステムは変わり続けるという意識はIoTに限らずどのようなシステムでも持っていたほうがよいと実感した。
市場でトラブルが発生したときに、開発者は、開発したシステムが原因ではないことを利害関係者に納得させる必要がある。そのような「説明責任」を求められることが昨今多くなった。開発者は高品質な製品を作ってきた自信があるが、過程を知らない第三者は製品の品質を知る術がない。従って開発者の意図を正しく論理的に第三者に説明し合意する道具として、D-Caseを用いる。
このようにD-Caseは、システムのディペンダビリティをシステムに関わる利害関係者間で共有・合意し、社会に対して説明責任を果たすために用いられるが、今回はこの記法を用いて、説明しやすい記述の書き方を学ぶ演習が行われた。
始めに、D-Caseの記法と各ノードの解説と、簡単な記述例を用いて書き方と説明の仕方の紹介があった。
D-Caseのノードのうち、Goal(主張)、Strategy(説明)、Context(前提)、Evidence(Solution)(証拠)、Undeveloped(未定義要素) を使う。(ワークショップでは日本語表記を用いていた。)
主張に対して、何をどのように説明するかを考え、説明を主張の下に配置する。上位の主張から下位の主張に分解し、説明の下に配置する。このとき、下位の主張は相手と合意形成できている上位の主張や説明に対する前提に基づいていることが必要であるため、主張と説明に対する合意形成済みの前提条件を先に記載する。必要に応じて更に下位の主張に分解する。最下位の主張の妥当性は証拠をその下に配置し、証拠に基づき説明する。証拠がまだ定義されていない、具体化されていない主張については、未定義要素を最下位に配置する。
前提ノードは主張ノードおよび説明ノードに付与することができる。前提ノードは対応する主張および説明ノードの水平位置に配置し、白抜き矢印で「主張→前提」「説明→前提」の方向につなぐ。上位下位の関係は黒塗り矢印で「上位→下位」の方向につなぐ。
このように配置することで、説明の順番がわかりやすくなり、納得しやすく論理立てた説明をすることが容易になる。前提条件は、なぜその主張でよいのか?を説明することを助ける。前提条件に対し満足できる成果物を証拠として紐付けることで、説明の妥当性をもたせることができる。
演習は、まず演習課題に類似した例を紹介し参加者にイメージを持たせてから、演習課題に取り組む、という流れで行われた。
演習課題はライト点灯制御装置プログラムで、3点スイッチを接続しているときには問題なく動作していたが、押しボタンスイッチに変更したときに、「左右どちらもONにできるようになったがそのときに右ライトが点灯しない」という問題が発生したため、部下がプログラム修正を行うことになったという背景が提示され、プログラムを修正した部下からの報告内容だけでプログラム修正の妥当性を説明できているかを、D-Caseを用いて確認するという内容だった。
まずは個人演習として各自でD-Caseで表してみて、その後、3〜4名のグループで共有しながらグループで図を発展させ、その成果をグループごとに発表した。
D-Caseの記述をすることで、変更箇所に対してテストが不十分であること、変更箇所の妥当性を見るために変更していないモジュールも確認しておく必要があることを示せた。また、D-Caseを用いて記述しただけでは前提を暗黙的にして記述を忘れるケースもあることと、声に出して説明を行うことで暗黙になっていることに対して気づきやすく指摘も得やすくなるということを体験した。
ワークショップとしては「D-Caseによってプログラムの修正内容や修正後のテストに対して不足しているところが見える」ことを実感することが主目的になると思うが、実際にテストを考えている立場としては、仕様とテストの内容を見せられた時点で「そもそもこの製品に対してこのテストだけでは足りない」という感覚を抱く。しかしそれをトップダウンでD-Case上に載せようとすると当てはめるGoal(主張)やStrategy(説明)が見つからない、ということを体験した。それは他のグループでも起こっていた。この点は非常に興味深かった。逆に「なぜそのテストが必要なのか?」「なぜそのテストはこの時点で考慮しなくてよいのか?」を説明できるように、リバースさせて図に盛り込むことで、第三者に納得してもらえる、ということを学ぶ良い機会になった。
最後に、実行委員の大羽氏から、閉会の挨拶があった。今回のワークショップはJaSST'17 Tokaiで開催されたコンテンツだった。大羽氏はJaSST'17 Tokaiに参加していたが複数並列セッションにより受講を逃した背景を持ち、今回四国で再演していただけたことをとても喜んでいた。JaSSTの講演やワークショップは素晴らしいものが多く、ひとつの地域だけ1回きりの講演では直接聴講し体験することができない参加者も多い。そういう点で、複数の地域で再度受ける機会が得られるというのは良いことだと思う。筆者も同様に講演・ワークショップとも機会を逃していたため、今回四国で機会を得られて嬉しかった。
四国は隣同士の県であっても移動に時間がかかり、日帰り参加も大変だという話を聞くことがある。そのような中、今回高知からの参加者がいた。JaSSTに興味を持ってくれる人が各地域に増えてきたのではないかと思った。来年また会えること、更に岡山など近隣の地域から参加してくださるかたが増えることを期待している。
記:坂 静香(ASTER)