网络安全事件响应流程图（SOC）
SOC 或 CSIRT 运行的技术性网络安全事件响应生命周期泳道图：从告警分流到清除、恢复与检测规则调优。
什么是网络安全事件响应流程图（soc）流程
网络安全事件响应流程，是安全运营中心或 CSIRT 在一条检测告警触发之后所遵循的实际工作生命周期。分流并丰富告警、判断它是否为真实告警、宣布事件并确定严重等级、指派一名指挥官、找出攻击者接触过的每一项资产和每一个账户、在不破坏证据的前提下遏制、清除威胁、证明它确实已经消失，然后才恢复。本模板把这条序列画在五条泳道上：检测／SOC、事件响应人员、事件指挥官、IT 运维和管理层。
有必要说清楚这个流程不是什么，因为常有两个相邻流程被并进来，而两者都因此变弱。它不是 IT 事件管理——后者以恢复被中断的服务为衡量标准，用户能重新工作就算结束；而一次安全事件并不会因为服务恢复就结束，因为过早恢复可能等于把访问权重新交回给攻击者。它也不是数据泄露通知。判断个人数据是否受到影响、是否必须告知监管机构或客户、以及按什么时限告知，属于法务、数据保护官和公关的工作，它按法定期限而不是技术节奏运行，归属于范围更广的安全事件响应流程。本图与那部分工作并行，而不是把它吸收进来。
本图的形态遵循大多数公开指南共有的顺序。SANS 的六步模型——准备、识别、遏制、清除、恢复、经验总结——可以直接对应；NIST SP 800-61 Revision 2 把同样的工作分组为检测与分析，遏制、清除与恢复，以及事后活动。Revision 3 改为围绕 Cybersecurity Framework 2.0 的各项职能来组织指南，而不再使用固定的阶段清单，但响应人员实际的工作顺序并没有变。准备没有被画成一个方框，因为它是持续性的工作——工具、值班排班、常年服务合约、演练——而不是事件发生期间执行的一个步骤。这张图真正要保护的，是那个顺序：先证据后清除，先验证后恢复，以及有一位具名的人能够批准把一套生产系统下线。
本流程图涵盖的内容
本模板包含
- 五条角色泳道——检测／SOC、事件响应人员、事件指挥官、IT 运维和管理层——横跨六个阶段列：检测与分流、宣布、定范围与遏制、清除、恢复，以及经验总结。
- SOC 泳道中的分流：“分流并丰富告警”通向“是否为真实告警？”的决策，其“否”分支走“关闭告警并调整检测规则”，让一次误报去改变检测规则，而不是被随手忽略。
- 交接与指挥：“宣布事件并确定严重等级”把工作从 SOC 移交给事件响应人员，而“指派事件指挥官”指名了在此后整个事件中对决策负责的那个人。
- 由事件指挥官负责的“遏制是否会中断服务？”决策，其“是”分支先经过管理层泳道的“批准会中断服务的遏制措施”，然后由 IT 运维执行“隔离受影响的主机与账户”。
- 先证据后清理：“保全取证证据与镜像”位于遏制与清除阶段之间；清除阶段涵盖搜寻攻击者的其他驻留点、移除恶意软件与持久化手段，以及重置凭据并修补被利用的漏洞。
- “威胁是否已彻底清除？”这一验证决策在未通过时回到“识别受影响的资产与账户”，通过后则进行从干净备份重建、在 SOC 泳道中受监控地恢复、事后复盘，以及在结案前“更新检测规则与处置手册”。
何时使用本模板
- 你们正在运行或正在筹建一个 SOC 或 CSIRT，希望把技术生命周期放在一页纸上，从告警队列一直到下一次会触发的检测规则。
- 你们正在编写事件响应计划中偏操作手册的那一半，需要在事件发生之前就把遏制、证据和清除的先后顺序谈定，而不是在事件当中争论。
- 你们正在准备一次桌面推演或紫队测试，希望把决策点、回路和交接摊开来作为检验对象。
- 你们需要安全、IT 运维和管理层提前就“谁有权把一套生产系统下线”达成一致，并约定这个人正在睡觉时该怎么办。
- 你们正在带新分析师入门，希望把从分流到响应人员再到事件指挥官的升级路径明确画出来，而不是靠耳濡目染学会。
运作方式
把泳道改成你们真实的组织结构
把检测／SOC、事件响应人员、事件指挥官、IT 运维和管理层换成你们实际拥有的：一家外包的 MSSP、拆成两条泳道的一级和二级、用平台或云团队代替 IT 运维、一家常年合作的取证供应商。与其留下一条没有人手的泳道，不如删掉它；如果确实由一个人同时承担，就把指挥官并入响应人员泳道。
把你们的严重等级矩阵放在宣布步骤上
打开“宣布事件并确定严重等级”，把说明换成你们自己的标准：什么样的事件算作严重，谁有权宣布，以及每个等级在响应时间、人员投入和非工作时间召集上分别意味着什么承诺。严重等级驱动本图下游的每一个决策，因此值得写得具体。
定下遏制的授权规则
“遏制是否会中断服务？”这条分支只有在凌晨三点也有人能回答时才有用。写下哪些系统可以由响应人员自行授权隔离、哪些需要一次业务决策、这个决策由谁掌握，以及在约定时间内联系不上他时该怎么办。
在遏制之前先定好证据规则
把你们的采集顺序记录在“保全取证证据与镜像”上：先内存与实时网络状态，再磁盘，最后归档日志，遵循 RFC 3227 提出的易失性顺序原则。注明主机是在网络层被隔离而不是被断电关机，并写明镜像存放在哪里、由谁签收。
定义“威胁已彻底清除”是什么意思
把退出条件写在“威胁是否已彻底清除？”决策旁边：没有观察到攻击者活动的观察窗口、每一项失陷指标已在整个环境范围内排查、每一个被攻陷的凭据已轮换、被利用的漏洞已修补。同时决定失败分支是像本图这样回到定范围，还是回到遏制。
把它与前后两侧的流程连起来，并做好版本管理
补上通向数据泄露通知路径的明确链接，通向面向永久修复的问题管理或变更管理的链接，以及在适用时通向网络保险或供应商通知的链接。然后把这张图发给安全负责人、IT 运维和管理层签署确认，并保留获批版本，因为你们演练的计划应当就是你们发布的计划。
常见问题
网络安全事件响应流程分为哪些阶段？
本图使用六个阶段列：检测与分流、宣布、定范围与遏制、清除、恢复，以及经验总结。它对应 SANS 的六步模型——准备、识别、遏制、清除、恢复、经验总结——也对应 NIST SP 800-61 Revision 2，后者把这些工作分组为检测与分析，遏制、清除与恢复，以及事后活动。Revision 3 改为围绕 Cybersecurity Framework 2.0 的各项职能来组织指南，而不再使用固定的阶段清单。准备没有被画成一个步骤，因为它是持续性的工作——检测工程、值班排班、常年服务合约、演练——在任何告警之前进行，而不是在告警发生期间进行。
这与 IT 事件管理、以及与数据泄露通知有什么不同？
IT 事件管理恢复被中断的服务，并在用户能重新工作时结案。安全事件里有一个对手，因此恢复服务并不是终点线：如果威胁仍然驻留，那恰恰是风险最高的时刻——这正是本图把一个验证决策放在恢复之前的原因。数据泄露通知是另一个相邻流程。判断个人数据是否受到影响、是否必须告知监管机构或客户、以及在什么法定时限之内告知，是按法律时钟运行的法务与公关工作，它与技术响应并行，而不是包含在技术响应之内。
为什么证据保全要排在清除之前？
因为最常见的遏制动作会破坏你之后需要的证据。给主机断电会丢失只驻留在内存中的恶意软件、实时网络连接、已解密的内容和被注入的进程。在范围尚未弄清之前就重建一台服务器，会抹掉那些显示攻击者如何进入、又触及了什么的痕迹。RFC 3227 描述的易失性顺序原则给出了可操作的规则：先采集内存与实时状态，再采集磁盘，最后采集归档日志。在本图中，证据步骤位于隔离之后、任何清除工作之前，而主机是在网络层被隔离，因此保持运行。
如何判断威胁已经彻底清除？
用事件发生之前就写好的标准，而不是当场判断。通常包括：在约定的观察窗口内，整个环境范围没有观察到攻击者活动；调查中得到的每一项失陷指标都已在所有主机上排查，而不只是在告警过的主机上；每一个可能已被窃取的凭据都已轮换，包括服务账户和机器账户；以及导致初始入侵的漏洞或错误配置已被封堵。当答案是否时，通常意味着范围判断错了，而不是清理做得马虎——这也是本图的失败分支回到“识别受影响的资产与账户”而不是回到隔离的原因。
把生产服务下线的遏制措施由谁批准？
由有权承担业务影响的人批准，而这个人很少是发现问题的那位响应人员。本图把这类情形引向管理层泳道，但重点不在泳道名称，而在于这个决策、这个具名角色，以及联系不上他时的替代方案都是提前约定好的。许多团队会针对一份明确的系统清单和严重等级预先授权隔离，让常见情形永远不必等一通电话，而把升级审批保留给涉及营收或安全的服务。没有这一点，争论就会在攻击者仍在活动的时候发生。