mcpField
B
building-incident-response-playbook

building-incident-response-playbook

github.com/mukul975安全35.2k293 次安装8 周前更新
代码仓库

关于 building-incident-response-playbook

面向安全团队的实用指南,用于编写可重复执行的事件响应程序。内容涵盖事件范围、决策路径、技术步骤、SOAR 自动化以及剧本测试与维护。

主要功能

  1. 01界定事件类型范围
  2. 02设计可复用的响应剧本
  3. 03制定决策树与升级标准
  4. 04编写具体工具操作步骤
  5. 05规划 SOAR 工作流
  6. 06测试与维护剧本

适用场景

  1. 01从零建立事件响应计划
  2. 02为新型攻击编写响应流程
  3. 03准备合规审计所需程序
  4. 04评估特定威胁下的响应差距

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/mukul975/anthropic-cybersecurity-skills --skill building-incident-response-playbook

安装后在 Claude Code 中输入/building-incident-response-playbook确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

LICENSE
references/
api-reference.md
scripts/
agent.py

详细介绍

构建事件响应手册

何时使用

  • 从零建立或完善事件响应程序
  • 在新型攻击发生后为新的事件类型记录处置流程
  • 在 SOAR 平台(Cortex XSOAR、Splunk SOAR)中自动化响应工作流
  • 为要求记录 IR 流程的合规审计做准备(SOC 2、PCI-DSS、HIPAA)
  • 针对特定威胁场景对现有 IR 能力进行差距分析

不要使用于一次性的临时调查;手册是可复用的流程文档,而不是特定案例的报告。

前置条件

  • 组织风险评估,按可能性和影响识别最主要的突发事件场景
  • 采用 NIST SP 800-61r3 或 SANS PICERL 框架作为组织 IR 标准
  • 资产清单,包含业务关键性评级和数据分类
  • RACI 图表,定义角色:事件指挥官、SOC 分析师、系统管理员、法务、沟通
  • 现有检测能力清单(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 团队进行桌面演练,走查手册内容
  • 在测试环境中执行模拟该事件类型的实弹演练
  • 每次使用该手册的真实事件后都进行审查和更新
  • 每季度审查联系人列表、工具流程和升级路径的准确性
  • 跟踪手册指标:平均遏制时间、平均解决时间、误报率

核心概念

术语定义
Playbook(响应手册)针对特定事件类型进行响应的、已文档化且可重复的流程集合
Runbook(操作手册)比 playbook 更细粒度;是 playbook 中针对特定任务的分步技术说明
RACI 矩阵责任分配图表,定义每项活动的负责人、批准人、被咨询人和被通知人
决策树基于流程图的逻辑,根据每个决策点的二元条件定义响应路径
升级标准触发通知更高级别人员或外部方的预定义条件
SOAR Playbook在 Security Orchestration, Automation, and Response 平台中执行 playbook 步骤的自动化工作流

工具与系统

  • Cortex XSOAR:SOAR 平台,具有可视化 playbook 编辑器、700+ 集成和协作 War Room
  • Splunk SOAR:与 Splunk ES 集成的 SOAR 平台,具有拖拽式 playbook 构建器和 2,800+ 自动化操作
  • TheHive:开源事件响应平台,其案例模板可作为 playbook 框架
  • Confluence / GitLab Wiki:用于维护人类可读 playbook 文档并支持版本控制的文档平台
  • Tines:无代码安全自动化平台,无需编程即可构建 playbook 工作流

常见场景

场景:从零构建钓鱼响应 Playbook

背景:一个拥有 5 人 SOC 的组织没有文档化的钓鱼响应流程。分析师处理钓鱼报告的方式不一致。

方法:

  1. 采访 SOC 分析师,记录他们当前的临时流程
  2. 定义触发条件:用户通过 abuse@ 邮箱或钓鱼按钮报告钓鱼邮件
  3. 编写分诊步骤:提取邮件头、检查发件人信誉、在沙箱中分析 URL/附件
  4. 定义遏制措施:从所有邮箱中隔离邮件、封锁发件人域名、如果凭据已输入则重置密码
  5. 构建 SOAR 自动化:从报告的邮件中自动提取 IOC,通过 VirusTotal 进行丰富,在 TheHive 中创建案例
  6. 使用模拟钓鱼邮件进行测试,并衡量响应时间的改进

陷阱:

  • 编写过于笼统的流程,未引用具体的工具界面或命令
  • 未包含通知收到钓鱼邮件的用户的沟通计划
  • 忘记定义钓鱼报告何时升级为完整事件调查的标准
  • 未对 playbook 进行版本管理或安排定期审查周期

输出格式

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