「IoTセキュリティガイドライン（案）」に関する意見

2016年6月14日
一般社団法人　情報処理学会
会　長　　富田　達夫

以下のとおり，2016年6月14日付で意見書を提出しましたのでご報告いたします．
（協力：システムソフトウェアとオペレーティング・システム（OS）研究会，組込みシステム（EMB）研究会，コンピュ－タセキュリティ（CSEC）研究会，インターネットと運用技術（IOT）研究会，セキュリティ心理学とトラスト（SPT）研究会，コンシューマ・デバイス&システム（CDS）研究会）

2016年6月14日

総務省情報流通行政局情報流通振興課情報セキュリティ対策室 御中
経済産業省商務情報政策局情報セキュリティ政策室 御中

一般社団法人 情報処理学会
会　長　　富田　達夫

 IoTデバイスの普及が，今後も飛躍的に増加すると予測される中，IoTに特化したセキュリティのガイドラインが策定されることに賛同いたします．ご提示の案はIoT機器・システム・サービスの関係者に対するセキュリティのガイドラインとして，何をすべきか／した方が良いのかという点において複数の異なる視点で整理され指標が提示されており，特にサービス提供者にとって有益なガイドラインになっていると考えます．

 一方で，ぜひ検討していただきたい点について以下に記します．

 1点目として，IoTに特化していない内容も含まれているのではないでしょうか．1.2節にガイドラインの目的として，「本ガイドラインは，上記のIoT特有の性質とセキュリティ対策の必要性を踏まえて‥」とありますが，2章冒頭の要点1と2は，IoT特有の話ではなく情報システム一般の話ではないでしょうか．よって，一般的な情報システムとの差分・位置づけを明確化し，IoT特有の性質に由来するセキュリティ対策・ガイドラインとなることを期待します．情報システム一般と峻別するために，対象とするIoT機器を，少なくともPCやスマートフォンといった従来型情報機器では無いモノとして分かり易く定義を行う必要があるのではないでしょうか．

 2点目として，本ガイドラインは全てのデバイスが直接インターネットに接続されることを想定しているような印象を受けます．そのため，各機器に要求しているソフトウェアの機能がかなり高機能になっている印象があります．今後の検討事項にも「リスク分析に基づく分野別の対策について」の検討は記されていますが，p.29～30「要点8.個々でも全体でも守れる設計をする」において，「対策が不十分なIoT機器・システムを上位のIoT機器・システムで守る対策」として，低機能な機器の構成への検討が述べられているように，上位と下位に分けそれぞれの観点でセキュリティ対策のガイドラインを提示した方が，より明確になるのではないかと思います．さらに下位の形態を特に検討し，「下位のIoT機器で最低限守られるべき項目はどれか」という対応分けが必要に思います．その理由は以下のとおりです．
・ IoT機器は数が多くなる分，個々のデバイスに対するコスト抑制圧力が強いため十分な機能を有す
 るほどのスペック面での余裕がない．
・ セキュリティ面の脆弱性は常に内在していると考えるべきで，それに対する対応（ソフトウェアの更
 新）は，「デバイス自体の機能の有無」「更新ソフトウェア提供の継続性」「デバイス数の規模による
 作業の困難さ」を考慮すると，容易ではないと推察される．
・ 暗号等のセキュリティ技術でよく見られるように，ある段階の保護技術は数年経過すると十分な強度
 を持たなくなる．

 3点目として，これまで「事故前提（セキュリティに絶対はなく事故は起こりうるものという前提）」の考え方に基づく取り組みが必要不可欠と言われていました．IoTにおいても同様に，複数の機器が攻撃の踏み台になったり，改ざんされたデータが送付されたりする脅威が存在していると考えられます．事故前提の考え方はとても重要であり，IoTセキュリティにおいても踏襲されることが必要不可欠であると考えます．本ガイドラインにおいても，明示的に謳うことを期待いたします．

 4点目として，人とモノ，モノ同士がつながることによって発生しうるセキュリティの脅威に対しては，提供者と利用者の双方で対策を実施することが重要と考えます．本ガイドラインにおいては，双方とも対象読者として書かれていますが，第3者からのセキュリティ脅威を，IoTセキュリティ機器・システム・サービス提供者がどのように対策をするかという視点にもっとも重点が置かれている（第2章）ように思われ，もっとも重要な利用者の安全とセキュリティを守るという本来の目的からすると，以下の視点が弱いと感じます．
