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