脅威モデルを作成する

トピック

 モジュールの内容
 目的
 適用対象
 モジュールの使用方法
 はじめに
 脅威モデル作成の原則
 手順 1: 資産を特定する
 手順 2: アーキテクチャの概要を作成する
 手順 3: アプリケーションを分解する
 手順 4: 脅威を特定する
 手順 5: 脅威を文書化する
 手順 6: 脅威を評価する
 脅威モデル作成後の作業
 要約
 その他のリソース

モジュールの内容

脅威モデルを作成すると、システムに影響を及ぼす可能性が最も高い脅威を体系的に特定し評価することができます。

脅威モデルの作成では、構造化されたアプローチをとります。したがって、各セキュリティ機能がどのような脅威に対処するものなのかを把握せずに無計画にセキュリティ機能を適用するよりも、はるかに効果的かつ効率的です。

このモジュールを読み、脅威モデルの作成手法を Web アプリケーションに適用すれば、アプリケーションの脆弱性を的確に把握したうえで、既存の脅威を特定および評価することができます。このように正確な情報に基づいて判断することで、既存の脅威に対して、論理的順序で適切な対策を講じることができます。つまり、最も大きなリスクをもたらす脅威から取り組みを始めることができます。

Web アプリケーションがインターネット、イントラネット、エクストラネットといった危険が潜む環境にさらされていることを考えると、100% 安全なシステムなど存在しません。このような状況に対応するためのソリューションは、脅威が存在することを認識し、それに伴って発生するリスクを軽減または管理することしかありません。脅威モデルを作成すれば、こうした分析を実行し、リスクの大きな問題に対して資金を重点的に配分できるため、投資収益率が最大化されます。

目的

このモジュールの目的は次のとおりです。

• 脅威モデルを作成する。

• 脅威の評価方法と DREAD モデルの使用方法を習得する。

• アプリケーション アーキテクチャを解析し、その脆弱性を検出する。

• 使用しているアプリケーションに関連する脅威を特定し文書化する。

適用対象

Web アプリケーション

モジュールの使用方法

このモジュールでは、アプリケーションに対する脅威を特定し文書化するための汎用的なプロセスを概説します。このモジュールから最大限の成果を得るには、以下を参照してください。

• 脅威モデルの作成プロセスを確立します。脅威モデルの作成プロセスをまだ導入していない場合は、このモジュールを導入の出発点として使用してください。そうしたプロセスを既に導入済みの場合は、このモジュールを比較のための参照用として使用してください。

• このガイドに含まれる他のモジュールも一読して、よくある脅威について知識を習得してください。ネットワーク、ホスト、アプリケーションの各レベルで頻繁に発生する脅威の概要については、モジュール 2「脅威とその対策」を参照してください。

  • ネットワークに対する具体的な脅威については、モジュール 15「ネットワークをセキュリティ保護する」の「脅威とその対策」を参照してください。

  • Web サーバー、アプリケーション サーバー、データベース サーバーに対する具体的な脅威については、モジュール 16「Web サーバーをセキュリティ保護する」、モジュール 17「アプリケーション サーバーをセキュリティ保護する」、モジュール 18「データベース サーバーをセキュリティ保護する」の各モジュールの「脅威とその対策」を参照してください。

  • アセンブリ、ASP.NET、サービス コンポーネント、リモート コンポーネント、Web サービス、データ アクセスに対する具体的な脅威については、モジュール 7「セキュリティ保護されたアセンブリを構築する」、モジュール 10「セキュリティ保護された ASP.NET ページとコントロールを構築する」、モジュール 11「セキュリティ保護されたサービス コンポーネントを構築する」、モジュール 12「セキュリティ保護された Web サービスを構築する」、モジュール 13「セキュリティ保護されたリモート コンポーネントを構築する」、モジュール 14「セキュリティ保護されたデータ アクセスを構築する」の各モジュールの「脅威とその対策」を参照してください。

• 脅威モデルを作成します。脅威モデルを早期に構築しておき、必要に応じて変更します。この作業は日々進行していきます。セキュリティ上の脅威も、アプリケーションも徐々に進化します。既知の脅威がどんなもので、その対策が講じられているかどうかを明確にする文書を作成しておけば、アプリケーションのセキュリティ対処状況を常に把握することができます。

はじめに

脅威モデルの作成プロセスを開始する前に、以下の基本用語を理解しておくことが重要です。

• 資産: 価値のあるリソース。データベース内あるいはファイル システム上のデータなど。システム リソース。

• 脅威: 悪意があるかどうかに関係なく、資産を破壊したり損なう可能性のある潜在的な発生事象。

• 脆弱性: 脅威を現実のものとする可能性のある、システムの機能や性質の弱点。脆弱性は、ネットワーク、ホスト、アプリケーションの各レベルに存在します。

• 攻撃 (または悪用): 誰かまたは何かによって実行される、資産に害を与える行為。誰かとは、脅威を遂行しようとする者、または脆弱性を悪用しようとする者です。

• 対策: 脅威に対抗しリスクを軽減するための防衛策。

家にたとえて考えてみましょう。家に置いてある宝石が資産、それを狙う泥棒が攻撃者です。ドアは家の機能であり、ドアが開いていることは脆弱性を表します。泥棒はドアが開いていることを悪用して、家の中に侵入し、宝石を盗みます。つまり、攻撃者は脆弱性を悪用して資産を手に入れるわけです。この脅威に対する適切な対策は、ドアを閉めて鍵をかけることです。

脅威モデル作成の原則

