脅威モデリングのアプローチ方法

このブログでは、脅威モデリングを組織のアプリケーション開発ライフサイクルに統合する方法のヒントを紹介します。脅威モデリングを実行する方法の手順については、多くの優れたガイドがあります。ここでは、そのガイドと方法論について簡単に説明します。

ただし、このブログの主な目的は、脅威モデリングのアプローチにおける人とプロセスコンポーネントの扱い方に関するヒントをいくつか追加して、既存のガイダンスを強化することです。私の経験によると、これらはセキュリティの成果やオーナーシップ、市場投入までの速度、および全体的な改善に大きく貢献します。さらに、Amazon Web Services (AWS) を使用する場合に固有のガイダンスも提供します。
まず、脅威モデリングの入門から始めましょう。

この投稿は2021年1月11日に公開されたHow to approach threat modeling を翻訳したものです。

脅威モデリングを使用する理由

ITシステムは本来複雑ですが、時間が経つにつれてますます複雑で機能的になり、ビジネス価値が高まり、顧客満足度とエンゲージメントが向上します。これは、増え続けるユースケースに対応し、データへの不正アクセス、サービス拒否、リソースの悪用など、ビジネスに影響を与える結果につながる可能性のある潜在的なセキュリティ上の脅威を軽減する方法でITの設計に関する決定が行われる必要があることを意味します。

通常、この複雑さとユースケースの数に対応するために、非構造的なアプローチを使用して脅威を発見し軽減しても効果的ではありません。代わりに、体系的なアプローチによってワークロードに対する潜在的な脅威を列挙し、軽減策を考案し、それらに優先順位を付け、組織の限られたリソースがワークロードの全体的なセキュリティ体制を改善するうえで最大限の効果を与えられるようにする必要があります。脅威モデリングは、この体系的なアプローチを提供するように設計されており、ライフサイクルの後半で緩和策を導入するよりも低コストで対応できる、設計プロセスの初期段階で問題を見つけて対処することを目的としています。

AWS Well-Architected Framework では、セキュリティの柱内の1つのベストプラクティスとして、基本的なセキュリティの設問「SEC 1：ワークロードを安全に運用するにはどうすればよいですか？」で脅威モデリングについて触れています:

“脅威モデルを使用してリスクを特定し、優先順位を付ける: 脅威モデルを使用して潜在的な脅威を特定し、その登録を最新の状態に維持します。脅威に優先順位を付け、セキュリティコントロールを調整して防止、検出、対応を行います。進化するセキュリティ環境の状況に応じてセキュリティコントロールを再確認および維持します”

脅威モデリングは、すべてのコンテキストを評価に使用できるようにするために、ワークロード（またはワークロードの機能）レベルで実行すると最も効果的です。AWS Well-Architected では、ワークロードを次のように定義しています。

“共にビジネス価値をもたらす一連のコンポーネント。ワークロードは通常、ビジネスリーダーとテクノロジーリーダーが会話する際に使われる粒度です。ワークロードの例としては、マーケティングWebサイト、eコマースWebサイト、モバイルアプリのバックエンド、分析プラットフォームなどがあります。ワークロードのアーキテクチャの複雑さは静的Webサイトから複数のデータストアと多数のコンポーネントを持つアーキテクチャまで、さまざまです。”

脅威モデリングの中心的なステップ

私の経験では、脅威モデリングのアプローチは全て似ており、大まかに言えば、次の手順に従います。

アセット、アクター、エントリポイント、コンポーネント、ユースケース、信頼レベルを特定し、それらを設計図に含めます。
脅威のリストを特定します。
脅威ごとに、セキュリティ制御の実装を含む緩和策を特定します。
リスクマトリクスを作成してレビューし、脅威が適切に緩和されているかどうかを判断します。

