# 流程
<a name="process"></a>

 要想成功实现可扩展的事件响应计划，制定全面且明确定义的事件响应流程是关键。在发生安全事件时，明确的步骤和工作流程有助于您及时做出响应。您可能已经有事故响应流程。无论您当前的状态如何，定期更新、迭代和测试事件响应流程都很重要。

# 制定并测试事件响应计划
<a name="develop-and-test-incident-response-plan"></a>

 为事件响应制定的第一个文档是*事件响应计划*。事件响应计划旨在为您的事件响应计划和战略奠定基础。事件响应计划是一份高级文档，通常包括以下部分：
+ **事件响应团队概述**：概述事件响应团队的目标和职能 
+ **角色和职责**：列出事件响应利益相关者，并详细说明他们在发生事件时的角色 
+ **沟通计划**：详细介绍联系人信息，以及在事件发生期间如何进行沟通 

   此时的最佳实践是采用带外通信，作为事件沟通的后备。[AWS Wickr](https://aws.amazon.com/wickr/) 就是一个提供安全的带外通信渠道的应用程序示例。
+ **事件响应阶段和应采取的行动：**列举事件响应的各个阶段（例如，检测、分析、根除、遏制和恢复），包括在这些阶段中要采取的高级别操作
+ **事件严重性和优先级定义：**详细说明如何对事件的严重性进行分类，如何确定事件的优先级，然后详细说明严重性定义对上报程序有何影响

 尽管这些内容部分在各种规模和行业的公司中很常见，但每个组织的事件响应计划都是独一无二的。您将需要制定最适合贵组织的事件响应计划。

# 记录并集中管理架构图
<a name="document-and-centralize-architecture-diagrams"></a>

 为了快速准确地响应安全事件，您需要了解系统和网络的架构方式。了解这些内部架构模式不仅对事件响应至关重要，而且对于验证遵循最佳实践构建这些模式的应用程序之间的一致性也同样重要。您还应确保本文档保持最新，并根据新的架构模式定期更新。您应建立文档和内部存储库，详细说明以下项目：
+ **AWS 账户结构**：需要了解：
  +  您有多少个 AWS 账户？ 
  +  这些 AWS 账户是如何组织的？ 
  +  AWS 账户的业务负责人是谁？ 
  +  您是否使用服务控制策略（SCP）？ 如果是，通过 SCP 实施了哪些组织护栏？ 
  +  您是否限制了可使用的区域和服务？ 
  +  业务部门和环境（开发/测试/生产）之间存在哪些差异？ 
+ **AWS 服务模式** 
  +  您使用了哪些 AWS 服务？ 
  +  使用最广泛的 AWS 服务有哪些？ 
+ **架构模式** 
  +  您使用了哪些云架构？ 
+ **AWS 身份验证模式** 
  +  您的开发人员通常如何向 AWS 进行身份验证？ 
  +  您使用的是 IAM 角色还是用户（或两者兼而有之）？ 您的 AWS 身份验证是否连接到身份提供者（IdP）？ 
  +  如何将 IAM 角色或用户映射到员工或系统？ 
  +  当某人不再获得授权时，如何撤销其访问权限？ 
+ **AWS 授权模式** 
  +  您的开发人员使用了哪些 IAM 策略？ 
  +  您是否使用了基于资源的策略？ 
+ **日志记录和监控** 
  +  您使用了哪些日志源？它们存储在何处？ 
  +  您是否聚合 AWS CloudTrail 日志？ 如果是，它们存储在何处？ 
  +  如何查询 CloudTrail 日志？ 
  +  您是否启用了 Amazon GuardDuty？ 
  +  如何访问 GuardDuty 调查发现（例如控制台、工单系统、SIEM）？ 
  +  调查发现或事件是否聚合在 SIEM 中？ 
  +  是否会自动创建工单？ 
  +  进行日志调查分析时，使用了哪些工具？ 
+ **网络拓扑** 
  +  网络上的设备、端点和连接在物理上或逻辑上是如何排列的？ 
  +  您的网络如何与 AWS 连接？ 
  +  不同环境之间的网络流量是如何过滤的？ 
+ **外部基础设施** 
  +  面向外部的应用程序是如何部署的？ 
  +  哪些 AWS 资源可以公开访问？ 
  +  哪些 AWS 账户包含面向外部的基础设施？ 
  +  部署了哪些 DDoS 或外部过滤措施？ 

 记录内部技术图表和流程能够减轻事件响应分析师的工作负担，帮助他们快速获得必要的机构知识以响应安全事件。全面记录内部技术流程不仅可以简化安全调查，还可以根据流程的合理性和评估进行调整。

# 制定事件响应行动手册
<a name="develop-incident-response-playbooks"></a>

 准备事件响应流程的关键环节是制定行动手册。事件响应行动手册提供了一系列规范性指南和步骤，供发生安全事件时遵循。清晰的结构和步骤可简化响应，减少发生人为错误的可能性。

# 应针对哪些事件场景创建行动手册
<a name="what-to-create-playbooks-for"></a>

 应针对以下事件场景创建行动手册：
+  **预期事件**：应针对预期的事件创建行动手册。这包括拒绝服务（DoS）、勒索软件和凭证泄露等威胁。
+ **已知的安全调查发现或警报**：应针对已知的安全调查发现和警报（如 GuardDuty 调查发现）创建行动手册。您可能会收到一个 GuardDuty 调查发现，然后想：“现在怎么办？” 为防止错误处理 GuardDuty 调查发现或忽略调查发现，应针对每个可能的 GuardDuty 调查发现创建行动手册。有关补救细节和指导的信息可在 [GuardDuty 文档](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html)中找到。需要注意的是，默认情况下并不会启用 GuardDuty，而且需要付费。有关 Guarduty 的更多信息，请参阅附录 A：云功能定义 – [可见性和警报](visibility-and-alerting.md)。

# 行动手册应包含的内容
<a name="what-to-include-in-playbooks"></a>

 行动手册应包含安全分析师需要完成的技术步骤，以便充分调查和应对潜在的安全事件。

 行动手册中应包括的项目有：
+  **行动手册概述**：本行动手册针对哪些风险或事件场景？ 本行动手册的目标是什么？
+  **先决条件**：此事件场景需要哪些日志和检测机制？ 预期的通知是什么？ 
+ **利益相关者信息**：涉及哪些人员？其联系人信息是什么？ 每个利益相关方的责任是什么？ 
+ **响应步骤**：在事件响应的各个阶段，应采取哪些战术性措施？ 分析师应该进行哪些查询？ 应该运行什么代码才能达到预期的结果？ 
  + **检测**：如何检测事件？ 
  + **分析**：如何确定影响范围？ 
  + **遏制**：如何隔离事件来限制其影响范围？ 
  + **根除**：如何从环境中消除威胁？ 
  + **恢复**：受影响的系统或资源将如何恢复生产？ 
+ **期望结果**：运行查询和代码后，行动手册的期望结果是什么？ 

 为确保每个行动手册中的信息一致，创建一个行动手册模板供其他安全行动手册参考会很有帮助。先前列出的某些项目，例如利益相关者信息，可以在多个行动手册中共享。在这种情况下，您可以为这些信息创建集中管理的文档，并在行动手册中引用，然后在行动手册中明确列举出差异。如此一来，您无需在所有单独的行动手册中更新相同的信息。通过创建模板并识别行动手册中的通用或共享信息，您可以简化并加速行动手册的制定过程。最后，行动手册可能会随着时间推移而演变；您确认步骤一致后，这便构成了自动化的需求基础。

# 示例行动手册
<a name="sample-playbooks"></a>

 有关大量示例行动手册，请参阅附录 B 中的[行动手册资源](appendix-b-incident-response-resources.md#playbook-resources)。此处的示例可用于指导您创建哪些行动手册以及行动手册应包含哪些内容。然而，至关重要的是，所制定的行动手册应涵盖与您的业务最相关的风险。您需要确认行动手册中的步骤和工作流程是否包含相关技术和流程。

# 定期进行模拟
<a name="run-regular-simulations"></a>

 随着组织不断发展壮大，威胁形势也会不断变化，因此，必须持续评估组织的事件响应能力。模拟便是可用于执行这种评估的一种方法。模拟过程使用现实世界中的安全事件场景，旨在模仿威胁主体采取的战术、技术和程序（TTP），让组织通过响应现实中可能发生的模拟网络事件，来练习和评估自己的事件响应能力。

 模拟有多种好处，包括：
+  检验网络准备情况，有助于事件响应人员树立信心。
+  测试工具和工作流程的准确性和有效性。
+  完善沟通和上报环节，使之与您的事件响应计划相吻合。
+  提供机会来应对不太常见的攻击载体。

# 模拟类型
<a name="types-of-simulations"></a>

 模拟主要分为三种类型：
+  **桌面演练**：桌面演练模拟方法严格来说是一种基于讨论的研讨会，让各个事件响应利益相关者参与进来，练习角色和职责，以及练习使用既定的沟通工具和行动手册。通常是用一整天的时间在虚拟场地和/或实地中协调完成演练。由于桌面演练以讨论为基础的特性，因而其侧重于流程、人员和协作。在讨论中，技术是必不可少的一部分，但事件响应工具或脚本的实际使用通常不包括在桌面演练中。
+  **紫队演练**：紫队演练可提高事件响应人员（*蓝队*）和模拟威胁行为者（*红队*）之间的协作能力。蓝队通常由安全运营中心（SOC）的成员组成，但也可以包括在实际网络事件中会参与进来的其他利益相关者。红队通常由渗透测试团队或接受过攻击安全培训的关键利益相关者组成。在设计场景时，红队会与演练协调员相互协作，以确保场景的准确性与可行性。在紫队演练中，主要的关注点是支持事件响应工作的检测机制、工具和标准操作程序（SOP）。
+ **红队演练**：在红队演练中，进攻方（*红队*）模拟进行攻击，以在预定范围内实现特定目标或一系列目标。防御方（*蓝队*）不一定知道演练的范围和持续时间，如此，可以更真实地评估他们应对真实事件的能力。由于红队的演练可能是侵入性测试，因此务必谨慎行事，并实施控制措施，以确保该演练不会对环境造成实际破坏。

**注意**  
AWS 要求客户在进行紫队或红队演练之前，先查看[渗透测试网站](https://aws.amazon.com/security/penetration-testing/)上提供的渗透测试策略。

 表 1 总结了这几类模拟的一些主要差异。值得注意的是，这些定义通常视为宽泛定义，可根据组织需求进行自定义。

*表 1 – 模拟类型*


|   |  桌面演练  |  紫队演练  |  红队演练  | 
| --- | --- | --- | --- | 
|  总结 |  此类演练基于文档，专注于一个特定的安全事件场景。可以是高级别的，也可以是技术性的，并通过一系列书面预设场景推动演练进程。 |  相较于桌面演练，此类演练更贴近现实。紫队演练期间，协调员需要与参与者协作，以提升演练参与度，并在必要时提供培训。 |  此类演练通常提供更高级别的模拟形式。具有高度的隐蔽性，参与者可能并不知晓演练的所有细节。 | 
|  所需资源 |  所需技术资源较少  |  需要多方利益相关者参与，且需要高水平的技术资源  |  需要多方利益相关者参与，且需要高水平的技术资源  | 
|  复杂性 |  低  |  中  |  高  | 

 请考虑定期协调开展网络模拟。对于参与者和整个组织而言，每种演练类型都可以带来独特的好处，因此您可以选择从不太复杂的模拟类型（例如桌面演练）入手，然后再慢慢过渡到较为复杂的模拟类型（红队演练）。您应根据自身的安全成熟度、资源和期望结果选择模拟类型。由于红队演练的复杂性和成本，一些客户可能不会选择进行红队演练。

# 演练生命周期
<a name="exercise-lifecycle"></a>

 无论您选择哪种模拟类型，模拟通常都遵循以下步骤：

1.  **定义核心演练要素**：定义模拟场景和模拟要达成的目标。这两者都应该得到领导层的认同。

1. **确定关键利益相关者**：演练至少需要演练协调员和参与者。根据具体的场景，可能会涉及其他利益相关方，例如法务、通信或行政等领域的领导层。

1. **构建和测试场景**：如果有特定要素不可行，则可能需要在构建时重新定义该场景。本阶段的期望结果是最终确定的场景。

1. **协调开展模拟**：采用的模拟类型决定了所需的协调工作（书面讨论场景对比高技术含量的模拟场景）。协调员应根据演练目标调整其协调战术，并应尽可能让所有演练参与者都参与进来，以实现最大利益。

1. **撰写事后报告（AAR）**：确定哪些方面进展较为顺利、哪些方面需要改进以及可能存在的差距。AAR 应衡量模拟的有效性，并记录团队对模拟事件的响应情况，以便在将来的模拟中可以不断跟踪进度。