セーフティ設計・セキュリティ設計に関するガイドブック紹介 ·...

Software Reliability Enhancement CenterCopyright © 2016 IPA, All Rights Reserved 1

2016年３月23日

独立行政法人情報処理推進機構（IPA)

技術本部ソフトウェア高信頼化センター（SEC)

研究員西尾桂子

セーフティ設計・セキュリティ設計に関するガイドブック紹介

2Copyright © 2016 IPA, All Rights Reserved Software Reliability Enhancement Center

本日お話する内容

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

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

IPA/SECの今後の取組み


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


IPA/SECが想定するリスク（接続先は信頼できる？）

自動運転の車スマートフォン人の命を預かる信頼性の設計要件

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

• 持ち主以外からの接続による車の盗難

• 車を制御・操作中のスマホのハングアップにより、制御・操作が効かなくなり、重大な事故が発生

• 脆弱性がある側の製品や機器への不正アクセスにより、相手側の製品や機器に保存されている情報が盗難

通信やエンターテイメントに利用する信頼性の

設計要件

接続しても問題がないかの確認が必要

IoT時代の安全と安心への危惧

等


IPA/SECが想定するリスク（接続先の信頼性の確認）

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

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

セーフティ設計

セキュリティ設計

セーフティ、セキュリティは

車の両輪

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

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

が必要不可欠に

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


実態調査の目的と内容

調査目的製品・サービスの接続先の信頼性を確認する仕組みを実現するときに、特に重要となるセーフティ設計・セキュリティ設計の実施と設計実施状況（設計品質）の見える化が、現在どの程度実施されているか取組み状況を把握し、作成予定のガイドブックに反映する。

調査内容セーフティ設計・セキュリティ設計の実施状況把握実際に使われているセーフティ設計・セキュリティ設計手

法の把握実際に使われている設計品質の見える化手法の把握


「セーフティ設計」「セキュリティ設計」「見える化」

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

◆設計の品質をエビデンス（証拠）に基づき第三者でも容易に理解できる表記で論理的に説明する


セーフティ設計・セキュリティ設計に関する実態調査結果（平成27年9月10日公開）

http://www.ipa.go.jp/sec/reports/20150910.html

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

サンプル数：320社有効回答：68組織回収率：21.3%

調査期間：２０１５年２月～４月

28

10

10

11

9

0 5 10 15 20 25 30

自動車

スマートフォン

ヘルスケア

スマート家電

その他

N=68

37

31

21

14

8

0 10 20 30 40

機器本体

アプリケーション

その他

クラウド上のソフトウェア

ゲートウェイ機器

N=66

分野別有効回答数

開発している製品・ソフトウェア（複数回答）

通信制御・ユーザーインターフェースAPI、マイコンドライバー、ミドルウェアなど、セキュリティ部分（但し、コピー防止、改変防止等）、FA機器、計測・測定装置、自社製品の組込みシステム開発～製造 (上記選択肢分野含む )、通信インフラ制御(基地局、Node、サーバー系)、無線/通信機器、制御盤


「セーフティ設計」「セキュリティ設計」の必要性

Q：セーフティ設計またはセキュリティ設計の必要性はお感じですか？

分野別

分野別と言うより回答者の業務によって比重が異なる回答になった

設計は必要 100％52

13

3

0

0 10 20 30 40 50 60

両方とも必要

セキュリティ設計は必要

セーフティ設計は必要

両方とも不要

N=68

3

0

0

0

0

3

2

4

3

1

22

8

7

7

8

0 5 10 15 20 25 30

自動車

ヘルスケア

スマート家電


その他

セーフティ設計は必要セキュリティ設計は必要両方とも必要両方とも不要N=68


36

29

29

15

5

2

1

0 10 20 30 40 50 60

ユーザの命や身体の安全を守るもの

ユーザの財産や利用環境を守るもの

発注者から「セーフティ」として与えられた要件

製品や開発案件ごとに異なる

関連法令や基準の安全に関わる事項

特に「セーフティ」は考えていない

その他

N=58N=58

製品のセーフティとは

Q：あなたのご担当部門でいう「製品のセーフティ」には、何が含まれますか？（複数回答）

最初の2つの選択肢に着目した分野別回答

10

1

1

1

4

1

1

4

3

1

9

3

4

1

2

0 5 10 15 20 25

自動車

ヘルスケア

スマート家電


その他

ユーザの命や身体の安全を守るものユーザの財産や利用環境を守るもの

両方

