セキュリティ バイ デザインとは ソフトウェアやシステム開発の過程程で開発の早期段階 ( 分析 設計 ) からセキュリティを作りこむ 対義語? セキュアプログラミングプログラミング工程での脆弱性排除 2

Transcription

1 セキュリティ バイ デザインと IoT 時代の脅威分析の意義 情報セキュリティ大学院大学大久保隆夫

2 セキュリティ バイ デザインとは ソフトウェアやシステム開発の過程程で開発の早期段階 ( 分析 設計 ) からセキュリティを作りこむ 対義語? セキュアプログラミングプログラミング工程での脆弱性排除 2

3 Security by Design Principles(OWASP) rinciples アーキテクト ソリューションプロバイダがセキュアなアプリケーションを設計から構築するためのガイダンス 資産の整理 攻撃者に対する知識 情報セキュリティの基本概念 (CIA( 機密性 / 完全性 / 可用性 )) セキュリティアーキテクチャ通常利用と異常時の双方に対応 セキュリティの原則アタックサーフェスの最小化 / デフォルトセキュア / 最小特権 / 多層防御 / セキュアなエラー処理 / サービスを信用しない / 職掌分離 /security by obscurity の回避 / できるだけシンプルな実現 / セキュリティ問題の適切な対処 3

4 セキュリティ バイ デザインの必要性 (1) ソフトウェア システム開発における一般的法則問題解決が後工程になるほど 解決コストが急激に増大 相対修正コスト 要件定義 設計 プログラム 開発 結合テスト 受入テスト 運用 プログラミングやテストで見つかった問題を修正するのには 費用 工数がかかる場合によっては 修正不可能な場合も設計にまで遡らなければならない場合も 4

5 セキュリティ バイ デザインの必要性 (2) 相対修正コスト 要件定義 設計 プログラム 開発 結合テスト 受入テスト 運用 早ければ早いセキュリティ対策ほどコストがかからない! 5

6 セキュリティ バイ デザインの困難さ 必要なこと要求仕様 設計仕様へのセキュリティの組み込み 従来の分析 設計ではなぜ難しいか? 要求 : 他の要求との違い ( 難しさ ) 要求策定者 利害関係者 ( ステークホルダー ) ではない他者 ( 悪意を持つ者 ) の要求に基づく 特定の攻撃に対する対策を考慮した要求が必要 ( になる場合あり ) 設計 : 他の設計との違い ( 難しさ ) 悪意を持つ者 = 攻撃者がどのような手段 ( 攻撃 ) で要求を達成するかを把握 適切な対策仕様を設計 上記は いずれも従来とは異なる知識とその活用手段が必要 6

7 セキュリティ バイ デザインのライフサイクル セキュリティ要求分析 要求の提示 ソフトウェア要求 検収 脅威分析 要求定義 サブシステム システムテスト セキュリティテスト セキュリティ設計 システム設計 プログラム 結合テスト セキュリティテスト 検証 セキュアプログラミング プログラム設計 実装 モジュール 単体テスト プログラミング / デバッグ セキュリティテスト 7

8 NIST special publication Systems Security Engineering システムをセキュアに構築するための技術 ISO/IEC/IEEE に対応 Systems and Software Engineering-- System life cycle processes システム開発のライフサイクルのプロセスを規定 設計問題としてのシステムセキュリティコンピュータシステムを十分にセキュリティの制御ができるかは システム設計の問題である 網羅的セキュリティの実現にはハードウェア ソフトウェア 物理的 人的 管理プロセス的保護が必要である 特に ソフトウェアによる保護だけでは 十分な対策にはならない The Ware Report Defense Science Board Task Force on Computer Security,

9 ISO/IEC/IEEE のプロセス 9

10 脅威分析 10

11 脅威分析とは 対象のソフトウェアやシステムに対する脅威を識別し その影響を評価し 対策を策定する分析 脅威 が 第三者の悪意に基づくため このような ( 通常の開発にはない ) 分析が必要 分析工程における脅威分析 = 論理層対象 = セキュリティ要求工学 設計工程における脅威分析 = 物理層対象 11

12 セキュリティ要求分析 主なアプローチ 1. 攻撃者のゴールベースの分析攻撃者は何を狙っているか? 2. 被害ベースの分析このシステムで何をされると困るか 3. 資産ベースで分析する守るべき対象を明確にして分析 12