これらの手順に関連する一般的なプラクティスをより深く理解するために、 SAFECode Tactical Threat Modelingホワイトペーパー(英語)とOpen Web Application Security Project (OWASP) 脅威モデリングのチートシート (英語) を読むことをお勧めします。これらのガイドは、特定のアプローチを採用する際に考慮すべき優れたリソースです。また、脅威モデル図を作成するOWASP Threat Dragon project や、発生する可能性のある脅威を特定するためのOWASP Top 10、OWASP アプリケーションセキュリティ検証標準 (ASVS) やSTRIDE など、脅威モデリングプロセスの高速化に役立つツールや方法論も多数参照しています。これらの組み合わせを採用するか、独自に作成するかを選択できます。

脅威モデリングをいつ行うべきか

脅威モデリングは設計時のアクティビティです。通常、設計段階では、アーキテクチャの図を作成するだけでなく、本番ではない環境で実際に構築してみる場合もあります。これらのアクティビティは、本番環境の設計に情報を提供し、開発を進めるために実行されます。脅威モデリングは設計時のアクティビティであるため、コードレビュー、コード解析 (静的または動的)、侵入テストの前に行われます。これらはすべて、セキュリティライフサイクルの後半で行われます。

ワークロードを初期段階から設計するときは、潜在的な脅威を常に考慮してください。通常は、ユーザーがまだホワイトボードに (物理または仮想を問わず) だけに存在している段階です。脅威モデリングは、特定のワークロードの機能または機能変更の設計フェーズで実行する必要があります。これらの変更により、新しい脅威が導入され、脅威モデルの更新が必要になる場合があるためです。

脅威モデリングのヒント

つまるところ、脅威モデリングには、思考、ブレーンストーミング、コラボレーション、コミュニケーションが必要です。その目的は、アプリケーション開発、運用、ビジネス、セキュリティの間のギャップを埋めることです。成功への近道はありません。しかし、脅威モデリングの採用と成功に有意義な影響を与えるものがあることが分かりました。これらの領域については、次のセクションで説明します。

1. 正しいチームを集める

脅威モデリングは「チームスポーツ」です。なぜなら、脅威モデリングには、すべてのインプットが同様に重要である多様なチームの知識とスキルセットが必要だからです。このセクションに記載されているすべてのペルソナについて、エンドユーザーの期待から始めて、逆方向に作業することを推奨します。セキュリティ特性と、機能と使いやすさのバランスの維持という観点から、このワークロードまたはワークロードの機能に顧客が何を期待しているのかを考えてみましょう。

次の視点をチームでカバーすることをお勧めします。1人の個人がこの中の複数の視点をテーブルに持ち込むことができることに注目してください。

ビジネス側のペルソナ — まず、物事を根底から守るために、脅威モデリングプロセスの一部であるワークロードまたは機能のビジネスの成果を代表する人材が必要です。この担当者は、ワークロードの機能要件と非機能要件について深く理解している必要があります。また、脅威に対処するために提案された緩和策によって、これらの要件が過度に影響を受けることがないようにするのが仕事です。つまり、提案されたセキュリティコントロール (つまり、緩和策) によってアプリケーションの要件が実現不能になったり、過度に低下したりした場合、セキュリティと機能の適切なバランスをとるためにさらに作業が必要になります。

開発者のペルソナ — ワークロードの機能について現在提案されている設計を理解し、これまでに行われた設計上の決定に最も深く関わってきた人物です。これまで、設計に関連する脅威やその緩和策を検討していた時には、設計のためのブレーンストーミングやホワイトボードセッションに携わっていました。自分たち自身で社内アプリケーション (COTS アプリケーションなど) を開発していない場合は、その社内アプリケーションのオーナーを招きます。

攻撃者のペルソナ — 次に、攻撃者の役を演じる人が必要です。このペルソナの目的は、攻撃者の立場に身を置き、ワークロードの設計を批判的に見直し、ワークロードの設計上の欠陥を利用して特定の目的（データの不正な共有など）を達成する方法を探すことです。彼らが行う「攻撃」は思考上のエクササイズであり、実際にキーボードを打って攻撃するわけではありません。組織にいわゆる Red Team がある場合は、この役割に最適かもしれません。そうでない場合は、セキュリティ運用チームまたはエンジニアリングチームの 1 人以上のメンバーにこの役割を担わせることもよいでしょう。あるいは、この分野に特化した第三者を招くこともできます。

