CIS Control 17. 事件响应管理

Center for Internet Security (CIS) 提供 Critical Security Controls（CSCs），帮助组织提升网络安全。CIS CSC 17 涵盖 事件响应与管理。 （在早期版本的 CIS 控制 中，对安全事件的处置包含在 Control 19 中。）

CIS CSC 17 重点关注如何制定应对攻击及其他安全事件的计划，包括为负责各项相关任务的人员明确角色的重要性。

这些建议有助于提升应对能力。不过，企业也可以使用 Council of Registered Security Testers (CREST) Cybersecurity Incident Response Guide，以制定更完善的安全计划并开展事件响应。

在深入了解事件响应和管理控制的保障措施之前，首先必须理解什么情况可能符合“事件”的定义。

安全事件与安全事故：有什么区别？

在信息安全的语境中，安全事件和安全事故是两回事。安全事故通常源于未能及时处理的安全事件。举例来说，对访问控制配置做出不当变更（例如 GPO 或安全组）属于安全事件。当黑客利用该配置变更从信息系统中窃取数据时，这就构成安全事故。事故的发生频率远低于事件，但危害可能大得多。简而言之，事故就是带来有害后果的事件。

为实现有效的事件响应管理，应由指定团队为所有已知安全事件制定一份详细的响应计划，其中应包括指定人员和恢复能力。完善的计划有助于解决诸如数据完整性等安全问题，并确保符合数据保护要求以及其他法规。

以下是 CIS 事件响应控制（incident response control）的九项保障措施：

17.1 指定人员以管理事件处理

该保障措施建议指定一名主要联系人和一名备份联系人，以管理事件处理流程，包括协调并记录事件响应与恢复工作。该指定应每年以及在任何重大变更影响安全时进行审查。

关键联系人可以是公司内部员工，也可以是第三方供应商。两种做法各有利弊。由员工担任关键负责人可确保响应管理保持在组织内部进行，但根据组织规模不同，这项工作可能会对单个员工来说负担过重。专门从事安全管理的第三方可能更能妥善处理安全事件。如果指定第三方负责风险评估和事件响应，该保障措施建议在组织内部至少安排一名人员以提供监督。

17.2. 建立并维护用于报告安全事件的联系信息

为所有应接收安全事件相关信息的各方维护准确的联系信息非常重要。这些各方的联系方式应当易于获取，并能快速访问。该列表可根据优先级进行排序。

该列表通常包括负责事件响应管理的人员，以及有权做出重大决策的人员。事件响应团队还可能需要通知执法机构、合作供应商、网络保险提供商或公众。

应建立机制，以便在事件发生后及时联系并通知相关各方。自动化事件通知流程也有助益。

应至少每年更新一次联系信息，或更频繁地更新，以确保通知能够传达给所有相关各方。

17.3. 建立并维护用于报告事件的企业流程

上一项保障措施关注 谁 应当被告知有关事件的信息。本项保障措施解决的是 如何 应报告事件，包括报告时限、报告机制以及需要上报的信息（例如事件类型、时间、威胁等级、受影响的系统或软件、审计日志等）。

拥有文档化的报告工作流程，可以让任何在获悉事件情况后的人更容易以及时且有效的方式告知相关人员。该流程应对全体员工开放，并且在每年以及任何可能影响安全的重大变更发生时进行审查。

17.4. 建立并维护事件响应流程

该保障措施要求通过定义角色与职责、沟通与安全计划以及合规要求，制定事件响应的路线图。若没有指定的任务和清晰的指令，相关方可能会误以为其他人正在处理某项特定任务，而实际上没有人负责。

响应流程应大体概述各个步骤，包括监控并识别与该事件相关的网络威胁、为处理该事件定义目标，以及采取行动以防止损害或恢复资产。 许多事件响应团队使用 jump kits 这些工具包中包含调查与响应事件所需的资源，例如计算机、备份设备、摄像机、便携式打印机，以及诸如协议分析器之类的数字取证软件。

通常，第一步是查明事件的性质，以便能够实施相应的响应程序。只要明确目标在前，团队就可以努力减缓威胁的扩散。随后，他们再根据已记录的行动计划采取合适的步骤来处理该事件，并扭转任何损害。

当安全性可能受到重大变更影响时，以及每年一次，都应对该流程进行复核。

17.5. 指定关键角色与职责

如前述保护措施所说明，事件响应人员必须了解自己在响应程序中的角色。根据适用情况，向不同个人或团队分配关键角色与职责。这可能包括安全团队（事件响应人员）、系统管理员、法务人员、公关（PR）与人力资源（HR）团队成员，以及分析人员。当然，在发生网络安全事件时，安全与 IT 团队将承担大部分职责。然而，法务或人力资源等部门的其他关键人员也应当了解各自的职能。

应每年以及在发生重大变更时，审查并更新角色及其相应职责的清单。

17.6. 定义事故响应期间的沟通机制

在进行事故报告与评估时，沟通至关重要。其他保护措施概述了 要 传达什么以及 向谁 传达，而本项保护措施则概述了 如何 进行沟通。应当预先定义沟通渠道，例如电子邮件或电话。

还应当制定应急计划。例如，严重事件可能会导致无法使用电子邮件进行沟通。因此，应当存在另一种沟通机制，用于告知相关方并就事故响应进展提供更新。

17.7. 定期开展事故响应演练

同样重要的是，通过针对关键人员开展例行的事件响应演练和情景推演，做好应对真实世界事件的准备。这些演练将测试并审计事件响应计划与流程的不同方面，例如沟通渠道、工作流程以及调查等。例如，练习响应会中断组织中关键信息流通的网络事件。请至少每年开展一次这些演练。

团队可以使用 NIST Technical Guide to Security Testing and Assessment 来制定演练方案。

17.8. 开展事后复盘

每次事件发生后，组织都需要同时调查事件本身以及自身的响应过程。他们应指定负责开展此类分析并编写事后报告的人员，以识别需要采取的后续行动和所犯的错误。

事后报告应回答诸如以下问题：

• 究竟发生了什么？
• 是什么导致的？
• 相关人员如何进行响应？
• 响应花了多长时间？
• 响应流程是否足够妥当？
• 本可以做得更好的地方是什么？
• 事故报告中的信息是否足够？
• 哪些方面可以采取不同的做法？
• 可以采取哪些措施来防止未来发生类似事件？

17.9. 建立并维护安全事件阈值

这一保障措施帮助组织区分安全事件和安全事件（security events）。通过定义不同的事故及其影响，组织可以确保资源优先投入到关键事故，而不仅仅是处理一些轻微的异常事件。此外，它还有助于为事故建立优先级体系，使响应人员明确何时需要采取行动以及应如何开展响应。

识别和分类事故可以在今后对响应程序进行标准化。组织应更新其阈值（判定标准），以纳入那些符合事故条件的新型内部和外部威胁。

摘要

CIS CSC 17 的九项保障措施帮助组织实施健全的事件响应管理，包括角色分配、联系人管理、情景演练，以及事件分析与文档编制。