脅威モデリングと DevOpsの統合

この投稿は、Simone Curzi、アンソニー・ネヴィコ、ジョナサン・デイビス、ラファエル・パソス・ロドリゲス、ベン・ハンソンが執筆しています。

はじめに

脅威モデリングは、アプリケーションまたはシステムの最も重要なリスク軽減策を特定して優先順位を付けるのに役立つ重要なセキュリティ方法です。 このホワイト ペーパーでは、脅威モデリングをより効果的かつ効率的に導入し、それを最新の DevOpsの方法論やツールと統合し、ソフトウェア開発ライフサイクルに関連するすべてのアクターに提供される価値に焦点を当てる方法について、いくつかの考察を取り上げます。

この論文はあなたですか？

このホワイト ペーパーは、Microsoftのセキュリティと脅威モデリングの専門家の小規模なチームの作業の結果であり、Microsoftの外部から最も著名な専門家の一部の入力とアイデアが組み込まれています。 ここでは、アジャイル手法と DevOps によって課される最新の要件に合わせて、使用する脅威モデリング プロセスを最新の要件に確実に更新し、必要な値を最小限のコストで提供するために、簡単だが緊急の質問に対処する必要があります。

製品所有者、セキュリティ チームのメンバー、または開発ライフサイクルの一部として脅威モデリングを採用することを検討している開発者の場合は、このホワイト ペーパーが適しています。

同様に、既に脅威モデリングを採用している場合でも、プロセスを改善するための実用的なアイデアが見つかる可能性があります。

ただし、このホワイト ペーパーは、現在のプロセスを改善したり、DevOps プロセスの一部として脅威モデリングを正常に採用したりするためのアイデアを紹介するように設計されています。 将来、一部のツールや製品によって実装されるアイデアを見たいと考えている場合でも、特定のツールや製品は導入されません。 そのため、今後の機能の新しいツールやプレビューのお知らせは、ここでは見つかりません。

脅威モデリングが重要な理由

脅威モデリングは、ソフトウェア ソリューションを安全に設計するための主要なアプローチの1つです。 脅威モデリングを使用して、システムを分析して攻撃ベクトルを特定し、それらの攻撃によってもたらされるリスクを軽減するためのアクションを開発します。 適切に行われる脅威モデリングは、リスク管理プロセスの優れたコンポーネントです。 また、設計の問題を早期に特定して修正することで、コストを削減することもできます。 NISTの以前の調査では、運用コードの設計の問題を修正するコストは、設計フェーズ中に修復するよりも約 40 倍高いと見積もっています。 また、最終的な設計上の問題に対するセキュリティ インシデントが原因でコストが発生するのを防ぐこともできます。 IBM Security とPonemon Instituteの 2022年のデータ侵害レポートでは、データ侵害の平均コストが $4.35M と見積もっていることを検討してください。 5、000 万件を超えるレコードの侵害を伴う、いわゆるメガ侵害の場合、平均コストは 3、870 万ドルに達します。

脅威モデリングは、ソリューション設計で動作するため、ソリューションをセキュリティで保護するために実行できる最初のアクティビティです。 この特性により、SDLC に適用できる最も効果的なセキュリティプラクティスになります。

Microsoft には、脅威モデリングに関する長い歴史があります。 1999年、2 人の Microsoft 従業員である Loren Kohnfelder と Praerit Garg が、Microsoft 製品に対する脅威に関するドキュメントを作成しました。 このホワイト ペーパーでは、Microsoft 脅威モデリング プロセスのシノニムである STRIDE アプローチについて説明しました。

脅威モデリングは進化的なプロセスです

脅威モデリングは静的なプロセスではありません。ニーズやテクノロジの変化に合わせて進化します。

• SolarWindsをターゲットとする最近の攻撃のようなサプライ チェーン攻撃は、開発や配置など、ソリューション自体よりも多くのシナリオを脅威モデリングでカバーする必要性を示しています。

• 最近の Log4jのようなオープン ソースの脆弱性は、ソフトウェアコンポジション分析ツールの導入に基づいて現在のアプローチを補完し、脆弱性のあるコンポーネントをスキャンする必要性を示しています。ソリューションを防御的に設計して露出を制限します。

• Machine ラーニング などの新しいテクノロジを適用すると、理解して制御する必要がある新しい攻撃ベクトルが導入されます。 たとえば、人間の耳では聞こえない悪意のある細工されたサウンドを再生して、https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/carliniAI サービスによるコマンドの実行を引き起こす可能性を考えてみましょう。

