事件后经验总结(Post-Incident Lessons Learned)
适用场景
- 安全事件完全解决且恢复完成后
- 桌面推演或 IR 模拟后
- 重大险情事件后
- 季度性的累积事件趋势审查
- 需要根据实际经验更新 IR 运行手册时
前置条件
- 事件已完全解决(遏制、根除、恢复均已完成)
- 事件时间线和文档已收集
- 所有事件响应人员可参与审查会议
- 协作讨论的会议场所
- 用于指标分析的事件工单系统数据
工作流程
步骤 1:收集事件数据
# 从工单系统导出事件时间线
curl -s "https://thehive.local/api/v1/case/$CASE_ID/timeline" \
-H "Authorization: Bearer $THEHIVE_API_KEY" | jq '.' > incident_timeline.json
# 从 SIEM 提取检测和响应指标
index=notable incident_id="IR-2024-042"
| stats min(_time) as first_alert, max(_time) as last_alert,
count as total_alerts, dc(src) as unique_sources
# 汇编所有响应人员操作和时间戳
grep -E "timestamp|action|analyst" /var/log/ir/IR-2024-042/*.json | \
python3 -m json.tool > compiled_actions.json
步骤 2:召开免责事后审查会议
结构化议程(90 分钟):
1. 事件摘要(5 分钟)- 事实性概述
2. 时间线梳理(20 分钟)- 按时间顺序的事件
3. 哪些有效(15 分钟)- 积极成果
4. 哪些需要改进(15 分钟)- 差距和失败
5. 根本原因分析(15 分钟)- 5 个为什么或鱼骨图
6. 行动项目(10 分钟)- 有负责人的具体改进措施
7. 运行手册更新(10 分钟)- IR 流程变更
免责原则:
- 关注系统和流程,而非个人
- 假设在现有信息下做出了最佳决策
- 寻求理解,而非归责
步骤 3:执行根本原因分析
# 5 个为什么分析示例:
# 为什么 1:为什么勒索软件加密了生产服务器?
# 答:攻击者拥有域管理员凭据
# 为什么 2:为什么攻击者拥有域管理员凭据?
# 答:对服务账号进行了 Kerberoasting 并破解了密码
# 为什么 3:为什么服务账号密码可以被破解?
# 答:使用了 12 个字符的基于字典的密码
# 为什么 4:为什么服务账号密码很弱?
# 答:没有强制执行服务账号密码策略
# 为什么 5:为什么没有服务账号密码策略?
# 答:未对服务账号实施 PAM
# 根本原因:缺少特权访问管理
步骤 4:计算响应指标
from datetime import datetime
events = {
'compromise': '2024-01-10 14:00:00',
'detection': '2024-01-15 08:30:00',
'triage': '2024-01-15 08:45:00',
'containment': '2024-01-15 09:30:00',
'eradication': '2024-01-16 14:00:00',
'recovery': '2024-01-18 16:00:00',
'closure': '2024-01-25 10:00:00',
}
fmt = '%Y-%m-%d %H:%M:%S'
times = {k: datetime.strptime(v, fmt) for k, v in events.items()}
print(f"驻留时间: {times['detection'] - times['compromise']}")
print(f"MTTD: {times['triage'] - times['detection']}")
print(f"MTTC: {times['containment'] - times['detection']}")
print(f"MTTR: {times['recovery'] - times['eradication']}")
print(f"总时长: {times['closure'] - times['detection']}")
步骤 5:记录发现并创建行动项目
# 在项目管理系统中创建可追踪的行动项目
curl -X POST "https://jira.local/rest/api/2/issue" \
-H "Authorization: Bearer $JIRA_TOKEN" \
-H "Content-Type: application/json" \
-d '{
"fields": {
"project": {"key": "SEC"},
"summary": "为服务账号实施 PAM(IR-2024-042)",
"issuetype": {"name": "Task"},
"priority": {"name": "High"},
"assignee": {"name": "security_engineer"},
"duedate": "2024-03-15"
}
}'
步骤 6:更新运行手册和检测规则
# 基于事件经验的新 Sigma 检测规则
title: 检测到 Kerberoasting 活动
status: stable
description: 基于 IR-2024-042 经验检测 Kerberoasting
logsource:
product: windows
service: security
detection:
selection:
EventID: 4769
TicketEncryptionType: '0x17'
condition: selection
level: high
tags:
- attack.credential_access
- attack.t1558.003
核心概念
| 概念 |
说明 |
| 免责事后审查(Blameless Post-Mortem) |
以系统为焦点而非追究个人责任的事件审查方式 |
| 根本原因分析(Root Cause Analysis) |
识别导致事件发生的根本原因 |
| 5 个为什么(5 Whys) |
通过迭代提问找到根本原因的技术 |
| MTTD(Mean Time to Detect,平均检测时间) |
从攻陷到检测的时间 |
| MTTC(Mean Time to Contain,平均遏制时间) |
从检测到遏制的时间 |
| MTTR(Mean Time to Recover,平均恢复时间) |
从根除到完全恢复的时间 |
| 持续改进(Continuous Improvement) |
基于真实事件数据迭代优化 IR 流程 |
工具与系统
| 工具 |
用途 |
| TheHive/ServiceNow |
事件时间线和文档管理 |
| Jira/Azure DevOps |
行动项目跟踪 |
| Confluence/SharePoint |
经验总结文档 |
| Splunk/Elastic |
事件指标和检测改进 |
| Sigma |
检测规则开发 |
常见场景
- 勒索软件事后审查:审查从初始访问到加密的完整杀伤链,识别检测缺口和备份失败。
- 钓鱼活动审查:分析用户为何点击、邮件过滤器为何遗漏以及如何改进培训。
- 云配置错误事件:审查 IaC 流水线、CSPM 覆盖范围和变更管理流程。
- 内部威胁审查:检查 DLP 有效性、访问控制缺口和用户监控能力。
- 第三方泄露影响:审查供应商风险评估流程和数据共享协议。
输出格式
- 事件后审查会议记录
- 根本原因分析文档
- 事件指标报告(MTTD、MTTC、MTTR)
- 有负责人和截止日期的行动项目列表
- 更新后的 IR 运行手册和检测规则
- 面向管理层的执行摘要