脅威モデリングツールと代替脅威
利用可能な脅威モデリングツール（脅威モデリング用のMicrosoft SDLはおそらく最もよい例です）を見ると、低レベルの脅威のみを考慮しているようで、主に開発者向けであると感じています。
システムの脅威は攻撃者だけのものではなく、クラウド上の脅威には、ロケーションやサービスベースの脅威が含まれる可能性があります（たとえば、法律によっては、特定の管轄区域内に特定の種類のデータを保持する必要がある場合があります。この種の脅威も、前述のツールで特定されたような「低レベル」ではなく、より中程度のレベルです。これらの種類の脅威は、私が見つけることができるツールには表示されていないようで、攻撃者以外のソースからの脅威でもありません。私の質問は次のとおりです。
「脅威モデリング」は、脅威を低レベルからのみ見るプロセスであり、開発者向けのプロセスと見なされていますか？これは、これらのツールがどのように機能するかを見ると理解できるからです。それとも、これらのツールは主に開発者によって使用されるため、開発者や同じように考えている人々の視点を優先するようになっただけなのでしょうか。
他の種類の脅威に関する情報を提供するツールが不足しているのではないでしょうか？おそらく、脅威と脆弱性のより高いレベルの見方を考慮したツールでしょうか？または、非攻撃者からの脅威だけでなく攻撃者からの脅威も考慮するものですか？ STRIDEやDREADなどの手動プロセスを使用すると、脅威を好きなレベルで特定できることを知っていますが、これを行うツールについて知りたいと思っています。
マイクロソフトのツールが開発者向けであることは、あなたの言うとおりです。 v3 SDLツールを開発したとき、開発者が知っている可能性があることに焦点を当てたかったのです。管轄権の管理は、他の場所から来る必要がある要件です。したがって、質問1では、現在のMicrosoft脅威モデリングツールは開発者に焦点を当て、開発者のニーズに優先順位を付けています。私の本で説明しているように、脅威モデリングは誰でもできることであり、誰もがすべきことです。残念ながら、非常に技術的な範囲外の攻撃モデルはあまり開発されていません。
[どうやら、私はコメントすることが許可されていないので、質問2にもう少し追加します。「その他の種類の脅威」の範囲を定義すると非常に役立ちます。脅威のモデリングプロセスを沈める可能性のあるものの1つは、何も実行できない一連の脅威です。 STRIDEで見つかる脅威の多くは、開発者が対処できます。 ＃2でどのスコープを探していますか？]
マイクロソフトは、「脅威モデリング」で「脅威」という言葉を使用するときに誤った用語を使用していました。 Cigitalは、この誤った用語を「アーキテクチャリスク分析」に置き換えました。リスク分析を処理するための最良のモデルは、情報リスクの要因分析（FAIR）です。その後、その概念をアプリ開発またはソフトウェア構築に適用するだけで済みます。
この領域のツールについては、必ずチェックアウトしてください