red-team-engagement

レッドチーム演習 — 許可を得た攻撃者エミュレーション

このスキルは、明示的に契約したシステムと組織に対して、許可を得たレッドチーム演習を計画・実行するためのものです。ペネトレーションテスト（手法に重点を置くもの。web-pentest を参照）や脅威ハンティング（防御側の活動。threat-hunting を参照）とは異なります。レッドチーム演習は数週間にわたり、目標を設定して実施され、多くの場合、侵入済みであることを前提とし、脆弱性を見つけるだけでなく、ブルーチームの検知・対応能力を試すことを明確な目的とします。

このカタログの中で、最もデュアルユース性の高いスキルです。依頼の表現にかかわらず、許可を得ていない攻撃者シミュレーションの実施には協力しません。以下の許可確認は厳格に適用されます。

計画または実行の前に必須となる許可の確認

このスキルを使って作業を始める前に、以下を確認してください。

1. この特定の演習と特定の対象に対する書面による許可があり、許可を与える権限を持つ役員が署名していること。「免責状」——チームが異議を申し立てられた際に提示できる、紙またはデジタルの文書
2. 定義されたスコープ — 対象となるシステム、実施時間帯、スコープ内外の手法
3. 特定された対象組織が対象システムを所有していること — 許可を得ていない第三者（ベンダー、顧客、サブテナント）のものではないこと
4. 定義された成功基準 — この演習で何を実証または検証する必要があるか
5. 特定された競合調整窓口 — 演習の一時停止・中止を指示でき、ブルーチームが活動を発見した際に「これはあなたたちの活動ですか？」という問いに答えられる、社内の担当者1名
6. 法務レビューの記録 — 管理対象データの露出に関する事項も含め、法務担当者がレビューした演習契約書または社内の許可書
7. 意図しない影響が発生した場合の連絡計画 — 本番環境に影響が出た場合の対応と報告方法、報告までの時間

上記のいずれかが欠けている、または不明確な場合は、停止してください。ユーザーに確認を求めてください。計画、手法の選定、実行作業には進まないでください。

ユーザーが、本人または契約上の顧客のものではないと思われる対象を説明した場合は、依頼を拒否してください。「教育目的」や「CTFである」と付け加えれば解決するような誤解ではありません。許可がないシステムへの攻撃シミュレーションには協力しません。

レッドチーム演習の目的と、目的ではないこと

レッドチーム演習は、脆弱性を見つけるだけでなく、セキュリティプログラムの対応能力を検証するために行います。優れたレッドチーム演習では、次のような問いに答えます。

• 攻撃者が最初のアクセスを得た場合、ブルーチームが気づくまでにどれくらいかかるか？
• ブルーチームが気づいた際、どれだけ迅速かつ完全に封じ込められるか？
• 文書化されたインシデント対応手順は、実際に使われているか？
• 理論上存在する検知機能は、実際の環境でも作動するか？
• 執拗な攻撃者は、名指しされた最重要目標に到達できるか？

レッドチーム演習の目的ではないこと：

• 脆弱性の発見 — それならペネトレーションテストのほうが、はるかに少ない負担で実施できます
• コンプライアンスのチェック項目を埋めること — 演習は合格するためではなく、学ぶために設計されています
• 人事評価 — レッドチーム演習を個々のブルーチーム従業員の評価に使うと、全員の行動を歪めるインセンティブ上の問題が生じます

目標が「脆弱性を見つけること」なら、web-pentest または関連する監査スキルを使ってください。目標が「検知と対応が実際に機能するかを検証すること」なら、このスキルが適しています。

エンゲージメントモデル — 3つの形式

モデル	説明	使用する場面
外部レッドチーム	境界の外側からエンゲージメントを開始します。初期 foothold はありません	攻撃チェーン全体をエンドツーエンドでテストする成熟したプログラム
侵害を前提としたエンゲージメント	付与された初期 foothold（ワークステーション、認証情報、低権限アカウント）からエンゲージメントを開始します	境界のテストがすでに十分に行われており、侵害後の封じ込めが課題となる場合
パープルチーム	レッドチームとブルーチームが並行して作業します。レッドチームが手法を実行し、ブルーチームがリアルタイムで検知を検証します	検知エンジニアリングの成熟度が初期段階にあり、学習効果を高めたい場合

