日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

2017年度演習コースⅢ 成果発表
「セーフティ＆セキュリティ開発のための技術統合提案と事例作成」
主査
副主査
アドバイザ
メンバ::::

金子 朋子
情報セキュリティ大学院大学
髙橋 雄志
トレドシステム勅使河原 可海 東京電機大学
荒井 文昭
キヤノンイメージングシステムズ
大森 淳夫
パイオニア
神田 圭
日立ソリューションズ
邱 章傑
パナソニック
久連石 圭
東芝
久木元 豊
テックスエンジソリューションズ
柴引 涼
メタテクノ
太郎田 裕介東京海上日動システムズ
中嶋 良秀
ノーリツ
西村 伸吾
富士ゼロックス細谷 雅樹
東光高岳
松本 江里加ダイキン工業日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

演習Ⅲ セーフティ＆セキュリティ開発 実績回

日時

講演テーマ

講演者

演習

１

5/12

セーフティ・セキュリティ開発のポイント

金子朋子

なし

２

6/9

IoT時代のリスク評価・リスクコミュニケーション

東京電機大学佐々木良一教授

アシュアランスケース

３

7/6,7合宿

セキュリティ標準とセキュリティ設計
ネットワークの信頼性とセキュリティアーキテクチャ

髙橋 雄志
勅使河原 可海

セキュリティ設計演習

４

8/3

第1回臨時会 論文化検討 脅威分析研究会での講演聴講

５

9/14,15

ソフトウェア品質シンポジウム（第2回臨時会 論文作成チーム分け）

６

10/13

STAMP/STPA，STPA-Sec
セーフティ・セキュリティリスク手法

金子朋子

事例作成検討７

11/17

トラストと安心・安全について

津田塾大学
村山優子教授事例作成を通じた演習

８

12/15

セキュリティ要求の保証概論と機能要件

金子朋子

事例作成を通じた演習

９

1/12

GSNの開発検証業務への応用事例

JAXA梅田浩貴氏

論文作成

10

2/1

第3回臨時会 論文作成 成果発表会準備112/23

成果発表会
2

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

2017年度演習コースⅢ 成果発表
「セーフティ＆セキュリティ開発のための技術統合提案と事例作成」
主査
副主査
アドバイザ
メンバ::::金子 朋子
情報セキュリティ大学院大学
髙橋 雄志
トレドシステム勅使河原 可海 東京電機大学
荒井 文昭
キヤノンイメージングシステムズ
大森 淳夫
パイオニア
神田 圭
日立ソリューションズ
邱 章傑
パナソニック
久連石 圭
東芝
久木元 豊
テックスエンジソリューションズ
柴引 涼
メタテクノ
太郎田 裕介東京海上日動システムズ
中嶋 良秀
ノーリツ
西村 伸吾
富士ゼロックス細谷 雅樹
東光高岳
松本 江里加ダイキン工業日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

目次
1. はじめに2. 開発プロセス説明
3. 開発プロセス適用事例紹介
1. 対象システム
2. ハザード抽出プロセス
3. ハザード分析・対策立案プロセス

4. 妥当性確認プロセス

4. 得られた知見，まとめ

5. 最後に4日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

目次
1. はじめに2. 開発プロセス説明
3. 開発プロセス適用事例紹介
1. 対象システム
2. ハザード抽出プロセス
3. ハザード分析・対策立案プロセス

4. 妥当性確認プロセス

4. 得られた知見，まとめ

5. 最後に
5日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

時代の流れ

1. はじめに 時代の流れセーフティの時代
機器は独立でネットワークのない時代

セキュリティの時代

セーフティ＆セキュリティの時代

ネットワークが繋がり IoT時代の到来により他の機器に影響があらゆる機器が有る時代影響を及ぼし合う時代
6日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

質問

1. はじめに

1. はじめに 皆さんの会社では，こんなやり取りありませんか？
＜セーフティ系担当者の場合＞
Ｎ氏：スマホと連動できるように，派生開発で，セキュリティ要件を追加しといてよ！
Ｙ氏：セキュリティなんて，専門外です．
専門部隊がやればいいじゃないですか？
上司Ｎ

Ｎ氏：最近，IoT系の依頼が多くて，当分対応してもらえないんだよ．
元々，セキュリティを専門にしている人員が少ないからねぇ・・・．

