应急响应

事件生命周期

NIST SP 800-61r2 把应急响应分为四个阶段：

准备（Preparation）：在事件发生前建立 IR 团队、制定 Playbook、部署日志和告警基础设施、定期演练（桌面推演 Tabletop Exercise）。
检测与分析（Detection & Analysis）：从告警、日志、用户举报、威胁情报等渠道发现事件，确定事件范围、严重等级（P1/P2/P3）和初始影响评估。
遏制、清除与恢复（Containment, Eradication & Recovery）：短期遏制（隔离受感染主机）→ 长期遏制（修复漏洞）→ 清除（删除恶意文件、后门账号）→ 恢复（从备份还原、监控验证）。
事后活动（Post-Incident Activity）：编写事件报告，分析根因，复盘改进，更新防御措施和 Playbook。

[1]

「遏制还是保留证据」是事件处置初期最难的两难选择：关机会保护业务但可能清除内存中的溯源关键证据（进程树、网络连接、未落盘的恶意代码）；继续运行则给攻击者时间扩大战果。通常的做法是先对内存做 Dump（Volatility、Rekall），再进行隔离。

通知时机同样复杂：GDPR 要求数据泄露后 72 小时内向监管机构报告；PCI DSS 有类似要求；中国的《网络安全法》要求「立即」启动应急预案并向主管机关报告。公关与法务团队需要与技术团队同步介入，避免技术人员的内部沟通消息成为诉讼证据。

2013 年 Target 信用卡数据泄露（4000 万张卡）是应急响应失败的经典案例：安全运营团队实际上收到了 FireEye 系统的告警，但被忽视，导致攻击者在系统中潜伏数周。