脅威のモデリング-軽減できない脅威を含みますか？
脅威をモデル化する場合、システムが軽減できない脅威を含める必要がありますか？
もしそうなら、どこで止めるべきですか？リストするのは非常に時間がかかる可能性がありますall軽減できない脅威。
ジョナBは物事をかなりうまくカバーしたと思いますが。もっと直接的に。
確かに「はい」と言います。
軽減できないリスクは、他のリスクと同じくらい重要です。
残留リスクは重要な指標です。これは残るリスクです後軽減。全体的なリスクを計算するときは、残りのリスクをすべて考慮に入れます。緩和策がない場合、残存リスクは初期リスクと同じです。
次に、ジョナが言うように、残留リスクとそれがビジネスにとって何を意味するかについて、組織内でオープンな議論を行う必要があります。 リスクアペタイトも理解する必要があります。組織はどのくらいのリスクを負いたいと思いますか？もちろん、これにはすべての組織的リスクを全体的に管理する必要があります。
更新：どこで停止する必要がありますか？リスクが無関係な場合。
これは、モデリングを誰のために行っているかにも依存します。シニアおよび経営幹部レベルの人々は、ビジネス全体に影響を与える高額商品のみを望んでいます。プロジェクトマネージャーは、プロジェクトの実施に影響を与える可能性のあるものをすべて望んでいます。サービスマネージャーは、ライブランニングやSLAなどに影響を与えるリスクを望んでいます。
組織の収益を年間200万ドル改善するシステム変更をモデル化している場合、1年に数百ドルの監視効果をもたらす可能性のあるリスクに関心があるかもしれません。顧客の信頼または法的な問題。
リスク管理のための単一の万能ソリューションはありません。
それはあなたがそれらを軽減できない理由とあなたがそれらを書き留めることから何を得るかによります。個々の脅威をリストするのではなく、確かにカテゴリを見つけたいと思うでしょう。
たとえば、ルートに対して防御できない可能性があります。それが引き続き発生する場合は、それを書き留めて、次のバリエーションが発生したときにそれをポイントして先に進みます。それを書き留めておくと、ラットホールから抜け出すことができるので便利です。カテゴリを書き留めたい（「ルートが勝つ」と「1.ルートはこの設定ファイルを変更できる、2。ルートはこのプロセスを停止できる...」）
多くの攻撃対象領域を含む（たとえば）Ubuntuのいくつかのリビジョンに依存しているため、多数の脅威がある可能性があります。その場合、それを書き留めておくと、Ubuntuから小さいディストリビューション。
対処できない脅威のリストは、セキュリティドキュメントの一部として役立ち（MSFTは「10の不変のセキュリティ法則」でこれを行います）、顧客やバグ発見者との関係を管理します。
コンテキスト、対象者などによって異なります。一般に、範囲は重要であり、特定の範囲では、軽減されていない重大な脅威の影響を理解する必要があります。
ビジネスまたは組織のレベルでは、軽減されていない重大な脅威は、特定の業務分野から抜け出す、追加のビジネス保険に加入する、雇用する、またはその他の戦略的行動を取るためのシグナルである可能性があります。
システムのレベルでは、軽減されていない重大な脅威がアーキテクチャの改善の領域を示唆している可能性があります。
アプリケーションのレベルでは、アプリケーションを対象とする重大な軽減されていない脅威は、通常、バックログに含まれるはずです。
アプリケーションは頻繁に変更されるため、そのレベルの脅威がアプリケーションの変更に寄与します。システムとビジネスの変化は遅くなります。これらのレベルの脅威は、絶えず再検討する必要はありません。
軽減できない脅威を含めることには明確な価値があります。脅威の軽減は、脅威を処理するための1つの方法にすぎません。脅威によってもたらされるリスクは次のとおりです。
- 回避（例：脆弱性を生み出す機能がない）
- 譲渡（例：保険）
- 軽減
- 承認済み
脅威がもたらすリスクを処理する正しい方法を選択するには、脅威（つまり、脅威が存在すること）と、それがシステムに与える可能性のある影響について知る必要があります。
軽減できない脅威を含めることが重要であるもう1つの理由は、それらの脅威がシステムに対する別の脅威（軽減できる可能性がある）のイネーブラーとして使用される可能性があるためです。