状况和漏洞管理

利用状况和漏洞管理，组织可以在利用之前系统地识别、评估、确定优先级并修正安全漏洞。 与传统的定期扫描不同，新式云环境需要持续评估、基于风险的优先顺序和自动修正，以解决跨基础结构即代码、容器和无服务器功能的快速预配、配置偏移和动态攻击面。 实施这些功能的组织在快速修正关键暴露的同时维护安全默认环境，而忽视这些控件的组织将面临未检测到的弱点和长时间的暴露窗口。

下面是“状况”和“漏洞管理”安全域的四大核心支柱。

建立安全基线： 在所有云资源中定义和实施安全配置基线，确保环境默认通过配置管理工具、策略强制和基础结构即代码方法进行安全保护，这些方法建立与行业标准和组织要求一致的安全配置。

相关控件：

• PV-1：定义和建立安全配置
• PV-3：定义和建立计算资源的安全配置

监视并强制实施合规性： 通过自动监视和修正功能持续审核并强制实施安全配置检测和修正配置偏移。 通过持续的资产发现和基础结构、平台、应用程序和作系统的漏洞评估来全面了解攻击面，确定需要注意的安全弱点。

相关控件：

• PV-2：审核并强制实施安全配置
• PV-4：审核并强制实施计算资源的安全配置
• PV-5：执行漏洞评估

使用基于风险的优先级进行修正： 将修正工作重点放在对真正构成威胁的漏洞，通过结合攻击可能性评估、主动利用监测、资产关键性和暴露上下文进行基于风险的优先排序。 实现自动修补和漏洞修正过程，优先处理关键风险，同时通过高级测试技术最大程度地减少作中断和验证安全功能。

相关控件：

• PV-5：执行漏洞评估
• PV-6：快速自动修正漏洞
• PV-7：定期开展红队行动

集成开发安全性： 在开发流程和软件供应链保护的早期集成安全验证，以防止生产部署中的漏洞。 实施部署前安全扫描、依赖项漏洞评估和供应链风险管理，防止安全弱点到达生产环境。

有关 Shift-left 安全做法和供应链安全控制的综合指南，包括 CI/CD 管道集成、SBOM 管理、项目签名、依赖项扫描和开发人员安全工作流，请参阅本基准的 DevOps Security （DS） 部分。

PV-1：定义并建立安全配置

安全原则

使用配置管理工具为云中的不同资源类型定义安全配置基线，以便默认建立合规的环境。 利用行业标准、供应商建议和组织要求创建可在资源部署期间自动应用的综合基线。

待缓解风险

如果没有标准化的安全配置基线，云环境就会遭受不一致的安全状况，从而造成可利用的弱点。 缺少安全配置标准会导致：

• 配置偏移漏洞： 在没有安全基线的情况下部署的资源引入了错误配置，包括打开防火墙规则、弱身份验证设置、权限过多以及为攻击者创建入口点时禁用的安全日志记录。
• 安全状况不一致： 部署具有不同安全配置的资源的不同团队会创建不可预知的攻击面，其中某些环境具有强大的保护，而另一些环境仍易受攻击。
• 合规性违规： 法规框架（PCI-DSS、HIPAA、SOC 2）强制实施特定的安全配置缺少基线，从而导致不合规的部署和审核失败。
• 默认配置利用： 云服务通常附带为功能而非安全优化的默认配置，未修改的默认值常常包含攻击者利用的安全弱点。
• 手动配置错误： 团队在手动配置安全设置时会引入人为错误，包括拼写错误、设置遗漏和需求误解，这些都会削弱整体的安全防护能力。
• 弱点的规模放大： 在云环境中，配置弱点会通过自动化在数百或数千个资源中复制，因此单个基线缺陷会影响整个环境。

如果没有安全配置基线，组织将运行反应式安全性，即仅在利用后发现漏洞，而不是通过主动标准进行阻止。

MITRE ATT&CK

• 初始访问（TA0001）：通过攻击面向公众的应用程序（T1190），利用配置错误的服务，这些服务有默认的凭据或网络暴露过多。
• 持久性（TA0003）：创建帐户（T1136），利用基线配置中的弱帐户策略或管理访问控制。
• 防御逃避（TA0005）：削弱防御（T1562），禁用在基线部署中未正确配置或强制执行的安全控制。
• 发现（TA0007）：云基础结构发现（T1580）枚举配置错误的资源，以映射攻击路径并识别高价值目标。

PV-1.1：建立安全配置基线

缺少标准化安全配置的组织会部署具有不一致安全状况的资源，从而在环境中创建漏洞，同时消耗大量作工作量来手动配置每个部署。 配置基线建立可重复的安全标准，防止配置偏移，并确保在所有云资源之间一致保护。 标准化安全配置可加速安全部署，同时减少与配置相关的安全事件和合规性违规。

通过标准化基线建立一致的安全配置：

• 定义安全配置基线： 使用 Microsoft云安全基准 和服务特定的安全建议为每个 Azure 服务建立配置标准。
• 实现 Azure 登陆区域： 使用 Azure 登陆区域 通过预配置的安全设置和治理控制来加速工作负荷部署。
• 使用基础结构即代码模板： 使用 Bicep 模板 和 模板规格 对可重复部署进行编码和部署一致的安全配置。
• 参考体系结构指南： 遵循 Azure Well-Architected Framework 安全支柱，获取体系结构配置指南和最佳做法。

实现示例

金融服务组织在其云基础结构中建立了全面的安全配置基线，支持在线银行应用程序和为 250 万客户提供客户数据处理系统。

挑战： 金融服务组织缺乏跨云基础结构的标准化安全配置，因此由于手动安全配置过程，500 多个 Azure 资源的安全状况与配置相关的安全事件和长时间的环境部署时间不一致。

解决方案方法：

定义全面的安全基线：

1. 创建包含常见资源类型的安全配置标准的模板规格：
   • 为最小特权访问配置的网络安全组的虚拟网络
   • 启用了静态数据加密、禁用了公共访问并配置了日志记录的存储帐户
   • 具有访问策略的密钥保管库，仅限制对已授权应用程序的机密访问
   • 配置了 HTTPS 强制、标识集成和安全标头的应用服务
   • 配置了透明数据加密、已启用审核和防火墙规则的 SQL 数据库