脅威モデルは一度作成すれば済むというものではありません。アプリケーション設計の初期段階から始めて、アプリケーションのライフサイクル全体を通して、何度も繰り返し行われるプロセスでなければなりません。そうしなければならない理由は 2 つあります。第一に、起こり得るすべての脅威を一度に特定するのは不可能です。第二に、アプリケーションが進化しないということはまずありません。どのようなアプリケーションであれ、ビジネス要件の変化に合わせて改善していく必要があります。それに伴い、脅威モデルの作成プロセスも手直ししなければなりません。

プロセス

図 3.1 に、6 段階のプロセスからなる脅威モデルの作成プロセスを示します。

注: 以下のプロセス アウトラインは、現在開発中のアプリケーションにも、既存のアプリケーションにも使用できます。

図 3.1
脅威モデル作成プロセスの概要

1. 資産を特定する:
   システムで保護する必要のある資産の価値を特定します。

2. アーキテクチャの概要を作成する:
   簡単な図と表を使用して、サブシステム、信頼性境界、データ フローなどを含む、アプリケーションのアーキテクチャを文書化します。

3. アプリケーションを分解する:
   基盤となるネットワークとホスト インフラストラクチャ設計を含むアプリケーションのアーキテクチャを分解し、アプリケーションのセキュリティ プロファイルを作成します。セキュリティ プロファイルの目的は、アプリケーションの設計、実装、展開構成における脆弱性を明らかにすることです。

4. 脅威を特定する:
   攻撃者の目的を意識し、アプリケーションのアーキテクチャと脆弱性を認識したうえで、アプリケーションに影響を与える可能性のある脅威を特定します。

5. 脅威を文書化する:
   各脅威に対して捕獲対象とする属性の主要項目を定義した共通の脅威テンプレートを使用して、各脅威を文書化します。

6. 脅威を評価する:
   脅威に優先順位を付け、最も重要な脅威に最初に取り組むために、脅威を評価します。これらの脅威は最も大きなリスクをもたらします。評価の過程では、発生する可能性のある脅威が実際に起こった場合の損害に重み付けします。脅威によってもたらされる危険、対処に必要なコストを比較した結果、ある脅威には対策がそれほど必要ないことが判明する場合があります。

出力

脅威モデルの作成プロセスの出力は、プロジェクト チームのさまざまなメンバのための文書です。この文書によって、対策を講じる必要がある脅威とその対策を明確に理解できます。脅威モデルは、アプリケーション アーキテクチャの定義とアプリケーションの利用ケースに応じた脅威の一覧で構成されます (図 3.2 参照)。

図 3.2
脅威モデルの構成要素

手順 1: 資産を特定する

保護しなければならない資産を特定します。保護対象の資産は、顧客または注文データベースといった機密性の高いデータから Web ページや Web サイトの可用性まで、広範囲にわたります。

手順 2: アーキテクチャの概要を作成する

この手順の目的は、アプリケーションの機能、アプリケーションのアーキテクチャと物理配置構成、ソリューションの一部を構成する技術を文書化することです。アプリケーションの設計と実装における潜在的な脆弱性を検出する必要があります。

この手順では、以下の作業を実行します。

• アプリケーションの処理内容を明確にします。

• アーキテクチャの図を作成します。

• テクノロジを特定します。

アプリケーションの処理内容を明確にする

アプリケーションの処理内容と、資産をどのように使用しアクセスするのかを明確にします。ユース ケースを文書化することで、アプリケーションの本来の使用方法を利用者が理解できるようにします。これにより、アプリケーションの間違った使用法も明確になります。ユース ケースにより、コンテキストにアプリケーションの機能を追加します。

以下に、セルフ サービス型の人事アプリケーションのユース ケースの例をいくつか挙げます。

• 社員が財務データを表示する。

• 社員が個人データを更新する。

• マネージャが社員の詳細データを表示する。

上のケースでは、ビジネス ルールが誤用される可能性があることがわかります。たとえば、あるユーザーが別のユーザーの個人データを変更しようとした場合を考えてみてください。定義済みのアプリケーション要件によると、こうした別ユーザーの個人データへのアクセスを許可してはなりません。

アーキテクチャ図を作成する

アプリケーションの構成と構造、そのサブシステム、および物理的な配置特性を記述したアーキテクチャ概要図 (図 3.3 参照) を作成します。システムの複雑さによっては、各エリアの図を追加作成しなければならない場合もあります。たとえば、中間層アプリケーション サーバーのアーキテクチャや外部システムとのやり取りをモデル化した図などです。

図 3.3
アプリケーション アーキテクチャ図の例

まず、アプリケーションとそのサブシステムの構成と構造およびアプリケーションの配置特性を表す概要図を描きます。次に、その概要図に、信頼境界、認証、承認のしくみを随時追加していきます (これは通常、手順 3 でアプリケーションを分解するときに行います)。

テクノロジを特定する

ソリューションの実装に使用されている個々のテクノロジを特定します。これは、後のプロセスでテクノロジ固有の脅威に注目する際に役立ちます。また、リスクを軽減するための正確かつ最も適切な手法を決定する際にも役立ちます。よく使用されるテクノロジとして、ASP.NET、Web サービス、Enterprise Services、Microsoft .NET Remoting、ADO.NET があります。また、アプリケーションが呼び出しているアンマネージ コードもすべて特定します。

これらのテクノロジを表 3.1 のような表を用いて文書化します。

表 3.1: 実装テクノロジ

テクノロジ / プラットフォーム	実装の詳細
Windows 2000 Advanced Server 上の SQL Server	ログイン、データベース ユーザー、ユーザー定義のデータベース ロール、テーブル、ストアド プロシージャ、ビュー、制約、トリガなど
Microsoft .NET Framework	フォーム認証に使用
Secure Sockets Layer (SSL)	暗号化 HTTP トラフィックに使用

