building-incident-response-playbook について
セキュリティチーム向けに、再利用可能なインシデント対応手順の作成方法を示す実践ガイドです。対象の定義、判断経路、技術手順、SOAR 自動化、プレイブックのテストと保守を扱います。
主な機能
- 01インシデント種別の範囲設定
- 02再利用可能なプレイブック構成
- 03判断ツリーとエスカレーション基準
- 04ツール別の対応手順
- 05SOAR ワークフローの計画
- 06テストと保守の指針
活用シーン
- 01インシデント対応プログラムの立ち上げ
- 02新たな攻撃向けの対応手順の文書化
- 03コンプライアンス監査用手順の準備
- 04脅威シナリオごとの対応ギャップ評価
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/ / github.com/ mukul975/ anthropic-cybersecurity-skills --skill building-incident-response-playbookインストール後、Claude Code で/building-incident-response-playbookを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
LICENSEreferences/api-reference.mdscripts/agent.py詳細
インシデント対応プレイブックの作成
使用する場面
- インシデント対応プログラムをゼロから構築、または成熟させる場合
- 新たな攻撃を受け、新しいインシデントの種類に関する手順を文書化する場合
- SOAR プラットフォーム(Cortex XSOAR、Splunk SOAR)で対応ワークフローを自動化する場合
- 文書化された IR 手順が求められるコンプライアンス監査(SOC 2、PCI-DSS、HIPAA)に備える場合
- 特定の脅威シナリオに照らして既存の IR 能力のギャップ分析を実施する場合
使用しないでください。一度限りのアドホックな調査には使用しないでください。プレイブックは再利用可能な手順書であり、個別の事例に特化した報告書ではありません。
前提条件
- 発生可能性と影響度に基づいて主要なインシデントシナリオを特定した組織のリスク評価
- 組織の IR 標準として採用された NIST SP 800-61r3 または SANS PICERL フレームワーク
- ビジネス上の重要度評価とデータ分類を含む資産インベントリ
- インシデントコマンダー、SOC アナリスト、システム管理者、法務、広報の役割を定義した RACI チャート
- 既存の検知能力のインベントリ(SIEM ルール、EDR 検知、IDS シグネチャ)
- 自動化されたプレイブックを作成する場合は SOAR プラットフォームへのアクセス
ワークフロー
ステップ 1:インシデントの種類を選択し、範囲を定める
プレイブックで対応する具体的なシナリオを定義します。
- 組織のリスク評価と過去のデータに基づいて、主要なインシデントの種類を特定します
- 明確さを保つため、各プレイブックの対象は単一のインシデントの種類とします(無関係なシナリオを組み合わせないでください)
- プレイブックを起動するトリガー条件を定義します
一般的なプレイブックの種類:
Priority Playbooks (build first):
1. Ransomware incident response
2. Phishing/credential compromise
3. Business email compromise
4. Malware infection
5. Data breach/exfiltration
6. DDoS attack
7. Insider threat
8. Account takeover
9. Web application compromise
10. Cloud infrastructure compromise
ステップ 2:プレイブックの構成を定義する
すべてのプレイブックで、一貫した構成に従うようにします。
PLAYBOOK TEMPLATE
━━━━━━━━━━━━━━━━
1. Playbook Metadata
- Name, version, owner, last review date
- Trigger conditions
- Severity criteria
2. RACI Matrix
- Who is Responsible, Accountable, Consulted, Informed for each step
3. Detection & Triage
- How the incident is detected
- Initial triage checklist
- Severity classification criteria
4. Containment
- Short-term containment actions
- Long-term containment actions
- Evidence preservation requirements
5. Eradication
- Root cause identification
- Malware/threat removal steps
- Verification procedures
6. Recovery
- System restoration steps
- Validation criteria
- Monitoring requirements post-recovery
7. Post-Incident
- Lessons learned meeting trigger
- Report template
- Detection improvement actions
8. Communication
- Internal notification matrix
- External notification requirements (regulators, customers, law enforcement)
- Status update cadence
9. Appendices
- Tool-specific procedures
- Contact lists
- Evidence collection checklists
ステップ 3:判断ツリーとエスカレーション基準を作成する
結果が二者択一となる明確な判断ポイントを定義します。
Detection Alert Received
├── Is the alert a true positive?
│ ├── YES → Classify severity
│ │ ├── P1 (Critical) → Page incident commander, begin containment immediately
│ │ ├── P2 (High) → Notify IR lead, begin investigation within 30 min
│ │ ├── P3 (Medium) → Queue for investigation within 4 hours
│ │ └── P4 (Low) → Document and investigate within 24 hours
│ └── NO → Document as false positive, tune detection rule
└── Cannot determine → Escalate to Tier 2 for deeper analysis
エスカレーションのトリガー:
- P1 インシデントはすべて、IR リードと CISO に直ちにエスカレーションします
- データ流出が確認された場合:法務顧問とプライバシー責任者に通知します
- 顧客データが関係する場合:顧客通知プロセスを開始します
- サードパーティが関係する場合:ベンダーのセキュリティ窓口に連絡します
- 法執行機関への連絡が必要な場合:連絡前に法務顧問の承認を得ます
ステップ 4:具体的な技術手順を定義する
各ステップについて、一般的な指針ではなく、ツール固有の手順を記述します。
CONTAINMENT - Endpoint Isolation via CrowdStrike:
1. Open Falcon Console > Hosts > Search for affected hostname
2. Click on the host > Host Details
3. Click "Contain Host" button in upper right
4. Confirm isolation (host will only communicate with CrowdStrike cloud)
5. Document containment action in incident ticket with timestamp
6. Verify containment: Host should show "Contained" status badge
CONTAINMENT - Block C2 Domain at DNS:
1. SSH to DNS server: ssh [email protected]
2. Add to block zone: echo "zone evil.com { type master; file /etc/bind/db.sinkhole; };" >> /etc/bind/named.conf.local
3. Reload DNS: rndc reload
4. Verify: dig @dns-primary evil.com (should resolve to sinkhole IP 10.0.0.99)
5. Document blocked domain in incident ticket
ステップ 5:SOAR プラットフォームと統合する
手動のプレイブック手順を自動化されたワークフローに変換します。
- 各プレイブックのステップを SOAR アクション(API 呼び出し、スクリプト、人による判断ポイント)に対応付けます
- 自動化の範囲(自動実行する処理と、アナリストの承認が必要な処理)を定義します
- トリアージ段階の情報補強を自動化します
- 影響の大きいアクションに承認ゲートを設けた封じ込め自動化を作成します
- 関係者への連絡に使用する通知自動化を設定します
ステップ 6:プレイブックをテストし、保守する
演習を通じてプレイブックを検証し、最新の状態を保ちます。
- IR チームがプレイブックの手順を確認しながら、机上演習を実施します
- テスト環境で対象のインシデントの種類をシミュレートし、実地演習を実施します
- プレイブックを使用した実際のインシデントの発生後は、毎回レビューして更新します
- 連絡先リスト、ツールの手順、エスカレーション経路の正確性について、四半期ごとのレビューを予定します
- プレイブックの指標(封じ込めまでの平均時間、解決までの平均時間、誤検知率)を追跡します
主要な概念
| 用語 | 定義 |
|---|---|
| プレイブック | 特定のインシデントの種類に対応するための、文書化された再現可能な一連の手順です |
| ランブック | プレイブックよりも詳細なもので、プレイブック内の特定のタスクを実行するための段階的な技術手順です |
| RACI マトリックス | 各アクティビティについて、責任者(Responsible)、説明責任者(Accountable)、協議先(Consulted)、報告先(Informed)を定める責任分担表です |
| 意思決定ツリー | 各判断時点での二択の条件に基づいて対応経路を定める、フローチャート形式のロジックです |
| エスカレーション基準 | 上位の担当者または外部関係者への通知を開始する、事前に定められた条件です |
| 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 にケースを作成します
- 模擬フィッシングメールを使ってテストし、対応時間の改善を測定します
落とし穴:
- 特定のツールのインターフェースやコマンドに言及しない、抽象的すぎる手順を書くこと
- フィッシングメールを受信したユーザーへの通知計画を含めないこと
- フィッシング報告が正式なインシデント調査に移行する基準を定義し忘れること
- プレイブックをバージョン管理せず、定期的なレビューサイクルも設定しないこと
出力形式
INCIDENT RESPONSE PLAYBOOK
============================
Playbook Name: Phishing Incident Response
Version: 2.1
Owner: SOC Manager
Last Reviewed: 2025-11-01
Next Review: 2026-02-01
Trigger: Phishing email reported via [email protected] or phish button
RACI MATRIX
Activity | SOC L1 | SOC L2 | IR Lead | Legal | Comms
Initial Triage | R | C | I | |
Email Analysis | R | A | I | |
Containment | | R | A | I |
Credential Reset | | R | A | |
User Notification | | C | A | | R
Regulatory Notification | | | C | R | A
Lessons Learned | C | C | R | I | I
PROCEDURE STEPS
[Detailed steps with tool-specific instructions]
DECISION TREE
[Flowchart logic]
ESCALATION MATRIX
[Conditions and contacts]
METRICS
Target MTTA: 15 minutes
Target MTTC: 1 hour
Target MTTR: 4 hours
コメント
Markdown 対応