セーフティ系担当者Ｙ

7日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

質問

1. はじめに 皆さんの会社では，こんなやり取りありませんか？
＜セキュリティ系担当者の場合＞
Ｎ氏：スマホを使って，新たなサービスを提供してほしい．
Ｙ氏：じゃあ，必要そうな制御信号を送れるように作りますね．
セキュリティ面について，ご心配なく．

上司Ｎ

セキュリティ系
Ｎ氏：この制御信号送ったらダメだよ～！
担当者Ｙ
万が一があった時，この制御信号によって，ユーザーに被害を与えるかもしれないよ！
8

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

視点の違い

1. はじめに セーフティとセキュリティの視点は違う

セキュリティ
機密性（Confidentiality）

完全性（Integrity）

可用性（Availability）

セーフティ
9

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

本日お伝えしたいこと

1. はじめに

IoT時代において，１．セーフティに関する開発方法論だけなら，情報の機密性を損なう可能性が上がる．
２．セキュリティに関する開発方法論だけなら，利便性や機能性を損なう可能性が上がる．
３．セーフティとセキュリティを，まとめて分析したら，情報量が多くなりすぎて，整理や説明に困る．

10

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

本日お伝えしたいこと

1. はじめに

IoT時代において，１．セーフティに関する開発方法論だけなら，情報の機密性を損なう可能性が上がる．
２．セキュリティに関する開発方法論だけなら，利便性や機能性を損なう可能性が上がる．
３．セーフティとセキュリティを，まとめて分析したら，情報量が多くなりすぎて，整理や説明に困る．
セーフティとセキュリティ，それぞれバランスの取れた開発方法論ってどうするの？
11

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

目次
1. はじめに2. 開発プロセス説明
3. 開発プロセス適用事例紹介
1. 対象システム
2. ハザード抽出プロセス
3. ハザード分析・対策立案プロセス

4. 妥当性確認プロセス

4. 得られた知見，まとめ

5. 最後に
12日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日（参考）関連用語

2. 開発プロセスの説明＜セーフティ系＞（１／３）
FTA⁃ Fault Tree Analysis⁃ 発生が好ましくない事象について，発生経路，発生原因及び発生確率をフォールトの木を用いて解析

FMEA⁃ Failure Mode and Effect Analysis⁃ 不完全な設計や潜在的な欠点を見出すために，構成要素の故障モードとその上位アイテムへの影響を解析

13

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日（参考）関連用語

2. 開発プロセスの説明＜セーフティ系＞（２／３）
STAMP- Systems-Theoretic Accident Model and Processes- システム理論に基づく事故モデル

STPA- System–Theoretic Process Analysis- STAMPアクシデントモデルを前提とする，システムのハザード要因を分析する新しい安全解析手法- MITのNancy Leveson教授が提唱
14日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日（参考）関連用語

2. 開発プロセスの説明＜セーフティ系＞（３／３）
ASIL分析
⁃ Automotive Safety Integrity Level⁃ 車載電子システムで起こり得るさまざまなハザードを，回避するために，達成しなければならない安全性レベル．
⁃ 以下，３つの評価指標により、ハザード要因を評価⁃ 過酷度クラス⁃ 発生頻度クラス⁃ 回避可能性クラス

15日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日（参考）関連用語

2. 開発プロセスの説明＜セキュリティ系＞⁃ コモンクライテリア⁃ Common Criteria(CC)セキュリティ評価における国際標準規格⁃ CC-Case⁃ ITセキュリティ評価の国際標準であるコモンクライテリアとアシュアランスケースを用い，セキュリティ仕様を顧客と合意の上で決定する開発方法論⁃ 論理モデル：論理的プロセスによって，保証全体像を示す⁃ 具体モデル：製品ごとの具体的な特性を持った，リスクに対する検証をするアシュアランスケース
16日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

目次
1. はじめに2. 開発プロセス説明3. 開発プロセス適用事例紹介
1. 対象システム
2. ハザード抽出プロセス
3. ハザード分析・対策立案プロセス

4. 妥当性確認プロセス

4. 得られた知見，まとめ

5. 最後に17日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

安全なIoTシステムを目指す 2. 開発プロセスの説明
セキュリティ・バイ・デザイン
企画・要件定義
-設計

実装

