つながる世界のセーフティ & セキュリティ設計入門 で伝えたいこと ~ 実態調査から見えたこと そして開発指針へ ~ ET/IoT2016 ブースプレゼン 2016 年 11 月 18 日 独立行政法人情報処理推進機構 (IPA) 技術本部ソフトウェア高信頼化センター (SEC) 西尾桂子 2016

ET/IoT2016 ブースプレゼン

2016年11月18日

独立行政法人情報処理推進機構（ＩＰＡ）

技術本部 ソフトウェア高信頼化センター（ＳＥＣ）

西尾 桂子

「つながる世界のセーフティ＆セキュリティ設計入門」

で伝えたいこと

～実態調査から見えたこと、そして開発指針へ～

目次

 つながる世界のリスク

 セーフティ設計・セキュリティ設計のアンケート調査結果より

 「つながる世界のセーフティ＆セキュリティ設計入門」解説

 設計入門発行後の取組み：「開発指針」

目次

 つながる世界のリスク

 セーフティ設計・セキュリティ設計のアンケート調査結果より

 「つながる世界のセーフティ＆セキュリティ設計入門」解説

 設計入門発行後の取組み：「開発指針」

つながる世界

（IoT）とは



様々な「モノ」がつながって

新たな価値を創出

していく世界

AVネットワーク 医療・ヘルスケアネットワーク 蓄電池・ コジェネ HEMSネットワーク 電力会社 省エネ制御 家電・照明 EV/HV 太陽光発電 HEMS 端末 医療・ヘルスケア 機器 ウェラブル 機器 医療・ ヘルスケア サーバ ロボット介護 テレマティクス端末、 データレコーダ等 ITS＆自動車安全機能の連携 Newサービス 後付 車載器 車車間通信 持込機器 ITS路側機 自動運転 車載 ECU ４K・８K コンテンツ ホーム サーバ ネットワーク 家電 HEMS 関連企業 コンテンツ 提供企業 医療機関・ ヘルスケア企業 サービス提供サーバ （クラウド） 自動車メーカ ・交通管制 Convenience お 弁 当 セ ー ル 生活圏の公共エリア のネットワーク機器 ATM _{遠隔監視・制御}機器メーカ 農地や工場 スマートメータ ホームゲートウェイ

接続先は信頼できる？

（信頼性に関する設計要件は自分が求めているものと合致しているか？）

設計要件が異なる際に想定されるリスク

• 車を制御・操作中のスマホのハングアップにより、

制御・操作が効かなくなり、重大な事故が発生

• 脆弱性がある側の機器への不正アクセスにより、

相手側の機器に保存されている情報が盗難

自動運転の車 スマートフォン _{人の命を預かる} 信頼性の設計要件 通信や エンターテイメントに 利用する信頼性の 設計要件

接続しても

問題がないかの

確認が必要

IoT時代の安全

と安心への危惧

等

つながる事を想定した安全・安心に向けた設計が重要に！

例）

接続先の信頼性をどう確認するのか？

（１）セーフティ・セキュリティ設計の確実な実

施

【IoT時代の安全・安心への危惧を払拭するには】

製品やサービスをつなげるための開発を

行う際に互いの信頼性を確認することが重要

セーフティ設計 セキュリティ設計 セーフティ、セキュリティは 車の両輪

その把握のためには、双方の

（２）その設計実施状況の見える化

が必要不可欠に

特にセーフティ設計・セキュリティ設計

目次

 つながる世界のリスク

 セーフティ設計・セキュリティ設計のアンケート調査結果より

 「つながる世界のセーフティ＆セキュリティ設計入門」解説

 設計入門発行後の取組み：「開発指針」

セーフティ設計・セキュリティ設計に関する実態調査結果

「セーフティ設計・セキュリティ設計に関する実態調査結果」

（平成27年9月10日発行）



対象：自動車、スマートフォン、ヘルスケア、スマート家電の4分野



サンプル数：３２０社 調査期間：２０１５年２月～４月 有効回答：68組織

◆

「セーフティ設計」「セキュリティ設計」