・IoTセキュリティ機器・システム・サービス提供者による，利用者の安全，セキュリティ侵害への対策
・利用者自身による安全，セキュリティ対策
・利用者自身によるサービス提供者への攻撃の防止（注意喚起）… （当たり前ですが…）

 最後に，本ガイドラインで示すセキュリティ対策をどのように実現するのかについては，分野，製品，企業によって適切な対策が異なるため，現案では対策例としていくつかの方法が示されているにとどまっていますが，実社会における実効性のあるガイドラインとするためには，今後も継続して議論されるべきであり，また必要に応じて適切にメインテナンスされることが望ましいと考えます．

以下，各章の内容について個別にコメントいたします．

＜第1章＞
■1.1.1「セキュリティの脅威の範囲の拡充」
 IoT機器に対するセキュリティの脅威（セキュリティを侵害する／脅かす要因）として，「第3者による攻撃」のみが触れられていますが，利用者が意図せずモノを繋げてしまっていることや，サービス提供者が利用者の情報を適切に管理してないことによる脅威も存在すると思われます．これらの脅威は，第3者による攻撃の脅威よりも，場合によっては，利用者の生命・財産に，比較的容易に，深刻な結果をもたらすことが想定されます．
例：サービス提供者が利用者に事前通知なく，遠隔制御機能を提供している．
   サービス提供者が，利用者の個人情報を企業のサーバに保存しており，適切に管理されていない．

■1.1.2「IoT 特有の性質」における利用者視点の追加
 性質1と性質6において，利用者の視点が抜けていると思われます．開発者だけでなく，利用者にとっても，所有する機器の接続範囲，影響度（繋ぐことのリスク）を想定・把握することが困難になるという性質があろうかと思います．サービス提供者／開発者よりも，ITスキルの乏しい利用者（未成年者や高齢者など）にとって，この性質は大きな影響を及ぼすものと思われます．
 例えば，第2章の要点18，要点19に繋がるので，p.4でも触れた方が良いと思われます．また，要点19で，利用者にリスクを認識してもらう上でも，十分な情報提供と説明が必要であることを明記した方が良いと思います．

＜第2章＞
■全般
 関係者に加え，機器や機能も多く存在するため，システムとしてリスク分析やセキュリティ・バイ・デザインの取り組みが必要と考えます．
 【運用・保守】における指針として，『IoTシステム・サービスにおいては，多くの関係者が存在し，かつ，複雑な関係となっている』という記述に同意いたします．この観点を【運用・保守】に限定されることなくさらに踏み込んでいただき，当該文章の「関係者」の部分を「機器」「機能」と置き換えて捉えることが重要と考えます．
 すなわち，他フェーズ（【方針】【分析】【設計】【構築・接続】）において，（多くの機器や機能が存在し複雑な関係となっている）IoTシステム・サービス全体に対する「リスクの分析」「セキュリティ・バイ・デザイン」などの取り組みが求められるよう明記することを期待します．

■2.1【方針】 要点1「経営者がIoTセキュリティにコミットする」
 運用・保守時に新たに発見，把握したセキュリティの脆弱性に関する情報を，JP-CERT，IPA等に通知すること，また利用者からの問い合わせに対応する窓口の設置を強く推奨するべきだと考えます．情報の把握に関しては，要点18（3）①で少し言及されていますが，明示すべきであると考えます．また，p.57の利用者のルール1で，サービス提供者から提示される情報を定期的に確認することを追記すると良いと思います．これらのことは，直ちに使用を停止すべき深刻な脆弱性が見つかった場合には，サービス提供者側だけでなく，利用者の行動を促すことが重要と考えるため，追記の検討をお願いします．

