本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 对环境中的安全发现进行分类和修复 AWS 分类和修复 对安全调查发现进行分类包括将调查发现发送给相应的利益相关者，对调查发现进行评测并确定其优先顺序，然后对其进行修复。本节详细介绍了每个步骤，并就可扩展性和效率提供了建议。其还包括一些示例，帮助说明分类与修复流程。 **Topics** + [ # 定义安全调查发现的责任归属 ](define-ownership-of-security-findings.md) + [ # 评测安全调查发现并确定其优先顺序 ](assess-and-prioritize-security-findings.md) + [ # 修复安全调查发现 ](remediate-security-findings.md) + [ # 对安全调查发现进行分类和修复的示例 ](triage-remediation-examples.md) # 定义安全调查发现的责任归属 分配调查发现 定义责任归属模式来对安全调查发现进行分类可能具有挑战性，但并非一定如此。安全格局瞬息万变，从业人员必须灵活地适应这些变化。采用灵活的方法来制定安全调查发现的责任归属模式。您的初始模式应使团队能够立即采取行动。我们建议从基本的责任归属逻辑入手，并随着时间的推移完善该逻辑。如果您因追求完美的责任归属标准而延迟定义，则安全调查发现的数量将持续增加。 为了便于将调查结果分配给适当的团队和资源，我们建议 AWS Security Hub CSPM 与您的团队用来管理其日常任务的任何现有系统集成。例如，您可以将 Security Hub CSPM 与安全信息和事件管理 (SIEM) 系统或产品待办事项和票务系统集成。有关更多信息，请参阅本指南中的[准备分配安全调查发现](prepare-finding-assignments.md)。 以下是可用作起始点的责任归属模式示例： + **安全团队会审查潜在的活跃威胁，帮助评测安全调查发现并确定其优先顺序。**安全团队拥有正确评估背景的专业知识和工具。团队了解其他与安全相关的数据，这些数据可以帮助他们评测漏洞并确定其优先顺序，以及调查威胁检测事件。如果需要调查发现严重性或其他调优，请参阅本指南中的[评测安全调查发现并确定其优先顺序](assess-and-prioritize-security-findings.md)一节。例如，请参阅本指南中的[安全团队示例](security-team-example.md)。 ![\[安全团队通过 SIEM 系统审查 Security Hub CSPM 的调查结果。\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/vulnerability-management/images/security-team-remediation.png) + **在云和应用程序团队之间分配安全调查发现**：如[分配安全责任归属](distribute-ownership.md)一节所述，有权配置资源的团队负责其安全配置。应用程序团队负责与其构建和配置的资源相关的安全调查发现，而云团队则负责与覆盖范围广泛的配置相关的安全调查发现。在大多数情况下，应用团队无权更改范围广泛的配置，例如 AWS Control Tower中的[服务控制策略](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) (SCPs) AWS 服务、与网络相关的 VPC 配置[AWS 和 IAM I](https://aws.amazon.com/iam/identity-center/) dentity Center。 AWS Organizations 对于将应用程序分离到专用账户的多账户环境，您通常可以将账户与安全相关的调查发现集成到应用程序的待办事项或工单系统中。通过该系统，云团队或应用程序团队可以解决该调查发现。有关示例，请参阅本指南中的[云团队示例](cloud-team-example.md)或[应用程序团队示例](application-team-example.md)。 ![\[)：应用程序或云团队通过待办事项修复来自 Security Hub CSPM 的安全发现。\]](http://docs.aws.amazon.com/zh_cn/prescriptive-guidance/latest/vulnerability-management/images/application-team-remediation.png) + **将剩余的、未解决的调查发现分配给云团队**：剩余的调查发现可能与默认设置或覆盖范围广泛的配置有关，云团队可以进行处理。该团队可能拥有最多的历史知识和解决该调查发现所需的权限。总体而言，这通常只是所有调查发现中很小的一部分。 # 评测安全调查发现并确定其优先顺序 评测调查发现并确定其优先顺序 有效漏洞管理计划的一个关键组成部分是能够评测安全调查发现并确定其优先顺序。这需要结合上下文信息、组织历史以及调优检测系统。确定安全调查发现的优先顺序有助于确定响应级别的适当速度。 对于 Amazon Inspector 和 Amazon GuardDuty，调查结果包含严重性标签或分数。 AWS Security Hub CSPM我们建议优先调查Security Hub CSPM中的所有关键和高严重性发现，包括与基础安全最佳实践 (FSBP) 标准、Amazon Inspector 和相关的调查结果。 GuardDuty调查发现严重性标签按以下方式确定评分： + [Amazon Inspector 评分](https://docs.aws.amazon.com/inspector/latest/user/findings-understanding-score.html)是每个调查发现高度情境化的评分。其通过将通用漏洞评分系统（CVSS）基本评分信息与网络可达性结果和可利用性数据关联进行计算。使用此评分，您可以确定调查发现的优先顺序，将重点放在最关键的调查发现和脆弱的资源上。除了评分外，Amazon Inspector 还提供有关[常见漏洞和风险（CVE）](https://www.cve.org/)的增强漏洞情报。这是 Amazon 提供的有关 CVE 的可用情报以及 Recorded Future 和美国网络安全与基础设施安全局（CISA）等行业标准安全情报来源的汇总。例如，Amazon Inspector 可提供用于利用漏洞的已知恶意软件工具包的名称。有关更多信息，请参阅 [Vulnerability Intelligence](https://docs.aws.amazon.com/inspector/latest/user/findings-understanding-score.html#vulnerability-intel)。 + 每个 GuardDuty 发现都有[指定的严重级别和值](https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_findings.html#guardduty_findings-severity)，以反映该发现对您的环境的潜在风险。此级别和值由 AWS 安全工程师确定。例如，`High` 严重性级别表示资源已泄露，并且正在被主动用于未经授权的目的。我们建议您将`High`严重性 GuardDuty 发现作为优先事项，并立即采取补救措施，以防止进一步未经授权的使用。 + Sec [urity Hub CSPM 控制发现的严重](https://docs.aws.amazon.com/securityhub/latest/userguide/securityhub-standards-control-details.html#control-findings-severity)性取决于漏洞利用的难度和入侵的可能性。难度取决于利用弱点执行威胁场景所需的复杂程度。泄露的可能性表明威胁情景导致您的 AWS 服务 或资源中断或泄露的可能性有多大。 要调优调查发现，您可以直接在相应的服务控制台中或使用服务的 API 来抑制或存档特定的调查发现。此外，您还可以使用[自动化](https://docs.aws.amazon.com/securityhub/latest/userguide/automation-rules.html)规则对 Security Hub CSPM 中的搜索结果进行更改。 GuardDuty 而且 Amazon Inspector 的调查结果会自动发送到 Security Hub CSPM。您可以根据定义的标准，使用自动化规则以近实时的方式自动更新（例如更改严重性）或抑制调查发现。在创建自动化规则时，我们建议对规则描述添加上下文，例如创建或修改日期、创建该规则的人员以及需要该规则的原因。这些信息通常有助于将来参考。 # 修复安全调查发现 修复调查发现 在评测调查发现并确定其优先顺序之后，下一步行动是修复调查发现。您可以采取许多不同的措施来修复调查发现。对于软件漏洞，您可以更新操作系统或应用补丁。对于云配置调查发现，您可以更新资源配置。通常，您采取的修复措施可归为以下成果之一： + **手动**修复-**** 您可以手动修复漏洞，例如修改 AWS 资源的属性以启用加密。如果发现来自 Security Hub CSPM 中的托管支票，则该发现包括一个指向手动修复该发现的说明的链接。 + **可重复使用的构件**：您可更新基础设施即代码（IaC）以修复漏洞，并知晓其他人可从类似的解决方案受益。考虑将更新后的 IaC 和解决方案的简要摘要上传到内部共享代码存储库。 + **自动修复**：****通过您创建的机制自动修复漏洞。 + **管线控制**：您在持续集成和持续交付（CI/CD）管线中应用控制措施以防止在存在漏洞时进行部署。 + **可接受的风险**：您不采取任何措施或不实施补偿性控制措施，并且您接受存在漏洞带来的风险。在风险注册表等专用位置跟踪可接受的风险。 + **误报**：您没有采取任何措施，因为您已确定该调查发现并非正确识别的漏洞。 您可以采取的各种措施以及可用于修复漏洞的工具的完整列表不在本指南的讨论范围之内。但是，有一些值得注意的服务和工具可以帮助您大规模修复漏洞，包括： + [Patch Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html) 是一项功能 AWS Systems Manager，它可以自动使用与安全相关的更新和其他类型的更新来修补托管节点。您可以使用 Patch Manager 来应用操作系统和应用程序的补丁。 + [AWS Firewall Manager](https://docs.aws.amazon.com/waf/latest/developerguide/fms-chapter.html)可帮助您在中的账户和应用程序中集中配置和管理防火墙规则 AWS Organizations。随着新应用程序的创建，Firewall Manager 通过强制执行一组通用的安全规则，更轻松地使新的应用程序和资源合规。 + 开@@ [启自动安全响应 AWS](https://aws.amazon.com/solutions/implementations/automated-security-response-on-aws/)是一种与 Security Hub CSPM 配合使用的 AWS 解决方案，可根据行业合规标准和安全威胁最佳实践提供预定义的响应和补救措施。 # 对安全调查发现进行分类和修复的示例 示例 本节提供安全、云和应用程序团队的分类流程示例。本节介绍每个团队通常处理的调查发现类型，并提供了如何应对的示例。还包括高级修复指导。 **Topics** + [ # 安全团队示例：创建 Security Hub CSPM 自动化规则 ](security-team-example.md) + [ # 云团队示例：更改 VPC 配置 ](cloud-team-example.md) + [ # 应用程序团队示例：创建 AWS Config 规则 ](application-team-example.md) # 安全团队示例：创建 Security Hub CSPM 自动化规则 安全团队示例 安全团队会收到与威胁检测相关的发现，包括 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 配置 云团队示例 云团队负责对具有共同趋势的安全发现进行分类和修复，例如对可能不适合您的用例的 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 规则 应用程序团队示例 以下是应用或开发团队可能负责的 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 控件关联的每个发现都包含有关该发现的详细信息以及修复问题的说明的链接。尽管云团队可能会遇到需要手动进行一次性修复的调查发现，但我们建议在适用时构建主动检查，以在开发过程中尽早明确问题。