Security Hub CSPM自动化规则迁移到Security Hub
AWS Security Hub的全新版本现已全面推出，具备跨亚马逊云科技账户聚合、关联和情境化安全警报的新功能。之前的版本现在称为 AWS Security Hub CSPM，并将继续作为一个专注于云安全态势管理和发现聚合的独特服务提供。
这两个服务都提供的一项功能是自动化规则。在 Security Hub 和 Security Hub CSPM 中，您都可以使用自动化规则在满足其定义的条件时自动更新发现结果字段。在 Security Hub 中，自动化规则可用于将发现结果发送到第三方平台以进行运营响应。许多现有的 Security Hub CSPM 用户已经建立了自动化规则，用于执行诸如提升影响生产资源的发现结果严重性、或添加注释以协助修复工作流等任务。虽然这两个服务提供相似的自动化规则功能，但规则在两个服务之间并不同步。如果您是现有的 Security Hub CSPM 客户并希望采用新的 Security Hub，您可能希望迁移已构建的自动化规则。这有助于让您的自动化规则处理更贴近您审查发现结果的位置。
本文提供了一个解决方案，用于自动将自动化规则从 Security Hub CSPM 迁移到 Security Hub，帮助您在利用新的 Security Hub 功能的同时，保持安全自动化工作流。
自动化规则迁移挑战
Security Hub CSPM 使用 AWS 安全发现格式（ASFF）作为其发现结果的架构。该架构是自动化规则如何应用于生成发现结果的基础。自动化规则首先定义一个或多个条件，然后选择一个或多个将在满足指定条件时应用的操作。每个条件都指定一个 ASFF 字段、一个操作符（例如等于或包含）和一个值。然后，操作更新一个或多个 ASFF 字段。
新版本的 Security Hub 使用开放网络安全架构框架（OCSF），这是一个广泛采用的开源架构，受到 AWS 和网络安全行业合作伙伴的支持。Security Hub 自动化规则在结构上与 Security Hub CSPM 规则相同。但是，底层架构的变更意味着现有的自动化规则需要转换。
本文提供的解决方案自动发现 Security Hub CSPM 自动化规则，将其转换为 OCSF 架构，并创建一个 AWS CloudFormation 模板，您可以用它来将它们部署到运行新版本 Security Hub 的 AWS 账户。由于 ASFF 和 OCSF 架构之间的固有差异，有些规则无法自动迁移，而其他规则在迁移后可能需要手动审查。
下表显示了当前支持作为条件的 ASFF 字段及其对应的 OCSF 字段之间的映射。这些映射可能会在未来的服务版本中发生变化。标记为 N/A 的字段无法迁移，在迁移自动化规则时需要特别考虑。它们需要在新的 Security Hub 中重新设计。本文提供的解决方案旨在跳过迁移那些包含一个或多个无法映射到 OCSF 字段的 ASFF 条件的规则，但会在报告中标识这些规则以供您审查。
| ASFF中的规则条件 | 对应的OCSF字段 |
|---|---|
| AwsAccountId | cloud.account.uid |
| AwsAccountName | cloud.account.name |
| CompanyName | metadata.product.vendor_name |
| ComplianceAssociatedStandardsId | compliance.standards |
| ComplianceSecurityControlId | compliance.control |
| ComplianceStatus | compliance.status |
| Confidence | confidence_score |
| CreatedAt | finding_info.created_time |
| Criticality | N/A |
| Description | finding_info.desc |
| FirstObservedAt | finding_info.first_seen_time |
| GeneratorId | N/A |
| Id | finding_info.uid |
| LastObservedAt | finding_info.last_seen_time |
| NoteText | comment |
| NoteUpdatedAt | N/A |
| NoteUpdatedBy | N/A |
| ProductArn | metadata.product.uid |
| ProductName | metadata.product.name |
| RecordState | activity_name |
| RelatedFindingsId | N/A |
| RelatedFindingsProductArn | N/A |
| ResourceApplicationArn | N/A |
| ResourceApplicationName | N/A |
| ResourceDetailsOther | N/A |
| ResourceId | resources[x].uid |
| ResourcePartition | resources[x].cloud_partition |
| ResourceRegion | resources[x].region |
| ResourceTags | resources[x].tags |
| ResourceType | resources[x].type |
| SeverityLabel | vendor_attributes.severity |
| SourceUrl | finding_info.src_url |
| Title | finding_info.title |
| Type | finding_info.types |
| UpdatedAt | finding_info.modified_time |
| UserDefinedFields | N/A |
| VerificationState | N/A |
| WorkflowStatus | status |
下表显示了支持作为操作的 ASFF 字段及其对应的 OCSF 字段。请注意，有几个操作字段在 OCSF 中不可用：
| ASFF中的规则操作字段 | 对应的OCSF字段 |
|---|---|
| Confidence | N/A |
| Criticality | N/A |
| Note | Comment |
| RelatedFindings | N/A |
| Severity | Severity |
| Types | N/A |
| UserDefinedFields | N/A |
| VerificationState | N/A |
| Workflow Status | Status |
对于包含没有 OCSF 等价项的操作的 Security Hub CSPM 自动化规则，该解决方案旨在迁移规则，但仅包含受支持的操作。这些规则将在规则描述和迁移报告中被指定为部分迁移。您可以使用此信息在启用规则之前审查和修改规则，有助于确保新的自动化规则按预期运行。
解决方案概述
此解决方案提供了一组 Python 脚本，旨在帮助将自动化规则从 Security Hub CSPM 迁移到新的 Security Hub。迁移过程如下：
- 开始迁移：解决方案提供了一个编排脚本，用于启动三个子脚本并管理向它们传递适当的输入。
- 发现：该解决方案扫描您的 Security Hub CSPM 环境，以识别和收集指定 AWS 区域中现有的自动化规则。
- 分析：根据 ASFF 到 OCSF 字段映射的兼容性，对每个规则进行评估，以确定其是否可以完全迁移、部分迁移或需要手动干预。
- 转换：使用预定义的字段映射，将兼容的规则自动从 ASFF 架构转换为 OCSF 架构。
- 模板创建：该解决方案生成一个包含转换后规则的 CloudFormation 模板，保持其原始顺序和区域上下文。
- 部署：审查生成的模板并将其部署到 Security Hub 中以创建迁移的规则，默认情况下这些规则处于禁用状态。
- 验证和启用规则：在 AWS 管理控制台的 Security Hub 中审查每个迁移的规则，验证其条件、操作，并在适用的情况下预览当前匹配的发现结果。确认规则单独和作为一个序列都能按预期工作后，启用它们以恢复您的自动化工作流。
该解决方案包括四个协同工作的 Python 脚本来迁移您的自动化规则：
- 编排器：协调发现、转换和生成，以及报告和日志记录
- 规则发现：从您指定的区域中的 Security Hub CSPM 识别和提取现有的自动化规则
- 架构转换：使用前面详述的字段映射将规则从 ASFF 格式转换为 OCSF 格式
- 模板生成：创建 CloudFormation 模板，您可以用它来部署迁移的规则
这些脚本使用通过 AWS 命令行界面（AWS CLI）配置的凭据来发现现有的 Security Hub 自动化规则。
先决条件
在运行解决方案之前，请确保已准备好以下组件和权限。
所需软件：
- AWS CLI（最新版本）
- Python 3.12 或更高版本
- Python 包：
- boto3（最新版本）
- pyyaml（最新版本）
所需权限：
用于规则发现和转换：
- securityhub:ListAutomationRules
- securityhub:BatchGetAutomationRules
- securityhub:GetFindingAggregator
- securityhub:DescribeHub
- securityhub:ListAutomationRulesV2
用于模板部署：
- cloudformation:CreateStack
- cloudformation:UpdateStack
- cloudformation:DescribeStacks
- cloudformation:CreateChangeSet
- cloudformation:DescribeChangeSet
- cloudformation:ExecuteChangeSet
- cloudformation:GetTemplateSummary
- securityhub:CreateAutomationRuleV2
- securityhub:UpdateAutomationRuleV2
- securityhub:DeleteAutomationRuleV2
- securityhub:GetAutomationRuleV2
- securityhub:TagResource
- securityhub:ListTagsForResource
AWS 账户配置
当与 AWS Organizations 一起使用时，Security Hub 支持委托管理员账户模型。此委托管理员账户集中管理您组织的成员账户中的安全发现结果和服务配置。自动化规则必须在委托管理员账户的主区域以及未链接的区域中创建。成员账户无法创建自己的自动化规则。
我们建议对 Security Hub CSPM 和 Security Hub 使用相同的账户作为委托管理员，以保持安全管理的一致性。在运行迁移解决方案之前，请为这个委托管理员账户配置您的 AWS CLI 凭据。
虽然此解决方案主要设计用于委托管理员部署，但它也支持单账户 Security Hub 实现。
关键迁移概念
在继续将自动化规则从 Security Hub CSPM 迁移到 Security Hub 之前，了解几个影响规则迁移和部署方式的关键概念非常重要。这些概念会影响迁移过程以及规则的最终行为。理解它们将有助于您规划迁移策略并有效验证结果。
默认规则状态
默认情况下，迁移的规则以 DISABLED（禁用）状态创建，这意味着操作不会应用于生成的发现结果。解决方案可以选择以 ENABLED（启用）状态创建规则，但不推荐这样做。相反，应以 DISABLED 状态创建规则，审查每个规则，预览匹配的发现结果，然后在准备好时将规则移动到 ENABLED 状态。
不支持的字段
迁移报告详细说明了任何无法迁移的规则，因为它们包含一个新的或多个不被新 Security Hub 支持的 Security Hub CSPM 条件。这些情况的发生是由于 ASFF 和 OCSF 架构之间的差异。这些规则需要特别关注，因为它们无法以等效的行为自动复制。如果您有依赖于优先级顺序的 Security Hub CSPM 规则，这一点尤其重要。
当规则具有不受支持的操作时，如果至少有一个操作受支持，它们仍将被迁移。具有部分支持操作的规则将在迁移报告和新的自动化规则描述中被标记，并应进行审查。
主区域和链接区域
Security Hub CSPM 和 Security Hub 都支持一个聚合来自链接区域的发现结果的主区域。但是，它们的自动化规则行为不同。Security Hub CSPM 自动化规则在区域基础上运行。这意味着它们只影响创建它们的区域中生成的发现结果。即使您使用主区域，Security Hub CSPM 自动化规则也不适用于主区域中从链接区域聚合的发现结果。Security Hub 支持在主区域中定义并应用于所有链接区域的自动化规则，并且不支持在链接区域中创建自动化规则。但是，在 Security Hub 中，未链接的区域仍然可以有自己的自动化规则，这些规则将仅影响在该区域生成的发现结果。未链接的区域需要单独应用自动化规则。
该解决方案支持两种部署模式来处理这些差异。第一种模式称为主区域模式，适用于启用了主区域的 Security Hub 部署。此模式从指定区域识别 Security Hub CSPM 自动化规则，然后通过添加一个条件来重新创建它们，以说明规则来自的区域。然后，生成一个 CloudFormation 模板，可以部署在主区域。由于为创建规则的原始区域添加了条件，自动化规则仍将按预期运行。
第二种模式称为按区域模式。此模式适用于当前不使用主区域的用户。在此模式下，解决方案仍然发现指定区域中的自动化规则，但为每个区域生成一个唯一的 CloudFormation 模板。然后，可以将生成的模板逐个部署到其对应区域的委托管理员账户。在此模式下，不会向自动化规则添加任何附加条件。
可以为主区域使用一个主区域并链接一些区域，但不是所有区域。如果是这种情况，请为主区域和所有链接区域运行主区域模式。然后，为所有未链接的区域按区域模式重新运行该解决方案。
规则顺序
Security Hub CSPM 和 Security Hub 自动化规则都有其被评估的顺序。这对于某些情况可能很重要，其中不同的自动化规则可能应用于相同的发现结果，或对相同的字段执行操作。此解决方案保留您的自动化规则的原始顺序。
如果存在现有的 Security Hub 自动化规则，该解决方案将在现有规则之后开始创建新的自动化规则。例如，如果您有 3 个 Security Hub 自动化规则，并且正在迁移 10 个新规则，该解决方案将向新规则分配从 4 到 13 的顺序。
使用主区域模式时，每个区域的自动化规则顺序将被保留，并最终在最终顺序中聚集在一起。例如，如果用户在三个不同的区域中各有三个 Security Hub 自动化规则迁移这些规则，它们将按顺序迁移。解决方案将首先以其原始顺序迁移区域 1 的所有规则，然后以其原始顺序迁移区域 2 的所有规则，最后以其原始顺序迁移区域 3 的所有规则。
部署和验证迁移
现在您已具备先决条件并了解了基本概念，可以部署和验证迁移了。
部署迁移：
- 从 AWS 示例 GitHub 仓库克隆 Security Hub 自动化规则迁移工具：
1git clone https://github.com/aws-samples/sample-SecurityHub-Automation-Rule-Migration.git
部署完成后，您可以使用 Security Hub 控制台审查迁移的自动化规则。请记住，规则默认是以 DISABLED 状态创建的。仔细审查每个规则的条件和操作，确保它们符合您预期的自动化工作流。您还可以在控制台中预览哪些现有的发现结果会匹配每个自动化规则。
审查和验证迁移的规则：
- 转到 Security Hub 控制台，并从导航窗格中选择 Automations。
- 选择一个规则，然后选择页面顶部的 Edit。
- 选择 Preview matching findings。即使自动化规则按预期运行，也可能不会返回任何发现结果。这只意味着当前 Security Hub 中没有匹配规则条件的发现结果。在这种情况下，您仍然可以审查规则条件。
- 验证规则配置后，您可以通过控制台从规则编辑页面启用它。您也可以更新 CloudFormation 堆栈。如果您不需要更改自动化规则的任何条件或操作，可以使用可选的
--create-enabled标志重新运行脚本，以使用所有启用的规则重新生成 CloudFormation 模板，并将其作为对现有堆栈的更新进行部署。
注意任何具有部分迁移操作的规则，这将在每个规则的描述中注明。这意味着 Security Hub CSPM 中的原始规则有一个或多个操作在 Security Hub 中不受支持，并且该规则的行为可能与预期不同。该解决方案还会生成一份迁移报告，其中包括哪些规则被部分迁移，并指定原始规则中哪些操作无法迁移。仔细审查这些规则，因为它们的行为可能与预期不同，需要进行修改或重建。
结论
新的 AWS Security Hub 提供了增强的功能，用于聚合、关联和情境化您的安全发现结果。虽然从 ASFF 到 OCSF 的架构变更带来了改进的互操作性和集成选项，但需要迁移现有的自动化规则。本文提供的解决方案通过发现您现有的规则，将其转换为新架构，并生成保留规则顺序和区域上下文的 CloudFormation 模板，帮助自动化此迁移过程。
迁移自动化规则后，首先审查迁移报告以识别任何未完全迁移的规则。特别注意标记为部分迁移的规则，因为它们的行为可能与原始版本不同。我们建议在禁用状态下测试每个规则，并验证规则能否按预期协同工作——尤其是在同一字段上操作的规则——然后再在您的环境中启用它们。