AWS安全事件响应：加速事件响应生命周期的客户之旅
组织在构建和维护有效的安全事件响应程序时面临越来越多的挑战。IBM和Morning Consult的研究显示，安全团队面临两大挑战：超过50%的安全警报因资源限制和警报疲劳而未得到处理，而误报消耗了30%的调查时间，延迟了对真正威胁的响应。
根据《2024年IBM数据泄露成本报告》，组织现在平均需要258天来识别和遏制安全事件。报告还显示，近一半的SOC团队报告在过去两年中检测和响应时间增加，80%的团队表示手动威胁调查显著影响了他们的响应时间。
尽管存在这些挑战，根据《2024年IBM安全服务基准报告》，具有成熟事件响应能力的组织显示平均解决时间（MTTR）减少了50%，每个事件节省了高达58%的成本。这些改进是通过采用自动化工作流、集成工具和简化通信流程来加速威胁检测和遏制所驱动的。
在本文中，我们将通过一个真实场景，展示AWS安全事件响应如何通过加速事件响应生命周期的每一步来立即产生效益，如何与Amazon GuardDuty、AWS Security Hub和AWS Systems Manager等其他原生AWS服务集成，以及如何集成第三方威胁检测结果以纳入自动化监控、分类和遏制能力。
AWS安全事件响应如何帮助
AWS安全事件响应是一项于2024年12月推出的Tier 1服务。该服务是AWS原生的、专为客户构建的安全事件响应解决方案，可与检测和响应（GuardDuty和Security Hub）、网络和内容交付（AWS WAF和AWS Shield）以及管理和治理（Systems Manager）领域的其他AWS服务一起使用，提供更好的体验。AWS安全事件响应还通过服务特定的合作伙伴专业化计划与AWS合作伙伴集成。更多详细信息可在AWS安全事件响应文档中找到。
AWS安全事件响应通过简化安全事件之前、期间和之后的事件管理能力来增强您的安全态势，从而补充现有服务。
关键挑战
AWS安全事件响应解决了三个常见挑战：
- 警报疲劳：通过自动化监控和智能分类，减少警报疲劳并加速安全调查，减少误报并帮助防止安全团队倦怠。
- 分散的访问和通信：通过简化AWS管理控制台权限管理和统一事件响应团队通信，解决分散的访问问题。
- 安全技能差距：通过提供24/7访问AWS安全专家的支持，弥补云安全技能差距，支持包括凭据泄露、数据外泄和勒索软件在内的事件。AWS安全事件响应服务允许安全团队处理即时安全挑战，同时保持对战略长期准备和运营改进的关注。
服务集成
AWS安全事件响应与AWS安全服务互补并集成，提供全面的事件响应能力。该服务与以下服务无缝协作：
- 检测服务：GuardDuty、Security Hub
- 网络安全：AWS WAF和Shield
- 管理工具：Systems Manager
- 第三方解决方案：通过Security Hub集成和AWS安全事件响应合作伙伴专业化计划。
这种集成帮助您构建高效的事件响应能力，可以最小化安全事件在组织云旅程中的时间、成本和影响，同时帮助减少在额外人员、培训和工具维护方面的投资。
独特能力
AWS安全事件响应服务提供：
- AWS客户事件响应团队（CIRT）的专家知识
- 通过API和控制台的工具
- 处理安全事件的简化流程
先决条件
在实施本文描述的能力之前，请确保您已：
- 配置了适当的AWS身份和访问管理（IAM）权限
- 建立了事件响应团队联系人
- 设置了通知渠道
- （可选）在您的账户和AWS区域中启用了GuardDuty
- （可选）在您的账户和区域中启用了SecurityHub
- （可选）部署了所需的AWS CloudFormation StackSets以进行自动化操作
这些先决条件有助于确保您能够充分利用服务的自动化检测、分类和响应能力。
该服务在其自己的服务基础设施内提供自动化监控和分析能力，能够自动分类来自GuardDuty和Security Hub的发现。
对于在您的AWS账户中的自动化遏制操作，您必须首先部署所需的CloudFormation StackSets并配置适当的IAM权限。这有助于确保您保持对环境中采取的自动化操作的完全控制，同时受益于服务的检测能力。这种自动化可以根据您建立的变量进行定制，例如已知的CIDR范围（定义您的网络的特定IP地址范围）和IP地址，并且您可以实施GuardDuty抑制规则以帮助减少误报和警报量。因此，该服务可以作为您现有安全事件响应程序和工具的强大增强。
设置AWS安全事件响应
您的云管理员，具有AWSSecurityIncidentResponseFullAccess权限，已在服务中建立了事件响应团队。该服务通知个人、您的合作伙伴或托管安全服务提供商（MSSP）以及添加到团队的其他联系人，支持快速升级以提醒所需方并响应事件。
作为最佳实践，您的团队为访问和管理AWS安全事件响应案例中的信息建立了最小权限。这有助于确保团队成员对案例详情、发现和调查数据具有适当的访问级别，同时满足安全和合规要求。AWS安全事件响应提供多个API操作，例如CreateCaseComment（向调查添加注释）和GetCase（检索案例元数据），以限制谁可以对不同案例执行哪些操作。对于开发和测试环境，AWS提供基于角色的策略，您可以使用例如AWSSecurityIncidentResponseCaseFullAccess和AWSSecurityIncidentResponseReadOnlyAccess进行基于角色的访问控制（如图1所示）。对于生产环境，我们建议根据您的安全要求，遵循最小权限原则创建自定义IAM策略。
图1：安全事件响应的权限策略
在配置AWS安全事件响应服务后，您的安全团队审查电子邮件分发列表或别名以接收来自服务的通知，如图2所示。您已在待办事项中开发了项目，以利用Amazon EventBridge集成在未来添加pager duty、Jira和其他服务以获取额外的通知机制。
图2：使用控制台管理您的事件响应团队成员
检测和响应可疑活动
在设置AWS安全事件响应几天后的凌晨2:00，该服务通过GuardDuty发现检测到一系列可疑活动，包括异常的IAM用户行为（如图3所示）、来自未知IP地址的异常API调用，以及偏离您账户正常基线的Amazon Elastic Compute Cloud（Amazon EC2）实例创建激增。这种活动模式与GuardDuty扩展威胁检测监控的已知威胁行为相匹配。如果没有该服务，安全团队将需要手动分析和关联这些跨账户和区域的单独发现。相反，该服务自动识别可疑活动的模式。
图3：潜在可疑活动的模式
其中一种异常行为是大量未被识别的EC2实例创建，包括SSH密钥（用于远程访问的安全凭据）和安全组配置（控制网络流量的防火墙规则）允许互联网连接。使用这个示例场景，让我们逐步了解该服务的自动化监控、分类和遏制能力、访问管理、用于自定义集成的API操作、协作工具以及24/7的AWS安全专家如何协同工作，帮助您应对AWS环境中的安全事件响应挑战。
|
|
随着初始检测完成，下一阶段侧重于集中和分析安全发现以了解事件的全范围。
集中安全发现：系统化方法
GuardDuty开始在您启用的区域中生成发现。
注意：必须在您的账户和区域中启用GuardDuty。有关设置说明，请参阅GuardDuty文档。
由于AWS安全事件响应与GuardDuty集成，这些发现会自动发送到服务进行内部处理、分析和自动分类，无需手动操作。该服务的主动响应和警报分类功能分析多个因素，包括您账户的历史基线活动、特定的GuardDuty发现类型以及跨账户的关联模式。在这种情况下，它识别了偏离您环境正常模式的异常EC2实例创建活动。
当服务识别出真正阳性时，会自动打开一个AWS安全事件响应案例（见图4），并通知您之前配置的事件响应团队。一个核心好处是服务如何关联不同的事件——将实例创建与安全组修改连接起来——以描绘出潜在安全事件的完整画面。
图4：自动化事件修复流程
这种主动监控和分析，如您的月度服务报告中所记录，通过减少警报疲劳和为SOC团队提供智能分类能力，展示了切实的好处。服务的自动化分析和关联能力为安全事件发生时的快速响应奠定了基础，这意味着您的团队可以专注于战略安全计划，而不是花费时间手动调查警报。该服务功能通过两种方式帮助您保持强大的安全性：
- 跨配置区域的全面监控。
- 与第三方安全工具的集成。这种自动化方法减少了安全事件的时间、成本和影响。
随着调查从初始检测进展到详细分析，GuardDuty集成为威胁模式提供了关键见解。
从检测到行动：GuardDuty集成故事
当您的安全团队响应内部检测机制时，AWS安全事件响应以三个关键步骤处理安全发现：
- 分析GuardDuty警报以识别真正的安全威胁
- 使用GuardDuty扩展威胁检测，关联相关事件以识别威胁模式
- 跟踪威胁序列，从初始操作（删除日志或创建未经授权的访问）到潜在的数据盗窃尝试
对于此事件，序列以删除CloudTrail日志开始，随后创建未经授权的访问密钥。随着威胁的进展，服务识别了可疑的Amazon Simple Storage Service（Amazon S3）对象访问模式和潜在的数据外泄尝试，以及复杂的规避技术和持久性机制。这些信号中的每一个都直接映射到特定的MITRE ATT&CK®战术、技术和程序（TTP），揭示了潜在勒索软件威胁的系统性性质。有关AWS安全事件响应发现与MITRE ATT&CK®框架的详细映射，请参阅将AWS安全服务映射到MITRE框架以进行威胁检测和缓解。
服务协助关联和分析，评估诸如删除CloudTrail跟踪、创建新访问密钥以及针对S3对象的可疑操作等模式。当GuardDuty的AI和机器学习（AI/ML）能力在一段时间内检测到这些令人担忧的模式时，服务会自动通过创建AWS安全事件响应案例来升级情况，为您带来额外的资源和集中关注。在早期步骤中定义的事件响应团队随后通过电子邮件或其他方法（如图5所示）收到通知，告知已创建新的分类事件并开始他们的调查。
好处包括服务协调跨您受影响账户的通信。而不是处理多个警报并试图拼凑潜在勒索软件事件的范围，GuardDuty扩展威胁检测提供了威胁序列的全面视图，而AWS安全事件响应案例提供了一个单一、连贯的通道来分类这些信号，并在您的全球团队上线加入响应努力时提供协调。
图5：事件警报消息
其他示例和进一步信息可在《介绍Amazon GuardDuty扩展威胁检测：AI/ML攻击序列识别以增强云安全》中找到。
注意：为简洁起见，省略了Security Hub的工作流细节，因为它们反映了上述GuardDuty的监控和升级过程。两种服务紧密集成并共享类似的操作模式，GuardDuty发现在检测后五分钟内发送到Security Hub。Security Hub通过聚合来自多个AWS服务和第三方合作伙伴的发现来增强安全覆盖范围。
随着威胁模式的识别，您的团队进入下一阶段——与AWS CIRT合作以获得专业知识和高级调查能力。
通过事件响应案例与AWS CIRT合作
您的团队继续调查事件并发现他们需要额外的帮助。您账户中的授权用户打开一个服务支持的案例以请求AWS的帮助。
AWS安全事件响应案例建立了与AWS CIRT的直接通信通道（如图6所示），通过控制台中的一键升级案例，提供即时访问专业知识。 upon case escalation, AWS CIRT通过事件响应案例参与，具有15分钟的确认时间范围，带来他们的高级工具和专门知识来分析您账户中的模式——即使在日志能力有限的环境中。这种合作提供：
- 通过会议桥视频通话进行实时协作
- 高级工件分析和模式识别
- 调查和遏制的技术指导
- 改进安全态势的建议
图6：连接AWS CIRT
图6是这在您账户中如何显示的示例，解析器设置为Self用于自我管理的案例。
回到场景，您发现多个账户启用的日志不足——这限制了可用的调查数据。虽然AWS CIRT可以通过专门工具提供额外的见解，但在您的账户中保持全面日志记录对于安全可见性、合规要求和彻底的事件调查仍然至关重要。AWS CIRT的能力补充——但不取代——适当的日志记录实践。这种能力提供了对事件范围的理解，因为他们看到了否则对您不可见的模式和活动。
协作开始于AWS CIRT使用他们的工具分析您的环境，寻找超出您立即日志中看到的异常模式。通过事件响应案例，他们通过以下方式帮助您理解您的情况范围：
- 沟通他们的发现
- 推荐额外的调查路径
- 分享显示来自其他环境的类似EC2实例创建模式的分析
AWS CIRT使用事件响应案例建立桥接呼叫，将他们的团队和您的团队聚集在一起进行实时协作。在这些呼叫期间，AWS CIRT分享他们对工件和服务数据的持续分析，帮助您理解发生了什么、为什么发生以及如何预防类似问题在未来发生。他们还提供关于在您的账户中实施适当日志记录以改善您未来安全态势的指导。
通过智能标记管理事件
当AWS CIRT开始他们的分析时，您的团队使用事件案例ID实施实时资源标记。这种系统化的标记方法被证明对于跨账户跟踪和管理可疑EC2实例至关重要。通过使用标记，您可以快速实施隔离策略并跟踪成本，同时在调查过程中保持受影响资源的清晰文档。
您的基于标记的方法帮助跟踪受影响资源以实施隔离策略。您使用事件案例ID标记快速识别与事件相关的资源，您用它来应用有针对性的访问控制和遏制措施。标记还帮助您跟踪与事件相关的成本，为您的财务团队提供事件财务影响的精确可见性。
与AWS安全事件响应服务一起工作，您发现使用事件案例ID作为您的主要标记键（如图7所示）创建了一种一致的方法来关联跨受影响账户的资源。这在与AWS CIRT协调时特别有帮助，因为您可以快速引导他们到需要调查的特定资源。即使在遏制之后，这些标记继续在支持您的事件后分析和帮助您基于从事件中学到的东西实施有针对性的安全控制方面提供价值。
图7：事件标记
通过Systems Manager集成的自动化遏制选项
在与AWS CIRT合作理解事件范围的同时，您还可以使用Systems Manager帮助自动遏制威胁。您的团队之前已在您的组织中部署了所需的CloudFormation StackSets，通过Systems Manager启用Amazon EC2遏制操作。
设置过程需要在您的账户中部署具有特定IAM角色和Systems Manager配置的CloudFormation StackSets。这种基础设施允许AWS安全事件响应服务代表您进行遏制操作。这些操作如果需要可以逆转——类似于使用撤销功能——这样您可以将系统恢复到之前的状态。
当通过您预部署的CloudFormation StackSets授权时，AWS安全事件响应服务可以请求Systems Manager实施遏制措施。遏制操作需要明确的客户授权和适当的IAM权限提前配置。服务通过修改其安全组和网络访问来隔离标记的可疑实例，同时保留其状态以保持取证完整性进行分析。
遏制过程发生在三个步骤中：
- 隔离：从安全组中移除受感染的实例
- 保留：创建受影响系统的备份副本（快照）
- 调查：使用Systems Manager收集系统信息
这些操作如果需要可以逆转，支持对合法工作负载的遏制决策。
自动化能力帮助简化跨多个实例的遏制程序，减少遏制受影响资源所需的时间。服务在事件响应案例中维护每个操作的详细日志，为您的团队提供遏制工作的清晰可见性。
通过这种响应能力，结合AWS CIRT的指导，您可以在几分钟而不是几小时内遏制事件的传播。Systems Manager集成提供了一种可靠的方法来实施遏制操作，同时保留证据用于调查（如图8所示）。
图8：遏制操作的Systems Manager文档
解决和经验教训
随着事件趋向解决，您的团队通过系统化过程来验证遏制、缓解威胁和恢复服务。与AWS CIRT通过AWS安全事件响应案例一起工作，您实施结构化方法以确保受影响资源被保护并且正常操作可以安全恢复。立即解决操作分为三个主要类别：
-
通过Systems Manager验证的遏制确认
- 验证安全组修改已就位
- 确认受影响实例的网络隔离
- 验证自动化遏制操作成功
- 审查Systems Manager日志以完成遏制操作
-
跨受影响资源的威胁缓解验证
- 分析GuardDuty发现以确认没有新的可疑活动
- 审查标记资源以完全遏制
- 验证未经授权的访问尝试终止
- 确认持久性机制移除
- 检查剩余的未经授权的IAM访问
-
服务恢复和访问控制正常化
- 基于验证的基线恢复合法工作负载访问
- 实施更新的安全组配置
- 重置受影响的IAM凭据和访问密钥
- 为验证干净的资源重新建立正常网络连接
- 更新资源标记以反映事件后状态
文档和报告
随着事件达到解决，AWS安全事件响应服务编译全面的事件时间线。这种文档加速了您的报告过程，帮助您快速生成所需的高管、监管机构和网络保险提供商的报告