防御側のペルソナ — 次に、防御の役割を果たす人が必要です。このペルソナの目的は、攻撃者ペルソナが設計した可能性のある「攻撃」を潜在的な脅威として認識し、脅威を軽減するセキュリティコントロールを考案することです。また、このペルソナは、継続的な運用サポート、監視、インシデント対応に関して、考えられる緩和策が合理的に管理可能であるかどうかを評価します。

AppSec SME のペルソナ — アプリケーションセキュリティ (AppSec) のSubject Matter Expert (SME) のペルソナは、脅威モデリングプロセスとディスカッションのモデレーション方法に最も精通しており、IT セキュリティに関する深い知識と経験を持っている必要があります。ディスカッションのモデレーションは、プロセスの全体的な目標が順調に維持され、セキュリティとお客様への価値の提供との間の適切なバランスを維持するために、演習プロセス全体にとって非常に重要です。最終的には、このペルソナが脅威モデルを承認し、脅威モデリングの実施範囲を超えたアクション (侵入テストの範囲など) をアドバイスします。

2. 一貫したアプローチを取る

前のセクションでは、一般的な脅威モデリングのアプローチをいくつか挙げましたが、どのアプローチを選択するかは重要ではありません。

チーム内およびチーム間で一貫して選択したものを利用することが重要です。一貫したアプローチとフォーマットを使用することで、チームはより迅速に行動し、作業量をより正確に見積もることができます。個人は、他のチームメンバーや他のチームによって開発された脅威モデルを見ることで、例から学ぶことができるため、ゼロから始める必要がありません。

チームが脅威モデルの作成に必要な労力と時間を見積もる際には、以前の脅威モデルで得た経験とかかった時間を参考に、スケジュールをより正確に見積もることができます。

一貫したアプローチとフォーマットを使用するだけでなく、モデル化する脅威の粒度と関連性の一貫性が重要です。この記事の後半では、組織全体で再利用する脅威のカタログを作成する際の推奨事項について説明します。

結果として、このアプローチによりスケーラビリティが確保できます。脅威モデリングを実施しているワークロードの機能が、既存の脅威モデルを持つコンポーネントを使用している場合、そのコンポーネントの脅威モデル (または個々のセキュリティコントロール) を再利用できます。このアプローチにより、コンポーネントの既存の脅威モデルへの依存関係を効果的に取得し、そのモデルに基づいて構築できるため、重複作業を減らすことができます。

3. ソフトウェアデリバリーの方法論に沿う

アプリケーション開発チームには、すでに特定のワークフローとデリバリーのスタイルがあります。最近では、アジャイルスタイルのデリバリーが最も人気があります。脅威モデリングに採用するアプローチが、デリバリーの方法論とツールの両方とうまく統合されるようにします。

他の成果物と同様に、脅威モデリングに関連するユーザーストーリーをワークロードの機能のスプリント、エピック、バックログの一部として捉えます。

4. 既存のワークフローツールを利用する

アプリケーション開発チームはすでに、彼らのデリバリー方法をサポートする一連のツールを使用しています。これには通常、ドキュメント用のコラボレーションツール (チームのWiki など) や、ソフトウェア開発ライフサイクルを通じて作業成果物を追跡する課題追跡ツールが含まれます。セキュリティレビューと脅威モデリングのワークフローの一部として、これらと同じツールを使用することを目指します。

既存のワークフローツールは、フィードバックの提供と表示、アクションの割り当て、ワークロードの機能の脅威モデリングの成果物の全体的なステータスの表示を一元的に提供できます。ワークフローに参加することで、プロジェクトを完了する際の煩わしさを軽減し、単体テスト、QA テスト、その他の一般的なワークフローの手順と同様に脅威モデリングを一般的なものにすることができます。

