インシデント対応プレイブックの構築
使用するタイミング
- インシデント対応プログラムをゼロから確立・成熟させる場合
- 新種の攻撃後、新しいインシデントタイプの手順を文書化する場合
- SOARプラットフォーム（Cortex XSOAR、Splunk SOAR）で対応ワークフローを自動化する場合
- 文書化されたIR手順を必要とするコンプライアンス監査（SOC 2、PCI-DSS、HIPAA）に備える場合
- 特定の脅威シナリオに対する既存のIR機能のギャップ分析を実施する場合
使用すべきでない場合: 1回限りのアドホック調査には使用しないでください。プレイブックは再利用可能な手順書であり、ケース固有のレポートではありません。
前提条件
- 発生可能性と影響度に基づいて主要なインシデントシナリオを特定した組織のリスク評価
- 組織のIR標準として採用されたNIST SP 800-61r3またはSANS PICERLフレームワーク
- 業務重要度評価とデータ分類を含む資産インベントリ
- 役割を定義するRACI図: インシデントコマンダー、SOCアナリスト、システム管理者、法務、広報
- 既存の検知機能のインベントリ（SIEMルール、EDR検知、IDSシグネチャ）
- 自動化プレイブックを構築する場合はSOARプラットフォームへのアクセス
ワークフロー
ステップ 1: インシデントタイプの選択とスコープ定義
プレイブックが扱う具体的なシナリオを定義します:
- 組織のリスク評価と過去のデータに基づいて主要なインシデントタイプを特定する
- 明確さのために各プレイブックを単一のインシデントタイプにスコープする（無関係なシナリオを組み合わせない）
- プレイブックを起動するトリガー条件を定義する
一般的なプレイブックタイプ:
優先プレイブック（最初に構築）:
1. ランサムウェアインシデント対応
2. フィッシング/認証情報漏洩
3. ビジネスメール詐欺
4. マルウェア感染
5. データ侵害/漏洩
6. DDoS攻撃
7. 内部不正
8. アカウント乗っ取り
9. Webアプリケーション侵害
10. クラウドインフラストラクチャ侵害
ステップ 2: プレイブックの構造を定義する
すべてのプレイブックは一貫した構造に従う必要があります:
プレイブックテンプレート
━━━━━━━━━━━━━━━━
1. プレイブックメタデータ
- 名前、バージョン、オーナー、最終レビュー日
- トリガー条件
- 重要度基準
2. RACIマトリックス
- 各ステップの責任者、説明責任者、相談者、情報提供者
3. 検知とトリアージ
- インシデントの検知方法
- 初期トリアージチェックリスト
- 重要度分類基準
4. 封じ込め
- 短期的封じ込め対策
- 長期的封じ込め対策
- 証拠保全要件
5. 根絶
- 根本原因の特定
- マルウェア/脅威の除去手順
- 検証手順
6. 復旧
- システム復旧手順
- 検証基準
- 復旧後の監視要件
7. インシデント後
- 教訓を学ぶ会議のトリガー
- 報告書テンプレート
- 検知改善アクション
8. コミュニケーション
- 内部通知マトリックス
- 外部通知要件（規制当局、顧客、法執行機関）
- ステータス更新の頻度
9. 付録
- ツール固有の手順
- 連絡先リスト
- 証拠収集チェックリスト
ステップ 3: 決定木とエスカレーション基準を記述する
バイナリ結果を持つ明確な決定ポイントを定義します:
検知アラート受信
├── アラートは真陽性か？
│ ├── はい → 重要度を分類
│ │ ├── P1（致命的）→ インシデントコマンダーをページング、直ちに封じ込め開始
│ │ ├── P2（高）→ IRリーダーに通知、30分以内に調査開始
│ │ ├── P3（中）→ 4時間以内に調査キューへ
│ │ └── P4（低）→ 文書化、24時間以内に調査
│ └── いいえ → 誤検知として文書化、検知ルールを調整
└── 判断できない → レベル2にエスカレーション、詳細分析
エスカレーションのトリガー:
- P1インシデント: 直ちにIRリーダーとCISOにエスカレーション
- データ漏洩が確認された場合: 法務顧問とプライバシー責任者に通知
- 顧客データが関与する場合: 顧客通知プロセスを開始
- サードパーティが関与する場合: ベンダーセキュリティ担当者に連絡
- 法執行機関が必要な場合: 連絡前にゼネラルカウンセルの承認を得る
ステップ 4: 具体的な技術手順を定義する
各ステップに対して（一般的なガイダンスではなく）ツール固有の指示を記述します:
封じ込め - CrowdStrikeによるエンドポイント隔離:
1. Falcon Consoleを開く > ホスト > 影響を受けるホスト名を検索
2. ホストをクリック > ホスト詳細
3. 右上の「ホストを隔離」ボタンをクリック
4. 隔離を確認（ホストはCrowdStrikeクラウドとのみ通信可能）
5. インシデントチケットにタイムスタンプと共に封じ込め対応を記録
6. 封じ込めを確認: ホストに「隔離済み」ステータスバッジが表示されること
封じ込め - DNSでのC2ドメインブロック:
1. DNSサーバーにSSH: ssh [email protected]
2. ブロックゾーンに追加: echo "zone evil.com { type master; file /etc/bind/db.sinkhole; };" >> /etc/bind/named.conf.local
3. DNSをリロード: rndc reload
4. 確認: dig @dns-primary evil.com（シンクホールIP 10.0.0.99に解決されること）
5. ブロックしたドメインをインシデントチケットに記録
ステップ 5: SOARプラットフォームと統合する
手動プレイブックの手順を自動化ワークフローに変換します:
- 各プレイブックステップをSOARアクション（API呼び出し、スクリプト、人間による判断ポイント）にマッピング
- 自動化の境界を定義する（何が自動実行され、何がアナリストの承認を必要とするか）
- トリアージフェーズのためのエンリッチメント自動化を構築
- 高影響アクションには承認ゲート付きの封じ込め自動化を作成
- ステークホルダーコミュニケーションのための通知自動化を設定
ステップ 6: プレイブックをテストおよび維持する
訓練を通じてプレイブックを検証し、最新の状態を維持します:
- IRチームと共にプレイブックを読み進める机上訓練を実施
- テスト環境でインシデントタイプをシミュレートする実動訓練を実施
- プレイブックを使用した実際のインシデントのたびにレビューと更新を実施
- 連絡先リスト、ツール手順、エスカレーションパスの正確性について四半期ごとのレビューをスケジュール
- プレイブックのメトリクスを追跡: 平均封じ込め時間、平均解決時間、誤検知率
主要概念
| 用語 | 定義 |
|---|---|
| プレイブック | 特定のインシデントタイプに対応するための文書化された再利用可能な手順セット |
| ランブック | プレイブックよりも詳細で、プレイブック内の特定タスクのステップバイステップの技術手順 |
| RACIマトリックス | 各アクティビティの責任者、説明責任者、相談者、情報提供者を定義する責任分担図 |
| 決定木 | 各決定ポイントでのバイナリ条件に基づいて対応経路を定義するフローチャートベースのロジック |
| エスカレーション基準 | 上位レベルの担当者または外部パーティへの通知をトリガーする事前定義条件 |
| SOARプレイブック | Security Orchestration, Automation, and Responseプラットフォーム内でプレイブックの手順を実行する自動化ワークフロー |
ツールとシステム
- Cortex XSOAR: ビジュアルプレイブックエディター、700以上の統合、およびコラボレーションWar Roomを備えたSOARプラットフォーム
- Splunk SOAR: Splunk ESと統合されたSOARプラットフォーム、2,800以上の自動化アクションを備えたドラッグアンドドロッププレイブックビルダー
- TheHive: プレイブックフレームワークとして機能するケーステンプレートを備えたオープンソースのインシデント対応プラットフォーム
- Confluence / GitLab Wiki: バージョン管理付きの人間可読プレイブック文書を維持するための文書化プラットフォーム
- Tines: プログラミング不要でプレイブックワークフローを構築するためのノーコードセキュリティ自動化プラットフォーム
一般的なシナリオ
シナリオ: フィッシング対応プレイブックをゼロから構築する
コンテキスト: 5名のSOCを持つ組織が、文書化されたフィッシング対応手順を持っていない。アナリストはフィッシングレポートを一貫性なく処理している。
アプローチ:
- SOCアナリストにインタビューし、現在のアドホックプロセスを文書化する
- トリガーを定義する: ユーザーがabuse@メールボックスまたはフィッシングボタンを介してフィッシングメールを報告
- トリアージ手順を記述する: メールヘッダーを抽出、送信者レピュテーションを確認、URL/添付ファイルをサンドボックスで分析
- 封じ込めを定義する: すべてのメールボックスからメールを検疫、送信者ドメインをブロック、認証情報が入力された場合はパスワードをリセット
- SOAR自動化を構築する: 報告されたメールからIOCを自動抽出、VirusTotalでエンリッチ、TheHiveでケースを作成
- シミュレーションフィッシングメールでテストし、対応時間の改善を測定する
落とし穴:
- 特定のツールインターフェースやコマンドを参照しない、過度に一般的な手順を記述すること
- フィッシングメールを受信したユーザーへの通知計画を含めないこと
- フィッシングレポートが完全なインシデント調査になる基準を定義し忘れること
- プレイブックのバージョン管理や定期的なレビューサイクルをスケジュールしないこと
出力形式
インシデント対応プレイブック
============================
プレイブック名: フィッシングインシデント対応
バージョン: 2.1
オーナー: SOCマネージャー
最終レビュー日: 2025-11-01
次回レビュー日: 2026-02-01
トリガー: [email protected]またはフィッシングボタンを介して報告されたフィッシングメール
RACIマトリックス
アクティビティ | SOC L1 | SOC L2 | IRリーダー | 法務 | 広報 |
初期トリアージ | R | C | I | | |
メール分析 | R | A | I | | |
封じ込め | | R | A | I | |
認証情報リセット | | R | A | | |
ユーザー通知 | | C | A | | R |
規制当局通知 | | | C | R | A |
教訓を学ぶ | C | C | R | I | I |
手順ステップ
[ツール固有の指示を含む詳細な手順]
決定木
[フローチャートロジック]
エスカレーションマトリックス
[条件と連絡先]
メトリクス
目標MTTA: 15分
目標MTTC: 1時間
目標MTTR: 4時間