侵害を前提としたエンゲージメントは、現在最も一般的なエンゲージメントモデルです。実際の侵害のほとんどは、すでに境界が突破された状態から始まるため、週あたりの価値が最も高くなります。外部レッドチームのみのエンゲージメントにも価値はありますが、所要期間が長く、コストがかかります。

エンゲージメントのライフサイクル

フェーズ 0 — エンゲージメント前（キックオフの4～8週間前）

クライアント／スポンサーとのスコープ設定：

• 目標 — エンゲージメントでは、クラウンジュエルへのアクセスやどのような能力を実証する必要がありますか？「保存中の顧客データにアクセスする」は具体的ですが、「できる限り見つける」では具体性に欠けます
• 対象範囲内のアセット — 特定の環境、特定のサブネット、特定のアプリケーションを指定します。説明ではなく、名称を列挙します
• 対象範囲外のアセット — 対象外となるアセットを明示します。サードパーティの SaaS、指定アカウントの顧客データ、特定の本番システム、経営幹部の個人アカウント、契約の対象外となる規制対象データなどです
• 実施期間 — 開始日と終了日を定めたエンゲージメント期間です。期間が短いほど集中が必要になり、長いほど侵害を前提としたシナリオを展開できます
• 対象範囲外の手法 — 価値の有無にかかわらず、チームが実施しないことを定めます。一般的な例は、破壊的な手法、顧客データの変更、実際の顧客データの大量流出、指定された経営幹部へのソーシャルエンジニアリング、別途の許可を得ない物理的アクセスです
• 信頼できる担当者（「ホワイトセル」）の特定 — エンゲージメントの実施を把握している社内担当者の最小人数です。通常は2～4名で、経営幹部のスポンサー、セキュリティ責任者、調整担当者、法務担当者などです
• 報告の頻度 — 毎日のスタンドアップ、週次のチェックポイント、エンゲージメント終了時の報告会を定めます
• 連絡手段 — 実施中にエンゲージメントがブルーチームに漏れないよう、安全な帯域外の連絡手段（Signal、暗号化メール、専用ブリッジ）を使用します

キックオフ前に用意する文書：

• 署名済みのルール・オブ・エンゲージメント（RoE）— レッドチームとスポンサー間の契約
• 物理的およびデジタルの免責証明書。権限を持つ経営幹部が署名します
• 目標、スコープ、予定する手法を含むエンゲージメント計画（目標ごとに記載し、攻撃手順を網羅的に列挙するものではありません）
• 連絡／エスカレーションマトリックス

フェーズ 1 — 偵察とインテリジェンス（エンゲージメントの種類に応じて実施）

外部エンゲージメントでは、recon と osint-recon を活用します。侵害を前提としたエンゲージメントでは、このフェーズで、付与された開始地点から内部偵察を行います。

成果物はターゲットマップです。これは、目標に到達するためにチームがたどるシステム、アカウント、ピボットを示します。

フェーズ 2 — 実行

エンゲージメントに合わせて調整された ATT&CK エミュレーション計画に従います。

エミュレーション計画は、特定の脅威アクターの活動方法をまとめた公開プレイブックです。スクリプトではなく、出発点として使用してください。

• MITRE ATT&CK エミュレーション計画 — オープンソースで、脅威アクターごとに作成されています（APT29、FIN6、FIN7、menuPass、OilRig、Carbanak、Sandworm など）。attack.mitre.org/resources/adversary-emulation-plans/ で利用できます
• CALDERA — MITRE が提供する自動化された敵対者エミュレーションフレームワークです。対象環境に対して ATT&CK 計画を実行します
• Atomic Red Team — 短く、焦点を絞った手法のテストです（「アトミック」ごとに ATT&CK の手法を 1 つテストします）。パープルチーム演習に役立ちます

エンゲージメントは、名前が付けられた目標に向けて、キルチェーンを進みます。外部からの侵入では初期アクセスから、侵害済み環境を前提とする場合は侵入後の実行から始まり、永続化、権限昇格、防御回避、認証情報へのアクセス、探索、ラテラルムーブメント、収集、持ち出し（シミュレーションのみ。境界条件を参照）へと進みます。

運用上の注意事項：

