セキュリティに関するブリーフィング

SDL 脅威のモデル化ツール入門

Adam Shostack

目次

脅威のモデル化プロセスを開始する
脅威を分析する
環境画面
レポートを追跡する
アクション メニュー
脅威のモデル化会議
資産について考える

図 1 脅威のモデル化プロセス

2008 年 11 月に、マイクロソフトはセキュリティ開発ライフサイクル (SDL) 脅威のモデル化ツールを MSDN から無料でダウンロードできるツールとして一般に公開しました。このコラムでは、チームが SDL の脅威のモデル化アプローチを開始するプロセスを説明し、新しいツールを使用して優れた脅威モデルをセキュリティ プロセスのバックボーンとして開発する方法を示します。

このコラムは、SDL の脅威のモデル化の入門書ではありません。入門書については、筆者が共同執筆した 2006 年 11 月号の MSDN Magazine で「脅威のモデル化: セキュリティ設計の欠陥を STRIDE 手法で明らかにする」の記事を参照してください。図 1 は、プロセスの概要を示しています。

脅威のモデル化プロセスを開始する

SDL 脅威のモデル化ツールを起動すると、左下隅に 4 つの画面があり、Microsoft Office Outlook によく似ていることがわかります。その画面は、ダイアグラム、分析、環境、およびレポートです (詳細については、図 2 を参照してください)。これらの画面は、図 1 に示したアウトラインとは若干異なります。脅威と対策は密接に関連しているため、まとめて検討することに意味があるからです。

このセクションでは、Deb (開発者)、Paul (プログラム マネージャ)、および Tim (テスト担当者) が最初の脅威モデルの開発プロセスを実行するようすを示し、ツールの各画面についても説明します。

「やあ、Deb。脅威モデルのダイアグラムを作ってみたんだけど、ざっと検討して詳細部分が正しいかどうかを確認する必要があるんだ」

「いいとも、Paul。さあ、どうぞこちらへ」

Paul は、図 3 に示す脅威モデル ツールの「ダイアグラムのみ」のレポートから既に作成したダイアグラムのプリントアウトを携えています。

「Paul、こんなダイアグラムは今まで見たことないよ。かなり単純に見えるけど、それぞれの形状が何を意味するのか説明してくれないか」

「この長方形は Carl といって通常の顧客なんだけど、外部エンティティとして描画されているよ。Carl は Web サーバーにコマンドを送信している。円は実行中のコードで、矢印は通信の方向を示している。Web サーバーはデータベースを調べているんだけど、データを格納する他の場所と同じく、これは 2 つの平行線で表されているね。システムはデータ フロー ダイアグラム (DFD) と呼ばれるものだよ。DFD に詳しいウィキぺディアの記事がある。そこで説明されていないのは、さまざまな人が管理している場所の間にある、信頼境界を示す点線だけだよ。たとえば、知ってのとおり IT プロフェッショナルはログイン情報を取得するために Active Directory システムを使用する必要があるから、Active Directory は管理対象外として示されている」

図 3 Paul の DFD ダイアグラム

ツールが開始すると、ダイアグラム画面が表示されます。これは、Paul が Visio ツールを使用した場所であり、DFD を描画するためのステンシルを提供します (図 4 を参照)。今回彼は初めて作業しましたが、左側のバリデータからフィードバックがあるため、SDL の一部として脅威のモデル化を使用した経験に基づいて苦もなく作業できました。描画が複雑になりがちなので、右上のコンテキスト フォルダを右クリックして詳細を追加し、複雑な階層化ダイアグラムを作成できました。

図 4 ダイアグラム画面

脅威を分析する

Paul は分析画面 (図 5 を参照) を開いたときに、少々ためらいました。その画面には脅威の長いリストがありました。これらはどこから来たものでしょうか。これは、"要素ごとの STRIDE" と呼ばれる SDL アプローチを使用して、ツールによって作成されました。つまり、ソフトウェアは一般に予測可能な脅威のセット (図 5 を参照) にさらされています。一部のセキュリティ専門家は、まずハッカーを追跡することを好みます。追跡自体を楽しめる場合があるためです。筆者は、各ドアと窓に何らかの鍵がかけられていることを確認して家の保安を開始した後でのみ、警報システムについて考える意味があると思います。そのため、分析画面のいずれかの行をクリックすることで、要素ごとの STRIDE を開始します。

図 5 分析画面

Paul は、要素の一覧でデータベースを選択することから開始しました。画面の上部で、"データベース" はデータ ストアであるため、改ざん、情報漏えい、およびサービス拒否の脅威の対象となるという記述を読みました。下の方に読み進むうちに、人々がデータを改ざんする方法について考えるのに質問が役立ち、データベースに接続できる人をだれも指定しなかったことに気付きました。ホワイトボード ダイアグラムといくつかの単純なルールによって、最初の脅威が明らかになりました。脅威のモデル化のスコア 1 です。

