SEC01-BP07 脅威モデルを使用して脅威を特定し、緩和策に優先順位を付ける

脅威モデリングを実行して、ワークロードの潜在的な脅威とそれに関連する緩和策の登録を特定して維持 up-to-dateします。脅威に優先順位を付け、セキュリティコントロール緩和策を調整して防止、検出、対応を行います。ワークロードの内容、および進化するセキュリティ環境の状況に応じてセキュリティコントロールを保持および維持します。

このベストプラクティスを活用しない場合のリスクレベル: 高

実装のガイダンス

脅威モデリングとは?

「脅威モデリングとは、価値あるものを保護する状況において、脅威とその緩和策を特定し、伝達して理解する取り組みをいう」。– Open Web Application Security Project (OWASP) アプリケーション脅威モデリング

なぜ脅威モデリングが必要なのか?

システムは複雑であり、時代とともに次第に複雑かつ高性能となり、提供するビジネス価値は向上し、顧客満足度とエンゲージメントは強化されています。つまり、IT 設計を決定する際は、増え続けるユースケースの件数を考慮する必要があるということです。このような複雑で数が多いユースケースの組み合わせは、非構造化アプローチでは一般に脅威の検出と緩和に効果がありません。代わりに必要となるのは、システムに対する潜在的な脅威を列挙し、緩和策を考案し、その緩和策に優先順位をつけて、組織の限定的なリソースがシステム全体のセキュリティ体制の改善に最大の効果を発揮できるような体系的アプローチです。

脅威モデリングは、このような体系的アプローチを提供する設計となっており、その狙いは、ライフサイクルの後半と比較すると相対的にコストと労力が低い設計プロセスの早い段階で問題を発見し、対処することです。このアプローチは、業界の原則であるセキュリティ戦略「シフトレフト」と一致しています。最終的に脅威モデリングは組織のリスク管理プロセスと統合し、脅威駆動型アプローチを使用して、実装するコントロールの決定を促します。

脅威モデリングを実行するタイミング

ワークロードのライフサイクルにおけるできるだけ早い段階で脅威モデリングを開始することにより、より柔軟に特定した脅威への対策を実施できるようになります。ソフトウェアのバグと同様、脅威を特定するのが早いほど、その対策のコスト効率が向上します。脅威モデルはライブドキュメントであり、ワークロードの変化に応じて進化し続ける必要があります。大きな変化、脅威の状況における変化が生じた場合や、新たな機能またはサービスを採用した場合などを含む、経時的な脅威モデルを保持します。

実装手順

脅威モデリングの実行方法

脅威モデリングにはさまざまな実行方法があります。プログラミング言語と同様、それぞれに長所と短所があり、自分に最も適した方法を選択する必要があります。そのうちの 1 つが「Shostack’s 4 Question Frame for Threat Modeling」から始める方法です。ここでは、自由形式の質問をたずねることで脅威モデリングに枠組みを与えます。

現在取り組んでいることは何か?

この質問の目的は、構築しているシステム、さらにはセキュリティに関連するシステムに関する詳細を理解してそれに合意するのを支援することです。この質問に答える最も一般的な方法は、モデルや図を作成することです。それにより、現在構築しているものをデータフロー図などを使って視覚化することができます。システムに関する推測と重要な詳細を書き留めることも、対象範囲を定義するのに役立ちます。これにより、脅威モデルに貢献しているすべてのユーザーが同じことに集中し、トピック (システムの古いバージョンを含む) への out-of-scope時間のかかる迂回を回避できます。例えば、ウェブアプリケーションを構築している場合、ブラウザクライアントのオペレーティングシステムの信頼できるブートシーケンスをモデル化する脅威については、あまり時間をかける価値があるとは思えません。
問題化する可能性があるものは何か?

ここで、システムに対する脅威を特定します。脅威とは、望ましくない影響を生じさせ、システムのセキュリティに悪影響を及ぼす恐れのある、偶発的または意図的なアクションや事象を指します。どのような問題が起きるかをはっきりと理解していなければ、何も対策は打てません。

何が問題になるのかに関して、定型的なリストは存在しません。このリストを作成するには、チームのメンバーと脅威モデリングに参加する関係者との全員による、ブレインストーミングとコラボレーションが必要となります。などの脅威を特定するためのモデルを使用することで、ブレインストーミングを支援できます。このモデルではSTRIDE、スプーフィング、改ざん、否認、情報開示、サービス拒否、特権昇格など、評価すべきさまざまなカテゴリを提案します。さらに、OWASP上位 10 位、HiTrust Threat Catalog 、組織独自の脅威カタログなど、既存のリストと調査を確認して、ブレインストーミングを支援することもできます。
どのように対処すべきか?

前の質問と同様、考えられる緩和策について定型的なリストはありません。このステップに対する入力項目は、特定された脅威、アクター、および前のステップからの改善点です。

セキュリティとコンプライアンスは、AWSとユーザー間で共有される責任です。「それをどうするのですか?」という質問を行うときは、「誰がその責任者なのか?」ということもたずねていると理解することが重要です。責任のバランスを理解し、脅威モデリングの演習を、通常、 AWS サービス設定オプションと独自のシステム固有の緩和策の組み合わせである、制御下にある緩和策に絞り込む AWS のに役立ちます。

責任共有の AWS 部分では、AWS サービスは多くのコンプライアンスプログラムの範囲内であることがわかります。これらのプログラムは、クラウドのセキュリティとコンプライアンス AWS を維持するためにで導入されている堅牢なコントロールを理解するのに役立ちます。これらのプログラムの監査レポートは、から AWS ダウンロードすることができますAWS Artifact。

使用している AWS サービスに関係なく、常にお客様の責任の要素があり、これらの責任に沿った緩和策を脅威モデルに含める必要があります。 AWS サービス自体のセキュリティコントロールの緩和策として、アイデンティティとアクセスの管理 (認証と認可）、データ保護 (保管中と転送中）、インフラストラクチャのセキュリティ、ログ記録、モニタリングなどのドメインを含むドメイン間でセキュリティコントロールを実装することを検討してください。各 AWS サービスのドキュメントには、緩和策として考慮すべきセキュリティコントロールに関するガイダンスを提供する専用のセキュリティ章があります。重要ですので、記述しているコードとコード依存関係を考慮し、それらの脅威に対応するために設定できるコントロールについて考えてください。こうしたコントロールには、入力の検証、セッションの処理、境界の処理などが含まれます。多くの場合、脆弱性の大部分はカスタムコードで発生するため、この領域を注視してください。
十分に優れた仕事をしたか?

狙いは、チームと組織が脅威モデルの質と、脅威モデリングを行う際の時間的な速さを改善することです。これらの改善は、練習、学習、指導、レビューを組み合わせることで実現します。十分に理解して実践的な経験を積むには、お客様とお客様のチームメンバー全員が「Threat modeling the right way for builders training course」またはワークショップを受講することが推奨されます。さらに、脅威モデリングを組織のアプリケーション開発ライフサイクルに統合する方法に関するガイダンスが必要な場合は、 AWS セキュリティブログの「脅威モデリングへのアプローチ方法」を参照してください。