エンジニアのための脅威モデリング：実践ガイド

脅威モデリングは、セキュリティ議論でよく使われる用語だが、バズワード以上の理解は稀だ。Soatokによる最近のブログ記事は、エンジニアに優しいストレートな入門書でノイズを断ち切る。元の記事は一般的な技術読者向けだが、核となる教訓はソフトウェアシステムを構築するすべての人、特にインフラ、マイクロサービス、分散アプリケーションに直接適用できる。

脅威モデルが実際に答えるべきこと

最も単純な形では、脅威モデルは7つの質問に答えるべきだ。最初の4つは基本：何を守るのか、誰または何がそれを害そうとするのか、どのように攻撃するのか、そしてそれを防ぐために何をするのか。しかし本当の価値は次の3つにある：資産はどのように接続されているか（リストではなくグラフで考える）、どのような前提を置いているか、そして意図的に扱わない脅威は何か。

あまりに多くのチームが前提のステップを飛ばす。モデルがメッセージごとに1つの有効な鍵だけを想定しているのに（AES-GCMやChaCha20-Poly1305のように）、システムが複数の有効な鍵を導入する場合（例えば不正報告を通じて）、セキュリティ保証を無効化したことになる。Invisible Salamanders攻撃はこの不一致の完璧な例だ。

脅威モデルの構築方法

まず、システムのコンポーネントを紙やホワイトボードにマッピングする。すべての関係を描く：どのサービスが互いに通信するか、何が何に依存するか。次に全体を箱で囲み、各コンポーネントに繰り返しズームインする。各反復で入出力を記録し、7つの質問にできる限り答える。抽象化が許す限り深く掘り下げるまで繰り返す。

このトップダウンアプローチは、不適切な関係を表面化させる——RSSフィードを持つべきでないデータベースや、X25519鍵交換を知る必要のないロードバランサーなど。

良い脅威モデルの姿

よく構成された脅威モデルは、前提を最初に文書化し、次に資産、アクター、リスクをリストする。リスクは分類されるべきだ：設計で防止、緩和（研究者にとって興味深い）、対処可能（オペレーターの注意が必要）、またはオープン（受け入れるリスク）。オープンリスクについて正直であることは重要だ——すべての可能な攻撃に対処することはできない。

Matrixプロトコルの脅威モデルは警告の例だ。前提と緩和策を明確に分離できず、セキュリティ境界が実際にどこにあるのかを推論するのが難しい。

エンジニアのための重要ポイント

• 脅威モデルは生きた文書であり、一度きりの成果物ではない。システムの進化に合わせて更新する。
• 前提を常に明示的に述べる。誤った前提はモデル全体を壊す。
• 関係をリストではなくグラフとしてマッピングする——攻撃者はグラフで考える。
• 保護しないものを文書化する。盲点についての正直さは、誤った自信より優れている。