挑战
安全团队需要高效验证和记录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发现状态
- 自动验证
- 状态更新
证据收集和审计跟踪
解决方案自动为每个验证活动捕获全面的证据。主要特性包括：
- 四表设计：单独的表用于控制、发现、历史和证据
- 详细证据：每个验证存储基于其类型的特定证据
- 不可变记录：每个证据包括时间戳、验证上下文和结果
- 历史跟踪：维护每个验证尝试的完整历史
部署和配置
使用提供的脚本部署解决方案：
git clone https://github.com/aws-samples/sample-automated-securityhub-validator.git
cd automated-securityhub-validator
cd scripts
./create-roles-quotas-check.sh
假设安全团队角色：
aws sts assume-role --role-arn arn:aws:iam::ACCOUNT_ID:role/securityhub-validator-SecurityTeamRole --role-session-name SecurityTeamSession
部署解决方案：
cd scripts
./deploy.sh
添加补偿控制：
cd scripts
./add-controls-role-based.sh
测试解决方案
测试GuardDuty发现的补偿控制验证示例场景：
- 安全团队使用add-controls-role-based.sh实用程序为GuardDuty.1发现类型创建补偿控制
- 开发人员实施所需控制（启用VPC流日志、创建CloudWatch警报）
- 开发人员将Security Hub发现状态更改为SUPPRESSED
- 自动验证过程开始
- 查看Lambda函数日志和Security Hub发现注释中的验证结果
清理
为避免持续费用，使用以下命令清理资源：
./cleanup.sh
结论
本文展示了安全团队如何实施解决方案来定义AWS Security Hub发现的补偿控制并自动验证其实施。该解决方案提供了结构化工作流程，安全团队在其中定义可接受的补偿控制，开发人员实施这些控制，自动化系统验证其有效性。
通过支持13种不同的验证类型，从AWS Config规则到流程文档，该解决方案为各种安全场景提供全面覆盖。
更多精彩内容 请关注我的个人公众号 公众号（办公AI智能小助手）
对网络安全、黑客技术感兴趣的朋友可以关注我的安全公众号（网络安全技术点滴分享）
公众号二维码
公众号二维码