一般的なワークフローツールを使用することで、脅威モデルの作成とレビューに取り組んでいるチームメンバーは別々に作業できます。たとえば、脅威モデルのレビュー担当者がフィードバックを追加すると、作成者に通知が届き、作成者は時間があるときにフィードバックに対処できます。会議のために時間を確保する必要はありません。また、これにより、AppSec SME は、関与している可能性のある複数の脅威モデルレビューに対して、より効率的に作業できるようになります。

前述のとおり、一貫したアプローチと共通言語を持つことは、この非同期プロセスを実現可能にするための重要な前提条件です。これにより、各参加者は毎回正しい解釈を再学習しなくても脅威モデルを読み、理解できるようになります。

5.ワークロードを小さなパーツに分解する

ワークロード全体に対して 1 つの脅威モデルを作成するのではなく、ワークロードをフィーチャに分解 (解体) し、フィーチャレベルで脅威モデリングの演習を実行することをお勧めします。このアプローチには、主に次のようなメリットがあります。

作業のチャンクを小さくすることで、進捗状況をより詳細に追跡できるため、アジャイルスタイルのデリバリーに従っている開発チームと連携し易く、リーダー層も常に進捗状況を把握できます。
このアプローチでは、より詳細な脅威モデルが作成される傾向があり、その結果、より多くの発見があります。
また、分解することで脅威モデルが、同じコンポーネントを使用する他のワークロードの機能の依存関係として再利用される可能性も生まれます。
ワークロードレベル全体で、コンポーネントごとに脅威の緩和策を検討することで、1 つの脅威に複数の緩和策がある可能性があり、その結果、これらの脅威に対する回復力が向上します。
単一の脅威モデルに関する問題 (まだ軽減されていない重大な脅威など) は、ワークロード全体ではなく、個々の機能のリリースに対してのみ、ブロッカーになります。

問題は、ワークロードをどこまで分解すべきかということです。

原則として、脅威モデルを作成するには、最低でも以下のコンテキストが必要です。

1つのアセット。例として認証情報、顧客レコードなど。
1つのエントリポイント。例として、 Amazon API Gateway の REST API デプロイメントなど。
2 つのコンポーネント。たとえば、ウェブブラウザと API Gateway の REST API、または API Gatewayと AWS Lambda 関数などです。

特定の AWS サービス (API Gateway など) の脅威モデルを単独で作成しても、この基準は完全には満たされません。サービスが単一のコンポーネントであるため、コンポーネント間でデータが移動することはありません。さらに、ワークロード内のサービスのあり得るすべてのユースケースのコンテキストが不明であるため、脅威と緩和策を包括的に導き出すことはできません。AWS は、特定の AWS サービスを構成する複数の機能の脅威モデリングを実行します。したがって、特定の AWS サービスを活用するワークロードの機能では、AWS サービスを脅威モデル化する必要はなく、特定した脅威を軽減するために、さまざまな AWS サービス設定オプションとあなたのワークロード固有の緩和策を検討する必要があります。これについては、「緩和策を特定し評価する」セクションで詳しく説明します。ここでは、ベースラインセキュリティコントロールの概念について説明します。

6.オーナーシップを分配する

脅威モデルの作成を中央集権的に担当する担当者や部署を持つことは、長期的には機能しません。これらの中心的なエンティティはボトルネックとなり、人員を追加しないとスケールアップできません。さらに、オーナーシップを一元化しても、ワークロードの機能を実際に設計および実装している人を支援することにはなりません。

代わりに、各ワークロードの機能の設計と実装を担当するチームに脅威モデル作成のオーナーシップを分配すると適切にスケールできるようになります。オーナシップを分配することで、行動の変化を促進しスケールするようになります。アプリケーションチームがコントロールできるようになり、重要なこととして、脅威モデリングプロセスから得たセキュリティについての学びを次の機能リリースに反映させることで、常にワークロードと機能のセキュリティを向上させていくことができます。

