conducting-post-incident-lessons-learned

开展事件后经验教训总结

何时使用

• 在任何安全事件已完全解决且恢复完成后
• 在桌面演练或 IR 模拟之后
• 在发生重大未遂事件之后
• 每季度审查累积的事件趋势时
• 当 IR 手册需要根据实际经验更新时

前置条件

• 事件已完全解决（遏制、根除、恢复均已完成）
• 已收集事件时间线和文档
• 所有事件响应人员均可参加复盘会议
• 有用于协作讨论的会议空间
• 有事件工单系统数据用于指标分析

工作流

第 1 步：收集事件数据

# Export incident timeline from ticketing system
curl -s "https://thehive.local/api/v1/case/$CASE_ID/timeline" \
  -H "Authorization: Bearer $THEHIVE_API_KEY" | jq '.' > incident_timeline.json

# Extract detection and response metrics from 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

# Compile all responder actions and timestamps
grep -E "timestamp|action|analyst" /var/log/ir/IR-2024-042/*.json | \
  python3 -m json.tool > compiled_actions.json

第 2 步：召开无责事后复盘会议

Structured Agenda (90 minutes):
1. Incident summary (5 min) - Factual overview
2. Timeline walkthrough (20 min) - Chronological events
3. What worked well (15 min) - Positive outcomes
4. What needs improvement (15 min) - Gaps and failures
5. Root cause analysis (15 min) - 5 Whys or fishbone
6. Action items (10 min) - Specific improvements with owners
7. Playbook updates (10 min) - Changes to IR procedures

Blameless Principles:
- Focus on systems and processes, not individuals
- Assume best intentions with available information
- Seek to understand, not to blame

第 3 步：执行根本原因分析

# 5 Whys analysis example:
# Why 1: Why did ransomware encrypt production servers?
#   Answer: Attacker had domain admin credentials
# Why 2: Why did attacker have domain admin credentials?
#   Answer: Kerberoasted a service account and cracked it
# Why 3: Why was the service account password crackable?
#   Answer: Used a 12-character dictionary-based password
# Why 4: Why was the service account password weak?
#   Answer: No enforcement of service account password policy
# Why 5: Why was there no service account password policy?
#   Answer: PAM was not implemented for service accounts
# ROOT CAUSE: Lack of privileged access management

第 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"Dwell Time: {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"Total Duration: {times['closure'] - times['detection']}")

第 5 步：记录发现并创建行动项

# Create tracked action items in project management
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": "Implement PAM for service accounts (IR-2024-042)",
      "issuetype": {"name": "Task"},
      "priority": {"name": "High"},
      "assignee": {"name": "security_engineer"},
      "duedate": "2024-03-15"
    }
  }'

第 6 步：更新手册和检测规则

# New Sigma detection rule based on incident learnings
title: Kerberoasting Activity Detected
status: stable
description: Detects Kerberoasting based on IR-2024-042 lessons
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4769
    TicketEncryptionType: '0x17'
  condition: selection
level: high
tags:
  - attack.credential_access
  - attack.t1558.003

关键概念

概念	描述
无责事后复盘	审查事件时关注系统，而非归咎于个人
根本原因分析	识别事件发生的根本原因
5 Why	通过反复提问找到根本原因的技术
MTTD	平均检测时间 - 从失陷到检测的时间
MTTC	平均遏制时间 - 从检测到遏制的时间
MTTR	平均恢复时间 - 从根除到完全恢复的时间
持续改进	基于真实事件数据迭代 IR 流程

工具与系统

工具	用途
TheHive/ServiceNow	事件时间线和文档
Jira/Azure DevOps	行动项跟踪
Confluence/SharePoint	经验教训文档
Splunk/Elastic	事件指标和检测改进
Sigma	检测规则开发

常见场景

1. 勒索软件事后复盘：审查从初始访问到加密的整个杀伤链。识别检测缺口和备份故障。
2. 钓鱼活动复盘：分析用户为何点击、邮件过滤器为何漏掉，以及如何改进培训。
3. 云配置错误事件：审查 IaC 流水线、CSPM 覆盖范围和变更管理流程。
4. 内部威胁复盘：检查 DLP 有效性、访问控制缺口和用户监控能力。
5. 第三方泄露影响：审查供应商风险评估流程和数据共享协议。

输出格式

• 事件后复盘会议纪要
• 根本原因分析文档
• 事件指标报告（MTTD、MTTC、MTTR）
• 带负责人和截止日期的行动项列表
• 更新后的 IR 手册和检测规则
• 面向管理层的执行摘要