2. 使用 Azure 计算机配置建立计算资源基线：
   • 使用 Azure Machine Configuration 实现 CIS 符合性的 Windows Server 基线配置
   • 通过 Azure Automanage 部署的 Linux 加固基线符合计算机最佳实践
   • 容器映像的安全扫描集成到 Azure 容器注册表中的 Microsoft Defender for Containers 中
   • 使用内置安全策略强制实施 Azure Policy 加载项的 Azure Kubernetes 服务安全基线

实现基础结构即代码部署：

1. 使用 Azure Policy 集成部署 Bicep 模板，确保部署时符合性：
   • 具有内置安全参数的 Bicep 模块（minimumTlsVersion、supportsHttpsTrafficOnly 属性）
   • Azure Policy deployIfNotExists 效果自动启用诊断设置和加密
   • 模板规格说明的版本在 Azure 中进行管理和存储，以便于集中式基线管理
2. 将 Azure DevOps 管道与 Azure 资源管理器部署任务和策略符合性检查配合使用
3. 在合并基线更改之前，实施需要安全团队代码评审的 Azure Repos 分支策略

结果： 组织实现了与安全配置标准的强烈合规性，在所有云基础结构中建立一致的安全态势。 与配置相关的安全事件大幅减少，表明标准化安全配置在防止常见漏洞和配置错误方面的有效性。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5： CM-2、CM-6、CM-6（1）
• PCI-DSS v4： 2.2.1、12.3.1
• CIS 控件 v8.1： 4.1、4.2
• NIST CSF v2.0： PR.IP-1，PR.DS-6
• ISO 27001：2022： A.8.9、A.5.37
• SOC 2： CC6.1、CC6.6

PV-2：审核并强制执行安全配置

Azure Policy： 请参阅 Azure 内置策略定义：PV-2。

安全原则

持续监视和警报定义的配置基线的偏差。 通过自动修复来强制实施所需的配置，如果不符合要求，则拒绝这些配置或自动部署修正配置以维护安全状态。

待缓解风险

配置偏离已建立的安全基线会引入一段时间内累积的漏洞，从而创建扩展的攻击面。 缺乏持续监测和执行：

• 无声变化的配置偏移： 手动更改、紧急修改和增量更新会逐渐削弱安全配置，而不会触发警报，造成表面上看来安全但实际上含有可被利用的漏洞的环境。
• 合规性降级： 最初部署的符合配置的系统因正常作更改而偏离法规要求，从而产生审核发现和认证风险。
• 实施不一致： 应用安全配置的不同团队会手动引入变体和遗漏，从而在整个环境中创建安全弱点。
• 紧急更改异常： 高压情况下可能会导致绕过安全措施，并使临时配置逐渐演变为永久性，从而侵蚀整体安全态势。
• 偏移的规模扩增： 在云环境中，通过自动化，配置更改可以在多个资源之间复制，一个单一的偏移事件可能会同时削弱数百个资源。
• 未检测到的错误配置： 如果不进行自动监视，安全配置在长时间内仍无法检测到，从而为攻击者利用提供了持续的机会。

配置偏移最初将安全环境转换为无法满足安全性和符合性要求的易受攻击的基础结构。

MITRE ATT&CK

• 防御逃避（TA0005）：损害防御（T1562）利用配置偏移来禁用或削弱安全控制。
• 持久性（TA0003）：通过利用偏离安全基线的弱化认证配置来修改身份验证过程（T1556）。
• 发现（TA0007）：云基础结构发现（T1580）通过系统枚举配置弱点来识别配置错误的资源。

PV-2.1：实现持续配置监视

配置漂移是指随着手动更改、紧急修复和未经授权的修改，资源逐渐偏离安全基线，这样就产生了安全漏洞，而传统的定期审核往往在漏洞已被利用时才发现。 持续配置监视提供对配置状态的实时可见性，并自动检测安全控制降级。 自动强制实施可防止配置偏差，同时在所有云资源中保持安全态势一致性。

通过持续监视和执行来维护安全基线合规性：

• 配置持续配置评估： 使用 Microsoft Defender for Cloud 根据安全建议持续评估资源配置，并确定与基线的偏差。
• 实现基于策略的监视： 部署具有审核和强制效果的 Azure Policy ，以监视和控制所有订阅中的资源配置。
• 创建配置偏差警报： 使用 Azure Monitor 在检测到配置偏差时创建警报，从而触发调查和修正工作流。
• 部署预防性控制： 实现 Azure Policy 拒绝影响 ，以防止在资源创建时部署不合规的配置。
• 自动执行配置修正： 使用 Azure Policy deployIfNotExists 效果 自动修正配置偏移，而无需手动干预。

实现示例

医疗保健科技公司跨云基础结构实施了全面的配置监视，支持电子健康记录（EHR）系统和为 150 多家医院提供服务的患者数据分析平台。

挑战： 医疗保健技术公司经历了配置偏移事件，这些事件造成了 HIPAA 合规性风险，在数周内未检测到配置更改，手动修正过程需要数天时间才能纠正超过 150 个医院环境的安全配置冲突。

解决方案方法：

部署持续监视基础结构：

1. 在所有配置了安全策略以进行评估的订阅中启用 Microsoft Defender for Cloud：
   • 存储帐户加密和访问配置
   • 网络安全组规则和网络暴露
   • 标识和访问管理配置符合性
   • 数据库安全配置和访问控制
   • 虚拟机安全基线符合性
2. 配置 Azure Monitor Log Analytics，以检测配置更改的 KQL 查询。
   • AzureActivity 查询监视 NetworkSecurityGroupRuleOperations 以修改防火墙规则
   • 检测 StorageAccountEncryptionDisabled 事件的 AzureDiagnostics 查询
   • 审计日志查询跟踪 Microsoft Entra PIM 角色分配和特权提升
   • PolicyEvents 查询监视策略豁免请求和合规性状态更改

实现策略驱动的强制实施：