Microsoft では、さまざまな製品グループが、特定のセキュリティ要件に基づいてさまざまな種類の脅威モデリングを実践しています。 各バリアントは、適用されるシナリオに対して適切なレベルのセキュリティ保証を保証することを目的としていますが、"適切" とは特定のコンテキストに応じて変化することを意味します。

たとえば、Windowsのセキュリティ保護は、Azure Cognitive Servicesのセキュリティ保護とは異なります。これらのシステムのサイズと特性は大きく異なるためです。 脅威モデリングの重要な側面は、そのコストとアプリケーションのリスク許容度のバランスを取る点です。 これは、一部のシナリオで脅威モデリングを完全に回避するという決定につながる可能性はありますが、適切に行った場合に非常に効果的であるため、ソフトウェア開発やインフラストラクチャの配置プロジェクトを含む IT イニシアチブにのみ採用することをお勧めします。

ROI に重点を置く重要性

ここ数年、重要なソフトウェア開発プロセスとして脅威モデリングへの関心が着実に高まってきました。 この関心は、インフラストラクチャとソリューションに対する攻撃の指数関数的な増加によるものです。 ベンダーの NIST 推奨最小標準やコードの開発者検証や脅威モデリング マニフェストなどの取り組みにより、現在のアプローチでいくつかの制限が示されるまで需要がさらに増加しました。 たとえば、脅威モデリングの結果は、採用されたプロセスと、脅威モデルを実行するユーザーに大きく依存します。 したがって、エクスペリエンスから一貫して高い品質を得ることに関する懸念があります。

しかし、脅威モデリングの品質とは何を意味するのでしょうか。 品質脅威モデルには、次の特性が必要です。

• アクションにつながる軽減策、攻撃による潜在的な損失を減らすために実行できるアクティビティを特定する必要があります。 アクション可能とは、これらの軽減策を適切に定義する必要があることを意味します。つまり、軽減策を実装し、実装をテストするのに十分な情報を取得できます。 これは、開発チームから簡単に使用できるように提供する必要があることを意味します。 DevOps とアジャイルでは、バックログに軽減策をインポートする簡単なパスがあることを意味します。

• 軽減策ごとに、その状態を識別する必要があります。 一部の軽減策は新しく、他の軽減策は既に存在します。 脅威モデルは、既に存在するものを認識し、現在のリスクに焦点を当てて、状況を改善する方法を特定する必要があります。

• それぞれの脅威にリンクすることで、各軽減策が必要な理由を明確に特定する必要があります。

• さらに、軽減策には、各脅威に対する相対的な強度があります。 たとえば、TLS 暗号化は、転送中にデータが公開されるリスクに対する強力な軽減策であり、同時に、サーバーのスプーフィングのリスクに対するほぼ完全な軽減策である可能性があります。

• 脅威は信頼でき、明確に定義され、ソリューションに固有である必要があります。

• 脅威には重大度が関連付けられている必要があり、その確率と影響の両方を考慮する必要があります。 重大度は妥当であり、理想的には偏りを持たない必要があります。

• リスクとその対処方法を包括的に確認できる必要があります。 このビューは、セキュリティ チームやビジネスの意思決定者との有意義な会話を促進するのに役立ち、不要な複雑さを隠すことができるようになります。

この一覧には、重要な概念が既に示されています。脅威モデリングは、ソフトウェア ライフサイクル中に関係する多くのロールに価値を提供できますが、各ロールのニーズと要件は異なります。 たとえば、開発者は、実装する必要がある内容や、実装した内容が期待どおりに動作することを確認する方法に関する明確な情報を受け取る必要があります。 一方、セキュリティ チームは通常、組織が所有するインフラストラクチャとアプリケーションのエコシステムの全体的なセキュリティに関するものです。そのため、スコープ内のシステムが十分にセキュリティで保護され、そのコンプライアンス要件を満たしているかどうかを判断できる情報を受け取る必要があります。 最後に、製品所有者とビジネスの意思決定者は、組織にとってリスクを許容できるようにするために何が必要かを理解する必要があります。

このようなニーズが異なる場合は、脅威モデルに関して異なるビューを提供する必要があります。それぞれのビューは、特定の使用シナリオに重点を置いています。