13 攻撃者の目標 (1) STIX(Structured Threat Information Expression) version 1.2 の Campaign( 作戦 ) Intended Effect( 意図 ) 参考情報処理推進機構 : 脅威情報構造化記述 STIX 概説 STIX2.0 では Campaign Objective( 目標 ) 13

14 攻撃者の目標 (2) 優位に立つ 盗む 経済的に 軍事的に 政治的に 知的財産 認証情報 識別情報 アカウントのっとり 信用へのダメージ 競争で優位 サービス品質の劣化 否認 欺瞞 破壊 名誉毀損 暴露 恐喝 詐欺 ハラスメント 制御システムの操作 抜け道 認可されていないアクセス 14

15 資産の識別 資産の識別 1. ユースケースの作成 2. ユースケースシナリオから資産候補の抽出 3. 資産候補が攻撃者の目標 or 被害に合致するか検証 資産として抽出 15

16 資産識別の例 (3) 自動ブレーキにおける資産候補 コントローラ ブレーキ ブレーキ信号 衝突可能性情報 16

17 攻撃者の目標とつきあ わせ 資産抽出 ブレーキ + 制御の不正な操作 = 危険! ブレーキは資産として抽出 同時に ブレーキに対する不正操作 を脅威として識別 17

18 更なる脅威抽出 ガイドワードの適用 エンティティへの STRIDE 適用 攻撃者目標を達成するか なりすまし エンティティの改ざん 18

19 ガイドワード候補 STRIDE STAMP/STPA のガイドワード 19

20 STRIDE エントリポイントにおいて脅威を発見するためのヒント 脅威分類 Spoofing( なりすまし ) Tampering( 改竄 ) Repudiation( 否認 ) Information disclosure( 情報の漏洩 ) Denial of service (DoS 攻撃 ) Elevation of privilege( 権限昇格 ) 20

21 STRIDE のガイドワード としての役割 外部エンティティ 0 プロセス 0 データ 0 エンティティ ( 外部エンティティ プトセス データストア ) に対するガイドワード エンティティからの情報漏洩 データフローに対するガイドワード フローからの情報漏洩 21

22 STPA のガイドワード 与えられるとハザード 与えられないとハザード 早すぎる / 遅すぎるとハザード 長すぎる / 短かすぎるとハザード 22

23 STPA のヒントワード 出典 :IPA はじめての STAMP/STPA( 実践編 ) 23

24 セーフティ系ガイドワードを 脅威分析に活かすには STPA のガイドワード : 攻撃者の目標ないし被害事象に直結 No/More の原因になるセキュリティ脅威を導出する ex) 改ざん (T) により Nol(More) 情報漏洩系は非対応 STPA のヒントワード : セーフティ寄りで セキュリティ脅威分析には不向き 24

25 脅威の詳細化 判明している情報のみで詳細化する ブレーキを不正操作 コントローラののっとり 衝突検知信号の改ざん ( なりすまし ) ブレーキ信号のなりすまし 25

26 ミスユースケースによる 脅威 対策記述 のっとり対策 コントローラののっとり ブレーキ信号のなりすまし 運転者 ブレーキを踏む アクター 2 ユースケース 6 <<include>> ブレーキに対する不正操作 衝突を検知する 衝突検知信号の改ざん 不正操作防止対策 対策 センサー 脅威 改ざん防止対策 26

27 論理層のみの 分析で十分か 通常のソフトウェア開発では アーキテクチャの選定は設計時に行う しかし 誤ったアーキテクチャ選択はセキュリティに致命的な ( 対処不可能な ) リスクを生む可能性がある 27

28 組込み系における開発 要求分析 後戻り困難特に H/W 系 システム設計 ハードウェア設計 ソフトウェア設計 ハードウェア実装 ソフトウェア実装 28

29 クリティカルな手戻りの 例 プロセッサバスの選択 要求分析 現行の H/W では AES 暗号化性能, 不足 システム設計 データ保護のため AES 暗号化必要 ハードウェア設計 ソフトウェア設計 ハードウェア実装 ソフトウェア実装 29

