安全事件响应流程图
安全事件响应流程的泳道图：从检测与分流，经严重性分级、遏制、证据保全与清除，一直到数据泄露通报、事后复盘与结案。
什么是安全事件响应流程
安全事件响应流程，是一个组织从发现可疑迹象的那一刻起，直到事件记录被关闭为止所遵循的序列。它被刻意设计成不同于 IT 服务事件流程。目标不仅是恢复服务，还要弄清楚攻击者做了什么、阻止他们继续做下去、保持证据完整，并判断这次事件是否必须向监管机构报告。
多数公开发布的流程共享同一副骨架。NIST SP 800-61r2 把它拆成准备，检测与分析，遏制、清除与恢复，以及事后活动。ISO/IEC 27035 用的则是规划与准备，检测与报告，评估与决策，响应，以及经验总结。本图沿用这个形态，并把在真实事件中最容易引发争论的两个决策画了出来：这到底是不是一次安全事件，以及这次泄露是否须通报。
团队在压力之下弄错的，通常是先后顺序的规则。用断电的方式遏制一台主机，会毁掉易失的内存证据。在范围尚未分析清楚之前就重建服务器，意味着你再也无法证明什么被拿走了。在系统尚未验证干净之前就恢复服务，会让整个环境再次被感染。提前约定好顺序，并且每个角色一条泳道，是这些规则能够熬过凌晨三点一通电话的方式。
本流程图涵盖的内容
本模板包含
- 五条角色泳道（报告人与检测、安全团队、事件指挥官、IT 运维、法务与传讯）横跨五个阶段列：检测与报告、分流与分级、遏制、清除与恢复，以及通报与复盘。
- 检测与报告：可疑活动通过单一的事件通道上报，随后由安全团队登记，并启动事件时间线。
- 分流之后的“是否确认为安全事件？”决策，把误报送往一份关闭的记录，把已确认的事件送往严重性与影响分级。
- “是否为高严重性事件？”决策，为高严重性情形指派一位具名的事件指挥官，其余一律直接进入遏制。
- 遏制被拆成短期（隔离受影响系统）与长期两段，中间是证据保全与系统镜像，之后是范围分析、清除，以及一个在未通过时回到隔离的“系统是否验证干净？”检查。
- 由法务与传讯负责的“是否属须通报的泄露？”决策，通向在法定时限内向监管机构和数据主体通报，随后是事后复盘、记录经验并结案。
何时使用本模板
- 你们正在编写或更新一份事件响应计划，需要用一页纸说明谁在什么时候做什么。
- 你们正在准备一次 ISO 27001 审核或一次客户安全评估，并被要求出示一份成文的响应流程（这张图证明流程存在，它本身并不表明符合性）。
- 你们正在进行桌面推演，希望把决策点、交接和通报时钟摊开来作为检验对象。
- 你们正在带新分析师入门，或者值班轮岗中包含安全团队以外的人。
- 你们希望安全、IT 运维和法务在事件发生之前而不是在事件当中就把交接谈定。
运作方式
把泳道改成你们真实的角色
把这五条泳道换成你们真正拥有的角色：SOC 或 MSSP、服务台、安全负责人、平台团队、数据保护官、外部取证机构或泄露事件法律顾问。如果某个角色并不存在，就删掉那条泳道，而不是让它空着无人承担。
设定你们的严重性判定标准
打开“对严重性与影响分级”方框，把说明换成你们自己的矩阵：什么样的事件算作高严重性、谁有权宣布，以及每个等级各自承诺什么样的响应时间。
确定通报时限与对应的监管机构
编辑“是否属须通报的泄露？”决策，让它写明适用于你们的制度：英国或欧盟 GDPR（72 小时内通报监管机关）、NIS2、HIPAA、行业规则，以及合同约定的客户通知期限——后者往往比法定期限更短。
补上人们在凌晨三点需要的联系方式
把事件通道、值班电话、事件指挥官排班和证据存放位置写进方框备注里，这样这张图在事件当中也用得上，而不只是在复盘时才拿出来。
调整回路并补上缺失的步骤
判断“系统是否验证干净？”回到隔离的这条分支是否符合你们的工作方式，并补上你们环境中特有的内容，例如启用常年合约的取证供应商、网络保险通报，或者一个客户沟通稿的审批步骤。
分发签署并保留版本
把这张图交给安全负责人、IT 运维和法务签署确认，然后保留获批版本。事件响应计划是一份受控文件，你们演练的版本应当就是你们发布的版本。
常见问题
事件响应流程分为哪些阶段？
本图使用五个阶段：检测与报告、分流与分级、遏制、清除与恢复，以及通报与复盘。它与 NIST SP 800-61r2 高度对应，后者使用检测与分析，遏制、清除与恢复，以及事后活动。NIST 另有一个准备阶段，但准备是持续性的工作（工具、值班排班、演练、常年服务合约），而不是你在事件当中执行的一个步骤，因此没有画在流程上。
安全事件响应与 IT 事件管理有什么不同？
一次 IT 服务事件在服务恢复时就结束了。安全事件不是，因为存在一个对手。过早恢复可能等于把攻击者的访问权重新交回去，而且它还带有 ITIL 事件流程并不承担的义务：在重建之前保全证据、判定哪些数据受到影响、并在需要时通报监管机构和个人。这正是本图把证据保全与镜像放在清除之前，并在恢复之后加上一条通报分支的原因。
谁应当担任事件指挥官，什么时候指派？
事件指挥官应当是有权做决定的人（把一套生产系统下线、聘请外部法律顾问、联系客户），而不一定是当下技术最强的人。他们负责协调，而不是负责调查。在本图中，只有当“是否为高严重性事件？”得到“是”时才指派指挥官；严重性较低的事件仍留在安全团队。在一次长时间的事件中，这个角色会在每次换班时明确交接。
72 小时的泄露通报时钟从什么时候开始？
在英国和欧盟 GDPR 之下，这 72 小时从组织知悉发生了个人数据泄露时起算，而不是从攻击开始时、也不是从调查结束时起算；如果尚未掌握完整情况，可以分阶段通报。通知受影响的个人是另一项判定：当泄露很可能给他们带来高风险时，须在不当延误的情况下通知。其他制度运行的是不同的时钟，因此请把适用于你们的那一个写在决策方框上。