検証・評価

保守・運用

企画・要件定義、設計段階という上流工程から情報セキュリティを確保するための方策-

IoT時代において，セキュリティ上の脅威によって，多大な被害を及ぼす可能性が出ているため，早期対応が重要．

CC-Caseをセーフティとセキュリティ，それぞれを考慮した開発方法論として適用する
18

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

論理モデルと具体モデル

2. 開発プロセスの説明

 CC-Caseの定義

19日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

保証全体像
 論理モデル例

2. 開発プロセスの説明
Goal：G_1「自動運転」に対するセーフティ&セキュリティ設計は妥当である
Strategy：S_1
プロセス毎に確認する

Context :C_1
STAMP/STPA
STAMP/S
TPA-sec
STRIDE

Goal：G_2
セーフティとセキュリティ観点
によるハザード
要因の洗い出しは妥当であるEvidence：E_1
識別したHCF一覧

Context :C_2
ASIL基準でセーフティ
セキュリティを統一

Goal：G_3
セーフティとセキュリティ観点
によるハザー
ド要因のハザード分析は妥
当である

Evidence：E_2
HCFのASIL分析
結果と対策

Context :C_3
アシュアランスケース

Goal：G_4
対策内容は妥当である

Evidence：E_3
対策内容妥当性確認のGSN20

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

保証全体像
 論理モデル例

2. 開発プロセスの説明
Goal：G_1「自動運転」に対するセーフティ&セキュリティ設計は妥当である
Strategy：S_1
プロセス毎に確認する

Context :Goal：G_2
C_1
セーフティとセ
STAMP/S
キュリティ観点
ハザード抽出
TPAによるハザード
STAMP/S
プロセス要因の洗い出
TPA-sec
しは妥当であSTRIDEる

Context :Goal：G_3
C_2
セーフティとセASIL基準
キュリティ観点
ハザード分析，でセーフティ
によるハザー
セキュリティ
ド要因のハザ
対策立案プロセスを統一
ード分析は妥当である

Evidence：E_1
識別したHCF一覧

Evidence：E_2
HCFのASIL分析
結果と対策

STAMP/STPA

ＡＳＩＬ分析と対策一覧

Goal：G_4
Context :対策内容はC_3
妥当である
アシュアラン
妥当性確認
スケースプロセス

アシュアランスケース
Evidence：E_3
対策内容妥当性確認のGSN

21

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

目次
1. はじめに2. 開発プロセス説明
3. 開発プロセス適用事例紹介
1. 対象システム
2. ハザード抽出プロセス
3. ハザード分析・対策立案プロセス4. 妥当性確認プロセス

4. 得られた知見，まとめ

5. 最後に22日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

目次
1. はじめに2. 開発プロセス説明
3. 開発プロセス適用事例紹介
1. 対象システム
2. ハザード抽出プロセス
3. ハザード分析・対策立案プロセス

4. 妥当性確認プロセス

4. 得られた知見，まとめ

5. 最後に23日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

対象システム3.1. 対象システム

対象システム：ネットワークに接続された レベル3の自動運転自動車- 通常，自動車は自動運転で走行する- システムが扱いきれない場合，運転手が運転する

運転手

クラウド

他車、路側機

衛星自動車

外部環境
24

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

目次
1. はじめに2. 開発プロセス説明
3. 開発プロセス適用事例紹介
1. 対象システム
2. ハザード抽出プロセス
3. ハザード分析・対策立案プロセス

4. 妥当性確認プロセス

4. 得られた知見，まとめ

5. 最後に25

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

STAMP/STPA 背景

3.2. ハザード抽出
プロセス

背景
シス
テム

安全
解析
手法

従来
- システムは小規模- ハードウェア主体

現在- システムは大規模/複雑- ソフトウェア主体- システム間のコミュニケーション
ミスによる障害が増加- 従来のアクシデントモデ - 新しいアクシデントモデル
ル：機器の故障や人間
STAMP：アクシデントは相互のオペレーションミスにシ作用が適切に働かないことにステムアクシデントの根よって起きる(次頁)
本原因がある- FTA FMEA- STPA：STAMPに基づく手法
26

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日
3.2. ハザード抽出
プロセス

STAMP/STPA
3.開発プロセス適用事例紹介
考え方