■2.2【分析】 要点3「守るべきものを特定する」
 対象をIoTと考えると，「デバイスの数」の観点が欠かせないのではないでしょうか．その点では「リスクの認識」の段階から，『数』を考慮に入れてリスクを把握し，負荷の高い対策が必要な機器を最小化する，といった観点も記載されていて良いのではないでしょうか．

 また，IoT セキュリティにおいて守るべきものの一つとして，IoT機器・システムが収集する個人情報（プライバシー含む）が挙げられています．ただ，Suicaの事例が示すように，単一の機器で収集された情報それぞれにはプライバシー上の懸念がなくとも，複数の機器からの情報を集約することにより，個人のプライバシーを犯しうるデータが生成されるリスクがあります．この点に関して，データを集約・蓄積することによるプライバシーリスクについて適切に啓発するとともに，サービスの提供に必須とは言えないデータについては，事業者自身を個人情報保護法違反のリスクから守る観点からも，収集しない，もしくは蓄積しない，などの対策を積極的に検討するよう促すことも重要かと思われます．

 さらに，要点3で特定した情報資産，及び要点13で収集した情報を，サービス提供者が保存，廃棄するルールについて，すなわち価値，個人情報（プライバシ情報を含む）を企業が保持することのリスクについて言及し，適切に保存，廃棄することの重要性を追記することの検討をお願いします．例えば，要点21を実施するためには，IoT機器とその利用者の対応情報をサービス提供者側が把握・管理する必要があると思われますが，逆にそれによって得られる情報の流出，機能の悪用等のインシデントが想定されます．

 さらに，「「安全安心」は，「セーフティ」「セキュリティ」及び「リライアビリティ」を含んだ概念であり，対象とする機器やシステムのセーフティ，セキュリティ，リライアビリティが確保されていること．」と定義されていますが，機器やシステムのみを対象としており，そのまま解釈すれば利用者の生命は含まれないことになります．利用者の安全性やセキュリティも明記した方が良いと思われます．また，“安心”は，安全からくる利用者の主観により決められる心理であり，何を達成すべきか曖昧なものでありますが，要点10,11,12,17においても”安心”について，具体的な事柄が述べられていません．安心性は提供者側が一定程度高めることは可能と思われますが，最終的な判断は利用者に委ねるのが自然であると思われます．その意味で，サービス提供者は，利用者が安心できるための必要な情報を正しく迅速に提供するべきであると考えます．”安心”という言葉を削除するか，具体的にガイドライン中で言及されると良いと考えます．

 また，本来機能を，”つながる”ことが不要な機能，”つながる”ことでより良いサービスを提供する機能，”つながる”ことが必須の機能などに分けて分類してはどうかと考えます．サービス提供者は，安全・セキュリティ分析において，これらの分類を実施すべきであるし，一方，利用者は，これらの機能を把握し，必要／不要を選択する権利があると思われます（例えば，リスクを許容したくないので，”つながる”ことが必須の機能は停止するなど）．

■2.2【分析】 要点4「つながることによりリスクを想定する」
 対策例としてパスワードの堅牢化が挙げられていますが，ガイドラインとして出すと，ある程度基準化してしまう可能性があると思われます．パスワード認証については，長時間をかけた総当たり攻撃が想定されますが，管理者がそれに気づかないといずれは破られる可能性が高いため，総当たり攻撃への対策（たとえば一定期間に一定回数以上認証に失敗すると，しばらくの間は認証を行えないようにするなど）を対策例に含めてはどうでしょうか．また，機器との間の直接パスワード認証以外の方法を検討すべきではないでしょうか．例えば，クラウド（側のtrust anchor）をまじえた認証システム，証明書ベースのセッション認証など，他の事例も含めた方が良いのではないでしょうか．
 また，①IoT機器・システムとしてのリスク想定にて「一定期間，パスワードが変更されない場合」が問題のある状況とされていますが，現在では，パスワードの定期変更はコスト（労力）の割には効果が薄く，パスワードは漏洩の可能性があった場合以外は変更は不要だという意見もあります．特に，IoT機器ではパスワード変更のコストは大きくなることが予測されるため，「パスワードの定期変更」を促す方向は再考する必要があるのではないでしょうか．あえて書くならば，「漏洩の可能性があった場合に変更を促す」ではいかがでしょうか．

■2.5【運用保守】要点19「つながることによるリスクを一般利用者に知ってもらう」
 リスクの一般利用者への周知のところ等で，どのような個人情報が取得され流出する恐れがあるのか理解した上で使ってもらうといった視点の記述が必要ではないでしょうか．