• 事後報告に備え、すべてのアクションについて、タイムスタンプ、手法、対象、観測された効果を記録します
• ブルーチームがエンゲージメントを発見した際に連絡を取れるよう、デコンフリクション担当者が応答します。リスクが高まる場合は一時停止し、そうでない場合は確認のうえ続行します
• 明示的に許可されていない限り、破壊的な手法は使用しません。許可されている場合も、安全に復旧できるシステムに対してのみ実施します
• 実データは決して持ち出しません。合成マーカー（特定のファイル名、特定のハッシュ値）を使用し、チームが顧客データを実際に移動させることなく、ブルーチームがアクセスされたデータを確認できるようにします
• ブルーチームの対応が実際の顧客サービスに影響する場合、エンゲージメントを一時停止します。実際のサービス停止を招く価値はありません

フェーズ 3 — 事後報告とレポート作成

最も投資が不足しているフェーズであり、エンゲージメントが実際に防御の改善につながるかを左右するフェーズです。

当日の事後報告（エンゲージメント終了から 24 時間以内）：

• レッドチームがアクションのタイムラインを説明します
• ブルーチームが、何をいつ認識し、何をしたかを説明します
• 両者の認識の差が、最も価値の高い発見事項です（レッドチームが X を実施したのに、ブルーチームには何も見えていなかった）

完全なレポート（2～4 週間以内）：

# Red Team Engagement Report
## Engagement: [name]
## Sponsor: [executive sponsor]
## Engagement window: [start - end]
## Engagement type: External / Assumed Breach / Purple
## Authors: [red team leads]