アクシデントは相互作用が適切に働かないことによって起きる制御を行う
コンポーネント

コントローラ

制御指示(コントロールアクション)

制御される
コンポーネント

フィードバック
データ

コントロールループ

被コントロールプロセス-

コントロールループが階層となり、システムが構築される-制御指示(コントロールアクション)が適切に与えられないためにア
クシデントが起こる
27

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日
3.2. ハザード抽出
プロセス

保証全体像
 論理モデル例

Goal：G_1「自動運転」に対するセーフティ&セキュリティ設計は妥当である
Strategy：S_1
プロセス毎に確認する

Context :Goal：G_2
C_1
セーフティとセ
STAMP/S
キュリティ観点
ハザード抽出
TPAによるハザード
STAMP/S
プロセス要因の洗い出
TPA-sec
しは妥当であSTRIDEる

Context :Goal：G_3
C_2
セーフティとセASIL基準
キュリティ観点
ハザード分析，でセーフティによるハザー
セキュリティ
ド要因のハザ
対策立案プロセスを統一
ード分析は妥当である

Evidence：E_1
識別したHCF一覧

Evidence：E_2
HCFのASIL分析
結果と対策

STAMP/STPA

ＡＳＩＬ分析と対策一覧

Goal：G_4
Context :対策内容はC_3
妥当である
アシュアラン妥当性確認
スケース

プロセス

アシュアランスケース
Evidence：E_3
対策内容妥当性確認のGSN

28

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

STAMP/STPA 概要手順

3.2. ハザード抽出プロセス

Step 0：(準備1)
アクシデント，ハザード，安全制約の識別

Step 0：(準備2)
コントロールストラクチャーの構築
Step 1：
非安全なコントロールアクション（UCA）の抽出
Step 2：
ハザード要因（HCF）の特定
29

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

STAMP/STPA 概要手順

3.2. ハザード抽出プロセス

Step 0：(準備1)
アクシデント，ハザード，安全制約の識別

Step 0：(準備2)
コントロールストラクチャーの構築
Step 1：
非安全なコントロールアクション（UCA）の抽出
Step 2：
ハザード要因（HCF）の特定
30

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日
3.2. ハザード抽出
プロセス

Step0（準備1）
アクシデント：損失(Loss)につながるような望ましくない事象→分析の目的ハザード：
アクシデントにつながるシステ
ムの状態

安全制約：ハザードから導かれるシステムを安全に保つための要件もしくは制約→step1へ入力作成した成果物
アクシデント(Loss)

ハザード（Hazard）

安全制約(Safety Constraints)(A1)自動車が外部環境(歩行者/他の車/周辺物)と衝突/接触する(H1-1) 自動車が，ブレーキをかけても，外部環境の前で停止できない(SC1-1) 自動車が，外部環境と衝突しないようにブレーキをかける(H1-2)ブレーキがかからな (SC1-2)運転手と自動車の両方がブいレーキをかけられない状態にならない

人命・財産喪失という重大アクシデントに限定
31

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

STAMP/STPA 概要手順

3.2. ハザード抽出プロセス

Step 0：(準備1)
アクシデント，ハザード，安全制約の識別

Step 0：(準備2)
コントロールストラクチャーの構築
Step 1：
非安全なコントロールアクション（UCA）の抽出
Step 2：
ハザード要因（HCF）の特定
32

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日
3.2. ハザード抽出
プロセス

Step0（準備2）

Step 0：（準備2）コントロールストラクチャーの構築- 目的：(相互作用が適切に働かないところを見つけるために) コンポーネント間の相互作用を明確化する- コントロールストラクチャー(制御構造図)で構成要素間の相互作用を表す
コントローラコントロールアクション

フィードバックデータ

被コントロールプロセス
33

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日
3.2. ハザード抽出
プロセス

Step0（準備2）
規定した自動車のシステムアーキテクチャ
運転する

運転手
指示

ハンドル

アクセル
ペダル

ブレーキ
ペダル

通知

速度制御

速度制御

ステアリン
グシステム

エンジン

ブレーキ
システム

クラウド
地図情報

人工知能
モジュール

外部環境情報他車，路側機

地図
モジュール
ローカル
ダイナミック
マップ

自動運転
解除指示
操舵制御

外部環境情報電波

衛星

車速，外部環境情報
センシング
モジュール

