2.1 事件响应流程概述

有许多行业标准、建议和最佳实践都有助于你创建自己的事件响应流程。不过，你仍然可以将本书内容作为参考，以确保涵盖了与你的业务类型相关的所有阶段。本书参考的是计算机安全事件响应（Computer Security Incident Response，CSIR），见NIST的出版物800-61R2。无论你选择哪一个作为参考，都要确保使其适应你自己的业务需求。在安全领域，大多数时候“一刀切”的概念并不适用，其目的总是利用众所周知的标准和最佳实践，并将它们应用到你自己的环境中去。保持灵活性以适应业务需求非常重要，以便在操作时提供更好的体验。

虽然灵活性是调整事件响应以适应个人需求和要求的关键，但了解不同响应之间的共性仍然是非常宝贵的。实施IR流程有多种原因，并且某些步骤将有助于创建事件响应流程和组建有效的事件响应团队。此外，每个事件都有一个事件生命周期，通过检查可以更好地了解事件发生的原因，以及如何防止将来出现类似问题。我们将更深入地讨论其中的每一项，让你更深入地了解如何形成自己的事件响应流程。

2.1.1 实施IR流程的理由

在深入学习流程本身的更多细节之前，了解使用的术语以及将IR用作增强安全态势一部分时的最终目标是什么是很重要的。让我们用一个虚构的公司来说明为什么这很重要。

图2.1所示为一个事件的时间表，用来引导服务台升级问题并启动事件响应流程。

表2.1列出了此场景中每个步骤的一些注意事项。

虽然前面的场景有很大的改进空间，但这家虚构的公司存在着世界上许多其他公司都没有的东西：事件响应本身。如果没有适当的事件响应流程，专业人员会将精力集中在与基础设施相关的问题上，从而耗尽他们排除故障的精力。安全态势较好的公司，都会有相应的事件响应流程。这类公司还将确保遵守以下准则：

●所有IT人员都应接受培训，了解如何处理安全事件。

●应对所有用户进行培训，使其了解有关安全的核心基础知识，以便更安全地开展工作，这将有助于避免感染。

●服务台系统和事件响应团队之间应该集成，以便共享数据。

上述场景可能会有一些变化，从而带来不同的挑战需要克服。一种变化是在步骤6中没有发现攻陷指示器（Indicator of Compromise，IoC）。在这种情况下，服务台可以轻松地继续进行故障排除。如果在某个时候又正常了呢？这有可能吗？当然有！当找不到IoC时，并不意味着环境是干净的，现在你需要改变策略，开始寻找攻击指示器（Indicator of Attack，IoA），这需要寻找能够表明攻击者意图的证据。在调查时，你可能会发现许多IoA，这可能不会引出IoC。关键是了解IoA将使你更好地了解攻击是如何执行的，以及如何对其进行防范。

当攻击者渗透到网络中时，他们通常希望保持隐形，从一台主机横向移动到另一台主机，危害多个系统，并试图通过攻陷具有管理权限的账户来提升权限。这就是为什么不仅要在网络中有好的传感器，而且主机本身也要有。有了好的传感器，你不仅可以快速检测到攻击，还可以识别可能导致迫在眉睫的违规威胁的潜在场景。

除了刚才提到的所有因素外，有些公司很快就会意识到必须有一个事件响应流程，以符合所处行业的相关规定。例如，2002年的联邦信息安全管理法案（Federal Information Security Management Act，FISMA）要求联邦机构制定检测、报告和响应安全事件的程序。

2.1.2 创建IR流程

虽然事件响应流程（见图2.2）会根据公司及其需求的不同而有所不同，但在不同的行业中，事件响应流程的一些基本方面并无差异。

创建事件响应流程的第一步是建立目标，换句话说，回答问题：流程的目的是什么？虽然这看起来可能是多余的，因为它的名称已经将意思表示得很明显了，但重要的是，你必须非常清楚流程的目的，以便每个人都知道该流程试图实现的目标。

一旦定义了目标，就需要处理范围问题。同样，你可以从回答一个问题开始，在本例中是：这一流程适用于谁？

虽然事件响应流程通常在公司范围内有效，但在某些情况下也可以局限于部门范围。因此，你是否将其定义为公司范围的流程，这一点很重要。

每家公司对安全事件可能有不同的看法，因此，你必须对安全事件的构成有一个定义，并提供示例以供参考。

除定义之外，公司还必须创建自己的词汇表，其中包含所用术语的定义。不同的行业会有不同的术语集，如果这些术语与安全事件相关，则必须将其记录在案。

在事件响应流程中，角色和职责至关重要。如果没有适当级别的授权，整个流程都会面临风险。当你考虑以下问题时，事件响应中权威等级的重要性就显而易见了：谁有权没收一台计算机以进行进一步调查？通过定义具有此权威等级的用户或组，你可以确保整个公司都知道这一点，并且如果发生事件，相关人员不会质疑执行策略的调查组。