上流の段階でリスク分析を実施し、

リスクを低減した設計を行う

◆

「見える化」

設計の品質をエビデンス（証拠）に基づき

第三者でも容易に理解できる表記で論理的

に説明する

その他, 7.0% 経営層, 19.3% 経営層と 品質管理, 10.5% 品質管理, 19.3% 開発部の み, 43.9% n=57 その他, 13.2% 経営層, 9.4% 経営層と 品質管理, 17.0% 品質管理, 26.4% 開発部の み, 34.0% n=53 セーフティ設 計は必要, 4.4% セキュリティ 設計は必要, 19.1% 両方とも必 要, 76.5% n=68

セーフティ・セキュリティ設計に関するアンケート結果から

経営層の関与が少ない

設計上の判断に、経営層や品質保証部門の 責任者が関わることはありますか？

経営層が関与していると回答した組織は、開発部門のみで判断していると言う

回答に比べて少ない

経営層 26.4% 経営層 29.8%

事故やインシデントが発生すると、損害賠償や企業の信用失墜・リコールなど、

経営リスクに発展

セーフティ設計 セキュリティ設計

セーフティ設計・セキュリティ設計上の判断には、

経営層の関与が必要

出典：独立行政法人情報処理推進機構「セーフティ設計・セキュリティ設計に関する実態調査結果」（平成27年9月10日） セーフティ設計・セキュリティ 設計の必要性 しかし 設計は必要 100%

セーフティ・セキュリティ設計に関するアンケート結果から

設計の基本方針が明文化されていない

セキュリティ 設計に特化 した基本方 針あり, 15.8% セキュリティ 設計を含む 基本方針あ り, 29.8% 明文化され たものはな い, 54.4% n=57 セーフティ設 計に特化し た基本方針 あり, 10.5% セーフティ設 計を含む基 本方針あり, 24.6% 明文化され たものはな い, 64.9% n=57 セーフティ設計の基本方針（明文化なし：64％） セキュリティ設計の基本方針（明文化なし：54％） 基本方針がないのに経営層の関与もなし 基本方針がある組織はほとんど設計ルールあり 基本方針がない組織はほとんど設計ルールなし なし あり なし あり あり 16.2% 40.0% 19.4% 42.3% なし 83.8% 60.0% 80.6% 57.7% セーフティ基本方針 セキュリティ基本方針 経営層関与 なし あり なし あり あり 27.0% 94.7% 9.7% 92.0% なし 73.0% 5.3% 90.3% 8.0% 設計ルール セーフティ基本方針 セキュリティ基本方針

半数以上の企業では基本方針が設けられていないが、

経営層の関与もなく、開発現場の判断に任せられている

セーフティ・セキュリティ設計に関するアンケート結果から

現場で行っているセーフティ設計

11

22 20 10 1 3 8 19 0 10 20 30