手順 3: アプリケーションを分解する

この手順では、アプリケーションを分解して、脆弱性が問題となることが多いエリアに基づいてアプリケーションのセキュリティ プロファイルを作成します。また、信頼境界、データ フロー、エントリ ポイント、特権コードも特定します。アプリケーションの動作のしくみに対する理解度が深いほど、脅威を洗い出すのも容易になります。図 3.4 は、分解プロセスにおけるさまざまなターゲットを示しています。

図 3.4
アプリケーション分解のターゲット

この手順では、以下の作業を実行します。

• 信頼境界を特定します。

• データ フローを特定します。

• エントリ ポイントを特定します。

• 特権コードを特定します。

• セキュリティ プロファイルを文書化します。

信頼境界を特定する

アプリケーションの有形資産を囲む信頼境界を特定します。これらの資産は、アプリケーション設計によって決まります。各サブシステムについて、上位のデータ フローまたはユーザー入力が信頼できるかどうかを検討します。信頼できない場合は、データ フローまたはユーザー入力を認証および承認する方法を考えます。また、呼び出し側のコードが信頼できるかどうかを検討し、信頼できない場合は、その認証および承認方法を考えます。特定の信頼境界への入口となるすべてのエントリ ポイントが適切なゲートキーパーによって保護されていること、およびデータの受け手であるエントリ ポイントでも信頼境界を越えて渡されるすべてのデータの検証を行っていることを確認できなければなりません。

まずは、コードの観点から信頼境界の分析を行います。信頼境界の 1 つであるアセンブリの分析から始めるとよいでしょう。どのアセンブリがどのアセンブリを信頼しているのか。特定のアセンブリが呼び出しているコードを信頼しているのか。それともコード アクセス セキュリティを用いて呼び出し側のコードを承認しているのかを確認します。

サーバーの信頼関係も検討します。特定のサーバーが、上位のサーバーによってエンド ユーザーの認証と承認を行われることを信用しているのか、それとも自身でゲート キーパー サービスを提供しているのか、さらには、上位のサーバーが整形された正しいデータを渡すものと信用しているのか、といった点を確認します。

たとえば、図 3.3 では、Web アプリケーションが、固定の信頼された ID (この例では ASPNET Web アプリケーション プロセス アカウント) を使用してデータベース サーバーにアクセスしています。このシナリオでは、データベース サーバーは、アプリケーションが呼び出し側の認証と承認を行い、承認されたユーザーに代わって有効なデータ要求だけを転送してくることを信用しています。

注: .NET Framework アプリケーションでは、アセンブリが信頼の最小単位になります。データがアセンブリ境界 (定義により、アプリケーション ドメイン、プロセス、マシン境界を含む) を越えるときはいつでも、データの受け手となるエントリ ポイントでその入力データを検証する必要があります。

データ フローを特定する

まずは簡単なアプローチとして、上位レベルのデータ フロー分析から始めます。その後、個々のサブシステム間のデータ フローを分析してアプリケーションを分解していきます。たとえば、まず Web アプリケーションと Enterprise Services アプリケーション間のデータ フローを分析してから、個々のサービス コンポーネント間の分析を行います。

信頼境界を越えるデータ フローには特に注意する必要があります。自身の信頼境界の外からデータを受け取るコードは、悪意のあるデータが渡されることを考慮してデータの検証を行う必要があります。

注: データ フロー図 (DFD) およびシーケンス図はシステムの正式な分解作業に役立ちます。DFD は、データ フロー、データ ストア、データの送信側と受取側の間の関係を図で表したものです。シーケンス図は、オブジェクトのグループが協調して動作する様子を時系列で示したものです。

エントリ ポイントを特定する

アプリケーションのエントリ ポイントは攻撃のエントリ ポイントでもあります。エントリ ポイントには、HTTP リクエストを待つフロントエンド Web アプリケーションなどがあります。このエントリ ポイントはクライアントに公開することを意図したものです。これに対して、アプリケーションの階層間にまたがるサブコンポーネントに公開される内部エントリ ポイントのように、他のコンポーネントとの内部的な通信を行うために存在しているエントリ ポイントもあります。ただし、攻撃者がアプリケーションのフロントドアを迂回して内部エントリ ポイントに直接攻撃を仕掛けてくる場合に備えて、こうした内部エントリ ポイントについても、それがどこに存在し、どのような入力データを受け取っているのかを把握しておく必要があります。

エントリ ポイントごとに、承認を行うゲートキーパーの種類と検証のレベルを確認しておく必要があります。

論理的なアプリケーション エントリ ポイントとしては、Web ページが提供するユーザー インターフェイス、Web サービス、サービス コンポーネント、.NET Remoting コンポーネントが提供するサービス インターフェイス、および非同期エントリ ポイントを提供するメッセージ キューなどがあります。物理的なプラットフォーム エントリ ポイントとしては、ポートとソケットがあります。

特権コードを特定する

特権コードはセキュリティ保護された特定タイプのリソースにアクセスし、特権操作を実行します。セキュリティ保護されたリソース タイプとしては、DNS サーバー、ディレクトリ サービス、環境変数、イベント ログ、ファイル システム、メッセージ キュー、パフォーマンス カウンタ、プリンタ、レジストリ、ソケット、Web サービスがあります。セキュリティ保護された操作としては、アンマネージ コードの呼び出し、リフレクション、シリアル化、コード アクセス セキュリティ アクセス許可、コード アクセス セキュリティ ポリシー (エビデンスを含む) の操作などがあります。

