攻撃モデル

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

攻撃モデル・レベル1

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

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

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

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

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

SSGは、新しいタイプの攻撃と脆弱性についての最新情報を常に入手します。特に、技術コンファレンスへの参加や攻撃者フォーラムの監視によって収集した情報を組織内で発生した事象に関連付ける(場合によっては運用ログやテレメトリーの確認などの手段を用いる)ことで、SSGは問題の可能性を特定し、エキスパートと協力して、発生した脆弱性のエクスプロイトに関する詳細を知ることができます。多くの場合、商用サービスに登録すれば、合理的に、基本的な攻撃インテリジェンスを収集できます。攻撃者情報は、情報源がどこであれ、開発チーム、テスター、およびDevOpsエンジニアにとって使用可能で、有用なものである必要があります。

攻撃モデル・レベル2

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

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

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

SSGは、テクノロジー固有の攻撃パターンを作成して、特定のテクノロジーを狙った攻撃に関する知識を入手します。たとえば、組織のクラウド・ソフトウェアでクラウド・ベンダーのセキュリティ対策(暗号化など)を使用している場合、SSGは、暗号化パッケージの欠陥と、その悪用方法を列挙できます。最先端のセキュリティ対策(IoTなど)と直接関係する攻撃パターンがここでも有効な場合があります。多くの場合、既存の一般的な攻撃パターンを基にして必要なテクノロジ固有の攻撃パターンを作成する方法が最も簡単ですが、たとえば、最後に「モバイル・アプリケーション用」の一言を追加するだけでは不十分です。

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

SSG は、増え続ける攻撃タイプのリストを定期的に要約し、組織が優先度の高いものだけをまとめた短いリスト(上位N)に対する予防対策に集中できるようにします。この初期リストは、組織の内部および外部の複数の情報源から入手した情報を組み合わせて作成できます。リストの優先順位は、組織によって、潜在的な事業損失の認識に従って決める場合もあれば、ソフトウェアに対する攻撃の成功実績に応じて決める場合もあります。上位N位のリストは、頻繁に更新する必要はなく、攻撃を細かく分類する必要はありません。たとえば、SSGは、攻撃リストを年に2回ブレインストームし、組織は、「現在」、「近日」、「将来」の反撃準備を行う必要があります。

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

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

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

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

攻撃モデル・レベル3

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

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

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

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

[AM3.3: 0] 自動化した資産の作成を監視する。

SSGは、ALMプロセスの一環としてエンジニアリング・チームによってインスタンス化されるさまざまなネットワーク、マシン、ソフトウェア、および関連インフラストラクチャ資産のビューを継続的に更新するテクノロジ・コントロールを実装します。SSGはエンジニアリング・チームの協力を得て、カスタマイズされた自動化機能およびクラウド・プロバイダー・ダッシュボードについて理解し、ソフトウェアのデプロイ用にサーバー、データベース、ネットワーク、およびクラウド全体を迅速に立ち上げる方法を把握します。アプリケーション設計の変更(モノリシック・アプリケーションからマイクロサービスへの移行など)の監視もこのプロセスの一環です。この監視には専門的な作業が必要です。通常のシステム、ネットワーク、およびアプリケーションのロギングと分析では不十分です。成果を上げるためには、オーケストレーションと仮想化メタデータの使用、クラウド・サービス・プロバイダーAPIのクエリ、外から情報を取り入れるWebクローリングおよびスクレイピングなど、多面的なアプローチが必要になる場合があります。プロセスが向上するほど、データは脅威モデリングに有用なものになります([AA1.1 セキュリティ機能のレビューの実施]を参照)。