### Executive summary
[3-5 paragraphs — were objectives achieved, what the blue team's detection-and-response posture looks like, top 3-5 systemic recommendations]

### Engagement timeline
[Red-team actions with timestamps and ATT&CK technique IDs]

### Blue-team observations
[For each red-team action, what the blue team saw, when, and how they responded — or did not]

### Detection coverage analysis
[Map of techniques used vs detections that did / should have fired]

### Findings
| ID | Severity | Category | Description |
|----|----------|----------|-------------|

(Categories: Detection gap, Response gap, Privileged-access exposure, Lateral-movement enabler, Crown-jewel access path, Compensating control reliance)

### Per-finding detail
[Technique used, what was achieved, what the blue team did / didn't see, recommended remediation]

### Recommendations
[Prioritized — usually 5-10 items mapping to specific systemic improvements, not point fixes]

### What the engagement did NOT cover
[Honesty about what was out of scope and where coverage gaps remain]

フェーズ 4 — 改善と再検証

レポートの推奨事項は作業項目になります。レッドチームの価値は、次の取り組みを通じて積み重なります。

• 重大度の高い推奨事項を完了まで追跡します（通常は、siem-detection に従って検知ルールを追加し、soc-operations に従って対応ランブックを更新し、監査スキルに従って管理策を改善します）
• パープルチーム演習として、できれば 6～12 か月後に、具体的な発見事項を再検証します
• 学んだ教訓を breach-patterns および incident-triage のランブックに反映します

同じ問題を 2 度発見するレッドチームは、2 度目に予算を無駄にしたことになります。

ルール・オブ・エンゲージメント（RoE）—文書に記載する内容

RoE は契約です。具体的に記載する必要があります。

セクション	指定する内容
承認	誰が、いつ、どのような権限でこのエンゲージメントを承認したか
スコープ — 対象	名前を明記した特定のシステム、アカウント、環境、アプリケーション
スコープ — 対象外	明示的に除外する対象 — 第三者、規制対象データ、指定アカウント、特定の本番システム
対象範囲内の手法	許可される手法のカテゴリ（例：「指定されたテスト環境での認証情報の取得」）
対象範囲外の手法	許可されない手法のカテゴリ（例：「破壊的な手法は禁止」「指定された幹部へのソーシャルエンジニアリングは禁止」「ベンダーのシステムの悪用は禁止」）
実施期間	開始日、終了日、実施禁止期間（例：「四半期決算中はエンゲージメント活動を行わない」）
データの取り扱い	エンゲージメント中に発見したデータの取り扱い — 破棄までの期限、暗号化要件、持ち出しを示すマーカー
報告頻度	毎日／毎週／エンゲージメント終了時
調整連絡先	氏名を指定した連絡担当者 1 名と代理担当者、および 24 時間対応の連絡手段
停止条件	エンゲージメントを一時停止または中止する条件 — 本番環境で発生した障害、規制関連の事象の発生、意図せずスコープ外に踏み込んだ場合
免責証明書	形式、配布先、確認のための連絡先

境界

このカタログで最も重大な境界に関するセクションです。よく読んでください。

• 承認は最低条件であり、許可の上限ではありません。 署名済みの承認があっても、あらゆる手法が許容されるわけではありません。契約によって、許可される範囲は引き続き定められます。ユーザーが判断に迷った場合は、「続行する前に依頼者に確認してください」と答えます
• 許可されていない対象への対応は拒否します。 ユーザーが所有も管理もしていないシステムを対象とした「仮定上の」エンゲージメントには対応しません。名前を挙げた第三者に対する「もし〜ならどうするか」という質問にも対応しません。このスキルは、任意の対象に対する敵対者視点の演習ではなく、承認済みのエンゲージメントを対象としています
• 破壊的な手法はデフォルトで禁止です。 対象範囲内であっても、非破壊的な代替手段を優先します — シミュレートしたランサムウェア（暗号化せずにファイルを列挙する）、実行せずにアーティファクトを配置して永続化を実証する、読み取り専用のアクセス証明
• 実際の顧客データは持ち出しません。 合成マーカーを使用します。ブルーチームは、レッドチームが実データを移動することなく、マークされたデータを確認して、何がアクセスされたかを検証します
• 安全のために一時停止します。 実世界への影響が発生した場合、エンゲージメントを一時停止します — 障害、権限のない第三者へのデータ漏えい、規制当局への通知が必要となる事象。再開するのは、依頼者の承認を得た後に限ります
• 攻撃ツールの構築支援は拒否します。 このスキルは、既存の手法とツールを責任を持って使用するエンゲージメントを計画します。新たなマルウェア、新たな C2 フレームワーク、あるいはデフォルトで回避機能を備えた新たなツールの作成は支援しません。ツールに関する判断は、このスキルの対象外です
• テストに同意していない人に対するソーシャルエンジニアリングの支援は拒否します。 ソーシャルエンジニアリングを対象範囲に含めることはできますが、対象者はエンゲージメントテストを受け入れる役割の人でなければなりません（通常は、明示的な除外対象を設けたうえで従業員全般が対象です）。同意の範囲外にいる特定の個人をフィッシングする依頼は拒否します
• 内部レッドチームが特定の従業員の監視に使われていると思われる場合は拒否します。 レッドチームがテストするのはシステムとプロセスであり、人ではありません
• 発見事項は武器ではなく、発見事項です。 改善作業につながるレッドチーム報告書は価値を生みますが、社内政治の弾薬となる報告書は価値を損ないます。執筆者とレビュー担当者には、前者となるよう責任を持つことが求められます

参考資料

• MITRE ATT&CK フレームワーク — attack.mitre.org
• MITRE ATT&CK Adversary Emulation Plans — attack.mitre.org/resources/adversary-emulation-plans/
• MITRE CALDERA — 自動化された敵対者エミュレーション
• Atomic Red Team — github.com/redcanaryco/atomic-red-team
• TIBER-EU（脅威インテリジェンスに基づく倫理的レッドチーム演習）— 金融セクター向けの欧州フレームワーク
• CBEST（英国イングランド銀行）— 英国の金融セクター向けレッドチームフレームワーク
• NIST SP 800-115（情報セキュリティのテストと評価に関する技術ガイド）
• PTES（ペネトレーションテスト実行標準）— レッドチームに関連するフェーズを含む手法の情報源
• Red Team Field Manual — Ben Clark — オペレーター向けの参考資料
• Adversary Tradecraft and the Importance of Cyber Threat Intelligence — MITRE / CTID による解説
• CTID（Center for Threat-Informed Defense） — ctid.mitre.org — オープンソースのエミュレーションコンテンツ
• 「Red Team Development and Operations」 — Joe Vest、James Tubberville
• 「How to Hack Like a Ghost」 — Sparc Flow（物語形式。長期にわたるエンゲージメントのモデルを理解するのに役立ちます）