特権コードには、コード アクセス セキュリティ ポリシーによって適切なコード アクセス セキュリティ アクセス許可を与える必要があります。特権コードは、自分にカプセル化されているリソースと操作が、信頼されていない、潜在的に悪意のあるコードに公開されないようにする必要があります。.NET Framework のコード アクセス セキュリティでは、スタック ウォークを行い呼び出し側のコードに与えられたアクセス許可を確認します。しかし、この動作を優先してすべてのスタック ウォークを避けなければならないことがあります。たとえば、サンドボックスを使用して特権コードの動作を制限したり、別の方法で特権コードを分離する場合です。そうしたケースでは、特権コードが格好の攻撃対象となり、悪意のあるコードが、信頼された中間コードを介して特権コードを呼び出します。

コード アクセス セキュリティによって提供されている既定のセキュリティ動作を優先する場合は常に、入念に適切な保護策を施したうえで行うようにしてください。コードをレビューしてセキュリティ上の短所がないか確認する方法については、モジュール 21「コード レビュー」を参照してください。コード アクセス セキュリティについては、モジュール 8「コード アクセス セキュリティの実践」およびモジュール 9「ASP.NET でコード アクセス セキュリティを使用する」を参照してください。

セキュリティ プロファイルを文書化する

次に、入力検証、認証、承認、構成管理の各領域、およびアプリケーションが最も脆弱になりやすいその他の領域で使用されている設計および実装方針を明確にする必要があります。これにより、アプリケーションのセキュリティ プロファイルを作成できます。

次の表に、アプリケーションの設計および実装に関するさまざまな側面を分析する際の留意点を示します。アプリケーションのアーキテクチャと設計をレビューする方法の詳細については、モジュール 5「セキュリティのためのアーキテクチャと設計レビュー」を参照してください。

表 3.2: セキュリティ プロファイルの作成

カテゴリ	留意点
入力検証	すべての入力データの検証が行われていますか。 攻撃者がアプリケーションに対してコマンドを不正に実行したり、悪意のあるデータを渡したりする可能性はありますか。 信頼境界を越えて渡されるとき、受け手であるエントリ ポイントによってデータの検証が行われていますか。 データベース内のデータは信頼できますか。
認証	資格情報がネットワークを介して渡されるときセキュリティ保護されていますか。 強力なアカウント ポリシーを使用していますか。 強力なパスワードの使用を強制していますか。 証明書を使用していますか。 ユーザー パスワードに一方向ハッシュを用いたパスワード ベリファイヤを使用していますか。
承認	アプリケーションのエントリ ポイントでどのようなゲートキーパーを使用していますか。 データベースでどのような承認方法を実施していますか。 多層防御戦略を採用していますか。 安全のため資格情報の確認に成功したときだけアクセスを許可していますか。
構成管理	アプリケーションはどのような管理インターフェイスをサポートしていますか。 管理インターフェイスはどのようにセキュリティ保護されていますか。 リモート管理はどのようにセキュリティ保護されていますか。 どの構成ストアを使用していますか。そして構成ストアはどのようにセキュリティ保護されていますか。
機密性の高いデータ	アプリケーションは機密性の高いどのデータを処理していますか。 ネットワーク上および永続ストア内で機密性の高いデータはどのようにセキュリティ保護されていますか。 どの種類の暗号化が使用されており、どのようにセキュリティ保護されていますか。
セッション管理	セッション クッキーはどのように生成されますか。 セッション ハイジャック防止にセッション クッキーはどのようにセキュリティ保護されていますか。 永続セッション状態はどのようにセキュリティ保護されていますか。 セッション状態がネットワークを介して渡されるとき、どのように保護されていますか。 アプリケーションはどのようにセッション ストアを認証しますか。 資格情報はケーブルを介して渡されますか。そしてアプリケーションによってメンテナンスされていますか。 その場合、どのようにセキュリティ保護されていますか。
暗号化	どのようなアルゴリズムと暗号化手法を使用していますか。 暗号鍵の長さとそのセキュリティ保護方法は。 アプリケーションは独自の暗号化を行っていますか。 キーが再使用される頻度はどれくらいですか。
パラメータ改ざん	アプリケーションは改ざんされたパラメータを検出していますか。 また、フォーム フィールド、ビュー ステート、cookie データ、HTTP ヘッダー内のすべてのパラメータの検証を行っていますか。
例外管理	アプリケーションはどのようにエラー条件を処理しますか。 例外のクライアントへの返送は許可されていますか。 悪用される情報を含まない汎用的なエラー メッセージを使用していますか。
監査とログ記録	アプリケーションは、すべてのサーバー上のすべての階層で監査を行っていますか。どのようにログ ファイルはセキュリティ保護されていますか。

手順 4: 脅威を特定する

この手順では、システムに影響を及ぼしたり資産を損なう可能性のある脅威を特定します。この特定プロセスを実行するには、開発チームとテスト チームのメンバが協力して、ホワイト ボードを使った詳細なブレインストーミングを行います。これは単純な方法ですが、潜在的な脅威を特定するには効果的です。チームは、アプリケーション設計者、セキュリティ専門家、開発者、テスト担当者、システム管理者で構成するのが理想的です。

基本的なアプローチは次の 2 つです。