N=65

自動車はほとんど命や身体の安全スマート家電・スマートフォンは財産や利用環境


製品のセキュリティとは

Q：あなたのご担当部門でいう「製品のセキュリティ」には、何が含まれますか？（複数回答）

50

40

36

31

24

16

2

1

0 10 20 30 40 50 60

ソフトウェア・情報の機密性

ソフトウェア・情報の完全性

正当なユーザだけがいつでも利用できる状態

発注者から与えられたセキュリティ要件

製品や開発案件ごとに異なる

関連法令や基準のセキュリティに関わる事項

その他

特に「セキュリティ」は考えていない

N=59

「ソフトウェア・情報の機密性」は、回答者の86％が選択上位3つは情報セキュリティの3大基本理念であるCIA（機密性、完全性、可用性）


経営層の関与状況

その他, 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

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

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

経営層26.4%

経営層29.8%

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

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

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

経営層の関与が必要であることを解説

Q:セーフティ設計・セキュリティ設計の必要性

しかし

設計は必要100%


設計の基本方針の明文化

セキュリティ

設計に特化

した基本方

針あり,

15.8%

セキュリティ

設計を含む

基本方針あ

り, 29.8%

明文化され

たものはな

い, 54.4%

n=57セーフティ設

計に特化し

た基本方針

あり, 10.5%

セーフティ設

計を含む基

本方針あり, 24.6%

明文化され

たものはな

い, 64.9%

n=57

Q:セーフティ設計の基本方針がありますか？ Q:セキュリティ設計の基本方針がありますか？

基本方針がないのに経営層の関与もなし

基本方針がある組織はほとんど設計ルールあり基本方針がない組織はほとんど設計ルールなし

なしありなしあり

あり 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%

設計ルール

セーフティ基本方針セキュリティ基本方針

明文化なし65%

明文化なし54%


設計ルールの代わり

Q：セーフティ設計ルールの代わりになるものはありますか？

Q：セキュリティ設計ルールの代わりになるものはありますか？

14

9

3

2

0 5 10 15 20

リーダーなどの判断に任されている

その他

セーフティ設計ルールは必要ない

社内に暗黙の設計ルールや習慣がある

N=28

20

6

4

0

0 5 10 15 20 25

リーダーなどの判断に任されている

その他

社内に暗黙の設計ルールや習慣がある

セーフティ設計ルールは必要ない

N=30

半数以上の企業では基本方針が設けられていないが、経営層の関与もなく、開発現場の判断に任せられている


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


ガイドブックの記載内容

今後のIoT時代の製品開発において重要となるセーフティ設計・セキュリティ設計時の考慮事項を記載

ハザード分析・脅威分析から始めるセーフティ設計・セキュリティ設計の重要性、見える化による設計情報共有の必要性とそれらへの経営層の関与のあり方の解説

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

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

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


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

【セーフティ設計・セキュリティ設計の課題】表面上に見える製品・サービスの機能とは異なり、下支えする要件のため、コストとリソースをかけにくい。→開発現場の判断だけでは取り組みにくい。

基本方針


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

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

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

ソフトウェア設計や再利用時の設計内容の理解1

2

3

サービス部門など

事故

製品Ａ

共有

説明

理解

事故

共有

説明

理解

製品Ｂ

連携のための共有

理解

サービス部門など


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

要件定義

システム設計

V字開発モデルセーフティとセキュリティのコンセプト

運用テスト

システムテスト

要件アーキテクチャー

分析・詳細化

Twin Peaksモデル

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

要件とアーキテクチャを、セーフティ／セキュリティ分析を繰り返して詳細化する


解説例（４）分析手法・設計手法

セーフティ設計・セキュリティ設計に有効な手法の紹介

手法手法の概要

リスクマトリックス事故の発生頻度と被害の大きさから2軸の表形式でリスクの程度を分類する

リスクグラフ頻度、過酷度、止めやすさなど複数要素の有無を順に判断して、リスクのレベルを分類する

FTA 事故など望ましくない事象を起点に、その発生原因を体系的に整理する

FMEA 部品の故障を起点に、システムへの影響を体系的に検討する

HAZOP 利用手順に連想しやすいガイドワードをあてはめながら、システムのハザードを想定する

STAMP/STPA システム間の制御ごとにガイドワードを適用して、複雑なシステムでの相互作⽤のハザードを特定する

技術名概要対応する脅威例

耐タンパー性

