Chapter 7 1 Processing and Managing Threats yoshioka

(1)

Chapter 7 Processing and Managi

ng Threats

Nobukazu Yoshioka

(2)

７章前半の概要

 脅威分析のプロセスを説明する

 いつ何をやればよいか？どこから始めるか？どうモデルを洗練するか？いつまでやるのか？

 トップダウンな分析 vs. ボトムアップな分析

 信頼境界から始める、図の構成要素から始める、脅威から始める

 脅威に対する軽減、その軽減に対する脅威、そして更なる軽減の繰り返し

 _{軽減の優先付け}

 チームでどうやればよいかに関しては 17 章

(3)

Starting the Threa

t Modeling Project

脅威分析プロジェクトを始める

(4)

脅威分析をいつ始めるか？

 プロジェクトの最初に Threat Model を作るべき

 早い段階で信頼境界 (Trust Boundary) を与えることは、アーキテクチャを改善するのに役立つ

 脅威分析のためのモデル：対象となるシステム、それに対する脅威、開発中に判明したバグリスト

 重要な構成要素に関してまず脅威分析すると、より小さい特定の脅威の分析に集中でき、重要な問題を後で発見することを防ぐことができる

 各構成要素で２回目、３回目の脅威分析を行う

 脅威を防ぐための構成要素や設計要素をバイパスする攻撃も分析

 例）１回目：窓を割って車の盗む脅威 ⇒ ハンドルロック ⇒ ２回目：イグニッションの始動 ⇒ ．．．

 構成要素の脅威分析をしておくとその設計を気をつけるようになる

 脅威を意識するようになり脅威分析のスキル自体も向上

 プロジェクトの最後（出荷前）に再度分析するとよい

 モデルの重要な部分にそれと合わないような変更をしてしまっていないか確認することができる

 関係者に（信頼境界やデータフォローを含む）モデルが妥当であるということを確認・合意してもらえる

 脅威につながるバグがチェックされたことを確認できる

(5)

分析の時間を管理する

どれくらい分析に時間をかければよいのか？

 システムの大きさや複雑さ、関係者がどれくらシステムを知っているかや脅威分析のスキル、組織の文化（やり方）に依存

 合意形成が必要な組織なら時間がかかる

 経験則：経験を持った分析者といっしょにシステムズを書いて、そのコンポーネントに対する脅威を見つけ、もっと脅威を列挙すべきかどうかを判断する時間は１時間程度。

 ちいさなスタートアップのシステムを分析するのには、だいたい数時間程度から１週間程度の脅威分析。但し、機密データを取り扱うものならもっと掛かる。

 大きなオンラインサービスの場合、４人で数ヶ月かかる場合も

(6)

何から始めてどう終えるか？

 ダイアグラムから始めるのがよい

 ダイアグラムを脅威に合わせて変更する。ダイアグラムに基づき抜けや必要ないものを発見する

 ダイアグラムを洗練させるプロセスは、要求を洗練させ、構築が優しいものと難しいものを発見するのと同様

 _{いつ分析を終えるか？}

 バグ（≒軽減したい脆弱性 ,see p.23 ）を記録したとき

 ダイアグラムの大きさに即したバグがあるべき

 ダイアグラムがシステムを表現していると関係者全員が合意できたとき

 もしデータフロー図や STRIDE を使っているならダイアグラムの要素あたり 5 つぐらいの脅威があるはず

参考：もともとの本で示していた脅威数

＝ ( プロセスの数 ×6) + ( データフローの数 ×3) + ( データストアの数 ×3.5) + ( 明確な外部要素数 ×2)

(7)

どこから始めるか？

 資産 (asset) や攻撃から始めより、システム全体をカバー

しているダイアグラムから始めるのが良い

 資産や攻撃から脅威は分析できない (Chapter 2, p39 からを参照 )

 信頼境界 (trust boundary) から分析する

 _{誰と議論すべきか？}

 ソフトウェア、データフロー、（可能ならば）脅威分析にのことを分かっている人たち

 ダイアグラムの構成要素に関連する人たち

 どういう手順で分析するか？

 トップダウンに、そして幅優先で分析

(8)

トップダウン分析

 まず構築したい全体システムの最も高レベルの側面をモデル化すべき

 何が全体なのか？どの構成要素を含めるべきなのか？

 対象となる組織が制御できる要素で構成する

 コンポーネントについて責任が発生する人とレビューする

 ボトムアップな分析はうまくいかない

 構成要素の脅威分析から始めて、一貫したモデルを作るやり方

 議論のために一度やってみることをお勧めする

 システムレベルの側面を作らないで、個々の脅威を組み合わせるのは困難

参考： 2000 年の Microsoft(SDL) はボトプアップアプローチだったがうまくいかなかった。構成要素ごとに担当者が脅威を列挙し、その

後、全体の脅威を作ったが、全体の脅威は優先的に扱われなかった。

(9)

横断的な脅威を見つける

横断的な脅威を見つける３つの方法：

 信頼境界のリストから見つける

 例） foo が信頼境界を超えると何かまずいか？

 高レベルの脅威を見つけやすい

 ダイアグラムの要素リストから見つける

 例）このデータベース、ログファイルで何かまずいことが起きるか？

 多数のチームと連携する時にうまくいく

 脅威のリストから見つける

 例）このダイアグラムでなりすましや改ざんが起こるのはどこ？

 関連する脅威を議論するのに役立つ

※ これらに拘束されなければどの方法でもよい。お勧めは信頼境界から始めて脅威を分類するやり方。

(10)

軽減策 (mitigation) を深堀す



る

軽減策は、多くは新しい構成要素により実施されるが、攻撃者はその意図しない、想定していない使い方を見つけて攻撃する

 _{軽減策は多段になる}

例）家の脅威分析

 まず、攻撃される側面 (Attack Surface) から始めて、すべての１段目の脅威の軽減を考える。そして２段目を分析

 深く多段で分析しているとどこかで分析時間がなくなるので幅優先で分析すべき

順番脅威軽減策

１番窓を割るガラスを強化

２番窓を割るアラーム

３番アラームのワイヤーを切る通電チェック

４番偽の通電チェック信号通電信号を暗号化

(11)

チェスのように分析する

 攻撃と軽減策はお互いが動的に相互に関係しあう

 攻撃者は、もっとも弱い部分を狙う

 _{弱い部分から分析せよ}

 さまざまな実際の攻撃シナリオを知っていると役立つ

 シナリオのレパートリーがなければ、２章のような文献に

あたってみるとよい

 ただし、攻撃者はシナリオ通り攻撃するとは限らない

 攻撃できそうな別な場所を攻撃するかもしれない

 どこを攻撃するかは攻撃者の自由

(12)

熊（攻撃者）から逃げろ！

 幅優先の分析 vs. 多段の分析：どちらが重要？

 _{どちらも重要！}

 分析が不十分なところが狙われる

 多段の分析により攻撃に強いシステムを作れる

 _{熊から逃げる}

 攻撃者は一人でない。たくさんの攻撃者が脆弱性を探している。攻撃ツールも作っている

 攻撃は日に日に自動化されて、大規模化している

 「次のターゲットよりも早く走れ」が、分析を早く済ませる合言葉？