つながる世界の開発指針 （案） イラスト はじめに 近年、IoT（Internet of Things）への取組みが各国で進んでいる。しかし、 今までつながっていなかったモノ、つながることを想定していないモノ同士が つながることで想定していないリスクも発生している。10 年以上使用される機 器も多いため、メーカでは IoT のリスクに対して早急に対策を行う必要があ る。IoT のリスクに対して守るべきものを守れる機器やシステムを開発するこ とは国際競争力の維持にも寄与すると期待される。 そこで、独立行政法人情報処理推進機構 技術本部 ソフトウェア高信頼化セ ンター(IPA/SEC)は、様々なモノがつながる世界において機器メーカやシステム 開発企業が安全安心に関して考慮すべき最低限の事項を開発指針としてとりま とめた。 なお、本開発指針は、個別具体的な遵守基準ではなく、業界横断的な安全安 心の取組みの方向性を示したものである。各業界に属する企業の経営者、開発 者及び運用者の方々に本指針をご理解頂くとともに、実践することで安全安心 の実現を目指していただきたいと考えている。 特に、お読みいただきたい読者 章 経営者 開発者 運用者 第１章 ○ ○ ○ 第２章 ○ 第３章 ○ ４．１ 第４章 第５章 ○ ○ ４．２ ○ ４．３ ○ ４．４ ○ ４．５ ○ ○ ○ ○ 本開発指針での用語の定義は以下のとおりである。 用語一覧 略語 CSIRT 名称 Computer Security Incident Response Team 用語は追記予定 3 目次 はじめに .................................................................................................1 第 1 章 つながる世界と開発指針の目的 ....................................................... 5 つながる世界の概要 .......................................................................... 6 1.1.1 IoTとつながる世界 ......................................................................6 1.1.2 各国におけるIoT推進の取組み ..................................................... 8 つながる世界のリスク .......................................................................10 1.2.1 つながる世界のリスクとは ...........................................................10 1.2.2 つながる世界のリスク例..............................................................12 開発指針の目的..............................................................................15 第 2 章 開発指針の作成方針...................................................................16 本書の位置付け ..............................................................................17 本書での「IoTの安全安心」の捉え方 ...................................................19 安全安心なコンポーネントの実現方針 ..................................................21 第 3 章 開発指針の前提としたリスク分析 ...................................................23 ＩｏＴコンポーネントの特性整理の観点 ...................................................24 つながる世界のリスク分析 .................................................................26 第 4 章 つながる世界の開発指針..............................................................27 つながる世界の安全安心に企業として取り組む ......................................29 安全安心の基本方針を策定する ...............................................29 安全安心のための体制・人材を見直す .......................................31 内部不正やミスに備える .........................................................33 つながる世界のリスクを認識する .........................................................36 つながる世界で守るべきものを特定する .....................................36 つながることによるリスクを想定する ..........................................38 つながりで拡大するリスクを想定する ..........................................40 物理的なリスクを認識する .......................................................42 守るべきものを守る設計を考える.........................................................44 個々でも全体でも守れる設計をする...........................................44 つながる相手に迷惑をかけない設計をする ..................................49 安全安心を実現する設計の整合性をとる ..................................53 4 知らない相手でも安全安心につなげられる設計をする .................56 安全安心を実現する設計の評価・検証を行う .............................57 市場に出た後も守る設計を考える .......................................................58 自身がどのような状態かを把握し、記録する ..............................58 時間が経っても安全安心を維持する ........................................61 関係者と一緒に守る ........................................................................63 最新の IoT リスクを把握し、情報共有する ................................63 各ライフサイクルの関係者と協力し、安全安心を維持する .............67 ユーザにつながることによるリスクを知ってもらう ........................70 第 5 章 今後必要となる対策技術例...........................................................72 相手の品質を判定するしくみ ..............................................................73 5.1.1 相手の品質判定の方針 ..............................................................73 5.1.2 判定に用いる情報群 ..................................................................74 5.1.3 標準化動向 .............................................................................76 つながった機器に迷惑をかけない制御 .................................................77 5.2.1 波及防止の方針 .......................................................................77 5.2.2 当該コンポーネントによる波及の防止 .............................................78 5.2.3 当該コンポーネント以外による波及の防止.......................................78 5.2.4 標準化動向 .............................................................................79 付録．本書の活用方法 ............................................................................80 A1．チェックリスト ...............................................................................80 A2．最低限実施すべき対策の洗い出し ...................................................80 おわりに ...............................................................................................81 5 第1章 つながる世界と開発指針の目的 本章の概要を説明する文章を挿入予定。 6 つながる世界の概要 1.1.1 IoT とつながる世界 IoT とは「Internet of Things」の略であり、1999 年に提唱した Kevin によ れば人間の代わりに RFID やセンサーを用いて迅速かつ正確に情報収集を行うこ とによりムダやコストを削減する概念とのことである。しかし、現在の IoT は、収集した莫大なデータ（ビッグデータ）を用いて新しい知見を得たり、リ アルタイムに機器やシステムを制御することも主要な要素となっている。近年 のカーナビや家電、ヘルスケアなどの機器にはコンピュータシステムが組み込 まれ、情報収集、データ送受信、遠隔制御の機能を有する例も増加している。 これらの組込みシステムでは汎用 OS や標準通信規格が利用されるケースも多 く、様々なモノ（things）が容易に「つながる世界」が実現しつつある。 クラウド ビッグデータ ネットワーク RFID 情 報 収 集 フ ィ ー ド バ ッ ク 組込みシステム 図 1-1 IoT のイメージ なお、IoT が他の IoT につながることで、より大きな IoT を構成することが 可能である。これについては「System of Systems（SoS）」の概念が参考とな る。 System of Systems（SoS）の主要特性 1.構成要素の運用の独立性：個々のコンポーネントは独立かつそれ自体が役に 立つように運用できる。 2.構成要素のマネジメントの独立性：コンポーネントは、個別に調達され，インテ グレートされるとともに、SoS の中で独立に運用が可能である。 3.進化的開発：完成形ではなく、機能や目的が追加・削除・変更されながら進化す る。 4.創発的振る舞い：コンポーネント単独では実現できない目的や機能を果たす。 5.地理的な分散：コンポーネントは広域に分散し、モノやエネルギーではなく、情 報を交換する。 出典：”Architecting Principles for Systems-of-Systems” Mark W. Maier(訳：IPA) 7 本書の「つながる世界」も単につながるだけではなく、コンポーネントが独 立に運用管理され、単独でも有用である IoT が他の IoT とつながることにより 進化し、より大きな IoT として新たな目的や機能を実現する SoS の世界をイメ ージしている。 モノがつながったIoT(System) IoT(System)がつながったIoT(Systems) =System of Systems 1.単独でも有用 サーバ 3.完成形ではなく 継続的に進化 2.つながっても 独立に管理可能 中継 ノード 4.つながることで 新しい目的や 機能を実現 モノ IoT IoT IoT 5.地理的に分散し 情報を交換 IoT IoT IoT 図 1-2 SoS 的な特徴を持った IoT＝「つながる世界」のイメージ なお、経済産業省 産業構造審議会 商務流通情報分科会 情報経済小委員会は 2015 年、中間とりまとめ(案)において、産業基盤の高度化を図る Cyber Physical System (CPS)のイメージを公表している（図 1-3）。本図では、各分 野における CPS が IoT として横連携することでビッグデータ解析などの新しい 価値を生み出すイメージが示されており、SoS の概念に適合していると考えら れる。 CPS の生 高産 度現 化場 を等 実を 現つ （な い で ）産 業 基 盤 異なる分野の製品がつながって新 しいサービスを創造（IoT） 出典：経済産業省 産業構造審議会 商務流通情報分科会 情報経済小委員会 中間とりまとめ（案）に加筆 図 1-3 CPS と IoT のイメージ 8 1.1.2 各国における IoT 推進の取組み 国際的な IoT 推進の主な取組み例として、ドイツ政府が推進する Industrie 4.0 及び米国企業コンソーシアム Industrial Internet Consortium（IIC）の概 要及び特徴を紹介する。 Industrie 4.0 Industrie 4.0 とはドイツ政府が推進する製造業の高度化を目指すプロジェ クトである。第 4 次産業革命と称されている。その特徴はサーバーフィジカル システムをベースとした製造業の高度化である。Industrie 4.0 は BITKOM、 VDMA、ZVEI の 3 団体がプラットフォームインダストリー4.0 を作成して推進し ている。 この Industrie 4.0 のアーキテクチャ(RAMI4.0)はスマートグリッドアーキテ クチャモデル（SGAM）を踏襲した立方体の形式で定義されている。立方体の横 方向は PLM（プロダクト・ライフサイクル・マネジメント）を示しており、ま た、立方体の奥行方向は TIA（トータリー・インテグレイティッド・オートメ ーション）を示している。さらに、立方体の垂直方向は相互接続の求められる サービスや機能をそれぞれのレベルに応じて配置することを意味する。 出典：経済産業省「2015 年版ものづくり白書」 図 1-4 Industrie4.0 リファレンスアーキテクチャモデル 9 IIC（Industrial Internet Consortium） IIC とは、Intel、IBM、Cisco Systems、GE、AT&T など 5 社によって産業市場 における IoT 関連の標準を目指して設立された団体である。IIC はエネルギ ー、ヘルスケア、製造、運輸、行政等の領域を対象としている。IIC では IoT 向け規格の標準化団体に会員企業の要望を伝えることにより、互運用性を実現 し、IoT 規格の標準化やテストベッドによる検証環境構築の推進を目的として いる。 IIC のリファレンスアーキテクチャは、ビジネス視点、利用の視点、機能の 視点、 実装の視点の 4 つの視点で定義されている。実装の視点ではエッジ層、 プラットフォーム層、エンタープライズ層の 3 階層に分けられており、それぞ れの関係をデータの流れと制御命令の流れで表している。 出典：Industrial Internet Consortium “Industrial Internet Reference Architecture (Version 1.7)” 図 1-5 IIC の実装アーキテクチャ なお、GE は 2015 年 8 月、IoT のためのクラウドサービス「Predix Cloud」を 発表している。 Industrie 4.0 はドイツの機械産業の国際市場拡大、IIC は参加企業による IoT プラットフォームビジネスの市場創生が主要な目的と想定される。 ※IoT 関連規格の一覧表（コラム）を追加予定。 10 つながる世界のリスク 1.2.1 つながる世界のリスクとは つながる世界においては、遠隔から利用する機器やシステムの誤操作、ネッ トワークを通じた故障の影響の波及、ウイルス感染や不正アクセスなど、安全 安心上の課題が想定される。本書では、ユーザの身体や財産に被害をもたらす 潜在的な要因のうち、セーフティに係るものを「ハザード」、セキュリティに 係るものを「脅威」と呼ぶ。安全安心の実現には、機器やシステムのハザード や脅威の特定及び対策が必要である。 しかしハザードや脅威は多岐に渡るため、全てに対処することは現実的には 困難である。そこで、機器やシステムにおいて発生しうる被害の大きさ及び発 生頻度の組み合わせ（リスク）を評価し、そのハザードや脅威への対策の要否 を判断する必要がある。図 1-6 につながる世界のリスク対応のプロセスのイメ ージを示す（参考 ISO/IEC Guide51,ISO 31000, 他）。 つながる世界のハザード （例：欠陥など） つながる世界の 潜在的要因 の想定 つながる世界の脅威 （例：脆弱性など） 危害 （例：事故など） 被害 の想定 インシデント （例：ウイルス感染） 被害の大きさ リスク評価 ←組み合わせ→ 発生確率 セーフティ対策 設計開発 （対策） セキュリティ対策 図 1-6 つながる世界のハザードと脅威の想定、リスク分析及び対策 本書では、つながることにより発生するハザードや脅威を特定し、リスク評 価及び設計開発（一部運用）によって対策を行うための方針を示している。 11 なお、本開発指針でいう「安全安心」は「セーフティ」、「セキュリティ」 及び「リライアビリティ」を含んだ概念である。以下にそれぞれの定義を示 す。 本開発指針でいう「安全安心」 セーフティ 用語 安全安心 セーフティ セキュリティ リライアビリティ セキュリティ リライアビリティ 本開発指針での定義 対象とする機器やシステムのセーフティ、セキュリティ及びリ ライアビリティが確保されていること。 製品又はシステムが、経済状況、人間の生活又は環境に対 する潜在的なリスクを緩和する度合い。 人間又は他の製品若しくはシステムが、認められた権限の 種類及び水準に応じたデータアクセスの度合いをもてるよう に、製品又はシステムが情報及びデータを保護する度合い。 明示された時間帯で、明示された条件下に、システム、製品 又は構成要素が明示された機能を実行する度合い。 図 1-7 本書における安全安心の定義 様々なメーカやサービス事業者、さらにはユーザまでが機器やシステムをつ なげ、新しい使い方を実現できる世界において、いかに安全安心を維持するか が喫緊の課題と考えられる。 12 1.2.2 つながる世界のリスク例 ここでは、つながる世界におけるセーフティ、セキュリティ及びリライアビ リティリスク例を紹介する。 つながる世界のセーフティのリスク例 セキュリティ会議「Black Hat 2015」において、遠隔から車載機にアクセス し、走行中の自動車のハンドルやエンジンを不正に制御するデモが発表され た。人命に係る重大な危害が想定され、遠隔から姿を見られずに攻撃可能なこ とから実際に発生する可能性も否定できない。このためリスクが高いと考えら れ、実際に 140 万台のリコールにつながっている。 攻撃者のスマホ モバイル網 ① IPアドレスを調べて モバイル網経由で 車載機に侵入 本来は 車両情報をWebで 見られるサービス サービス用チップ CANにつながるチップ CAN （車載ネットワーク） 車載機 D-Busが オープンに なっていた 攻撃 ②CANにつながるチップの ファームウェアを書き換え ③遠隔からCANに命令を送信、 ハンドルやエンジンを不正操作 出典：一般社団法人重要生活機器連携セキュリティ協議会 生活機器の脅威事例集 図 1-8 自動車に対する遠隔からの攻撃 本事例の重要な原因として、モバイル網、車載機、車載ネットワーク、車両 情報を表示するサービスなどの構成要素がそのような攻撃を想定していなかっ たことが挙げられる。このため、攻撃者がモバイル網から侵入し、車載機に不 正アクセスし、チップのファームウェアを書き換え、車載ネットワークに不正 な命令を送信するという一連の攻撃が成立している。つながる世界において は、構成要素のどこかで攻撃を止めることが必要である。 またセーフティでは故意の攻撃を対象としていないため、つながる世界では 外部からの脅威がセーフティに係る機能に及ぼすリスクについても対応してい く必要がある。 13 つながる世界のセキュリティのリスク例 近年海外で、保守用扉の物理鍵を不正に入手し ATM の筐体を開けてスマート フォン等を接続したり、ウイルスを感染させて現金を引き出す事例が発生して いる。現金盗難という明確な危害があり、実際にインシデントが発生している ことからリスクが高いと考えられる。 保守用扉 物理鍵 インターネッ ト サイト 扉錠 ATM SMSテ キスト（ 出金指示等） 出金指示等 業界標準I/F 仕様書 ダウンロード 電話機 USBメモリ マルウェア USBポート USBポート HDD インストール アプリケーション CD-ROMドライブ マルウェア ブートメディア マルウェア開発者 リ モ ート指示 サーバ ミドルウェア ディスプレイ QR/スクランブルコード （ 金庫内紙幣枚数等） 操作 現地実行者 金 庫 出金 コマ ンド 紙幣処理部 リ モ ート指示者 現地実行者の取り分 を差し引いた現金 ドライバ OS ピンパッド 承認コード 制御部 BIOS 現金 ホスト コンピュータ 図 1-9 ATM のリスク事例（海外のケース） ATM については、銀行が調達先を自由に選べるように仕様が共通化されてお り、ある機種を解析すれば他のメーカの機種も攻撃しやすいという特徴があ る。特に近年の ATM の多くは Windows OS を使用していることから、スマートフ ォンなどの機器をつなげた攻撃の対象になりやすいと想定される。 また、ATM に限らず、内部関係者が機器に不正なソフトウェアを組み込んだ り、機器の設定や操作に関する情報を漏えいさせれば強固な機器でも脅威が高 まると想定される。 つながる世界では、どのような機器やシステムにおいてもリスク対応が必要 であるとともに、内部不正への対応も必要となる。 14 つながる世界のリライアビリティのリスク例 近年、一部のメーカのテレビが視聴中または録画中に電源が OFF/ON を繰り返 す不具合が発生した。あるメーカの発表によれば、テレビ番組と併せて送信さ れる「特定放送データ（共通の番組表や特定機種のファームウェア更新用デー タなど）」中の他社のデータを正常に処理できなかったとのことで、対象はそ のメーカだけで 118 機種、最大約 162 万台であった。 A社 B社 C社 更新 更新 更新 データ データ データ A社 更新 データ 地上波、BS電波 テレビ映像 A社テレビ 本来、自社に関する データを利用して アップデート 他社のデータ の影響で誤動作 図 1-10 更新用データによるテレビの誤動作 以前、パソコン用のアンチウイルスソフトウェアのパターンファイルに不具 合があり、PC の動作が極端に遅くなるというトラブルが発生した。土曜日であ ったため、企業の被害は新聞社や交通関係など限定されたが、それでも個人向 けで約 16 万 1000 件、法人向けで約 1 万 3000 件の電話が殺到、発生当初に対処 できた件数はそのうち 4000 件程度とのことである。 つながる世界では、PC だけでなく自動車や家電、その他、様々な機器やシス テムがネットワークにつながるため、何らかの原因で一斉に使用できなくなる 状況が発生すれば生活に与える影響は大きい。特に、ファームウェア更新の不 具合の影響は大きいと想定される。 15 開発指針の目的 本開発指針は、1.2 で例示したつながる世界のリスク対応に向けて、つなが る世界のハザードや脅威の想定、リスク評価及び設計による対策を推進するた めの方向性を提示することを目的とする。本書の対象読者は主として設計者で あるが、設計者だけでは対応が難しい事項については経営者や運営者も対象と している（「はじめに」参照）。 経営者 設計者 運用者 つながる世界への 企業としての取組み 開発 指針 ハザードや脅威の想定、 リスクの評価 守るべきものを守る、 市場に出た後も守る設計 運用担当者やユーザと 協力して守る取組み 図 1-11 開発指針のイメージ なお、指針の策定に当たっては、1.1 に示した IoT 及び SoS の概念を踏ま え、異なる分野の IoT がつながることによって新たな目的や機能を実現する IoT の安全安心をイメージしている。そのために、各業界での安全安心の取組 み状況や先進事例、異なる業界の機器やシステムの連携のための共通の要件に ついて記述している。 また、各業界の企業が現在の安全安心の取組み状況と指針との対応を確認で きるよう、チェックリストも付録としている。本書により、各業界における取 組みの推進と異なる業界の機器やシステムのつながりにおける安全安心の実現 を期待している。 16 第2章 開発指針の作成方針 本章の概要を説明する文章を挿入予定。 17 本開発指針の位置付け 図 2-1 に示すとおり、IoT について様々な団体で標準化が進められている。 それらの規格について、業界や特定の分野に依存する業界別・特定規格と、業 界や特定の分野に依存しない共通・汎用規格に分類できる。前者としては Industrie4.0 や IIC の規格等があり、後者としては IEEE、ISO/IEC、NIST、 oneM2M 等の規格がある。共通・汎用規格には前記の４つ以外にも、すでに国際 規格となっている ZigBee、MQTT 等の共通の通信規格がある。 図 2-1 汎用共通的な国際 IoT 規格及び産業界における IoT 規格 ここで、共通・汎用規格の高信頼化関連項目は、共通的な汎化された内容と なっており、実践的なリスクにまで踏み込んだ内容となっていない。また、業 界別・特定規格は業界別の個別事項を考慮している傾向が強い。本開発指針で は、実践的なリスクにまで踏み込んだものを前提としつつ、それを共通的なも としてまとめたものとする。そのために、各業界別の実際のリスク例をベース に業界横断的なものとしてまとめる（図 2-2）。 18 最新のＩｏＴ共通・汎用規格 の高信頼化関連項目 開発指針 共通的な汎化された内容 実践的なリスクにまで踏み込んだ ものでない 実践的なリスクにまで踏み込んだ ものを前提としつつ、それを共通的なものと してまとめ上げたもの 業界別・特定規格 の高信頼化関連項目 BottomUp 業界別の個別事項を考慮している 傾向が強い 各業界別 のリスク例 図 2-2 開発指針の位置づけ 普及展開 各業界・企業 の対策 19 本開発指針での「IoT の安全安心」の捉え方 「コンポーネント」と「つながり」により構成される IoT 安全安心に係る設計や評価は機器やシステムの基本構成に対して行われる場 合が多い。IoT は 1.1.1 で示したように IoT 同士がつながったり切り離された りすることで刻々と構成が変化していくため、何度も安全安心の設計の見直し や再評価が必要となる。 安全安心に係る設計・評価は 基本構成に対して実施 構成が変わると設計の見直しや 再評価が必要 つながる世界（IoT）では 構成が刻々と変化 何度も安全安心の設計の見直しや 再評価が必要 図 2-3 刻々と変化する「つながる世界（IoT）」の安全安心設計・評価 本開発指針では、1.1.1 で示した SoS の最小単位、すなわち IoT を構成する 機器やシステムのうち単独で目的や機能を果たすものを「コンポーネント」と 呼び、IoT は「コンポーネント」と「つながり（ネットワークや情報通信 等）」から構成されるものとする。その上で、「コンポーネント」の安全安心 の設計・評価により IoT 全体の安全安心を高める方策を検討する。 A社家電 Internet of Things B社自動車 つながる単位(構成要素) つながり 通信、通信規格等 コンポーネント 個別の機器、サービス、 システム等 C社システム 図 2-4 「コンポーネント」と「つながり」により構成される IoT 20 IoT の「コンポーネント」の安全安心 家電や自動車、省エネサービスなど個々の機器やシステム（コンポーネン ト）の安全安心の設計や評価は、メーカやサービス提供企業が実施している。 これに加え、コンポーネントがつながった場合でも安全安心を維持できる設 計・評価を行えば、インテグレータやユーザがコンポーネントを組み合わせて 利用する場合においても、IoT 全体の安全安心を高められると期待される。こ の際には、設計内容やその条件を利用側に分かりやすく伝えることも必要であ る。そこで本書では、コンポーネントがつながっても安全安心を維持するため の指針を示すこととした。 単体でも安全安心な コンポーネント Ａ社システム Ｂ社サービス 安全安心 安全安心 安全安心 安全安心 安全安心 ＩｏＴ インテグレータ 安全安心の 設計・評価内容 Ｃ社家電 Ｄ社スマホ Ｅ社自動車 つながっても安全安心な コンポーンネント Ａ社システム Ｂ社サービス 安全安心 安全安心 情 報 提 供 保証内容や 使用制限等 安全安心 安全安心 安全安心 Ｃ社家電 Ｄ社スマホ Ｅ社自動車 図 2-5 コンポーネントの安全安心 ＩｏＴユーザ 21 IoT の「つながり」の安全安心 IoT の「つながり」の安全安心に関しては、通信セキュリティ、通信の安定 性などが挙げられる。これらについては、図 2-1 で示した IoT に関する国際規 格などで検討されている。これを参照することにより、国際的にも連携可能な 安全安心対策の実現を目指すことが可能となる。 ISO/IEC IEEE oneM2M 策定中の国際IoT規格の 関連部分を参照し、開発指針を作成 Internet of Things つながり 通信、通信規格等 図 2-6 「つながり」の検討方針 安全安心なコンポーネントの実現方針 安全安心なコンポーネントの実現に向けた指針の策定フローを下図に示す。 IoTに対する 脅威やハザードの想定 コンポーネントのつながり、 守るべきもの、リスク箇所 主要な原因及び IoTに 着目した課題の整理 対策の方向性 （指針のプロトタイプ）の導出 安全安心な コンポーネントの開発方針 他のコンポーネントを守ったり、 迷惑をかけない機能の開発方針 つながる世界の開発指針 図 2-7 開発指針の策定フロー 本フローには「他のコンポーネントを守ったり、迷惑をかけない機能の開発 方針」が含まれている。これは、IoT には安全安心設計を行うことが難しい低 機能・低価格のコンポーネントや世代が古いコンポーネントも混在すると想定 22 され、各コンポーネントは自己を守るだけでなく、そのようなコンポーネント への対応が必要と想定されるためである。具体的には、傘下のコンポーネント に対する攻撃を遮断したり、インテグレータやユーザがつなげた他の機器に対 して自らの異常動作を波及させないことが挙げられる。 コンポーネント コンポーネント 傘下の コンポーネント 対策 異常信号 故障 外部の異常動作から 傘下のコンポーネントを守る 対策 他 社ユ のー コザ ンが ポつ ーな ネい ンだ ト 自分に異常動作が発生しても 他のコンポーネントに迷惑をかけない 図 2-8 他のコンポーネントの安全安心を実現するイメージ 以上より、コンポーネントの安全安心設計によって、刻々と構成が変化する IoT においても全体的な安全安心に寄与することが期待される。 23 第3章 開発指針の前提としたリスク分析 本章の概要を説明する文章を挿入予定。 24 ＩｏＴコンポーネントの特性整理の観点 本書における IoT コンポーネントの分析の考え方を以下に示す。 コンポーネントのつながりパターンの整理 【メーカーや関連会社がつなげるケース】 つ な げ た 者 【サービス事業者がつなげるケース】 自機 ？ 自機 メーカーが設計時に想定しているケース メーカーが設計時に想定していないケース 【ユーザがつなげるケース】 【攻撃者がつなげるケース】 ？ 自機 自機 意図的だけでなく、誤ってつなげるケースも ぜい弱性をついたケース等 ？ ※：その他、色々つなげているうちに偶発的なつながりが生じるケースも想定される つ な が れ 方 【直接的】 【固定的】 自機 【間接的】 自機 【複合的】 自機 【動的(必要時に接続)】 自機 仲介 特定・ 不特定 図 3-1 コンポーネントのつながりパターン（例） 説明文を追加予定 守るべきものの整理 要求に応じて 利用可能であること 本来機能 IoTアプリ、通信機能、 セキュリティ設定など (サーバ､センサー､ アクチュエータ等) IoT機能 (通信､連携､集約等) 自動販売機内の商品、 ATM内の現金、 本体や部品など 誤動作や不正利用により ユーザの身体や財産に 危害を与えうる機能など データ その他 図 3-2 守るべきものの例 説明文を追加予定 個人情報、決済情報、 センサーデータなど 25 リスク箇所の整理 IoT コンポーネントにおけるリスク箇所を以下に示す。 ローカル接続(RS-232C等)の 機器(センサーユニット等)は 本体に含める ⑤物理的接触 直接、本体に接触 本来機能 (サーバ､GW､ アクチュエータ等) IoT機能 ②メンテナンス用I/F 管理者用操作盤、 遠隔管理用通信I/F, ソフトウェア更新用の USB端子など (通信､連携､集約等) ①通常使用I/F ユーザ用操作パネル、 サービス用通信I/F, USB端子など データ ④内包リスク ③非正規I/F 故障の原因となる欠陥やバグ、 攻撃の対象となるぜい弱性、 故障や悪用で危害を及ぼす機能など ふさぎ忘れた不要ポート, 製造時にのみ使用する USB端子など 図 3-3 IoT コンポーネントのリスク箇所（例） 説明文を追加予定 具体的なリスクのイメージを下図に示す。 ⑤物理的接触 ウイルス、不正アクセス、 DoS攻撃、他のIoTコン ポーネントからの異常 データなど ①通常使用I/F 故障やバグによる異常 データ発信、出荷前に 感染したウイルスによる 不正サーバアクセスなど 本来機能 (サーバ､GW､ アクチュエータ等) IoT機能 (通信､連携､集約等) データ ④内包リスク センサーの不正交換、 拾ったIoT機器の誤操作など ②メンテナンス用I/F 保守要員の特権を利用した 設定変更や機能の不正利用、 誤った設定変更など ③非正規I/F 露出した回路への結線による IoTソフトウェア分析、 誤ったUSBデバイス接続など 図 3-4 IoT コンポーネントに対するリスク（例） 説明文を追加予定 26 つながる世界のリスク分析 別添予定の表を基に、リスク分析の手順を説明する予定。 27 第4章 つながる世界の開発指針 本章の概要を説明する文章を挿入予定。 28 ※開発指針導出のプロセスを説明予定。 開発指針の導出プロセス リスクから導き出した開発指針 大項目 4.1 つながる世界の 安全安心に企業とし て取り組む 指針 指針 1 安全安心の基本方針を策定する 指針 2 安全安心のための体制・人材を見直す 指針 3 内部不正や情報漏えいに備える 指針 4 つながる世界で守るべきものを特定する 4.2 つながる世界の リスクを認識する 指針 5 つながることによるリスクを想定する 指針 6 つながりで拡大するリスクを想定する 指針 7 物理的なリスクを認識する 指針 8 個々でも全体でも守れる設計をする 指針 9 つながる相手に迷惑かけない設計をする 4.3 守るべきものを 守る設計を考える 指針 10 安全安心を実現する設計の整合性をとる 指針 11 知らない相手でも安全安心につなげられる設計 をする 指針 12 安全安心を実現する設計の評価・検証を行う 4.4 市場に出た後も 守る設計を考える 指針 13 自身がどのような状態かを把握し、記録する 指針 14 時間が経っても安全安心を維持する 指針 15 最新の IoT リスクを把握し、情報共有する 4.5 関係者と一緒に 守る 指針 16 各ライフサイクルの関係者と協力し、安全安心 を維持する 指針 17 ユーザにつながることによるリスクを伝える 29 つながる世界の安全安心に企業として取り組む 安全安心の基本方針を策定する ポイント ・企業としてつながる世界の安全安心の基本方針を策定し社内に周知する。 ・定期的に基本方針の遵守及び安全安心の実現の状況を把握し、問題があれ ば再検討を行う。 解説 つながる世界においては、リスクが多様化・拡大し、企業の存続に係る影響 をもたらす可能性がある。また、そのリスク対策にはコストを要するため、開 発現場の判断を超える場合も多いと想定される。そこで、経営が率先して対応 方針を示すことが必要と考えられる。 しかしながら、IPA が先行して取り組んでいると想定した企業を対象に実施 したアンケートでは、セーフティ／セキュリティの基本方針を策定している企 業は半数以下という状況であった。つながる世界の安全安心に関する基本方針 の策定と周知が急務である。 0 10 20 30 明文化された基本方針はない（セーフティ設計） 明文化された基本方針はない（セキュリティ設計） 50 37 31 セーフティ設計を含む基本方針あり セキュリティ設計を含む基本方針あり セーフティ設計に特化した基本方針あり セキュリティ設計に特化した基本方針あり 40 14 17 6 9 出展：セーフティ設計・セキュリティ設計に関する実態調査結果 IPA アンケートより 図 4-1 セーフティ／セキュリティの基本方針の策定状況 つながる世界に向けて安全安心に係る基本方針を策定し、社内への周知、遵 守状況の把握及び見直しが必要である。 30 対策例 経営層が関与して、つながる世界の安全安心の基本方針を策定する。 ① 基本的な記載事項 ■IoT に関わらず、企業が記載すべき項目例（内容は業種や業態による） ・安全安心の対象（ユーザの生命や財産など）や対策のレベル ・安全安心な管理体制の確立および関連規程の整備・遵守 ・適切な人的・組織的・技術的対策および継続的な教育 ・問題が発生した場合の迅速な原因究明、被害の抑制及び再発防止 ・法令、国が定める指針、その他の社会的規範の遵守 ・継続的な見直し及び改善 など ② つながる世界の安全安心に向けた記載事項（例） ■つながる世界で必要となる事項（内容は業種や製品による） 1) 企画・設計段階からの安全安心への取組み (Safety & Security by Design) 後付けでの安全安心対策はコスト面、効果面で課題が多いため、プロセス の早期から取り組む。 2) つながる世界でのサポート方針 刻々と変化するつながる世界において、出荷した機器やシステムの安全安 心を維持する方針、さらに安全安心の保証の期限や使用制限などに関す る方針を定める。 3) つながる世界の安全安心対策の評価・検証の方針 つながる世界における外部からの影響や外部に影響を与えうる機能に対 する安全安心の評価・検証（出荷判定条件を含む）の方針を定める。 4) つながる世界の事故や障害の迅速な対応方針 生活やビジネスを支えるインフラである IoT における事故や障害時の早期 対応の方針を定める。 5)つながる世界の安全安心の方針の見直し 想定外の課題が予想されるつながる世界において安全安心の知見を蓄積 し、PDCA サイクルにより方針を見直していく。 31 安全安心のための体制・人材を見直す ポイント ・つながる世界において、セーフティ、セキュリティ及びリライアビリティ の問題を統合的に検討できる体制を整える。 ・そのための人材（技術者や運用担当者など）を確保・育成する。 解説 つながる世界では想定外の問題が発生したり、影響が広域に波及したりする 可能性がある。その場合、被害の波及を防いだり、原因を分析したり、ソフト ウェア改修などの対策を実施したりする体制が必要となる。つながる世界では 様々な企業の機器やシステムにより構成されるため、企業が連携して対応に当 たる「体制の連携」も必要である。 事故 インシ デント 図 4-2 に対する問い合わせ また、知識や技術を活用して対応に当たる人材の確保・育成も必要となる。 対策例 ① 安全安心に関する体制の例 安全安心の検討体制を連携させ、つながる世界での問題に統合的に対処 可能な体制を整備する。 ■基本的な体制の例 1) 製品安全管理態勢の整備・維持・改善（組織体制） 経済産業省が公表した「製品安全に関する事業者ハンドブック（2012 年 6 月）」の「1-3．組織体制」において、「事業者は、製品安全に関する内部統 制の目的を果たすために、社内外における組織の 役割と権限を明確化 し、製品安全管理態勢の整備・維持・改善の観点から、組織のあり方を検 証し続けることが必要である。」との推奨事項が示されている。 32 また 4 章では「ステークホルダーとの連携・協働」として、消費者や販売事 業者、設置事業者等との連携・協働による製品事故の未然防止、被害の拡 大防止策が示されている (http://www.meti.go.jp/product_safety/producer/jigyouhandbook.pdf) 2) CSIRT (Computer Security Incident Response Team：シーサート) コンピュータセキュリティインシデントへの対応、対策活動を行う組織の総 称であり、インシデント対応及びその支援、分析や教育、研究開発などを含 めて様々な活動を行う。日本シーサート協議会において組織内 CSIRT の 設置のためのスタータキットを公開している（http://www.nca.gr.jp/）。企業 の CSIRT が連携して対策に当たる WG などの枠組みもある。 ② 人材育成に有用な情報源 ■参考資料 1)つながる世界のセーフティ＆セキュリティ設計入門（IPA） つながる世界における安全安心の実現に向けて、事故及びインシデント事 例、セーフティ及びセキュリティ設計手法、関係者間での情報共有やユー ザ説明に有用なセーフティ・セーフティ設計品質の見える化手法などを紹介 している。(http://www.ipa.go.jp/sec/reports/20151007.html) 2)組込みシステムのセキュリティへの取組みガイド（2010 年度改訂版）（IPA） 組込みシステムのセキュリティ対策に関するガイド。改訂に当たり、IoT で の活用が想定される IPv6 を利用した組込みシステムへの攻撃想定と対策 などの記述を追加。 (https://www.ipa.go.jp/security/fy22/reports/emb_app2010) 3) 自動車の情報セキュリティへの取組みガイド（IPA） 特に自動車に焦点を当てた組込みシステムのセキュリティガイド。欧州の 先進事例を調査するとともに、モデルとして「IPA カー」を設定し、リスクの想 定と対策の検討を行った。 (http://www.ipa.go.jp/security/fy24/reports/emb_car/) 33 内部不正やミスに備える ポイント ・つながる世界の安全安心を脅かす内部不正の潜在可能性を認識し、対策を 検討する。 ・社員のミスを防ぐとともに、ミスがあっても守る対策を検討する。 解説 海外では、不満を持った退職者が遠隔から自動車の管理サービスを不正操作 し、自動車を発進できなくしたり、ホーンを鳴らしたりする事件[参考]や、銀 行が管理する ATM の物理鍵を複製し、その鍵を用いて ATM の保守扉を開けてウ イルスを感染させた上で、ATM の USB 端子にモバイルデバイスをつなげて現金 を払い出させる事件が発生している。つながる世界のサービスを構成する機器 やシステムの設計や構造を熟知していたり、アクセス権限や鍵を不正に利用で きたりする社員や退職者による「内部不正」への対策が必要である。 また悪意がない場合でも、標的型メールの添付ファイルを開封したり、持ち 出した情報を紛失したりすることにより設計情報が漏えいするような「ミス」 への対策が必要である。 退職した技術者 メール添付のウイルス付き ファイルを開封してしまった社員 設計を熟知 開発企業 悪意が ある社員 いつのまにか 情報漏えい 漏えい情報を 利用した攻撃 IoT 機密を転売 図 4-3 内部不正やミスによる影響 対策例 ① 内部不正への対策例 つながる世界での内部不正は他社の機器やシステム、ユーザにも多大な 影響を与えるため、原因の理解と対策の必要性の認識が必要である。 34 IPA 調査による内部不正事例では、金銭詐取や転職を有利にする目的、仕 事上の不満が主な原因となっている。同調査における、企業社員に対する 「不正をしたいと思う気持ちが高まると思う条件」のアンケート結果でも「不 当だと思う解雇通告を受けた」、「条件のいい企業に対して有利に転職がで きる」が上位となっている（表 4-1）。 表 4-1 不正をしたいと思う気持ちが高まると思う条件（アンケート結果） 分類 動機・プレ ッシャー 環境・機会 順位 割合※ 1位 不当だと思う解雇通告を受けた 30.0% 2位 条件のいい企業に対して有利に転職ができる 10.2% 3位 社内の人事評価に不満がある 8.2% 1位 職場で頻繁にルール違反が繰り返されている 8.8% 2位 社内ルールや規則を違反した際、罰則がない 8.7% 3位 1位 知識・経験 内容 2位 2位 システム管理がずさんで、顧客情報を簡単に 持ち出せることを知っている 自分が情報システムの管理者ではないが、不 正操作した証拠を消去することができる 社内の誰にも知られずに、顧客情報などの重 要な情報を持ち出せる方法を知っている これまでに顧客情報などの重要な情報を持ち 出しても誰からも注意や指摘を受けなかった 8.4% 9.8% 9.5% 9.5% ※内部不正行為への気持ちが高まると回答した回答者の割合。 出典：IPA 組織内部者の不正行為によるインシデント調査 IPA では「組織における内部不正防止ガイドライン」[ ]において、内部不正 の基本 5 原則を公開している。本ガイドラインはつながる機器やシステムの 内部不正リスクにも共通する事項が多いため、参照されたい。 表 4-2 内部不正の基本 5 原則 基本５原則 概要 犯行を難しくする (やりにくくする) 捕まるリスクを高める （やると見つかる） 犯行の見返りを減らす （割に合わない） 犯行の誘因を減らす （その気にさせない） 犯罪の弁明をさせない （言い訳させない） 対策を強化することで犯罪行為を難しくする 管理や監視を強化することで捕まるリスクを高める 標的を隠す/排除する、利益をなくすことで犯行を防ぐ 犯罪を行う気持ちにさせないことで犯行を抑止する 犯行者による自らの行為の正当化理由を排除する 出典：IPA 組織における内部不正防止ガイドライン 35 ② 社員のミスや違反への対策例 近年、特定の企業や組織に対して、関係者や政府関係など信頼性が高い団体 の担当者を名乗り、ウイルスを含む添付ファイル付のメールを送りつける攻撃 が急増している。ウイルスは情報漏えいのみならず、銀行勘定系システムに 感染し、システムの不正操作を通じて ATM から金銭を払い出させるものもあ る。 ＩＰＡからメール？ セキュリティ対策の 報告書か 添付のpdfを開くと マルウェアに感染 政府関係組織 図 4-4 実際にあった標的型攻撃メール つながる機器やシステムの開発や運用の現場に関わらず、このような攻撃が 流行していることを社内に認知させることが重要である。しかし、標的型メール は非常に巧妙になっており、ついウイルスを含む添付ファイルを開封してしまう 場合も多いため、社内ネットワークの設計によりウイルスによる情報漏えいを 防ぐ対策も必要である。IPA では、ウイルス感染後のウイルスの動作を防ぎ、 被害を最小限に留めるための「『高度標的型攻撃』対策に向けたシステム設計 ガイド」を公開している[ ]。 36 つながる世界のリスクを認識する つながる世界で守るべきものを特定する ポイント つながることによるリスクから守るべき情報や機能を特定する。 解説 個別の機器やシステムにおいては、事故が起きても人を守ったり、不正アク セスから情報を守ったりするなどの安全安心対策が必要となるが、つながる世 界ではさらにつながりに起因するリスクに対応する必要がある。そのため、つ ながる世界で守るべきものを特定することが重要となる。 ネットワーク ＋ 個別の機器・サービスのリスクから 守るべきものを守る || 従来の安全安心 つながりによるリスクから 守るべきものを守る || つながる世界の安全安心 図 4-5 従来の安全安心とつながる世界の安全安心 対策例 具体的には、以下の対策例が挙げられる。 1) 守るべき機能の洗い出し ・本来機能 IoT コンポーネントは IoT の構成要素であるとともに、自動車であれば「走る」、 「曲がる」、「止まる」、エアコンであれば冷暖房などの本来機能を有している。 これらの機能がユーザが要求したときに利用できなかったり、不正に利用され ないように守る。特に身体や財産に関わるセーフティ関連機能は優先的に守 る。 37 ・IoT 機能 IoT コンポーネントは IoT の構成要素としてデータ収集、送信、被制御などの IoT 機能を有しており、IoT 全体の目的を達成するために個別の IoT 機能を守 る。また、一部の IoT コンポーネントや通信が停止した場合でも本来目的を達 成できるよう、全体の IoT 機能を守る。 電力データ 蓄積 HEMS サーバ 消費電力 分析 消費電力計測 HEMS端末 受像、表示 通信、通話 ON/OFF 被制御 電力グラフ 表示 冷暖房 ON/OFF指示 ON/OFF制御 電力グラフ 表示 ON/OFF 被制御 家電遠隔 ON/OFF 本来機能 IoT機能 図 4-6 本来機能と IoT 機能の例（HEMS の場合） ・機能を構成するソフトウェアや設定 上記の機能を構成するソフトウェアやその設定を読み出されると、攻撃手法の 考案に利用されるなど様々なリスクにつながるため、守る必要がある（［指針 7］参照）。 2) 情報やデータの洗い出し 末端の IoT コンポーネントが収集したり、サーバが蓄積するセンサーデータ、 個人情報（プライバシー含む）、他のデータを守る。 表 4-3 組込みシステムで保護すべき情報資産の例 情報資産 説明 コンテンツ ユーザ情報 機器情報 ソフトウェアの状態 データ ソフトウェアの設定 データ ソフトウェア 設計データ内部ロ ジック 音声、画像、動画等のマルチメディアデータ（商用コンテンツ利用 時の著作権管理データおよびプライベートコンテンツ等）、コンテ ンツ利用履歴（コンテンツの利用履歴も保護することが重要）等 ユーザの個人情報（氏名/住所/電話番号/生年月日/クレジットカ ード番号等）、ユーザ認証情報、利用履歴・操作履歴等 情報家電そのものに関する情報（機種、ID（Identification）、シリア ル ID 等）、機器認証情報等 各ソフトウェアに固有の状態データ（動作状態、ネットワーク利用 状態等） 各ソフトウェアに固有の設定データ（動作設定、ネットワーク設 定、権限設定、バージョン等） OS（Operating System）、ミドルウェア、アプリケーション等（ファー ムウェアと呼ばれることもある） 企画・設計フェーズで発生する仕様書・設計書等の設計情報 出典：IPA 組込みシステムのセキュリティへの取組みガイド 38 つながることによるリスクを想定する ポイント ・通信機能を有する機器やシステムは、開発側の意図に関わらず IoT に組み 込まれてしまう前提でリスクを想定する。 解説 以前、Web 機能を有する HDD レコーダーがブログ向けのスパムコメントの踏 み台にされるというインシデントが発生した。また近年、複数メーカのプリン ター複合機に蓄積されたデータがインターネットから公開状態になるというイ ンシデントも発生している。どちらも、メーカ側がインターネットに直結され ることを想定しておらず、ID・初期パスワードが未設定または Web で公開され た状態で出荷し、ユーザにも初期パスワードの設定を依頼していないことが原 因であった。 インターネット インターネット 踏み台化 複数の大学 NAT設定 なし ルーター ID/パスワードは HDDレコーダー 出荷時は無効化 初期パスワード 変更なし プリンター複合機 ルーター 蓄積データ 参照可能 ファイア ウォール なし 図 4-7 インターネットにつながらないと想定していたため発生したインシデント例 ユーザによって外部アクセスが可能なように設定されたり、ファイアウォー ルがないネットワーク環境に設置されたりする可能性を想定せず、初期設定が 不十分のまま出荷したこと、設置担当者にリスクや対応を周知していなかった ことが課題として挙げられる。 39 対策例 以下に、対策例を示す。 1)「クローズドな環境向けだから安全安心」という油断の排除 IoT につながる機能がある機器やシステムは、家庭や企業の LAN で使用する 想定であっても IoT コンポーネントとして利用される前提で設計、運用する。 IoT接続 つながる機器 やシステム を想定 つながるものはＩｏＴにつながる メーカーＡ社 ＩｏＴ クローズドな 環境を想定 つながる機器 やシステム メーカーＢ社 外部からアクセス可能な環境 に設置される可能性も 図 4-8 つながるものは IoT につながる 具体例を以下に示す。 ・出荷時の初期パスワードを同一にしない。また、推定されにくいものとする。 ・ユーザ側でのパスワード変更を必須とし、パスワードの自動生成またはユー ザが入力したパスワードの強度をチェックする。 ・必須でない場合はサーバ機能を持たせない。持つ場合は使用するポートを 最小限とし、その他は使用不可とする。 ・内部の機能はすべて管理者権限とせず、適切なユーザ権限を割り当てる。 2)想定外の状況への対応 将来的には、機器やシステムの接続環境を確認し、問題がある場合には対策 を促す機能を設けることが期待される。具体例としては、以下の状況を検知す るとユーザに変更を促すメッセージを表示したり、サポート担当に通知したりす る機能が挙げられる。 ・一定期間、パスワードが変更されない場合 ・外部からアクセス可能な環境に設置されている場合 など 40 つながりで拡大するリスクを想定する ポイント ・つながりによる危害の拡大、安全安心レベルが異なる機器やコンポーンネ ントのつながりによるリスクを想定する。 解説 機器やシステムに故障が発生したりウイルスに感染した場合、つながりを通 じて影響が広範囲に伝播することが懸念される。また、安全安心レベルが異な る IoT コンポーネントがつながることで全体的な安全安心レベルが低下するこ とも想定される。つながりの部分が安全安心の弱点となる可能性もある。 異なる業界の IoT 製品やサービスはリスクの想定や安全安心の設計方針が異 なると想定され、つながりで拡大するリスクへの協調した対応が必要である。 つなげやすい 拡大していく ＩｏＴ 誤ったつながり、共用機器 に対する制御の競合など 故障の影響やウイルスの伝播、 安全安心レベルが異なるIoTの混在 図 4-9 つながりによるリスクの増大例 対策例 想定するリスクの例を以下に示す。 1) つながりを介して伝播するリスクの想定 故障による異常がつながる他の IoT コンポーネントに影響を与えるリスク、ウ イルスがつながりを介して IoT 全体に波及するリスクなどを想定する。 図 4-10 つながりを介して伝播するリスクのイメージ 41 2) 異なる安全安心レベルの IoT がつながることで生じるリスクの想定 安全安心のレベルが異なる IoT がつながることで、レベルが低い IoT が攻撃 の入り口になるリスクを想定する。 セキュリティレベル高 セキュリティレベル やや低 攻撃者 守るべきもの セキュリティレベル やや高 セキュリティレベル低 図 4-11 弱い部分からリスクが発生するイメージ 3) つながる共用機器のリスクの想定 家庭用ロボットや表示デバイス、IP カメラなど、複数のサービス事業者の共同 利用が想定される機器やシステムについて、操作が競合したり、共用のインタ フェース経由で第三者に不正アクセスされるリスクを想定する。 Ａ社防犯サービス Ｂ社のスマホアプリで 家族の帰宅をチェック 制御が競合？ ネットワーク インタフェース ネットワークカメラ 不正アクセス のリスクも 図 4-12 共用機器のリスクのイメージ 4) その他のつながりによるリスクの想定 ユーザの誤った接続による事故、偽の IoT 機器の接続による攻撃、無線 LAN 経由の不正アクセスなどのリスクを想定する。 42 物理的なリスクを認識する ポイント ・機器を管理者のいない場所に置いたり、落とした場合に対する物理的なリ スクを想定する。 ・中古や廃棄された機器の情報等の読み出しやソフトウェアの書き換え・再 販売などのリスクを想定する。 解説 つながる世界では、家庭や公共空間などに設置して利用している機器やシス テムも IoT につながっていく。これらの物理的に管理されていない機器に対し て第三者が直接、何かをつなげたり、不正に操作したりする危険性がある。 図 4-13 メーカにより物理的に管理されない家庭や公共空間の機器やシステム また、落としたウエアラブルデバイスが子供に操作されて宅内の家電の遠隔 操作機能が誤作動したり、廃棄した機器から情報が漏えいする可能性もある。 つながる世界においては、このような物理的なリスクの想定が必要となる。 対策例 ① 物理的リスクの想定例 1) 落とした IoT コンポーネントに起因するリスクの想定 落としたウエアラブル端末が拾われ、いじられることによる IoT サービスの誤 動作や不正に操作されるリスクを想定する。 ウエアラブル 端末を落とす 子供が拾って いじり回す IoTサービス が誤動作 ON! 図 4-14 落とした IoT コンポーネントによる物理的リスクの例 REC! 43 2) 駐車場や庭に入って物理的に攻撃されるリスクの想定 駐車場の車や庭に置かれた省エネ機器などの IoT コンポーネントに不正な機 器をつなげられて遠隔操作されるなどのリスクを想定する。また、留守宅に侵 入して家電の設定を変更し、不正なサイトに接続させるリスクも考えられる。 遠隔から不正な命令を送信し、 車を遠隔操作 駐車場に置かれた車のドアを開け、 車載ネットワークに不正なIoT機器を設置 止まれ ! 走れ ! 図 4-15 駐車場の車に攻撃される物理的リスクの例 ② 不正な読み出しや書き換えの想定例 1) 廃棄された IoT コンポーネントから守るべきものを読み出されるリスクの想定 廃棄された IoT コンポーネントのソフトウェアや設定を読み出してつながる仕 組みを解析して IoT の攻撃に利用したり、個人情報を読み出し、なりすましに より不正アクセスするリスクを想定する。 廃棄されたIoTコンポーネント を入手 ソフトウェアや個人情報 を読み出し、解析 解析結果や個人情報を 利用してIoTに不正アクセス ソフトウェア 個人情報 図 4-16 廃棄された IoT コンポーネントを利用して攻撃されるリスクの例 2) IoT コンポーネントに不正な仕組みを埋め込み、中古販売されるリスクの想定 IoT コンポーネントのソフトウェアを不正なサイトに接続させるように書き換えて オークションに出したり、中古店に販売されるリスクを想定する。 IoTコンポーネントの ソフトウェアを書き換え 自動的に不正な サイトに接続 する仕組み オークションや中古店に販売 購入者がネットにつなぐと 自動的に不正なサイトに接続 中古センター 図 4-17 不正なサイトに接続する中古 IoT コンポーネントが販売されるリスクの例 44 守るべきものを守る設計を考える 個々でも全体でも守れる設計をする ポイント ・外部インタフェース経由／内包／物理的接触によるリスクに対して個々の IoT コンポーネントで対策を検討する。 ・個々の IoT コンポーネントで対応しきれない場合は当該コンポーネントを 含む上位コンポーネントによる対策を検討する。 ・攻撃の高度化等によるセキュリティリスクの増大に備える。 解説 IoT コンポーネントは、想定されるリスクから守るべきものを守る設計が必 要である。前述の図 3-4 では、IoT コンポーネントにおいて想定されるリスク として以下を挙げている。 - 外部インタフェース（通常使用 I/F、メンテナンス用 I/F、非正規 I/F） 経由のリスク - 内包リスク - 物理的接触によるリスク 外部インタフェース経由のリスクとしては、DoS 攻撃、ウイルス、再送攻 撃、なりすましなどの攻撃や他の IoT コンポーネントからの異常データなどが 考えられる。特に、メンテナンス用 I/F については攻撃に対する対策が不足し がちである。内包リスクの要因としては、検出されなかった欠陥、出荷前に不 正に埋め込まれたマルウェア、誤設定などが考えられる。物理的接触によるリ スクの要因としては、家庭や公共空間等などに置かれた IoT コンポーネントの 持ち逃げ・分解、部品の不正な入れ替えなどが挙げられる。 遠隔監視 通信回線切断 物理的攻撃 機器の部品 入れ替え 機器の持ち逃げ・分解 図 4-18 機器に対する物理的接触による攻撃 45 IoT コンポーネントにはセンサーなど低機能のものも含まれており、単独で は対策機能の実装が難しい場合がある。このような場合については、それらを 含む上位の IoT コンポーネントによって対策を行う必要がある。 さらに、実装されたセキュリティ機能に対しては、暗号鍵推定やハッシュ値 衝突攻撃、プログラム解析技術等、攻撃手法が高度化していく傾向があるた め、リスク増大への対策も必要となる。 対策例 ① 外部インタフェース経由のリスクに対する対策 ○外部インタフェース 一般的に、メッセージフィルタリング、利用者認証、通信情報の暗号化・正 当性検証や証明書検証、ソフトウェア難読化、最新のファジングツール等 による継続した脆弱性対策、ロギングなどの対策が行われている。[文献 番号] ○メンテナンス用 I/F 限定された機器、利用者用のインタフェースであるため、接続機器認証、 利用者認証等のアクセス制限対策が行われている。また重要な機器は、 物理的な鍵で保護するとともに、二重鍵、生体認証、認証された機器のみ が通信できる特殊プロトコルなどを適用する例も増えている。 ② 内包リスクへの対策 ・一般的に、外部から調達する部品（ソフトウェアを含む）の選定において設 計データや品質データを入手し、不正な埋め込みや品質上の問題がない ことを確認する対策が行われている[文献番号]。 ・有料コンテンツ・サービスを利用するための端末では、入力データの正当性 チェック、自プログラムの作成データの正当性チェック、プログラム自体の 改竄チェックの適当なタイミングでの実施、といったことにより、外部に影響 を及ぼす処理・データの実行時のチェックを行っている（注１）。また、重要 な情報については暗号化等の秘匿対策を行っている。 ・内蔵時計（ハード実装／ソフト実装）を持つ端末では、時刻のずれや時刻改 竄が機能障害やコンテンツの不正利用を引き起こす可能性があり、一般に 46 は外部の信頼できるシステムを利用した定期的な時刻補正や時計機能の 耐タンパー性の強化を行っている。また、複数の IoT コンポーネントの機能 が相互に関連するケースでは、それらの間で時刻同期を行っている（直接 的な同期、あるいは共通の時刻補正方式の導入）場合がある。 ・スマートフォン等のオープンなプラットフォーム上で動作するソフトウェアで は、最新のファジングツール、脆弱性検査ツール、セキュリティ診断ツール 等を使って外部に影響する処理の重点的な検証を行っている。 注１）改竄チェックの対象箇所、改竄チェックの方式は、利用可能な資源 の仕様、チェック対象の重要度によって選択する必要がある。 ③ 物理的接触によるリスクへの対策 ・機器が盗みだされて分解されても内包する情報やソフトウェアを読み出され ない耐タンパー性の実装例として、有料コンテンツ等を扱う端末での対策 例示す[文献番号]（組み合わせでの適用もあり）。 ○ハードウェア・構造設計による対策 １）機器を分解すると BUS が切断されたり、インタフェースが破壊されたり することで解析を妨げる設計。 ２）不要な非正規インタフェースや露出した配線の除去。 ３）専用デバイスを接続しないと内部にアクセスできない設計。 ４）漏えい電磁波から内部処理を推定させないための電磁シールド。 ５）チップ間の直接連結（Ball Grid Array 等）による BUS 経由の不正アクセ ス防止。 ○データやソフトウェア設計による対策 １）ソフトウェアの難読化、暗号化、処理の複雑化。 ２）機密データの暗号化、使用時のメモリ在中時間の短縮や SWAP 域等へ の書き出し対策。 ３）実行時のメモリ上でのプログラムやデータの改竄の防止（チェックサム やダイジェスト情報によるチェックなど）。 47 ④ 上位コンポーネントで守る対策 ・IoT コンポーネントがインターネットにつながる接点を絞り込むとともにゲー トウェイを設置し、攻撃を遮断する設計を行う。[文献番号] DoS 攻撃 再送攻撃 なりすまし 攻撃遮断 ウイルス ゲートウェイ ・上位のコンポーネントにより内包する機器やシステムを監視し、異常検知や 原因推定を行う。例としては、家電の遠隔管理のための仕様である Broadband Forum (BBF)の TR-069 が挙げられる。 [文献番号] ⑤ 守る範囲を定める境界を設ける ・IoT コンポーネントを構成する機器やシステムをいくつかの通信可能な範囲 （以降[ドメイン]）に分割し、異常発生の影響の範囲を局所化する対策がと られることがある。ドメインを分割する境界の実現方法としては、ドメイン毎 に通信管理用のゲートウェイを設け、通信可能な要素のアドレスを登録し ておくといったものがある。また、ドメインの中にドメインを設けることによっ て、保護の多重化も可能である。 ⑥ 攻撃の技術的高度化等によるリスクの増大への対策 ・セキュリティ対策の陳腐化や内部情報の流出等によるセキュリティリスクの 増大に対して、端末の失効運用やソフトウェアを安全に更新するための対 策がとられている例がある。 ○セキュリティリスクが増大した端末の失効 セキュリティリスクの影響が大きい分野では、端末毎、あるいは端末の製造 ロット毎に電子証明書を発行し、暗号鍵の推定リスクやハッシュ衝突攻撃に よる重要データの改竄リスクが高まったときに、電子署名書を失効させるこ 48 とで対策が陳腐化した機能を無効化する運用が行われている。 ○ソフトウェアの妥当なタイミングでの安全な更新 端末のファームウェアを更新するサービスは一般的に行われているが、セ キュリティリスクの増大に伴い、ファームウェア更新自体への攻撃や障害 による更新中断への対策が行われているケースが増えている。 49 つながる相手に迷惑をかけない設計をす る ポイント ・IoT コンポーネントの異常を検出する設計を行う。 ・IoT コンポーネントの異常の影響を他の IoT コンポーネントに波及させな い設計を行う。 ・IoT コンポーネントがネットワークから切り離された場合に、管理サーバ が特定して復旧できる設計を行う。 解説 ソフトウェア／ハードウェアの障害や攻撃などによる異常な動作が発生した 場合、影響拡大を防ぐために、まず異常な状態を検出できるようにする必要が ある。 異常な状態が検出された場合、内容によっては影響が他の IoT コンポーネン トに波及する可能性があり、それを防ぐために当該 IoT コンポーネントをネッ トワークから切り離す等の対策の検討が必要である。 上記のネットワークからの切り離しが発生した場合、その IoT コンポーネン トの機能を利用していた他の IoT コンポーネントやユーザへの影響を抑えるた めに、状況に応じて早期に復旧するための設計が必要となる。 図 4-19 機能の切り離しと復旧のイメージ 50 対策例 ① 異常状態の検出 異常状態の検出は、まず各 IoT コンポーネントが個々に行っておく必要があ る（対策例は 3 [指針 8]を参照）。ただし、仕様や異常の状態によっては IoT コ ンポーネントが自身の異常を検出できないケースがある。このケースに対し ては、IoT コンポーネントのログ情報を監視サーバが参照することによって異 常状態を検出する対策が取られている例が見られる。 ログによる監視の例を以下に示す。 ・個々の IoT コンポーネントのログ情報の監視 監視システムが適当なタイミングで対象の IoT コンポーネントのログ情報 を参照し、異常の発生を検出する。 ・連携した複数の IoT コンポーネントの監視 複数の IoT コンポーネントの連携が重視されるケースでは、監視システム が関連したコンポーネントの処理結果の整合性を確認して異常を検出する 例がある。[文献番号] ・多数の IoT コンポーネントからの異常発生場所の特定 ログ監視にはサーバ側の CPU や記憶域、ネットワーク帯域などの資源を 消費することになるため、ログの内容と監視方法を適切に設計する必要が ある。以下に性能を考慮した監視方法の例を示す。 51 ② 異常状態の影響の波及抑止 ・IoT コンポーネントが自身の異常な状態を検出した場合、それが他の IoT コ ンポーネントに影響を及ぼす可能性がある場合は、自身を停止、あるいは ネットワークから切り離すことにより、影響の波及を抑止する例がある。 ・監視サーバが IoT コンポーネントの異常を検出した場合は、その内容によ って当該 IoT コンポーネントに停止やネットワーク切断を指示したり、ルー タ等を利用して強制的にネットワークから切り離す対策がとられている例 がある。 ③ IoT コンポーネントの復旧 ・異常が発生した機能のみ制限する 発生した異常が機能に限定されていると判断される場合は、その機能の実 行のみ制限し、他の機能は実行可能としておく、といった対応をとっている 例がある。以下に例を示す。 - 当該機能の受信ポートのみ閉鎖する - 当該機能を実行するプロセスのみ停止する - 環境設定により当該機能が必ずエラーを返すようにする ・停止された IoT コンポーネントを再起動・再接続するケース 状況によっては、当該 IoT コンポーネントを再起動することで異常な状態 が解消され、復旧するケースがある。再起動は、異常検出を契機として IoT コンポーネント自身で行うケースと、監視サーバ等の外部から行うケー スとがある。 ・切断された IoT コンポーネントの復旧で作業が必要なケース ネットワークから切り離された IoT コンポーネントは、監視サーバなどが検 出して復旧させる必要があるが、監視対象の数が非常に多かったり、ネッ トワーク帯域が限られている場合、監視処理が制約されるケースがある。 この場合、前述①の「多数の IoT コンポーネントからの異常発生場所の特 定」で示した方法がある。これにより、復旧対象の IoT コンポーネントを特 定したら、その運用方針や機能に応じた手順でネットワークに再接続させ る。 52 ※レジリエンスに関するコラムを追加予定。 ＜コラム＞ 近年、製品・サービスの品質やセキュリティだけでなく、故障や異常が 発生した場合の回復力についても重視されており、ISO 等の標準化や IoT の活動の中でも検討課題となっている。 ・ISO/TC 292 Security and resilience ・IIC と Internet Industrie 4.0 の重要な設計思想の１つとして Resilient & Secure が挙げられている。 IoT の世界では、異なる会社や組織の製品・サービスがつながることに なり、その中で異常発生時の高い回復力を実現し高可用性につなげるた めには難しい課題が多く、今後も動向調査と検討が必要である。 53 安全安心を実現する設計の整合性をとる ポイント ・セーフティとセキュリティの設計を見える化する。 ・セーフティとセキュリティの相互の影響を確認する。 解説 セーフティとセキュリティの設計品質を適切なレベルで実現するために、以 下の見える化を行う。 - ハザードや脅威とそれらから引き起こされるリスクに対する分析と評価 - 上記への対策 設計の見える化において、IoT コンポーネントがつながる世界で影響を受け る範囲、影響を与える範囲を考慮する必要がある。 セキュリティ上のリスクがセーフティのハザードにつながるケースがある。 例えば、第三者による IoT コンポーネントへの不正侵入によりソフトウェアや データの改竄が行われた場合、それは IoT コンポーネントの誤動作を引き起こ す可能性がある。セーフティのハザードはセキュリティの脅威の観点でも検討 する必要がある。 図 4-20 ハザードにつながる脅威の分析 54 また、セキュリティの脅威への対策を検討するにあたっては、その対策の効 果だけでなく、それが本来機能に与える影響も考慮しなくてはならない。 対策例 ① セーフティとセキュリティの設計の見える化 設計を見える化するための手法の例として、以下がある。[文献番号] 上記のうち、GSN の表記法の例を以下に示す。 （セーフティとセキュリティの相互の影響の確認については、以下の③で記載。） 55 ② セーフティとセキュリティの相互の影響の確認 セキュリティ対策においては、守るべき機能（本来機能やセーフティ関連機 能）を特定し、脅威とリスクの分析を行う必要がある。以下に検討の例を示 す。 ・守るべき機能（要件）に対する脅威・リスク分析、セキュリティ対策検討、 効果及び守るべき機能への影響の分析・評価を行い、評価結果が不十分 であると判断される場合には再設計を行う。 ・守るべき機能の規模が大きい場合、セキュリティ対策の影響分析を漏れ なく行うことが複雑になる。この場合の影響分析手法の例として、DRBFM (Design Review Based on Failure Model) が挙げられるる。[文献番号] 56 知らない相手でも安全安心につなげら れる設計をする ポイント ・メーカが想定していないコンポーネントが接続されても、安全安心な連 携を可能とする設計を目指す。 解説 今後、IoT が普及するに従い、インテグレータやユーザによって開発時に想 定していないコンポーネントをつなげられるケースが想定される。この場合に も、相手と信頼性情報を交換し、可能な範囲で安全安心に連携する設計を検討 する。 つなげることに 興味あり 趣味で アプリ開発 製品出荷、 サービス提供 インテグレータ がつなげる 図 4-21 想定外のつながり 対策例 検討中。 先進ユーザ がつなげる 57 安全安心を実現する設計の評価・検証 を行う ポイント ・機器やシステムの安全安心について、つながる観点で評価を行う。 ・安全安心のための設計について、妥当性の評価や実効性の検証を行う。 解説 つながる機器やシステムにおいては、つながることにより想定しない動作や 脆弱性が生じる危険性があるため、安全安心に係る評価が必要である。また、 つながる世界での安全安心を実現する設計が妥当であるかの評価、実際の環境 において効果を発揮しうるかについての検証が必要である。 対策例 検討中。 ※セキュリティ評価認証に関するコラムを追加予定。 58 市場に出た後も守る設計を考える 自身がどのような状態かを把握し、記録 する ポイント ・自身の状態や他機器との通信状況を把握しログを記録する。 ・ログそのものが不正に消去・改竄されないよう管理する。 ・低機能な機器の場合には上位のコンポーネントを含めて対策を行う。 解説 様々な機器やサービスがつながった状態では、どこで何が発生しているかを 把握することは容易ではない。異常が発生した場合に検知したり・分析して原 因を明らかにしたり、対策を検討したりするためには、個々の IoT コンポーネ ントがログを残すことが望ましい。記録する内容としては、IoT コンポーネン ト自身の状態だけでなく他の機器との通信状況も考えられる。 また、IoT コンポーネントの中にはセンサーなど低機能のものもふくまれて おり、単独での大量のログの管理や、ログ暗号化 などの対策が難しい場合があ る。そのような機器については、それらを含む上位のコンポーネントで対策を 行う必要がある。 ・・・ アイド リング 他IoTが アクセス 認証ＯＫ 機能 作動 他IoTに 結果返信 アイド リング アイド リング 他ＩｏＴが アクセス 認証ＮＧ 他ＩｏＴが アクセス 認証ＮＧ IoT コンポー ログ ネント 図 4-22 IoT コンポーネントにおけるログ（動作履歴） ・・・ 59 対策例 ① ログの記録 ・各 IoT コンポーネントで動作を記録する。記録する内容の例 セキュリティ解析用：攻撃、ユーザ認証、データアクセス、構成管理情報更新、 アプリケーション実行、ログの起動・停止、通信、扉の開閉、チェックサム セーフティ解析用：故障情報（HW,SW） リライアビリティ解析用、結果情報、状態情報、動作環境情報（温度、湿度、 CPU 負荷、ネットワーク負荷、リソース使用量等）、ソフトウェアの更新 ・ログを保管するための資源は有限であるため、保管期限を策定する。 ・ログが有効なものとなるように関連するコンポーネント間で時刻の同期を行う[文 献番号]。 ・ログに記録するタイミングは機器別に設計するのではなくて IoT コンポーネント全 体で考慮する。 ・ログ情報の収集が IoT コンポーネントの保全のためであることをマニュアル等に 記載する。 ② ログの不正な消去、改ざんの防止 ・IoT コンポーネントにおいて、ログに対してアクセス権限の設定、暗号化を行う 方法がある。 ・IoT コンポーネントにおいて収集したログを定期的に上位コンポーネントに送信 する方法がある。 ・ログへの書き込みは追記のみ可能な仕組みを用意している例もある[文献番 号]。 ・IoT コンポーネントにおいて、ログに対してアクセス権限の設定、暗号化を行う 方法がある。 ・IoT コンポーネントにおいて収集したログを定期的に上位コンポーネントに送信 する方法がある。 ・ログへの書き込みは追記のみ可能な仕組みを用意している例もある[文献番 号]。 60 ③ IoT コンポーネントが低機能な場合の対策 ・IoT コンポーネントがアクセス権限を管理できない場合や、低容量でログを記録 できない場合は、上位コンポーネントが読み取ったデータをログとして記録する 仕組みが考えられる。 61 時間が経っても安全安心を維持する ポイント ・経年で生じるリスクに対し、遠隔アップデートで安全安心を維持する対策 を検討する。 ・アップデート中、アップデート後の不具合を回避する対策を検討する。 解説 長持ちさせる作り方（拡張性のある作り方、"future-proof”設計[文献番 号]）と環境に順応させる方法があるが、ここでは後者を対象とする。製品サー ビスの出荷後に欠陥が発見される場合や、経年によるセキュリティ機能の劣化 （危殆化）、新製品とつながらないなどの問題も発生しうる。IoT において は、ネットワークにつなげて利用されると経年で生じるリスクがより顕著にな る。コンポーネントの置き換えができないケースもあり、その場合はソフトウ ェアのアップデートが必要である。 一方で、アップデートにはリスクも伴う。アップデートにより、IoT コンポー ネントの動作に不具合が生じることや、アップデート中に IoT コンポーネント の性能の低下や多数の IoT コンポーネントの同時アップデート等によりネット ワーク帯域の不足により機能や安全性が低下するリスクがある。 なお、万一、経年劣化による深刻な故障の可能性により回収が必要になった場 合を考慮して、IoT コンポーネントの利用者の把握も必要となる。 危殆化 バグ発見 欠陥発見 出荷時 メーカによる 緊急回収 ５年後 図 4-23 経年で生じるリスク 10年後 新製品と つながらない 62 対策例 以下に対策の例を示す。 ① アップデート機能の搭載 IoT コンポーネントが自動、または手動によりアップデートできる機能を搭載 する。 アップデート機能をなりすましで利用されないように、アップデートファイルの 暗号化や署名を利用する方法が考えられる。 ② アップデート中、アップデート後の不具合の防止 アップデート中の性能低下やネットワーク帯域の不足により機能や安全性 への影響が予測される場合には、アップデート手順の設計を実施する方法 が考えられる。 自動アップデート後に動作しなくなった場合の自動バージョンダウン（特に自 動アップデートの場合）を可能とする方法が考えられる。 アップデート後に性能ダウンを防止するために、事前検証を確実に行うこと が考えられる。 アップデート時のウイルス混入を防止する。USB でアップデートする場合は USB のチェックを徹底する。通常ネットワークに接続していない機器はセキ ュリティ対策を実施されていない可能性が高いのでアップデートだけのため にネットワークに接続することは避けることが望ましい。 63 関係者と一緒に守る 最新の IoT リスクを把握し、情報共有す る ポイント ・急増しているつながるリスクの情報を収集・把握する。 ・把握した情報は、開発にフィードバック、運用組織やユーザに伝達する。 解説 POS を狙ったウイルスの事例が急増していたにも関わらず、対策が不十分で あったためセンターサーバに不正アクセス、POS 端末にウイルスを感染させら れ、顧客の決済情報が不正に収集されるというインシデントが発生した事例が ある（図 4-22）。また、OSS（Open Source Software）を用いたソフトウェア 開発時、脆弱性やバグに関する情報収集を十分に行っていないために、開発し たソフトウェアが脆弱性を持つ危険性がある。 同様にセーフティに関しても、市場に出ている機器やシステムが意図しない つなげ方・使い方をされ、その結果、事故が急増する可能性がある。 IoT 時代では、想定外な出来事が発生するリスクが高まっている。従って、 これらの問題に早急に対応するために、絶えず、継続的な情報収集、分析及び 共有が必要である。 ①スーパー向け冷蔵機器業者 のアカウントで不正アクセス インター ネット Ｃ＆Ｃ サーバ ②店舗のPOSに 専用マルウェア をインストール SUPER MARKET SUPER MARKET 店舗 店舗 １２３４５６７８９０ ④C&Cサーバ（仮想）を 設置、カード情報を収集 SUPER MARKET POS用マルウェアの 事例が急増していた にも関わらず内部の 対策が不十分 店舗 POS ○○ＣＡＲＤ 攻撃者 マルウェア ③POSの動作を 監視し、カード 情報を蓄積 出典：CCDS 生活機器の脅威事例集を基に作成 図 4-24 POS 端末に対する攻撃事例 64 対策例 IoT を意識して運用者が実施する主な対策例を以下に示す。 他社情報の把握・展開 最新の情報を常に把握（最新情報把握方法についてはコラム参照） 社内への影響調査、展開 自部門の担当領域以外にも影響する可能性あり。 調達先への確認 該当する IoT コンポーネント利用の有無など。 つながる他者のための自身の異常の情報提供 つながっている相手が明確なとき、リアルタイムに正確に伝える。 つながる他者が不明確なとき、事故情報・インシデント情報を該当 するサイトに提供する。（コラム参照） 自社の HP などで告知する。 ※CIRT と ISEC の違いが分かる解説コラムを追加予定。 ＜コラム＞一般的に実施される主な対策例 つながることを想定しなくても、管理者・開発者・運用者は下記の観点を持つこと。 運用体制の構築（組織により形態は選択する）：管理者 開発者が継続して業務に当たる。 担当専門組織を設置する。 管理責任者のみ設置し、実質の担当は外部リソース（有償）に委託 する。 運用の準備：管理者・運用者 運用管理範囲を明確化する。 情報収集元を選択する。 ユーザや外部機関から欠陥情報・脆弱性情報を受け取る窓口を設 置する。 情報展開のしくみを構築する。 運用にあたっての基本的な業務：運用者 セーフティ・セキュリティ情報の収集 運用者は開発者・開発元からコンポーネントリストを入手する （監視対象を明確にする）。 65 脆弱性情報提供サイトを利用し、インシデント事例を把握す る。 例：JPCERT コーディネーションセンター(JPCERT/CC) https://www.jpcert.or.jp/ 脆弱性対策情報ポータルサイト http://jvn.jp/ 脆弱性対策情報データベース http://jvndb.jvn.jp/ 脅威事例を把握する。 例：情報セキュリティ 10 大脅威 https://www.ipa.go.jp/security/vuln/10threats2015.html サイバー脅威アライアンス(Cyber Treat Alliance:CTA) http://www.cyberthreatalliance.org/ Black Hat（コンピュータセキュリティの国際的なカンファレン ス、攻撃事例や対策方法の研究事例を発表） https://www.blackhat.com/us-15/ ISAC(Information Sharing and Analysis Center)：インシデント、 脅威及び脆弱性に関する分野独自の情報共有・会員同士の 情報交換を行う組織の会員となり、分野独自の情報を把握す る。 例：金融 ISAC http://www.f-isac.jp/ Telecom-ISAC https://www.telecom-isac.jp/ マルウェア対策の情報を入手する。 例：マルウェア対策プロジェクト ACTIVE http://www.active.go.jp/ セーフティ・セキュリティ情報の収集（OSS 関連） OSS は採用時に提供元を事前調査し、サポートサービスを活 用する。 企業外の一般利用者が実施する対策 情報収集 製品事故情報・リコール情報 独立行政法人 製品評価技術基盤機構 http://www.nite.go.jp/jiko/jikojohou/index.html 各メーカサイトの情報、新聞 また、業務プロセスの品質を審査するための規格 BS 15000 や、IT サービスマネ ジメントの適切性を評価するための認証基準 ISO/IEC 20000 は ITIL（Information Technology Infrastructure Library）を取り込んでいるが、ITIL 自体は規格ではな 66 く、システム運用にかかわる業務全般を整理・体系化したものであるので、参考に されたい。 IT 運用のノウハウを体系化しガイドラインとしてまとめたもの 運用管理作業を解説した「サービスサポート」と運用管理計画の策定につ いて解説した「サービスデリバリ」に分かれる。 「サービスサポート」はさらに「インシデント管理」「問題管理」「変更管理」 「リリース管理」「構成管理」を一連の活動として解説。 67 各ライフサイクルの関係者と協力し、安全 安心を維持する ポイント ・開発者は運用・保守フェーズや廃棄フェーズで守ってもらいたいことを運 用者に的確に伝える。 解説 景況や嗜好などの影響により、メーカが想定した製品やシステムの寿命と実 態が乖離し、ユーザ（企業及び消費者）が、サポートを終了した製品やシステ ムを利用し続ける場合がある。また、廃棄時に設計時には想定しなかったリス クが生じる可能性もある。これらは企画・設計・開発時の対策だけでは対応が 難しいため、運用・保守・廃棄時の対策が必要となる。 組込みOSの関係で 家電のサポート期間は 7年とします 景気が悪いから 長く使いたい 使いやすいから 換えたくない つながってるから 換えるの難しい 家電メーカ 家電が組み込まれたIoT IoTユーザ 図 4-23 サポート期間を過ぎても使われる IoT コンポーネント 製品・サービスのライフサイクルは、例えば図 4-24 のように定義されるが、 IoT 時代では出荷後、ユーザが使用を開始してからも注意が必要である。 出荷 企画 開発 製品開発 図 4-24 製造 運用 保守 廃棄 出荷後 製品・サービスのライフサイクル ※ ライフサイクルの明確化と関係者と連携した対策の実施 製品やシステムのライフサイクルを整理し、各フェーズの想定期間や関係者 との関わりを明確にする。例えば、「企画・開発フェーズ」、「製造フェー ズ」、出荷後の「運用・保守フェーズ」、「廃棄（リサイクル）フェーズ」に 68 分け、各フェーズの期間と関係者を明確化する。その上で各自の役割分担や安 全安心対策を整理し、関係者と連携しながら対策を実施する。 対策例 IoT を意識して運用・保守フェーズのために、管理者・開発者・運用者は以 下の対策を考慮する。 サポート体制の構築：管理者 社内・社外の問合せ受付窓口 開発部門の対応担当組織 ソフトウェア更新時の検証担当組織 他社の問合せ受付窓口 遠隔地対応 情報資産管理手順 サポート内容 ID/パスワードの設定変更の周知 つなげて良い・悪い条件の伝達（警告） メンテナンス手順を第三者に公開しない 運用・保守時に取得した個人情報（ユーザ情報・ログ情報）の取り 扱いに注意する 運用維持 関係先（調達先含む）との関係性を明確にする。 IoT コンポーネントの監視 ネットワークの異常診断 サポート期間終了の予告及び通知 サポート期間終了もネットワークにつないだまま利用するとリスク が高いケースでは、技術的にネットワークへの接続制限を行う手 段を検討する。（監視、認証など） ＜参考＞一般的な運用・保守フェーズにおいて、以下の対策を行う。 運用体制の構築（組織により形態は選択する） 開発者が継続して業務に当たる。 管理責任者のみ設置し、実質の担当は外部リソース（有償）に委 託する。 製品・サービス内部のソフトウェア更新 出荷後に発見された欠陥や脆弱性への対策としてソフトウェア更 新を実施する。 69 ソフトウェア更新時の役割分担 発見時の窓口・仕分け・開発部門への連絡・ソフト修正。 内部確認、更新公開用確認・更新公開 ソフトウェア更新の通知 通知を目的としたユーザ登録の推奨 自動更新機能（設計時に搭載） 運用維持 定期点検 サポート期間終了の予告及び通知 製品やシステムのサポート期間終了をユーザに確実に予告及び 通知をする。 新聞・雑誌・自社 HP への掲載やユーザ登録されている住 所・個別メールによる文書の通知 機器やシステム上のメッセージ表示（設計時に表示機能搭 載） 廃棄（リサイクル）フェーズにおいて、開発側が運用者・利用者に対して以 下を伝える。 廃棄時のリスクを警告 運用中に製品・サービスに保管された個人データなどの機密デー タの消去の必要性を利用者に周知させ、消去を推奨する。 特にリサイクルする場合、Linux や Windows の「ごみ箱」を空にし たり、Linux の rm コマンド、fdisk コマンド、mkfs コマンド、 Windows(DOS)の del コマンドを用いても、データが完全消去され ないことを警告する。 個人情報の消去方法 運用中に製品・サービスに保管された機密データを消去する方法 を利用者に周知させる。 消去プログラムの搭載 マニュアル・仕様書などに説明記載 自社 HP で掲載、サービスセンターなどへの案内 データ破壊ツールの提供、回収システムの整備（有償によ る実施でも良い） 廃棄・リサイクル業者とのデータ消去の契約と消去証明の 入手 消去内容（項目）の明確化 70 ユーザにつながることによるリスクを知っ てもらう ポイント ・開発者は運用・保守フェーズや廃棄フェーズで守ってもらいたいことを運 用者に的確に伝える。 解説 通常の使用でも、個人宅でユーザが外出先から家庭のエアコンをオフにした ところ、想定外に家人が病気で寝ており、室温が上がって熱中症になる危険性 がある。 無線 LAN の暗号化設定をしておらず、第三者による不正利用の被害も既知の リスクではあるが注意が必要である。 通信アダプタ 外部サーバ インターネット ブロードバンド ルータ エアコン HEMSコントローラ 熱中症 暑い… 誤った温度設定 スマートフォン 全体システム（スマートハウス／HEMS） 図 4-25 つながることによるリスクの例 対策例 運用フェーズにおける対策例を以下に示す。 遠隔操作時の注意勧告表示（設計時に表示機能搭載） オープニング画面への記載。 マニュアルへの例示記載（開発者から、または運用者からユーザ への周知）。 自社 HP で掲載 71 必ずセキュリティ設定を行うようにユーザに喚起する。 無線 LAN（Wi-Fi など） 【注意喚起】家庭内における無線 LAN のセキュリティ設定の 確認を https://www.ipa.go.jp/security/topics/alert270612.html ユーザに以上を知らせる仕組みをいれる（設計時に機能搭載） 警告音、警告灯。 画面への表示。 72 第5章 今後必要となる対策技術例 本章では現時点では技術的に確立されていないが、今後必要になることが想 定される対策技術の例について記載する。 5 章全体は策定中 73 相手の品質を判定するしくみ 第 5 章でも述べたとおり、つながる世界では、出荷したコンポーネントやサ ービスを開始したシステムがサービス事業者やユーザによって手を加えられ、 メーカが思いもよらない使い方やつなげ方になることがある。また、異なる分 野のコンポーネントがつながるようになると、それぞれ品質に関する考え方 や、常識などがことなり、想定していた品質が担保できなくなるリスクがあ る。このようにリスクがある接続であるにもかかわらず、ユーザはそのことに 気づかないまま利用してしまうことになりかねない。本章では、モノ同士がつ ながる相手の品質を判定する仕組みについて提案する。 5.1.1 相手の品質判定の方針 意図しないつながり方 意図しないつながり方としては、ある時点のコンポーネントにメーカが意図 しない品質の低いコンポーネントをユーザが接続する場合や、自律的に動作す るコンポーネントが品質の低いコンポーネントとつながるケースあるいは異な る分野間で品質や常識の異なるコンポーネント間で接続されるケースが想定さ れる。 74 意図しないつながり方への対応方針 意図しないつながり方をした場合においてリスクを低減するために以下の３ つの対応を行えるようにする。 1. 安全安心に接続できるかを評価するための情報群を整備 2. 接続時の情報群の交換方法を整備 3. 接続時の接続可否・サービスの提供範囲の判断・通知の考え方を整備 5.1.2 判定に用いる情報群 情報群の整備 コンポーネントの接続時に確認できるものとしたい リライアビリティ、セーフティ、セキュリティに関する対応について交 換・確認できるものとしたい。また、特定の分野内だけでなく、異分野 間でも交換できるものとしたい。 セキュリティレベル（EAL、EDSA のレベル、等）、機能安全 （SIL、PL、等）はそれぞれ分野が異なると数値の意味が異なるた め、既存の指標はそのままでは交換はできない。 効率的に整備できるものとしたい。 従来の方法では、ある分野 A のコンポーネントに分野 B のコンポ ーネントが接続する場合、分野 B は分野 A の条件を満足させる （必要な認証を取得）必要がある。この方法だと分野 B で認証を 取得していているコンポーネントが分野 A でも認証のための作業 が必要となり、分野が増えるとその組み合わせの数だけ認証が必 要となってしまう。 IoT では安価な機器が多品種・多数接続されることが想定される ため、１つ１つの機器のための情報整備は効率化が必要。 機能安全適合性には第三者による「認証」、第二者による「確 認」、「自己宣言」があるので必ずしも「認証」によるものだけ でなく「自己宣言」も可能としたい 75 情報群の整備方針 「安全安心を実現するための相互に確認する情報群」を整備する。 情報群にはリライアビリティ、セーフティ、セキュリティを含む。保証 の定義、開発プロセス（設計・検証）、第三者認証(確認・自己宣言を 含む) 相互認証（分野間で認証されているものの交換パターンの取り決 め）を行う。これは、分野が増えるとその組み合わせの数だけ認 証が必要となってしまうので、より効率的にするためである。 情報には必須の情報とオプションの情報を含むことができる。 情報には独自の項目を追加することができる。 異常の波及の防止対策の実施状況 情報群の交換・判断・通知方法に関する方針（※通知箇所 は次回検討） 静的な方法と動的な方法 静的な交換は必要な要件とする。動的な交換については、実施できる分 野から取り組んでいただく方針とする。 まずは同じ分野で整備をすすめて異なる分野でも利用できるようにする 76 5.1.3 標準化動向 ２０１６年３月現在では、リライアビリティ、セーフティ、セキュリティに関 する総合的な指標は整備されていない。一部、C2C-CC における TAL（信用保証レ ベル）のように検討されている例はあるが、ほとんどの分野で取り組まれておら ず、共通的な指標は確認できていない。 77 つながった機器に迷惑をかけない制御 つなげる相手に迷惑をかけないようにするためには、それぞれのコンポーネン トが守るべきものを守る（被害者とならない工夫）だけでなく、コンポーネント の異常の波及防止（加害者とならない工夫）が必要となる。ここでは、コンポー ネントの異常の波及を防止するための対策を提案する。 5.2.1 波及防止の方針 波及防止すべき内容 波及防止すべき内容は、コンポーネントの異常をそのままにしておくとつなが っている他のコンポーネントにも影響があるものである。たとえば、コンポーネ ントが暴走しネットワークの負荷を上げてしまうケース、コンポーネントがマル ウェア感染しそれが他のコンポーネントにも伝播してしまうケース、データ破壊 /改竄による危険な動作の連鎖等が想定される。 波及防止の方針 波及防止の方針としては以下の２つがある。 当該コンポーネント内での防止（異常なデータを受けても誤動作しない、 異常なデータを他へ出さない） 当該コンポーネント以外による防止（監視システム・人など） 情報システムのように保護された環境に設置され、人手により常時監視される わけではなく、IoT などのコンポーネントでは以下のような課題がある。常時監 視されているわけではないので可能なケースでは当該コンポーネント内による 防止対策を実施すべきであるが、一方で当該コンポーネントだけで守りきれない ケースや低機能なコンポーネントの場合に防止対策を盛りこむことは困難であ ることが想定されるため、当該コンポーネント以外による防止が必要となる。 管理者が不在になりがち（人が介在しない。人と機器の場所が異なる。家 庭等では管理の専門家がいない） 場所が変更になる（管理できない場所への移動するリスクがある） 低機能なモノがつながる（当該コンポーネント自身で防止できない） 危険な（破壊行為や不正使用されやすい）場所に設置される（外に設置） 78 5.2.2 当該コンポーネントによる波及の防止 主に管理者が不在になりがちなケースや、コンポーネントが管理できない場所 へ移動することがあるケースケースでは当該コンポーネントに自身の波及防止 は必要な要件としたい。 異常の検出 対象：コンポーネント自身の異常 時期：即時、定期的 手法：送信時のチェック、定期的な自己診断 異常検出時の通知 対象：利用者、運用者 時期：即時、定期的 通知場所：当該機器のランプ等、管理者の携帯電話、つながっている他のコン ポーネント 異常検出時の遮断・停止 異常を検出することできた場合、自己で遮断・停止 異常からの回復処理 自己診断等により確認した後に組み込み 5.2.3 当該コンポーネント以外による波及の防止 主にコンポーネントが低機能な場合や危険な場所に設置されているケースで はコンポーネントが自身で防止できないので、下記に示す当該コンポーネント以 外による波及防止について必要な要件としたい。 異常の検出 対象：他のコンポーネント（監視対象） 時期：常時監視/定期監視 手法：遠隔管理等（次ページに現時点での標準化動向を示す） 79 異常検出時の通知 対象：利用者、運用者 時期：即時、定期的報告 通知場所：監視パネル 異常検出時の遮断・停止 ネットワークからの遮断 遠隔で停止 異常からの回復処理 診断などにより確認した後に組み込み 5.2.4 標準化動向 M2M デバイスに関する遠隔管理の標準として現時点では決定的な標準技術は なく、一部の業界で検討中。oneM2M では業界別で整備されている OMA、BBF への 対応を実施。 TS005 OMA デバイス管理技術の利用 TS006 BBF 管理技術の利用 その他の共通・汎用規格ではまだ明確になっていない。 80 付録．本書の活用方法 A1．チェックリスト 説明する文章を挿入予定。 A2．最低限実施すべき対策の洗い出し 説明する文章を挿入予定。 81 おわりに ・今後、本開発指針をアップデートしていく。国際 IoT 規格の策定状況のフォ ローアップ、IoT におけるデータの信頼性などについて取り込む。 説明する文章を挿入予定。
© Copyright 2024 ExpyDoc
