本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。

# 对安全调查发现进行分类和修复的示例
<a name="triage-remediation-examples"></a>

本节提供安全、云和应用程序团队的分类流程示例。本节介绍每个团队通常处理的调查发现类型，并提供了如何应对的示例。还包括高级修复指导。

**Topics**
+ [安全团队示例：创建 Security Hub CSPM 自动化规则](security-team-example.md)
+ [云团队示例：更改 VPC 配置](cloud-team-example.md)
+ [应用程序团队示例：创建 AWS Config 规则](application-team-example.md)

# 安全团队示例：创建 Security Hub CSPM 自动化规则
<a name="security-team-example"></a>

安全团队会收到与威胁检测相关的发现，包括 Amazon 的 GuardDuty 发现。有关按 AWS 资源类型分类的 GuardDuty 查找类型的完整列表，请参阅 GuardDuty 文档中的[查找类型](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-active.html)。安全团队必须熟悉所有这些调查发现类型。

在此示例中，安全团队接受安全发现的相关风险级别 AWS 账户 ，该级别仅用于学习目的，不包括重要或敏感数据。此账户的名称为 `sandbox`，账户 ID 为 `123456789012`。安全团队可以创建 AWS Security Hub CSPM 自动化规则，禁止从该账户中 GuardDuty发现的所有结果。其可以根据涵盖许多常见使用案例的模板创建规则，也可以创建自定义规则。在 Security Hub CSPM 中，我们建议预览标准的结果，以确认该规则是否返回了预期的结果。

**注意**  
此示例重点介绍自动化规则的功能。我们不建议隐瞒账户的所有搜索 GuardDuty 结果。上下文至关重要，每个组织都必须根据数据类型、分类和缓解控制措施来选择要抑制哪些调查发现。

以下是用于创建此自动化规则的参数：
+ **规则：**
  + **规则名称**为 `Suppress findings from Sandbox account`
  + **规则描述**为 `Date: 06/25/23 Authored by: John Doe Reason: Suppress GuardDuty findings from the sandbox account`
+ **标准：**
  + `AwsAccountId` = `123456789012`
  + `ProductName` = `GuardDuty`
  + `WorkflowStatus` = `NEW`
  + `RecordState` = `ACTIVE`
+ **自动化操作：**
  + `Workflow.status` 是 `SUPPRESSED`