外部環境情報

外部環境

自動車
34

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日
3.2. ハザード抽出
プロセス

Step0（準備2）
作成したコントロールストラクチャー
CA1 ブレーキを踏む

ブレーキ
ペダル

運転手

自動運転不能警告
自動運転解除報告

CA3 自動運転解除指示

CA2 減速指示
ブレーキシステム

CA4 減速制御

人工知能
モジュール

クラウド

ローカル
ダイナミックマップ

コントロールアクション

車速，外部環境情報

CA5 速度制御
車体

フィードバック
データなど

センシング
モジュール

外部との作用
自動車

車速

外部環境
35

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

STAMP/STPA 概要手順

3.2. ハザード抽出プロセス

Step 0：(準備1)
アクシデント，ハザード，安全制約の識別

Step 0：(準備2)
コントロールストラクチャーの構築
Step 1：
非安全なコントロールアクション（UCA）の抽出
Step 2：
ハザード要因（HCF）の特定
36

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

Step1：ＵＣＡの抽出3.2. ハザード抽出プロセス

Step 1：非安全なコントロールアクション（UCA）の抽出-

UCA：Unsafe Control Action
非安全なコントロールアクション
ハザードにつながるコントロールアクション-

目的：ハザードにつながり得る，適切ではないコントロールアクション
を識別する

-

手順：4個のガイドワードを当てはめて，安全制約(SC)違反となれば，UCAとする(1) コントロールアクションが与えられない(2) 不適切なコントロールアクションが与えられる(3) コントロールアクションが早過ぎる，遅過ぎる(4) コントロールアクションの早過ぎる停止，長過ぎる適用
37

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日
3.2. ハザード抽出プロセス

Step1：ＵＣＡの抽出作成した成果物

与えられないとハザードコントロール Not
アクション
Providing与えられるとハザード

Providingcauseshazard

早過ぎ，遅過ぎToo early /Too late

早過ぎる停止，長過ぎる適用
Stop too soon
/ Applying toolong

CA1(UCA1-N) 運 (UCA1-P) 運 (UCA1-T) 運 (UCA1-S) 運
運転手が 転手がブレーキ 転手が誤った力 転手のブレー 転手がブレーキ加減でブレーキ キが遅すぎる を踏む時間が短ブレーキ を踏まないと危 操作を行うと， 場合，危険 すぎる場合，危を踏む
険回避ができず，減速が弱く外部 回避ができず， 険回避ができず外部環境と衝突 環境と衝突する 外部環境と衝 外部環境と衝する (SC1-2) (SC1-1)違反 突する (SC1- 突する (SC11)違反
1)違反
違反
CA2 減速指示
ガイドワードを当てはめて，安全制約違反(SC)となれば，UCAとする
38

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

STAMP/STPA 概要手順

3.2. ハザード抽出プロセス

Step 0：(準備1)
アクシデント，ハザード，安全制約の識別

Step 0：(準備2)
コントロールストラクチャーの構築
Step 1：
非安全なコントロールアクション（UCA）の抽出
Step 2：
ハザード要因（HCF）の特定
39

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

Step2：ハザード要因の特定

3.2. ハザード抽出プロセス

Step 2：ハザード要因（HCF）の特定-

HCF：Hazard Causal Factor
ハザード要因．ハザードを引き起こす原因-

目的：抽出したUCA について，どのような原因によってハザードと成り得るのか（安全制約違反になるか）を特定する-

手順：ヒントワードを当てはめて，ハザードになるかどうかを考える．
ハザードになる場合，どうなったらハザードになって，アクシデントにつながるかを考えて、ハザード要因を特定する

40

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

ヒントワード①

3.2. ハザード抽出
プロセス

STPAのヒントワード(1) コントロール入力や外部情報の誤りや喪失(2) 不適切なコントロールアルゴリズム(3) 不整合，不完全，または不正確なプロセスモデル．不適切な操作．
(4) コンポーネントの不具合．経年による変化．

(5) 不適切なフィードバック，あるいはフィードバックの喪失．フィードバックの遅れ(6) 不正確な情報の供給，または情報の欠如．測定の不正確性．フィードバックの遅れ(7) 操作の遅れ(8) 不適切または無効なコントロールアクション，コントロールアクションの喪失(9) コントロールアクションの衝突．プロセス入力の喪失または誤り(10) 未確認，または範囲外の障害(11) システムにハザードを引き起こすプロセス出力
41

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