• STRIDE を使用して脅威を特定する: 偽装、改ざん、サービス拒否といった広範な脅威の可能性を考慮し、モジュール 2「脅威とその対策」で説明した STRIDE モデルを使用して、アプリケーションのアーキテクチャと設計に関連する質問をします。これは、攻撃者の目標に注目した目標ベースのアプローチです。たとえば、「攻撃者が、サーバーまたは Web アプリケーションにアクセスするための個人識別情報を偽装する可能性はありますか」、「ネットワーク上または情報ストア内のデータを誰かが改ざんする可能性はありますか」、「誰かがサービス拒否攻撃を行う可能性はありますか」といった質問をします。

• 分類された脅威リストを使用する: このアプローチでは、まず、ネットワーク、ホスト、アプリケーション別に分類された一般的な脅威の詳細なリストを作成します。次に、その脅威リストを、自社のアプリケーション アーキテクチャと、前のプロセスで特定したすべての脆弱性に当てはめてみます。自社のシナリオに当てはまらないシナリオは即座に除外できます。

脅威特定プロセスについては、以下のモジュールが参考になります。

• ネットワーク、ホスト、アプリケーション階層別に整理された脅威のリスト、および脅威とその対策の説明については、モジュール 2「脅威とその対策」を参照してください。

• テクノロジ別の脅威のリストについては、このガイドの第 3 部の各構築モジュールの冒頭にある「脅威とその対策」を参照してください。

この手順では、以下の作業を実行します。

• ネットワークでの脅威を特定します。

• ホストでの脅威を特定します。

• アプリケーションでの脅威を特定します。

ネットワークでの脅威を特定する

これは、ネットワークの設計者および管理者が行う作業です。ネットワーク トポロジとデータ パケットの流れ、およびルーター、ファイアウォール、スイッチの構成を分析して、潜在的な脆弱性を検出します。仮想プライベート ネットワーク (VPN) のエンド ポイントにも注意を払います。モジュール 2「脅威とその対策」で特定したネットワーク層で最もよく知られている脅威に対する防御をレビューします。

設計フェーズで考慮すべきネットワークでの脅威のうち、主なものを以下に挙げます。

• 送信者の IP アドレスに依存したセキュリティ メカニズムを使用する。偽のソース IP アドレスが設定された IP パケットを送信すること (IP 偽装) は比較的簡単です。

• セッション識別子や cookie を、暗号化されていないネットワーク チャネル上に送る。IP セッション ハイジャックの危険性があります。

• クリア テキストの認証資格情報やその他の機密性の高いデータを、暗号化されていない通信チャネル上に送る。攻撃者にネットワークを監視されたり、ログオン資格情報を取得されたり、その他の機密性の高いデータを取得または改ざんされたりする可能性があります。

安全でないデバイスやサーバー構成に起因する脅威に対してネットワークが脆弱にならないようにする必要もあります。たとえば、不要なポートやプロトコルがクローズされ無効化されているか、ルーティング テーブルと DNS サーバーはセキュリティ保護されているか、サーバー上の TCP ネットワーク スタックは強化されているか、といった点を確認します。このタイプの脆弱性を防ぐ方法の詳細については、モジュール 15「ネットワークをセキュリティ保護する」を参照してください。

ホストでの脅威を特定する

このガイドでは、ホスト セキュリティ (すなわち、Microsoft Windows 2000 と .NET Framework) を構成する際に、構成を個別のカテゴリに分割して、構造化された論理的な方法でセキュリティ設定を適用できるようにするというアプローチを一貫して採用します。このアプローチは、セキュリティを見直し、脆弱性を突き止め、脅威を特定するのに理想的な方法です。すべてのサーバー ロールに適用可能な共通の構成カテゴリとして、修正プログラムとアップデート、サービス、プロトコル、アカウント、ファイルとディレクトリ、共有、ポート、監査とログ記録があります。各カテゴリについて、潜在的に脆弱な構成を特定し、そこから脅威を特定します。

考慮すべき主な脆弱性は次のとおりです。

• サーバーに修正プログラムを適用しないまま放置する。ウイルス、トロイの木馬、ワーム、よく知られた IIS 攻撃によって悪用される可能性があります。

• 不要なポート、プロトコル、サービスを使用する。攻撃の種類を増やし、攻撃者にシステム環境に関する情報を収集され悪用されます。

• 認証されていない匿名アクセスを許可する。

• 弱いパスワードとアカウント ポリシーを使用する。パスワード解読やなりすましといった攻撃につながります。また、アカウントを故意にロックできる場合はサービス拒否攻撃も受ける可能性があります。

アプリケーションでの脅威を特定する

前出の手順で、アプリケーションのアーキテクチャ、データ フロー、信頼境界を定義しました。また、アプリケーションが、認証、承認、構成管理などの主要領域を処理する方法を記述したセキュリティ プロファイルも作成しました。

ここでは、広範な STRIDE 脅威カテゴリと事前定義の脅威リストを使用して、アプリケーションのセキュリティ プロファイルの各側面を詳細に検討します。アプリケーションでの脅威、テクノロジ固有の脅威、コードでの脅威を重点的に取り上げます。考慮すべき主な脆弱性は次のとおりです。

• 入力検証が不完全である場合、クロスサイト スクリプティング (XSS)、SQL 挿入、バッファ オーバーフロー攻撃などを仕掛けられます。

• 認証資格情報や認証 Cookie を暗号化されていないネットワーク上に送ると、資格情報を取られたり、セッション ハイジャックされたりする可能性があります。

• 弱いパスワードとアカウント ポリシーを使用すると、不正アクセスにつながります。

• アプリケーションの構成管理 (管理インターフェイスを含む) のセキュリティ保護ができていない。

• 接続文字列、サービス アカウント資格情報といった構成上の機密情報をクリア テキストで格納する。

• 必要もないのに高い特権を持つプロセスやサービス アカウントを使用する。

