38.11 安全应急响应
一句话
安全应急的第一目标不是“查清真相”，而是在损失扩大前止血、同时保住证据；顺序错了（先重启、先删日志、先格式化）就把可追查性连同损失一起交出去。
四个误区，先拆掉
| 误区 | 现实 |
|---|---|
| 先查清谁干的、怎么进来的 | 查清通常要几天，而数据正在以每小时固定速率外流。先止血，再取证，顺序不能反 |
| 先重启/先重装恢复业务 | 重启会清掉内存里的后门、连接、进程链——最关键的证据在第一层就没了，还会让攻击者知道你发现了 |
| 没确认就不敢上报 | 通报时限从“知道”起算，不是从“确认”起算。拖到确认往往已经超时，且性质从“技术事件”变成“瞒报” |
| 安全团队单打 | 应急要研发（改代码）、运维（隔离）、法务（通报）、公关（对外）、客服（用户沟通）同时动，安全团队只是指挥席 |
六阶段：每一步的产出与最常见错误
| 阶段 | 谁主导 | 产出 | 最常见错误 |
|---|---|---|---|
| 准备 | 安全 + SRE | 联系人表、权限预案、取证包（预装工具与只读介质）、演练记录 | 出事时才发现“隔离权限要临时申请” |
| 检测与分析 | 安全（值班） | 事件单、影响面初判、分级 | 只信告警不看原始日志，误判为“误报”而关掉 |
| 遏制 | 指挥 + 运维 | 止血动作与时间戳、证据快照 | 直接重启、直接删库、直接格式化 |
| 根除 | 研发 + 安全 | 补丁、后门清除、凭证轮换记录 | 只清当前主机，没查横向移动 |
| 恢复 | 运维 + 业务 | 分批放量、加强监控、观察窗口 | 一次性全量放开，攻击者仍在 |
| 复盘 | 指挥 | 时间线、根因、行动项（owner + 期限） | 报告只写“已处置完毕”，没有行动项 |
分级：先定级，才谈时限
| 级别 | 判据 | 首次响应 | 指挥 | 对外通报 |
|---|---|---|---|---|
| P0 | 核心数据批量外泄 / 核心链路被控 / 勒索 | 15 分钟内 | CTO + 安全负责人 | 法务 + 公关，按法域时限 |
| P1 | 单租户数据泄露 / 可越权访问资金 / 内网失陷 | 1 小时 | 安全负责人 | 视监管要求 |
| P2 | 单点漏洞被利用、无数据外泄证据 | 4 小时 | 安全值班 | 内部 |
| P3 | 扫描探测、低危漏洞报告 | 1 个工作日 | 安全值班 | 不需要 |
🔑 定级的依据是“影响面”，不是“技术听起来多严重”。同一个 RCE，在无数据的测试环境是 P2，在核心库是 P0。先定级的好处是：它替你决定了“谁有权喊停”和“要不要惊动法务”，这两个决定在凌晨三点最难做。
遏制：三种手段，各有代价
| 手段 | 生效速度 | 副作用 | 对取证的影响 | 什么时候用 |
|---|---|---|---|---|
| 网络隔离（安全组/出口封禁） | 分钟级 | 业务可能整体不可用 | 小（主机仍活着，内存与连接都在） | 首选：先切断外传与横向移动 |
| 吊销凭证 + 踢会话 | 分钟级 | 用户被登出、批处理失败 | 小 | 凭证泄露、会话被劫持 |
| 关停服务 | 秒级 | 全量不可用、损失直接落地 | 中（进程被杀，内存证据丢失） | 最后手段，或已被勒索时 |
顺序建议：先切外传通道（隔离）→ 再吊销凭证 → 最后才关服务。原因很直接：前两步能止住“继续丢数据”，第三步只是止住“继续提供服务”。
可运行的时间账：暴露量 = 速率 × 窗口
package main
import (
"fmt"
"time"
)
// 安全事件的时间账：检测与遏制之间的每一小时，都按"外传速率"折算成记录数。
// 时间戳全部用 UTC，避免跨时区复盘时先吵半小时"谁先动的"。
type phase struct {
name string
from time.Time
to time.Time
}
func (p phase) dur() time.Duration { return p.to.Sub(p.from) }
func hm(d time.Duration) string { return fmt.Sprintf("%.1fh", d.Hours()) }
func main() {
parse := func(s string) time.Time {
t, err := time.Parse("2006-01-02 15:04", s)
if err != nil {
panic(err)
}
return t
}
t0 := parse("2026-03-02 14:00") // 初始入侵（事后从日志倒推）
t1 := parse("2026-03-03 09:00") // 告警触发
t2 := parse("2026-03-03 09:40") // 有人认领并接管
t3 := parse("2026-03-04 02:00") // 遏制完成（凭证吊销 + 出口封禁）
t4 := parse("2026-03-04 18:00") // 根除完成（后门清除、补丁上线）
t5 := parse("2026-03-05 10:00") // 业务恢复
phases := []phase{
{"检测（入侵 → 告警）", t0, t1},
{"响应（告警 → 认领）", t1, t2},
{"遏制（认领 → 隔离）", t2, t3},
{"根除（隔离 → 清除）", t3, t4},
{"恢复（清除 → 业务恢复）", t4, t5},
}
fmt.Println("【一】五段耗时（外传速率 2000 条/小时，示例值）")
var total time.Duration
for _, p := range phases {
total += p.dur()
fmt.Printf("%-26s %8s\n", p.name, hm(p.dur()))
}
fmt.Printf("%-26s %8s\n", "合计（入侵 → 恢复）", hm(total))
dwell := t3.Sub(t0) // 暴露窗口止于遏制完成
const rate = 2000.0 // 条/小时
fmt.Printf("\n【二】暴露量 = 外传速率 × 暴露窗口（入侵 → 遏制）\n")
fmt.Printf("暴露窗口 %s × %.0f 条/h = %.0f 条记录\n", hm(dwell), rate, dwell.Hours()*rate)
fmt.Printf("若检测从 %s 压到 1h，暴露量 = %.0f 条（降 %.0f%%）\n",
hm(t1.Sub(t0)), (dwell.Hours()-t1.Sub(t0).Hours()+1)*rate,
100*(1-(dwell.Hours()-t1.Sub(t0).Hours()+1)/dwell.Hours()))
fmt.Printf("\n【三】通报时限（从“知道”起算，不是从“入侵”起算）\n")
deadline := t1.Add(72 * time.Hour)
fmt.Printf("72 小时口径（GDPR Art.33；中国《个人信息保护法》要求“立即”，无固定小时数）：%s\n",
deadline.Format("2006-01-02 15:04"))
fmt.Printf("实际完成遏制：%s → %s截止 %s\n", t3.Format("2006-01-02 15:04"),
map[bool]string{true: "早于", false: "晚于"}[t3.Before(deadline)], deadline.Format("01-02 15:04"))
fmt.Println("\n【四】关键指标（同一套时间戳算出来，可跨事件比较）")
fmt.Printf("MTTD（检测） %8s\n", hm(t1.Sub(t0)))
fmt.Printf("MTTA（认领） %8s\n", hm(t2.Sub(t1)))
fmt.Printf("MTTC（遏制） %8s\n", hm(t3.Sub(t2)))
fmt.Printf("MTTR（恢复） %8s\n", hm(t5.Sub(t1)))
}
本机运行结果（GO111MODULE=off go run main.go，Go 1.27.1 darwin/arm64）：
【一】五段耗时（外传速率 2000 条/小时，示例值）
检测（入侵 → 告警） 19.0h
响应（告警 → 认领） 0.7h
遏制（认领 → 隔离） 16.3h
根除（隔离 → 清除） 16.0h
恢复（清除 → 业务恢复） 16.0h
合计（入侵 → 恢复） 68.0h
【二】暴露量 = 外传速率 × 暴露窗口（入侵 → 遏制）
暴露窗口 36.0h × 2000 条/h = 72000 条记录
若检测从 19.0h 压到 1h，暴露量 = 36000 条（降 50%）
【三】通报时限（从“知道”起算，不是从“入侵”起算）
72 小时口径（GDPR Art.33；中国《个人信息保护法》要求“立即”，无固定小时数）：2026-03-06 09:00
实际完成遏制：2026-03-04 02:00 → 早于截止 03-06 09:00
【四】关键指标（同一套时间戳算出来，可跨事件比较）
MTTD（检测） 19.0h
MTTA（认领） 0.7h
MTTC（遏制） 16.3h
MTTR（恢复） 49.0h
逐条读这份输出：
- 检测 19 小时占暴露窗口的 52.8%——暴露窗口是 36 小时（入侵到遏制），其中一半多在“没人知道”。把检测压到 1 小时，暴露量从 72000 条降到 36000 条（−50%）。应急响应里投入产出最高的一项，永远是检测，不是处置。
- 认领只用了 0.7 小时，遏制却用了 16.3 小时：说明瓶颈不在“有没有人管”，而在“敢不敢下手”（谁有权封出口、封了业务方是否答应）。这一段是组织问题，加工具没用，只能靠预案里写死“P0 由谁拍板”。
- MTTR 49 小时 ≠ 用户受影响 49 小时：遏制在第 36.3 小时就完成了，之后是根除与恢复。对外承诺用的应该是“遏制时间”（数据停止外流、攻击者失去控制），而不是“业务完全恢复时间”——两者混用会让复盘的数字对不上。
- 72 小时通报截止前完成了遏制，但这不代表可以慢慢通报：截止是按“知道”起算的，本例是 03-03 09:00 + 72h。若告警当晚无人认领（MTTA 从 0.7h 变成 12h），截止时间不变，准备材料的时间就少了 11 小时。
证据保全：按易失性顺序取，别按方便取
| 顺序 | 证据 | 为什么先取 | 常用命令（未验证：本机无目标环境） |
|---|---|---|---|
| 1 | 内存 | 进程、密钥、连接、后门代码只在内存里，重启即失 | avml / winpmem 抓内存镜像 |
| 2 | 网络连接 | ss/netstat 的连接表，攻击者的 C2 地址在这里 | ss -antp、lsof -i |
| 3 | 进程与定时任务 | 持久化机制（cron、systemd、计划任务） | ps auxf、crontab -l、systemctl list-timers |
| 4 | 磁盘镜像 | 文件系统里的一切，但量大、耗时 | dd（只读挂载）、云厂商快照 |
| 5 | 日志 | 应用、系统、网关、审计日志 | 先异地备份再分析，别在原机 grep |
| 6 | 备份与配置 | IaC 仓库、密钥库、证书 | 版本库历史 + 密钥轮换记录 |
⚠️ 最容易被破坏的不是磁盘，是内存与连接表。所以第一条纪律是：在隔离主机之前，先跑一遍取证脚本（把内存、连接、进程、定时任务各存一份），再动手。
反模式
| 反模式 | 后果 |
|---|---|
| 先重启再排查 | 内存证据与连接表全丢，攻击者提前知情并清理痕迹 |
直接在受害机上 grep 日志 | 攻击者能看到你的排查动作；且 grep 会改访问时间 |
| 只封一台主机，不查横向移动 | 相邻主机上的后门仍在，48 小时后二次失陷 |
| 通报等“确认”后再报 | 时限已过，性质从技术事件变成合规问题 |
| 复盘只写“已恢复” | 没有行动项与 owner，同类事件半年后重演 |
| 用“攻击者没拿走数据”结案 | 外传证据往往不在你的日志里（走加密通道/第三方服务） |
关联
- 前置：38.9 安全开发 (SDL / DevSecOps / SAST / DAST)（把事件挡在发生之前）、38.6 常见攻击（判断“被利用的是哪一类”）
- 并列：56.5 事故响应（通用事故的指挥与沟通框架，安全事件同样适用）
- 下游：56.6 无指责复盘（复盘方法与行动项跟踪）、38.10 供应链安全（依赖被投毒时的取证与替换）
自检
Q1 凌晨 2 点告警：某服务疑似被入侵，数据正在外传。值班人的第一个动作应该是什么？为什么不是“重启服务”？
▸ 答案：第一个动作是切断外传通道（封出口 / 隔离主机 / 吊销该主机的出网凭证），同时跑一遍取证脚本把内存、连接表、进程、定时任务存下来。不能先重启：重启会清掉内存里的后门与 C2 连接（证据 1、2 全丢），还会让攻击者立刻知道被发现。顺序是“先取证快照 → 再隔离 → 再吊销凭证”，关停服务是最后手段——它只止住“继续提供服务”，止不住“继续丢数据”。
Q2 本例 MTTD 19h、MTTC 16.3h、MTTR 49h。对外该承诺哪个数字？为什么不能混用？
▸ 答案：对外（监管、客户）该用遏制时间：本例入侵到遏制是 36 小时，它对应“数据什么时候停止外流、攻击者什么时候失去控制”。MTTR 49h 是“业务完全恢复”，包含根除与恢复，与数据泄露的严重程度无关。混用的后果：① 复盘时数字对不上（有人说 36 小时、有人说 49 小时）；② 承诺被拉长到 49 小时后，团队会倾向于把“遏制”也拖到 49 小时——因为考核的是 MTTR，而遏制更难、更容易背锅。
Q3 团队说“我们做了隔离和查杀，事件已闭环”。还差哪三件事才能算闭环？
▸ 答案：① 横向移动排查：隔离了入口主机，但凭证可能已被复制到其他主机——要查认证日志里该凭证在异常时段的登录，而不是只查那一台；② 凭证与密钥轮换：任何在受害机上出现过的密钥、token、数据库密码都必须换，否则清掉后门也没用；③ 通报与复盘：按法域判断是否触发通报义务（本例 72 小时口径），并输出带 owner 与期限的行动项。缺任何一件，“闭环”都只是“当前这台机器干净了”。
Q4 为什么“检测”通常是投入产出最高的一环，而多数团队把预算花在“处置工具”上？
▸ 答案：因为暴露量 = 速率 × 窗口，窗口的一半以上在检测段（本例 19/36 = 52.8%）。检测每缩短 1 小时，就少丢 2000 条记录，而且检测能力对所有事件通用；处置工具只对已经发生的事件生效，且效果受“敢不敢下手”限制（本例 MTTC 16.3h 里大部分是决策等待）。团队偏爱处置工具的原因是：检测的成果是“没发生的事”，难以汇报；处置的成果是“我救回来了”，容易汇报。这也是为什么检测投入必须由指标（MTTD）来驱动，而不是靠自觉。