ヒントワード②

3.2. ハザード抽出
プロセス

STPA-Sec-STPAにセキュリティの要素を組み込んだ安全解析手法-

セキュリティ上の脅威抽出に必要な分析の視点が追加
青字部分がSTPA-Secで追加されたヒントワード(5) 悪い形状・不適切なフィードバック，あるいはフィードバックの喪失．フィードバックの遅れ(6) 部分的な情報・不正確な情報の供給，または情報の欠如．
測定の不正確性．フィードバックの遅れ(7) 操作の遅れ，部分的・悪い形状のオペレーション(8) 悪い形状・不適切または無効なコントロールアクション，コント
ロールアクションの喪失
42

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

ヒントワード③

3.2. ハザード抽出
プロセス

STRIDE：マイクロソフト社が定義する脅威モデルをヒントワードとして使用S

Spoofing
Identity

なりすましコンピュータに対し，他のユーザを装うこと

T

Tampering

改ざん

データを意図的に操作することR

Repudiation

否認

ユーザがあるアクションを行ったことを否認し，相手はこのアクションを証明する方法がないこと

I

Information
Disclosure

情報の暴露

アクセス権限を持たない個人に情報が公開されていること

D

Denial ofService

サービス不能攻撃により正規へのユーザへのサービスが中断されるE

Elevation ofPrivilege

権限の昇格

権限のないユーザがアクセス権限を得ること
43日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

Step2：ハザード要因の特定

3.2. ハザード抽出
プロセス

STRIDE

作成した成果物

STPA-Sec44

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

Step2：ハザード要因の特定

3.2. ハザード抽出
プロセス

作成した成果物
UCAx(1)コントロー
ル入力や外部情報の誤りや喪失(2)

UCA1-N・悪天候など 運転手がブレー 外部環境がキを踏まないと危 悪く，運転手険回避ができず， が危険察知し外部環境と衝突 ないする(SC1-2)違反(3)不整合，不完全，または不正確なプ
ロセスモデル，不適切な操作(5)(6)部分的な情報・不正確な情報の供給，または情報の欠如，測定の不正確性，フィードバックの遅れ

・運転手が危険を察知したが自動運転を過信して，ブレーキを踏まない-・人工知能モジュールで異常を検知したが内部判定ロジックの誤りで自動運転不能警告が報知されない
45

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日
3.2. ハザード抽出プロセス

Step2：ハザード要因の特定作成した成果物
UCAx

(S)
なりす
まし

UCA1-N
運転手がブレーキを踏まないと危険回避ができず，外部環境と衝突する(SC1-2)違反(T)
Tampering
改ざん(R)
否認・クラウドから の情報を改ざんし，人工知能モジュールに自動運転継続可能であると誤認識させる

(I)
情報の暴露

(D)
Denial ofService
サービス不能-・人工知能モジュールに高負荷を与え自動運転不能警告を報
知できない

46

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

目次
1. はじめに2. 開発プロセス説明
3. 開発プロセス適用事例紹介
1. 対象システム
2. ハザード抽出プロセス
3. ハザード分析・対策立案プロセス

4. 妥当性確認プロセス

4. 得られた知見，まとめ

5. 最後に47

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日
3.3. ハザード分析
対策立案プロセス

保証全体像
 論理モデル例

Goal：G_1「自動運転」に対するセーフティ&セキュリティ設計は妥当である
Strategy：S_1
プロセス毎に確認する

Context :Goal：G_2
C_1
セーフティとセSTAMP/S
キュリティ観点
ハザード抽出
TPAによるハザードSTAMP/S
プロセス要因の洗い出
TPA-sec
しは妥当であSTRIDEる

Context :Goal：G_3
C_2
セーフティとセ
ASIL基準キュリティ観点
ハザード分析，でセーフティ
によるハザー
セキュリティ
ド要因のハザ
対策立案プロセスを統一
ード分析は妥当である

Evidence：E_1
識別したHCF一覧

Evidence：E_2
HCFのASIL分析
結果と対策

STAMP/STPA

ＡＳＩＬ分析と対策一覧

Goal：G_4
Context :対策内容はC_3
妥当である
アシュアラン
妥当性確認
スケース

