简介：《信息系统应急响应预案》是一份面向企事业单位信息安全负责人、网络管理员及运维人员的文档资料，用于在信息系统遭遇突发事件时迅速启动处置流程，降低危害与影响。文档依照国家《信息安全事件分类分级指南》《国家突发公共事件总体应急预案》等编制，正文包含总则、组织机构与职责、预防与预警机制、应急响应程序等章节，并把突发事件细分为网络攻击、信息破坏、信息内容安全、网络故障、服务器与软件故障、灾害性事件等八类，按中断运行时长划分一般至特别重大四个级别，逐一给出判别口径与处置措施。资源包内共1个doc文件，约42KB，属于可直接编辑套用的预案模板。已有336人学习下载，适合需要快速搭建或完善本单位应急响应制度的安全与运维人员参考。
1. 预案写在 .doc 里，为什么真出事时没人翻它
凌晨两点告警响起来，值班的人先在共享盘里翻出《信息系统应急响应预案.doc》，打开看到第 17 页写着「立即上报领导小组」，可领导小组是谁、电话多少、多久算「立即」，一个字没写。于是他先去群里问，等人回话的十几分钟里，攻击者已经把横向移动做完了。这不是预案写得不用心，是它从落地那天起就被当成一份「制度材料」而不是一份「操作对象」。
信息系统应急响应预案真正要解决的是三件事：什么条件下谁做决策、动手的先后顺序是什么、每一步做完留下什么证据。它服务的读者也不是评审专家，而是半夜被叫起来的一线值班、安全工程师和系统管理员。写得好不好，唯一的判据是：一个不熟悉这套系统的人，拿着它能不能在 15 分钟内做出第一个正确动作。
2. 信息系统应急响应预案的分级标准与角色矩阵怎么定
2.1 事件分级按影响面乘持续时长，不按故障名字
分级不是给事件贴标签，它是整个预案的触发器。级别定不下来，后面所有动作都没法自动展开。常见做法是把判定条件写成可观察、可计时的事实，而不是「系统严重故障」这类形容词——形容词留给人解释，事实留给值班人执行。
| 级别 | 可观察的判定条件（满足任一即成立） | 启动决策人 | 首次通报时限 | 恢复目标 |
|---|---|---|---|---|
| P1 特别重大 | 核心业务整体不可用超过 10 分钟；核心数据被篡改或删除且无可信备份点 | 应急指挥 | 15 分钟内 | 2 小时内恢复核心功能 |
| P2 重大 | 单一核心模块不可用超过 30 分钟；管理员账号出现非授权使用 | 事件经理 | 30 分钟 | 4 小时 |
| P3 较大 | 非核心系统不可用；单台主机发现可疑程序但未横向扩散 | 值班主管 | 1 小时 | 8 小时 |
| P4 一般 | 性能下降但业务可用；单个用户账号异常 | 一线值班 | 当班内 | 24 小时 |
表里的分钟数要按自己系统的 RTO、RPO 改，别照抄。写成事实有三个直接好处：值班人不用等授权就能定级；通报范围由级别自动决定，不用临时问；演练时可以照着打分。最常见的误用是把「影响范围」写成部门名，比如「影响财务部」，这种描述既不能计时也不能复核。
2.2 角色矩阵：一个岗位可兼多角，但不能有空位
应急响应的失败往往不是技术不行，而是某个动作没人认领。角色矩阵的作用就是把「我以为他会做」变成「写着他做」。
| 角色 | 主责 | 备份人 | 预案中必须写死的动作 |
|---|---|---|---|
| 应急指挥 | 决策是否启动、是否停机、是否对外通报 | 由分管负责人指定 | 宣布级别、批准回滚 |
| 事件经理 | 组织处置、控制时间线、对外统一口径 | 安全负责人 | 召集处置人、记录时间点 |
| 技术处置 | 采集证据、隔离、根除、恢复 | 系统管理员 | 执行采集与隔离脚本 |
| 业务联络 | 判断业务影响、协调停机窗口 | 业务负责人 | 确认可接受的停机时长 |
| 记录员 | 记时间线、附证据文件清单 | 值班同事 | 每 10 分钟落一次时间点 |
一个人可以同时兼两个角色，但同一时刻不能既当处置人又当记录员，否则事后没人说得清先做了什么。记录员这个位置最容易被省掉，而它恰恰是复盘和定责的唯一依据。备份人机制要写成硬规则：主责人 5 分钟内联系不上，直接找备份人，不需要再请示任何人。
提示：每个角色留两个独立通道的联系方式，别把手机号和即时通讯都放在同一个会一起失效的地方。
2.3 把分级和角色写成可校验的配置
文档里的表格改起来方便，也容易被改坏——删掉一行备份人、把审批角色名写错，肉眼很难发现。我一般把分级和角色抽成一份 YAML，作为文档的数据源，改完跑一遍校验再导出。
# plan-meta.yaml：预案的分级与角色，既是文档数据源，也是校验脚本的输入 plan_version: "2024.2" review_cycle_days: 180 levels: - id: P1 name: 特别重大 triggers: ["核心系统整体不可用>=10min", "核心数据被篡改且无可信备份"] first_notify_minutes: 15 restore_target_minutes: 120 approver: cmd_lead - id: P3 name: 较大 triggers: ["单主机可疑程序未横向扩散"] first_notify_minutes: 60 restore_target_minutes: 480 approver: duty_supervisor roles: - key: cmd_lead title: 应急指挥 primary: { name: "张××", mobile: "139****", im: "值班群" } backup: { name: "李××", mobile: "138****", im: "值班群" } must_do: ["宣布级别", "批准停机或回滚"]# validate_plan.py：校验预案元数据完整性，缺项直接以非 0 退出，方便接进导出流程 import sys, yaml PLAN = yaml.safe_load(open("plan-meta.yaml", encoding="utf-8")) def fail(msg): print(f"[FAIL] {msg}") sys.exit(1) role_keys = {r["key"] for r in PLAN["roles"]} for lv in PLAN["levels"]: if lv["approver"] not in role_keys: fail(f"{lv['id']} 的审批角色 {lv['approver']} 未在 roles 中定义") for r in PLAN["roles"]: for slot in ("primary", "backup"): if not r[slot].get("mobile"): fail(f"{r['key']}.{slot} 缺少联系方式") print(f"[OK] 预案 {PLAN['plan_version']} 校验通过：{len(PLAN['levels'])} 个级别，{len(role_keys)} 个角色")逻辑说明：脚本先收集所有角色 key，再逐个检查每个级别的approver是否存在，避免出现「审批人指向一个不存在的角色」；然后检查每个角色的主备联系方式，空值直接失败。参数说明：plan_version用于导出时写入页脚；review_cycle_days用来提醒复审周期，超过 180 天未更新应该触发一次复核；first_notify_minutes和restore_target_minutes会被演练脚本直接读取，用来判定是否超时。校验失败就退出非 0，导出流程会直接中断，坏版本发不出去。
3. 技术处置章节：把主机排查命令写进预案附录
3.1 采集顺序：先易失后持久，别一上来就重启
预案里关于技术的部分，最容易写成「发现异常后立即杀进程并重启」。真实处置里这条最危险：进程一杀，内存里的连接关系、命令行参数、父子进程关系全没了；一重启，/proc下的证据全清空。正确的顺序是先记录时间基准、再采易失性数据、最后才动持久化文件和网络隔离。
# 易失性数据采集：输出全部落到独立目录，命令本身不修改系统状态 export CASE="/cases/$(date -u +%Y%m%dT%H%M%SZ)-INC" umask 077 mkdir -p "$CASE"/{volatile,logs,hash} date -u +"%F %T UTC" > "$CASE/volatile/collect_start.txt" uptime > "$CASE/volatile/uptime.txt" who -a > "$CASE/volatile/who.txt" ss -antp > "$CASE/volatile/ss.txt" 2>&1 ps -eo pid,ppid,user,lstart,etime,cmd --forest > "$CASE/volatile/ps.txt" ls -l /proc/*/exe > "$CASE/volatile/proc_exe.txt" 2>&1 sha256sum "$CASE"/volatile/* > "$CASE/hash/volatile.sha256"逻辑说明：先落一个 UTC 时间戳，是为了后面把所有主机、设备、应用的日志对齐到同一条时间线，跨时区排查时这一步能省掉大量争论。ss -antp里的p需要 root 权限才显示进程名，普通账户跑出来只有端口没有进程，这一点要提前在预案里注明用哪个账户执行。ps -eo lstart给的是绝对启动时间而不是相对时间，方便和登录日志比对。最后用sha256sum固定采集结果的完整性，移交时可以直接核对。参数说明：umask 077保证采集目录只有属主可读，避免证据被其他人改动。
注意：采集启动前先确认目标主机的时钟有没有同步，时钟偏差会让整条时间线失真，必要时在记录里写明偏差量。
3.2 Linux 入侵排查的六类证据与对应命令
预案的附录应该按「证据类别」组织命令，而不是按工具名堆砌。一线人员拿着类别就能往下查，不需要理解每一条命令背后的原理。
# 1) 进程与网络：重点找"名字和路径对不上"的进程 ps -eo pid,user,lstart,cmd --sort=start_time | tail -n 30 ls -l /proc/<PID>/cwd /proc/<PID>/exe # 可执行文件真实路径 tr '\0' '\n' < /proc/<PID>/environ | head # 启动参数，常藏外联地址 # 2) 计划任务与定时器：最常见的持久化位置 crontab -l for f in /etc/cron.d/* /etc/cron.hourly/* /etc/cron.daily/*; do echo "== $f"; cat "$f"; done systemctl list-timers --all # 3) 账户与登录：UID 0 账户和异常登录 awk -F: '($3==0){print}' /etc/passwd awk -F: '($2==""){print $1}' /etc/shadow last -aiF | head -n 40 lastb -aiF | head -n 40 # 4) 启动项与动态链接劫持 systemctl list-unit-files --state=enabled | tail -n 40 cat /etc/ld.so.preload 2>/dev/null # 5) 文件与时间线：与事件时间窗重合的改动 find /etc /usr/bin /usr/sbin /tmp /var/tmp -type f -newermt "-7 days" \ -printf "%T+ %p\n" 2>/dev/null | sort # 6) 日志：认证、审计与 Web 访问 journalctl --since "-24h" -p warning..alert --no-pager | tail -n 200 grep -Ei "Failed password|Accepted|sudo:" /var/log/secure /var/log/auth.log 2>/dev/null | tail -n 200逻辑说明：第 1 类看/proc/<PID>/exe是因为ps的 COMMAND 列可以被进程自己改写，而/proc里的链接指向真实文件，指向/tmp、/dev/shm或显示(deleted)的进程都值得重点看。第 2 类里，计划任务中一行包含 base64 解码、curl、wget的内容基本都是可疑的，正常运维任务很少这么写。第 4 类中/etc/ld.so.preload文件本身不存在是正常状态，一旦存在且指向不明动态库，就要按劫持处理。第 5 类依赖-newermt而不是访问时间，因为多数发行版默认relatime，访问时间在排查中不可靠。
3.3 关键证据字段与常见误操作对照
| 检查项 | 命令 | 要看的字段 | 常见误操作 |
|---|---|---|---|
| 监听端口 | ss -antp | 高位端口 + 陌生进程名 + 非标准路径 | 先 kill 进程再看，连接与内存证据丢失 |
| 进程 | ls -l /proc/PID/exe | 指向 /tmp、/dev/shm 或已删除 | 只看ps的 COMMAND 列，被同名伪装骗过 |
| 计划任务 | crontab -l、/etc/cron* | base64、curl、wget 组成的一行流 | 只查 root 的 crontab，漏掉业务账户 |
| 账户 | awk -F: '($3==0)' | 多出来的 UID 0 账户 | 只看 passwd，漏掉authorized_keys |
| 持久化 | systemctl list-unit-files | 近期新增的 enabled 单元 | 只查 systemd，漏掉 rc.local、ld.so.preload |
| 日志 | journalctl、/var/log/secure | 爆破成功后的首次登录 | 采集前清空日志或先重启，时间线断裂 |
提示：把这张表直接放进预案附录，比写一段「请全面排查系统异常」有用得多。
3.4 隔离与根除：只写最小动作
预案里的隔离章节不要写原理，只写动作和边界。网络层隔离优先，主机侧规则容易把自己也挡在外面。
# 主机侧应急隔离：先放行管理网段，再丢弃其余入向流量 iptables -I INPUT -p tcp --dport 22 -s 10.10.0.0/24 -j ACCEPT iptables -I INPUT -j DROP # 证据打包固定（务必在隔离动作之前完成易失性采集） tar -czf "$CASE.tar.gz" -C "$(dirname "$CASE")" "$(basename "$CASE")" sha256sum "$CASE.tar.gz" >> "$CASE/hash/package.sha256"逻辑说明：先插入放行规则再插入丢弃规则，顺序反了会把自己锁在外面；如果目标是通过交换机端口或 VLAN 做隔离，主机侧规则可以省略，避免和网络团队的操作互相覆盖。参数说明：-s 10.10.0.0/24要换成实际管理网段，别照抄。根除阶段的关键是重置受影响账户凭据、从可信基线重建而不是在原主机上删文件，恢复前要确认备份点的完整性和可用性——很多事故的第二段损失，都是用被污染的备份「恢复」出来的。
4. 把预案跑成可验证的检查单：桌面推演与限时演练
4.1 桌面推演：90 分钟能验证什么
预案写完不演练，等于不知道哪一页是错的。演练形式不必一上来就搞全员红蓝对抗，从桌面推演起步，投入最小、暴露问题最快。
| 演练形式 | 参与人 | 时长 | 能验证的预案要素 | 常暴露的问题 |
|---|---|---|---|---|
| 桌面推演 | 指挥、事件经理、业务联络 | 90 分钟 | 分级判定、上报链路、决策权限 | 同一现象两人判不同级别 |
| 单点技术演练 | 处置工程师 | 2 小时 | 采集脚本、隔离步骤、取证目录 | 命令权限不足、路径不存在 |
| 全流程演练 | 全员加业务方 | 半天 | 跨部门协同、对外口径、恢复顺序 | 业务方不知道找谁 |
| 无预告演练 | 值班团队 | 随机 | 值班独立性、备份人机制 | 主责人联系不上时无人接手 |
桌面推演的注入卡只给现象，不给结论，让参与者自己定级。比如给一张卡：「T+00:35，核心订单库主节点 CPU 持续 98%，应用侧 5xx 比例升至 12%，备份任务最近一次成功时间是昨天 02:10，值班工程师正在处理另一张工单。」观察员记录的第一个时间点，就是定级用时；如果超过预案里 P2 的 30 分钟通报时限，这条偏差必须写回文档。
4.2 用脚本把响应时限算成数字
演练结束后靠回忆写复盘，数字一定失真。我一般让记录员按固定格式填时间线，再用一个短脚本算指标。
# timeline_metrics.py：从演练时间线 CSV 中算 MTTD、MTTA、MTTR import csv, datetime as dt def parse(ts): # 统一按 UTC 解析，避免跨时区对不上 return dt.datetime.fromisoformat(ts.replace("Z", "+00:00")) rows = list(csv.DictReader(open("timeline.csv", encoding="utf-8"))) t = {r["event"]: parse(r["time"]) for r in rows} mttd = (t["detect"] - t["occur"]).total_seconds() / 60 # 发现用时 mtta = (t["ack"] - t["detect"]).total_seconds() / 60 # 响应用时 mttr = (t["restore"] - t["occur"]).total_seconds() / 60 # 恢复用时 print(f"MTTD={mttd:.1f}min MTTA={mtta:.1f}min MTTR={mttr:.1f}min") assert mtta <= 15, "首次响应超时：检查告警通道和备份人机制"逻辑说明：CSV 每行是event,time两个字段，用事件名做键，算出发现、响应、恢复三个区间；assert让脚本在超时的时候以非 0 退出，可以把演练接入流水线，超时即失败。参数说明：event取值固定为occur、detect、ack、restore，记录员按这四类填就行；时间统一用 UTC，带Z后缀。阈值 15 分钟对应预案里 P1 的首次通报时限，改预案时同步改这里。
4.3 偏差修复：结论要写回预案，不是写进会议纪要
演练的问题如果只停在纪要里，下一轮还会重演。每次演练结束的三个工作日内，把偏差逐条归类并落到具体修改。
| 偏差类型 | 典型表现 | 修复动作 | 验证方式 |
|---|---|---|---|
| 分级歧义 | 同一现象两人判不同级别 | 把形容词改成可观察事实并计时 | 下一轮重新判级 |
| 联系人失效 | 主责人电话打不通 | 补备份人、加独立第二通道 | 现场拨打测试 |
| 命令不可用 | 采集脚本某条命令在目标系统不存在 | 脚本加版本分支和降级路径 | 在测试机完整跑一遍 |
| 工具缺失 | 现场没有只读介质或抓包工具 | 工具清单并入应急箱并定期清点 | 开箱清点 |
| 权限不足 | 值班账户看不到进程名 | 预授权最小排查权限集 | 用值班账户实测 |
修复动作写完要体现在版本号上，plan_version从2024.2变成2024.3，变更记录里写清改了什么、依据哪次演练。这样下一次有人问「这条为什么是 15 分钟」，答案是一条演练记录，不是某个人的印象。
5. 进阶：把 .doc 变成版本化、可导出的应急响应预案
5.1 用 Git 管预案，.doc 只是导出产物
预案的正文用 Markdown 维护，分级和角色用 YAML，.doc和 PDF 交给导出流程生成。这样做不是为了好看，是为了能被 diff。谁在什么时候把 P2 的通报时限从 30 分钟改成 60 分钟、改动理由写在哪一行，都能查到；合并前还能先跑一遍完整性校验，把缺联系方式、审批角色写错的版本挡在发布之前。
# 预案导出：先校验元数据，再生成对外发布的 .docx python validate_plan.py || exit 1 pandoc plan.md -o "信息系统应急响应预案-$(date -u +%Y%m%d).docx" \ --reference-doc=template.docx \ --metadata version:"$(git describe --tags --always)" sha256sum "信息系统应急响应预案-$(date -u +%Y%m%d).docx" > plan.sha256逻辑说明：validate_plan.py返回非 0 就不导出，避免坏版本流出去；--reference-doc指定样式模板，导出的文件仍然保留单位的公文格式要求；--metadata version用 Git 描述填版本号，页脚能直接看到这份文件对应哪个提交。参数说明：导出物算一次 SHA256，和发布记录一起归档，方便确认现场用的是哪一版。
5.2 一键取证包：把附录命令固化成脚本
附录里的命令散落在文档中，现场还要一行行复制。把它们收进一个入口脚本，按固定顺序调用，输出目录只追加不覆盖。
#!/usr/bin/env bash # collect.sh <CASE_ID>：在目标主机按固定顺序采集，全程留执行记录 set -euo pipefail CASE_ID="${1:?用法: collect.sh CASE-20240612-01}" OUT="/mnt/evidence/${CASE_ID}" mkdir -p "$OUT" exec > >(tee -a "$OUT/collect.log") 2>&1 echo "[*] 开始采集 $(date -u +%FT%TZ) 主机 $(hostname)" bash ./volatile.sh "$OUT" # 易失性数据：连接、进程、登录 bash ./persist.sh "$OUT" # 持久化位置：计划任务、启动项、ld.so.preload bash ./logs.sh "$OUT" # 日志与文件时间线 sha256sum "$OUT"/*.txt > "$OUT/SHA256SUMS" echo "[*] 采集结束，核对 SHA256SUMS 后卸载介质"逻辑说明：set -euo pipefail保证任何一步失败立即停止，不会出现「看起来跑完了其实中间断了」；CASE_ID必填，缺失时直接报用法退出，避免证据全落进同一目录；exec > >(tee -a ...)让屏幕上看到的内容和执行日志完全一致，事后能还原脚本做过什么。参数说明：OUT指向只读介质或已挂载的取证盘，不要写在目标主机本地磁盘上。这个脚本本身也要进应急箱清点清单——演练时至少完整跑一次，把目标发行版上缺失的命令补进工具清单，比在文档里多写两段描述有用。
本文还有配套的精品资源，点击获取