30 手戻りを防ぐには 要求分析後 設計前にハードウェア ソフトウェアのアーキテクチャ候補を列挙 それぞれの候補についてリスク評価を行う CVE CWE などの評価を参考 明確な脆弱性がないか データ保護 アクセス制御などを実現可能か 30

31 脅威分析 設計段階においては 資産ベースの分析よりも モデルベースの分析を重視 脅威モデリング セキュリティ要求を侵害しそうな脅威を識別し 対策する アーキテクチャ選択時に 想定済の典型的脅威を利用 31

32 脆弱性分析と 脅威分析 脆弱性分析 = 既存のシステムの脆弱性を調べる 脅威分析 : 通常は原因となる脅威 + リスクについて調査 脅威分析は既存のものが対象の場合と これから開発するものが対象の場合と双方ある どんな弱みがあるかと 弱みをつくどんな脅威があるかを調べるのは質的に異なる作業

33 脅威モデリング 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

34 DFD 外部エンティティ データ 境界 プロセス データストア 出典 :M.Howard et al: Writing Secure Code, Microsoft press 3 4

35 DFD 境界の意味 データ送受信の相手が信頼できるか? を考える 物理的境界を越えてくるデータは信頼できない 外部エンティティから来るデータは信頼できない 信頼できない相手にデータを送るのは危険 エントリポイント : 脅威の起きそうなポイント 境界とデータフローの交点 境界を越えてデータがやりとりされる時に脅威が発生しやすい 信頼できない相手から来たデータ : 改ざんされているかも? 信頼できない相手にデータを送る 流出するかも? 35

36 エントリポイント 出典 :M.Howard et al: Writing Secure Code, Microsoft press 3 6

37 アタックツリー 脅威分析手法の一つ 脅威を Tree 状に詳細化していく 具体的な攻撃手段とその可能性を明確化 対策の糸口 原典 [SCH99] B. Schneier, Attack trees: modeling security threats, Dr. Dobb s Journal, December [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

38 アタックツリー 分析の手順 上位の攻撃を考える その攻撃を実現する手段や条件を下位ノードとして接続 下位ノードが独立である場合 : 線で接続するのみ 下位ノードの組み合わせで上位が実現できる場合 :and 関係で接続 38

39 アタックツリー 分析の手順 金庫を開ける ピッキング ダイアルの組み合わせを知る 金庫を切断 不適切な設置 ダイアルの組み合わせのメモを見つける 持ち主から組み合わせ情報を得る 脅迫詐欺メール盗聴賄賂 and 会話から聞き取る 持ち主に言わせる 39

40 リスク評価と対策 アタックツリーの末端ノード ( 葉 ) の攻撃が起きうるリスクを考える 攻撃の可能性があるか 攻撃にかかるコストはどのくらいか リスクの高い ( 攻撃される可能性が高く コストも低い ) ノードについては対策を考える 40

41 アタックツリーの例 金庫を開ける ピッキング ダイアルの組み合わせを知る 金庫を切断 不適切な設置 ダイアルの組み合わせのメモを見つける 持ち主から組み合わせ情報を得る 脅迫詐欺メール盗聴賄賂 and 会話から聞き取る 持ち主に言わせる 41

42 セキュリティとセーフティ の統合は IoT 組み込み機器 システム開発時における security,safety 双方のリスク分析の統合の可能性を模索 security,safety 双方の既存のリスク評価手法について調査 Security では 発生確率はほとんど用いられないため そのままでの統合は困難 今後 別の統合手法を検討していく 42

43 参考 :STPA-sec STPA のセキュリティ拡張 unsafe control action の他に unsecure control action を想定し分析 セキュリティとセーフティのより複合的な分析については十分ではない セキュリティ脅威 セーフティへの影響 セーフティハザード セキュリティへの影響 43

44 44

45 ヤング氏の焦点はトップレベル = 防衛 脆弱性分析 インパクト分析 脅威分析 情報セキュリティで対象とするのは脅威分析 45

46 46

47 まとめ 組込み IoT システムの安全品質の実現のために必要なセキュリティ バイ デザインと脅威分析について紹介 組込みの場合 従来の機能安全的手法に加え セキュリティも考慮しなければならない セキュリティ セーフティ双方の分析に STPA を用いる可能性について STPA-sec の例を紹介 47

48