ウェブアプリケーションセキュリティ 第2版

第24章. 脅威モデリングの応用

この作品はAIを使って翻訳されている。ご意見、ご感想をお待ちしている：[e-mail]

脅威モデリング（ ）は、アプリケーションのセキュリティ態勢を改善するための貴重なメソッドで ある。不適切な実装や性急な実装では、脅威モデリング演習はチェックボックスをチェックするだけで、貴重な時間を浪費する。

脅威モデリングが適切に実装されていれば、ソフトウエアエンジニアとセキュリ ティエンジニアは、結束した方法で協働することができる。脅威モデリングが適切に実装された結果、エンジニアリングとセキュ リティのワークフローが共有され、企業は脅威（潜在的な脆弱性など）、脅威要因（潜在的なハッカーな ど）、既存の緩和策（セキュリティ管理策など）、脅威と緩和策の間のデルタを特定できる。

よく実装された脅威モデリングプロセスは、前述の利点に加えて、セキュリティ知識を迅速か つ効果的に技術者から別の技術者に引き継ぐための生きた文書となる。他のほとんどのメソッドでは不可能な方法で、組織のセキュリティ知識に堅牢性が実装される。

急ごしらえで実装した脅威モデリングプロセスを活用することは避けたいが、堅牢性の高い脅威モデリングワークフローを設計し実装する方法を学ぶことは、長期的には組織のセキュリティ体制を劇的に改善することになる。

効果的な脅威モデルを設計する

適切な脅威モデルは、多くの目標を達成できるはずである。これらの目標がすべて達成されなければ、脅威モデルの影響は限定的なものとなる：

• 知識を文書化する

• 脅威の主体を特定する

• リスク（攻撃ベクトル）を特定する

• 緩和策を特定する

• リスクと緩和策のデルタを特定する

これらの主要な目標は、それぞれ他の目標の上に構築される。例えば、生きた知識リポジトリとしての脅威モデリングは、アプリケーションのアーキテクチャに関して選択された データだけでなく、脅威の主体や潜在的な脅威等も含んでいる場合に、最も価値がある。

同様に、リスクの特定のみを行い、緩和策を文書化していない脅威モデリングは、リスク が実行可能でないため、望ましくない。リスクは何らかの価値があるにもかかわらず、既存の緩和策が判明するまでは実行不可能である。すでに緩和策があるリスクに対して緩和策を実装することは、バグや技術的負債を増やし、コードベースにさらに脆弱性を追加する可能性さえある。

例による脅威モデリング

架空の企業メガバンクが、ユーザがメガバンクの既存機能をレビューできる新機能を実装したとする。これは、メガバンクがどの機能が好評であるかを判断するのに役立ち、またそれらの機能を他のユーザに宣伝することにもなる。

この機能は一般に公開され、適切に実装されなければ悪用される可能性があるため、メガバンクはアプリケーションセキュリティチームに、開発者と協力して脅威モデルを開発するよう依頼した。メガバンクのセキュリティ・チームのシニア・メンバーであるホリー・ハッカーは、この取り組みに価値を見いだし、脅威モデルの目標を知っているため、開発チームと協力して脅威モデルを作成するためのデータ収集を開始した。

ロジック・デザイン

ホリーが収集する最初のデータは単純である。彼女は、論理設計の観点から新機能の説明を要求する。ソフトウェア製品の場合、論理設計とは、機能の観点から見た機能や製品の説明を指す。この視点は、エンジニアリングアーキテクチャや設計書よりも高いレベルであるが、マーケティングや販売説明書よりも低いレベルである。通常、この記述の詳細レベルは、UXデザイナーが使用するものと同じである。UXデザイナーは、効果的なUIを開発できるようになる前に、アプリケーションのロジックを理解しなければならない。 ...