Comments
Description
Transcript
ソフトウェアサプライチェーンの課題と つながる世界のセーフティ
ITフォーラム：IPA/SECセッション ソフトウェアサプライチェーンの課題と つながる世界のセーフティ＆セキュリティ設計の見える化 2015年2月3日 独立行政法人 情報処理推進機構 技術本部 ソフトウェア高信頼化センター ソフトウェアグループ・研究員 鈴木基史 ソフトウェアグループ・研究員 Copyright © 2015 IPA, All Rights Reserved 鈴木基史 Software Reliability Enhancement Center 1 サプライチェーン調査結果 「ソフトウェア開発の取引構造（サプライチェーン）の実態に関わる課題の調査報告書」 https://www.ipa.go.jp/sec /reports/20140725.html Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 3 ソフトウェアサプライチェーンとは ここでの定義 ソフトウェアの開発から、それがエンドユーザに使用され るまでの流通、その後の運用・保守、およびユーザが組合 せて利用するまでの、それに関与する組織の活動、役割、 情報、資源等を指すものとする。 ユーザの組み合わせ による新たな価値 運用・保守も含むライフ サイクル全体 ベーシックな サプライチェーン * 使用 企画 設計 検証 部品 事業者 半製品 組立て 物流 運用 ユーザ 組合せ 保守 廃棄 顧客 *ベーシックなサプライチェーン： 個々の企業の役割分担にかかわらず、原料の段階から製品やサービスが消費者の手に届くまでの全プロセスの繋がり Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 4 調査対象分野 市場規模が大きく、対策により得られる効果の大きい分野： 自動車、クラウドサービス、スマートフォン 日系企業の世界シェアが高いなど日本の競争優位性が高く、日本の強みを生かすことができる分野：デジタル複合機 安全性が求められる分野： ヘルスケア機器、サービスロボット、鉄道 ネットワーク化により新たな産業の創出が期待される分野： スマート家電 分野 選定理由 組込 業務 WE み系 系 B系 企業例 自動車 製造業の中で市場規模（出荷額 約50兆円）が大きく、多くの取引企業からなる 裾野の広い産業。高い安全性・信頼性が求められる。IT融合領域のスマートシ ティに関わる分野。 クラウドサービス 市場の拡大傾向が予想されており、ネットワーク化、サービス化の重要な役割を 担う分野である。サーバ側の基盤。 スマートフォン 世界市場規模が拡大傾向にあり、多くの分野と連携するクライアント側の基盤的 な分野である。 ● デジタル複合機 日本の競争力が高く（世界シェア77%）、情報セキュリティを含む要求水準の高 い分野である。コモンクライテリア製品認証の取得率が高く、取組みの参考とな る。 ● セイコーエプソン、富士ゼロック ス ● オムロンヘルスケア、タニタ ● 東 芝ホ ー ム 、シ ャ ー プ、 パナ ソ ニック ヘルスケア機器 サービスロボット 血圧、活動量、睡眠ログなどセンサデータの統合管理サービスに焦点を当てる。 クラウドを用いたITと他分野の融合分野であり、高齢化社会を迎え市場拡大が予 想されている。 IT融合領域に含まれる。また、今後、技術進歩に伴い家庭等における一般利用の 拡大が予想され、その際に、安全性、信頼性が求められる分野である。介護ロ ボットに焦点。 鉄道（運行管理系） 重要インフラ分野であり、高信頼性が求められる分野である。（信号システム等 の制御系は対象とはしない。） スマート家電 IT融合領域のスマートコミュニティの重要な構成要素。家電のIT化、ネットワー ク化の進展が予想され、新たな領域として注目度が高い。 Copyright © 2015 IPA, All Rights Reserved トヨタ自動車、日産自動車、デン ソー、アイシン精機 ● ● ● ● ● 富士通、NTTコミュニケーション ズ、Amazon Web Services ● NTTドコモ、富士通、Google JR東日本、日立製作所 パナソニック、ソニー、東芝 Software Reliability Enhancement Center 5 サプライチェーンの類型による整理 類型 垂 直 統 合 型 従 来 型 ※1 水 平 分 業 型 説明 典型例 調達者仕様決定型 資本関係にある企業グループ内で安定的な関係により開 発（仕様策定、開発、製造、試験等）を行う。エンド 自動車分野の系列取引 ユーザに近いサプライチェーンの下流からニーズに基づ き調達者が主導で仕様を策定する。 供給者仕様決定型※2 企業グループ内で、コア技術や先端技術を持つ子会社が、 供給者主導で仕様を策定する。資本関係が強い場合、水 （このケースは少ない） 平分業に移行せず垂直統合型を維持する場合がある。 調達者仕様決定型 調達側が主体的に決めた仕様に基づいて、資本関係の有 無に係らず固定化されない複数企業から発注先を決定す 開発委託など る。 供給者仕様決定型 製品の部品を提供する企業が仕様決定権を持ち、複数の OSS, COTSなどの 調達先に供給する。調達者にとって部品の管理が希薄に メジャー製品ベンダ なる場合がある。 ユーザ組合せ型※1 （サービス連携型） 複数の企業により提供される製品・サービスをユーザが スマートフォンアプリ、 クラウドサービス連携など 自ら組合せて選択し、同時利用する。 ※1：ユーザへの利用形態に焦点を当てた分類 ※2：表においては体系的な整理の軸として記載するが、少ないケースであるため、対象とする類型に含めない。 Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 6 各類型の取引関係図 垂直統合型・調達者仕様決定型 ユーザ組合せ型の取引関係図 Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 7 代表的類型パターン（スマート家電） 凡例 利用者 企業単位 （色枠）ポジション ・ ・ ユーザ組合せ型 取引関係 スマート家電製品 スマートフォン用アプリ 住宅設備機器 ソフトウェア種類等 住宅設備機器メーカ 家電メーカ サービスプロバイダ ツール提供 サービス部品提供 調達 検証委託 カスタマイズ OSベンダ 調達 ソフトウェア部品提供 OS 検証サービス ソフトウェアベンダ セットメーカ アプリケーション開発 機器部品提供 水平分業型（供給者仕様決定型） 組込みソフト サーバソフト サービス提供 調達 部品メーカ 部品 組込みソフト 機器部品提供 開発委託 家電メーカグループ内ソフトウェアベンダ 受託開発 組込みソフト サーバソフト 垂直統合 （調達者仕様決定型） 開発委託 外部ソフトウェアベンダ 水平分業型 （調達者仕様決定型） Copyright © 2015 IPA, All Rights Reserved 受託開発 Software Reliability Enhancement Center 8 サプライチェーンの主な変化と課題 ソフトウェア開発の水平分業化への変化 供給部品のソフトウェア仕様決定者の変化 製品・サービスをユーザが組合せて利 用する形態への変化 垂直統合型 水平分業型 調達者仕様決定型 供給者仕様決定型 従来型 ユーザ組合せ型 利用者 利用者 利用者 利用者 利用者 利用者 相互に連携し、 新たな機能を提供 調達者 調達者 調達者 調達者 一次提供者 仕様決定 ブラックボックス化 供給者 供給者 供給者 供給者 Ａ B C 供給者 xx 供給者 （調達側仕様に 合わせたソフトウェア） 供給者 （OSS） 仕様決定 通信 供給者 ソ製 フ品 ト・ ウサ ェー アビ ス ソ製 フ品 ト・ ウサ ェー アビ ス ソ製 フ品 ト・ ウサ ェー アビ ス ソ製 フ品 ト・ ウサ ェー アビ ス 仕様決定 （クラウド サービス） 例： 鉄道、クラウド 等 例： スマートフォン（Android OS）、 （クラウド利用）ヘルスケア機器等 例： スマートハウス、 スマート家電 【課題】 【課題】 【課題】 • トレーサビリティ確保が重要であるが、サ プライチェーンが複雑になり、部品供給元 トレースが困難になる。 • 情報漏えい、不正プログラムの埋込みの危 険性が増大する。 Copyright © 2015 IPA, All Rights Reserved • 調達者からの仕様決定や不具合修正の優先 付け等の制御が利かなくなる。 • 利用時の品質を出荷時にすべて想定し、検 査することが困難になる。 • 通信におけるセキュリティ問題発生リスク が増大する。 • 製品・サービスを提供する複数の企業の責 任の所在が曖昧になる。 • 利用者が連携時のリスクを十分に理解でき ていない。 Software Reliability Enhancement Center 9 サプライチェーンにおけるセキュリティ Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 10 サプライチェーンにおける脅威 海外から調達した通信機器がアメリカで深夜 に勝手に動き本国にデータ送信の疑惑 スマホの「バックドア設置が発覚」 Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 11 バックドアの種類 From wikipedia 設計開発段階で盛り込まれるバックドア 【意図されないバックドア】 プログラムの開発者が意図的にプログラムに組み込んだバックドアをもつソフトウェア製品や、それを含んだハードウェア製品が 販売されてしまうことがある。これが、バックドアの中で比較的多い。 開発者が私的な利益のために組み込むバックドア 【悪意のバックドア】 一部の、倫理的な問題をもつコンピュータプログラム開発者の中には、依頼者と契約によって製造するプログラムの中に、 バックドアを（仕様には明らかにせずに）意図的に組み込み、依頼者がそのプログラムを使用している最中に、このバックド アを利用して、何らかの不正を働く場合がある。 意図されない開発段階のバックドア 【意図されないバックドア】 コンピュータは元来、外部からの信号を受けて作動する。求められる仕様に応じて、特定の操作だけに反応するようプログラ ムやハードウエアを設計する。しかし、OSなどが、バグや設計上のミスから、本来受け入れるべきではない通信を受け入れ てしまう場合がある。これらは一般的にセキュリティホールと呼ばれていて、その中には特定の通信に対してコンピュータの 設定を自由に変更できる管理権限を許してしまう場合もある。 稼動中のコンピュータに外部から送り込まれるバックドア 【悪意のバックドア】 稼動中のコンピュータにおいて、その中にある情報を見るには、正規の手続きを踏んで閲覧するのが普通である。しかし、正規 の手続きによらずに情報を呼び出したり、場合によっては情報の作成・変更・消去を、正規ではない手続きで行うことを可能に するプログラムを外部から送り込み、コンピュータ内で動作させることもある。この行為は、不正アクセスである。 メンテナンス用バックドア 【メンテナンス用バックドア】 機器のメンテナンス等を目的に、マニュアルに載せないが、メーカーが組み込むバックドア。 http://ja.wikipedia.org/wiki/%E3%83%90%E3%83%83%E3%82%AF%E3%83%89%E3%82%A2 Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 12 調達ソフトウェアによる不正ソフトの混入課題 A社 調達ソフトウェア#1 101100010110 10010111001 メーカー 統合ソフトウェア 1011000101101 0010111001010 1010001111001 B社 調達ソフトウェア#2 1011000101101 0010111001010 1010001111 1011000101101 0010111001 C社 調達ソフトウェア#3 不正ソフト検出ツール/手法が必要 サプライチェーン上の不正ソフトは、 ウイルス検出ソフトでは検出できない Copyright © 2015 IPA, All Rights Reserved 101100010 110100101 110010101 010001111 内製 101100010110 10010111001 開発委託 調達 (派遣含む) Software Reliability Enhancement Center 13 調達ソフトウェアのトレースの必要性 サプライチェーン・リスクマネージメント 調達におけるリスク考慮 A社 調達ソフトウェア#1 101100010110 10010111001 メーカー 統合ソフトウェア 1011000101101 0010111001010 1010001111001 1011000101101 0010111001010 1010001111 B社 調達ソフトウェア#2 トレース 1011000101101 0010111001 C社 調達ソフトウェア#3 すべてのソフトウェアをトレース できる仕組みが求められる 101100010 110100101 110010101 010001111 内製 101100010110 10010111001 開発委託 調達 (派遣含む) DB Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 14 サプライチェーンにおける課題と取組み Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 15 つながる世界の課題 • すべての接続検証することは困難に • 企業の責任の所在が曖昧に • 利用者が連携時リスクを把握できない Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 16 異なる品質基準製品の連携時の課題 ユーザにはソフトの品質レベルは分からない セーフティレベル7 コマンド: 自動駐車 PARKING セーフティレベル5 コマンド: ヒータON 寒い システムの品質レベル 自動運転車 セーフティレベル: 0 コマンド：不可 ADAS + レベル高 = レベル高 + レベル低 Copyright © 2015 IPA, All Rights Reserved レベル高 = レベル高 レベル低 Software Reliability Enhancement Center 17 「つながる世界」での安心・安全の仕組み環境の整備に向けて 課題 • 品質基準が異なる製品を接続する際、その全体品質が一番低い部分の品質に依存する課題 （安全性、セキュリティ等） • 利用者が製品やサービスを組み合わせて利用する際、すべての接続品質の検証が困難という課題 【 目指す 世界 】リスクのある連携動作に警告発生 環境の整備に向けた活動 異なる品質基準の製品間の制御可否判断 トラスト環境の整備 H26年度 セーフティ＆セキュリティ設計 の見える化 Copyright © 2015 IPA, All Rights Reserved ソフトウェア相互の 信頼性確認の仕組み Software Reliability Enhancement Center 18 設計品質の見える化の推進 H26年度 設計品質の見える化 セーフティ＆セキュリティ設計 の普及・促進 セーフティ＆セキュリティ設計 の品質の見える化 ガイドブック作成 品質向上のためのセーフティ＆ セキュリティ設計の勧め（仮） 2015年 プロモーション セミナー、雑誌 H27年度以降 ソフトウェア相互の信頼性確認の仕組み 見える化（アシュアランスケース） 警告発生・制御可否 Copyright © 2015 IPA, All Rights Reserved セーフティ・セキュリティ設計 Software Reliability Enhancement Center 19 設計品質の見える化とアシュアランスケース Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 20 日本メーカ製自動車の「意図しない急加速（UA）」 2009～2010年 日本メーカ製自動車の「意図しない急加速」に関するクレームが急増 米国議会や米運輸省道路交通安全局(NHTSA)から報告を求められるもメー カ側は説明に苦慮 NHTSAは米国航空宇宙局(NASA)に脆弱性の有無の調査を要請 上記の結果ＮＡＳＡ が実施したこと 調査範囲 電子スロットル制御(Electronic Throttle Control)システムの設計及び/もしくは実装に実際に意図しな い加速(Unintended Acceleration)を引き起こすことが予期できる脆弱性があるかないかを決定する。 UAを引き起こす可能性はあるか 通常の使用で実際に起こりうるか 実施した解析（いずれもツールを最大限活用） 実装コードの解析 ロジックの解析 モデルベースのテスト 実時間性の解析 結果 NASAの解析とテストでは、消費者が報告したような、大きなUAを引き起こすETCの不具合の 証拠は見つからなかった。 Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 21 客観的・合理的な説明の必要性 これまでの日本企業は、利用者の要望に個々に答えることで 高品質というブランド力を築いてきた 実際、日本製のソフトウェアの品質は海外に比べて1桁以上高いとの調 査報告もある しかしながら、グローバル市場においては客観的・合理的な 説明が求められる 客観的・合理的な説明が必要 製品自体の品質を事実に基づいて論理的に説明できなくてはならない 国際標準（ISO/IEC）等、世界的に合意されている基準類を用いた説明、 または、それに準じた説明（規格適合、規格認証 等） 専門性のある第三者による説明（第三者確認、第三者証明 等） Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 22 アシュアランスケースとは 参考：松野、高井、山本「D-Case入門 ～ディペンダビリティ・ケースを書いてみよう！～」」 アシュアランスケース あるシステム／サービスが、特定の要求を満足するとの主張を立証 するために作られた、一連の監査可能な主張、議論、及び証拠 OMG SACM アシュアランス（Assurance:保証）+ ケース（Case:論拠） 1988年の北海油田事故（167名死亡）などを契機に、 欧米で規格認証の際に義務付けられるまでに普及 手順やチェックリスト等だけではなく、なぜ安全性が保たれるか、 明示された議論で、エビデンスをもとに保証する 導入により北海油田における事故が減少 安全性を議論する場合はセーフティケース、セキュリティを議論す る場合はセキュリティケースと呼ばれる （歴史的にはセーフティケースが最初でそれが一般化された） アシュアランスケース Copyright © 2015 IPA, All Rights Reserved セーフティケース、セキュリティケース、… Software Reliability Enhancement Center 23 トゥールミン・ロジックの基礎 論理の基本 主張（Claim） 論理として構築されるひとつの主張 基礎（Data） 論理の根拠となる、状態、事実など 最初に呈示される説明情報 主張 ： Claim 根拠 ： Warrant 根拠（Warrant） クレームの根拠としてデータが利用 可能であることを正当化する情報 基礎 ： Data ディベートで超論理思考を手に入れる ISBN 978-4-904209-13-4 著者： 苫米地英人 脳機能学者/カーネギーメロン大学博士 Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 24 トゥールミンの三角ロジック（１） 窓を開けた方がいい 主張： Claim 根拠： Warrant 窓を開ければ室温が下がり、 快適になる 基礎： Data 室温が30度だ Copyright © 2015 IPA, All Rights Reserved トゥールミンの三角ロジック 早稲田大学人間科学学術院 向後千春 http://kogolearn.wordpress.com/ Software Reliability Enhancement Center 25 トゥールミンの三角ロジック（２） 反駁(はんばく）: Rebuttal 窓を開けた方がいい トゥールミンの三角ロジックが成り立っている場合 ←（主張は反駁できない） 主張： Claim 根拠： Warrant 窓を開ければ室温が下がり、 快適になる 基礎： Data ↑ 外の方が気温が高ければ、 温度は下がらない 反駁： Rebuttal 室温が30度だ ↑ 温度計が狂っている Copyright © 2015 IPA, All Rights Reserved トゥールミンの三角ロジック 反駁： Rebuttal 早稲田大学人間科学学術院 向後千春 http://kogolearn.wordpress.com/ Software Reliability Enhancement Center 26 トゥールミンの三角ロジック（３） 質疑: Question 窓を開けた方がいい トゥールミンの三角ロジックが成り立っている場合 ←（主張は反駁できない） 主張： Claim 根拠： Warrant 窓を開ければ室温が下がり、 快適になる 基礎： Data ↑ なぜ窓を開けると 室温が下がるのか？ 質疑： Question 室温が30度だ トゥールミンの三角ロジック ↑ なぜ30度だとわかるのか？ 質疑： Question Copyright © 2015 IPA, All Rights Reserved 早稲田大学人間科学学術院 向後千春 http://kogolearn.wordpress.com/ Software Reliability Enhancement Center 27 トゥールミンの三角ロジック（４） 反論: Counter argument 窓を閉めた方がいい 主張： Claim 新たな三角ロジックを立てる 根拠： Warrant クーラを入れれば、 室温が下がり、快適になる 基礎： Data 室温が30度だ Copyright © 2015 IPA, All Rights Reserved トゥールミンの三角ロジック 早稲田大学人間科学学術院 向後千春 http://kogolearn.wordpress.com/ Software Reliability Enhancement Center 28 トゥールミン・モデル 論理を支える構造 クレーム（C論理） 論理として構築されるひとつの主張 データ ：Data クレーム ：Claim データ（D論理） 論理の根拠となる、状態、事実など 最初に呈示される説明情報 ワラント（W論理） クレームの根拠としてデータが利用 可能であることを正当化する情報 ワラント ：Warrant バッキング ：Backing リザベーション ：Reservation クゥオリフィアー ：Qualifier ディベートで超論理思考を手に入れる ISBN 978-4-904209-13-4 著者： 苫米地英人 脳機能学者/カーネギーメロン大学博士 Copyright © 2015 IPA, All Rights Reserved バッキング（B論理） ワラントが正しいことを支持する証 拠、証言、統計、価値判断、信憑性 などの情報 クゥオリフィアー（Ｑ論理） クレームの相対的強度の定性的な表 現。また、可能であれば90％などの 定量的な表現 リザベーション（Ｒ論理） クレームに対する例外を主張する論 理 Software Reliability Enhancement Center 29 アシュアランスケースの表記法と利用 Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 30 表記法 アシュアランスケースは通常、自然言語で記述 トゥールミン（Toulmin）モデル Stephen Edelston Toulmin, 1922年3月25日 - 2009年12月4日 イギリス生まれの哲学者(専門は科学哲学) グラフィックな表記法 GSN（Goal Structuring Notation） イギリス ヨーク大学、イギリス国防省 D-CASE 日本 DEOS（Dependable Embedded Operating Systems for Practical Use）プロジェクト （科学技術振興機構（JST）の戦略的創造研究推進事業CRESTの研究領域のひとつとして作られた） CAE (Claim Argument Evidence) イギリス Adelard社、City University London Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 31 ＧSＮ（Goal Structuring Notation） 保証のための構造化された議論の記述法(T.Kellyらにより開発） - GSN Community Standard Ver.1.0 ゴール（Goal） 保証したいこと、命題（例：システムは安全である） ゴールはさらに詳細なゴール（サブゴール）に分解される 前提（Context) システムの状態、環境などゴールを議論するときの前提等 （例：リスク分析の結果得られたハザードのリスト） 戦略（Strategy） ゴールをサブゴールに分けるときの考え方 （例：個別の障害ごとに議論する） 根拠 ゴールが成り立つことを最終的の保証するもの （例：テスト結果、運用事例など） （Evidence/Solution） 未展開記号 ゴールを保障するための十分な議論又はエビデンスがない （Undeveloped entity） （これはゴールやストラテジーにつけることができる） 参考：松野、高井、山本「D-Case入門 ～ディペンダビリティ・ケースを書いてみよう！～」」 Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 32 GSNの規格 GSNの仕様は、GSNワーキング グループの以下のWebサイトから入手可能 Goal Structuring Notation The GSN Working Group Online http://www.goalstructuringnotation.info/documents/GSN_Standard.pdf GSN COMMUNITY STANDARD VERSION1 November 2011 日本語は以下のWebサイトから入手可能 https://s3-ap-northeast-1.amazonaws.com/cdn.change-vision.com/tutorials/GSN_Standard_by_ChangeVision+(Ver3).pdf Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 33 GSNの記述例 前提（Context) ゴール（Goal） C1 システム仕様書 G1 システムは安全である 戦略（Strategy） S1 ハザードがすべて回避されているこ とを保証する議論 C2 同定されたハザード ハザード1 ハザード2 サブゴール（Sub Goal） G2 ハザード１が回避されている G3 ハザード２が回避されている この戦略に従い、トップの ゴールが下の２つのサゴー ルに分解される 根拠（Evidence/Solution） Sn1 ハザード1の回 避方法 Copyright © 2015 IPA, All Rights Reserved Sn2 ハザード2の回 避方法 Software Reliability Enhancement Center 34 D-Case D-CaseはGSNを使って表記します。 主に右表のノードにより構成されます。 このうち、モニタと外部接続はDCaseのGSN からの拡張です。 名称 ノード ゴール システムは ディペンダブル である 対象システムに対して、議論すべき命題 ハザードごと に議論する ゴールが満たされることを、サブゴールに分 割して詳細化するときの議論の仕方 戦略 前提 エビデンス ハザード リスト テスト 結果 外部接続 DEOSプロジェクト研究成果集 P41, 図4-5: D-Caseの例 http://www.jst.go.jp/crest/crest-os/osddeos/data/DEOS-FY2013-SS-01J.pdf Copyright © 2015 IPA, All Rights Reserved ゴールや戦略を議論するとき、その前提とな る情報 詳細化されたゴールを最終的に保障するもの ゴールを保障するための十分な議論もしくは エビデンスがない 未達成 モニタ 解説 システム ログ 運転中のシステムより取得可能なエビデンス 他のシステムのD-Caseへのリンク http://www.dcase.jp/introduction2.html#a2 Software Reliability Enhancement Center 35 CAE (Claims, Arguments and Evidence) クレーム (Claim) サポート 議論 (Argument) サブクレーム (Subclaim) サブクレーム (Subclaim) 証拠 (Evidence) クレーム 正しい又は誤りであ ると評価することが できる議論の中での 主張 それぞれのクレームは、いくつかの サブクレーム、議論、又は証拠でサ ポートされる。 サブクレームは付加的な文脈に関係 する資料、例えば使用される用語や 範囲の説明、を含んでいるかもしれ ない。 議論 クレームを支持して 提示する議論アプ ローチの記述 この要素はオプションであるが、多 くの場合、親クレームを満足するた めのアプローチの説明を含めると良 い。 もしクレームをサポートするアプ ローチが、対象とする読者によって 良く理解されているか、単純であれ ば、単にサポートするクレームから 直接リンクすることが許容される。 証拠 クレーム又は議論を 支持して提示される 証拠への参照 通常、証拠ノードは要約され、そし て証拠を含む関連する外部レポート へリンクします。 http://www.adelard.com/asce/choosing-asce/cae.html Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 36 アシュアランスケースと認証規格 Safety Caseの作成、提出を義務付けている規格 Yellow Book: 鉄道システムの改変時の安全管理 EUROCONTROL: 安全で機能的な航空管制管理 ISO26262: 自動車の電気、電子システムの機能安全規格 Def-Stan 00-56: 英国防衛省策定の防衛システムの安全管理 US. Food and Drug Administration (FDA) Infusion Pump Improvement Initiative: 点滴ポンプなどの医療器具の病院導入時 今後はセーフティだけでなく、セキュリティ等 にも広がる可能性大 CC-Case: http://lab.iisec.ac.jp/~tanaka_lab/images/pdf/kennkyukai/kennkyukai-2013-09.pdf Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 37 認証規格以外の利用 ① 説明責任をはたすため 欧米では説明責任をはたすために、規格として求められるケースもある ② ステークスフォルダーとの情報共有のため マネージャレベルでも、アシュアランスケースから何が設計されているか、理解が可能 ③ 設計の再利用のため 何か設計・実装されているか容易に分かる ④ ソフトウェアの相互の信頼性確認のため つながる世界において、ソフトウェアの相互の信頼性確認のための基礎 • ETロボコンへの応用例： 富士ゼロックス（株） 伊東敦 http://www.jst.go.jp/crest/crest-os/osddeos/event/201211/ET2012C805.pdf • 計画立案時の事例： （株）デンソークリエイト 小林 展英 http://www.jst.go.jp/crest/crest-os/osddeos/event/201402/DEOS_13.pdf • シミュレーションへの適用例： 三菱電機（株） 森 素子 http://deos.or.jp/event/files/ET2014presentation_mitsubishielectric.pdf Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 38 SECの具体的活動内容 Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 39 セーフティ・セキュリティ設計普及と見える化の取り組み WG名：サプライチェーンにおける品質の見える化WG 期間：2014年9月～2015年５月 目的： 設計品質の見える化のためのセーフティとセキュリティ設計の取組みとハザード・ 脅威事例を含めて分かり易く解説するガイドブックの作成とそのプロモーション メンバー：セーフティ or セキュリティの有識者 主査：情報セキュリティ大学院大学 後藤教授 成果物： ガイドブック 2014年 2015年 3Q 10月 4Q 11月 12月 1月 2月 １Q 3月 4月 5月 6月 ガイドブック公開 第1回 9/22 Copyright 第2回 10/20 第3回 11/28 © 2015 IPA, All Rights Reserved ４回 12/22 ５回 2/2 ６回 3/16 7回 4/20 8回 5/21 Software Reliability Enhancement Center 40 ガイドブックとプロモーション << ガイドブックのイメージ >> 見える化手法 対象読者 セーフティ セーフティ＆セキュリティ設計 の品質の見える化 セキュリティ セーフティ＆セキュリティ設計 の普及・促進 PROMOTION = 普及・促進 IPA: INFORMATION-TECHNOLOGY PROMOTION AGENCY, JAPAN Copyright © 2015 IPA, All Rights Reserved Software Reliability Enhancement Center 41