1. 为符合 HIPAA HITRUST 9.2 要求部署 Azure Policy 预定义策略：
   • 使用 Microsoft.Compute、Microsoft.Storage、Microsoft.Network 资源提供程序审核效果策略
   • 强制实施的拒绝效果策略适用于 allowedLocations、allowedVirtualMachineSkus 和 deniedResourceTypes
   • DeployIfNotExists 效果策略部署Microsoft Defender for Cloud、诊断设置、加密
2. 使用托管身份分配来配置 Azure Policy 的补救任务：
   • 使用系统分配的托管标识自动完成策略合规性的修复任务
   • 由策略合规状态变化触发的 Azure 自动化脚本集
   • 用于需要多步骤编排的复杂修正的 Azure 逻辑应用工作流

建立警报和响应工作流：

1. 为关键配置更改创建 Azure Monitor 警报规则：
   • 安全控制禁用或策略豁免的即时警报
   • 跨环境配置符合性状态的每日摘要
   • 确定系统配置管理问题的每周趋势分析
2. 将警报与 Azure DevOps 集成，以便进行跟踪和解决：
   • 针对关键的安全配置违规自动创建工作项
   • 根据资源类型和严重性分配给适当的团队
   • SLA 跟踪可确保及时解决配置偏移

结果： 组织的配置监视检测到并修正了可能导致 HIPAA 合规性违规、防止监管处罚和保护患者数据的配置偏移事件。 自动强制在到达生产环境之前阻止了不合规的资源部署，确保安全配置在整个资源生命周期中保持一致。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5： CM-2、CM-3、CM-6、CM-7、CM-7（1）
• PCI-DSS v4： 2.2.2、2.2.7、11.5.1
• CIS 控件 v8.1： 4.1、4.2、4.7
• NIST CSF v2.0： DE.CM-7、PR.IP-1
• ISO 27001：2022： A.8.9、A.8.34
• SOC 2： CC6.1、CC6.6、CC7.1

PV-3：定义和建立计算资源的安全配置

安全原则

为计算资源（包括虚拟机（VM）和容器定义安全配置基线。 默认情况下，使用配置管理工具和预配置的映像建立合规的计算环境，确保在所有计算部署中一致地应用安全强化。

待缓解风险

计算资源（包括虚拟机和容器）通常使用不安全的默认配置进行部署，这些配置会公开组织遭到入侵。 没有安全的计算基线：

• 作系统漏洞： 默认 OS 安装包含不必要的服务、弱身份验证设置和缺少的安全修补程序，这些修补程序为特权升级和横向移动提供攻击途径。
• 容器安全漏洞： 在没有安全强化的情况下生成的容器映像包含易受攻击的基础层、过多的特权和不安全的运行时配置，这些配置可实现容器转义和主机泄露。
• 服务配置弱点： 使用默认配置部署的应用程序和服务通常启用不必要的功能、使用弱凭据和缺少适当的访问控制。
• 持久访问机会： 具有弱安全基线的计算资源为攻击者提供了稳定的立足点，用于维护长期访问和执行侦察。
• 缩放放大： 云自动缩放和业务流程系统跨数百个实例复制不安全的计算配置，从而放大了基线安全漏洞的影响。
• 合规性违规： 法规标准需要计算资源不安全基线的特定安全配置，这会产生明显的合规性差距。

不安全的计算配置为攻击者提供了许多路径，用于在云环境中进行初始访问、特权升级和持久存在。

MITRE ATT&CK

• 初始访问（TA0001）：利用面向公众的应用程序（T1190）以不安全配置的计算资源上运行的服务为目标。
• 执行（TA0002）：使用弱计算安全性执行恶意代码的命令和脚本解释器（T1059）。
• 持久性（TA0003）：创建或修改系统进程（T1543），利用弱计算基线建立持久访问。
• 防御规避（TA0005）：通过禁用安全控制来削弱配置薄弱的计算资源中的防御（T1562）。

PV-3.1：建立计算安全基线

使用默认配置部署的计算资源包含已知的安全漏洞和不必要的服务，攻击者利用这些服务进行初始访问和特权提升，作系统漏洞在云环境中仍存在主要攻击途径。 通过禁用不必要的服务、应用安全配置并在作系统级别强制执行最低特权原则，安全强化可减少攻击面。 强化的计算基线可防止常见的利用技术，同时确保所有计算资源的安全状况一致。

通过标准化基线实现计算安全性强化：

• 应用操作系统安全基线：使用适用于 Windows 和 Linux 操作系统的 Azure 安全基线来强制实施 CIS 基准和 Microsoft 安全建议。
• 创建强化的虚拟机映像： 使用 Azure 映像生成器 创建强化的 VM 映像，该映像在部署前预先应用了安全配置。
• 建立容器安全基线： 使用 Microsoft Defender for Containers 建议应用容器安全标准，以便进行映像强化和运行时保护。

实现示例

一家制造公司跨工业 IoT 基础结构和企业应用程序建立了安全计算基线，支持 50 多个生产设施和供应链管理系统。

挑战： 制造公司面临安全事件，其中计算资源存在严重漏洞，不一致的安全配置导致合规性审核准备时间过长，以及 50 多个地点的生产设施扩展的 VM 部署过程缓慢。

解决方案方法：

建立 VM 安全基线：

1. 通过 Azure 映像生成器和 Azure 计算库创建强化的 VM 映像：
   • 使用 Azure Image Builder 的自定义设置应用 CIS 基准的 Windows Server 2022 映像
   • 使用 Azure 映像生成器 runScripts 进行安全强化的 Ubuntu 22.04 LTS 映像
   • Microsoft Defender for Endpoint 通过映像生成器生成脚本自动载入
   • 跨区域复制的 Azure 计算库版本管理，以实现基线分发
2. 为 OS 级合规性配置 Azure 机器配置：
   • 将 DSC 配置部署到 Windows VM 的 Azure 计算机配置包
   • 强制实施 Linux 安全基线的 Azure 计算机配置自定义策略
   • 通过 Azure Policy 的 deployIfNotExists 强制执行 Azure 磁盘加密的启用
   • 通过 VM 创建策略强制实施的安全启动和 vTPM 要求

部署容器安全基线：