脅威モデリングの一般的な問題は、成功するほど、このエクスペリエンスから期待される高品質を提供しながら、少数の利用可能な専門家が需要をカバーすることが困難であるということです。 その結果、品質が悪影響を受ける場合があります。 脅威モデリングが投資と比較して大きな価値を提供しなくなるまで、すべて問題ありません。 この問題の影響を受けた組織は複数あります。 コストに大きな価値を提供できないので、ビジネス意思決定者が脅威モデリングに疑問を持ち始めたという報告が既に2つあります。

価値とは、ビジネス価値を指します。これは、システムがスコープ内で表すリスクを理解するために必要な情報を提供し、実装する適切な軽減策を選択するための意味のある決定プロセスを推進する機能です。 さらに、価値は、開発者とテスターに正しい情報を提供することにも関連しています。 最後に、価値は、すべての関係者と残留リスクを伝えることに関連しています。 たとえば、脅威モデリング プロセスの影響を測定して値を測定する場合があります。 各脅威に特定された重大度に数値を割り当てることで、ソリューションの全体的なリスクを測定するとします。 その場合、脅威モデルの影響ごとに全体的なリスクが時間の経過と同時に減少することが予想されます。 全体的なリスクがメイン一定または増加する場合は、問題が発生する可能性があります。 減少が急なほど、脅威モデルの影響が大きくなります。 もちろん、脅威モデルは実装された軽減策を制御しません。 実装する必要がある内容を決定するのは、製品所有者の責任です。 しかし、脅威モデルの有効性と軽減策の実際の実装をリンクする利点は、ソリューションの実際のセキュリティへの影響を高め、脅威モデルが再びメイン理論上の演習となるリスクを減らすことです。

代わりに、コストは、脅威モデル自体を実行するために必要なアクティビティに関連します。これは、すべての関係者が脅威モデルを生成して議論するために必要な時間です。

ビジネス価値の最大化とコストの最小化に重点を置いた脅威モデリング プロセスを定義できますか。

DevOpsの重要性

脅威モデリングが DevOps プロセスと統合された貴重なプラクティスであることを確認することがいかに重要であるかを既に強調しました。 これは、プロセスを簡略化して自動化することで、すべてのチーム メンバーがプロセスを利用できるようにする必要があることを意味します。 最も重要なのは、DevOpsの脅威モデリングに重点を置くということは、エクスペリエンスが既存の DevOps プロセスと深く統合されていることを確認する必要があることを意味します。

脅威モデリングはまだ別の負担になるべきではありませんが、代わりに、セキュリティ要件の引き出しと収集、セキュリティで保護されたソリューションの設計、選択したタスク & バグ追跡ツールへのアクティビティの組み込み、ソリューションの現在および将来の状態に基づいて残りのリスクの評価を容易にする資産である必要があります。

DevOps との連携

さまざまな手法を使用して、脅威モデリングを現在の DevOps プラクティスに合わせて調整できます。

脅威と軽減

まず、脅威モデリング プロセスを、何を行う必要があるかに焦点を当てる必要があります。 攻撃パターンとその発生方法である脅威は、チームがセキュリティコントロールを実装する必要がある理由を説明するために必要です。 また、軽減策を実装する必要があるタイミングを決定する際の要因でもあります。 それでも、実際の目標は、何を行う必要があるか(軽減策)を決定することです。 したがって、このアプローチは、必要な軽減策を迅速に特定し、何をいつ行うかを簡単に判断できるように決定プロセスを通知する必要があります。 この決定プロセスのメイン成果物は、バックログで選択した軽減策を使用して、それらを標準プロセスの一部にすることです。 脅威モデルの軽減状態の更新を反映するために、脅威モデリング ツールとタスク & バグ追跡ツールを同期するのが理想的です。 これにより、残余リスクを動的かつ自動的に修正できます。これは、スプリント計画会議のような、採用されたアジャイル手法の通常の振り付けの一環として、情報に基づいた意思決定をサポートするために不可欠です。

今日は何ができるでしょうか？

脅威モデリングの専門家として、アクションを明確に識別し、それらを選択したタスクとバグ追跡に含むことができる脅威モデリング プロセスを実装する必要があります。 1 つの方法として、このプロセスを自動化できる多くの脅威モデリング ツールの1つを採用する方法があります。

開発者は、必要に応じて識別されるセキュリティコントロールに焦点を当てる必要があります。 このプロセスは、他のアクティビティを受け取るのと同じ方法で提供するように設計する必要があります。

機能、ユーザーストーリー、タスク