有关更多信息，请参阅 Security Hub CSPM 文档中的[自动化规则](https://docs.aws.amazon.com/securityhub/latest/userguide/automation-rules.html)。安全团队有多种方法可用于调查和修复检测到威胁的调查发现。如需详细指导，请参阅《AWS 安全事件响应指南》[https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html](https://docs.aws.amazon.com/whitepapers/latest/aws-security-incident-response-guide/aws-security-incident-response-guide.html)。我们建议您查看该指南，以确认您已建立强大的事件响应流程。

# 云团队示例：更改 VPC 配置
<a name="cloud-team-example"></a>

云团队负责对具有共同趋势的安全发现进行分类和修复，例如对可能不适合您的用例的 AWS 默认设置的更改。这些发现往往会影响许多 AWS 账户 资源，例如 VPC 配置，或者它们包含应在整个环境中施加的限制。在大多数情况下，云团队会手动进行一次性更改，例如添加或更新策略。

在您的组织使用 AWS 环境一段时间后，您可能会发现一组反模式正在形成。*反模式*是一种用于解决反复出现的问题的常用解决方案，而在这类问题中，此解决方案适得其反、无效或不如替代方案有效。作为这些反模式的替代方案，您的组织可以使用更有效的环境范围限制，例如 AWS Organizations 服务控制策略 (SCPs) 或 IAM Identity Center 权限集。 SCPs 权限集可以为资源类型提供额外的限制，例如禁止用户配置公共的亚马逊简单存储服务 (Amazon S3) 存储桶。尽管限制所有可能的安全配置可能很诱人，但对 SCPs 和权限集都有策略大小限制。我们建议采取平衡的方法进行预防性和侦测性控制。

以下是云团队可能负责 AWS Security Hub CSPM [的基础安全最佳实践 (FSBP)](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html) 标准中的一些控制措施：
+ [[EC2.2] VPC 默认安全组不应允许入站和出站流量](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-2)
+ [[EC2.6] 应全部启用 VPC 流量记录 VPCs](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-6)
+ [[EC2.23] Amazon EC2 传输网关不应自动接受 VPC 连接请求](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-23)
+ [[CloudTrail.1] CloudTrail 应启用并配置至少一条包含读写管理事件的多区域跟踪](https://docs.aws.amazon.com/securityhub/latest/userguide/cloudtrail-controls.html#cloudtrail-1)
+ [AWS Config 应启用 [Config.1]](https://docs.aws.amazon.com/securityhub/latest/userguide/config-controls.html#config-1)

在此示例中，云团队处理 FSBP 控制 EC2.2 的调查发现。此控制措施的[文档](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-2)建议不要使用默认安全组，因为其允许通过默认的入站和出站规则进行广泛的访问。由于无法删除默认安全组，因此建议更改规则设置以限制入站和出站流量。为了有效地解决这个问题，云团队应使用已建立的机制来修改所有人的安全组规则， VPCs 因为每个 VPC 都有这个默认安全组。在大多数情况下，云团队使用 [AWS Control Tower](https://docs.aws.amazon.com/controltower/latest/userguide/what-is-control-tower.html) 自定义或基础设施即代码（IaC）工具（例如 [https://www.terraform.io/](https://www.terraform.io/) 或 [AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)）来管理 VPC 配置。

# 应用程序团队示例：创建 AWS Config 规则
<a name="application-team-example"></a>

以下是应用或开发团队可能负责的 Security Hub CSPM [基础安全最佳实践 (FSBP)](https://docs.aws.amazon.com/securityhub/latest/userguide/fsbp-standard.html) 安全标准中的一些控制措施：
+ [[CloudFront.1] CloudFront 发行版应配置默认根对象](https://docs.aws.amazon.com/securityhub/latest/userguide/cloudfront-controls.html#cloudfront-1)
+ [[EC2.19] 安全组不应允许不受限制地访问高风险端口](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-19)
+ [[CodeBuild.1] CodeBuild GitHub 或者 Bitbucket 源存储库 URLs 应使用 OAuth](https://docs.aws.amazon.com/securityhub/latest/userguide/codebuild-controls.html#codebuild-1)
+ [[ECS.4] ECS 容器应以非特权身份运行](https://docs.aws.amazon.com/securityhub/latest/userguide/ecs-controls.html#ecs-4)
+ [[ELB.1] 应将 Application Load Balancer 配置为将所有 HTTP 请求重定向到 HTTPS](https://docs.aws.amazon.com/securityhub/latest/userguide/elb-controls.html#elb-1)

在此示例中，应用程序团队处理 FSBP 控制 EC2.19 的调查发现。此控件检查风险最高的指定端口是否可以访问安全组的不受限制的传入流量。如果安全组中的任何规则允许来自 `0.0.0.0/0` 或 `::/0` 这些端口的入口流量，则此控制措施失效。此控制措施的[文档](https://docs.aws.amazon.com/securityhub/latest/userguide/ec2-controls.html#ec2-19)建议删除允许此流量的规则。

除了解决单个安全组规则外，这也是一个很好的例子，说明了应该会产生新 AWS Config [规则](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html)的发现。通过使用[主动评估模式](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config-rules.html#aws-config-rules-evaluation-modes)，您可以帮助防止未来部署高风险的安全组规则。主动模式会在部署资源之前对其进行评估，这样您就可以防止资源配置错误及其相关的安全调查发现。在实施新服务或新功能时，应用程序团队可以在主动模式下运行规则，作为持续集成和持续交付（CI/CD）管线的一部分，以识别不合规的资源。下图显示了如何使用主动 AWS Config 规则来确认 AWS CloudFormation 模板中定义的基础架构是否合规。



![\[检查 AWS CloudFormation 模板合规性的主动 AWS Config 规则\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/vulnerability-management/images/cloudformation-config-proactive-workflow.png)


此示例还能带来另一项重要的效率提升。当应用程序团队创建主动 AWS Config 规则时，他们可以在公共代码存储库中共享该规则，以便其他应用程序团队可以使用。

与 Security Hub CSPM 控件关联的每个发现都包含有关该发现的详细信息以及修复问题的说明的链接。尽管云团队可能会遇到需要手动进行一次性修复的调查发现，但我们建议在适用时构建主动检查，以在开发过程中尽早明确问题。