1. 使用 Microsoft Defender for Containers 配置 Azure 容器注册表：
   • 使用集成的 Trivy 扫描程序对 ACR 映像进行漏洞扫描的 Microsoft Defender for Containers
   • 使用 ACR 隔离模式，通过存储库权限来阻止易受攻击的映像拉取。
   • 使用最小的基础镜像和多阶段构建来优化容器构建
   • Azure DevOps 管道检查点在 Defender 检测到关键/高风险的 CVE 时导致失败
2. 实现 Azure Kubernetes 服务安全基线：
   • 使用内置策略定义强制实施 Azure Kubernetes 服务 (AKS) 的 Pod 安全基线的 Azure 策略
   • Azure CNI 与 Calico 网络策略用于命名空间级别的网络隔离
   • Azure Kubernetes Fleet Manager 跨群集部署安全配置
   • AKS 映像清理器根据保留策略自动删除旧映像

使用 Azure Policy 建立映像治理：

1. 部署 Azure Policy 确保容器镜像的合规性：
   • Azure Policy 确保仅将来自 ACR 的映像部署到 AKS 群集
   • 通过 Azure Policy 审核效果强制执行的容器映像标记要求
   • 使用 Azure 容器注册表任务计划的运行进行的自动映像刷新工作流
   • 已认证的 VM 和容器基础映像在 Azure 计算库中的分发集成

结果： 组织的安全计算基线大大减少了涉及计算资源的安全事件，演示标准化安全配置的有效性。 漏洞评估结果显示，严重性和高严重性发现显著减少，减少了生产设施的攻击面和合规性风险。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5： CM-2、CM-6、SC-28、SC-28（1）
• PCI-DSS v4： 2.2.1、2.2.4、2.2.5
• CIS 控件 v8.1：4.1 、4.8、18.3
• NIST CSF v2.0： PR.IP-1, PR.DS-6, PR.PT-3
• ISO 27001：2022： A.8.1、A.8.9、A.8.19
• SOC 2： CC6.1、CC6.6、CC6.7

PV-4：审核并强制实施计算资源的安全配置

Azure Policy： 请参阅 Azure 内置策略定义：PV-4。

安全原则

持续监视和警报计算资源中定义的基线的配置偏差。 通过自动修正强制实施所需的配置，防止不合规配置或自动应用纠正措施来维护安全状况。

待缓解风险

计算资源配置因正常作而偏离安全基线，从而创建随时间累积的漏洞。 缺乏持续监测和执行：

• 关键系统上的配置偏移： 生产系统通过合法更改、紧急修改和增量更新削弱安全态势逐渐偏离安全基线，而不会触发警报。
• 修补管理差距： 缺少安全更新会使计算机资源容易受到利用已知漏洞进行的攻击，而组织却认为它们的软件系统是最新的。
• 服务蔓延漏洞： 在计算资源上安装的新服务和应用程序引入了绕过基线安全控制的安全弱点。
• 容器运行时安全偏差： 容器业务流程平台允许进行运行时修改，从而削弱安全策略并公开底层基础结构。
• 合规性验证差距： 如果没有持续监视，计算资源就不符合定期审核之间的法规要求。

计算资源中的配置偏差为攻击者提供了不断演变的利用机会，因为安全控制会随着时间推移而减弱。

MITRE ATT&CK

• 特权提升（TA0004）：针对配置漂移的系统，利用漏洞进行特权提升（T1068）的攻击。
• 防御逃避（TA0005）：利用削弱安全控制的配置更改来损害防御（T1562）。
• 持久性（TA0003）：修改身份验证过程（T1556）利用身份验证配置偏差来维护持久访问。
• 发现（TA0007）：系统信息发现（T1082）从配置错误的系统收集信息，以识别攻击机会。

PV-4.1：实现计算配置监视

计算资源配置通过修补安装、应用程序更新和管理修改频繁更改，从而为攻击者利用安全控制降级在云环境中建立立足点创造了机会。 用于持续计算的配置监控在攻击者能利用配置漏洞进行权限升级或横向移动之前，能检测到安全漏洞和未经授权的更改。 自动配置评估和修正可维护计算安全状况，同时防止跨虚拟机和容器部署进行配置偏移。

通过持续配置评估和强制实施来维护计算安全性：

• 持续评估计算安全配置： 使用 Microsoft Defender for Cloud 根据行业基准和最佳做法持续评估计算资源安全配置。
• 实施持续的合规性监视： 部署 Azure 计算机配置 ，以便持续监视和自动修正配置偏移。
• 维护所需的配置状态： 使用 Azure Automation State Configuration 跨具有自动更正功能的计算资源维护所需的配置状态。
• 监视配置更改： 实现 更改跟踪和清单 ，以监视跨计算资源的配置更改，并检测未经授权的修改。
• 启用容器安全状况监视： 部署 Microsoft Defender for Containers， 以便跨 AKS 群集和容器注册表进行容器安全状况监视。

实现示例

一家金融技术公司实现了跨交易系统和面向客户的应用程序的全面计算配置监视，支持实时金融交易和敏感的财务数据处理。

挑战： 金融技术公司经历了影响交易系统的配置偏移事件，检测需要数天时间，并手动修正数小时，从而在处理数百万客户的实时财务交易的系统中产生合规性风险和潜在的安全威胁。

解决方案方法：

部署全面的配置监视：

1. 在所有计算资源中启用 Microsoft Defender for Cloud：
   • 根据 CIS 基准持续评估 VM 安全配置
   • Kubernetes 群集的容器安全状况评估
   • 基于风险评估的安全建议优先顺序
   • 与 Microsoft Sentinel 集成，用于集中安全监视
2. 实现 Azure 计算机配置：
   • 适用于 500 多个 VM 的 Windows 和 Linux 基线符合性监视
   • 强制实施金融服务安全要求的自定义策略
   • 常见配置漂移场景的自动修复
   • 为法规审核准备的合规报告

建立自动修正工作流：

1. 配置 Azure Automation State Configuration：
   • 维护交易系统安全要求的 PowerShell DSC 配置
   • 在 5 分钟内自动更正与安全相关的配置偏移
   • 维护期间合法配置变体的异常处理
   • 合规性验证确保修正作成功完成
