# 事件响应 事件响应 **Topics** + [ # SEC 10. 如何预测、响应意外事件以及从意外事件中恢复？ ](sec-10.md) # SEC 10. 如何预测、响应意外事件以及从意外事件中恢复？ 即使采用成熟的预防和检测性控制措施，您的组织也应实施机制来响应安全事件并缓解安全事件可能带来的影响。您的准备工作会极大地影响团队在意外事件发生期间采取有效行动、对问题进行隔离、遏制和取证并将运行状态恢复到已知良好状态的能力。在安全事件发生之前确保相关工具和访问权限部署到位，然后通过 GameDay 活动定期进行事件响应演练，这样有助于确保您有能力恢复并最大限度避免业务中断。 **Topics** + [ # SEC10-BP01 确定关键人员和外部资源 ](sec_incident_response_identify_personnel.md) + [ # SEC10-BP02 制定事件管理计划 ](sec_incident_response_develop_management_plans.md) + [ # SEC10-BP03 准备取证能力 ](sec_incident_response_prepare_forensic.md) + [ # SEC10-BP04 制定和测试安全事件响应行动手册 ](sec_incident_response_playbooks.md) + [ # SEC10-BP05 预置访问权限 ](sec_incident_response_pre_provision_access.md) + [ # SEC10-BP06 预部署工具 ](sec_incident_response_pre_deploy_tools.md) + [ # SEC10-BP07 运行模拟 ](sec_incident_response_run_game_days.md) + [ # SEC10-BP08 建立从事件中吸取经验教训的框架 ](sec_incident_response_establish_incident_framework.md) # SEC10-BP01 确定关键人员和外部资源 SEC10-BP01 确定关键人员和外部资源 确定内部和外部人员、资源和法律义务，来协助组织应对事件。 **期望结果：**您有一份关键人员名单、他们的联系信息以及他们在应对安全事件时扮演的角色。您可以定期审查这些信息并进行更新，以便分别从内部工具和外部工具的角度反映人事变动。在记录这些信息时，您需要考虑所有第三方服务提供商和供应商，包括安全合作伙伴、云提供商和软件即服务（SaaS，Software-as-a-Service）应用程序。在安全事件发生期间，有适当级别的责任、背景和访问权限的人员能够做出响应和恢复动作。  **常见反模式：** + 在应对安全事件时，没有维护一份包含关键人员联系信息、角色和职责的最新关键人员名单。 + 在应对事件和从事件中恢复时，假设每个人都了解人员、依赖项、基础设施和解决方案。  + 没有代表关键基础设施或应用程序设计的文档或知识库。 + 没有为新员工制定适当的入职流程，无法有效参与安全事件响应，例如进行事件模拟。 + 没有制定当关键人员暂时无法到岗或者在安全事件中无法做出反应时，所需要的上报途径。 **建立此最佳实践的好处：**这种实践减少了事件发生期间用于确定合适人员及其角色的分流和响应时间。通过维护一份关键人员及其角色的最新名单，极大限度地减少事件发生期间的时间浪费，这样您就能够让合适的人员进行分流并从事件中恢复过来。 **在未建立这种最佳实践的情况下暴露的风险等级：**高 ## 实施指导 实施指导 **确定组织中的关键人员：**维护一份贵组织内需要参与事件的人员的联系名单。在发生组织变革、晋升和团队变动等人事变动时，应定期审查和更新这些信息。这对于事件经理、事件响应者和沟通负责人等关键角色尤其重要。  + **事件经理：**事件经理在事件响应期间拥有全面权力。 + **事件响应者：**事件响应者负责调查和修复活动。这些人员可能因事件类型而异，但通常是负责受影响的应用程序的开发人员和运营团队。 + **沟通负责人：**沟通负责人负责内外部沟通，特别是与公共机构、监管机构和客户的沟通。 + **入职流程：**定期对新员工进行培训和入职，使他们具备必要的技能和知识，以便有效地为事件响应工作做出贡献。将模拟和动手练习作为入职流程的一部分，以协助他们做好准备。 + **主题专家（SME）：**对于分布式自主团队，我们建议您为任务关键型工作负载确定一名 SME。主题专家有助于我们深入了解事件中涉及的关键工作负载的运行和数据分类。 示例表格式： ```   | Role | Name | Contact Information | Responsibilities | 1 | ——– | ——- | ——- | ——- | 2 | Incident Manager | Jane Doe| jane.doe@example.com | Overall authority during response | 3 | Incident Responder | John Smith | john.smith@example.com | Investigation and remediation | 4 | Communications Lead | Emily Johnson | emily.johnson@example.com | Internal and external communications | 5 | Communications Lead | Michael Brown | michael.brown@example.com | Insights on critical workloads | ``` 考虑使用 [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) 功能，来捕获关键联系人、制定响应计划、自动执行随时待命方案并制定上报计划。通过随时待命方案自动安排和轮换所有员工，使工作负载的责任由其所有者分担。这促进了良好的实践，例如发布相关指标和日志，以及定义与工作负载相关的警报阈值。 **确定外部合作伙伴：**企业运用独立软件供应商（ISV）、合作伙伴和分包商开发的工具，为客户构建差异化解决方案。让各方的这些关键人员参与进来，他们有助于应对事件并从事件中恢复。我们建议您注册相应级别的 支持，以便通过支持案例及时联系 AWS 主题专家。考虑与所有关键解决方案提供商就工作负载达成类似安排。有些安全事件要求上市企业向相关公共机构和监管机构通报事件及影响。请维护和更新相关部门和负责人的联系信息。 ## 实施步骤 实施步骤 1. 设置事件管理解决方案。 1. 考虑在您的安全工具账户中部署 Incident Manager。 1. 在事件管理解决方案中定义联系人。 1. 为每位联系人至少定义两种联系渠道（例如短信、电话或电子邮件），以便确保事件发生期间能够联系上。 1. 制定响应计划。 1. 确定事件发生时应接洽的最合适的联系人。根据参与人员的角色，而不是单个联系人，制定上报计划。考虑纳入可能负责通知外部实体的联系人，即使他们没有直接参与解决事件也是如此。   ## 资源 资源 **相关最佳实践：** + [OPS02-BP03 确定对运营活动绩效负责的责任人](https://docs.aws.amazon.com/wellarchitected/latest/framework/ops_ops_model_def_activity_owners.html) **相关文档：** + [AWS《Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)》 **相关示例：** + [AWS 客户行动手册框架](https://github.com/aws-samples/aws-customer-playbook-framework) + [准备和响应 AWS 环境中的安全事件](https://youtu.be/8uiO0Z5meCs) **相关工具：** + [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) **相关视频：** + [Amazon's approach to security during development](https:/www.youtube.com/watch?v=NeR7FhHqDGQ) # SEC10-BP02 制定事件管理计划 SEC10-BP02 制定事件管理计划 为事件响应制定的第一个文档是事件响应计划。事件响应计划旨在为您的事件响应计划和战略奠定基础。 **建立此最佳实践的好处：**要想成功实现可扩展的事件响应计划，制定全面且明确定义的事件响应流程是关键。在发生安全事件时，明确的步骤和工作流有助于您及时做出响应。您可能已经有事故响应流程。无论您当前的状态如何，定期更新、迭代和测试事件响应流程都很重要。 **在未建立这种最佳实践的情况下暴露的风险等级：**高 ## 实施指导 实施指导 对于响应、缓解安全事件的潜在影响并从中恢复来说，事件管理计划是至关重要的。事件管理计划是一个结构化的过程，用于及时地确定、补救和响应安全事件。 云的许多操作角色和要求都与本地环境中的相同。在创建事件管理计划时，应考虑最符合业务成果和合规性要求的响应和恢复策略，这一点非常重要。例如，如果您在 AWS 中运行符合美国 FedRAMP 标准的工作负载，请遵守 [NIST SP 800-61 Computer Security Handling Guide](https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-61r2.pdf) 中的建议。同样，在运行存储个人身份信息（PII）的工作负载时，请考虑如何防止和应对与数据驻留和使用相关的问题。 在为 AWS 中的工作负载制定事件管理计划时，请首先使用 [AWS 责任共担模式](https://aws.amazon.com/compliance/shared-responsibility-model/)，以便构建针对事件响应的深度防御方法。在此模式中，AWS 负责管理云本身的安全，云内部的安全则由您负责。这意味着您将保留控制权，并对选择实施的安全控制机制负责。《[AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)》详细介绍了构建以云为中心的事件管理计划的关键概念和基本指南。 必须不断地迭代有效的事件管理计划，使其与您的云运营目标保持一致。在创建和改进事件管理计划时，请考虑使用下面详述的实施计划。 ### 实施步骤 实现步骤 1. 定义组织内部用于处理安全事件的角色和职责。这应涉及不同部门的代表，包括： + 人力资源（HR） + 执行团队 + 法务部门 + 应用程序所有者和开发人员（主题专家或 SME） 1. 明确概述在事件发生期间谁负责、对谁问责、咨询谁以及通知谁（RACI）。创建 RACI 图表来促进快速和直接的沟通，并清楚地概述事件不同阶段的领导关系。 1. 在事件发生期间，让应用程序所有者和开发人员（SME）参与进来，因为他们可以提供有价值的信息和背景信息来帮助衡量影响。与这些 SME 建立关系，并在实际事件发生之前与他们练习事件响应场景。 1. 让值得信赖的合作伙伴或外部专家参与调查或响应过程，因为他们可以提供额外的专业知识和视角。 1. 使您的事件管理计划和角色与管理您组织的任何当地法规或合规要求保持一致。 1. 定期练习和测试您的事件响应计划，并涉及所有已定义的角色和职责。这有助于简化流程，并验证您对安全事件的响应井井有条且高效。 1. 定期审核和更新角色、职责和 RACI 图表，或者在组织结构或要求发生变化时进行审核和更新。 **了解 AWS 响应团队和支持** + **AWS 支持** + [支持](https://aws.amazon.com/premiumsupport/) 包含一系列计划，这些计划旨在让您能够运用各种工具和专业知识来为成功部署和正常实施 AWS 解决方案提供支持。如果您需要技术支持及更多资源来规划、部署和优化 AWS 环境，则可以选择最符合 AWS 使用案例的支持计划。 + 考虑将[支持中心](https://console.aws.amazon.com/support)（在 AWS 管理控制台 中，需要登录）作为中心联系点，为影响您 AWS 资源的问题获取支持。对 支持 的访问由 AWS Identity and Access Management 控制。有关获取对 支持 功能的访问权限的更多信息，请参阅《[Getting started with 支持](https://docs.aws.amazon.com/awssupport/latest/user/getting-started.html#accessing-support)》。 + **AWS 客户事件响应团队（CIRT）** + AWS 客户事件响应团队（CIRT）是一支专业的 AWS 全球团队，全天候向客户提供支持，协助客户解决根据 [AWS 责任共担模式](https://aws.amazon.com/compliance/shared-responsibility-model/)应由客户一方负责的安全事件。 + 当 AWS CIRT 为您提供支持时，他们会为 AWS 上出现的安全事件提供分类和恢复方面的协助。他们可以使用 AWS 服务日志来协助分析根本原因，并为您提供恢复建议。他们还可以提供安全建议和最佳实践，从而让您以后能够避免出现安全事件。 + AWS 客户要与 AWS CIRT 交流，可以开立 [支持 案例](https://docs.aws.amazon.com/awssupport/latest/user/case-management.html)。 + [https://aws.amazon.com/security-incident-response/](https://aws.amazon.com/security-incident-response/) + 在 re:Invent 2024 上发布的 AWS 安全事件响应是一项托管式安全事件响应服务，它既使用现代分诊技术，又使用人工干预。该服务接收所有 GuardDuty 调查发现和发送给 AWS Security Hub CSPM 进行分诊的任何第三方调查发现，以仅针对需要调查的调查发现时向客户发出提醒。该服务还提供了一个门户，用于针对客户注意到的安全事件提交被动案例，并获得 AWS 的高级事件响应团队的支持。 + **DDoS 响应支持** + AWS 提供 [AWS Shield](https://aws.amazon.com/shield/)，它提供了托管的分布式拒绝服务（DDoS）攻击保护服务，可保护在 AWS 上运行的 Web 应用程序。Shield 提供不间断检测和自动化内嵌缓解措施，可以最大限度地减少应用程序停机时间和延迟，因此无需与 支持 交流即可从 DDoS 保护中受益。Shield 分为两个级别：AWS Shield Standard 和 AWS Shield Advanced。要了解这两个级别之间的区别，请参阅《[Shield 功能文档](https://aws.amazon.com/shield/features/)》。 + **AWS Managed Services（AMS）** + [AWS Managed Services（AMS）](https://aws.amazon.com/managed-services/)可持续管理您的 AWS 基础设施，让您可以专注于应用程序。AMS 实施最佳实践来维护您的基础设施，让您能够降低运营开销和风险。AMS 可以自动执行常见活动 (例如更改请求、监控、补丁管理、安全性和备份服务)，并可以提供全生命周期服务来预置、运行和支持您的基础设施。 + AMS 负责部署一套安全检测控制措施，并全天候提供对警报的第一线响应。启动警报后，AMS 遵循一组标准的自动和手动行动手册，验证是否有一致的响应。这些行动手册在功能部署期间与 AMS 客户共享，这样客户就能够开发并与 AMS 协调响应措施。 **制定事件响应计划** 事件响应计划旨在为您的事件响应计划和战略奠定基础。事件响应计划应包含在正式文档中。事件响应计划通常包括以下部分： + **事件响应团队概述：**概述事件响应团队的目标和职能。 + **角色和职责：**列出事件响应利益相关者，并详细说明他们在发生事件时的角色。 + **沟通计划：**详细介绍联系信息，以及在事件发生期间如何进行沟通。 + **后备沟通方法：**此时的最佳实践是采用带外通信，作为事件沟通的后备。AWS Wickr 就是一个提供安全的带外通信渠道的应用程序示例。 + **事件响应阶段和应采取的行动：**列举事件响应的各个阶段（例如，检测、分析、消除、遏制和恢复），包括在这些阶段中要采取的高级别操作。 + **事件严重性和优先级定义：**详细说明如何对事件的严重性进行分类，如何确定事件的优先级，然后详细说明严重性定义对上报程序有何影响。 尽管这些内容部分在各种规模和行业的公司中很常见，但每个组织的事件响应计划都是独一无二的。您需要制定最适合贵组织的事件响应计划。 ## 资源 资源 **相关最佳实践：** + [SEC04 检测](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/detection.html) **相关文档：** + 《[AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)》 + [ NIST：计算机安全事件处理指南 ](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf) # SEC10-BP03 准备取证能力 SEC10-BP03 准备取证能力 在发生安全事件之前，可以考虑构建取证能力来支持安全事件调查工作。 **在未建立这种最佳实践的情况下暴露的风险等级：**中 传统本地取证的概念适用于 AWS。有关开始在 AWS Cloud 中构建取证功能的关键信息，请参阅《[Forensic investigation environment strategies in the AWS Cloud](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/)》。 设置好取证的环境和 AWS 账户 结构后，确定在以下四个阶段有效执行可靠取证方法所需的技术： + **收集：**收集相关的 AWS 日志，例如 AWS CloudTrail、AWS Config、VPC 流日志和主机级日志。收集受影响的 AWS 资源的快照、备份和内存转储（如果有）。 + **检查：**通过提取和评测相关信息来检查收集到的数据。 + **分析：**分析收集到的数据，以便了解事件并从中得出结论。 + **报告：**提供分析阶段得出的信息。 ## 实施步骤 实施步骤 **准备取证环境** [AWS Organizations](https://aws.amazon.com/organizations/) 有助于您随着 AWS 资源的增长和扩展，集中管理和监管 AWS 环境。AWS 组织会整合您的 AWS 账户，这样您就能够将这些账户作为一个单元进行管理。您可以使用组织单元 (OU)，将账户分组到一起，作为一个单元管理。 对于事件响应，拥有一个支持事件响应功能的 AWS 账户 结构（包括*安全 OU* 和*取证 OU*）会很有帮助。在安全 OU 中，您应该拥有以下账户： + **日志存档：**将日志聚合到权限有限的日志存档 AWS 账户 中。 + **安全工具：**将安全服务集中在安全工具 AWS 账户 中。此账户以安全服务的委托管理员身份运行。 在取证 OU 中，您可以选择实施单一取证账户，也可以为您运营的每个区域实施账户，具体取决于哪种账户最适合您的业务和运营模式。如果为每个区域创建一个取证账户，就可以阻止在该区域之外创建 AWS 资源，降低资源被复制到非预期区域的风险。例如，如果您只在美国东部（弗吉尼亚州北部）区域（`us-east-1`）和 美国西部（俄勒冈州）（`us-west-2`）运营，那么您将在取证 OU 中拥有两个账户：一个用于 `us-east-1`，另一个用于 `us-west-2`。 可以为多个区域创建取证 AWS 账户。在将 AWS 资源复制到该账户时应小心谨慎，确保符合数据主权要求。由于预置新账户需要时间，因此必须在事件发生前创建和分析取证账户，以便响应人员能够做好准备，有效地使用这些账户进行响应。 下图显示了一个账户结构示例，其中包括一个取证 OU，涵盖了根据每个区域创建的取证账户： ![\[流程图显示了用于响应事件而根据区域创建的账户结构，分为安全 OU 和取证 OU。\]](http://docs.aws.amazon.com/zh_cn/wellarchitected/latest/framework/images/region-account-structure.png) **捕获备份和快照** 为关键系统和数据库建立备份对于从安全事件中恢复和取证至关重要。有了备份，您就能够将系统恢复到以前的安全状态。在 AWS 上，您可以创建各种资源的快照。快照为您提供这些资源的时间点备份。有许多 AWS 服务能够在备份和恢复方面为您提供支持。有关这些服务以及备份和恢复方法的详细信息，请参阅《[Backup and Recovery Prescriptive Guidance](https://docs.aws.amazon.com/prescriptive-guidance/latest/backup-recovery/services.html)》以及《[Use backups to recover from security incidents](https://aws.amazon.com/blogs/security/use-backups-to-recover-from-security-incidents/)》。 特别是遇到勒索软件等情况时，妥善保护备份至关重要。有关保护备份的指导，请参阅《[Top 10 security best practices for securing backups in AWS](https://aws.amazon.com/blogs/security/top-10-security-best-practices-for-securing-backups-in-aws/)》。除了确保备份安全外，您还应当定期测试备份和还原流程，从而确保现有的技术和流程按预期运行。 **自动取证** 在安全事件期间，您的事件响应团队必须能够快速收集和分析证据，同时保持事件相关时间段的准确性（例如捕获与特定事件或资源相关的日志，或收集 Amazon EC2 实例的内存转储）。对于事件响应团队来说，手动收集相关证据既具有挑战性又很耗时，尤其是在存在大量实例和账户的情况下。此外，手动收集容易出现人为错误。出于这些原因，您应该尽可能开发和实现取证自动化功能。 AWS 提供了大量用于取证的自动化资源，这些资源在下面的“资源”部分中列出。这些资源是我们开发并由客户实施的取证模式示例。虽然这些资源可能是有用的参考架构，但可以考虑根据您的环境、要求、工具和取证流程对资源进行修改，或者创建新的取证自动化模式。 ## 资源 资源 **相关文档：** + 《[AWS Security Incident Response Guide》– Develop Forensics Capabilities](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/develop-forensics-capabilities.html) + 《[AWS Security Incident Response Guide》– Forensics Resources](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-b-incident-response-resources.html#forensic-resources) + [AWS Cloud 中的取证调查环境策略](https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/) + [如何在 AWS 中自动实施取证磁盘收集](https://aws.amazon.com/blogs/security/how-to-automate-forensic-disk-collection-in-aws/) + [AWS Prescriptive Guidance – 自动化事件响应和取证 ](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/automate-incident-response-and-forensics.html) **相关视频：** + [ 自动化事件响应和取证 ](https://www.youtube.com/watch?v=f_EcwmmXkXk) **相关示例：** + [ 自动事件响应和取证框架 ](https://github.com/awslabs/aws-automated-incident-response-and-forensics) + [ Amazon EC2 的自动取证编排工具 ](https://docs.aws.amazon.com/solutions/latest/automated-forensics-orchestrator-for-amazon-ec2/welcome.html) # SEC10-BP04 制定和测试安全事件响应行动手册 SEC10-BP04 制定和测试安全事件响应行动手册 准备事件响应流程的关键环节是制定行动手册。事件响应行动手册提供了规范性指南和步骤，供发生安全事件时遵循。清晰的结构和步骤可简化响应，减少发生人为错误的可能性。 **在未建立这种最佳实践的情况下暴露的风险等级：**中 ## 实施指导 实施指导 应针对以下事件场景创建行动手册： + **预期事件**：应针对预期的事件创建行动手册。这包括拒绝服务（DoS）、勒索软件和凭证泄露等威胁。 + **已知的安全调查发现或警报**：应该创建行动手册来应对已知的安全调查发现和警报，例如来自 Amazon GuardDuty 的调查发现和警报。当您收到 GuardDuty 调查发现时，行动手册应提供明确的步骤，以防止错误处理或忽略警报。有关修复措施的更多详细信息和指南，请参阅 [Remediating security issues discovered by GuardDuty](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_remediate.html)。 行动手册应包含安全分析师需要完成的技术步骤，以便充分调查和应对潜在的安全事件。 AWS 的客户事件响应团队（CIRT）发布了一个[包含事件响应行动手册的 GitHub 存储库](https://github.com/aws-samples/aws-customer-playbook-framework/tree/main/docs)，而这些事件响应行动手册按威胁情景、类型和资源进行整理。这些行动手册可以进行调整，使其与现有的事件响应过程保持一致，也可以作为开发新的事件响应过程的基础。 ### 实施步骤 实施步骤 行动手册中应包括的项目有： + **行动手册概述**：本行动手册针对哪些风险或事件场景？ 本行动手册的目标是什么？ + **先决条件**：此事件场景需要哪些日志、检测机制和自动化工具？ 预期的通知是什么？ + **沟通和上报信息**：谁参与其中，他们的联系信息是什么？ 每个利益相关方的责任是什么？ + **响应步骤**：在事件响应的各个阶段，应采取哪些战术性措施？ 分析师应该进行哪些查询？ 应该运行什么代码才能达到预期的结果？ + **检测**：如何检测事件？ + **分析**：如何确定影响范围？ + **控制**：如何隔离事件来限制其影响范围？ + **消除**：如何从环境中消除威胁？ + **恢复**：受影响的系统或资源将如何恢复生产？ + **期望结果**：运行查询和代码后，行动手册的期望结果是什么？ ## 资源 资源 **相关的 Well-Architected 最佳实践：** + [SEC10-BP02 – 制定事件管理计划](https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_develop_management_plans.html) **相关文档：** + [事件响应行动手册框架](https://github.com/aws-samples/aws-customer-playbook-framework)  + [制定自己的事件响应行动手册](https://github.com/aws-samples/aws-incident-response-playbooks-workshop)  + [事件响应行动手册样本](https://github.com/aws-samples/aws-incident-response-playbooks)  + [使用 Jupyter 行动手册和 CloudTrail Lake 构建 AWS 事件响应运行手册](https://catalog.workshops.aws/incident-response-jupyter/en-US)  # SEC10-BP05 预置访问权限 SEC10-BP05 预置访问权限 确保事件响应者将正确的访问权限预置到 AWS 中，以缩短调查到恢复所需的时间。 **常见反模式：** + 使用根账户进行事件响应。 + 变更现有账户。 + 在提供实时权限提升时直接操作 IAM 权限。 **在未建立这种最佳实践的情况下暴露的风险等级：**中 ## 实施指导 实施指导 AWS 建议尽可能减少或消除对长期有效凭证的依赖，转而使用临时凭证和*实时*权限提升机制。长期有效的凭证容易带来安全风险，并且会增加运营开销。对于大多数管理任务以及事件响应任务，建议您对管理访问实施[身份联合验证](https://aws.amazon.com/identity/federation/)以及[临时上报](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/)。在此模型中，用户请求提升到更高级别的权限（例如事件响应角色），如果用户符合提升条件，则会向审批者发送请求。如果请求获得批准，用户将收到一组临时的 [AWS 凭证](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-files.html)，可用于完成用户任务。在这些凭证过期后，用户必须提交新的提升请求。 在大多数事件响应场景中，建议使用临时权限提升。执行此操作的正确方法是使用 [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/welcome.html) 和[会话策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session)来限定访问范围。 在一些场景中，联合身份不可用，例如： + 与被盗用的身份提供者（IdP）相关的中断。 + 导致联合访问管理系统损坏的错误配置或人为错误。 + 恶意活动，例如分布式拒绝服务（DDoS，Distributed Denial of Service）事件或导致系统不可用的活动。 在上述情况下，应配置紧急 *Break Glass* 访问，以允许调查事件并及时给予补救。我们建议您使用[具有适当权限的用户、组或角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#lock-away-credentials)，来执行任务和访问 AWS 资源。请仅将根用户用于[需要根用户凭证的任务](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)。要确认事件响应者对 AWS 和其他相关系统是否具有正确的访问权限级别，建议预置专用的账户。账户需要特许的访问权限，并且必须受到严格的控制和监视。在构建账户时，必须使用执行必要任务所需的最少权限，并且访问级别应基于作为事件管理计划的一部分创建的行动手册。 最好使用专门构建的专用用户和角色。通过添加 IAM 策略来临时提升用户或角色的访问权限，既会导致无法清楚地了解用户在事件期间拥有哪些访问权限，又会带来无法撤销提升的权限的风险。 请务必删除尽可能多的依赖项，以确保能在尽可能多的故障场景中获得访问权限。为了支持此操作，可创建一个行动手册，验证是否在专用的安全账户中创建事件响应用户作为用户，而不是通过任何现有的联合身份验证或单点登录（SSO）解决方案管理他们。每个响应者都必须拥有自己的指定账户。账户配置必须实施[强密码策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html)和多重身份验证（MFA）。如果事件响应行动手册仅需要对 AWS 管理控制台 的访问权限，则用户不应配置访问密钥，并且应明确禁止用户创建访问密钥。可以使用 IAM 策略或服务控制策略（SCP，Service Control Policy）进行此配置，如 AWS 安全最佳实践（适用于 [AWS Organizations SCP](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html)）中所述。用户仅能够在其他账户中代入事件响应角色，而不应具有其他任何权限。 在事件处理期间，可能需要向其他内部或外部人员授予访问权限，以支持调查、补救或恢复活动。在这种情况下，可以使用前面提到的行动手册机制，并且必须创建一个流程，确保在事件结束后立即撤消其他任何访问权限。 要确保能正确地监控和审计对事件响应角色的使用，至关重要的一点是，为此目的创建的 IAM 账户不会在人员之间共享，并且不会使用 AWS 账户根用户，除非[特定任务要求这样做](https://docs.aws.amazon.com/accounts/latest/reference/root-user-tasks.html)。如果需要根用户（例如，对特定账户的 IAM 访问权限不可用），请使用单独的流程和可用的行动手册来验证根用户登录凭证和 MFA 令牌的可用性。 要为事件响应角色配置 IAM 策略，请考虑使用 [IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-generation.html) 来生成基于 AWS CloudTrail 日志的策略。为此，请在非生产账户中向事件响应角色授予管理员访问权限，并运行行动手册。完成后，会创建一个策略，仅允许已执行的操作。之后，可以跨所有账户将此策略应用于所有事件响应角色。您可能希望为每个行动手册创建一个单独的 IAM 策略，以便更轻松地进行管理和审计。示例行动手册可能包括针对勒索软件、数据泄露、丢失生产访问权限和其他场景的响应计划。 使用事件响应用户账户可在[其他 AWS 账户 中代入专用的事件响应 IAM 角色](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html)。必须将这些角色配置为仅可由安全账户中的用户代入，并且信任关系必须要求调用主体已使用 MFA 进行身份验证。角色必须使用严格界定的 IAM 策略来控制访问。确保这些角色的所有 `AssumeRole` 请求都记录在 CloudTrail 中并发出提醒，并确保记录使用这些角色执行的任何操作。 强烈建议清楚地命名 IAM 账户和 IAM 角色，以便在 CloudTrail 日志中轻松找到他们。例如，将 IAM 账户命名为 `-BREAK-GLASS`， 并将 IAM 角色命名为 `BREAK-GLASS-ROLE`。 [CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) 用于记录 AWS 账户中的 API 活动，并且应该用于[配置关于使用事件响应角色的提醒](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/)。请参阅博文，了解有关配置使用根密钥时的提醒。可以修改说明以配置 [Amazon CloudWatch](https://aws.amazon.com/cloudwatch/) 指标筛选条件，从而筛选 `AssumeRole` 事件（与事件响应 IAM 角色相关）： ``` { $.eventName = "AssumeRole" && $.requestParameters.roleArn = "" && $.userIdentity.invokedBy NOT EXISTS && $.eventType != "AwsServiceEvent" } ``` 由于事件响应角色可能具有高级别的访问权限，因此，请务必将这些提醒转至广泛的群体，并及时采取适当的行动。 在事件处理期间，响应者可能需要访问不受 IAM 直接保护的系统。它们可能包括 Amazon Elastic Compute Cloud 实例、Amazon Relational Database Service 数据库或软件即服务（SaaS）平台。强烈建议不要使用 SSH 或 RDP 等本机协议，而是使用 [AWS Systems Manager Session Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html) 对 Amazon EC2 实例进行所有管理访问。可以使用安全且经过审计的 IAM 控制此访问。此外，还可以使用 [AWS Systems Manager Run Command 文档](https://docs.aws.amazon.com/systems-manager/latest/userguide/execute-remote-commands.html)自动实施行动手册的部分内容，这样可以减少用户出错的机会并缩短恢复时间。对于访问数据库和第三方工具，我们建议将访问凭证存储在 AWS Secrets Manager 中，并向事件响应者角色授予访问权限。 最后，事件响应 IAM 账户的管理应该添加到您的[合并人员、移动人员和离开人员流程](https://docs.aws.amazon.com/wellarchitected/latest/security-pillar/permissions-management.html)中，并定期进行检查和测试，以确认只允许预期访问。 ## 资源 资源 **相关文档：** + [管理对 AWS 环境的临时提升的访问权限](https://aws.amazon.com/blogs/security/managing-temporary-elevated-access-to-your-aws-environment/) + 《[AWS Security Incident Response Guide](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html)》 + [AWS Elastic Disaster Recovery](https://aws.amazon.com/disaster-recovery/) + [AWS Systems Manager Incident Manager](https://docs.aws.amazon.com/incident-manager/latest/userguide/what-is-incident-manager.html) + [为 IAM 用户设置账户密码策略](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_passwords_account-policy.html) + [在 AWS 中使用多重身份验证（MFA）](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html) + [ 使用 MFA 配置跨账户访问 ](https://aws.amazon.com/blogs/security/how-do-i-protect-cross-account-access-using-mfa-2/) + [ 使用 IAM Access Analyzer 生成 IAM 策略 ](https://aws.amazon.com/blogs/security/use-iam-access-analyzer-to-generate-iam-policies-based-on-access-activity-found-in-your-organization-trail/) + [Best Practices for AWS Organizations Service Control Policies in a Multi-Account Environment](https://aws.amazon.com/blogs/industries/best-practices-for-aws-organizations-service-control-policies-in-a-multi-account-environment/) + [ 如何在使用 AWS 账户的根访问密钥时接收通知 ](https://aws.amazon.com/blogs/security/how-to-receive-notifications-when-your-aws-accounts-root-access-keys-are-used/) + [ 使用 IAM 托管策略创建精细会话权限 ](https://aws.amazon.com/blogs/security/create-fine-grained-session-permissions-using-iam-managed-policies/) + [Break glass access](https://docs.aws.amazon.com/whitepapers/latest/organizing-your-aws-environment/break-glass-access.html) **相关视频：** + [ 在 AWS 中自动化事件响应和取证](https://www.youtube.com/watch?v=f_EcwmmXkXk) + [运行手册、事件报告和事件响应 DIY 指南](https://youtu.be/E1NaYN_fJUo) + [ 准备和响应 AWS 环境中的安全事件 ](https://www.youtube.com/watch?v=8uiO0Z5meCs) # SEC10-BP06 预部署工具 SEC10-BP06 预部署工具 确保安全人员预部署了适当的工具，来缩短从调查到恢复的时间。 **在未建立这种最佳实践的情况下暴露的风险等级：**中 ## 实施指导 实施指导 要自动执行安全响应和操作功能，您可以使用 AWS 提供的一整套 API 和工具。您可以完全自动执行身份管理、网络安全、数据保护和监控功能，并使用您已采用的常见软件开发方法交付这些功能。当构建安全自动化时，您的系统可以监控、审核和启动响应，您不必安排人员监控您的安全位置并对事件做出人为响应。 如果您的事件响应团队继续以同样的方式响应警报，警报可能会让他们应接不暇。久而久之，团队对警报的敏感性可能会下降，并可能在处理正常情况时犯错或者错过异常警报。利用一些功能自动处理重复和正常的警报，并将敏感、特殊的事件交由人员来处理，这样有助于避免疲于应对警报。集成异常检测系统（例如 Amazon GuardDuty、AWS CloudTrail Insights 和 Amazon CloudWatch Anomaly Detection）可以减轻常见阈值警报的负担。 您可以通过编程方式自动执行此流程中的步骤，从而改进手动流程。为事件定义修复模式之后，您可以将此模式分解为可执行的逻辑，并编写代码以执行此逻辑。然后，响应人员可以运行该代码来修复问题。久而久之，您就可以自动化越来越多的步骤，并最终自动处理各类常见事件。 在安全调查期间，您需要能够查看相关日志，以便记录并了解事件的来龙去脉和时间线。生成警报时也需要日志，因为日志可以指示某些相关操作已经发生。选择、启用、存储、设置查询和检索机制以及设置警报至关重要。此外，提供工具来搜索日志数据的有效方法是 [Amazon Detective](https://aws.amazon.com/detective/)。 AWS 提供 200 多种云服务和数千种功能。我们建议您检查可支持和简化事件响应策略的服务。 除日志记录外，还应当制定并实施[标记策略](https://docs.aws.amazon.com/whitepapers/latest/tagging-best-practices/tagging-best-practices.html)。标记有助于提供有关 AWS 资源用途的背景信息。标记也可用于实现自动化。 ### 实施步骤 实施步骤 **选择并设置用于分析和报警的日志** 请参阅以下关于配置事件响应日志记录的文档： + [ 安全事件响应的日志记录策略 ](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/) + [SEC04-BP01 配置服务和应用程序日志记录](sec_detect_investigate_events_app_service_logging.md) **启用安全服务来支持检测和响应** AWS 提供检测、预防和响应功能，而其它服务可用于构建自定义安全解决方案。有关与安全事件响应最相关的服务的列表，请参阅[云功能定义](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html)和[安全事件响应主页](https://aws.amazon.com/security-incident-response/)。 **制定和实施标记策略** 要获取围绕 AWS 资源的业务场景和相关内部利益相关方的背景信息，可能很困难。要做到这一点，可以采用标签的形式，标签为 AWS 资源分配元数据，并由用户定义的键和值组成。您可以创建标签，按照用途、所有者、环境、处理的数据类型以及您选择的其他标准对资源进行分类。 采用一致的标记策略可以加快响应速度，并通过快速识别和辨别 AWS 资源的背景信息，最大限度地减少在组织背景方面所花费的时间。标签还可以充当启动自动响应的机制。有关要标记的内容的详细信息，请参阅《[标记 AWS 资源](https://docs.aws.amazon.com/tag-editor/latest/userguide/tagging.html)》。首先，您需要定义要在组织内实施的标签。之后，实施并强制执行这一标记策略。有关实施和强制执行的详细信息，请参阅《[使用 AWS 标签策略和服务控制策略（SCP）实施 AWS 资源标记策略](https://aws.amazon.com/blogs/mt/implement-aws-resource-tagging-strategy-using-aws-tag-policies-and-service-control-policies-scps/)》。 ## 资源 资源 **相关的 Well-Architected 最佳实践：** + [SEC04-BP01 配置服务和应用程序日志记录](sec_detect_investigate_events_app_service_logging.md) + [SEC04-BP02 在标准化位置收集日志、调查发现和指标](sec_detect_investigate_events_logs.md) **相关文档：** + [ 安全事件响应的日志记录策略 ](https://aws.amazon.com/blogs/security/logging-strategies-for-security-incident-response/) + [ 事件响应云功能定义 ](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/appendix-a-cloud-capability-definitions.html) **相关示例：** + [ 使用 Amazon GuardDuty 和 Amazon Detective 进行威胁检测和响应 ](https://catalog.workshops.aws/guardduty/en-US) + [ Security Hub 讲习会 ](https://catalog.workshops.aws/security) + [ 使用 Amazon Inspector 进行漏洞管理 ](https://catalog.workshops.aws/inspector/en-US) # SEC10-BP07 运行模拟 SEC10-BP07 运行模拟 随着组织不断发展壮大，威胁形势也会不断变化，因此务必要持续评估组织的事件响应能力。运行模拟（也称为实际演练）是可用于执行这种评估的一种方法。模拟过程使用现实世界中的安全事件场景，旨在模仿威胁主体采取的战术、技术和程序（TTP），让组织通过响应现实中可能发生的模拟网络事件，来练习和评估自己的事件响应能力。 **建立此最佳实践的好处：**模拟有多种好处： + 检验网络准备情况，有助于事件响应人员树立信心。 + 测试工具和工作流程的准确性和有效性。 + 完善沟通和上报环节，使之与您的事件响应计划相吻合。 + 提供机会来应对不太常见的攻击载体。 **在未建立这种最佳实践的情况下暴露的风险等级：**中 ## 实施指导 实施指导 模拟主要分为三种类型： + **桌面演练：**桌面演练模拟方法是一种基于讨论的研讨会，让各个事件响应利益相关方参与进来，练习角色和职责，以及练习使用既定的沟通工具和行动手册。通常是用一整天的时间在虚拟场地和/或实地中协调完成演练。由于桌面演练以讨论为基础，因此侧重于流程、人员和协作。在讨论中，技术是必不可少的一部分，但事件响应工具或脚本的实际使用通常不包括在桌面演练中。 + **紫队演练：**紫队演练可提高事件响应人员（蓝队）和模拟威胁主体（红队）之间的协作能力。蓝队由安全运营中心（SOC）的成员组成，但也可以包括在实际网络事件中会参与进来的其他利益相关方。红队由渗透测试团队或接受过攻击安全培训的关键利益相关方组成。在设计场景时，红队会与演练协调员相互协作，以确保场景的准确性与可行性。在紫队演练中，主要的关注点是支持事件响应工作的检测机制、工具和标准操作程序（SOP）。 + **红队演练：**在红队演练中，进攻方（红队）模拟进行攻击，以在预定范围内实现特定目标或一系列目标。防御方（蓝队）不一定知道演练的范围和持续时间，如此，可以更真实地评估他们应对真实事件的能力。由于红队的演练可能是侵入性测试，因此务必谨慎行事，并实施控制措施，以确保该演练不会对环境造成实际破坏。 请考虑定期协调开展网络模拟。对于参与者和整个组织而言，每种演练类型都可以带来独特的好处，因此您可以选择从不太复杂的模拟类型（例如桌面演练）入手，然后再慢慢过渡到较为复杂的模拟类型（红队演练）。您应根据自身的安全成熟度、资源和期望结果选择模拟类型。由于红队演练的复杂性和成本，一些客户可能不会选择进行红队演练。 ## 实施步骤 实施步骤 无论您选择哪种模拟类型，模拟通常都遵循以下实施步骤： 1. **定义核心演练要素：**定义模拟场景和模拟要达成的目标。这两者都应该得到领导层的认同。 1. **确定关键利益相关方：**演练至少需要演练协调员和参与者。根据具体的场景，可能会涉及其他利益相关方，例如法务、通信或行政等领域的领导层。 1. **构建和测试场景：**如果有特定要素不可行，则可能需要在构建时重新定义该场景。本阶段的期望结果是最终确定的场景。 1. **协调开展模拟：**采用的模拟类型决定了所需的协调工作（书面讨论场景对比高技术含量的模拟场景）。协调员应根据演练目标调整其协调战术，并应尽可能让所有演练参与者都参与进来，以实现最大利益。 1. **撰写事后报告（AAR）：**确定哪些方面进展较为顺利、哪些方面需要改进以及可能存在的差距。AAR 应衡量模拟的有效性，并记录团队对模拟事件的响应情况，以便在将来的模拟中可以不断跟踪进度。 ## 资源 资源 **相关文档：** + [AWS 事件响应指南](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/welcome.html) **相关视频：** + [AWS 实际演练 – 安全版](https://www.youtube.com/watch?v=XnfDWID_OQs) + [Running effective security incident response simulations](https://www.youtube.com/watch?v=63EdzHT25_A) # SEC10-BP08 建立从事件中吸取经验教训的框架 SEC10-BP08 建立从事件中吸取经验教训的框架 实现*经验教训总结*框架和根本原因分析能力不仅能够有助于提高事件响应能力，还有助于防止事件再次发生。通过从每次事件中吸取教训，您可以避免重复同样的错误、泄露或错误配置，这不仅可以改善您的安全态势，还可以最大限度地减少因可预防的情况而损失的时间。 **在未建立这种最佳实践的情况下暴露的风险等级：**中 ## 实施指导 实施指导 重要的是要实现一个*经验教训总结*框架，大体上确立并实现以下几点： + 何时总结经验教训？ + 总结经验教训的过程涉及什么？ + 如何总结经验教训？ + 谁参与了这个过程，具体情况如何？ + 如何确定需要改进的领域？ + 如何确保有效跟踪和实施改进措施？ 该框架不应关注或指责个人，而应侧重于改进工具和流程。 ### 实施步骤 实施步骤 除了前面列出的大体上的成果外，重要的是要确保提出正确的问题，以便从流程中获得最大价值（可以带来切实可行的改进的信息）。请考虑以下问题，以便于您启动经验教训讨论： + 发生了什么事件？ + 何时首次发现该事件？ + 是如何发现的？ + 哪些系统针对该活动发出了警报？ + 涉及哪些系统、服务和数据？ + 具体发生了什么？ + 哪些地方做得好？ + 哪些地方做得不好？ + 哪些流程或程序出现问题或未能扩展以应对事件？ + 以下方面有哪些地方有待改进： + **People** + 需要联系的人是否真的可以联系上，联系名单是否是最新名单？ + 相应人员是否缺少有效应对和调查事件所需的培训或能力？ + 相应的资源是否已就绪并随时可用？ + **流程** + 是否遵循了流程和程序？ + 是否针对这种事件记录并提供了流程和程序？ + 是否缺少必要的流程和程序？ + 响应人员是否能够及时获得所需的信息来处理问题？ + **技术** + 现有警报系统是否能有效识别活动并发出警报？ + 我们如何将检测时间缩短 50%？ + 现有警报是否需要改进，或者是否需要针对这种事件设置新的警报？ + 现有工具是否允许对事件进行有效调查（搜索/分析）？ + 怎样才能更快地识别这种事件？ + 如何防止这种事件再次发生？ + 谁是改进计划的负责人，如何检验改进计划的执行情况？ + 实施和测试额外监控或预防性控制机制和流程的时间表是怎样的？ 此列表并非详尽无遗，但旨在作为一个起点，确定组织和业务需求是什么，以及如何分析这些需求，以便最有效地从事件中吸取经验教训，并不断改进您的安全态势。最重要的是，该列表开始将经验教训作为事件响应流程、文档和利益相关方期望的标准组成部分。 ## 资源 资源 **相关文档：** + 《[AWS Security Incident Response Guide》– Establish a framework for learning from incidents](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/establish-framework-for-learning.html) + [NCSC CAF 指南：总结经验教训](https://www.ncsc.gov.uk/collection/caf/caf-principles-and-guidance/d-2-lessons-learned)