セキュリティ・バイ・デザイン(PDF)

セキュリティ・バイ・デザインのメリット①
セキュリティ・バイ・デザインは開発の早い段階から対処するので、
運用でのセキュリティ対処よりも手戻りが少なく納期を守れる。
運用時のセキュリティ
セキュリティ・
バイ・デザイン
コスト削減
100
運用でのセ
キュリティ
対処
100倍
対策コストは
設計時のセキュリティ
対策コストを1とすると
競争力強化
1
設計
6.5
開発
15
テスト
コスト大
運用
1
Copyright © 2016 IPA, All Rights Reserved
Software Reliability Enhancement Center
セキュリティ・バイ・デザインのメリット②
米国ではTREAD法によりタイヤ空気圧監視システム
TPMS (Tire Pressure Monitoring Systems)の)装着
が2007年から完全義務化。
・南カリフォルニア大とラトガーズ大は、TPMSのプロト
コル解析に成功、近傍の車両の無線通信と区別するため、車輪毎に
32bitの固有IDが割当てられていることを発見。
・車輪IDを読み出すことで、車両を追跡したり、誤った
情報の送信により誤った警告灯の表示が可能。
攻撃ツールの開発に要した原価は$1,500程度。
セーフティの観点から設計すると車輪毎の固有ID付与は妥当だが、
セキュリティの観点からは車両の追跡や誤った警告灯の表示という脅威を生む。
問題の解決には、統合的観点でのセキュリティ・バイ・デザインが必要
設計思想の転換
Copyright © 2016 IPA, All Rights Reserved
2
Software Reliability Enhancement Center
セキュリティの課題
• 現行のセキュリティ対策は、運用段階でのインシデントに対するコーディング段
階から修正対応や脆弱性検査による検証が中心。これらはセキュリティ上のバグ
修正と本質的に同じ。
• セキュリティ仕様はコーディング段階からでは対応できず、企画・要件定義段階
からの早期対応が必要(→セキュリティ・バイ・デザイン)
セキュリティ・バイ・デザイン
開発工程
技術施策
企画・
要件定義
設計
脅威分析
セキュリティ仕様
現行のセキュリティ対策
実装
セキュア
コーディング
検証・評価
脆弱性検査
保守・運用
インシデント
対応
3
Copyright © 2016 IPA, All Rights Reserved
Software Reliability Enhancement Center
設計段階での対処と運用段階での対処
設計段階での対処
VS
(セキュリティ・バイ・デザイン)
製品・システム自体のもつ脆弱性を生まないように
リスクを想定して事前に対策をする。
脆弱性
実際の攻撃
脆弱性
運用段階での対処
(セキュリティ・バイ・オペレーション)
攻撃者は製品システムの脆弱性を狙って攻撃する。
→受けた攻撃に対して対策をする
攻撃手段
脆弱性
企画・要件段階からのリスク検討と対策
• 事前に想定したリスクに対して対策となる設計をする。
• 幾つかの手法があるが基準も手法も確立されてはい
ない。
• ITシステムでも対応は不十分。ましてIoTはこれから
検討し、確立していく状態であり、未知のものが多い。
Copyright © 2016 IPA, All Rights Reserved
運用段階で実施されるセキュリティ対策
• 攻撃がなされている中で特定の攻撃手段に着
目して攻撃を可視化し、対処する。
• 現在はこちらが主流。
4
Software Reliability Enhancement Center
セキュリティ・バイ・デザインの価値と実現方法
Why
安全 コスト 利便性の併立
• 解決したいビジネス
課題上の価値
難しい
計画的なセキュリティの作りこみで実現可能!
• セーフティも併せて確保することによる安全性向上
• 早期段階対応で手戻りコストを削減
• 運用時のユーザニーズを反映することによる利便性向上
What
• セーフティとセキュリティを
早期段階からライフサイ
クルを通じて考慮
企画・
要件定義
How
設計
機能要件
リスク分析
• セーフティとセキュリティを
共に実現する技術
開発方法 (脅威・ハザード)
説明責任 アシュアランスケース
トレーサビリティ技法
Copyright © 2016 IPA, All Rights Reserved
実装
セキュア
コーディング
検証・評価
脆弱性検査
保守・運用
インシデント対応
5
Software Reliability Enhancement Center
リスク分析
• 対象のシステムやソフトウェアに特有な脅威やハザードを識別し、
その影響を評価し対策を策定
• IoTセキュリティは生命・健康への影響が大きいにも関わらず、知
見が蓄積されていないため、未知の脅威の洗い出しが重要。
• セキュリティ上の脅威もセーフティ上のハザードも実施プロセスは
類似しており、どちらも分析結果を仕様に反映しつつ設計を実施
脅威分析の手順
6
Copyright © 2016 IPA, All Rights Reserved
Software Reliability Enhancement Center
セーフティ設計とセキュリティ設計のすり合わせ
• 早期の段階でセーフティ設計とセキュリティ設計のすり合わせ
すれば、手戻りが少ない。
7
Copyright © 2016 IPA, All Rights Reserved
Software Reliability Enhancement Center
機能要件と作りこみ
• IoTは絶えずリスクが変化するため、イテレーションを回して必要なセキュリ
ティ等の機能要件を随時作りこめる開発方法が適している。(ウオーターフォール型か
らの脱却)
運用の対策
開
始
予
防
検
出
回
復
終
了
企画・要件定義
システム設計
リスク
分析
(脅威・
ハザード)
ハードウェア設計
開始時の
機能要件
システムテスト
予防時の
機能要件
検出時の
機能要件
回復時の
機能要件
終了時の
機能要件
(例)検出
された脆
弱性
ハードウェアテスト
ソフトウェア設計
ソフトウェアテスト
実装
Copyright © 2016 IPA, All Rights Reserved
運用の対策において
必要となる機能を設計時に作りこむ。
*発見された脆弱性へ対処する。
8
Software Reliability Enhancement Center
セキュリティ・バイ・デザインの開発プロセス
・各段階において、セキュリティリスク分析と脆弱性を生まない設計を実施する。
セキュリティの基本方針
コンセプ
ト
段階
実施事項
実施内容例
コンセプト
製品・システムのセ
キュリティ要件を定
義
• 製品・システムに対する脅威の洗い出し。
例)屋内のHEMSコンロトーラの脅威として、ウイルス
感染。監視カメラの脅威として、個人情報の流出(画
像)
システム
アーキテクチャレベル
の設計
•
コンポーネン
ト
ソフトウェア設計・実
装
• 新規と既存の脆弱性への対応
例)セキュアコーディング/脆弱性診断
ハードウェア設計・実
装
• 物理的なセキュリティ設計・実装
例)耐タンパ性設計等
要件レベル
システムレベル
ソフトウェア
ハードウェア/
レベル
他社
システム
システム
ネットワーク
他社
システム
ハードウェア ソフトウェア
脅威に対して実施するセキュリティ対策をシステム、
ネットワーク等のどこで実施するのかを設計。
例)不正利用に対して、ユーザ認証方式を設計。無
線ネットワークの盗聴・改ざん対策として暗号化方式を
規定
9
Copyright © 2016 IPA, All Rights Reserved
Software Reliability Enhancement Center
アシュアランスケース
• アシュアランスケースは対象となる機器やシステムについて
なぜその設計で目標が達成されるかを事実に基づき,論理的
かつ第三者でも容易に理解できる表記で説明する手法
設計品質のロジカルな説明ができる
分析
設計
説明
評価
設計品質
の見える化
設計品質の説明、共有、
過去の設計の理解
アシュアランス(Assurance:保証)+ ケース(Case:論拠)
• IoTの対象となる航空,鉄道,軍事,自動車,医療機器の分野の複数の安
全性規格やガイドラインで要求され,欧州を中心に広く利用されている
10
Copyright © 2016 IPA, All Rights Reserved
Software Reliability Enhancement Center
IoTに適した具体的手法例
• IT産業に比べ、IoT製品を扱うモノづくり業界は既にセーフティ技術
をもっているため、セーフティとセキュリティを共に実現する技術が
適している。
リスク分析
STAMP/STPA
• IoT時代のシステムに適し
た未知の脅威やハザード、
利用者品質も含めた
安全・安心のための手法
アシュアランスケース
機能要件
IoT高信頼化機能要件
• セキュリティ機能要件や
セーフティ/リライアビリティ
機能要件を「開発指針」の
テクニカルレファレンスとして
検討中
• セキュリティ版の
• セキュリティ機能要件は
STPA-SECも公開されたため ITセキュリティ基準である
セーフティとセキュリティの コモンクライテリア(CC)に
詳細定義とツールボックスあり
リスク洗い出しが可能
CC-Case
• アシュアランスケースの
代表的表記法GSNでIoT基準・
要件に則った保証を見える化
• 顧客への説明責任、設計の
トレーサビリティ技法、セーフティ・
セキュリティのすり合わせ手法として
利用可能
11
Copyright © 2016 IPA, All Rights Reserved
Software Reliability Enhancement Center
IoT人材育成
• IoTの人材育成は従来の組込みソフトウェア技術に加え、企画・要件
定義・設計段階からのセキュリティ開発技術の習得が不可欠である。
SECで提供可能と考えられる
セキュリティ・バイ・デザインに必要な項目
モノづくり
業界
自動車
(OEM)産業
に必要性が
高い項目*
その他必要項目
リスク分析*
(STAMP/STPA、STPA-SEC)
ネットワークセキュリティ
要件の見える化・保証*
(アシュアランスケース)
セキュリティインシデント対応
セーフティセキュリティ
プロセス・規格*
アジャイル開発
IoT高信頼化要件
IoTを対象したシステムズ
エンジニアリング
ビッグデータ、AI
クラウドコンピューティング
組込み開発技法
12
Copyright © 2016 IPA, All Rights Reserved
Software Reliability Enhancement Center