FMEA (Failure Mode and Effect Analysis） FTA (Fault Tree Analysis)手法 HAZOP（Hazard and Operability Studies）手法 STAMP/STPA手法を利用 その他の手法やツール 独自の手法 ハザード分析は行っていない N=55 Q：ハザード分析について、手法やツールを利用していますか？（複数回答） セーフティ分析 ３大手法 ハザード分析をしてい ないプロダクトも多い 19 8 7 5 2 4 17 12 0 10 20 30 40 フェールセーフ手法を利用 フールプルーフ手法を利用 形式手法を利用 多層防御手法を利用 アフォーダンス手法を利用 その他の手法やツール 独自の手法 セーフティ設計は行っていない N=50 Q:ハザードに対するセーフティ設計・評価について、手法やツールを利用していますか？ （複数回答） フェールセーフ手法が１強 独自手法が多い セーフティ設計をしてい ないプロダクトも多い

12 9 9 7 7 2 2 2 2 1 1 9 19 13 0 10 20 30

FMEA (Failure Mode and Effect Analysis） 脅威モデリング手法(STRIDE, DFD) FTA (Fault Tree Analysis)手法 Attack Tree手法 HAZOP（Hazard and Operability Studies）手法 ISO/IEC27005 (GMITS) ミスユースケース手法を利用 問題フレーム手法 ゴール指向 エージェント指向 (ｉ*／Secure Tropos) 手法 ALE (Annual Loss Expectation）手法 その他の手法やツール 独自の手法 リスク分析は行っていない N=56 35 32 25 20 18 17 12 11 6 4 3 3 2 1 1 5 11 5 0 10 20 30 40 認証 暗号化 アクセス制御 電子署名 脆弱性評価 ログ・監査 UML 侵入検知 CC (ISO/IEC 15408) SDL (Secure Development Lifecycle) SIM/TPM等信頼を担保する手法 形式手法 FIPS-140 Twin Peaks手法 SQUARE その他の手法やツール 独自の手法 セキュリティ設計は行っていない N=56 Q：セキュリティ上のリスク分析について、 手法やツールを利用していますか？（複数 回答）セキュリティ分 析 ５大手法 独自手法が最多 Q：リスクに対するセキュリティ設計・評価につ いて、手法やツールを利用していますか？ （複数回答） セキュリティ対 策は様々な手法 が使われている リスク分析をしていな いプロダクトも多い セキュリティ設計をしていない プロダクトは少ない

分析は行っていないが設計は行っている

→手法やツールを利用することが通常の開発に組み込まれている？

→その手法やツールが本当に有効か確認しているか？

セーフティ・セキュリティ設計に関するアンケート結果から

現場で行っているセキュリティ設計

セーフティとセキュリティの設計の

整合性



現状、セーフティ及びセキュリティの担当者間の連携は不十分



相互の信頼性確認の前提となる

ガイドブック

の作成が必要！



セーフティ設計とセキュリティ設計の取組みとハザード・

脅威事例を含めて解説



担当者間で設計のすり合わせをするための「見える化」を

解説

脅

威

セキュリティ

設計

ハ

ザ

ー

ド

セーフティ

設計

設計のすりあわせ

目次

 つながる世界のリスク

 セーフティ設計・セキュリティ設計のアンケート調査結果より

 「つながる世界のセーフティ＆セキュリティ設計入門」解説

本ガイドブックの構成と対象読者

現状と背景(1章) 事故事例(2章) リスク対応した開発プロセス(3章) セーフティ設計(4章) セキュリティ設計(5章) 設計品質の見える化(6章) 経営層にも 読んで頂き たい内容 ソフトウエア 開発者向けの 入門レベルの 内容

2015年10月発行

SEC BOOKS 書籍 または SEC HPからPDF DL http://www.ipa.go.jp/sec/repo rts/20151007.html

主な対象読者

リーダー 組み込み系の ソフトウェア技術者

「セーフティ設計・セキュリティ設計」は、製品開

発の根幹に係り、つながる世界では更に重要になる。

その重要性を認識してもらうために、本ガイドブック

の読者は

組込み系のソフトウェア技術者

や、製品開発

の責任を担う

経営層

を主な対象とする。

← 製品開発責任者 （経営層） ←実装責任者

ガイドブックの記載内容

今後のIoT時代の製品開発において重要となる

設計時の考慮

事項

を記載



的確なリスク対応、

セーフティ設計・セキュリティ設計の重要

性、見える化

による設計情報共有の必要性とそれらへの

経

営層の関与

のあり方



実際に発生した事故とインシデントの具体的事例、原因、およびその対策の

ヒント



実際に産業界で使われているリスク分析・脅威分析手法、およびその設計手

法



事故・インシデント発生時に第三者への説明責任を果たすための設計品質

の見える化手法

解説例（１） 経営層の関与の必要性

【セーフティ設計・セキュリティ設計の課題】

表面上に見える製品・サービスの機能とは異なり、下支えする要件のため、コストとリソースをかけにくい。

→開発現場の判断だけでは取り組みにくい。

解説例（２） 安全安心を実現する設計の

整合性

をとる

セキュリティ上の脅威がセーフティを阻害する

ハザード要因

に

誤設定 など ハザード 事故 引き金 脆弱性 攻撃

機器やシステム

侵害 欠陥、 故障など セキュリティ上の脅威 セーフティの ハザード要因

セキュリティ上の脅威はセーフティにも

影響

赤線は対策のポイント インシ デント 引き金

解説例（３） 設計の見える化の必要性

トレーサビリティ、説明責任

ステークホルダーとの設計情

報共有

ソフトウェア設計や再利用時

の設計内容の理解

1

2

3

サービス部門 など 事故 製品Ａ 共 有 説 明 理解 事故 共 有 説 明 理解 製品Ｂ 連携のための 共有 理解 サービス部門 など

解説例（４） セーフティ＆セキュリティ機能を実現するために

要件とアーキテクチャを、セーフティ／セ

キュリティ分析を繰り返して詳細化する

要件定義 システム設計 V字開発モデル セーフティとセキュ リティのコンセプト 運用テスト システムテスト 要件 アーキテクチャー

分

析

・

詳

細

化

Tw in Peaksモデル

上流の段階でリスク分析を実施し、リスクを低減した設計を行う

目次

 つながる世界のリスク

 セーフティ設計・セキュリティ設計のアンケート調査結果より

 「つながる世界のセーフティ＆セキュリティ設計入門」解説

IoTの安全安心対策の

課題



IoTの構造（アーキテクチャ）：接続/分離、拡大/縮小、新旧混在



新しいつながりや移動先でのつながりなど、日々変化



IoTのアーキテクチャに依存しない守り方

が必要

構

成

変

化

ある日のIoT

_{次の日のIoT}

開発者に最低限検討して欲しい事項を「開発指針」としてまとめ

開発指針

一覧

（詳細はパネル前で）

「つながる世界の開発指針」の内容

目次： 第一章 つながる世界と開発指針の目的 第二章 開発指針の対象 第三章 つながる世界のリスク想定 第四章 つながる世界の開発指針（17指針） 第五章 今後必要となる対策技術例 ※各指針毎にポイント・解説・対策例を記載 http://www.ipa.go.jp/sec/reports/20160511_2.html

IoT機器/システ

ムの開発者が安

全安心の確保の

ために最低限検

討して欲しい事

項を、開発ライ

フサイクルに

沿って17の指

針として整理。

大項目 指針 方 針 つながる世界の安全 安心に企業として取 り組む 指針1 安全安心の基本方針を策定する 指針2 安全安心のための体制・人材を見直す 指針3 内部不正やミスに備える 分 析 つながる世界のリス クを認識する 指針4 守るべきものを特定する 指針5 つながることによるリスクを想定する 指針6 つながりで波及するリスクを想定する 指針7 物理的なリスクを認識する 設 計 守るべきものを守る 設計を考える 指針8 個々でも全体でも守れる設計をする 指針9 つながる相手に迷惑をかけない設計をする 指針10 安全安心を実現する設計の整合性をとる 指針11 不特定の相手とつなげられても安全安心を確保できる 設計をする 指針12 安全安心を実現する設計の検証・評価を行う 保 守 市場に出た後も守る 設計を考える 指針13 自身がどのような状態かを把握し、記録する機能を設 ける 指針14 時間が経っても安全安心を維持する機能を設ける 運 用 関係者と一緒に守る 指針15 出荷後もIoTリスクを把握し、情報発信する 指針16 出荷後の関係事業者に守ってもらいたいことを伝える 指針17 つながることによるリスクを一般利用者に知ってもら う

開発企業における開発指針の使い方

各指針のポイントは必ず検討すべき内容 開発指針 対策の実施は当事者の判断とする。実施 する場合は各指針の対策例が参考となる ・IoT製品やシステムの開発時のチェック リストとして利用する。 ・指針で記述している事項は、検討時に 企業や団体、業界の実情に合わせてカ スタマイズして利用する。 ・内部での開発のみならず受発注の要件 確認にも活用する。 ・チェック結果を取組みのエビデンスと して活用する。

 開発指針の利活用方針

 開発指針の利活用方法