これにより、AppSec SME (またはチーム) が、組織内のさまざまなアプリケーションチームすべてに対して、モデレーターおよびセキュリティアドバイザーの役割を効果的に果たすチャンスが生まれます。AppSec SME は、一貫性、適用、コミュニケーションを促進し、チーム間のセキュリティ基準を制定し、引き上げる立場となっていくでしょう。

7. エントリポイントを特定する

全体の脅威モデルに含まれるAWS サービスのエントリーポイントを特定する時、AWS のサービスの種類によって、脅威モデルのスコープに含まれるワークロードの機能のアーキテクチャに応じてエントリーポイントが異なる場合があることを理解することは重要です。

例えば、 Amazon Simple Storage Service (Amazon S3)の場合、S3 バケットへのエントリーポイントとして可能なものは Amazon S3 API を通して公開されているものに限られ、サービスはお客様であるあなたに他の種類のエントリーポイントを作る機能を提供しません。この Amazon S3 の例では、お客様であるあなたは、バケットがプライベートであるかパブリックにアクセスできるかなど、どのように公開するかを既存の種類のエンドポイントから選択できます。

一方で、 Amazon Elastic Compute Cloud (Amazon EC2)はお客様にEC2インスタンスへ Amazon EC2 API やEC2インスタンスで実行されているネイティブなオペレーティングシステムが提供するもの(例:SSHやRDP) 以外の他の種類のエントリーポイントを提供することを許します(例:あなたのアプリケーションのAPI)。

そのため、脅威モデルの一部に、AWS サービスのネイティブなエンドポイントに加えて、ワークロードの機能に固有のエントリポイントを含めていることを確認してください。

8. 脅威を洗い出す

ここでの目的は、「何が問題を起こすのか?」という質問に対する答えを考え出すことです。脅威を特定するかどうかは、評価対象のワークロードの機能のコンテキストや、特定の業界、地域などに固有の脅威の種類によっても異なるため、考えられるすべての脅威を一覧表示する標準的なリストはありません。

脅威を洗い出すにはブレーンストーミングが必要です。ブレーンストーミングの演習は、 STRIDE ( Spoofing:なりすまし、Tampering:改ざん、Repudiation:否定、Information Disclosure:情報開示、Denial of Service:サービス拒否、and Elevation of Privilege:特権の昇格) のよう考えを補助する仕組みを使用するか、 OWASP Top 10 または HiTrust Threat Catalog のような脅威リストを見渡してアイデアを湧かせます。

このプロセスを通じて、組織の状況に応じた脅威カタログを開発して、それにコントリビューションすることで、今後のブレーンストーミングプロセスを加速し、モデル化する脅威の粒度の一貫性を高めることが推奨されます。

9. 緩和策を特定し評価する

ここでは、ワークロードの設計における緩和策 (セキュリティコントロール) を特定し、脅威に適切に対処したかどうかを評価することが目的です。通常、統制には複数の層があり、複数の責任が存在していることに注意してください。

社内のアプリケーションやコードについては、入力のバリデーション、認証、セッション処理、境界処理など、またこれらに限らず、設計に含めた緩和策を確認する必要があります。

ワークロードの他のすべてのコンポーネント (サービスとしてのソフトウェア (SaaS)、 COTS (※訳註日本語Wikipedia はこちら )アプリケーションをサポートするインフラストラクチャ、オンプレミスのデータセンター内でホストされるコンポーネントなど) を考慮し、ワークロードの設計の一部として、セキュリティコントロールを決定します。

AWS のサービスを利用する場合、セキュリティとコンプライアンスは AWS とお客様の間で共有される責任です。これについては、AWS の責任共有モデルのページで説明しています。

つまり、使用している AWS サービスのうち、AWS (Security of a Cloud) が責任を負う部分については、脅威の特定と軽減とともに、セキュリティコントロールが AWS によって管理されます。AWS (Security of the Cloud) とお客様 (Security in the Cloud) の間の責任の分配は、使用する AWS のサービスによって異なります。以下に、インフラストラクチャ、コンテナ(※訳註)、抽象化された AWS サービスの例を示し、脅威を特定して軽減するお客様の責任がどのように異なるかを示します。