この軽減策は、DevOps 統合に関する脅威モデルによって生成される最も重要な成果物を表していると既に述べていました。 したがって、選択したタスク & バグ追跡ツールで、それらの軽減策から作成されたオブジェクトの種類を明確に定義することが重要です。 一部の軽減策は、スプリントよりも多く続く可能性があります。 そのため、それらをフィーチャーとして作成することをお勧めします。 しかし、多くは簡単で、単一のスプリントに実装することができます。したがって、それらをユーザー ストーリーまたはタスクとして表すことができます。 異なる作業項目の種類を生成することは可能ですが、これにより、間違いや混乱につながる複雑なプロセスが発生する可能性があります。 このため、1 つの作業項目の種類を使用する方が実用的なようです。 軽減策がユーザー ストーリーの子と見なされる可能性がある場合は、それらをタスクとして表現することを検討できます。これは、単一のスプリントで実行される作業項目の種類を確保するという要件を緩和することを意味します。

今日は何ができるでしょうか？

脅威モデルによって識別される軽減策がバックログに表示されていることを確認します。 それらを明確に表す方法を特定します。

ユーザー ストーリー

軽減策は、脅威モデルの唯一の成果物の部分ではありません。これは、タスク & バグ追跡ツールに含まれるものに合わせて調整する必要があります。 たとえば、脅威も表したい場合があります。 この目標は、WITHOUT 句を通常の "[自分は誰として] 私が [何かを行う] ように [私が望むもの] に追加することで、ユーザー ストーリーを拡張することによって達成できます。例： "ユーザーとして、クレジット カードを使用して支払い、クレジットカード盗まれたデータを盗まなくても、商品を購入できるようにします。 WITHOUT 句は、1 つ以上の脅威にマップでき、場合によってはセキュリティ要件を表現できます。 脅威と WITHOUT 句の間のこの整合性が脅威モデル内で明示的に行われるようにすることで、考えられるリスクがユーザー ストーリーの一部として含まれているため、チームによって確実に反映され、処理されるようにすることができます。 この関係を使用して、ユーザー ストーリーの一部として識別されたすべてのセキュリティ要件を少なくとも脅威にマップすることもできます。

知っておくとよいこと

WITHOUT 句は、このページを作成したチームによるオリジナルのアイデアではありません。 誰が最初に導入したかはわかりませんが、このアイデアを持って来た人に感謝しています。

図 1： 要件の調整

たとえば、前の図は次の状況を示しています。

• 脅威 A は、1 なしでの句を介して User Story1にリンクされます。

• 脅威 B は、2 なしでの句を介して User Story2にリンクされています。

• 脅威 B は、ユーザー ストーリー3にもリンクされています。 ただし、User Story3はどの WITHOUT 句にも割り当てません。 なぜですか？ これは、調査する必要がある潜在的な異常を表します。

• 脅威 B は、ユーザー ストーリー1にもリンクされています。 複数の脅威にリンクされたユーザー ストーリーを許可する必要があるかどうかはまだ明らかではありません。

• 脅威 C は、3 と4なしで関連付けられているユーザー ストーリー4にリンクされています。 複数の WITHOUT 句を許可する必要があるかどうかはまだ明確ではありません。

• 脅威 D は、どのユーザー ストーリーにもリンクされていません。 ユーザー ストーリーまたは WITHOUT 句がありませんか？

• User Story5は WITHOUT 句にリンクされていますが、関連する脅威はありません。 脅威が見つからないか、単にユーザー ストーリーと脅威の間のリンクですか？

脅威モデルの一部としてセキュリティ要件を特定することはめったにありません。 したがって、WITHOUT 句では、脅威モデルをセキュリティ要件に拡張し、関連するユーザー ストーリーとリンクすることで、エクスペリエンスをさらに統合する機会が導入されます。 このアプローチは、脅威モデリング エクスペリエンスを時間の経過と同時に評価から進化させる上で重要な役割を果たし、DevOpsのセキュリティ設計ツールになります。

今日は何ができるでしょうか？

ユーザー ストーリー内で WITHOUT 句の使用を開始します。

識別した脅威を、WITHOUT 句を使用してユーザー ストーリーにマップします。また、その逆も同様です。

統合されたエクスペリエンス

同じアイデアを他のシナリオに適用できます。 たとえば、脅威モデルは、脅威モデル自体 (脅威や軽減策など) 内の成果物と、追跡およびバグ追跡ツールの成果物とセキュリティ要件をリンクできます。 たとえば、進行中の攻撃を識別するための監視を実装する要件は、監視に関連するすべての軽減策にマップし、タスクとバグ追跡ツールの対応する成果物にマップする必要があります。 その結果、セキュリティ要件が実現されない状況を簡単に特定できます。実際には、何にもリンクされません。