2. 部署更改跟踪和清单监视：
   • 实时检测未经授权的软件安装
   • 监视安全关键文件和注册表更改
   • 维护时段外配置更改的警报生成
   • 与已批准修改的变更管理流程集成

实现容器安全监视：

1. 启用 Microsoft Defender for Containers 于 AKS 群集：
   • 运行时安全监视，检测可疑容器行为
   • 所有已部署容器映像的映像漏洞评估
   • 针对安全最佳做法的 Kubernetes 群集配置评估
   • 识别异常通信模式的网络流量分析
2. 通过适用于 Kubernetes 的 Azure Policy 强制实施 AKS 安全策略：
   • 强制实施 Pod 安全基线的 Azure Policy 内置定义（无特权容器）
   • 适用于 AKS 并使用 Gatekeeper v3 OPA 约束框架的 Azure Policy 插件
   • Azure CNI 与 Calico 网络策略用于命名空间级别的网络隔离
   • 通过 LimitRange 对象部署容器 CPU/内存限制的 Azure Policy 计划

建立治理和报告：

1. 创建合规性仪表板和报告：
   • 实时查看计算资源符合性状态
   • 确定系统配置管理问题的趋势分析
   • 有关安全状况和改进指标的执行报告
   • 与风险管理框架集成以用于风险量化
2. 实现自动事件响应：
   • 针对严重安全配置冲突的即时警报
   • 自动隔离不符合的资源，等待修正
   • 与 Azure DevOps 集成，以便进行工作项跟踪和解决
   • 事件后分析和基线改进建议

结果： 组织的配置监视检测到并修正了可能导致安全泄露、防止财务损失和数据泄露的配置偏移事件。 在影响生产系统之前，自动执行可防止危险的配置更改，确保整个业务增长中的平台稳定性。

严重性级别

必须具有。

控件映射

• NIST SP 800-53 Rev.5： CM-3、CM-6、CM-6（1）、SI-2、SI-2（2）
• PCI-DSS v4： 2.2.2、2.2.7、11.3.1、11.3.2
• CIS 控件 v8.1：4.1 、4.2、4.7、18.5
• NIST CSF v2.0： DE.CM-7、DE.CM-8、PR.IP-1
• ISO 27001：2022： A.8.9、A.8.19、A.8.34
• SOC 2： CC6.1、CC6.6、CC7.1、CC7.2

PV-5：执行漏洞评估

Azure Policy： 请参阅 Azure 内置策略定义：PV-5。

安全原则

按计划且按需跨所有云资源执行全面的漏洞评估。 跟踪和比较扫描结果以验证修正有效性。 包括评估基础结构漏洞、应用程序弱点、配置问题和网络暴露，同时保护用于扫描活动的管理访问权限。

待缓解风险

跨云基础结构的不明漏洞为攻击者提供了许多利用机会。 没有全面的漏洞评估：

• 未知漏洞暴露： 系统中存在的安全弱点未被检测到，直到它们被利用，攻击者才能借此在系统中建立立足点，从而绕过安全防护措施。
• 过时的漏洞数据库： 安全团队缺乏对新出现的威胁和新发现的影响其基础结构的漏洞的了解。
• 多层盲点： 传统的以网络为中心的扫描错过了云服务、容器映像、无服务器函数和托管服务中的漏洞。
• 基于配置的漏洞： 错误配置和策略弱点会逃过传统漏洞扫描程序的检测，因为这些程序主要侧重于软件缺陷。
• 特权访问风险： 用于漏洞扫描的管理帐户会创建其他攻击途径（如果未正确保护并受到监视）。
• 评估覆盖率差距： 不完整的扫描使部分基础结构不受评估，为攻击者作创造了安全避风港。
• 修正跟踪失败： 如果没有系统化的漏洞跟踪，组织将无法了解哪些漏洞已经解决，哪些漏洞仍然未解决。

漏洞评估不足将未知的弱点转化为成功的攻击途径，从而启用初始访问、特权升级和横向移动。

MITRE ATT&CK

• 初始访问（TA0001）：利用 Web 应用程序和服务中未修补的漏洞利用面向公众的应用程序（T1190）。
• 特权提升（TA0004）：利用已知操作系统和应用程序中的漏洞进行特权提升（T1068）。
• 横向移动（TA0008）：通过利用漏洞来攻击远程服务（T1021），在系统和网络之间进行移动。
• 防御逃避（TA0005）：通过利用漏洞禁用或绕过安全控制，以实现防御逃避（T1562）。

PV-5.1：实施全面的漏洞评估

缺乏全面漏洞可见性的组织在安全团队发现这些未知安全弱点之前就已经被攻击者识别并利用，而且计算资源、容器和数据库中的关键漏洞仍然未被发现。 持续漏洞评估可全面了解所有云资源的安全弱点，在攻击者利用漏洞进行初始访问或特权升级之前启用主动修正。 多层扫描与暴露管理相结合可实现基于风险的优先排序，集中修正工作于可能被成功利用进行攻击的漏洞。

通过全面的漏洞评估确定和确定安全漏洞的优先级：

• 启用全面的漏洞评估： 为虚拟机、容器和 SQL 数据库部署 Microsoft Defender for Cloud 漏洞评估，以识别所有资源类型的安全漏洞。
• 使用集成的漏洞扫描： 实现 内置漏洞扫描程序 进行全面的 VM 评估，而无需额外的代理部署或许可。
• 集成曝光管理： 使用 Microsoft安全暴露管理 来识别攻击路径，并根据资产关键性和潜在爆炸半径确定漏洞的优先级，以便进行基于风险的修正。
• 实现数据库漏洞评估： 部署 SQL 漏洞评估 ，以便进行数据库安全评估和配置漏洞识别。
• 配置漏洞跟踪： 启用 连续导出 以跟踪和趋势分析，以测量一段时间内的修正进度。

实现示例

医疗保健服务公司跨云基础结构实施了全面的漏洞评估，支持患者护理系统、医疗设备集成和健康信息交换服务 500 多个医疗保健设施。

挑战： 医疗保健服务公司缺乏全面的漏洞评估功能，严重漏洞在数周内未检测到，手动漏洞管理流程导致 500 多个医疗保健设施的合规性风险降低，处理敏感患者数据。

解决方案方法：

部署集成的漏洞扫描：

