つながる世界のセーフティ & セキュリティ設計入門 で伝えたいこと ~ 実態調査から見えたこと そして開発指針へ ~ ET/IoT2016 ブースプレゼン 2016 年 11 月 18 日 独立行政法人情報処理推進機構 (IPA) 技術本部ソフトウェア高信頼化センター (SEC) 西尾桂子
2 目次 つながる世界のリスク セーフティ設計 セキュリティ設計のアンケート調査結果より つながる世界のセーフティ& セキュリティ設計入門 解説 設計入門発行後の取組み : 開発指針
3 目次 つながる世界のリスク セーフティ設計 セキュリティ設計のアンケート調査結果より つながる世界のセーフティ& セキュリティ設計入門 解説 設計入門発行後の取組み : 開発指針
つながる世界 (IoT) とは 様々な モノ がつながって新たな価値を創出していく世界 電力会社 蓄電池 コジェネ HEMS ネットワーク EV/HV 太陽光発電 スマートメータ 自動運転 HEMS 端末 省エネ制御家電 照明 車車間通信 ITS 路側機 AV ネットワーク 4K 8K コンテンツ ネットワーク家電 ホームサーバ ホームゲートウェイ 車載 ECU 医療 ヘルスケアネットワーク ロボット介護 後付車載器テレマティクス端末 データレコーダ等 医療 ヘルスケア機器 医療 ヘルスケアサーバ 持込機器 ITS& 自動車安全機能の連携 Newサービス生活圏の公共エリアのネットワーク機器出典 : 一般社団法人重要生活機器連携セキュリティ協議会 セキュアライフ2020 中の図に加筆 お弁当セール Convenience ウェラブル機器 ATM サービス提供サーバ ( クラウド ) 農地や工場 機器メーカ遠隔監視 制御 HEMS 関連企業 コンテンツ提供企業 医療機関 ヘルスケア企業 自動車メーカ 交通管制 4
接続先は信頼できる 信頼性に関する設計要件は自分が求めているものと合致しているか 例 通信や エンターテイメントに 利用する信頼性の 設計要件 接続しても 問題がないかの 確認が必要 スマートフォン 自動運転の車 設計要件が異なる際に想定されるリスク 車を制御 操作中のスマホのハングアップにより 制御 操作が効かなくなり 重大な事故が発生 脆弱性がある側の機器への不正アクセスにより 相手側の機器に保存されている情報が盗難 等 人の命を預かる 信頼性の設計要件 IoT時代の安全 と安心への危惧 つながる事を想定した安全 安心に向けた設計が重要に 2016 IPA Software Reliability Enhancement Center 5
接続先の信頼性をどう確認するのか IoT時代の安全 安心への危惧を払拭するには 製品やサービスをつなげるための開発を 行う際に互いの信頼性を確認することが重要 特にセーフティ設計 セキュリティ設計 セーフティ設計 セキュリティ設計 セーフティ セキュリティは 車の両輪 その把握のためには 双方の １ セーフティ セキュリティ設計の確実な実 施 ２ その設計実施状況の見える化 が必要不可欠に 2016 IPA Software Reliability Enhancement Center 6
7 目次 つながる世界のリスク セーフティ設計 セキュリティ設計のアンケート調査結果より つながる世界のセーフティ& セキュリティ設計入門 解説 設計入門発行後の取組み : 開発指針
8 セーフティ設計 セキュリティ設計に関する実態調査結果 セーフティ設計 セキュリティ設計に関する実態調査結果 ( 平成 27 年 9 月 10 日発行 ) 対象 : 自動車 スマートフォン ヘルスケア スマート家電の 4 分野 サンプル数 :320 社調査期間 :2015 年 2 月 ~4 月有効回答 :68 組織 セーフティ設計 セキュリティ設計 上流の段階でリスク分析を実施し リスクを低減した設計を行う 見える化 設計の品質をエビデンス ( 証拠 ) に基づき第三者でも容易に理解できる表記で論理的に説明する
セーフティ セキュリティ設計に関するアンケート結果から 経営層の関与が少ない 設計上の判断に 経営層や品質保証部門の 責任者が関わることはありますか セーフティ設計 セキュリティ 設計の必要性 セーフティ設 計は必要, 4.4% n=68 セキュリティ 設計は必要, 19.1% n=53 しかし セーフティ設計 その他, 13.2% 開発部の み, 34.0% 経営層, 9.4% n=57 セキュリティ設計 経営層 26.4% 経営層, 19.3% 開発部の み, 43.9% 経営層と 品質管理, 17.0% 両方とも必 要, 76.5% 設計は必要 100% 品質管理, 26.4% 経営層 29.8% その他, 7.0% 経営層と 品質管理, 10.5% 品質管理, 19.3% 出典 独立行政法人情報処理推進機構 セーフティ設計 セキュリティ設計に関する実態調査結果 平成27年9月10日 経営層が関与していると回答した組織は 開発部門のみで判断していると言う 回答に比べて少ない 事故やインシデントが発生すると 損害賠償や企業の信用失墜 リコールなど 経営リスクに発展 セーフティ設計 セキュリティ設計上の判断には 経営層の関与が必要 2016 IPA Software Reliability Enhancement Center 9
セーフティ セキュリティ設計に関するアンケート結果から 設計の基本方針が明文化されていない セーフティ設計の基本方針 明文化なし 64 セキュリティ設計の基本方針 明文化なし 54 セーフティ設 計に特化し た基本方針 あり, 10.5% n=57 セーフティ設 計を含む基 本方針あり, 24.6% 明文化され たものはな い, 64.9% 経営層関与 あり なし 設計ルール あり なし セーフティ基本方針 なし あり 16.2% 83.8% 40.0% 60.0% セーフティ基本方針 なし あり 27.0% 73.0% 94.7% 5.3% セキュリティ 設計に特化 した基本方 針あり, 15.8% n=57 明文化され たものはな い, 54.4% セキュリティ 設計を含む 基本方針あ り, 29.8% セキュリティ基本方針 なし あり 19.4% 80.6% 42.3% 57.7% 基本方針がないのに経営層の関与もなし セキュリティ基本方針 なし あり 9.7% 90.3% 92.0% 8.0% 基本方針がある組織はほとんど設計ルールあり 基本方針がない組織はほとんど設計ルールなし 半数以上の企業では基本方針が設けられていないが 経営層の関与もなく 開発現場の判断に任せられている 2016 IPA Software Reliability Enhancement Center 10
セーフティ セキュリティ設計に関するアンケート結果から現場で行っているセーフティ設計 11 Q: ハザード分析について 手法やツールを利用していますか?( 複数回答 ) N=55 0 10 20 30 FMEA (Failure Mode and Effect Analysis) 22 FTA (Fault Tree Analysis) 手法 20 セーフティ分析 3 大手法 HAZOP(Hazard and Operability Studies) 手法 10 STAMP/STPA 手法を利用 1 その他の手法やツール 3 独自の手法 8 ( 複数回答 N=50 ) ハザード分析は行っていない フェールセーフ手法を利用 フールプルーフ手法を利用 形式手法を利用 多層防御手法を利用 アフォーダンス手法を利用 その他の手法やツール 独自の手法 セーフティ設計は行っていない 0 10 20 30 40 2 4 5 7 8 11 12 17 19 19 ハザード分析をしていないプロダクトも多い Q: ハザードに対するセーフティ設計 評価について 手法やツールを利用していますか? フェールセーフ手法が 1 強 独自手法が多い セーフティ設計をしていないプロダクトも多い
セーフティ セキュリティ設計に関するアンケート結果から 現場で行っているセキュリティ設計 N=56 0 10 12 FMEA (Failure Mode and Effect Analysis 脅威モデリング手法(STRIDE, DFD) 9 9 FTA (Fault Tree Analysis)手法 HAZOP Hazard and Operability Studies 手法 ISO/IEC27005 (GMITS) 問題フレーム手法 ゴール指向 その他の手法やツール 析 ５大手法 N=56 1 1 独自手法が最多 9 独自の手法 リスク分析は行っていない Q セキュリティ上のリスク分析について 手法やツールを利用していますか 複数 セキュリティ分 回答 2 2 2 2 ミスユースケース手法を利用 ALE (Annual Loss Expectation 手法 30 7 7 Attack Tree手法 エージェント指向 (ｉ* Secure Tropos) 手法 20 19 13 リスク分析をしていな いプロダクトも多い Q リスクに対するセキュリティ設計 評価につ いて 手法やツールを利用していますか 複数回答 0 認証 暗号化 アクセス制御 電子署名 脆弱性評価 ログ 監査 UML 侵入検知 CC (ISO/IEC 15408) SDL (Secure Development Lifecycle) SIM/TPM等信頼を担保する手法 形式手法 FIPS-140 Twin Peaks手法 SQUARE その他の手法やツール 独自の手法 セキュリティ設計は行っていない 10 20 30 40 35 32 25 20 18 17 セキュリティ対 策は様々な手法 が使われている 12 11 6 4 3 3 2 1 セキュリティ設計をしていない 1 プロダクトは少ない 5 11 5 分析は行っていないが設計は行っている 手法やツールを利用することが通常の開発に組み込まれている その手法やツールが本当に有効か確認しているか 2016 IPA Software Reliability Enhancement Center 12
セーフティとセキュリティの設計の整合性 現状 セーフティ及びセキュリティの担当者間の連携は不十分 相互の信頼性確認の前提となるガイドブックの作成が必要! セーフティ設計とセキュリティ設計の取組みとハザード 脅威事例を含めて解説 担当者間で設計のすり合わせをするための 見える化 を解説 ハザード セーフティ設計 セキュリティ設計 脅威 設計のすりあわせ 13
14 目次 つながる世界のリスク セーフティ設計 セキュリティ設計のアンケート調査結果より つながる世界のセーフティ& セキュリティ設計入門 解説 設計入門発行後の取組み : 開発指針
本ガイドブックの構成と対象読者 2015年10月発行 現状と背景(1章) 事故事例(2章) 経営層にも 読んで頂き たい内容 ソフトウエア 開発者向けの 入門レベルの 内容 リスク対応した開発プロセス(3章) セーフティ設計(4章) SEC BOOKS 書籍 または SEC HPからPDF DL http://www.ipa.go.jp/sec/repo rts/20151007.html セキュリティ設計(5章) 設計品質の見える化(6章) 主な対象読者 セーフティ設計 セキュリティ設計 は 製品開 発の根幹に係り つながる世界では更に重要になる その重要性を認識してもらうために 本ガイドブック の読者は組込み系のソフトウェア技術者や 製品開発 の責任を担う経営層を主な対象とする 2016 IPA 製品開発責任者 経営層 リーダー 組み込み系の ソフトウェア技術者 実装責任者 Software Reliability Enhancement Center 15
16 ガイドブックの記載内容 今後の IoT 時代の製品開発において重要となる設計時の考慮事項を記載 的確なリスク対応 セーフティ設計 セキュリティ設計の重要性 見える化による設計情報共有の必要性とそれらへの経営層の関与のあり方 実際に発生した事故とインシデントの具体的事例 原因 およびその対策のヒント 実際に産業界で使われているリスク分析 脅威分析手法 およびその設計手法 事故 インシデント発生時に第三者への説明責任を果たすための設計品質の見える化手法
17 解説例 (1) 経営層の関与の必要性 セーフティ設計 セキュリティ設計の課題 表面上に見える製品 サービスの機能とは異なり 下支えする要件のため コストとリソースをかけにくい 開発現場の判断だけでは取り組みにくい 基本方針
解説例 (2) 安全安心を実現する設計の整合性をとる セキュリティ上の脅威がセーフティを阻害するハザード要因に セキュリティ上の脅威 機器やシステム 引き金 攻撃 脆弱性 侵害 インシデント 赤線は対策のポイント 誤設定など ハザード セキュリティ上の脅威はセーフティにも影響 事故 セーフティのハザード要因 欠陥 故障など 引き金 出典 :SESAMOプロジェクト SECURITY AND SAFETY MODELLING FOR EMBEDDED SYSTEMS を基に作成 18
19 解説例 (3) 設計の見える化の必要性 3 2 製品 A 説明 サービス部門など 共有 事故 連携のための共有 製品 B 説明 事故 サービス部門など 共有 トレーサビリティ 説明責任 ステークホルダーとの設計情報共有 1 理解 理解 理解 ソフトウェア設計や再利用時の設計内容の理解
20 解説例 (4) セーフティ & セキュリティ機能を実現するために 上流の段階でリスク分析を実施し リスクを低減した設計を行う Tw in Peaks モデル 分析 詳細化 セーフティとセキュリティのコンセプト 要件定義 システム設計 V 字開発モデル 運用テスト システムテスト 要件 アーキテクチャー 要件とアーキテクチャを セーフティ / セキュリティ分析を繰り返して詳細化する
21 目次 つながる世界のリスク セーフティ設計 セキュリティ設計のアンケート調査結果より つながる世界のセーフティ& セキュリティ設計入門 解説 設計入門発行後の取組み : 開発指針
22 IoT の安全安心対策の課題 IoT の構造 ( アーキテクチャ ): 接続 / 分離 拡大 / 縮小 新旧混在 新しいつながりや移動先でのつながりなど 日々変化 ある日の IoT 次の日の IoT 構成変化 IoT のアーキテクチャに依存しない守り方が必要 開発者に最低限検討して欲しい事項を 開発指針 としてまとめ
開発指針一覧 ( 詳細はパネル前で ) IoT 機器 / システムの開発者が安全安心の確保のために最低限検討して欲しい事項を 開発ライフサイクルに沿って 17 の指針として整理 つながる世界の開発指針 の内容 目次 : 第一章つながる世界と開発指針の目的第二章開発指針の対象第三章つながる世界のリスク想定第四章つながる世界の開発指針 (17 指針 ) 第五章今後必要となる対策技術例 各指針毎にポイント 解説 対策例を記載 方針 分析 設計 保守 運用 大項目 つながる世界の安全安心に企業として取り組む つながる世界のリスクを認識する 守るべきものを守る設計を考える 市場に出た後も守る設計を考える 関係者と一緒に守る 指針 指針 1 安全安心の基本方針を策定する 指針 2 安全安心のための体制 人材を見直す 指針 3 内部不正やミスに備える 指針 4 守るべきものを特定する 指針 5 つながることによるリスクを想定する 指針 6 つながりで波及するリスクを想定する 指針 7 物理的なリスクを認識する 指針 8 個々でも全体でも守れる設計をする 指針 9 つながる相手に迷惑をかけない設計をする 指針 10 安全安心を実現する設計の整合性をとる 指針 11 不特定の相手とつなげられても安全安心を確保できる設計をする 指針 12 安全安心を実現する設計の検証 評価を行う 指針 13 自身がどのような状態かを把握し 記録する機能を設ける 指針 14 時間が経っても安全安心を維持する機能を設ける 指針 15 出荷後も IoT リスクを把握し 情報発信する 指針 16 出荷後の関係事業者に守ってもらいたいことを伝える 指針 17 つながることによるリスクを一般利用者に知ってもらう http://www.ipa.go.jp/sec/reports/20160511_2.html 23
24 開発企業における開発指針の使い方 開発指針 開発指針の利活用方針 各指針のポイントは必ず検討すべき内容 対策の実施は当事者の判断とする 実施する場合は各指針の対策例が参考となる 開発指針の利活用方法 IoT 製品やシステムの開発時のチェックリストとして利用する 指針で記述している事項は 検討時に企業や団体 業界の実情に合わせてカスタマイズして利用する 内部での開発のみならず受発注の要件確認にも活用する チェック結果を取組みのエビデンスと して活用する
25 ご清聴ありがとうございました