タスク & バグ追跡ツールの成果物と、脅威モデルによって識別される脅威と軽減策の間の同じリンクを使用して、セキュリティ アクティビティの優先順位付けを容易にすることができます。 通常、セキュリティは最後に実装されます。場合によっては、一部のツールまたは侵入テストによって識別される事後対応的な脆弱性に対処します。 それどころか、関連するユーザー ストーリーや機能と共に軽減策を実装することが最も効果的です。 関連する支払い機能と共にクレジット カードの詳細を実装する必要があるときに、コントロールを実装してクレジットの詳細をセキュリティで保護するのはなぜですか？ 脅威モデルは、これらの関係を強調し、スプリント中に何らかの機能を実装するときに、関連するセキュリティ機能の実装が必要かどうかを判断する簡単な方法を提供する必要があります。 この情報は、たとえばスプリント計画会議中に、有意義な議論を行い、情報に基づいた優先順位付けを推進するために使用できます。 仕組みは簡単です。 ここで取り組むプロジェクトの製品所有者が、次のスプリントのユーザー ストーリーを計画するとします。 上記のユーザー ストーリーには、脅威にリンクされた WITHOUT 句があります。 脅威モデルは、同じ脅威に対するいくつかの軽減策を識別します。 そのため、特定された軽減策の1つ以上に優先順位を付ける必要があるとすぐに推測できます。

図 2： セキュリティの優先順位付け

たとえば、上の図では、User Story1が脅威1にリンクされており、次に軽減策 A と B にリンクされていることがわかります。そのため、これらの軽減策の一方または両方を実装することも検討する必要があります。

今日は何ができるでしょうか？

脅威モデルを参照として使用して、WITHOUT 句を持つユーザー ストーリーを選択した軽減策に対応する作業項目にリンクします。 次のスプリントを計画するときは、WITHOUT 句を使用してこれらのユーザー ストーリーの1つを実装するときに、リンクされたセキュリティ アクティビティに優先順位を付けます。

ミスアラインメントを強調表示するための統合

脅威モデルを作成するアーティファクトをタスク & バグ追跡ツールの成果物とリンクさせる方法について考え始めると、両方の品質を向上させる機会を特定しやすくなります。 重要なのは、その関係を活用して不一致を強調し、一方に存在する情報を活用して、他の部分に存在するものを補完、統合、解釈することです。 上で説明したように、チームの動作に大きな影響を与えることなく、これを行うことができます。 これは、アプローチが既存の情報に依存し、さまざまな世界のさまざまなオブジェクト間の関係を作成するためです。 そのため、脅威モデルがソリューションのセキュリティの信頼の源になります。 同時に、バックログはソリューションの状態と継続的に一致します。

今日は何ができるでしょうか？

WITHOUT 句を使用して、マップされていない脅威やユーザー ストーリーがないことを定期的に確認します。

脅威のモデリングと操作

これらのアイデアはすべてメイン DevOpsの開発側に焦点を当てています。 運用を改善するために何かを行うことができますか？ 私たちはそう考える。 たとえば、脅威モデリングをツールとして使用して根本原因分析を容易にすることができます。これは、セキュリティの観点からシステムの包括的なビューを提供し、一部の攻撃の影響をより深く理解できるためです。 これを実現するには、選択した監視ツールの既存のフィードと脅威モデルを統合する必要があります。 このアプローチは、選択した SIEMの補数を表す場合があります。

脅威モデリングをOperations と統合するためのもう1つの考え方は、最初のモデルを使用して、後者が発生する方法の設計を推進することです。 その例として、ソリューションのイベントの設計があります。 脅威モデリングでは、攻撃の可能性を特定し、その知識を使用して、スコープ内のソリューションがそれらの攻撃が失敗したときに発生する可能性があるイベントを特定できます。 厳密な入力検証を行うと、悪意のある攻撃者が成功する前に数回試行する必要があります。 最初は試行が失敗し、そのうちの1つが最終的に成功します。 障害ごとにイベントを発生させ、しきい値に達したときにアラートをトリガーすることで、攻撃を検出して修復するためのアクションを実行できる場合があります。 インフラストラクチャの監視に制限すると、このような状況はほとんど検出されない。 そのため、カスタム イベントを含める必要があります。このイベントは、SOC がそれらを活用する前にチームが設計して実装する必要があります。

