利用 Amazon Security Lake 加速事件响应
- 17
使用Amazon Security Lake加速事故响应 第2部分
由Frank Phillis和Jerry Chen于2024年7月29日发布于 高级(300)、 Amazon SecurityLake、安全、身份与合规、技术操作指南永久链接评论 分享
关键要点
在本部分中，我们将展示如何使用Amazon Security Lake作为主要数据源来加速事故响应工作流程。本篇文章是两部分系列的第二部分，其中涵盖了如何有效应对特定安全事件。我们将在此文中详细讨论事故响应的各个阶段，包括侦测和分析，以及隔离、消除和恢复。
文章重点
本文为两部分系列的第二篇文章，内容主要围绕通过Amazon Security Lake来加速事故响应工作流程。我们将复述在不经意的数据访问在Amazon S3中的事故响应剧本中所描述的工作流。前一篇文章已介绍了必要的先决条件和如何设置Security Lake。
概述
图片 1 显示了我们在上一篇文章中配置的服务架构。特别强调的服务Amazon Macie、Amazon GuardDuty、AWS CloudTrail、AWS Security Hub、Amazon Security Lake、Amazon Athena和AWS Organizations与本篇文章的示例相关，特别是涉及NIST SP 80061中定义的事故响应阶段。
第一步骤：准备
NIST SP 80061框架的第一阶段是准备，这是在两部分系列的第一部分中讨论的内容。接下来的部分将介绍第二阶段检测和分析及第三阶段隔离、消除和恢复，并展示Security Lake如何通过提供统一格式的安全日志和发现的中心数据存储来加速事故响应工作流程。
假设您的安全团队通过Amazon GuardDuty和Amazon EventBridge收到了关于异常用户行为的警报。此时团队得知可能出现了不经意的数据访问，GuardDuty发现了IAM用户ServiceBackup的异常活动并生成了相关发现。安全团队通过EventBridge设置的规则接收到有关IAM用户活动的警报邮件。此时，团队尚不确定是否发生了恶意活动，然而用户名却并不熟悉。安全团队需要进一步调查，以确定该发现是否为误报，并通过查询Security Lake中的数据来验证。
第二阶段：获取、保留和记录证据
安全团队想调查这一陌生用户进行了哪些API调用。首先，团队检查AWS CloudTrail中该用户的管理活动，并使用Security Lake来实现这一查询。他们希望获得该用户活动的清单，以使他们可以从多个方面获取信息：
列出这些API调用中那些值得进一步调查的尤其是Create相关的调用确定该活动是否异常与帐户、团队、用户组或个人用户的“典型”活动相比确定潜在恶意活动可能开始的时间用户历史团队可以使用Amazon Athena查询CloudTrail中由Security Lake捕获的管理事件。在某些情况下，已被攻陷的用户账户可能在之前作为合法用户存在很长时间，并进行数万次API调用。在这种情况下，安全团队如何识别可能需要进一步调查的调用呢？一种快速的方法是运行如下查询：
sqlSELECT DISTINCT apioperation FROM amazonsecuritylaketableuswest2cloudtrailmgmt20 WHERE lower(actorusername) = servicebackup
上述查询的结果可帮助团队确定关注的关键信息及查询方向。团队首先使用此查询列出用户进行的API调用的数量和类型，如图2所示。
图2显示初步查询的结果，表明可能存在特权提升的API调用如创建用户、附加用户策略等。还有其他API调用显示可能创建了更多资源，例如Amazon S3存储桶和Amazon EC2实例。
注意，此时团队并未时间限制该查询。但如果他们对聚焦某个特定时间或日期范围有较高的信心，查询可以进一步修改。团队可以参考从EventBridge接收到的警报邮件中有关GuardDuty发现的时间信息。
团队现在希望更详细地查看用户的活动。为此，他们可以使用返回每个API调用更具体信息的查询：
sqlSELECT timedt AS Time Date metadataproductname AS Log Source cloudregion actorusertype actorusername actoruseraccountuid AS User AWS Acc ID apioperation AS API Operation status AS API Response apiservicename AS Service apirequestdata AS Request Data FROM amazonsecuritylaketableuswest2cloudtrailmgmt20 WHERE lower(actorusername) = servicebackup
图3显示了查询结果。团队发现该用户创建了一个S3存储桶并进行了其他管理操作，包括创建IAM用户并为新创建的用户附加管理员访问策略。虽然尝试创建其他资源如Amazon EC2实例未成功，但团队需要对新创建的IAM用户和S3存储桶进行进一步调查。
团队开始关注调查ServiceBackup用户的IAM权限，因为该用户创建的某些资源可能导致特权提升例如：CreateUser gtgt AttachPolicy gtgt CreateAccessKey。团队确认附加到该新用户的策略为AdminAccess，因此对该新用户的活动进行调查变得至关重要。现在，凭借对该用户活动及其发生时间的初步了解，安全团队希望聚焦IAM活动，以便确认其所创建的资源。
团队可以使用如下查询来寻找用户创建、修改或删除的资源详情。在这种情况下，用户也创建了其他IAM用户和角色。团队利用时间戳来限制查询结果，使其仅限于他们认为可疑活动发生的特定时间范围。
sqlSELECT timedt AS Time cloudregion AS Region actorsessionissuer AS Role Issuer actorusername AS User Name apioperation AS API Call jsonextract(apirequestdata userName) AS Target Principal jsonextract(apirequestdata policyArn) AS Target Policy jsonextract(apirequestdata roleName) AS Target Role actoruseruid AS User ID username AS Target Principal status AS Response Status accountid AS AWS AccountFROM amazonsecuritylaketableuswest2cloudtrailmgmt20 WHERE (lower(apioperation) LIKE create OR lower(apioperation) LIKE attach OR lower(apioperation) LIKE delete) AND lower(apiservicename) = iamamazonawscom AND lower(actorusername) = servicebackup AND timedt BETWEEN TIMESTAMP 20240301 000000000 AND TIMESTAMP 20240531 235900000
此附加细节帮助安全团队聚焦于ServiceBackup用户创建的资源。这些资源将需要进行进一步调查，并可能需要被隔离。如果需要进一步分析，可以禁用这些资源，或在某些情况下，将其复制到法医帐户中进行分析。
在识别出需要进一步调查的新创建IAM资源后，团队现在继续关注在S3中创建的资源。ServiceBackup用户是否在该存储桶中放入对象？他们是否与其他存储桶中的对象进行了交互？为此，团队通过Athena查询S3数据事件，如下所示：
sqlSELECT timedt AS Time Date cloudregion AS Region actorusertype actorusername AS User Name apioperation AS API Call status AS Status apirequestdata AS Request Data accountid AS AWS Account ID FROM amazonsecuritylaketableuswest2s3data20 WHERE lower(actorusername) = servicebackup
安全团队发现ServiceBackup用户创建了一个名为breachnotify的S3存储桶，并在该存储桶中上传了名为datalockedxxxtxt的文件存储桶名称也在图3的查询结果中返回。另外，他们还观察到有Potentially Sensitive Data可能是敏感数据的GetObject API调用，随后是相同数据和其他潜在敏感数据文件的DeleteObject API调用。这些是一些CSV文件，例如ccdata2csv， 如图5所示。
现在，安全团队有两个重要目标：
保护和恢复其数据和资源确保所有依赖于这些资源或数据的应用程序可用并为客户服务安全团队知道他们的S3存储桶确实包含敏感数据，他们需要快速了解哪些文件可能对威胁行为者有价值。通过快速调查S3数据日志并确定文件确实已被下载和删除，他们已经获得了可操作的信息。为了进一步丰富此信息，团队需要验证这些文件是否包含敏感数据。Amazon Macie可以配置为检测S3存储桶中的敏感数据，并与Security Hub原生集成。团队已配置Macie扫描他们的存储桶，并在发现潜在敏感数据时发出警报。团队可以继续使用Athena查询存储在Security Lake中的Security Hub数据，以观察Macie结果是否与这些文件或存储桶相关。团队希望查找在breachnotify S3存储桶创建时生成的发现，使用如下Athena查询：
sqlSELECT timedt AS Date/Time metadataproductname AS Log Source cloudaccountuid AS AWS Account ID cloudregion AS AWS Region resources[1]type AS Resource Type resources[1]uid AS Bucket ARN resources[2]type AS Resource Type 2 resources[2]uid AS Object Name findinginfodesc AS Finding summary FROM amazonsecuritylaketableuswest2shfindings20 WHERE cloudaccountuid = ltYOURAWSACCOUNTIDgt AND lower(metadataproductname) = macie AND timedt BETWEEN TIMESTAMP 20240310 000000000 AND TIMESTAMP 20240314 235900000
如图6所示，团队使用前述查询提取了所需的信息，以帮助他们理解存储桶中是否可能含有敏感信息、哪些文件包含该信息以及信息的种类。从这些结果来看，列表中的文件确实包含敏感信息，似乎与信用卡相关。
是时候停下来简单回顾一下团队现在所知的内容，以及仍需完成的任务。团队确认ServiceBackup用户创建了额外的IAM用户并为这些用户分配了广泛的权限。他们还发现ServiceBackup用户下载了看似机密的数据，随后将这些文件从客户的存储桶中删除。同时，ServiceBackup用户创建了新的S3存储桶，并在其中存储了赎金文件。此外，该用户还创建了IAM角色并尝试创建EC2实例。在我们的示例场景中，调查的第一部分已经完成。
免费APN加速器关于团队迄今为止在Security Lake中所做的事情，有几点需要注意。首先，由于他们已经在整个组织中设置了Security Lake，团队可以从他们组织中的帐户查询结果，针对各种类型的资源。这本身即可在调查过程中节省大量时间。此外，团队无缝查询了不同的数据集以获得结果到目前为止，他们已经通过Security Lake直接从Athena控制台查询了CloudTrail管理事件、S3数据事件和Macie发现，而无需进行帐户或角色切换和工具切换。
接下来，我们将进入隔离步骤。
第三阶段：隔离、消除和恢复
在前面阶段收集到足够的证据以采取行动后，团队现在需要采取措施来隔离这一事件，并着重使用AWS API，可以通过AWS管理控制台、AWS CLI或其他工具进行操作。为了便于本篇文章，我们将使用CLI工具。
团队需要执行若干操作以隔离事件。他们希望降低进一步数据暴露的风险以及在这些AWS账户中创建、修改或删除资源的风险。首先，他们将禁用ServiceBackup用户的访问，随后调查和评估是否禁用创建该用户的IAM主体的访问。此外，由于ServiceBackup用户创建了其他IAM用户，因此也必须使用之前概述的相同过程调查这些用户。
接下来，安全团队需要确定如何恢复已从存储桶中删除的敏感数据。如果存储桶启用了版本控制，则删除对象的操作将导致下一个最新版本成为当前版本。此外，如果他们使用了AWS Backup来保护其Amazon S3数据，则可以恢复最近备份的版本。值得注意的是，可能还有其他方法来恢复该数据，比如组织可能已为S3存储桶配置crossRegion复制或其他方法来保护其数据。
完成帮助防止受影响的IAM用户进一步访问的步骤后，并恢复相关数据后，团队现在将注意力转向已被禁用用户创建的额外资源。由于这些资源包括IAM资源，团队需要列出已创建和删除的内容。虽然他们可以从前面的查询中查看到这些信息，但现在决定使用以下查询来专注于IAM资源：
sqlSELECT timedt AS Time cloudregion AS Region actorsessionissuer AS Role Issuer actor