攻撃モデル

攻撃モデルは、攻撃者の視点で考えるために使用される情報を収集します。これには、脅威モデリング、悪用ケースの作成と調整、データの分類化、テクノロジー固有の攻撃パターンが含まれます。

攻撃モデル・レベル1

[AM1.2: 75] データ分類スキーマとインベントリの作成。

組織は、データ分類スキーマに合意し、そのスキーマを使用して、ソフトウェアが処理するデータの種類に従って、ソフトウェアが社内設備内にあるかどうかにかかわりなく、ソフトウェアのインベントリを作成しています。これにより、データ分類に従って、アプリケーションの優先順位を付けられます。多くの分類スキーマが可能ですが、1つの方法としては、たとえばPIIを中心に作成することが考えられます。関係するスキーマとソフトウェアよっては、データ・リポジトリをまず分類し、次に、アプリケーションで使用するレポジトリに従って、アプリケーションを分類すると簡単に作成できます。他の方法としては、たとえば、知的財産の保護や、漏洩の影響、攻撃への露出度、GDPRへの関連性、または地理的境界に従ってデータを分類することが可能です。

[AM1.3: 38] 潜在的な攻撃者の特定。

SSGは、その意図と能力を理解するため、潜在的な攻撃者を特定します。この演習の結果、攻撃者分類の概要や、注目すべき攻撃者の詳細説明などの攻撃者のプロファイルが作成できます。場合によっては、外部業者と契約してこの情報を取得することができます。ほとんどの場合、誰かが作成したリストからの一般的な情報よりも、具体的で背景のわかる攻撃者情報の方が有用です。また、単に内部関係者と外部者をわけたリストでは、有用な結果は得られません。

[AM1.5: 53] 攻撃者インテリジェンスを収集し使用する。

SSGは、新しいタイプの攻撃と脆弱性についての最新情報を常に入手します。情報は、カンファレンスやワークショップ、関連刊行物、メーリング・リスト、ブログから、あるいは攻撃者フォーラムを監視して収集します。「敵を知り己を知れば百戦殆うからず」とは孫子の言葉ですが、皆さんを困らせるような高度な問題を提示しそうなセキュリティ研究者と連絡を取ります。多くの場合、商用サービスに登録すれば、合理的に、基本的な攻撃インテリジェンスを収集できます。攻撃者情報は、情報源がどこであれ、ソフトウェア開発者とテスターにとって使用可能で、有用なものである必要があります。

攻撃モデル・レベル2

[AM2.1: 10] 潜在的な攻撃者と関連付けた攻撃パターンと悪用ケースを構築する。

SSGは、潜在的な攻撃者と関連付けた攻撃パターンと悪用ケースを構築することにより、セキュリティ・テストとアーキテクチャ分析を準備します([AM1.3 潜在的な攻撃者の特定]参照)。これらのリソースは、アプリケーションごとにすべて作成しなくても、有効なリソースが入手できます。類似したプロファイルのアプリケーションのための標準セットが存在する場合があります。SSGは、攻撃事例を基に、これを追加します。たとえば、不適切な設計のクラウド・アプリケーションに対する攻撃の例から、新しいタイプのテストを推進するクラウド・セキュリティ攻撃パターンが作成できることもあります。企業で、詐欺行為や特定の攻撃に関連するコストを追跡している場合、この情報は、攻撃パターンや悪用ケースを構築するプロセスの優先順位を付けるために使用できます。

[AM2.2: 10] テクノロジー固有の攻撃パターンを作成する。

SSGは、テクノロジー固有の攻撃パターンを作成して、特定のテクノロジーを狙った攻撃に関する知識を入手します。たとえば、組織のクラウド・ソフトウェアでクラウド・ベンダーのセキュリティ対策(暗号化など)を使用している場合、SSGは、暗号化パッケージの欠陥と、その悪用方法を列挙できます。最先端のセキュリティ対策(IoTなど)と直接関係する攻撃パターンが有効な場合もあります。一般ガイドライン(「移動中のデータは必ず保護する」など)を再発行して、「モバイル・アプリケーションでは」と文章に追加しただけではテクノロジー固有の攻撃パターンを作成したとはみなされません。