さらに、後者は解決策についてあまり知らないかもしれません。 そのため、SOC では、入力の検証が失敗したときにどのように対応するかを判断できない場合があります。 残念ながら、データ侵害が発生した場合、直接的な損害と最終的な罰金の確率とエンティティを減らすために、迅速に対応することが不可欠です。

そのため、監視する必要がある内容、問題が発生した場合の状況、その場合の対応を事前に計画する必要があります。 これらのイベントを識別する最善の方法は、脅威モデルに依存することです。 そのため、それを活用して標準化された成果物を生成し、監視と監査を推進し、インシデント対応を促進するために必要な構成の実装をガイドして高速化すると便利です。

今日は何ができるでしょうか？

脅威モデルを積極的に使用して、脅威ごとに発生できるイベントを特定します。 これらのイベントは、インフラストラクチャによって提供される場合や、アプリケーションで発生させる必要があるイベントによって提供される場合があります。 バックログに作業項目を含め、それらのイベントが確実に実装されるようにします。

SOC チームを含む運用チームとセキュリティ チームと積極的に協力して、イベントを確実に活用してアラートを生成し、セキュリティ インシデントを特定します。

ROI への影響

これらの手法が脅威モデリングの ROI にプラスの影響を与える理由を疑問に思うかもしれません。 Microsoftの観点からは、DevOps チームの脅威モデリングの価値を高める上で非常に重要です。 繰り返し見てきた問題は、これらのチームがセキュリティを限られた価値を提供し、予期しない作業を必要とするコストとして認識することです。 場合によっては、セキュリティを修正するために多くの時間を投資する必要がある理由が不明な場合があります。 その結果、セキュリティは機会ではなく問題になります。 脅威モデリングは、セキュリティを実装する理由を提供するため、これらの問題を克服する可能性があります。 さらに、開発プロセスの早い段階で開始し、すぐに検出されないと大きくコストがかかる可能性のある設計ミスを回避できます。 上記の手法は、脅威モデリングをDevOps とより適切に統合することを目的としています。 これにより、ビジネスの意思決定者と開発者は、脅威モデリングが開発と運用プロセスの自然な補完として認識されるようになります。 そのため、脅威モデリングを採用することで受け取る値が増加し、既に使用されているさまざまなツールとの統合によりコストが減少します。

脅威モデリングの作業を簡略化する

脅威モデリングの ROIを向上させるために必要なもう1つの重要な側面は、コストを削減し、より均一な品質レベルを維持しながら、それを提供できるユーザーの数を増やすことメイン関連しています。

能力のある人の不足に対処するために多くの試みがあります。 その一部は、脅威モデリング演習における DevOps チーム全体の積極的な関与に基づいています。 この考え方は、イニシアチブのリーダーを特定することです。これは、プロセスに関する中間知識を持つ人ですが、必ずしも専門家であるとは限らない人であり、他のチーム メンバーの間で彼女が議論をリードするようにすることです。 このアプローチは、脅威モデリング マニフェストの署名者によって積極的に承認されています。

私たちは、このアプローチが良い価値を得ることを可能にし、現在の状況に対する改善を表することに同意します。 また、優れた分析情報を提供し、チームがセキュリティ 文化を拡大できるようにします。 それにもかかわらず、それは多くを残して、いくつかの問題だけをカバーしているので、欠点がないわけではありません。 これは、ウサギの穴を下がり、重要なものを欠いている二次的な問題に貴重な時間を無駄にするのは簡単すぎるため、一貫性の問題を生み出します。 リーダーの経験は、このような状況が発生するのを防ぐ上で重要な役割を果たします。 さらに、このアプローチでは、すべてのチーム メンバーが各問題について話し合うために多くの時間が必要です。

このため、この演習のためにスプリントごとに数時間を費やしても、かなりの投資を表す可能性があります。 ほとんどのチームは全員が参加する大規模な会議で時間を無駄にする傾向があり、それらの脅威モデリング セッションは例外にならないことを誰もが知っています。 それでも、このアプローチは、チームが少数の上級メンバーで構成される小規模な製品に最適です。

別のアプローチ

前のアプローチの制限を考えると、会議の数、会議の長さ、参加者の数を制限することをお勧めします。 したがって、脅威モデルの責任は、インタビューを主導するだけでなく、脅威モデル自体を作成してメインを維持するというより重要な役割を担います。 このアプローチには、より重要なコンピテンシーと専門知識が必要です。 脅威モデリングは、セキュリティ チャンピオンまたは内部セキュリティ チームのメンバーによって表される場合があります。 セキュリティ チームは通常、完全に予約されているため、ほとんどの組織が最初に使用します。