数分間の話し合いにより、アクセス制御とロールについて考える必要があると理解しました。Paul は、2 つの脅威を簡単にメモしました。最初のメモは、"アクセス制御計画なし" です。Team Foundation Server (TFS) データベースへの作業項目のファイリングも行いました。2 つ目のメモは、"アクセス制御計画にはロールの一覧が必要" です。Paul は、TFS を調べて、最初のバグに依存する 2 つ目のバグを作成しました。

Paul は情報漏えいについて調べたときに、アクセス制御計画に、監査およびレポート生成用の読み取り専用アカウントが必要なことに気付きました。これが新しい脅威かどうかを疑問に思い、対策が同じであり、バグは TFS で編集したため、新しい脅威ではないと判断しました。次に、脅威の対策が他の場所でとられたことを認定することに決め、"TFS バグ #235 でカバー" と記しました。これでよいかどうか確信はありませんでしたが、これが認定機能の目的です (図 6 を参照)。

図 6 脅威が適用されないことを認定する

また、情報漏えいについてもう少し考え、バックアップ テープを暗号化する必要があるが、これは運用部門のジョブであることに気付きました (どのように追跡したかについては、もう 1 つの関連機能である上部の [auto-generate threats for this element] (この要素の脅威を自動生成する) チェック ボックスについて説明した後、すぐに説明します)。

自動生成機能は、多くの脅威モデルを持ち、テスト担当者とプログラム マネージャで脅威モデルの内容について確実に話し合いが行われるようにするための方法も有する、大規模なチーム向けにデザインされています。したがって、この状況で Paul は、コンテキストについて示すいくつかの要素とそれらが機能とやり取りする方法を Phil が担当すると言うことができます。自動生成ボックスは既定でオンになっていますが、Paul はそれをオフにして、これが Phil の機能であるという考えを示すことができます。

環境画面

バックアップ テープを暗号化する操作について気にした Paul は、環境画面を開き、外部セキュリティ ノートに関するセクションを参照しました (図 7 を参照)。ここで、運用部門でテープ バックアップを処理する必要があるということをメモしました。運用部門にツールのコピーがあることを確認する必要がありました。

図 7 外部セキュリティ ノート

この画面で、ドキュメント ヘッダー セクションが何であるかを疑問に思い、上部により詳しいガイド テキストがあることを見て安心しました。このテキストでは、脅威モデルの所有者や、その目的などをここで識別することが説明されています。これを入力し、Contoso プロジェクト追跡番号が含まれるようにしたいと考えました。

ツリーの要素間を体系的に移動し、Paul は、SQL Server と Fabrikam Foxy Web Widgets 2.3 ウィジェット ライブラリに依存関係があることに気付きました。Paul は、これらを調査して最新であることを確認することと、Fabrikam からセキュリティ通知を受け取っていることの確認を Tim に依頼するようメモを追加しました。

レポートを追跡する

使用可能な脅威のモデル化レポートは 5 つあります。

分析レポート このレポートは、脅威モデルを検討するセキュリティ アドバイザまたはコンサルタント向けにデザインされていますが、だれでもこのレポートを使用して、未解決のダイアグラム検証の問題、入力されていない空の脅威、対策のない脅威、脅威を生成しないものとして認定されたまたはマーク付けされた脅威を確認できます。

脅威モデル レポート このレポートには、1 ページのビューで表される、脅威モデルに入力された情報が含まれます。

ダイアグラムのみ このレポートは、ダイアグラムを簡単に印刷するためにデザインされています。一部の人々は紙で作業することを好みますが、必要なのがダイアグラムのみの場合はレポート全体を印刷する必要はありません。

バグ レポート このレポートは、この脅威モデルからファイリングされたバグと、そのステータスを示します。

ファジー化レポート ファジー化レポートでは、ダイアグラム作成手順で提供されたアーキテクチャ情報を使用して、ファジー化対象に優先順位を付けた一覧を提供します。ファジー化は、プログラムのランダム入力の生成に関連するテスト技法です。何かをクラッシュするにはファジー化が非常に役立つこと、また、そのクラッシュの多くが悪用可能であることは驚くべきことです (ファジー テストの詳細については、「チーム システム向けにカスタム テスト インターフェイス プロバイダを作成する」または「Fuzz Testing at Microsoft and the Triage Process (マイクロソフトのファジー テストとトリアージ プロセス)」を参照してください)。

アクション メニュー