1. 启用 Microsoft Defender for Cloud 集成漏洞扫描：
   • 使用 Microsoft Defender for Cloud 和集成 Qualys 扫描程序对 Azure VM 进行无代理扫描
   • 使用 Microsoft Defender for Containers 配合 Trivy，对 300 多个 Azure 容器注册表映像进行漏洞扫描。
   • Microsoft Defender for SQL 的漏洞评估功能，支持自动基线创建
   • Azure Monitor Log Analytics 集成将 SecurityAssessment 表导出到 Microsoft Sentinel

实现 Microsoft Defender for Cloud 持续评估：

1. 配置自动漏洞检测和优先级：
   • 基于风险的漏洞优先级，考虑资产关键性和曝光度
   • 与 Microsoft Defender 漏洞管理中本机提供的 Exploit Prediction Scoring System（EPSS）集成，以获取漏洞利用可能性的数据。
   • 与威胁情报源关联，以识别主动利用的漏洞（使用 Microsoft Defender 威胁情报优先级评分和利用跟踪）
   • 与资产清单集成，以便进行上下文感知漏洞评估
   • 通过 Microsoft Defender 威胁情报文章和网络入侵洞察进行实时攻击活动的上下文
   • 影响患者护理系统的漏洞的业务影响评估

建立漏洞管理工作流：

1. 使用 Azure 逻辑应用自动执行漏洞修正工作流：
   • Azure DevOps REST API 集成通过 SecurityAssessment KQL 查询创建工作项
   • Azure 自动化 Runbook 触发用于修补关键 CVE 的 Azure 更新管理器补丁部署
   • Microsoft Defender for Cloud 工作流自动化，将漏洞数据发送到 Azure DevOps
   • Azure Policy 的修正任务通过部署安全配置来解决配置错误
2. 使用 Microsoft Defender for Cloud 的安全性评分实施治理：
   • Azure Monitor 工作簿可视化来自 SecurityAssessment 表的漏洞趋势
   • 显示安全功能分数指标和漏洞修正 KPI 的 Power BI 仪表板
   • 适用于 HIPAA/HITRUST 跟踪的 Microsoft Defender for Cloud 法规合规性仪表板
   • 用于漏洞管理计划分析的 Microsoft Sentinel 工作簿模板

结果： 组织的综合漏洞评估已确定并有助于修正可能损害患者数据系统的漏洞，防止 HIPAA 违规。 关键漏洞检测时间通过自动持续扫描和集成威胁情报大幅提高，从而快速响应新兴威胁。

严重性级别

应该有。

控件映射

• NIST SP 800-53 Rev.5： RA-3、RA-5、RA-5（1）、RA-5（2）、RA-5（5）
• PCI-DSS v4： 6.3.1、6.3.2、11.3.1、11.3.2
• CIS 控件 v8.1： 7.1、7.2、7.5、7.7
• NIST CSF v2.0： DE.CM-8，ID.RA-1
• ISO 27001：2022： A.5.14、A.8.8
• SOC 2： CC7.1、CC7.2

PV-6：快速自动修正漏洞

Azure Policy： 请参阅 Azure 内置策略定义：PV-6。

安全原则

使用基于风险的优先顺序快速自动部署修补程序和更新，以首先解决最高价值资产中最严重的漏洞。 实现自动化修补功能，以平衡安全要求与作稳定性。

待缓解风险

漏洞修正缓慢延长了暴露窗口，使攻击者能够在应用修补程序之前利用已知弱点。 没有快速修正功能：

• 扩展曝光窗口： 关键漏洞在数天或几周内仍可被利用，同时手动修补进程进度，为攻击者开发和部署攻击提供了充足的时间。
• 修补程序管理延迟： 复杂的审批工作流和测试要求会延迟安全更新，使系统在延长修正周期期间易受攻击。
• 规模扩展： 具有数百或数千个资源的云环境需要自动修补来实现及时的补救，手动过程无法有效扩展。
• 业务中断风险： 担心系统停机会延迟修补决策，导致漏洞未得到解决，而组织在讨论运营影响。
• 第三方软件差距： 由于复杂的更新过程，作系统修补未涵盖的应用程序和中间件仍然易受攻击。
• 优先级不一致： 如果没有基于风险的修正优先级，影响高价值资产的关键漏洞可能不会受到适当的关注。
• 修正验证差距： 缺少修补后验证会导致是否成功解决漏洞的不确定性。

延迟漏洞修正将发现的弱点转化为成功的攻击途径，然后组织才能应用必要的修复。

MITRE ATT&CK

• 初始访问（TA0001）：利用面向公众的应用程序（T1190）在扩展修复窗口中针对已知漏洞进行攻击。
• 特权升级（TA0004）：通过利用未修补的本地漏洞进行特权升级（T1068）的攻击。
• 横向移动（TA0008）：使用已知漏洞利用远程服务（T1021）在系统之间传播。

PV-6.1：实现自动漏洞修正

手动补丁管理会在安全团队完成大规模环境中的修正过程之前，产生长时间的漏洞暴露窗口，使攻击者有机可乘，利用已知漏洞。 自动漏洞修正将平均修补时间从数周缩短到数小时，防止攻击者在长时间暴露期间利用公开披露的漏洞。 基于风险的优先顺序可确保关键漏洞立即得到关注，同时自动修补在所有计算资源中保持一致的安全卫生。

通过自动化和基于风险的优先顺序加速漏洞修正：

• 实现自动修补管理： 部署 Azure 更新管理器 ，以便通过集中式管理功能跨 Azure VM 和已启用 Arc 的服务器自动修补 Windows 和 Linux 虚拟机。
• 配置维护时段： 使用符合业务需求的维护时段设置 更新设置 ，以最大程度地减少对生产工作负荷的影响。
• 启用零停机时间修补： 使用适用于 Windows Server 2025 的 热修补 安装安全更新，而无需系统重启，从而减少停机时间和暴露窗口。
• 建立基于风险的优先顺序： 优先考虑漏洞严重性、资产严重性和暴露级别，以首先关注风险最高的问题。

实现示例

全球电子商务平台实现了跨云基础结构的自动漏洞修正，支持在线零售运营和客户数据处理服务全球 1000 万客户。