• セキュリティ上危険なデータ アクセス コーディング手法を使用すると、SQL 挿入による脅威が増す可能性があります。

• 弱い暗号化またはカスタムの暗号化を使用しているために暗号鍵を十分にセキュリティ保護できない。

• フォーム フィールド、クエリー文字列、Cookie データ、HTTP ヘッダーなど、Web ブラウザから渡されたパラメータの整合性に依存している。

• セキュリティ上危険な例外処理を行うと、サービス拒否攻撃や攻撃者に役立つシステムレベルの詳細情報が漏れる可能性があります。

• 不十分な監査とログ記録は、否認による脅威につながります。

攻撃ツリーと攻撃パターンの利用

攻撃ツリーと攻撃パターンは、セキュリティ専門家が使用する主要なツールです。これらは、脅威の特定フェーズに不可欠なコンポーネントというわけではありませんが、役に立ちます。これらのツールを使用すると、脅威を詳細に分析し、既知の情報からさらに掘り下げて、その他の可能性を特定することができます。

重要: 前の手順で作成したカテゴリ別脅威リストでは、一般的なよく知られた脅威しかわかりません。攻撃ツリーと攻撃パターンを使用したアプローチを追加すると、その他の潜在的な脅威を特定するのに役立ちます。

攻撃ツリーとは、システムに対する潜在的な攻撃を、構造化された階層的な手法で収集および文書化する方法のことです。ツリー構造によって、攻撃者がシステムに危害を加えるために使用するさまざまな攻撃を説明的に分解することができます。攻撃ツリーを作成すれば、セキュリティ問題を再利用可能な形で表現できるため、対応策に集中できます。テスト チームはテスト計画を立てることで、セキュリティ設計を検証できます。開発者は実装時にさまざまな設計上のバランスをとることができ、設計者と開発者が率先して代替アプローチのセキュリティ費用を評価できます。

攻撃パターンとは、エンタープライズ環境内で攻撃情報を捕捉するための正式なアプローチです。これらのパターンを使用すれば、一般的な攻撃手法を特定できます。

攻撃ツリーを作成する

実際にはいくつかのアプローチが使用できますが、よく使用されるのは、攻撃の主目的と準目的、および攻撃を成功させるために何を実行する必要があるのかを特定するというアプローチです。攻撃ツリーを表現するには、階層図か簡単なアウトラインを使用します。最終的に重要なのは、アプリケーションの攻撃プロファイルを何らかの形で表現することです。そうすることで、起こり得るセキュリティ上のリスクを評価し、そうしたリスクを適切な対策、たとえば、設計方法の修正、構成設定の強化といった対策によって軽減できます。

攻撃ツリーを作成するには、まず、攻撃者の目的を表すルート ノードを作成します。次に、リーフ ノードを追加します。これは一意な攻撃を表す攻撃方法に相当します。図 3.5 に簡単な例を示します。

図 3.5
攻撃ツリーの説明

リーフ ノードには、"AND" ラベルまたは "OR" ラベルを付けることができます。たとえば、図 3.5 では、1.1 と 1.2 の両方が起こらなければ、脅威が実際の攻撃につながることはありません。

このような攻撃ツリーは、すぐに複雑になってしまう傾向があります。また、作成するのに時間もかかります。このため、以下に示すようなアウトラインを使用して攻撃ツリーを作成する代替アプローチを好んで使用するチームもあります。

1.  目標 1
1.1 準目標 1
1.2 準目標 2
2.  目標 2
2.1 準目標 1
2.2 準目標 2

注: 攻撃ツリーには、目標と準目標に加えて、方法や必要な条件も含まれます。

以下に、アウトライン方式の実例を示します。

脅威 #1 攻撃者がネットワークを監視して認証資格情報を取得する
1.1 クリア テキストの資格情報がネットワーク上に送出される AND
1.2 攻撃者がネットワーク監視ツールを使用する
1.2.1 攻撃者が資格情報データを認識する

完全な例については、このガイドの「チャート シート」にある「攻撃ツリーの例」を参照してください。

攻撃パターン

攻撃パターンとは、さまざまな異なるコンテキストで発生する、よくある攻撃の汎用的な表現です。攻撃パターンは、攻撃の目標、現実に攻撃を行うために必要な条件、攻撃に必要な手順、および攻撃の結果を定義します。STRIDE ベースのアプローチでは攻撃者の目標に注目しますが、攻撃パターンでは攻撃の手法に注目します。

攻撃パターンの例として、コード挿入のケースを考えてみます。このパターンは、コード挿入攻撃を汎用的な方法で記述するために使用されます。表 3.3 に、コード挿入攻撃パターンを記述します。

表 3.3: コード挿入攻撃パターン

パターン	コード挿入攻撃
攻撃の目標	コマンドまたはコードの実行
必要な条件	脆弱な入力検証 攻撃者の実行するコードがサーバー上で十分な特権を持っていること。
攻撃の手法	1. 脆弱な入力検証を実行しているターゲット システム上のプログラムを特定します。 2. 挿入するコードを作成し、ターゲット アプリケーションのセキュリティ コンテキストを使用して実行します。 3. 入力値を作成してコードをターゲット アプリケーションのアドレス空間に挿入し、スタックを強制的に破壊して、アプリケーションの実行を挿入コードにジャンプさせます。
攻撃の結果	攻撃者のコードが起動され、悪意のある処理が実行されます。

攻撃パターンの詳細については、このモジュールの最後の「関連情報」に記載されている情報を参照してください。

手順 5: 脅威を文書化する