プロセス

アシュアランスケース
Evidence：E_3
対策内容妥当性確認のGSN48

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

ハザード要因抽出完了…

3.3. ハザード分析
対策立案プロセス

STRIDE

作成した成果物

STPA-Sec

いきなり分析を始めてもいいのですが・・・

49

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日
3.3. ハザード分析
対策立案プロセス

ＵＣＡを整理3.開発プロセス適用事例紹介
全体像- 抽出したハザードをCC-Caseの具体モデルに基づき，ＵＣＡを整理した全体像「生命を脅かす障害」
部分を拡大！

50

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日
3.3. ハザード分析
対策立案プロセス

ＵＣＡを整理3.開発プロセス適用事例紹介
具体例- ＡＳＩＬ分析における評価指標のうち，深刻度が高い，ＵＣＡを整理して，対策立案を検討する優先度を決定．

ＵＣＡを整理！

51

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日
3.3. ハザード分析
対策立案プロセス

ＡＳＩＬ分析結果と対策
3.開発プロセス適用事例紹介- ＵＣＡ毎に整理したＡＳＩＬ分析を実施- 分析結果により，優先順位の高いものについて，優先的に対策内容を検討- 優先順位が低いハザード要因について，残存リスクを確認
評価指標
アクシデント

対象

該当する
UCA

自動車が 運転手－ UCA1-N
外部環境 ブレーキ(歩行者/ ペダル間他の車/周辺物)と衝突/接触する

HCF

対策内容

残存リス
ク

過酷度
クラス

発生頻度
クラス

回避可能性
クラス

悪天候など外部環境が悪く，運転手が危険察知しない

S3

E2

C2

ASIL_A 運転手の注意レベルを監視する-

運転手が危険を察知したが自動運転を過信して，ブレーキを踏まない

S3

E4

C2

ASIL_C

運転手の注意レベルを監視する
定期的に音声による注意喚起-

ブレーキペダルの遊びと認知する値が大きすぎて，ブレーキを踏んだと認識しない

S3

E2

C2

ASIL_A

ユーザビリティ評価を実施し，適切な遊び量に調整する-

ＵＣＡごとに，ＨＣＦを整理

ASIL_A～Dを優先して分析．
優先度：A＜D

ＡＳＩＬ
決定値

対策が不十分な内容について，残存リスクを別途管理
52

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日
3.3. ハザード分析
対策立案プロセス

ＡＳＩＬ分析結果と対策例
3.開発プロセス適用事例紹介- 具体的な対策内容を立案
評価指標
該当するUCA

UCA1-N

HCF

ＡＳＩＬ
決定値

対策内容

運転手が危険を察知したが自運転手の注意レベルを監視する
動運転を過信して，ブレーキを ASIL_C
定期的に音声による注意喚起
踏まない
人工知能モジュールに高負荷を与え自動運転不能警告を報 ASIL_A DoS対策を実施する
知できない

対策が十分か，
社内合意を取る53

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

目次
1. はじめに2. 開発プロセス説明
3. 開発プロセス適用事例紹介
1. 対象システム
2. ハザード抽出プロセス
3. ハザード分析・対策立案プロセス

4. 妥当性確認プロセス

4. 得られた知見，まとめ

5. 最後に54

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日
3.4. 妥当性確認
プロセス

保証全体像
 論理モデル例

Goal：G_1「自動運転」に対するセーフティ&
セキュリティ設計は妥当である
Strategy：S_1
プロセス毎に確認する

Context :Goal：G_2
C_1
セーフティとセ
STAMP/S
キュリティ観点
ハザード抽出
TPAによるハザード
STAMP/S
プロセス要因の洗い出
TPA-sec
しは妥当であSTRIDEる

Context :Goal：G_3
C_2
セーフティとセ
ASIL基準キュリティ観点
ハザード分析，でセーフティによるハザー
セキュリティ
ド要因のハザ
対策立案プロセスを統一
ード分析は妥当である

Evidence：E_1
識別したHCF一覧

Evidence：E_2
HCFのASIL分析
結果と対策

STAMP/STPA

ＡＳＩＬ分析と対策一覧

Goal：G_4
Context :対策内容はC_3
妥当である
アシュアラン
妥当性確認
スケース

プロセス

