セキュリティ・バイ・デザインと
IoT時代の脅威分析の意義
情報セキュリティ大学院大学 大久保 隆夫
セキュリティ・バイ・デザインとは ソフトウェアやシステム開発の過程程で 開発の早期段階(分析、設計)からセキュリ ティを作りこむ 対義語？ セキュアプログラミング プログラミング工程での脆弱性排除
Security by Design
Principles(OWASP)
https://www.owasp.org/index.php/Security_by_Design_P rinciples アーキテクト、ソリューションプロバイダがセキュアなアプリ ケーションを設計から構築するためのガイダンス 資産の整理 攻撃者に対する知識 情報セキュリティの基本概念(CIA(機密性/完全性/可用性)) セキュリティアーキテクチャ 通常利用と異常時の双方に対応 セキュリティの原則 アタックサーフェスの最小化/デフォルトセキュア/最小特権/多層防御/ セキュアなエラー処理/サービスを信用しない/職掌分離/security by obscurityの回避/できるだけシンプルな実現/セキュリティ問題の適切 な対処 3セキュリティ・バイ・デザイン の必要性(1) ソフトウェア、システム開発における一般的法則 問題解決が後工程になるほど、解決コストが急激に増大 プログラミングやテストで見つかった問題を修正するのには、費用、工数 要件定義 設計 プログラム 開発 結合 テスト 受入 テスト 運用 相対修正コスト
セキュリティ・バイ・デザイン の必要性(2) 要件定義 設計 プログラム 開発 結合 テスト 受入 テスト 運用 相対修正コスト 早ければ早いセキュリティ対策ほど コストがかからない！ 5
セキュリティ・バイ・デザインの困 難さ 必要なこと 要求仕様、設計仕様へのセキュリティの組み込み 従来の分析、設計ではなぜ難しいか？ 要求:他の要求との違い(難しさ) 要求策定者、利害関係者(ステークホルダー)ではない他者(悪意を持つ者)の 要求に基づく 特定の攻撃に対する対策を考慮した要求が必要(になる場合あり) 設計:他の設計との違い(難しさ) 悪意を持つ者=攻撃者がどのような手段(攻撃)で要求を達成するかを把握 適切な対策仕様を設計 上記は、いずれも従来とは異なる知識とその活用手段が必要
セキュリティ・バイ・デザインの ライフサイクル 検収 システムテスト 要求定義 システム設計 プログラム設計 ソフトウェア要求 サブシステム プログラム モジュール 要求の提示 結合テスト 単体テスト プログラミング/デバッグ 実装 セキュリティ 要求分析 脅威分析 セキュリティ 設計 検証 セキュアプロ グラミング セキュリティ テスト セキュリティ テスト セキュリティ テスト 7
NIST special publication 800-160 Systems Security Engineering
システムをセキュアに構築するための技術 ISO/IEC/IEEE 15288に対応
Systems and Software Engineering-- System life cycle processes システム開発のライフサイクルのプロセスを規定 設計問題としてのシステムセキュリティ コンピュータシステムを十分にセキュリティの制御ができるかは、システム設計の問題である。 網羅的セキュリティの実現にはハードウェア、ソフトウェア、物理的、人的、管理プロセス的保護 が必要である。特に、ソフトウェアによる保護だけでは、十分な対策にはならない。
‐‐ The Ware Report Defense Science Board Task Force on Computer Security, 1970.
ISO/IEC/IEEE 15288
のプロセス
脅威分析とは
対象のソフトウェアやシステムに対する脅威 を識別し、その影響を評価し、対策を策定す る分析 「脅威」が、第三者の悪意に基づくため、この ような(通常の開発にはない)分析が必要 分析工程における脅威分析=論理層対象 =セキュリティ要求工学 設計工程における脅威分析=物理層対象 11セキュリティ要求分析
主なアプローチ 1. 攻撃者のゴールベースの分析 攻撃者は何を狙っているか？ 2. 被害ベースの分析 このシステムで何をされると困るか 3. 資産ベースで分析する 守るべき対象を明確にして分析攻撃者の目標(1)
STIX(Structured Threat Information Expression) version 1.2のCampaign(作戦)→Intended Effect(意図)参考
情報処理推進機構:脅威情報構造化記述STIX概説
https://www.ipa.go.jp/security/vuln/STIX.html
※STIX2.0では、Campaign→Objective(目標)
https://oasis-open.github.io/cti-documentation/stix/intro
攻撃者の目標(2)
優位に立つ 経済的に 軍事的に 政治的に 盗む 知的財産 認証情報 識別情報 アカウントのっとり 信用へのダメージ 競争で優位 サービス品質の劣化 否認、欺瞞 破壊 名誉毀損 暴露 恐喝 詐欺 ハラスメント 制御システムの操作 抜け道 認可されていないアクセス資産の識別
資産の識別 1. ユースケースの作成 2. ユースケースシナリオから資産候補の抽出 3. 資産候補が攻撃者の目標or被害に合致す るか検証→資産として抽出 15資産識別の例(3)
自動ブレーキにおける資産候補 コントローラ ブレーキ ブレーキ信号 衝突可能性情報攻撃者の目標とつきあ
わせ→資産抽出
ブレーキ+制御の不正な操作 =危険！ ブレーキは資産として抽出 同時に、「ブレーキに対する不正操作」を脅威 として識別 17更なる脅威抽出
ガイドワードの適用 エンティティへのSTRIDE適用→攻撃者目標 を達成するか なりすまし エンティティの改ざんガイドワード候補
STRIDE
STAMP/STPAのガイドワード
STRIDE
エントリポイントにおいて脅威を発見するための ヒント、脅威分類 Spoofing(なりすまし) Tampering(改竄) Repudiation(否認) Information disclosure(情報の漏洩) Denial of service (DoS攻撃)STRIDEのガイドワード
としての役割
21 外部エンティティ0 プロセス0 データ0 エンティティ (外部エンティ ティ、プトセス、 データストア) に対するガイド ワード データフローに 対するガイド ワード エンティティからの情報漏洩 フローからの情報漏洩STPAのガイドワード
与えられるとハザード 与えられないとハザード
早すぎる/遅すぎるとハザード 長すぎる/短かすぎるとハザード
STPAのヒントワード
23
セーフティ系ガイドワードを
脅威分析に活かすには
STPAのガイドワード:攻撃者の目標ないし被 害事象に直結 No/More…の原因になるセキュリティ脅威を導出 する ex)改ざん(T)により、Nol(More) 情報漏洩系は非対応 STPAのヒントワード:セーフティ寄りで、セ キュリティ脅威分析には不向き脅威の詳細化
判明している情報のみで詳細化する 25 ブレーキを不正操作 コントローラののっと り 衝突検知信号の改 ざん(なりすまし) ブレーキ信号のなり すましミスユースケースによる
脅威、対策記述
運転者 センサー ブレーキを踏 む 衝突を検知す る <<include>> アクター2 ブレーキに対 する不正操作 不正操作防止 対策 ブレーキ信号 のなりすまし コントローラ ののっとり ユースケース 6 衝突検知信号 の改ざん のっとり対策 対策論理層のみの
分析で十分か
通常のソフトウェア開発では、アーキテクチャ の選定は設計時に行う しかし、誤ったアーキテクチャ選択はセキュリ ティに致命的な(対処不可能な)リスクを生む 可能性がある 27組込み系における開発
要求分析 システム設計 ハードウェア設計 ソフトウェア設計 ハードウェア実装 ソフトウェア実装×
後戻り困難 特にH/W系クリティカルな手戻りの
例
29 要求分析 システム設計 ハードウェア設計 ソフトウェア設計 ハードウェア実装 ソフトウェア実装 プロセッサ バスの選択 データ保護のた めAES暗号化 必要 現行のH/Wでは AES暗号化性能, 不足手戻りを防ぐには
要求分析後、設計前にハードウェア、ソフト ウェアのアーキテクチャ候補を列挙 それぞれの候補についてリスク評価を行う CVE、CWEなどの評価を参考 明確な脆弱性がないか データ保護、アクセス制御などを実現可能か脅威分析
設計段階においては、資産ベースの分析より も、モデルベースの分析を重視 脅威モデリング セキュリティ要求を侵害しそうな脅威を識別し、 対策する アーキテクチャ選択時に、想定済の典型的脅 威を利用 31脆弱性分析と
脅威分析
脆弱性分析=既存のシステムの脆弱性を調 べる 脅威分析:通常は原因となる脅威+リスクにつ いて調査 脅威分析は既存のものが対象の場合と、これか ら開発するものが対象の場合と双方ある どんな弱みがあるかと、弱みをつくどんな脅 威があるかを調べるのは質的に異なる作業脅威モデリング
Microsoftが考案した脅威分析手法
脅威分析の中では一般に最もよく使われている
設計したシステムにおける脅威分析(脅威の抽出、評価)を行う手法
Data Flow Diagram(DFD)を用いた脅威抽出 STRIDEによる脅威発見
アタックツリー等による脅威のリスク評価
アーキテクチャが明確なとき、脅威抽出の手法としては有効 参考書
[HL04]M.Howard, D.LeBlanc: WRITING SECURE CODE, Microsoft press,2004.
[Swiderski05] Swiderski, F. and Snyder, W. : 脅威モデル ― セキュアなア プリケーション構築, 日経BPソフトプレス (2005).
[Sho14] A.Shostack: Threat Modeling , Wiley (2014).
3 3
DFD
外部エンティティデータ
境界
DFD
境界の意味
データ送受信の相手が信頼できるか？を考える 物理的境界を越えてくるデータは信頼できない 外部エンティティから来るデータは信頼できない 信頼できない相手にデータを送るのは危険 エントリポイント:脅威の起きそうなポイント 境界とデータフローの交点 境界を越えてデータがやりとりされる時に脅威が発生しや すい 信頼できない相手から来たデータ:改ざんされているか も？ 信頼できない相手にデータを送る→流出するかも？ 35アタックツリー
脅威分析手法の一つ 脅威をTree状に詳細化していく 具体的な攻撃手段とその可能性を明確化 ⇒対策の糸口 原典 [SCH99] B. Schneier, “Attack trees: modeling security threats,” Dr. Dobb’s Journal, December 1999.
[MEL01] B A. P. Moore, R. J. Ellison, and R. C. Linger, “Attack modeling for information security and
survivability,” CMU/SEI-2001-TN-001, March 2001.
アタックツリー
分析の手順
上位の攻撃を考える その攻撃を実現する手段や条件を下位ノード として接続 下位ノードが独立である場合:線で接続するのみ 下位ノードの組み合わせで上位が実現できる場 合:and関係で接続アタックツリー
分析の手順
39 金庫を開ける ピッキング ダイアルの組み 合わせを知る 金庫を切断 不適切な設置 ダイアルの組み合わ せのメモを見つける 持ち主から組み合わ せ情報を得る 脅迫 詐欺メール 盗聴 賄賂 会話から聞き取る 持ち主に言わせる andリスク評価と対策
アタックツリーの末端ノード(葉)の攻撃が起き うるリスクを考える 攻撃の可能性があるか 攻撃にかかるコストはどのくらいか リスクの高い(攻撃される可能性が高く、コス トも低い)ノードについては対策を考えるアタックツリーの例
41 金庫を開ける ピッキング ダイアルの組み 合わせを知る 金庫を切断 不適切な設置 ダイアルの組み合わ せのメモを見つける 持ち主から組み合わ せ情報を得る 脅迫 詐欺メール 盗聴 賄賂 会話から聞き取る 持ち主に言わせる andセキュリティとセーフティ
の統合は
IoT、組み込み機器、システム開発時におけ るsecurity,safety双方のリスク分析の統合の 可能性を模索 security,safety双方の既存のリスク評価手法 について調査 Securityでは、発生確率はほとんど用いられ ないため、そのままでの統合は困難 今後、別の統合手法を検討していく参考:STPA-sec
STPAのセキュリティ拡張
unsafe control actionの他にunsecure control actionを想定し分析 セキュリティとセーフティのより複合的な分析 については十分ではない セキュリティ脅威→セーフティへの影響 セーフティハザード→セキュリティへの影響 43
45 脆弱性分析 脅威分析 インパクト分析 ヤング氏の焦点はトップレベル＝防衛 情報セキュリティで対象とするのは脅威分析