挑战： 全球电子商务平台的修补时间很长（严重漏洞为 14 天）、与未修补漏洞相关的高安全事件量，以及与支持在线零售运营的 2,000 多个 VM 中的修补程序管理流程不足相关的合规性审核发现。

解决方案方法：

部署自动修补管理基础结构：

1. 部署具有自动虚拟机评估和修补功能的 Azure 更新管理器：
   • 在 2,000 多个已启用 Azure VM 和已启用 Arc 的服务器上启用 Azure 更新管理器定期评估
   • 使用 Azure Resource Graph 查询进行动态范围设置的维护配置
   • 应用程序停止/启动协调操作的 Azure 自动化 Runbook 用于补丁前/后
   • Azure Policy deployIfNotExists 在所有订阅中强制执行更新评估
2. 使用 Microsoft Defender 漏洞管理配置基于 EPSS 的优先级：
   • 用于漏洞到修补相关性的 KQL 查询，将 SecurityAssessment 和 SecurityRecommendation 表联接以实现相关性分析。
   • 在 EPSS 分数 > 为 0.7 的关键 CVE 上触发的 Azure Monitor 警报规则
   • Azure 更新管理器按优先级分类安排补丁（关键/重要/中等）
   • Azure Resource Graph 查询，用于识别面向 Internet 的 VM（虚拟机）进行快速修补

建立自动修正工作流：

1. 将 Azure 逻辑应用程序与 Microsoft Defender 集成，实现自动化修复：
   • Microsoft Defender for Cloud 漏洞警报触发的 Azure 逻辑应用工作流
   • Microsoft Graph 安全 API 查询，将 CVE 与 Azure 更新管理器知识库文章相关联
   • Azure 自动化运行手册调用 Install-AzUpdateManagerUpdate 以进行紧急修补
   • Microsoft Defender 漏洞管理的威胁和漏洞管理 API 用于曝光评分

实现延迟修补的补偿控制：

1. 为需要延长修补时间线的系统部署临时保护措施：
   • Azure 应用程序网关 WAF 自定义规则阻止特定漏洞的已知攻击尝试
   • 网络安全组限制限制对易受攻击系统的网络访问，直到修补
   • 通过 Microsoft Defender for Endpoint 增强监视和警报，检测未修补资产上的可疑行为
   • 实时 （JIT） VM 访问控制减少了易受攻击的管理接口的暴露窗口
   • Microsoft Defender for Endpoint 攻击面缩减规则的缓解利用技术
2. 在 Microsoft 云防御中跟踪补偿性控制措施：
   • 包含用于记录补偿控制措施的结构化豁免元数据的 Azure Policy 豁免
   • Microsoft Defender for Cloud 安全功能分数自定义建议，用于免除漏洞
   • 带有过期跟踪的 Azure Monitor 工作簿可视化活动补偿控制
   • Microsoft Sentinel 监视列表，使用自动警报维护补偿控制清单

使用 Azure Monitor 和 Power BI 实现治理：

1. 部署全面的监视和报告仪表板：
   • Azure Monitor 工作簿查询更新表以检查所有 VM 的补丁合规性
   • 利用 Azure Resource Graph REST API 创建 Power BI 报表，以便实时揭示漏洞情况。
   • Microsoft Defender for Cloud 安全评分 API 集成，用于高管报告
   • Azure DevOps Boards 集成跟踪补丁例外并通过自动 SLA 升级处理
2. 使用 Microsoft Defender 漏洞管理自动进行紧急修补：
   • Microsoft Defender 漏洞管理 CISA KEV 目录集成，实现零日优先顺序
   • 使用 Azure 更新管理器的 InstallUpdates 操作的 Azure 自动化运行手册，以支持紧急部署
   • Azure Monitor动作组触发关于已利用漏洞的短信/电子邮件警报
   • Microsoft Defender for Cloud 工作流自动化，为活动攻击创建高优先级事件

结果： 组织的自动漏洞修正大大缩短了修补关键漏洞、减少暴露窗口和防止安全泄露的时间。 与未修补漏洞相关的安全事件量通过系统修补管理和基于 EPSS 的优先顺序显著减少。

严重性级别

应该有。

控件映射

• NIST SP 800-53 Rev.5： SI-2、SI-2（1）、SI-2（2）、SI-2（5）、RA-5
• PCI-DSS v4： 6.3.3、6.4.3、11.3.1
• CIS 控件 v8.1： 7.2、7.3、7.4、7.5、7.7
• NIST CSF v2.0： PR.IP-12, RS.MI-3
• ISO 27001：2022： A.8.8、A.5.14
• SOC 2： CC7.1、CC7.2、CC8.1

PV-7：定期执行红队操作

安全原则

通过红队行动和渗透性测试模拟现实攻击，来实现全面的安全验证。 遵循行业最佳做法，设计、准备和安全执行测试，同时确保全面的范围和利益干系人协调。

待缓解风险

传统的漏洞评估和渗透测试可能会错过真正的对手采用的复杂攻击技术和复杂的攻击链。 没有全面的对抗测试：

• 安全控制中的盲点： 自动化安全工具和标准渗透测试无法识别熟练攻击者通过合法功能和轻微漏洞的创造性组合利用的弱点。
• 错误的安全置信度： 组织基于合规性复选框和标准测试认为其安全态势很强，但这可能使其容易受到高级持续性威胁和有针对性的攻击。
• 人为因素漏洞： 安全意识培训和技术控制可能不足以抵御复杂的社会工程和人为操纵技术。
• 复杂的攻击链差距： 多阶段攻击结合了物理访问、社会工程、技术开发以及持久性技术通过孤立的安全测试来逃避检测。
• 事件响应弱点： 安全团队可能缺乏检测和响应复杂攻击的经验，从而导致延迟发现和遏制不足。
• 紫色团队协作差距： 进攻（红队）和防御（蓝队）安全操作之间的断开限制了知识转移和改进的机会。

如果没有现实的对抗测试，组织会以未经评估的安全假设进行作，这些假设在面对熟练、有动机的攻击者时会失败。

MITRE ATT&CK