＜第3章＞
 IoT機器・システム・サービスの利用における，安全性とセキュリティを確保するためには，利用者自身による対策が必要不可欠だと考えます．IoT機器が収集する情報は，各種センサデータなど多岐にわたり，また，利用者が自発的に入力するとは限らないものが多いと想定されます．どのようなデータが収集され，また蓄積もしくは利用されるかについて，個人情報保護（適切な個人情報の取得）の原則からも，利用者（機器の所有者と限らない可能性があります）に適切に認識してもらえるようにする必要があります．また，IoT機器・システムの利用者に対しても，リスクから身を守るための原則として，その機器・システムにおいて適切な情報の収集・管理がなされているかを積極的に確認するように第3章（一般利用者のためのルール）などで啓発することが重要と考えます．そこで以下のルールを追加することを検討願います．

・ 「使用機器，サービスの最新情報を把握し，必要に応じて使用機器やサービスの保守を実施する」
・ 「使用機器，サービスに関して，サービス提供者による接続の目的・意図を把握し，理解できない
  機能やサービスの利用を控える」
  →要点18～21との対応．特に要点18（3）②における重要事項説明等に追記するのはいかがで
   しょうか．
・ 「利用者自身による物理的なセキュリティへの対策（注意喚起）」
  →第3章に，利用者自身が，IoT機器の管理，保有の重要性を理解し，個人情報（プライバシ情報
   を含む）場合には，その管理に十分気をつける（盗難や転売の防止）ことを追加するのはいかがで
   しょうか．
・ 「利用者自身による機能・設定の見直し」
  →第3章 要点19の内容を受けて，利用者自身が，「必要な機能とそのリスクを把握し，機能・設定
   を定期的にチェックする」という事項を追加するのが望ましいと考えます．
・ 「利用者自身によるサービス提供者への攻撃の防止（注意喚起）」の追加
  →第3章に，利用者自身によるIoT機器の悪用，サービス提供者への攻撃を防止するための注意
   喚起を追加してはどうか．他の利用者にも悪影響を及ぼす可能性が考えられます．

 その他，IoT特有のセキュリティ問題として，本ガイドラインに追加した方が望ましいと思われる項目を，下記に示します．

■長期間利用される機材について
 10年間，あるいはそれ以上利用される耐久消費財・設備機器などにおいては，ベンダが存在しなくなった／サポートをとりやめた後どうするかというポリシーを事前に定めておくべきではないでしょうか．

■IoT機器の所有者によるアクセス認可
 本ガイドラインにおいて認証に関する記述はありますが，IoT機器への（アクセス権限）所有者によるアクセス認可に関する記述が見当たりません．セキュリティやプライバシーの観点から，ユーザが明示的に許諾したアクセスしか許可されないように対策することは極めて重要だと考えます．
 特にコンシューマ向けのIoT機器は，所有者が明確に定まるケースが多いと考えられます．IoT機器は，システム・サービスへの接続時に，所有者との紐付けが確実に行われ（所有者の許諾のもとに，ネットワーク接続が開始され），サービス，他機器，アプリから当該IoT機器へのアクセスは，紐付けられた所有者による明示的な認可を前提として行われるようにデザインされるべきです．これは，UI等を持たない非力なIoT機器においても同様に対策されるべきだと考えます．（IETF OAuthWG, ACE WG等で検討が進んでおり，対策は現実的なものとなってきています）

追加箇所としてのご提案：
- 2.2【分析】IoT機器に対する，所有者が認可していないアクセス（未認可アクセス）もセキュリティリス
  クとして加える．
- 2.3【設計】他機器，システム・サービス，User Agent（アプリやWebブラウザ）からの直接アクセス，
  システム上での当該機器のデータ利用について，所有者の明示的な認可を経るように設計する．
- 2.4【構築・接続】IoT機器のネットワークへの接続時に，所有者との紐付けが行われ，所有者の認可
  の元に接続が行われるように設計する等．

