本文档仅供参考。 它代表了截至本文档发布之日 Amazon Web Services (AWS) 提供的当前产品和实践，这些产品和做法如有更改，恕不另行通知。 客户有责任对本文档中的信息以及对 AWS 产品或服务的任何使用情况进行自己的独立评估，每种产品或服务都是 “按原样” 提供的，无论是明示还是暗示的担保。 本文档不创建 AWS、其附属公司、供应商或许可方的任何担保、陈述、合同承诺、条件或保证。 AWS 对客户的责任和责任受 AWS 协议的控制，本文档既不是 AWS 与其客户之间的任何协议的一部分，也不修改。
© 2021 Amazon 网络服务公司或其附属公司。 保留所有权利。 本作品根据知识共享署名 4.0 国际许可协议进行许可。
提供此 AWS 内容须遵守 http://aws.amazon.com/agreement 提供的 AWS 客户协议的条款或客户与 Amazon Web Services, Inc. 或 Amazon 网络服务 EMEA SARL 或两者之间的其他书面协议。
- 游戏手册应以降价格式存储在 git 存储库中。
- 为每个 PlayBook 创建一个易于打印的自包含版本，以便与那些无权访问 git 存储库的人共享。
- 建议允许事件响应团队成员将 git 项目分支并克隆到他们的本地环境，例如 PC、VDI 或笔记本电脑。
- 在对分支进行改进时，请将其提交审核、批准并合并到主分支机构中。
- git 项目将托管文档和代码。
- 考虑使用 CD/CI 管道来促进行动手册的治理和部署。
- ** 威胁 **：描述行动手册已解决的威胁
- Endgam：根据 _ [* AWS 云采用框架 (CAF) *] 的安全视角描述行动手册的预期结果（https://d0.awsstatic.com/whitepapers/AWS_CAF_Security_Perspective.pdf)_）和业界接受的安全模式，例如漏洞评估和影响分析。
- ** 响应步骤 **：根据 * [_NIST 800-61r2-计算机安全事件响应指南 _] (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf) * 提供按时间顺序对事件作出响应的逐步程序。 请参阅图 A。
- ** 模拟 ** [**CODE **]：提供分步过程来生成触发启动响应的警报所需的指标。
- ** 事件分类、处理和检测 **：按 [MITRE ATT&CK 企业策略] (https://attack.mitre.org/tactics/enterprise/) 对行动手册进行分类，列举运行行动手册所需的工具，列举用于检测生成警报的指标（又名调查结果），日志生成指标和促进分析所需的来源以及所涉团队.
- ** 事件处理流程 **：响应的每个学科应遵循的规范性指导。 这些不是按时间顺序排列的执行顺序，它们是在进行 **3 时参考的。 响应步骤 **。 在整个响应过程中，必须记录所有执行的操作，并将所有收集的证据集中在已知存储库中，并根据事件响应团队 RACI 提供适当的权利。 同样至关重要的是，在响应期间拥有合适的沟通渠道，并具有集中编排能力，这将使事件响应团队成员能够专注于自己的专长范围内的任务。 集中编排功能将保持适当的沟通流动，并确保所有需要的活动都在业务知识和批准的情况下进行。
- ** 分析-警报验证 **：警报通知的内容需要直接对照源生成指标（即 “地面真相”）进行验证。 这是必需的，原因至少有两个。 首先，一般来说，随着原始指标流过不同的系统而转变，直到它们到达事件响应小组，这可能导致意外修改重大事件数据。 其次，通知可能是由于机器或人为配置错误而生成的。
- ** 分析-警报分类 **：根据警报提供的指标，搜索用于生成这些指标的日志构建上下文以便进行分析。
- ** 分析-范围 **：在可用和警报相关的日志源中搜索证据，以确定演员在事件生命周期内执行的活动。
- ** 分析-影响 **：确定哪些工作负载和组件受到参与者的活动及其程度的影响。 制定假设以与更大的事件响应团队讨论，以确定对业务的影响并确定后续步骤的优先顺序。
- ** 遏制：** 确定在进展或分析阶段结束期间事件的遏制策略。 适当的策略取决于范围和影响，并得到工作负载所有者的批准。 遏制活动应与受影响工作负载的威胁模型和事件响应期间的实际情境保持一致。 应该提供一些不同的或补充的遏制选项，以尽量减少可能的附带影响，例如停机时间、数据销毁等遏制措施。 在此阶段，必须在收集证据过程中给予应有的谨慎。 尽管在分析过程中开始取证数据聚合，例如 CloudTrail 日志、VPC Flow 日志和 GuardDuty 日志，但这是快照和备份的最合适时间，因为服务已重新配置以防止进一步活动，例如 EC2 实例快照、RDS 数据库备份和 Lambda 触发器移除。
- ** 根除和恢复 **：对手提供的资源被禁用或完全删除，并确定所有受影响资源的漏洞和配置问题。 在工作负载所有者批准后，所有资源都会正确重新配置，并应用安全更新，以降低相同或类似漏洞获得成功的可能性。 已完成对工作负载安全状况的重新评估。 在应用配置更改和安全更新之后，如果工作负载的安全态势仍对业务构成不可接受的风险程度，则应起草中长期架构更改建议，并提交由负责任和负责任的团队评估。
- ** 事故后活动 **：在完成之前的所有阶段之后，将以 “经验教训” 课程的形式对事件进行深入分析。 公布了事件响应时间表，并讨论了重点放在为加强应对下一次安全事件的准备而需要做出的更改。 在此阶段，事件响应小组的重点是加强指令、预防、检测和响应控制（参见图 B），不仅针对受影响的工作负载，而且针对企业拥有的所有工作负载。
! [图片] (/images/nist_life_cycle.png)
** 图 A-事件响应生命周期 **
! [图片] (/images/image-caf-sec.png)
** 图 B-AWS 云采用框架的安全视角 **
- 选择游戏手册将要解决的威胁，然后在 ``1 中描述它。 威胁部分 ```。 根据需要提供尽可能多的参考资料，以帮助剧本读者理解它。
- 查看行动手册模板部分 ``2。 终局部分 ```并进行更改或保持原样。 它们基于 AWS 安全和行业模式，例如 [CAF 的安全视角] (https://d0.awsstatic.com/whitepapers/AWS_CAF_Security_Perspective.pdf)、[AWS 架构完善框架的安全支柱] (https://d1.awsstatic.com/whitepapers/architecture/AWS-Security-Pillar.pdf)、[AmazonWeb 服务：安全流程概述] (https://d0.awsstatic.com/whitepapers/aws-security-whitepaper.pdf)、[AWS 安全事件响应指南] (https://d1.awsstatic.com/whitepapers/aws_security_incident_response.pdf) 和 [NIST Special Publication 800-61r2 Computer Security Incident Handling Guide] (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-61r2.pdf)。
- 填写 ``5 部分。 事件分类、处理和检测 ```，并提供适当的信息。 如果在构建剧本的其他部分的过程中，你最终发现了新的指标、你可能想要使用的其他工具等，你可以稍后回到本部分。
- 定义触发威胁指标的步骤。 记录流程、AWS 资源、IAM 委托人、所需的策略和代码，例如 AWS CLI 命令、基于 AWS 开发工具包的代码，最好包装在 shell 脚本或支持的语言代码程序中。 添加屏幕截图，说明使用 CloudWatch Insights 或 Athena 等分析工具生成的模拟活动生成的各种日志。
- 在
3 节下制定应对步骤。 响应步骤部分突出显示每个步骤所属的 NIST IR 生命周期阶段。 应按照与受影响工作负载的威胁模型相一致的时间顺序列举这些步骤。 在剧本中明确指出，按时间顺序排列的顺序不是不可变的，可以根据事件的上下文进行更改。 建议任何偏离既定执行命令的行为都必须经过先前批准的审查程序，以尽量减少可能进一步损害受影响工作量的行动的风险。 - 在第 `6 节中创建支持 NIST IR 生命周期每个阶段的 AWS CLI 命令和 Athena 查询。 事件处理过程 ```。 一系列查询和命令应从一般角度满足每个阶段的要求，并以屏幕截图的形式记录其输出。 这些命令使用类似或等于事件响应者权利的角色针对受影响的帐户运行。 查询将针对使用 Athena 的相关日志存储库运行，最低限度为 CloudTrail 和 VPC Flow 日志。 如果需要分析的日志无法通过 Athena 获得，请使用可用的分析工具，例如 SIEM 或大数据解决方案。