(※訳註: ここでいうコンテナはdocker などの仮想化技術としてのコンテナではありません)

Amazon EC2 は、クラウド内の仮想マシンにアクセスし、オペレーティングシステムを選択し、サービスとその上で実行するあらゆる側面を制御できるインフラストラクチャサービスの好例です。そのため、特定された脅威を軽減する責任はお客様にあります。
Amazon Relational Database Service (Amazon RDS) は、コンテナサービスの代表的な例です。オペレーティングシステムは公開されておらず、AWS は選択したデータベースエンジン (MySQL など) を公開します。この例では、AWS はオペレーティングシステムのセキュリティに責任を負うため、お客様はその緩和策を考案する必要はありません。ただし、データベースエンジンは、その上位のすべての側面と同様にお客様の管理下にあるため、これらの領域に対する緩和策を検討する必要があります。ここでは、インフラストラクチャサービスに比べると、AWS が多くの責任を担っています。
Amazon S3、 AWS Key Management Service (AWS KMS)、および Amazon DynamoDB は、AWS がサービス API を通じてサービスのコントロールプレーンとデータプレーン全体を公開する抽象化されたサービスの例です。ここでも、オペレーティングシステム、データベースエンジン、プラットフォームは公開されていません – これらは AWS の責任です。ただし、API アクションと関連するポリシーはお客様のコントロール下にあり、API レベルを上回る側面に関しては、全て緩和策を検討する必要があります。このタイプのサービスでは、コンテナやインフラストラクチャタイプのサービスに比べて、AWS がさらにより大きな責任を負います。

これらの例は、ワークロードに含まれる可能性のあるすべての AWS サービスを網羅しているわけではありませんが、責任共有モデルにおけるセキュリティとコンプライアンスのお客様の責任がこのコンテキストでどのように異なるかを示しています。ワークロード内の AWS サービスの種類に対する AWS とお客様との間の責任のバランスを理解しておくと、脅威モデリングの実行範囲を、自社の管理下にある緩和策の範囲に絞り込むことができます。それは通常 AWS のサービスの設定オプションとお客様固有のワークロードの緩和策の組み合わせです。AWS の責任において、AWS のサービスは多くのコンプライアンスプログラムの対象であり、AWS のお客様は AWS Artifact から監査レポートを (無償で) ダウンロードできます。

使用している AWS のサービスに関係なく、常にお客様の責任の要素があり、これをワークロードの脅威モデルに含める必要があります。

具体的には、AWS のサービス自体のセキュリティコントロールの緩和策には、ID とアクセス管理 (認証/認可)、データ保護 (保管時及び送信時)、インフラストラクチャセキュリティ、ロギング、モニタリングなどのドメインを跨った、全体のセキュリティコントロールを検討したくなるでしょう。AWS の各サービスのドキュメントには、セキュリティに関する専用の章があり、緩和策として検討すべきセキュリティコントロールに関するガイダンスが記載されています。これらのセキュリティコントロールと緩和策を脅威モデルに取り込む場合は、ワークロードのInfrastructure-as-Code のリポジトリなどにある実際のコード、IAM ポリシー、AWS CloudFormation テンプレートへの参照を含めるようにしてください。これにより、脅威モデルのレビュー担当者または承認者は、意図した緩和策を明確に把握できます。

脅威を特定する場合と同様に、すべての可能なセキュリティコントロールを列挙した標準的なリストはありません。ここで説明するプロセスを通じて、組織の統制目標に合わせたベースラインセキュリティコントロールを意識的に開発し、可能な場合は AWS のサービスレベル設定 (保管時の暗号化など) またはガードレール (サービスコントロールポリシーなどによる)を含め、これらのベースラインセキュリティコントロールをプラットフォームレベルの統制として実装する必要があります。) 。これにより、一貫性と拡張性を高めることができるため、実装されたベースラインセキュリティコントロールは、設計およびデプロイする他のワークロード機能に対して自動的に継承され、適用されます。