[AM2.5: 16] 上位N位の考えられる攻撃リストを作成し更新する。

SSGは、重要な攻撃のリストを最新の状態に維持することによって攻撃の基本情報を組織に周知し、変革を推進するために使用します。このリストは、攻撃の観察、ハッカー・フォーラム、業界の傾向、新しいテクノロジー・スタック、デプロイメント手法など、複数の情報源から入手した情報を組み合わせて作成します。リストは、頻繁に更新する必要はなく、攻撃を細かく分類する必要はありません。たとえば、SSGは、攻撃リストを年に2回ブレインストームし、組織は、「現在」、「近日」、「将来」の反撃準備を行う必要があります。場合によっては、攻撃モデル情報を、アーキテクチャ分析に対するリストベースのアプローチとして使用し、STRIDE手法の場合のように解析を行うことができます。リストは作成することが目的ではなく、活用する必要があります。

[AM2.6: 14] 攻撃事例を収集し、公開する。

(場合によっては手痛い被害と引き換えに得られた)教訓を最大限に生かすため、SSGは組織に対する攻撃に関する事例を収集し公開します。成功事例と失敗事例の両方が貴重です。ソフトウェア攻撃に関する履歴情報を討議することにより、企業の現実に即してソフトウェア・セキュリティの基礎を築けます。これは、特に、トレーニングの講義が、リストの上位10位に偏った一般的な手法や、関連の薄い旧式のプラットフォーム攻撃に終始しないようにするために有効です( [T1.6 会社の履歴に合わせた教材を作成し、使用する。]を参照)。新しいシステムを開発している従業員から攻撃に関する情報を隠蔽していては、過去の過ちから学ぶことはできません。

[AM2.7: 11] 攻撃について討議する社内フォーラムを構築する。

組織に、SSG、サテライトメンバー、およびその他の従業員が攻撃や攻撃方法について討議する社内フォーラムがあります。フォーラムでは、攻撃者の視点で対話することができます。SSGは、主要なインシデントに関する最新の情報について登録者が討議する、社内メーリング・リストを管理することもできます。会社に関係のある攻撃や悪用を分析すると、開発におけるリスク低減の論議を活発化する上で特に有効です。公開されたメーリング・リストからの項目を再発行するだけでは、積極的な議論ほどの効果が達成できず、コードを実際に作成している開発者は参加しない閉鎖的な討論になります。従業員が脆弱性や悪用について自由に質問したり学習したりできる必要があります。警戒とは、常に油断しないことです([SR1.2 セキュリティ・ポータルの構築]参照)。

攻撃モデル・レベル3

[AM3.1: 4] 新しい攻撃方法を開発する科学チームが存在する。

SSGには、実際の攻撃者がその存在を知る前に、新しい種類の攻撃を特定し、無力化させる科学チームがあります。新しいテクノロジーのセキュリティ上の意味は、一般にはあまり探求されていないため、自社で研究するのが最適な方法である場合があります。これは、既知のタイプの脆弱性を持つ新しいインスタンスを特定するペネトレーション・テスト・チームとは異なり、新しいタイプの攻撃を開発する研究グループです。科学チームには、DEF CONなどのカンファレンスで研究発表を行った有名なセキュリティ研究者が含まれる場合もあります。

[AM3.2: 2] 攻撃者を疑似するための自動化を作成、使用する。

SSGは、攻撃者が何をするかを疑似する自動化機能をテスターに提供します。たとえば、科学チームによって特定された新型の攻撃に新しいツールが必要だったとします。SSGは、新しいツールをパッケージ化してテスターに配布します。ここで重要なのは、一般の市販ツールや製品の範囲を超えた攻撃能力を作り出し、その情報を他者が別の目的で使用できるようにすることです。これらの新しいツールを、会社の特定のテクノロジー・スタックや潜在的な攻撃者用にカスタマイズするとさらに効果的です。テクノロジー・スタックやコーディング言語の進化がベンダーの開発ペースより速い場合は、独自のツールを作成することが最善の方法になる可能性があります。