Information-technology Promotion Agency, Japan
Copyright © 2014 IPA, All Rights Reserved
S o f t w a r e R e l i a b i l i t y
E n h a n c e m e n t C e n t er
1
Software Reliability Enhancement Center
つながる世界のセーフティ＆セキュリティ
設計の見える化
「つながる世界」での安心・安全の仕組み環境の整備に向けて
ソフトウェアグループ・研究員 鈴木基史
独立行政法人 情報処理推進機構
技術本部 ソフトウェア高信頼化センター
2014年11月19日
ソフトウェアグループ・研究員 鈴木基史
Copyright © 2014 IPA, All Rights Reserved
Software Reliability Enhancement Center
2
サプライチェーン調査結果
https://www.ipa.go.jp/sec/reports/20140725.html
「ソフトウェア開発の取引構造（サプライチェーン）の実態に関わる課題の調査報告書」
3
Copyright © 2014 IPA, All Rights ReservedSoftware Reliability Enhancement Center
ソフトウェアサプライチェーンとは
ユーザの組み合わせ
による新たな価値
ソフトウェアの開発から、それがエンドユーザに
使用され
るまで
の流通、その後の
運用・保守
、および
ユーザが組合
せて利用するまで
の、それに関与する組織の活動、役割、
情報、資源等を指すものとする。
ここでの定義
*ベーシックなサプライチェーン： 個々の企業の役割分担にかかわらず、原料の段階から製品やサービスが消費者の手に届くまでの全プロセスの繋がり運用・保守も含むライフ
サイクル全体
ベーシックな
サプライチェーン *
企画
設計
検証
部品
半製品
組立て
物流
運用
ユーザ
組合せ
保守
使用
顧客
事業者
廃棄
4
Copyright © 2014 IPA, All Rights ReservedSoftware Reliability Enhancement Center
サプライチェーンの主な変化と課題
利用者
調達者
供給者
ソフトウェア開発の水平分業化への変化
例： 鉄道、クラウド 等利用者
調達者
供給者 Ａ供給部品のソフトウェア仕様決定者の変化
例： スマートフォン（Android OS）、 （クラウド利用）ヘルスケア機器等製
品
・
サ
ー
ビ
ス
ソ
フ
ト
ウ
ェ
ア
製
品
・
サ
ー
ビ
ス
ソ
フ
ト
ウ
ェ
ア
製品・サービスをユーザが組合せて利
用する形態への変化
例： スマートハウス、 スマート家電利用者
相互に連携し、
新たな機能を提供
【課題】
• トレーサビリティ確保が重要であるが、サ プライチェーンが複雑になり、部品供給元 トレースが困難になる。 • 情報漏えい、不正プログラムの埋込みの危 険性が増大する。【課題】
• 利用時の品質を出荷時にすべて想定し、検 査することが困難になる。 • 製品・サービスを提供する複数の企業の責 任の所在が曖昧になる。 • 利用者が連携時のリスクを十分に理解でき ていない。 供給者 B 供給者C 供給者xx利用者
調達者
供給者
（調達側仕様に 合わせたソフトウェア）利用者
調達者
供給者 （OSS）ブラックボックス化
供給者 （クラウド サービス）【課題】
• 調達者からの仕様決定や不具合修正の優先 付け等の制御が利かなくなる。 • 通信におけるセキュリティ問題発生リスク が増大する。一次提供者
垂直統合型
水平分業型
調達者仕様決定型
供給者仕様決定型
従来型
ユーザ組合せ型
製
品
・
サ
ー
ビ
ス
ソ
フ
ト
ウ
ェ
ア
製
品
・
サ
ー
ビ
ス
ソ
フ
ト
ウ
ェ
ア
通信
利用者
仕様決定 仕様決定 仕様決定5
Copyright © 2014 IPA, All Rights ReservedSoftware Reliability Enhancement Center
つながる世界の課題
• すべての接続検証することは困難に
• 企業の責任の所在が曖昧に
6
Copyright © 2014 IPA, All Rights ReservedSoftware Reliability Enhancement Center
異なる品質基準製品の連携時の課題
自動運転車
セーフティレベル: 0
コマンド：不可
セーフティレベル7
コマンド: 自動駐車
セーフティレベル5
コマンド: ヒータON
寒い
+
レベル
高
レベル
高
=
レベル
高
+
レベル
高
レベル
低
=
レベル
低
ADAS
システムの品質レベル
PARKING
ユーザにはソフトの品質レベルは分からない
Copyright © 2014 IPA, All Rights Reserved
Software Reliability Enhancement Center
7
サプライチェーン課題における取り組み
8
Copyright © 2014 IPA, All Rights ReservedSoftware Reliability Enhancement Center
「つながる世界」での安心・安全の仕組み環境の整備に向けて
課題
リスクのある連携動作に
警告発生
異なる品質基準の製品間の
制御可否
判断
目指す
世界
【
】
セーフティ＆セキュリティ設計
の見える化
環境の整備に向けた活動
H26年度ソフトウェア相互の
信頼性確認の仕組み
トラスト環境の整備
• 品質基準が異なる製品を接続する際、その全体品質が一番低い部分の品質に依存する課題
• 利用者が製品やサービスを組み合わせて利用する際、すべての接続品質の検証が困難という課題
（安全性、セキュリティ等）9
Copyright © 2014 IPA, All Rights ReservedSoftware Reliability Enhancement Center
設計品質の見える化の推進
セーフティ＆セキュリティ設計
の品質の見える化
セーフティ＆セキュリティ設計
の普及・促進
2015年 品質向上のためのセーフティ＆ セキュリティ設計の勧め（仮）ガイドブック作成
プロモーション
H26年度
H27年度以降
セミナー、雑誌
ソフトウェア相互の信頼性確認の仕組み
警告発生・制御可否
設計品質の見える化
見える化
セーフティ・セキュリティ設計
Copyright © 2014 IPA, All Rights Reserved
Software Reliability Enhancement Center
10
設計品質の見える化と手法
11
Copyright © 2014 IPA, All Rights ReservedSoftware Reliability Enhancement Center
なぜ設計品質の見える化をするのか
① 説明責任をはたすため
② ステークスフォルダーとの情報共有のため
③ 設計の再利用のため
④ ソフトウェアの相互の信頼性確認のため
何か設計・実装されているか容易に分かる
欧米では説明責任をはたすために、規格として求められるケースもある
マネージャレベルでも、アシュアランスケースから何が設計されているか、理解が可能
つながる世界において、ソフトウェアの相互の信頼性確認のための基礎
12
Copyright © 2014 IPA, All Rights ReservedSoftware Reliability Enhancement Center
設計品質の見える化の実現ために
アシュアランス
（Assurance:保証）+
ケース
（Case:論拠）
1988年の北海油田事故（167名死亡）などを契機に、
欧米で規格認証の際に義務付けられるまでに普及
手順やチェックリスト等だけではなく、なぜ安全性が保たれるか、
明示された議論で、エビデンスをもとに保証する
導入により北海油田における事故が減少
安全性を議論する場合はセーフティケース、セキュリティを議論す
る場合はセキュリティケースと呼ばれる
（歴史的にはセーフティケースが最初でそれが一般化された）
参考：松野、高井、山本「D-Case入門 ～ディペンダビリティ・ケースを書いてみよう！～」」あるシステム／サービスが、特定の要求を満足するとの主張を立証
するために作られた、一連の監査可能な
主張
、
議論
、及び
証拠
アシュアランスケース
OMG SACM
アシュアランスケース
セーフティケース、セキュリティケース、…
13
Copyright © 2014 IPA, All Rights ReservedSoftware Reliability Enhancement Center
表記法
アシュアランスケースは通常、自然言語で記述
以下はグラフィックな表記法
GSN（Goal Structuring Notation）
イギリス ヨーク大学、イギリス国防省
D-CASE
日本 DEOS
（Dependable Embedded Operating Systems for Practical Use）プロジェクト
（科学技術振興機構（JST）の戦略的創造研究推進事業CRESTの研究領域のひとつとして作られた）
CAE (Claim Argument Evidence)
14
Copyright © 2014 IPA, All Rights ReservedSoftware Reliability Enhancement Center
ゴール
（Goal）
保証したいこと、命題（例：システムは安全である）
ゴールはさらに詳細なゴール（サブゴール）に分解される
前提
（Context)
システムの状態、環境などゴールを議論するときの前提等
（例：リスク分析の結果得られたハザードのリスト）
戦略
（Strategy）
ゴールをサブゴールに分けるときの考え方
（例：個別の障害ごとに議論する）
根拠
（Evidence/Solution）
ゴールが成り立つことを最終的の保証するもの
（例：テスト結果、運用事例など）
未展開記号
（Undeveloped entity）
ゴールを保障するための十分な議論又はエビデンスがない
（これはゴールやストラテジーにつけることができる）
ＧSＮ（Goal Structuring Notation）
保証のための構造化された議論の記述法
(T.Kellyらにより開発）
- GSN Community Standard Ver.1.0
15
Copyright © 2014 IPA, All Rights ReservedSoftware Reliability Enhancement Center
GSNの記述例
G1
システムは安全である
S1 ハザードがすべて回避されているこ とを保証する議論G2
ハザード１
が回避されている
G3
ハザード２
が回避されている
Sn1
ハザード1
の回
避方法
Sn2
ハザード2
の回
避方法
C2
同定されたハザード
ハザード1
ハザード2
C1
システム仕様書
ゴール（Goal） 前提（Context) 戦略（Strategy） サブゴール（Sub Goal） 根拠（Evidence/Solution）この戦略に従い、トップの
ゴールが下の２つのサゴー
ルに分解される
Copyright © 2014 IPA, All Rights Reserved
Software Reliability Enhancement Center
16
今後の具体的活動
17
Copyright © 2014 IPA, All Rights ReservedSoftware Reliability Enhancement Center
セーフティ・セキュリティ設計普及と見える化の取り組み
WG名：
サプライチェーンにおける品質の見える化WG
期間：
2014年9月～2015年3月
目的：
設計品質の見える化のためのセーフティとセキュリティ設計の取組みとハザード・
脅威事例を含めて分かり易く解説するガイドブックの作成とそのプロモーション
メンバー：
セーフティ or セキュリティの有識者
主査：
情報セキュリティ大学院大学 後藤教授
成果物：
ガイドブック
2Q
3Q
4Q
１Q
9月
10月
11月
12月
1月
2月
3月
ガイドブック公開2014年
2015年
第1回 第2回 第3回 ４回 ５回 ６回18
Copyright © 2014 IPA, All Rights ReservedSoftware Reliability Enhancement Center
ガイドブックとプロモーション
セキュリティ セーフティ 見える化手法セーフティ＆セキュリティ設計
の普及・促進
セーフティ＆セキュリティ設計
の品質の見える化
<< ガイドブックのイメージ >>対象読者
IPA: INFORMATION-TECHNOLOGY PROMOTIONAGENCY, JAPAN
