本文来自嘶吼网，作者/小二郎。
没有企业想在网络安全事件发生时才被动响应，因此许多企业都已经制定了安全事件响应的策略和计划，以尽量减小攻击事件造成的影响。可以说，事件响应计划已经成为每个企业网络安全实践的关键组成部分。
然而，随着网络威胁形势的不断变化，很多错误的做法都有可能会破坏响应计划的有效执行，并使企业系统暴露在更多的威胁面前。下面我们将概述企业在创建或更新事件响应计划时易犯的7个常见错误，避免这些错误可以确保企业在事件发生时做好行动准备。
创建事件响应计划时要避免的陷阱
1.未能定义文档层次结构
在开始制定新的或更新的事件响应计划时，一个常见的错误是孤立地看待该计划，而未考虑组织中存在的所有网络安全文档。
“文档层次结构”（document hierarchy）这一术语可能听起来复杂而陌生，但它可以简单地理解为“组织中的所有文档都应该具有特定的范围、目的和目标受众”，有点像相互构建的乐高积木。
文档B可以通过提供关于流程特定部分的更多细节来深化文档A中呈现的信息，而无需重复文档A中已经呈现的内容。清楚地了解单个文档如何适应整个文档层次结构有助于避免信息重复，从而只保留真正需要的文档。
简明扼要、重点明确的文档更容易被目标受众阅读和有效使用。在网络安全的背景下，推荐使用一个由以下构建块组成的文档层次结构：
事件响应计划侧重于事件处理过程，它是建立在安全策略或安全主体声明中的高级信息之上的第二级或第三级文档。与前两份文档相比，该计划的受众范围更窄，在该计划中，人们可以找到有关事件响应团队的组成和操作、事件响应过程每个阶段的行动和可用资源、升级程序和通信流程的详细信息。
事件响应计划中的信息适用于所有网络安全事件，并作为开发更程序化和基于场景的下一级文档的基础。
如果没有定义和坚持一个清晰的文档层次结构，您将面临事件响应计划过载的风险。这些信息通常建立在事件响应计划的基础上，为响应特定事件类型（如勒索软件、可疑电子邮件和异常网络流量）提供逐步指导。另一个风险是，该计划过于宽泛，借鉴了政策的内容，列出了一般的网络卫生建议和最终用户培训主题。这使得作为计划主要受众的响应者很难找到他们需要的重要信息。
2.太过笼统
事件响应计划至少应该回答有关网络安全事件的“谁、什么、何时、如何？”等问题。
进一步细分为如下信息：
·谁——哪些角色是事件响应过程的一部分，角色成员需要哪些技能或能力（涉及技术以及危机管理和协调方面），以及在不同的事件响应阶段涉及哪些其他支持角色。
·什么——在事件响应过程的每个阶段执行什么活动？请记住，事件响应计划不是剧本/操作指南，因此您不需要描述细节，例如，调查主机上的可疑可执行文件。相反地，该计划应该描述一般的分类过程，组织内可用的数据源，以及一旦事件缩小范围后可以遵循的可能的操作指南。
·何时——时间在事件中是宝贵的，所以最好有一个预先确定的行动顺序，以便在事件发生时执行。例如，基于事件的优先级分类（这也是计划中应该包含的内容），可能会启动一个升级流程。周末发生的重要事件是否需要立即打电话给经理？在正常工作时间以外是否有这样的升级点？每个操作还应该有一个角色所有者标识。
·如何——事件响应计划应包含有关在事件期间通常用于技术响应（包括数据捕获、检测能力和分析工具）和事件通信（例如，如果怀疑网络被破坏，可以使用哪些替代基础设施）的工具的高级信息。然而，计划应该只提供工具功能的概述，团队可以使用的工具箱，而不是使用它们的过程细节。后者应该被添加到组织的操作指南中。
3.过于具体
事件响应计划不是剧本，计划中的信息是基础，不需要在其他剧本中重复。例如，确保计划不包括仅适用于一种攻击类型（如勒索软件或分布式拒绝服务）的过程性信息，因为这会削弱文档的范围。
4.孤立编辑
平心而论，很少有技术人员真正热衷于编写过程文档，这使得更重要的是要确保无论谁负责事件响应计划都要得到更广泛团队的支持。
创建有意义的事件响应计划最成功的方法之一是让公司的利益相关者参与进来，比如主要的业务应用程序所有者，这样他们就可以理解并确保他们的需求和期望被计划满足。
最初的计划草案应由至少两名具有流程知识并负责事件响应流程实施的团队成员审查。然后，下一个级别的审查应该由核心事件响应团队之外的团队（例如网络和存储管理，它们在恢复过程中起着关键作用）完成。最后，支持非技术团队（如法律、通信和人力资源）提供最终草案的审查。后者的投入与技术投入一样有价值，因为一些法规（如NIS2）将要求在24小时内通知事件。例如，如果发生在周五下午、周日之前的事件需要报告，法律团队需要确认是否有人（以及谁）在周末可以联系执法部门。
5.没有测试事件响应计划
事件响应计划通常包含几个子过程描述，例如升级过程、分类过程、替代通信通道激活过程等。计划只有在实际事件中使用时才能发挥作用，识别这些子过程中任何缺陷的最佳方法是对它们进行测试。
如何测试事件响应计划？首先，将其分解为作为整个事件处理一部分的关键流程。然后，根据它们对整体响应的重要性和测试的难易程度对这些过程进行排序。从最上面的子流程开始，然后往下进行。
例如，以恢复操作为例，“事件负责人联系备份管理团队以获取备份的状态。”以下是一些您可能需要检查的问题：
·事件指挥官如何联系后备管理团队？如果公司的通信工具宕机或被入侵，该通信渠道是否离线可用？
·备份管理团队在这个时候可用吗？如果事故发生在周末或公众假期，该怎么办？
·备份管理团队将在哪里找到备份的最新测试日期？备份管理团队在验证备份完整性的过程中·是否有可遵循的程序？创建这样一个概述的速度有多快？
·如果备份已被隔离，是否可以检查其完整性？
·在怀疑存在泄露的情况下，备份管理团队是否拥有访问备份的所有帐户的列表？
·事件指挥官如何跟踪事件期间发送给他们的所有信息，并将其提供给更大的团队？
为了测试这种情况下涉及的工具、人员和流程，建议每年至少进行一次桌面练习。桌面测试是通过为您的组织定制的场景进行演练，并不会对环境产生实际影响，以查看负责团队将如何响应。如果操作得当，桌面演练可以使团队以新的视角看待他们的事件响应计划，发现包含最新信息的良好文档的力量以及需要改进的地方。
6.计划陈旧
事件响应计划应至少每年更新和改进一次，此外，当所处环境中有主要的软件或硬件更改时也应更新，组织法律结构的变化（如兼并和收购）还需要进行审查。在任何重大事件结束后，也建议审查事件响应计划并根据事件进行调整。定期审查还有助于确保在人员变动的情况下——例如，成员在团队或组织外部轮换，或者IT环境变化——计划仍然有效。
7.过于关注IT
应与其他非技术团队（如法律、合规、人力资源部门等）协商制定事件响应计划。需要与这些团队密切合作的具体原因包括，员工的个人数据受到影响，需要根据法规要求向当局通报事件，或者需要就重大事件发布公开声明。
另一个经常被忽视但应该成为事件响应计划开发一部分的团队是服务台团队。代理是否能够正确地处理网络安全事件，并迅速将其升级到事件响应团队？他们是否受过训练，即使受影响的用户较少，也能识别出勒索软件、擦拭器和社交工程等常见攻击的高可信度迹象？
如果过于关注处理事件的技术方面，就有可能创建不完整的文档，支持团队应该是开发过程、最终文档的分发列表以及测试和培训练习的一部分。
