脅威モデリングのプロセス

Harnessで使用している脅威モデリングプロセスの概要、その課題、利点、およびプロセス内のステップの概要を説明します。

脅威モデリングはセキュリティーライフサイクルの重要な部分になりつつありますが、Harnessではソフトウェアデリバリーライフサイクル（SDLC）に脅威モデリングを組み込むプロセスにも取り組んでいます。このブログでは、Harnessが使用している脅威モデリングプロセスの概要、その課題、利点、およびプロセス内のステップの概要を説明します。

脅威モデリングとは

脅威モデリングは、セキュリティーのニーズを特定し、脅威と脆弱性を特定し、その重大度を評価し、解決策の優先順位を付けるプロセスです。

OWASP（The Open Worldwide Application Security Project）が定義しているように、脅威モデリングは、価値のあるものを保護するという観点から、脅威と軽減策を特定、伝達、理解するために機能します。

脅威モデルは、アプリケーションのセキュリティーに影響を与える全ての情報を構造化して表現したものです。本質的にはアプリケーションとその環境をセキュリティーというレンズを通して見たものです。

脅威モデリングは、ソフトウェア、アプリケーション、システム、ネットワーク、分散システム、IoTデバイス、ビジネスプロセスなど幅広く適用できます。

脅威モデリングでは、防御側の視点ではなく、潜在的な攻撃者の視点からシステムを検討します。脅威モデリングをSDLCの中核コンポーネントにすることで、製品のセキュリティーを向上させることができます。

脅威モデルの利点

目に見えない脆弱性にパッチを適用することはできませんし、来るかどうか分からない攻撃に対して防御することもできません。ただし、大まかに言えば、これらは脅威モデリングで実際に対処できる問題です。これにより、攻撃に対する既存のアーキテクチャーの強化と技術エコシステムへの新しいセキュリティー追加の評価の両方を行う標準化された手段がセキュリティーチームに提供されるため、組織のセキュリティー体制が全体的に強化されます。

脅威モデリングの主な利点は、コードを1行も書かずに設計上の欠陥に対処できるため、後から再設計してコード内のセキュリティー問題を修正する必要が減り、コスト、時間、リソースが節約できることです。これは全員が参加するディスカッションであるため、開発者、アーキテクト、セキュリティー専門家、ビジネス関係者間のコラボレーションを強化するのに役立ちます。この実践は、組織がSDLCにセキュリティー最優先のアプローチを組み込むのに役立ちます。これにより、コンプライアンスと規制要件に向けて一歩ずつ前進できます。

導入後に脅威モデルを実施することにも価値があります。現在のデプロイの問題を理解することで、将来のセキュリティーアーキテクチャー戦略のベストプラクティスが得られます。弱点を監視することで、より迅速かつ効果的な修復も可能になります。

脅威モデルの作成責任者は誰か

セキュリティーアーキテクト、開発者、テスター、DevOpsチームを含むチーム全体が、脅威モデルの開発において重要な役割を果たします。

• まず、チーム全体で脅威モデリング演習中にシステム／ソフトウェアに該当する脅威を特定し、脅威モデルレポートを公開
• 次に、開発チームが脅威モデルを使用して制御を実装し、安全なコードを作成
• テストチームが、脅威モデルを使用してセキュリティーテストケースを生成するだけでなく、脅威モデルで特定された脅威を軽減するために必要なコントロールを検証
• 運用チームが脅威モデルを使用してソフトウェアを安全に構成し、全てのエントリーポイントに必要な保護制御を導入

脅威モデルの課題

脅威モデリングの利点は多岐にわたりますが、いくつかの課題も伴います。最も一般的なものは次の通りです。

• 設計段階からセキュリティーチームが関与するため、時間がかかるプロセスになる可能性がある
• 脅威モデリングの全ての要件に対応するには、かなり成熟したSDLCが必要
• 脅威を正しくモデル化し、脆弱性に対処するための従業員のトレーニングが必要

脅威モデリングの手順

脅威モデリングのプロセスには、大きく5つの重要なステップが含まれます

1. セキュリティー目標を特定して定義する
2. アプリケーションを分析して分解する
3. 潜在的な脅威を特定してランク付けする
4. 対策と緩和戦略を確立する
5. 包括的な脅威モデリングレポートを生成する

ステップ1：セキュリティー目標を特定する

セキュリティー目標は、アプリケーションの機密性、完全性、可用性に関連する目標と制約です。次のものが含まれます。

• 機密性：不正な情報変更に対する保護
• 完全性：不正な情報変更の防止
• 可用性：攻撃を受けているときでも必要なサービスを提供

ステップ2：アプリケーションを分解する

脅威モデリングプロセスの第2のステップは、アプリケーションを分解すること、つまりアプリケーションとアプリケーションが外部エンティティーとどのように相互作用するかを基本的に理解することに関係します。以下が含まれます。

• ユースケースの特定、アプリケーションのエントリーポイントと信頼レベルの定義
• アクター、資産、サービス、役割、データソースの特定
• データフローダイアグラム（DFD）を使用して、データの移動（転送中または保存中）を文書化。既存の変更だけでなく提案された変更も含めて、信頼境界を表示
• 攻撃者が興味を持ちそうな領域の特定

この情報は、生成される脅威モデル文書に文書化されます。アプリケーションのDFDを生成するためにも使用されます。DFDは、システム内のさまざまなユーザーパスを示し、アクセス権限の境界を強調表示します。

ステップ3：脅威を特定してランク付けする

評価のターゲット内に存在する可能性のある攻撃者または脅威エージェントを特定します。手段、動機、機会を使用して、攻撃者によってもたらされる脅威を理解します。次に、脅威エージェントを、直接対話できるシステムコンポーネントに関連付けます。次の方法で脅威エージェントの数を最小限に抑えるよう取り組んでください。

• 同等のクラスとして扱う
• 可能性を評価する際に攻撃者の動機を考慮する
• 内部関係者の脅威を考慮する

以下のサブセクションがあります。

• 脅威の分類
• ストライド
• 脅威分析
• 脅威のランキング
• 恐怖
• 定性的リスクモデル

ステップ4：対策と緩和策を決定する

リスク所有者を特定し、リスクオーナーおよびステークホルダーとリスクの軽減について合意します。コードのアップグレードや構成の更新という形で必要な制御を提供し、リスクを許容可能なレベルまで低減します。

リスク軽減戦略には、脅威がもたらすビジネスへの影響から脅威を評価することが含まれる場合があります。考えられる影響が特定されたら、リスクに対処するためのオプションは次の通りです。

• 受け入れる：ビジネスへの影響が許容できると判断
• 削除：脆弱性を可能にするコンポーネントの削除
• 軽減：リスクの影響またはその発生の可能性を軽減するチェックまたは制御の追加

ステップ5：脅威モデリングレポートを作成する

このステップでは、各ビジネス/機能の所有者と共有できる詳細な脅威モデリングレポートを作成します。

レポートには、特定されたリスク、リスクスコア、緩和戦略、影響、脅威のターゲットなどに関する詳細情報を含めることができます。また、各脅威に対処するために問題追跡システムで作成されたバグの追跡参照を含めることもできます。

結論

これは、脅威モデリングプロセスに関与する主要な側面、重要性、参加者の簡潔な概要を提供します。このトピックに関するブログ投稿の次のパート2では、各ステップをさらに詳しく掘り下げ、このプロセスの一部を達成するためにHarnessがどのように支援できるかを検討していきます。

この記事はHarness社のウェブサイトで公開されているものをDigital Stacksが日本語に訳したものです。無断複製を禁じます。原文はこちらです。