この文書は2016年以降更新されていません
攻撃対象領域分析に関するチートシート
|
最終改訂日 (yy/mm/dd):2015/07/18 攻撃対象領域分析とは何か、なぜ重要なのかこの資料では、攻撃対象領域分析の実行とアプリケーションの攻撃対象領域の管理について、簡単で実用的な方法を説明します。この資料は、開発者によるアプリケーション設計 / 変更時のアプリケーションセキュリティのリスクの理解と管理および、アプリケーションセキュリティ専門家によるセキュリティリスク評価のための使用を目的としています。ここでの重点は、外部の攻撃からアプリケーションを保護することにあります。システムのユーザーやオペレーターに対する攻撃については考慮していません (マルウェアインジェクション、ソーシャルエンジニアリング攻撃など)。また、内部脅威にも重点は置いていませんが、方針は類似しています。内部的な攻撃対象領域は、外部的な攻撃対象領域とは異なることがあり、一部のユーザーが多数のアクセスを行う可能性があります。 攻撃対象領域分析とは、セキュリティの脆弱性について、レビューとテストが必要になるシステムの部分を明確に示すことです。攻撃対象領域分析の要点は、アプリケーションのリスク領域を理解し、攻撃に対して無防備なアプリケーション部分を開発者とセキュリティ専門家に認識させ、無防備な部分を最小化する方法を見つけ出し、攻撃対象領域の変更がいつどのように起こり、リスクの観点からどのような意味を持つのかを把握することです。 攻撃対象領域分析は通常、セキュリティアーキテクトと侵入試験担当者が実行します。ただし、開発者は、システムの設計、構築、変更の際に攻撃対象領域について理解し、監視する必要があります。 攻撃対象領域分析は、以下のことに役立ちます。
アプリケーションの攻撃対象領域の定義攻撃対象領域は、攻撃者がシステムに侵入したり、データを持ち出したりする可能性のある各種ポイントのすべてを表します。 アプリケーションの攻撃対象領域は、以下のようなものです。
認可されているかどうかにかかわらず、システムにアクセスする各種のユーザー (ロールや特権レベル) を、このモデルに配置します。ユーザーの種類が増えると複雑さが増します。ただし、特に重要なのは、認証されていない匿名ユーザーと、高度な特権管理ユーザー (データベース管理者やシステム管理者など) という両極端のユーザーに焦点を合わせることです。 各種攻撃ポイントをリスク (外部に対するものと内部に対するもの)、目的、実装、設計、およびテクノロジーに基づいて、バケットにグループ化します。その後、各種攻撃ポイントの数を数えて、それぞれの種類にいくつかの事例を選択し、事例に焦点を合わせてレビューと評価を行います。 このアプローチにより、システムの攻撃対象領域と潜在的なリスクプロファイルを理解するために、すべてのエンドポイントを把握する必要がなくなります。代わりに、異なる一般的な種類のエンドポイントと、各種のポイントの数を数えることができます。これにより、さらに大きな規模でのリスク評価にかかる予算配分が可能になり、アプリケーションのリスクプロファイルが大幅に変化した時期がわかるようになります。 攻撃対象領域の特定とマッピング攻撃対象領域について、図と注釈によるベースラインの説明書の作成を開始します。数時間を費やして、攻撃者の視点で設計書とアーキテクチャ文書をレビューします。ソースコードを見渡して、次に示す、さまざまな入出力のポイントを特定します。
異なる攻撃ポイントの総数は、すぐに数千以上になり得ます。これを管理できるようにするには、機能、設計、およびテクノロジーに基づいて、このモデルを以下のように異なる種類に分割します。
アプリケーション内の重要データ (守秘、機密、規制対象など) を特定することも必要です。そのために、システムの開発者とユーザーに聞き取り調査を行い、ソースコードをもう一度レビューします。 また、アプリケーションを精査して、攻撃対象領域の図を作成することもできます。Web アプリケーションについては、OWASP_Zed_Attack_Proxy_Project や Arachni、Skipfish、w3af などのツール、または多数ある市販の動的テストおよび脆弱性スキャンツールを使用して、アプリケーションをクロールし、Web からアクセスできるアプリケーション部分をマップすることができます。一部の Web アプリケーションファイアウォール (WAF) には、アプリケーションのエントリポイントのモデルをエクスポートできるものもあります。 システムの主な使用事例のいくつかをウォークスルーして、攻撃対象領域に関する理解を検証して確認します。この使用事例としては、サインアップやユーザープロファイルの作成、ログイン、項目の検索、発注、注文の変更などが挙げられます。システムの制御とデータの流れをたどって、情報の検証方法、情報の保存場所、アクセスされるリソース、および関連する他のシステムを確認します。攻撃対象領域分析とアプリケーションの脅威モデリングの間には再帰的な関係があります。つまり、攻撃対象領域への変更によって脅威モデリングがトリガーされ、脅威モデリングによってアプリケーションの攻撃対象領域についての理解が促進されるということです。 攻撃対象領域モデルは、特に今までにアプリケーションに対するセキュリティの取り組みを行っていない場合は、開始点としては詳細さに欠けた不完全なものになることがあります。セキュリティ分析の調査やアプリケーションに対する作業を進めて弱点を補っているうちに、攻撃対象領域についての理解が深まっていくことがわかります。 攻撃対象領域の測定と評価攻撃対象領域のマップが用意できたら、リスクの高い領域を特定します。リモートのエントリポイント (外部システムおよびインターネットとのインターフェイス) と、特に匿名やパブリックのアクセスを許容するシステムに注目します。
これらは通常、攻撃にもっともさらされている部分です。そこで、アプリケーション保護を支援するために、ネットワークファイアウォールやアプリケーションファイアウォールなどの運用上の制御や侵入検知 / 防御システムなど、どのような相殺策を導入しているかを理解します。 Microsoft の Michael Howard 氏などの研究者は、アプリケーションの攻撃対象領域を測定して、攻撃対象領域への変更を経時的に追跡するメソッドを開発しました。このメソッドは、Relative Attack Surface Quotient (RSQ) と呼ばれています。このメソッドを使用することで、攻撃対象領域の全体的なスコアを計算できます。システムに変更を加えたときや、システムの展開方法に変更を加えたときに、このスコアを計測します。Carnegie Mellon の研究者は、この作業を基にして、SAP などの大規模システムに対する攻撃対象領域メトリックを計算する正式な方法を開発しています。この方法では、攻撃対象領域を入出力のポイント数、チャネル数 (TCP / UDP ポート、RPC エンドポイント、名前付きパイプなどを含む、クライアントや外部システムがシステムに接続する各種の方法) および信頼されないデータ要素数の合計として計算します。その後、損害の潜在性 / 影響度の比率を該当する攻撃対象領域の要素に適用して、リスクの高い領域を特定します。 アプリケーションの複数バージョンを展開する、使用しなくなった機能を将来の万が一の事態に備えて残しておく、古いバックアップコピーと未使用のコードを残しておく、などの行為は攻撃対象領域の拡大につながるので注意してください。ソースコード管理と堅牢な変更管理 / 構成の実践によって、実際に展開された攻撃対象領域と論理的な攻撃対象領域をできる限り一致させる必要があります。 コードとデータのバックアップ (オンライン、およびオフラインメディア上) はシステムの攻撃対象領域として重要であるにもかかわらず、見過ごされがちです。セキュアなソフトウェアを記述し、インフラストラクチャを強化して、データと IP を保護していても、バックアップを保護していないために悪意のある人物にすべてを渡すはめになれば、すべての努力が無駄になります。 攻撃対象領域の管理攻撃対象領域のベースラインを理解していると、将来アプリケーションに変更を加えたときのリスクを増分的に特定して管理できるようになります。次の事項について考えてみてください。
初めて作成した Web ページはシステムの攻撃対象領域を大幅に広げ、あらゆる種類の新しいリスクを招き入れます。このページや、これと同様の他のページに別のフィールドを追加すると、理論的には攻撃対象領域を拡大させることになりますが、実際にはそれほどアプリケーションのリスクプロファイルを増やしてはいません。このような増分的な変更は、新しい設計に従っていたり、新しいフレームワークを使用したりしていない限り、どれもほとんど同じようなものです。 既存の Web ページと同じ設計に従って、同じテクノロジーを使用する他の Web ページを追加する場合は、これにどれくらいのセキュリティテストとレビューが必要かは簡単にわかります。新しい Web サービス API やインターネットからアップロードできるファイルを追加する場合には、変更するたびに異なるリスクプロファイルをもう一度持つことになり、その変更が既存バケットに収まるかどうかを確認し、既存のコントロールと保護を適用できるかどうかを確認しなくてはなりません。既存バケットに当てはまらないものを追加している場合は、どのようなセキュリティホールを導入したのか、どのような保護策を実施する必要があるのかを理解するために、徹底したリスク評価を実施する必要があります。 セッション管理、認証およびパスワード管理に対する変更は、攻撃対象領域に直接的な影響を与え、レビューが必要になります。そのため、特にロール定義に追加や変更を行った場合や、高い権限を持つ管理ユーザーや管理機能を追加した場合は、認可とアクセス制御のロジックに変更を加えます。暗号化やシークレットを処理するコードに変更を加えた場合も同様です。データ検証の方法に根本的な変更を加えます。さらに、レイヤー構造と信頼関係に大幅なアーキテクチャの変更を行うか、技術的なアーキテクチャの根本的な変更 (Web サーバーまたはデータベースプラットフォームの交換や、ランタイムオペレーティングシステムの変更) を行います。 新しいユーザーの種類やロール、または特権レベルを追加するときには、同様の分析とリスク評価を実行します。データと機能全体をアクセスの種類で覆って、問題点と矛盾点を調べます。アプリケーションのアクセスモデルについて、そのモデルがポジティブ (既定でアクセスを拒否する) であるか、ネガティブ (既定でアクセスを許可する) であるかを理解することが重要です。ポジティブなアクセスモデルでは、新しいユーザーの種類やロールに許可するデータや機能の定義に含まれる間違いが簡単にわかります。ネガティブなアクセスモデルでは、ユーザーが許可されていないデータや機能にアクセスしないように、十分な注意を払う必要があります。 このような脅威またはリスクの評価は、定期的に行うようにするか、シリアル / 段階的 / スパイラル / ウォータフォールの開発プロジェクトにおける設計作業の一部として行うか、アジャイル / 反復型開発で継続的および増分的に行います。 通常、アプリケーションの攻撃対象領域は、新しいインターフェイスやユーザーの種類を追加したり、他のシステムと統合したりするにつれて拡大します。また、モデルの簡易化 (たとえば、ユーザーレベルの数を減らす、必要のない守秘データを保存しないなど) 、使用していない機能とインターフェイスをオフにする、Web アプリケーションファイアウォール (WAF) とアプリケーション固有のリアルタイム攻撃検出などの運用上の制御を導入するなどにより、できる限り攻撃対象領域のサイズを小さくする方法を調べてください。 関連資料攻撃対象領域を特定する OWASP CLASP: Identify attack surface
Authors and Primary EditorsJim Bird - jimbird[at]shaw.ca
Other CheatsheetsDeveloper Cheat Sheets (Builder)
Assessment Cheat Sheets (Breaker)
Mobile Cheat Sheets OpSec Cheat Sheets (Defender) Draft Cheat Sheets
|