機器に格納されたソフトウェアや暗号鍵データを解析されないように、こじ開けられると自動的にメモリを消去したり、漏えい電磁波や電力消費量の測定による解析を防ぐ特殊な回路を追加することで、攻撃耐性を高める

機器に格納されたソフトウェアを読みだされ、コピー製品を作られることを防ぐ

暗号化機器に格納したデータや機器間で送受信するデータを暗号化し、不正に読みだされたり盗聴された場合でも情報漏えいを防ぐ

生活機器で測定した個人のデータが送信中に盗聴され、プライバシーが侵害されることを防ぐ

認証正規のユーザ、サーバ、機器などの真正性を確認することで、なりすましによる不正利用や機器・部品の不正な入れ替えを防ぐ

所有者でない者が勝手に機器を利用することを防ぐ

アクセス制御

認証されたユーザの権限の範囲で、機器やシステムの利用を認可する

子供が親の許可なしで有料サービスを利用しないよう、ペアレンタル機能で制限する

電子署名ソフトウェア更新用ファイルなど重要なデータに電子的な署名を付与することで、ファイルの真正性や完全性（改ざんされていないこと）を確保する

偽のソフトウェア更新ファイルの送りつけによるウイルス感染を防ぐ

侵入検知機器やシステムへの不正な侵入、実行中のメモリまたはソフトウェアの改ざんなどをリアルタイムで検知する

ネットワーク経由で機器に不正アクセスされた場合、即時に検知して遮断する

ログ・監査機器やシステムへのアクセス記録を蓄積・分析し、攻撃回数の統計を作成したり、万一侵入された場合の被害や攻撃元を明らかにする

不正アクセスのログを分析し、攻撃元や攻撃が成功した原因を特定し、対策する


解説例（５）問題発生時の設計品質の説明、共有

アシュアランスケースの表記法解説

表記法特徴 CAE GSN D-Case

正式名称 Claim, Argument, Evidence

Goal Structuring Notation Dependability Case

登場時期 1998年 2011年 2012年

構成要素 3種類(主張、議論、証拠)

6種類(表 6-4参照)

GSNを拡張(モニタ、パラメタ、アクション、外部接続、説明責任)

開発組織英Adelard社、ロンドン大学

英ヨーク大学日DEOSプロジェクト

グラフィカルなアシュアランスケースの表記法一覧

GSNの表記例

経営層

ハザードや脅威は

想定されていたか？

対策はとられていたか？

機能は有効であったか？

残存リスクは適正だったか？

見える化された設計ドキュメント

リアルタイムで原因特定、対策検討

危害を受けた

ユーザー

原因

エビデンスをもって論理的に説明

過失の有無

今後の対策

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

設計の品質をエビデンス（証拠）に基づき第三者でも容易に理解できる表記で論理的に説明する


課題：上流工程でのセキュリティ設計

上流の段階におけるセキュリティ設計の手法がセーフティ設計と比較して普及していない

要件定義

システム設計

運用テスト

システムテスト

プログラミング

ソフトウェアテストソフトウェア設計

検証

検証

検証

セーフティとセキュリティの設計（アーキテクチャ設計）

システム化の方向性・システム化計画運用・評価セーフティとセキュリティの

コンセプトの策定及び周知

リスク分析、評価及びリスク低減策検討（セーフティとセキュリティの要件定義）

セーフティとセキュリティの設計（ソフトウェア設計）

信頼性の高いソフトウェアの実装

セーフティとセキュリティの設計プロセスＶ字開発モデル

評価

本日のセミナーをご参考にしてください


IPA/SECの今後の取組み


つながる世界に向けた取組み

品質ガイド

つながる世界の開発指針検討WGつながる世界の安全・安心を確保するために、各製品の開発時に考慮すべきセーフティ要件、セキュリティ要件及び信頼性要件を検討し、開発指針として策定（2016年3月公開予定）

セーフティ＆セキュリティ設計入門

つながる世界の品質理解の共通化

コンシューマデバイスの信頼性確保に向けた取組み

つながる世界のセーフティ設計・セキュリティ設計の薦めと見える化

つながる対象であるコンシューマデバイスの開発方法論の標準化

現在活動中

ISO/IEC 25000シリーズ

2015年６月発行 2015年10月発行 2013年9月公開2015年3月標準規格として認定

(案)


ご清聴ありがとうございました。

セーフティ設計・セキュリティ設計に関する ガイドブック紹介 ·...

Documents

セーフティ設計・セキュリティ設計に関するガイドブック紹介 ·...