不知您是否留意到，我们这边正在举国上下欢庆春节和冬奥会开幕之时，远在欧洲大陆的德国却传来了，其主要石油储存公司 Oiltanking，以及矿物油贸易公司 Mabanaft 的 IT 系统遭到黑客组织的持续网络攻击。由于他们的储罐装 / 卸载过程，完全依赖于已被攻击下线的计算机系统，因此无法从自动化退回到手动操作模式。此次中断预计会给整个供应链造成严重的影响。

遥想 2021 年 5 月，DarkSide 黑客集团也曾利用勒索软件，攻击了美国最大燃油管道公司 Colonial Pipeline，并引起了油气管道的计量系统无法运行，进而中断服务。面对这些屡禁不止的恶意安全事件，我不禁利用这个春节长假中，再次思考了事件响应与事件管理的相关问题。

事件响应与事件管理的区别✦

面对突发的各种网络安全事件，我们通常考虑的是如何在最短的时间内，去消除事件的影响，甚至会眉毛胡子一把抓、病急乱投医。不过，实际上事件响应(Incident Response，IR)和事件管理(Incident Management，IM)是两种截然不同的处置方式。理清它们之间的区别，将有助于我们从根本上更好的管控安全事件。

从定义上来看：

• 事件响应主要包括对事件进行检测分类、深入分析、实施控制、减少影响、保护关键数据、资产与系统、以及采取技术恢复等具体的行动要素。

• 事件管理主要涉及到安全事件响应团队在各个处置阶段所采取的不同流程，而且不限于技术流程。它包含了各种通信交流、升级转发、以及事态报告等。可以说，它起到了将整个响应的环节串联起来，形成一个有机整体的作用。

从人员上来看：

• 事件响应是技术人员的主要职责。

• 事件管理则需要更广泛的利益相关方(例如：法务部门、公关团队、合规人员、以及后勤保障等)开展沟通与协作。

从目标上来看：

• 事件响应需要各个职能角色各司其职，通过快速检测和修复损坏，来达到预定的技术要求。

• 事件管理则着眼于最小化安全事件对于整个业务的影响，最大程度地降低危害、防止组织因违规而招致的惩罚。

事件威胁建模✦

众所周知，事件响应离不开响应团队成员和应手的工具。常言道：“知己知彼，百战不殆。”一套清晰全面的威胁模型，可以被用来详细定义不同类型的安全威胁，概述组织会采取哪些略有区别地响应措施，以及涉及到的角色和责任等。面对可以预见的网络、系统和应用等维度的安全威胁，业界常用 STRIDE 威胁建模，来识别潜在的漏洞，并建立响应机制。该模型包含了六种不同的威胁类别：

• 欺骗身份(Spoofing identity)，主要针对的是系统的身份认证机制。攻击者伪造的身份既可以是合法用户本身，又可以是合法的技术调用或进程。例如，典型的中间人攻击(MIM)、网站木马、邮件伪造等都属于此类威胁。一旦获得了易受攻击系统的访问权限，攻击者便可以截取敏感信息，进而执行深层次的攻击。

• 篡改数据(Tampering with data)，主要针对的是数据的完整性。攻击者通过未经授权的数据篡改，可以更改系统或应用的配置文件，以获得控制权、插入恶意代码、甚至删除日志。例如，数据包传输过程中的注入攻击，以及由于执行了错误的代码，而导致完整数据被损坏等都属于此类威胁。对此，我们可以通过文件完整性监控(File Integrity Monitoring，FIM)，根据已创建的基线，去判断和识别关键日志、配置与存储文件是否被篡改。

• 否认(Repudiation), 主要体现在攻击者在执行了非法操作后，隐匿其行踪，以达到抵赖的效果。对此，我们可以通过审计用户的登录与执行，采取签名和哈希等手段，来增强追踪恶意活动的识别能力。

• 信息泄露(Information disclosure)，主要体现在应用或网站向未经授权的用户泄露敏感数据。例如，在有漏洞的系统进行调用，可能会遭遇缓冲区溢出攻击。同时，中间人对于传输数据的截获也属于此类威胁。值得注意的是，它与前面提到的“欺骗身份”威胁不同，攻击者是直接获取到不该泄露的信息，而不需要通过假扮或欺骗合法用户来得到。