セキュリティ チャンピオンは、セキュリティに特に関心を持つ DevOps チームのメンバーです。 彼らは決して専門家ではありませんが、基本的な知識とチームのセキュリティ体制を改善する意欲を持っています。 この考え方は、セキュリティ チャンピオンと内部セキュリティ チームの間に特権接続を作成して、最初のチームが適切な作業を行うのを支援できるようにし、セキュリティ チームがワークロードを軽減できるようにすることです。 脅威モデリングを使用すると、セキュリティ チャンピオンは脅威のモデリング担当者として機能し、内部セキュリティ チームはそれらをガイドして作業を確認する責任を負います。

今日は何ができるでしょうか？

セキュリティ チャンピオンズ プログラムを採用し、それを活用して、セキュリティで保護されたソフトウェア開発ライフサイクルをさらに強化する可能性を調査します。

サポート情報の役割

脅威モデリングの重要な問題は、脅威モデルを実行するユーザーに関係なく、エクスペリエンスの品質と DevOps チームの価値が高くなるということです。 セキュリティ チャンピオンの場合、この問題はさらに緊急になります。 これに対処する考え方は、脅威モデルの作成を推進するサポート情報を提供することです。 脅威モデリングのナレッジ ベースは、特定のコンテキストに関する情報のパッケージです。そのコンテキストに関連するエンティティの定義、それらのエンティティに対する考えられる攻撃パターン、および適用できる標準的な軽減策が含まれています。 ナレッジ ベースを使用すると、脅威のモデリング担当者を規範的な方法でガイドする参照資料を表すので、組織はより良く一貫性のある結果を得ることができます。 ナレッジ ベースには、脅威と軽減策をシステムに自動的に適用できるルールが必要です。 この自動化により、一部の脅威モデリング担当者は、脅威を適用する必要があるかどうか、または何らかの軽減策が有効かどうかを判断するために必要なエクスペリエンスを持たない可能性があるという事実を克服できます。

ナレッジ ベースは新しいアイデアではありません。現在の脅威モデリング ツールの多くは、既に何らかの形でそれらをサポートしています。 しかし、多くの現在の実装には大きな欠点があります。 たとえば、サポート情報を簡単にメインできる必要があります。 そのメイン持続性は、まだ未解決の問題です。 たとえば、構築に使用する最適な情報源を特定するのは簡単ではありません。 さらに、通常、メインテナントは手動です。 サポート情報の作成とメインの管理は、組織の内部セキュリティ チームの責任である必要があります。 今後、最も一般的な脅威モデリング ツールのサポート情報の提供を開始し、顧客からの負担の一部を解消することを期待しています。 これらのサポート情報は、最も成熟した組織による導入をサポートし、容易にするために柔軟である必要があり、そのサポート情報をプラクティス、ポリシー、および規制に適応させる必要があります。

今日は何ができるでしょうか？

さまざまな開発チームが脅威モデリングを高速化するために使用できるサポート情報を開発するために、一元化されたセキュリティ チームの取り組みの一部を割き込む可能性を検討してください。

ナレッジ ベースを使用する

サポート情報のもう1つの問題は、複雑すぎて使用できないためです。 その多くは、本質的で重要度の低い問題を含めることで、包括的な存在を試みます。 残念ながら、すべてのシステムですべてが必要なわけではありません。 分析するシステムが小さく、機密データを処理しない場合は、より簡単なアプローチを採用する必要があります。 逆に、システムが複雑で、PII とビジネス価値の高いデータを処理する場合は、さらに詳しく行く必要があります。 そのため、コンテキストに応じて異なるバージョンのナレッジを適用したり、攻撃パターンや関連する軽減策を"TOP" としてマークしたりすることができます。 その結果、脅威のモデリング担当者は、包括的なエクスペリエンスが必要かどうかを判断するか、簡単に実行して必要な作業を最小限に抑えることができます。

効率に関して言えば、必要な作業量を減らすために、アクティビティをできるだけ合理化して自動化することが不可欠です。 平均サイズのソリューションの脅威モデルを実行するスイート スポットは、脅威モデリングツールの作業の1日である必要があると考えられます。 このような結果は、選択したツールが必要な時間の短縮を可能にするアクセラレータを提供する場合にのみ可能です。 たとえば、ツールが 100の異なる場所に 20 種類の軽減策を適用し、それぞれの状態を指定するように求められた場合、後者ではなく最初の軽減策に焦点を当てることで、5 倍の効率が向上します。 選択したツールは、この機能を提供しながら、必要に応じてより徹底的なジョブを実行する可能性を付与する必要があります。

