脅威モデリング

OWASP の Threat Modeling Cheat Sheet を取得して読み、 理解した内容を自分の言葉で書いたもの。

4つの問い

Threat Modeling Manifesto が挙げている、答えるべき問い。

1. 何を作っているのか
2. 何がうまくいかなくなりうるか
3. それに対して何をするのか
4. 十分にやれたと言えるか

4番目があるのが要点。 やって終わりではなく、やれたかどうかを確かめる。

いつやるか

SDLC の早い段階、設計フェーズで行う。 そして一度きりではなく、継続して手を入れるもの。

これは OWASP Top 10 の A06(Insecure Design)に直接効く。 実装の不備は後から直せるが、設計が安全でないものは後から直せない

原則の 「左への移動」— 早く見つけるほど安い — と同じ話。

手順

1. システムをモデル化する

データフロー図(DFD)などで、次を図にする。

信頼境界
データの流れ
プロセス
外部エンティティ

信頼境界を引くことが本体。 どこからどこへ、信頼できないデータが渡るのかを可視化する。

ツールとして OWASP Threat Dragon、Microsoft Threat Modeling Tool、draw.io が挙がっている。

2. 脅威を洗い出す

STRIDE が代表的な枠組み。6つの分類はそれぞれ、破られるセキュリティ属性に対応している。

分類脅威破られるもの
Spoofingなりすまし認証
Tampering改ざん完全性
Repudiation否認否認防止
Information Disclosure情報漏洩機密性
Denial of Serviceサービス妨害可用性
Elevation of Privileges権限昇格認可

他に LINDDUN、PASTA、OCTAVE、VAST が文脈に応じて使える。

3. リスクを順位づける

起こりやすさと影響で並べる。ありうる かつ 損害が大きいものに集中する。

4. 脅威ごとに対応を決める

選択肢は4つ。全部を緩和しようとしない。

対応内容
Mitigate(緩和)起こりやすさを下げる
Eliminate(除去)リスクのある機能そのものを削る
Transfer(移転)責任を移す
Accept(受容)認識したうえで進む

Eliminate が選択肢に入っているのが重要。 設計の「ユーティリティのツールを作るかどうか」や 廃止の「最善の修正がコードの削除であることも実際にある」と同じ発想。

5. 見直して検証する

モデルは正確か
脅威の洗い出しは網羅できているか
緩和策は実現可能か
対策はテストできるか

最後の「テストできるか」がテストにつながる。 壊れてほしくないものを全部テストする対象に、セキュリティも入っている。

関連