使用AWS Security Hub自动业务上下文验证加速安全发现审查

挑战

安全团队需要高效验证和记录AWS Security Hub发现的异常，同时保持适当的治理。企业安全团队需要确保安全最佳实践的异常得到适当验证和记录，而开发团队需要简化的流程来实施和验证补偿控制。

解决方案先决条件

具有适当服务配额的AWS账户（Amazon DynamoDB、AWS Lambda、Amazon SQS）
必要的IAM权限
AWS CLI版本2.17.44或更高版本
Python版本3.12或更高版本
jq JSON处理工具
目标区域启用的Security Hub
推荐启用AWS Config以增强验证能力

解决方案概述

该解决方案提供示例代码和CloudFormation模板，组织可以部署这些模板来自动验证被抑制Security Hub发现的补偿控制，同时保持安全团队和开发团队之间的适当职责分离。

架构

图1说明了解决方案工作流程：当开发人员将Security Hub发现的工作流状态更改为SUPPRESSED以请求业务合理的安全异常时启动该流程。解决方案将验证结果作为注释添加到相应的Security Hub发现中，维护异常请求和验证结果的完整审计跟踪。

工作流程步骤：

开发人员将Security Hub发现状态更改为SUPPRESSED
EventBridge检测到状态更改为SUPPRESSED
EventBridge规则将事件发送到Amazon SQS队列
Lambda函数从Amazon SQS队列检索消息
Lambda函数从DynamoDB补偿控制表获取补偿控制
Lambda函数使用适当的AWS服务API验证每个控制
为每个验证收集证据并存储在DynamoDB中
发现验证结果和时间戳存储在DynamoDB Findings表中
发现验证尝试的版本历史记录存储在DynamoDB History表中
如果安全团队提供的控制通过验证，发现保持SUPPRESSED，并在相应的Security Hub发现中添加注释；如果控制验证失败，发现状态更改为NOTIFIED

工作原理

该解决方案专为组织安全团队部署和管理而设计。只有安全团队应具有部署AWS CloudFormation堆栈、修改Lambda验证代码、添加/修改补偿控制或访问四个DynamoDB表的权限。

安全团队定义控制

安全团队为特定Security Hub发现类型建立补偿控制，并将其存储在DynamoDB表中。

支持13种验证方法：

验证类型	描述	示例用例
CONFIG_RULE	使用AWS Config规则验证	GuardDuty未启用发现：vpc-flow-logs-enabled Config规则确保监控网络流量
API_CALL	使用直接AWS API调用验证	Amazon S3公共访问发现：API调用验证CloudFront分发存在于S3存储桶前
SECURITY_HUB_CONTROL	使用Security Hub控制状态验证	GuardDuty未启用发现：CloudTrail.1控制通过确认全面的API日志记录
CLOUDWATCH	使用CloudWatch警报验证	GuardDuty未启用发现：监控可疑API调用和网络流量模式的警报
CLOUDTRAIL	验证CloudTrail配置	GuardDuty未启用发现：多区域CloudTrail，具有日志验证和CloudWatch集成
SYSTEMS_MANAGER	使用Systems Manager参数验证	GuardDuty未启用发现：确认自定义威胁检测解决方案已启用的参数
PROCESS_CONTROL	验证基于流程的控制	GuardDuty未启用发现：记录网络安全事件的事件响应流程
INSPECTOR	验证Amazon Inspector配置	漏洞发现：Inspector EC2扫描已启用，不允许关键发现
ACCESS_ANALYZER	验证AWS IAM Access Analyzer	IAM权限发现：IAM Access Analyzer已启用，不允许活动发现
MACIE	验证Amazon Macie配置	数据保护发现：Macie已启用，具有敏感数据发现，不允许敏感存储桶
AUDIT_MANAGER	验证AWS Audit Manager框架	合规性发现：自定义安全框架处于活动状态，具有必需的控制集
EVENTBRIDGE	验证EventBridge规则	GuardDuty未启用发现：监控AWS CloudTrail事件并具有Lambda目标的规则
TRUSTED_ADVISOR	验证AWS Trusted Advisor检查	安全最佳实践发现：S3存储桶权限检查通过，零警告或错误资源

开发人员实施控制

当Security Hub发现被抑制时，开发人员必须实施安全团队定义的所需补偿控制。

开发人员与解决方案交互的方式：

查看所需控制
实施补偿控制
更改Security Hub发现状态
自动验证
状态更新

证据收集和审计跟踪

解决方案自动为每个验证活动捕获全面的证据。主要特性包括：

四表设计：单独的表用于控制、发现、历史和证据
详细证据：每个验证存储基于其类型的特定证据
不可变记录：每个证据包括时间戳、验证上下文和结果
历史跟踪：维护每个验证尝试的完整历史

部署和配置

使用提供的脚本部署解决方案：

bash 复制代码

git clone https://github.com/aws-samples/sample-automated-securityhub-validator.git
cd automated-securityhub-validator
cd scripts
./create-roles-quotas-check.sh

假设安全团队角色：

bash 复制代码

aws sts assume-role --role-arn arn:aws:iam::ACCOUNT_ID:role/securityhub-validator-SecurityTeamRole --role-session-name SecurityTeamSession

部署解决方案：

bash 复制代码

cd scripts
./deploy.sh

添加补偿控制：

bash 复制代码

cd scripts
./add-controls-role-based.sh

测试解决方案

测试GuardDuty发现的补偿控制验证示例场景：

安全团队使用add-controls-role-based.sh实用程序为GuardDuty.1发现类型创建补偿控制
开发人员实施所需控制（启用VPC流日志、创建CloudWatch警报）
开发人员将Security Hub发现状态更改为SUPPRESSED
自动验证过程开始
查看Lambda函数日志和Security Hub发现注释中的验证结果

清理

为避免持续费用，使用以下命令清理资源：

bash 复制代码

./cleanup.sh

结论

本文展示了安全团队如何实施解决方案来定义AWS Security Hub发现的补偿控制并自动验证其实施。该解决方案提供了结构化工作流程，安全团队在其中定义可接受的补偿控制，开发人员实施这些控制，自动化系统验证其有效性。

通过支持13种不同的验证类型，从AWS Config规则到流程文档，该解决方案为各种安全场景提供全面覆盖。