アプリケーションでの脅威を文書化するには、以下に示すような脅威属性を示すテンプレートを使用します。脅威の記述と脅威のターゲットは不可欠な属性です。この段階では、リスク評価は空白のままにしておきます。これは脅威モデル作成プロセスの最終段階で、特定された脅威リストに優先度を付ける際に使用します。その他の属性として、攻撃手法 (悪用される脆弱性を明確にする意味もある) と脅威に対応するために必要な対策があります。

表 3.4: 脅威 1

脅威の説明	攻撃者はネットワークを監視して認証資格情報を取得
脅威の対象	Web アプリケーションのユーザー認証プロセス
リスク
攻撃の手法	ネットワーク監視ソフトウェアの利用
対策	SSL を使用してチャネルを暗号化します。

表 3.5: 脅威 2

脅威の説明	SQL コマンドの挿入
脅威の対象	データ アクセス コンポーネント
リスク
攻撃の手法	攻撃者はユーザー名に SQL コマンドを付加します。このユーザー名を使用して SQL クエリーを作成します。
対策	ユーザー名の検証を行う正規表現を使用します。また、パラメータを介してデータベースにアクセスするストアド プロシージャを使用します。

手順 6: 脅威を評価する

ここまでの手順で、特定のアプリケーション シナリオに当てはまる脅威のリストができあがりました。プロセスの最後の手順では、脅威がもたらすリスクに基づいて脅威を評価します。これにより、最初に最もリスクが大きい脅威の対策を施してから、他の脅威の対策に移ることができます。実際、特定されたすべての脅威に対策を施すことはコスト的に不可能ですので、発生確率が低いものや発生したとしても最小限の損害で済むものについては無視するという判断を下すこともあります。

リスク = 発生確率 * 潜在的損害の大きさ

この公式は、特定の脅威によってもたらされるリスクは、脅威が発生する可能性に潜在的損害の大きさ (攻撃されたときにシステムが受ける損害) を掛けることで算出できることを示しています。

発生確率は 10 段階で評価します。1 は、脅威が実際に発生する可能性が非常に小さいことを表し、10 はほとんど確実に発生することを表します。同様に、潜在的損害の大きさも 10 段階で評価します。1 は最小限の損害、10 は壊滅的な損害を表します。この公式を使用すると、発生確率は低いが潜在的損害は大きい脅威と、潜在的脅威はそれほどでもないが発生確率は非常に高い脅威とで、もたらされるリスクがほぼ等しくなります。

たとえば、発生確率=10 で 潜在的損害の大きさ = 1 の場合、リスク = 10 * 1 = 10 になります。逆に、発生確率 = 1 で 潜在的損害の大きさ = 10 の場合も、リスク = 1 * 10 = 10 でリスクの大きさは同じになります。

この公式ではリスクを 100 段階で評価することになるため、おおまかに評価値を 3 つに分けて高、中、低のリスクを評価します。

高、中、低の各評価

高、中、低の 3 段階で脅威の対策優先度を評価します。「高」レベルの脅威は、アプリケーションに重大なリスクをもたらすため、早急に対策を講じる必要があります。「中」レベルの脅威は対策を講じる必要はありますが、緊急度は高くありません。「低」レベルの脅威は、対策を講じるために必要な作業量とコストの大きさによっては無視することもできます。

DREAD

こうした簡単な評価システムでは通常、チームの各メンバ間で評価が一致しないため問題となります。これを解決するには、セキュリティ上の脅威による影響が実際にどの程度になるのかを判定できるように、新しい評価軸を追加します。マイクロソフトでは、DREAD モデルを使用して脅威を評価しています。DREAD モデルを使用すれば、以下の質問をすることで特定の脅威に対するリスク評価を算出できます。

• 潜在的損害の大きさ (Damage potential): 脆弱性を悪用された場合にどの程度の損害を被りますか。

• 再現性 (Reproducibility): どのくらい簡単に攻撃を再現できますか。

• 悪用性 (Exploitability): どのくらい簡単に攻撃を開始できますか。

• 影響を受けるユーザー (Affected users): 大まかにどのくらいの割合のユーザーが影響を受けますか。

• 検出可能性 (Discoverability): どのくらい簡単に脆弱性を検出できますか。

上記の各観点から脅威を評価します。必要に応じて質問の数を増やすこともできます。たとえば、顧客信頼度の潜在的な低下に関する質問を追加してもよいでしょう。

顧客信頼度 (Reputation): どのくらいの資金が必要ですか。会社の評判が損なわれ、顧客信頼度の喪失につながる可能性がありますか。

評価段階はあまり細かくする必要はありません。評価段階を増やすと、他の脅威との比較において一貫性を維持した評価が難しくなります。高 (1)、中 (2)、低 (3) などの簡単な評価方式を採用してください。

各値が評価システムにおいて何を表すのかを明確に定義すると、混乱を避けることができます。表 3.6 に、評価表の典型的な例を示します。この表は、脅威の優先度を付ける際にチーム メンバによって参照されます。

表 3.6: 脅威評価表

	評価項目	高 (3)	中 (2)	低 (1)