アクション メニューには、サムネイル ビュー、バグ追跡設定、チーム リード モードなど、いくつかの便利な機能があります。サムネイル ビューでは、他の画面を表示しているときに、ダイアグラムに簡単にアクセスできます。この機能は、複雑なダイアグラムがあり、モデルの分析中にそのダイアグラムを画面に表示する場合に役立ちます。ウィンドウの大部分を占めるようにサムネイルのサイズが自動的に調整されるので、サイズ変更しても、ダイアグラム全体がビューに表示されます。

バグ情報を入力しないでバグをファイリングしようとした場合は、バグ追跡ダイアログが開いてプロンプトが表示されますが、アクション メニューを使用すればいつでも開くことができます。入力が必要なフィールドの定義、またはフィールドの編集のみ ([use template] (テンプレートを使用する) ボックスがオンになっていないことが前提です) に使用できる非常に単純な XML ファイルがあります。バグのタイトルは自動的に "TM: [threat] affects [element]" (TM: [脅威] は [要素] に影響します) となり、コンテンツには脅威と対策情報が事前に入力されます。フィールドは、選択して Del キーを押すことで削除できます。

チーム リード モードでは、[Template Settings] (テンプレート設定) と呼ばれる新しいセクションが説明環境画面に表示されます。これにより、チーム リーダーは、ガイドの質問を変更したり、脅威モデルを保存するための既定の場所を設定したりできます。チーム リーダーは、ドキュメント ヘッダー情報のフィールドを編集し、環境に合わせて追加や削除を行うこともできます。

前に望んでいたように、Paul は Contoso プロジェクト追跡番号を新しいフィールドとして追加しました。チーム リード モードから保存した任意の脅威モデルは、テンプレートして使用できます (実際に、脅威モデルは追加作業のテンプレートとして機能できます)。

ガイドの質問を変更するには、SDL 脅威のモデル化ツールの \Data フォルダで開始する XML ファイルを編集します。形式はかなり簡単です。

脅威のモデル化会議

Paul が脅威モデルを周囲に送信したところ、テスト担当者である Tim はかなり失望しました。差し出されたあらゆる種類の資料を見て、Paul にたずねました。「プログラム マネージャって、いつもすべてが正常に動作することを前提としてるよね」

驚かれるかもしれませんが、テスト担当者とその懐疑的な態度によって補完されることで、脅威モデルが優れたものになります。その結果、多くのチームはテスト担当者に脅威のモデル化プロセスを主導するよう求めています。このシナリオでは、Tim は脅威モデルを引き継いだ後、2 回の脅威のモデル化会議を招集しました。1 回目の会議では、プロセスの同期をとり、ダイアグラムをひととおり検討しました。2 回目の会議では、脅威を検討し、承認しました。

最初の会議で、Tim は全員に SDL の脅威のモデル化プロセスを 10 分かけて概説しました。次に、脅威モデル ダイアグラムを掲げて、詳細な説明を開始しました。5 分以内に、重要な欠落コンポーネントが特定されました。

数分後には、Tim と Paul は Web サーバーを実際に構築する方法についての詳細な議論に入りました。会議の進め方としては理想的な方法ではありませんが、矛盾の早期発見が後々の大きな時間の節約になるということで全員が最終的に合意しました。

2 回目の会議では、チームは脅威をひととおり検討し、その対処方法について議論し、脅威モデルを承認しました。ドキュメントをソース管理にチェックインし、開発を続行しました。

資産について考える

脅威をモデル化した一部の読者は、資産についてまったく触れられていないことに気付いたかもしれません。私たちは、多くのソフトウェア エンジニアが、資産の概念や攻撃者が興味を持つ資産の種類についてよりも、ソフトウェアについてよく理解していることに気付きました。

家での脅威モデルについて考える場合は、家族またはかけがえのない写真や貴重な芸術品について考えることから開始すると思います。おそらく、押し入ってくる可能性のある人物や最新のセキュリティ システムについて考えることから開始するかもしれません。または、プールや正面ポーチなどの物理的な特徴について検討することから開始するかもしれません。これらは、資産、攻撃者、またはソフトウェア デザインについて考えるのと似ています。これら 3 つのアプローチのいずれも有効です。

ここで示した脅威のモデル化のアプローチは、マイクロソフトが過去にとったアプローチよりもはるかに単純です。マイクロソフトの SDL チームは、ソフトウェア デザイン アプローチが多くのチームで実際にうまく機能することを確認しました。あなたのチームがその中に含まれているとよいのですが。

ご意見やご質問は、briefs@microsoft.com まで英語でお送りください。

Adam Shostack は、マイクロソフトの Security Development Lifecycle (SDL) チームのプログラム マネージャです。彼は、SDL の脅威のモデル化コンポーネントを担当しています。