Threat Modeling Tool の概要
Microsoft Threat Modeling Tool 2018 は、無料で クリックしてダウンロードできる ツールとして 2018 年 9 月に GA としてリリースされました。 配布のしくみが変わり、ユーザーがツールを開くたびに、最新の改善とバグの修正をプッシュできるようになりました。そのため、保守と使用が簡単になりました。 この記事では、Microsoft SDL 脅威モデリング アプローチの基本的なプロセスについて説明します。また、ツールを使用して、セキュリティ プロセスのバックボーンとして優れた脅威モデルを作成する方法について説明します。
この記事は、SDL の脅威モデリング アプローチの既存の知識に基づいています。 短時間で復習するには、「Web アプリケーションの脅威モデル」と、2006 年に公開されたアーカイブ版の MSDN 記事「Uncover Security Flaws Using the STRIDE Approach」(STRIDE アプローチを使用してセキュリティ上の欠陥を見つける) を参照してください。
簡単にまとめると、このアプローチにはダイアグラムの作成、脅威の特定、脅威の軽減、各軽減策の検証が含まれます。 このプロセスをまとめた図を次に示します。
脅威のモデリング プロセスを開始する
Threat Modeling Tool を起動すると、次の図のようにいくつかの点に気づきます。
[Threat model](脅威モデル) セクション
| コンポーネント | 詳細 |
|---|---|
| [Feedback, Suggestions and Issues](フィードバック、提案、問題) ボタン | すべての SDL の MSDN フォーラム が表示されます。 他のユーザーが実行していること、回避策、推奨事項を読むことができます。 探している情報が見つからない場合は、サポート チーム (tmtextsupport@microsoft.com) に電子メールで問い合わせてください。 |
| Create a Model (モデルの作成) | ダイアグラムを描画できる空白のキャンバスが開きます。 実際のモデルで使用したいテンプレートを選択してください。 |
| Template for New Models (新しいモデル用のテンプレート) | モデルを作成する前に、テンプレートを選択する必要があります。 メインのテンプレートは Azure Threat Model Template です。Azure 固有のステンシル、脅威、軽減策が含まれています。 汎用的なモデルの場合は、ドロップダウン メニューから [SDL TM Knowledge Base](SDL TM ナレッジ ベース) を選択します。 独自のテンプレートを作成する場合、または全ユーザーが使用できるように新しいテンプレートを提出する場合は、 「 Template Repository 」(テンプレート レポジトリ) GitHub ページで詳細を確認してください。 |
| Open a Model (モデルを開く) | 以前に保存した脅威モデルを開きます。 [Recently Opened Models](最近開いたモデル) 機能は、最近使ったファイルを開く必要がある場合に便利です。 この項目にマウスを移動すると、モデルを開く方法が 2 つ表示されます。
|
| ファースト ステップ ガイド | Microsoft Threat Modeling Tool のメイン ページを開きます |
[Template](テンプレート) セクション
| コンポーネント | 詳細 |
|---|---|
| Create New Template (新しいテンプレートの作成) | 基礎となる空白のテンプレートが開きます。 テンプレートをゼロから構築できる豊富な知識を持っていなければ、既存のテンプレートから作成することをお勧めします |
| Open Template (テンプレートを開く) | 変更を加えることができる既存のテンプレートを開きます |
Threat Modeling Tool チームはツールの機能と操作性を改善するために常に取り組んでいます。 その過程で軽微な変更がいくつか加えられる可能性がありますが、重大な変更の場合は必ずこのガイドが改訂されます。 最新のお知らせを確認するために、ガイドを頻繁に確認してください。
モデルの構築
ここでは、次の 3 人を例にして説明します。
- 佐藤さん (開発者)
- 高橋さん (プログラム マネージャー)
- 山本さん (テスト担当者)
3 人は 1 つ目の脅威モデルの開発プロセスを実行しています。
高橋:佐藤さん、脅威モデル ダイアグラムを編集しているところなのだが、詳細な部分が正しいことを確認したい。 確認を手伝ってもらえないだろうか。 佐藤:そして、 見せてください。 高橋さんがツールを開き、画面を佐藤さんと共有します。
佐藤:単純に見えますが、簡単に説明していただけますか。 高橋:もちろんです。 内訳を説明する。
- 人間のユーザーは外部エンティティ (四角形) で描画されている
- ユーザーはコマンドを会社の Web サーバー (丸) に送信する
- Web サーバーはデータベースに問い合わせる (2 本の並列の線)
高橋さんが佐藤さんに表示しているものは DFD です。DFDは Data Flow Diagram (データ フロー ダイアグラム) の短縮形です。 ユーザーは Threat Modeling Tool を使用して、異なるエンティティが管理されている場所を示す信頼の境界 (赤の点線) を指定できます。 たとえば、IT 管理者は、認証目的で Active Directory システムを必要としているため、Active Directory は管理の範囲外です。
佐藤:適切な内容だと思います。 脅威はどうですか。 高橋:説明しよう。
脅威の分析
彼がアイコン メニューの選択から分析ビュー (虫眼鏡のあるファイル) をクリックすると、既定のテンプレートに基づいて Threat Modeling Tool が検出し、生成した脅威の一覧が表示されます。このテンプレートでは、STRIDE (スプーフィング、改ざん、否認、情報漏えい、サービス拒否、特権の昇格) という SDL アプローチを使用しています。 STRIDE は、予測可能な特定の組み合わせ脅威をソフトウェアが受け、脅威はこれら 6 つのカテゴリを使用して検出できる、という考えです。
このアプローチは、自宅を守るために、アラーム システムを追加したり、泥棒を追いかける前に、個々のドアと窓にロックのしくみを確実に持たせることに似ています。
高橋さんは一覧の最初の項目を選択します。 これは次のように動作します。
まず、2 つのステンシル間の相互作用が強調表示されます
次に、脅威に関する詳細情報が [Threat Properties](脅威のプロパティ) ウィンドウに表示されます
高橋さんは生成された脅威を見て、設計の欠陥の可能性が把握できます。 STRIDE カテゴリは、攻撃ベクトルの可能性に関するヒントになります。また、詳細な説明で、問題のある点とその軽減策の案を正確に把握できます。 高橋さんは編集可能なフィールドを使用して、理由の詳細にメモを書き込んだり、組織のバグ バーに基づいて優先度を変更したりすることができます。
Azure テンプレートの詳細情報には、説明、例、Azure 固有のドキュメントのハイパーリンクが追加されているので、問題のある点だけでなく、修正方法もユーザーが把握できます。
高橋さんはこの説明から、対応が必要な最初の脅威がわかり、ユーザーのなりすましを防ぐために認証メカニズムを追加する重要性に気づきました。 高橋さんは佐藤さんと数分話し合い、2 人はアクセス制御とロールを実装する重要性を把握しました。 高橋さんは、確実に実装されるように簡単なメモを入力しました。
高橋さんは情報漏えいの脅威を確認し、アクセス制御計画に、監査とレポート生成目的の読み取り専用アカウントがいくつか必要であることに気づきました。 これを新しい脅威にするべきかどうかは迷いましたが、軽減策は同じなので、それに従って脅威についてメモしました。 また、情報漏えいについても少し考え、バックアップ用のテープに暗号化が必要であることに気づきました。これは運用チームの仕事です。
既存の軽減策またはセキュリティの保証は、[Status](状態) ドロップダウンから [Not Applicable](適用不可)に変更できるため、脅威は設計に適用されません。 他にも 3 つの選択肢があります。[Not Started](未着手) は既定の選択です。[Needs Investigation](要調査) は項目のフォロー アップに使用されます。[Mitigated](軽減済み) は対策が完了したことを示します。
レポートと共有
高橋さんは佐藤さんと一覧を検討し、重要なメモ、軽減策/理由、優先度、状態の変更を追加し、[レポート] -> [フル レポートの作成] -> [レポートの保存] の順に選択します。これで、同僚との検討に利用できる良質なレポートが印刷され、適切なセキュリティ対策を確実に実施することができます。
印刷するのではなく、ファイルを共有したい場合は、組織の OneDrive アカウントに保存することで簡単に共有できます。 OneDrive アカウントに保存したら、ドキュメントのリンクをコピーし、同僚と共有することもできます。
脅威モデリングのミーティング
高橋さんはOneDrive を使用して脅威モデルを同僚に送信しましたが、テスト担当者の山本さんはがっかりしました。 高橋さんと佐藤さんは、簡単に侵入される可能性がある重要なレア ケースをいくつか見逃しているようです。 山本さんの懐疑的な見方は、脅威モデルを補完するものです。
このシナリオでは、山本さんが脅威モデルを引き継ぎ、2 つの脅威モデリング ミーティングの開催を呼びかけました。1 つは、プロセスについて考えを合わせ、ダイアグラムの概要を説明するミーティングです。もう 1 つは、脅威のレビューと承認のためのミーティングです。
1 つ目のミーティングで、山本さんは SDL の脅威モデリング プロセスについて 10 分間で概要を説明しました。 次に、脅威モデル ダイアグラムを見せ、詳細な説明を始めました。 5 分以内に、欠落している重要なコンポーネントが特定されました。
さらに数分後、山本さんと高橋さんは Web サーバーの構築方法について詳細な議論を始めました。 理想的なミーティングの進め方ではありませんでしたが、最終的には、早期に矛盾を見つけることで、将来的に時間を節約できるということに全員が合意しました。
2 つ目のミーティングで、チームは脅威を検証し、その対応方法についていくつか話し合い、脅威モデルを承認しました。 このドキュメントはソース管理にチェックインし、作成が継続されました。
資産について考える
脅威をモデル化したことがある場合は、この記事で資産についてまったく触れていないことに気づかれたかもしれません。 多くのソフトウェア エンジニアは、自作のソフトウェアほど、資産の概念や攻撃者が興味を持つ資産の内容を理解していないことがわかっています。
家の脅威をモデル化する場合、まず家族、かけがえのない写真、貴重な芸術作品について考えるのではないでしょうか。 侵入者像や、現在のセキュリティ システムから考えるかもしれません。 または、プールや正面ポーチなど、物理的な機能の検討から始めるかもしれません。 これは、資産、攻撃者、またはソフトウェア設計について考える場合と似ています。 これら 3 つのアプローチのすべてが役立ちます。
ここで紹介した脅威モデリングのアプローチは、Microsoft が過去に実行したアプローチよりもはるかに単純です。 ソフトウェア設計アプローチは、多くのチームに適していることがわかっています。 その中に皆さんも含まれることを願っています。
次の手順
ご質問、ご意見、懸念事項は tmtextsupport@microsoft.com に送信してください。 Threat Modeling Tool をダウンロード すると、すぐに使い始めることができます。