另一个需要回答的重要问题与事件的严重性有关。什么可以用于定义危急事件？危急程度决定了资源分配，这带来了另一个问题：当事件发生时，你们将如何分配人力资源？你应该将更多资源分配给事件A还是事件B？为什么？这些只是一些应该回答的问题示例，以便定义优先级和严重程度。要确定优先级和严重程度，你还需要考虑业务的以下方面：

●事件对业务的功能影响：受影响的系统对业务的重要性将直接影响事件的优先级。受影响的系统的所有利益相关者都应该意识到这一问题，并在确定优先事项时发表自己的意见。

●受事件影响的信息类型：每次处理个人身份信息（Personally Identifiable Information，PII）时，你的事件将具有高优先级。因此，这是事件发生时首先要核实的因素之一。另一个可能影响严重性的因素是根据你公司使用的合规标准而泄露的数据类型。例如，如果你的公司需要符合HIPAA标准，那么如果泄露的数据受HIPAA标准管理，就需要提高严重性级别。

●可恢复性：在初步评估之后，可以估计需要多长时间才能从事件中恢复过来。根据恢复时间的长短，再加上系统的危急程度，可能会将事件的优先级提升到很高。

除了这些基本领域之外，事件响应流程还需要定义如何与第三方、合作伙伴和客户进行交互。

例如，如果发生事件，并且在调查过程中发现某个客户的PII被泄露，公司将如何向媒体传达此事？在事件响应流程中，与媒体的沟通应与公司的数据泄露安全策略保持一致。在新闻稿发布之前，法律部门也应该参与进来，以确保声明不引发法律问题。在事件响应流程中，参与执法的程序也必须一并记录。在记录这一点时，请考虑物理位置——事件发生的位置、服务器所在的位置（如果合适），以及状态。通过收集这些信息，将更容易确定管辖权和避免冲突。

2.1.3 IR小组

现在已经覆盖了基本领域，还需要组建事件响应小组。小组的形式将根据公司规模、预算和目的而有所不同。大型公司可能希望使用分布式模型，其中有多个事件响应小组，每个小组都有特定的属性和职责。此模型对地理位置分散、计算资源分布在多个区域的组织非常有用。其他公司可能希望将整个事件响应小组集中在单个实体中，负责处理任何位置的事件。在选择了使用的模式后，公司可以着手招募员工加入小组。

事件响应流程需要具有广泛技术知识的人员，同时还需要具有其他一些领域的深厚的知识。挑战在于如何在这个领域找到有深度和广度的人，这有时会使你需要雇佣外部人员来填补一些职位，甚至将事件响应小组的部分工作外包给不同的公司。

事件响应小组的预算还必须包括通过教育进行持续改进，以及购买适当的工具、软件和硬件。随着新的威胁出现，负责事件响应的安全专业人员必须做好准备，并要接受良好的应对培训。许多公司未能及时更新员工队伍，这可能会使公司面临风险。当将事件响应流程外包时，要确保你所雇佣的公司负责不断地对员工进行这方面的培训。

如果计划将事件响应运营外包，请确保你拥有定义明确的服务等级协议（Service-Level Agreement，SLA），该协议满足之前建立的严重性等级。在此阶段，你还应该定义小组的覆盖范围，假设需要24小时运行。

在此阶段，你将定义：

●班次：要实现24小时覆盖，需要多少班次？

●小组分配：根据这些班次，要怎样安排每个班次的值班人员，包括全职员工和承包商吗？

●随叫随到流程：建议轮流安排技术人员和管理人员值班，随叫随到，以防问题需要升级。

在这个阶段定义这些方面是特别有用的，因为它能让你更清楚地看到团队需要涵盖的工作，从而相应地分配时间和资源。

2.1.4 事件生命周期

每个事件都必须有始有终，在开始和结束之间发生的事情分属不同阶段，将决定响应过程的结果。这是一个持续的过程，我们将其称为事件生命周期。到目前为止，我们所描述的可以看作准备阶段。但是，这个阶段的范围更广——它还包括基于初始风险评估创建的安全控制的部分实施（这应该在创建事件响应流程之前就已经完成了）。

准备阶段还包括实施其他安全控制措施，例如：

●端点保护

●恶意软件防护

●网络安全

准备阶段不是一成不变的，你可以在图2.3中看到，该阶段将接收来自事后活动的输入。事后活动对于提高未来攻击的准备水平至关重要，因为在这里你将执行事后分析，以了解根本原因，并了解如何改进防御以避免将来遭受相同类型的攻击。图2.3还显示了生命周期的其他阶段及其相互作用方式。

检测和遏制阶段在同一事件中可以有多个交互。循环结束后，将进入事后活动阶段。以下各节将更详细地介绍后三个阶段。