• 拒绝服务(Denial of Service，DoS)，主要体现在攻击者迫使目标系统的资源(如：处理或存储能力等方面)不可被访问与使用、或完全无法受理正常服务请求。例如，各种 SYN 泛洪攻击、TCP 复位攻击、缓冲区溢出等都属于此类威胁。对此，我们可以通过采用安全协议，完善配置，增加检查等方式，来予以防范。

• 特权提升(Elevation of Privilege)，主要体现在攻击者在系统管理员不知情的状态下，通过普通用户获得特殊访问权，进而破坏目标系统。例如，用户代码超越缓冲区，以更高权限执行敏感操作。或是由于访问检查的缺失或不当，导致攻击者未经授权地运行了可执行文件等。

尽管 STRIDE 是目前最为流行且有效的威胁建模与安全设计框架，不过如果您觉得它有些陈旧的话，则可以参考最新的零信任网络(zero trust networks，ZTN)安全模型。它秉承的是“从不信任，始终验证”的概念，即：在任何用户、资源或资产都是不可信的前提下，通过消除隐含的信任关系，并不断验证每个阶段的交互过程，来保护目标组织和应用系统。

无论是被部署在云端，还是在本地，零信任网络作为一种持续评估和验证的关键性流程组件，可以在检测过程中，为响应团队提供有关的可疑访问请求、以及事件本身的详细信息。我们可以通过如下方面对各类网络攻击，做出及时响应，并最大限度地减少损害。

• 假设违规。由于凡事都不可信，因此我们能够从网络中已存在着攻击者的角度出发，更加专注于阻止各种违规行为。

• 完整的可见性。我们能够通过管理各种凭证、访问、操作、端点环境、以及基础设施，来监控用户请求所对应的身份、设备、应用和数据，这四种元素的详细信息。而在验证过程中，一旦发现任何异常的访问尝试，响应团队都能准确地关联到特定的实体、应用和数据上。

• 自动化响应。由于处于零信任状态，因此有待检查的节点会更多。我们往往需要实施自动化的检测与缓解手段，并通过事件关联来剔除误报，并自动更改网络访问规则，进而构建比手动响应更为有效的反应机制。

当然，没有一种完全模型能够完美到“团灭”所有的威胁、或“包治百病”。我们应当根据实际情况，选用、调整或自定义某一种、或混用各种安全模型的用例，通过缩小信任区域范围，制定出更快、更有效的响应计划。

事件严重级别✦

光有定性的识别模型显然是不够的，我们在实践中还需要有定量的指标等级，以便滤除“噪声”，界定和分析事件。

从表面上看，严重性高的事件通常需要快速的响应，但是实际情况并非一成不变。由于在事件响应的过程中，我们往往推崇的是“快速生效”。因此，对于某些低严重性事件而言，如果它们需要调用的资源较少，能够立竿见影，起到迅速遏制事件在范围与程度的效果，那么我们就可以将其视为高优先级的处置目标，予以快速修复。可见，事件的严重程度并不能完全决定了事件的优先级，我们需要从业务的角度，多方面综合考虑。

当然，最为稳妥的方法应该是：以事件对于业务的影响程度，来界定严重性级别。无论是服务级别目标(Service Level Object，SLO)也好，还是服务级别约定(Service Level Agreement，SLA)也罢，它们都直接影响着我们去确定安全事件的严重性与优先级，并且会影响到如何配置人员与资源，以及是否按需升级响应等级。在此，我以一个 APP 的页面平均加载时间为例，向您展示严重性与响应的关系：

通常，我们应当事先制定好一个包含了事件影响范围和程度的等级关系矩阵。运维人员和应急响应人员可以将收集到的指标参数，对应到事先明确定义好的取值范围中，进而通过客观且公式化结合方式(或是相乘、或是相加)，来确定其严重性。

事件管理团队✦