アシュアランスケース
Evidence：E_3
対策内容妥当性確認のGSN55

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日
3.4. 妥当性確認
プロセス

対策内容の妥当性を確認
3.開発プロセス適用事例紹介- 対策内容が妥当かを示す．

ASIL_A～Dについて，対策内容が妥当か確認

インスペクション議事録等，実施した証跡を確認
56

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日
3.4. 妥当性確認
プロセス

保証全体像
Goal：G_1「自動運転」に対するセーフティ&セキュリティ設計は妥当である
Strategy：S_1
プロセス毎に確認する

Context :Goal：G_2
C_1
セーフティとセSTAMP/S
キュリティ観点
ハザード抽出
TPAによるハザード
STAMP/S
プロセス要因の洗い出
TPA-sec
しは妥当であSTRIDEる

Context :Goal：G_3
C_2
セーフティとセASIL基準
キュリティ観点
ハザード分析，でセーフティによるハザー
セキュリティ
ド要因のハザ
対策立案プロセスを統一
ード分析は妥当である

Evidence：E_1
識別したHCF一覧

Evidence：E_2
HCFのASIL分析
結果と対策

STAMP/STPA

ＡＳＩＬ分析と対策一覧

Goal：G_4
Context :対策内容はC_3
妥当である
アシュアラン
妥当性確認
スケース

プロセス

アシュアランスケースEvidence：E_3
対策内容妥当性確認のGSN

57

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

目次
1. はじめに2. 開発プロセス説明
3. 開発プロセス適用事例紹介
1. 対象システム
2. ハザード抽出プロセス
3. ハザード分析・対策立案プロセス

4. 妥当性確認プロセス

4. 得られた知見，まとめ

5. 最後に58

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

4. 得られた知見，まとめ得られた知見3.開発プロセス適用事例紹介
プロセス毎に，知見をまとめる⁃ ハザード抽出プロセス⁃ STAMP/STPAは，セーフティの手法であるが，STAMP/STPA-SecやSTRIDEをヒントワードとして適用することにより，セキュリティに関する脅威を洗い出せた．
特にSTRIDEをヒントワードとして用いて拡張することは，有効であった．
⁃ ハザード，UCA ，HCFを複数人で分析することを考慮すると，各用語に該当する具体例を事前に定義することが必要である．
実際，複数人で分析を始めると，各用語に対する粒度が異なり，整合性が取れなかった．

⁃ ハザード整理，対策立案プロセス⁃ ハザード抽出プロセスにより得た結果を，深刻度が高いハザードをUCA毎に，整理することで，対策を立案する優先順位が明確になった．

⁃ 妥当性確認プロセス⁃ 開発者が，対策の妥当性をGSNを用いて検証することで，第三者に対して説明しやすくなった．
59

日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

4. 得られた知見，まとめ

まとめ3.開発プロセス適用事例紹介
１. IoT時代に必要なセーフティとセキュリティをバランスよく対応できるか，開発方法論を試行した．

２．自動運転に対して，知見のないメンバーが， 効率よく進めるための改善策は知見参照

STAMP/STPAを拡張して適用することにより，セーフティとセキュリティ，それぞれに関するハザードを抽出できた．

３．CC-Caseで提唱している論理モデルを使って，プロセスを定義し，具体モデルを使って，妥当性を確認するという開発方法論は，思考を整理できる点や説明性において有益である．

セーフティとセキュリティ，それぞれバランスの取れた開発方法論いかがですか？
60日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

目次
1. はじめに2. 開発プロセス説明
3. 開発プロセス適用事例紹介
1. 対象システム
2. ハザード抽出プロセス
3. ハザード分析・対策立案プロセス

4. 妥当性確認プロセス

4. 得られた知見，まとめ

5. 最後に61日科技連 第33年度ソフトウェア品質管理研究会 成果発表会 2018年2月23日

5. 最後に謝辞 3.開発プロセス適用事例紹介

ご指導を頂きました金子主査，髙橋副主査，勅使河原アドバイザ
ならびに特別講義の講師の方々に御礼申し上げます．
また，有意義な機会を与えて頂きました
日本科学技術連盟の皆様，およびコース参加を許可して頂きました会社と上司の方々へ感謝申し上げます．
ご清聴ありがとうございました
演習コースⅢ 参加者一同62