ベースラインのセキュリティコントロールを考える際には、特定のワークロードの機能のコンテキストが不明であることに注意することが重要です。そのため、ワークロードの脅威モデリングの演習を実行するときに、ベースラインコントロールが軽減するように設計された脅威が適用されない場合や、脅威を適切に軽減する他の緩和策や代替となるコントロールがあることを条件として、これらのベースラインコントロールを逸脱できるよう交渉できるものとして考えることをお勧めします。代替となるコントロールや緩和策としてはデータ資産の分類の軽減、人間以外によるアクセス、一時的なデータ/ワークロードなどがあります。

クラウドセキュリティのガバナンス全体の一部としてベースラインセキュリティコントロールについて考える方法の詳細については、「How to think about cloud security governance(クラウドのセキュリティガバナンスの考え方)」のブログ記事をご覧ください。

10.もう十分、というタイミングを決める

この質問に対する完璧な答えはありません。ただし、リスクの可能性と影響が適切に考慮されるように、バランスの取れたアプローチを作成するには、脅威モデリングのプロセスについてリスクベースの視点を持つことが重要です。“let’s build and ship it” の考え方を重視しすぎると、多大なコストが発生し、後で遅延が発生する可能性があります。逆に、「考えられるすべての脅威を軽減しよう」としすぎると、ワークロードの機能の公開が遅くなる（またはまったくない）ことになり、顧客が離れてしまうかもしれません。「正しいチームを集める」セクションで前述した推奨事項では、機能の公開と脅威の軽減の間に自然な緊張が生じるように、ペルソナの選択は慎重に行います。この健康的な緊張を受け入れます。

11. 始める前にやめない

「ワークロードを小さなパーツに分解する」セクションの前半で、脅威モデルの範囲をワークロードの機能に限定することをお勧めしました。あなたは「<X>個の機能がすでに公開済みだが、それらをどのように脅威モデルにしようか」と考えているかもしれません。これは完全に合理的な質問です。

私の見解では、すでに公開されている脅威モデルの機能に戻るよりも、現在作業中の新機能を脅威モデル化し、次に公開するコードのセキュリティプロパティを改善し、その後公開する各機能のセキュリティープロパティを改善することを目指します。この過程で、あなた、チーム、組織は、脅威モデリングだけでなく、互いに効果的にコミュニケーションをとる方法を学びます。調整、反復、改善しましょう。将来的には、新機能に対して高品質で一貫性のある再利用可能な脅威モデルを日常的に提供するようになると、既存の機能の脅威モデリングを実行するアクティビティをバックログに追加し始めることができます。

まとめ

脅威モデリングは投資です。私の考えでは、ワークロードの機能の設計段階で脅威を検出して軽減することで、脅威を後で検出する場合と比較して、緩和にかかる相対的なコストを削減できるため、脅威モデリングは優れた投資です。脅威モデリングを一貫して実装することで、時間の経過とともにセキュリティ体制が改善される可能性もあります。

エンドカスタマーが期待する脅威を見つけて対処するためのコミュニケーション、コラボレーション、人間主導の専門知識を中心に、脅威モデリングを組織に組み込むための実践的な方法に関する観察とヒントを共有しました。これらのヒントを参考に、現在取り組んでいる (またはバックログにある) ワークロードの機能を調べて、最初に脅威モデルにするワークロードの機能を決定することをお勧めします。

この投稿に関するフィードバックがある場合は、翻訳前の投稿の [コメント] セクションにコメントを送信してください。

AWS セキュリティのハウツーコンテンツ、ニュース、機能に関するお知らせをもっと知りたいですか?ツイッターでフォローしてください。

この記事の翻訳は、ソリューションアーキテクトの金森政雄が担当しました。

Amazon Web Services ブログ