如前文所述，事件管理比事件响应更加“高屋建瓴”，是一整套实践流程和解决方案。它不但需要组织能够管理好安全事件的发展走势，而且可以满足所处环境中日益严苛的数据合规要求。此外，它还能够让各个利益相关方通过规范化的流程，避免同类事件的复发。

常言道：“凡事预则立，不预则废。”事件管理切忌临时抱佛脚。我们应当事先构建好一个“召之即来，来之能战”的团队。在实践中，一些组织会片面地认为安全事件处理只和那些谙熟日常运维的技术大咖有关。但其实，若要真正管理好事件，少不了安全、基础架构与运营(I&O)、以及管理层的调兵遣将与有效沟通。

事件管理指标✦

如今已是大数据时代，我们担心的不再是得不到必要的数据指标，而是向我们涌来的数据是否有用、是否能够协助我们实施事件管理。以下便是一些常见的指标类别，它们有助于随着事件响应的逐步推进，各方更好地把控安全事件的全局：

• 各类警告数量：我们可以通过衡量事件警告的不同类型、级别和数量，从宏观上直接了解当前的任务积压。

• 平均检测时间(Mean time to detect，MTTD)：我们可以用来了解监控工具的事件触发效率，以及运维人员对于事件威胁的敏感程度。

• 平均确认时间(Mean time to acknowledge，MTTA)：我们既可以用来判定对于事件分类的合理性，又能够获悉响应团队剔除误报的专业程度。

• 平均解决时间(Mean time to resolve，MTTR)：指从事件响应开始，到业务服务完全恢复所需要的平均时间。它是组织在事件管理能力方面的直接体现。

• 预算消耗比例。这反映了团队在事先制定响应计划，并申请资源配置方面的规划能力。为了避免出现“时间未半，却已花光预算”的情况，团队应当实时根据该指标，灵活地调整事件处置的策略。

事件管理工具✦

俗话说：“工欲善其事，必先利其器。”优秀的工具往往能够协助我们进行事件的跟踪、记录、处置、以及最终的绩效考评。在管理事件时，我们通常会用到如下两类工具：

• 即时通讯工具。在实践中，许多组织都会通过此类工具，方便团队实时地以协同和会诊的方式，去分析事件。各种图文并茂的交流记录，不但为事件的响应和决策过程提供了丰富的第一手资料，而且方便了响应过程的后期复盘。

• 事件管理工具。除了团队之间的人员沟通，我们也离不开事件从生成时的捕获，到原始信息的转存，以及任务的分派等自动化流转的过程。在实践中，我们常用到的此类工具包括：ServiceNow 和 OnPage 等。响应团队不但可以在 PC 端上使用它们，还能够通过智能手持设备接收到其推送的通知，并通过友好的界面，随时随地参与事件的协同处理。

事件回顾总结✦

我们常说，没有总结就没有进步。事后分析是事件管理的最后一个环节，也是不可或缺的部分。团队成员可以查阅过往的处置记录，回顾在整个响应过程中，本应该实施、却由于某种原因并未能实现或拖延执行的任务，以及由此导致的失误。据此，我们可以提高组织在如下方面的事件应对能力：

• 以“左移”的方式提高事故预防能力

• 减少或消除服务中断的停机时间

• 改善 MTTD、MTTA、以及 MTTR 等指标

• 提高相关数据的保存与使用能力

• 通过频繁广泛的内外部沟通，提供客户的知情能力

与此同时，通过撰写事后分析报告，主要利益相关方不但可以审查、并了解安全事件发生的根本原因，以及下一步相关部门与团队将如何通过整理，来防止此类事件的复发，而且能够督促响应团队不断改进事件的响应流程，优化事件的管理效果，将这些“增量”知识变为“存量”技能。

小结✦

综上所述，无论事件响应计划、威胁建模、严重性划分、团队处置能力、以及指标与工具的使用，都会是一个需要不断查缺补漏的动态更新过程。无论您是事件响应团队成员，还是事件管理的相关方，都应该练就“不怕事，不避事，善处事”的心态，不要将安全事件视为挫折，而将其看作历练的机会。