今日は何ができるでしょうか？

現在使用しているサポート情報が "TOP"の脅威と軽減策の概念をサポートしていない場合は、まれに必要なものや役に立つものを削除して、本当に重要なものだけに焦点を当てることができるようにする可能性を検討してください。

場合によっては、採用されたサポート情報が一般的であり、複数のシナリオに対応しようとしているという問題があります。 状況を特殊化することで、状況を改善できます。

正しい質問をする

分析中に、質問フレームワークをサポートするツールを使用して分析の最初のフェーズを推進する可能性を検討しました。 ほとんどの経験の浅い脅威モデリング担当者は、分析に必要な情報を得るために適切な質問をできないことに気付きました。 一部のエキスパートは、スコープ内のシステム図に基づいていくつかの重要な質問を決定することが可能であることを実証しています。 これらの質問は、いくつかの生成ルールを使用して自動的に適用することもできます。 問題は、このアプローチが約束しているように見える値を提供しない可能性があるということです。 これは、各質問の背後にある根拠を理解する必要があるためです。 それ以外の場合は、回答を評価して満足できるかどうかを判断することはできません。 それでも、自動化された質問の生成は、専門家の少ない脅威モデリング担当者に大きな価値を提供し、スコープ内のシステムに対する理解を向上させる可能性があります。

今日は何ができるでしょうか？

質問に構造化されたアプローチを採用します。 たとえば、Microsoft STRIDEを参照として採用することで、チームは良好な結果を得ました。 これを行うには、ソリューションの各コンポーネントについて次のような質問をします。

• スプーフィング： コンポーネントは、使用するサービスとリソースに対してどのように認証されますか？

• 改ざん： コンポーネントは受信したメッセージを検証しますか？ 検証は緩いか厳密か。

• 否認： コンポーネントは、監査ログ内の相互作用をログに記録していますか？

• 情報漏えい： トラフィックの送受信コンポーネントは暗号化されていますか？ 許可されるプロトコルとアルゴリズムは何ですか？

• サービス拒否： コンポーネントは高可用性で構成されていますか？ DDoS 攻撃から保護されていますか？

• 特権の昇格： ユーザーには最低限必要な特権が割り当てられますか？ ソリューションでは、通常のユーザーを対象とするコードと、高い特権を持つユーザー向けのコードが混在していますか？

このようなテクニックは教えられ、経験によって改善することができます。 そのため、学習を収集して組織内に広げるように設計された継続的なラーニングアプローチを実装することが重要です。

ROI への影響

要するに、脅威モデリング エクスペリエンスの効率、品質を向上させ、最終的に ROIを向上させるための多くのアイデアを特定することができます。 ただし、この取り組みは継続的なプロセスと見なす必要があります。これは、プラクティスの継続的な改善に向ける必要があります。

結論

脅威モデリングは、組織のセキュリティを向上させる優れた手法です。 正しく行えば、非常に合理的なコストの価値を提供できます。 Microsoft は、最新のソリューションをセキュリティで保護するために脅威モデリングの価値を向上させるために不可欠な可能性があるさまざまな手法を既に特定しています。

• 脅威モデルをDevOps プラクティスに合わせます。

  • 軽減策に重点を置く

  • 軽減策をユーザー ストーリーにリンクする

  • 脅威モデルとバックログの不一致を強調する

  • 脅威モデルを使用して、セキュリティのためのより包括的な監視と監査を推進する

• 脅威モデルの作成を簡素化し、結果の一貫性を高める

  • セキュリティ チャンピオンに依存する

  • 脅威と軽減策の識別を自動化するサポート情報を採用する

  • より優れたサポート情報の作成

  • 自動化でサポートされている質問フレームワークを提供する

できれば、それらの一部は、選択した脅威モデリング ツールで既に見つかります。 その他は今後含まれる予定です。 脅威モデリングの ROIを最大化することは、まだない回答を必要とする長期的な取り組みであることを認識しています。 また、いくつかの質問がまだ不明であることを知っています。 このホワイト ペーパーでは、思考のためのいくつかの食料を提供する必要があります。できれば、脅威モデリングを行う方法の改善に役立つ可能性があります。 私たちはそれがあなたと私たちのための灯台になることを願っています、そして、それは今後の私たちの努力を導くために役立つことを願っています。