■IoT機器のライフサイクル，特にサービス終了時の考慮
 IoT機器には，ネットワーク接続（システム・サービスとの連携）が前提となっているものがあり，主要機能がネットワーク接続を前提にする点は，IoT機器特有のものといえます．本ガイドラインには，「サポート終了」については言及がありますが，PCやソフトウェアと同様のニュアンスで記述されているような印象を受けます．例えば，サービス停止によるIoT機器の主要機能の停止，それに伴うセキュリティリスクにフォーカスした記述を追加すると良いのではないでしょうか．以下，参考情報として最近の事例を挙げます．
・スマホで開ける南京錠「246Padlock」，サービス終了で開錠不能に．
  http://japanese.engadget.com/2016/04/27/246padlock-6-30/

追加箇所としてのご提案：
- 2.1【方針】：経営者は，サービス終了=主要機能停止なIoT機器について，特に，サービス終了時
  の対応・セキュリティリスク洗い出し・対策について企画段階から考慮する等
- 2.2【分析】サービス終了＆機能停止時のリスク分析
- 2.3【設計】サービス終了時のセキュリティ対策設計

■既存法との整合性と今後の発展
 既存の機器やシステムは，ネットワークに接続するしないにかかわらず，安全安心が担保できるような法整備や規制が行われてきました．p.19にあるエアコンを例にとれば電気用品安全法がそれにあたります．すでに整備されている法や規制と整合性をとりながら，産業界による積極的な開発等の取組を促すとともに，利用者が安心してIoT 機器やシステム，サービスを利用できる環境を生み出すことにつなげる必要があると考えます．

■既存のIPA，官公庁（経産省・総務省等）によるセキュリティガイドラインとの差分や関係性の明確化
 本案のp.9には，IoTの分野として，自動車，家電（HEMS），医療，工場が挙げられていますが，各分野では既にセキュリティガイドラインが策定されている，あるいは，策定に向けた取り組みが行われています．よって，既存のガイドラインも参照可能とすることで，より有益なガイドラインになるのではないでしょうか．
 また，本ガイドラインのp.58において，「分野それぞれにおいて求められるセキュリティのレベルは自ずと異なってくる」と記載があるため，本ガイドラインの読者がセキュリティ対策を検討するためにも分野別のガイドラインの情報を掲載した方が良いと考えます．
 以下に既存のガイドラインの例を示します．

（1）医療関係
   経産・総務・厚労3省から複数のガイドラインが発行されている．例えば，「医療情報システムの
   安全管理に関するガイドライン」，「医療情報を受託管理する情報処理事業者向けガイドライン」
   などがある．
（2）自動車関係
   IPAが「自動車の情報セキュリティへの取組みガイド」を発行している．
（3）HEMS関係
   スマートメーターの運用ガイドラインがある．また，セキュリティ・ガイドラインも検討中である
   （スマートメーター制度検討会 セキュリティ検討ワーキンググループ 報告書）．
（4）その他
   工場関係では，IPAが「制御システム利用者のための脆弱性対応ガイド」を発行している．

＜その他＞
その他，細かい内容ではございますが，文言の統一など気になった点を下記に示します．

・p.1 「本ガイドラインは，IoT 機器やシステム，サービスの供給者及び利用者を対象として，
  サイバー攻撃などによる新たなリスクが，モノの安全や，」
  →モノの安全性について，説明が必要だと考えます．物理的な価値の損失のみを指している
   のでしょうか．おそらく，ガイドラインの主旨としては，”モノの利用者”の安全も含まれるの
   ではないかと想像します．
・p.3 IoT の関係者=1.4対象読者という解釈で正しいでしょうか．
・p.5,8 「安全」が”誰の／何の”安全なのか，対象が曖昧に記述されているので，関係者のうち，
  誰の／何の安全性を指しているのか明記すべきと考えます．対象が曖昧ですと，対策を
  検討する上でも曖昧な議論になりがちです．
・p.14 「利用者」→「ユーザ」という表現に変わっています．統一するべきと考えます．
・p.35 「守るべき機能（要件）に対する脅威・リスク分析，セキュリティ対策検討，効果及び守るべき
  機能への影響の分析・評価を行い，評価結果が不十分であると判断される場合には再分析・
  再検討を行う．」
  →「守るべき機能（要件）に対する脅威・リスク分析，セキュリティ対策検討，効果及び守るべき
   機能への影響の分析・評価を行い，評価結果を受容可能でない場合には，対策を検討し，
   再度分析を繰り返す．」でしょうか．