D	潜在的損害の大きさ	攻撃者はセキュリティ システムの破壊、完全な信頼承認の取得、管理者権限での操作の実行、コンテンツのアップロードが可能。	機密性の高い情報の漏洩	価値の低いデータの漏洩
R	再現性	攻撃は毎回再現可能。特定のタイミングを狙う必要がない。	攻撃は再現できるが、特定のタイミングと競合状態が必要。	セキュリティ ホールを知っていたとしても攻撃の再現は非常に難しい。
E	悪用性	経験の浅いプログラマでも短時間で攻撃が可能。	技術力のあるプログラマであれば攻撃が可能。攻撃を簡単に繰り返すこともできる。	攻撃のたびに極めて高い技術力と深い知識が必要。したがって攻撃を簡単に繰り返すことはできない。
A	影響を受けるユーザー	すべてのユーザー、既定の構成、主要な顧客	一部のユーザー、既定外の構成	極めて少数のユーザー、よく知られていない機能、匿名ユーザーに影響を与える。
D	検出可能性	公開情報によって攻撃が説明されている。脆弱性はごく一般に使用されている機能に見つかるため、すぐに気付く。	脆弱性は製品の滅多に使用されない部分に潜んでおり、少数のユーザーしか気付かない。悪意のある使い方かどうかを判断するには若干考える必要がある。	バグの存在が不明確で、ユーザーが潜在的な損害を解明することもまずない。

上の質問に答えたら、特定の脅威についてその評価値を計算します。結果は、5 ～ 15 の間に収まります。総合評価値が 12 ～ 15 の脅威は「高」レベル、8 ～ 11 の脅威は「中」レベル、5 ～ 7 の脅威は「低」レベルと見なすことができます。

たとえば、以前に説明した 2 つの脅威について考えてみます。

• 攻撃者がネットワークを監視して認証資格情報を取得します。

• SQL コマンドをアプリケーションに挿入します。

表 3.7 に、この 2 つの脅威を DREAD を使用して評価した例を示します。

表 3.7: DREAD 評価

脅威	D	R	E	A	D	合計	評価項目
攻撃者がネットワークを監視して認証資格情報を取得する	3	3	2	2	2	12	高
SQL コマンドをアプリケーションに挿入する	3	3	3	3	2	14	高

リスクの評価値を算出したら、文書化された脅威を更新して評価レベルを追加します。上の 2 つの脅威の評価レベルはどちらも「高」です。表 3.8 に例を示します。

表 3.8: 脅威 1

脅威の説明	攻撃者がネットワークを監視して認証資格情報を取得
脅威の対象	Web アプリケーションのユーザー認証プロセス
リスク評価	高
攻撃の手法	ネットワーク監視ソフトウェアの利用
対策	SSL を使用してチャネルを暗号化します。

脅威モデル作成後の作業

脅威モデル作成プロセスの成果物には、アプリケーション アーキテクチャのセキュリティ面の文書化と評価された脅威のリストがあります。脅威モデルを使用すれば、開発チームのメンバ同士が協調して、最も影響の大きい脅威に対する対策に集中できます。

重要: 脅威モデルの作成は対話的なプロセスです。脅威モデルは、時間と共に進化する文書です。また、各チームのメンバが行う作業の基準にもなります。

脅威モデルは、以下の職種の人々が使用します。

• 設計者は、テクノロジと機能の両面でセキュリティ上安全な設計を選択するために、脅威モデルを使用します。

• コードを書く開発者は、リスクを軽減するために脅威モデルを使用します。

• テスターは、テスト ケースを作成して、脅威モデルによる分析によって特定された脅威に対してアプリケーションが脆弱かどうかをテストします。

作業報告書を作成する

初期の脅威モデルを基に、属性が追加された作業報告書を作成します。たとえば、バグ ID を属性として追加すると、常用しているバグ追跡システムに脅威を関連付けることができます。実際、特定された脅威をバグ追跡システムに入力し、同システムのレポート機能を使用してレポートを生成できます。また、バグが修正されたかどうかを示す情報をレポートに含めることもできます。このレポートには、元の脅威番号を含めることで、脅威を脅威モデル文書に関連付けられるようにしておく必要があります。

レポートでは、ネットワーク、ホスト、アプリケーション別に脅威を整理してください。これにより、どのロールのどのチーム メンバにとっても使いやすいレポートになります。各カテゴリ内には、対策優先度順に (リスク評価の高いものから順に) 脅威を提示します。

要約

攻撃のリスクを軽減することはできても、実際の脅威が軽減または排除されるわけではありません。どのようなセキュリティ アクションを実行し、どのような対策を施しても、脅威は依然として存在します。セキュリティ保護の現実とは、脅威の存在を認識して、リスクを管理することです。脅威モデルを作成すると、チーム全体でセキュリティ上のリスクを管理および伝達できます。

脅威モデルの作成は対話的なプロセスです。脅威モデルは、時間の経過と共に変化する動的なものでなければなりません。新たな脅威や攻撃が見つかり次第、それらに対応する必要があります。また、アプリケーションは、ビジネス要件の変化に対応するために改良または修正されます。脅威モデルは、こうしたアプリケーションの自然な進化にも適応できなければなりません。

その他のリソース

関連する文献として、次のリソースを参照してください。

• 攻撃パターンの詳細については、Andrew P. Moore、Robert J. Ellison、Richard C. Linger 共著「Attack Modeling for Information Security and Survivability」(英語) (http://www.cert.org/archive/pdf/01tn001.pdf) を参照してください。

• 脅威、資産、脆弱性の評価については、Carnegie Mellon Software Engineering Institute のサイトにある「Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) Framework, Version 1.0」(英語) (http://www.sei.cmu.edu/publications/documents/99.reports/99tr017/99tr017figures.html) を参照してください。

• 脅威モデル作成の概要については、「Architect WebCast: Using Threat Models to Design Secure Solutions」(英語) (http://www.microsoft.com/usa/webcasts/ondemand/1617.asp) を参照してください。

• DFD の作成方法の詳細については、Michael Howard、David C. LeBlanc 共著『Writing Secure Code, Second Edition』を参照してください。