• 侦查（TA0043）：主动扫描（T1595）并收集受害者信息（T1589），以确定攻击机会并计划有针对性的行动。
• 初始访问（TA0001）：网络钓鱼（T1566）和利用面向公众的应用程序漏洞（T1190），测试组织对社会工程和技术漏洞利用的易感性。
• 持久性（TA0003）：有效帐户（T1078）和创建帐户（T1136）模拟攻击者建立长期访问。
• 横向移动（TA0008）：远程服务（T1021）和内部鱼叉式网络钓鱼（T1534）测试对手在环境中的移动检测。

PV-7.1：实现全面的对抗测试

仅依赖于自动漏洞扫描和合规性评估的组织无法验证安全控制是否阻止在实际攻击中使用的复杂攻击者技术。 对抗测试模拟实际攻击方案，以确定自动化工具无法发现的安全控制差距、检测盲点和事件响应弱点。 常规红队作业提供实际性的安全验证，并确保安全投资能够有效防御、检测和响应高级持久性威胁。

通过实际的对抗测试验证安全性有效性：

• 遵循Microsoft渗透测试规则： 遵循 Microsoft基于云的测试活动的云渗透测试规则 ，确保经过授权和安全的测试过程。
• 参考 Azure 测试指南： 遵循 Azure 渗透测试指南 ，了解授权的测试过程与Microsoft的协调要求。
• 使用 Microsoft 红队方法： 应用 Microsoft Cloud 红队方法 ，以便进行符合真实对手技术的综合性攻击模拟。
• 协调测试范围： 与相关利益干系人和资源所有者建立测试范围和约束，以确保业务连续性，并最大程度地减少意外的影响。

实现示例

金融服务组织跨云基础结构实施了全面的红队运营，支持投资银行、交易系统和客户财富管理平台处理数十亿笔日常交易。

挑战： 金融服务组织缺乏现实的安全测试功能，自动化工具缺少关键安全漏洞、对复杂攻击检测功能的可见性有限，以及难以向监管者展示安全验证有效性，以检查投资银行和财富管理安全控制。

解决方案方法：

建立与微软一致的红队测试计划：

1. 实现以下 Microsoft Cloud Red Teaming 方法的测试：
   • 使用 Microsoft Enterprise Cloud Red Teaming 攻击模拟框架进行季度练习
   • 利用 Microsoft Entra 攻击模拟工具和 Microsoft Sentinel 分析的年度评估
   • 来自 Microsoft Defender 威胁情报的威胁情报用于制定攻击场景
   • 使用 Microsoft Defender for Cloud 攻击路径分析结果进行紫色团队演练
2. 使用 Azure 安全措施配置测试环境：
   • Azure 资源管理器锁可防止在测试期间删除生产资源
   • Azure Policy 的拒绝效果会阻止在生产环境中部署危险配置
   • Microsoft Defender for Cloud 实时 VM 访问限制红队横向移动范围
   • Azure Monitor操作组为测试活动超出阈值提供实时警报

执行以 Azure 为中心的攻击模拟：

1. 模拟特定于云的攻击方案：
   • 使用 Microsoft Defender for Office 365 活动中的 Microsoft 365 网络钓鱼攻击模拟
   • Azure 应用服务的利用测试 Web 应用程序防火墙的有效性
   • Azure 资源管理器 API 滥用测试 Azure Policy 和 RBAC 控件
   • Azure DevOps 管道入侵模拟 CI/CD 基础设施上的供应链攻击
2. 测试 Microsoft Entra ID 和身份安全控制：
   • Microsoft Entra Privileged Identity Management （PIM） 提升路径开发
   • Microsoft Entra 通过设备合规性差距尝试绕过条件访问策略
   • Microsoft Entra 身份验证协议测试以防止 MFA 绕过和令牌盗窃
   • Azure Key Vault 机密外泄尝试验证访问策略和日志记录

验证Microsoft安全检测和响应：

1. 测试Microsoft Sentinel 检测和响应功能：
   • Microsoft Sentinel 分析规则用于评估检测红队 MITRE ATT&CK 技术的有效性
   • Microsoft Defender for Cloud 警报验证测试运行时威胁防护准确性
   • Microsoft Defender for Endpoint EDR 遥测覆盖范围，用于测量行为检测率
   • Azure Monitor Log Analytics 查询性能测试事件调查工作流程
2. 评估安全业务流程和自动化：
   • Microsoft Sentinel 自动化规则测试自动事件响应手册的执行
   • Azure 逻辑应用工作流，验证与 Microsoft Teams 的集成，以获取事件通知
   • Microsoft Defender for Cloud 工作流自动化测试修正措施有效性
   • Azure 自动化运行手册评估自动包含和隔离过程

利用Microsoft工具进行持续改进：

1. 记录调查结果并使用微软安全平台：
   • Microsoft Defender for Cloud 攻击路径分析，记录多步骤攻击链
   • 用于标识云环境中类似攻击面的 Azure Resource Graph 查询
   • Microsoft Sentinel 工作簿可视化映射到 MITRE ATT&CK 框架的攻击技术
   • Azure DevOps Boards 根据可利用性确定优先级，跟踪修复措施。
2. 利用红队发现的结果增强检测能力。
   • Microsoft Sentinel 自定义分析规则基于红队技术和指标
   • Microsoft Defender for Endpoint 自定义检测规则，用于标识的陆地技术
   • Azure Monitor Log Analytics 已保存的搜索查询加速了未来事件调查
   • Microsoft Defender 威胁情报集成，通过红队攻击情境丰富警报

结果： 组织识别并修正了自动化工具错过的关键安全漏洞，包括身份验证绕过技术和特权提升路径。 通过实际攻击模拟通知的增强监视和响应过程，安全团队能够更有效地识别和响应高级持久性威胁。

严重性级别

很好。

控件映射

• NIST SP 800-53 Rev.5： CA-8、CA-8（1）、CA-8（2）
• PCI-DSS v4： 11.4.1、11.4.2、11.4.6
• CIS 控件 v8.1： 15.1、18.1、18.2、18.3、18.5
• NIST CSF v2.0： DE.DP-4，ID.RA-10
• ISO 27001：2022： A.5.7、A.8.29
• SOC 2： CC7.3、CC7.4