当前位置：首页 > news >正文

Gartner发布CTEM指南：使用持续威胁暴露管理来减少网络攻击

news 2025/7/31 11:43:00

由于企业在实施网络安全计划时采取了不切实际、各自为政且以工具为中心的方法，导致其无法通过自我风险评估来降低威胁暴露。本研究旨在帮助安全运营领导者启动并完善持续的威胁暴露管理计划，以缓解威胁。

主要发现

0-day漏洞很少是造成数据泄露的主要原因。最成功的防护方法是将应对未知威胁的准备与降低风险的策略相结合，重点关注已知的漏洞和已确定的控制差距。
以技术为中心的攻击面和漏洞自我评估项目会产生很少被采取行动的报告和冗长而通用的补救措施清单。典型的漏洞管理程序往往难以跟上报告和补救措施的总量，导致攻击面风险迅速扩大。
确保持续适应并保持强大的安全态势，仍然是高管层风险管理的核心挑战。项目成熟度的最佳实现途径是清晰高效的工作流程，战略性地部署自动化，使组织能够主动管理风险并快速应对新兴威胁。
利用安全态势验证计划测试攻击可行性，可以改进基于分数的优先级排序方法。然而，由于缺乏业务背景和责任考量，仅仅依靠优先级列表不足以动员非安全团队并解决问题。

建议

负责安全运营的安全运营领导者应该：

设计一个风险管理计划，其输出可以为安全和 IT 组织的多个部分做出贡献，而不是仅仅清点和处理来自不同漏洞评估工具的遥测数据，以有效地管理更广泛的风险。
通过遵循可重复的五步流程（范围界定、发现、确定优先级、验证和动员），建立与持续威胁暴露管理 (CTEM) 计划相称的定期风险降低周期。
将攻击面管理和对抗性暴露验证等功能纳入更广泛的暴露管理计划。随着 CTEM 计划的成熟，应纳入组织控制力较弱的资产，例如 SaaS 应用程序、供应链合作伙伴持有的数据以及供应商自身的依赖项。
将 CTEM 与组织级补救和事件工作流程相结合，超越特定于安全的自动化技术修复，以确保跨职能协作成为常态。

概述

随着数字化转型和人工智能加速攻击面的扩展，风险暴露正迅速超出已知漏洞的范围。此外，随着企业根据不断变化的工作实践更新其IT和安全程序，攻击面正变得更加复杂和分散——无论是在本地还是在云端。

随着威胁形势的迅速扩张，现有的漏洞管理方案——从紧急修补到更全面的基于风险的漏洞管理 (RBVM)，往往无法有效识别新兴风险。因此，组织既无法修复所有潜在漏洞，也无法确定哪些漏洞可以安全地推迟修复。

因此，致力于构建强大漏洞管理方案的安全运营领导者需要从单纯的预防性方法转向更成熟的策略，以检测和响应能力增强预防性控制。CTEM 就是这样一种务实的系统性方法，它通过不断优化优先级来促进修复/缓解措施，从而在修复所有漏洞和推迟漏洞之间找到适当的平衡（参见图 1）。

图 1：持续威胁暴露管理

分析

设计全面的 CTEM 计划

持续威胁暴露管理 (CTEM) 计划是一套流程和功能，使企业能够持续一致地评估其数字和物理资产的可访问性、暴露程度和可利用性。因此，构建 CTEM 计划的组织应使用工具来清点和分类资产和漏洞，并模拟或测试攻击场景以及其他形式的态势评估流程和技术。此外，为了使 CTEM 的输出可用，必须为基础设施团队、系统和项目所有者创建一条有效且可操作的路径，以便他们根据 CTEM 的发现采取行动。

建立有效的 CTEM 计划需要跨团队协作以及责任和义务的统一，尤其是在风险暴露的评估、跟踪、管理和补救工作由多个团队共同承担的情况下。例如：安全运营团队可能负责监督风险暴露的评估、跟踪和管理；基础设施和运营团队以及企业架构团队则负责对风险暴露采取行动。

为了定义并随后完善 CTEM 计划的范围，安全团队首先需要了解对其业务伙伴而言什么是重要的，以及哪些影响（例如生产系统的必要中断）可能严重到需要采取协作补救措施。

如果没有 CTEM，补救措施通常不会像建议的那样简单。领导者首先需要动员其他团队，并确定问题的解决是否会给运营业务功能带来摩擦或问题（即“治标不治本” ）。CTEM 让这一切变得简单：它提供的治疗和安全态势优化解决方案不仅超越了传统的补丁、签名和策略方案，而且能够独立于 CTEM 计划而不断成熟。

CTEM 不是一个工具，而是一个计划

在构建有效的风险发现、分类和管理方案时，安全运营领导者不应受制于供应商平台的叙事。重点应放在解决CTEM 方案的所有五个阶段（范围界定、发现、优先级排序、验证和动员）。

跨框架多个组成部分的多功能平台的概念是存在的，但平台的用途可能会影响其设计。CTEM支持平台，例如暴露评估平台 (EAP)，可以协助完成发现、优先级排序和动员阶段，而其他类型的平台，例如对抗性暴露验证 (AEV)，可以协助验证。

CTEM 计划可能会利用自动评估技术的结果，但必须重申的是，堆积评估报告或仅仅购买一个承诺“全能”的综合平台是不够的。

漏洞程序历史告诉我们，仅仅依靠工具会不可避免地造成诊断疲劳，并且缺乏相关优先级或成功补救的业务背景。

由于供应商对新收入的渴望以及对其产品沦为功能性产品的担忧，多个以风险暴露为导向的市场趋于融合，这加剧了最初的混乱。为了避免这种情况，安全运营领导者应该首先将各个组件作为独立产品进行评估，然后再单独评估集成平台的价值。

归根结底，无法通过花钱来处理风险暴露。必须首先构建旨在解决已发现问题的流程。然后，可以通过购买技术来加速某些功能，例如评估（风险暴露的）可利用性或可利用服务的可访问性，从而提高效率。

正在开启网络安全网格架构 (CSMA) 之旅的组织机构将会认识到一个共同的理念。随着 CTEM 项目的成熟，它将成为 CSMA 设计中安全情报层的关键来源。

建立定期风险管理周期

在任何成熟阶段，CTEM 周期都必须包括五个阶段：范围界定、发现、优先排序、验证和动员（见图 2）。

图 2：持续威胁暴露管理流程阶段

范围

对于大型组织而言，攻击面的范围通常超出了漏洞管理程序的典型关注范围。因此，漏洞管理需要涵盖更广泛的资产，从传统的设备和应用程序，到不那么具体的元素，例如企业社交媒体账户、在线代码存储库和集成供应链系统。解决此问题的一个有效方法是确定初始范围，其中应包含一个向利益相关者证明其价值的计划，并随着计划的进展而不断扩展。

在 CTEM 的范围界定阶段，资产的初步识别和定义并非仅仅是技术操作，而是从一开始就与业务相关性进行战略性协调。这意味着范围会刻意缩小，以专注于对业务最关键的因素，以及哪些潜在影响（例如生产系统中断）会严重到需要协作补救。

通过建立以业务为中心的基础，范围界定可以有效地为所有后续发现创建“业务相关性标签”。此标签对于优先级排序阶段至关重要，它使组织能够超越通用漏洞评分（例如 CVSS），而是根据威胁对关键业务资产的真正潜在影响来确定其优先级，同时考虑可利用性、补偿控制措施和风险偏好。

此外，业务主导的范围界定可确保报告更具针对性和可操作性。这种关注使安全运营领导者能够提供清晰、有影响力的洞察，引起业务利益相关者的共鸣，并通过提供必要的业务背景和问责考量，动员非安全团队采取补救措施，而这些是传统的以技术为中心的报告通常所缺乏的。

CTEM 项目超越了自身造成的漏洞，并采取了“攻击者的视角”，超越了传统的常见漏洞和暴露。在为 CTEM 项目试点确定合适的范围时，合适的候选范围包括：

它结合了相对较窄的范围（对于大多数组织而言）和不断发展的工具生态系统，减少了可用性问题对面向客户的关键基础设施的影响。
虽然工具仍然不够成熟，但远程劳动力的增加使得更多关键业务数据托管在 SaaS 上，从而确保更轻松地沟通风险。

后续周期可能会扩展至：

提高攻击面的可见性，降低客户数据泄露的可能性
识别对关键资产的潜在威胁，并提供有关威胁行为者以及用于进行恶意活动的策略和流程的背景信息

发现

利用范围界定过程中收集的信息，针对该范围内的相关资产和风险状况进行目标发现。应优先发现范围界定过程中已确定的业务领域，尽管这并非始终是驱动因素。

暴露发现不仅限于漏洞。它可能包括资产和安全控制的错误配置，也可能包括其他弱点，例如伪造资产或对网络钓鱼测试的错误响应。

在构建 CTEM计划时，混淆范围界定阶段和发现阶段的要求往往是第一个失败。

发现的资产和漏洞的数量本身并不代表成功。基于业务风险和潜在影响的准确范围界定才更有价值。

由于许多发现过程超出了最初规定的范围（识别可见和隐藏的资产、漏洞、错误配置和其他风险），负担转移到“优先排序”阶段，在此阶段需要额外的“噪音消除”。

优先级

风险暴露管理的目标并非修复所有已发现的问题或大多数零日威胁，而是识别并解决最有可能针对组织的威胁。

企业无法像传统方式那样，通过预先定义的通用漏洞评分系统 (CVSS) 基准严重性评分来对漏洞进行优先级排序。他们需要考虑漏洞利用的普遍性、可用的控制措施、缓解措施选项以及业务关键性，以反映漏洞对企业的潜在影响。

确定风险暴露处理的优先级，需要综合考虑紧急程度、严重程度、补偿控制措施的可用性、风险偏好以及对组织构成的风险等级。换句话说，组织应根据现有安全控制措施是否到位以及资产被攻击者利用的可能性来确定其高价值资产（即关键业务价值所在）。之后，组织可以根据情况重点处理风险暴露。

作为持续威胁管理 (CTEM) 计划的一部分，风险补救的优先级排序已启用。此外，还会根据系统的拓扑结构/配置/关键程度，审查降低优先级的理由。这清晰地阐明了组织优先处理任务关键型和业务关键型系统的方法。它还能够处理异常或例外事件（例如需要立即响应的零日漏洞和/或关键漏洞），并展示改进情况。

然而，即使有一份清晰的优先处理清单（例如补丁、签名、配置更改），也可能不足以触发必要的协作方法来修复突出的问题。因此，CTEM 的验证和动员阶段是成功的关键。

一旦组织不再仅仅依赖通用漏洞评分（例如 CVSS 基本严重性评分），就应该开始根据优先级采取行动。暴露管理的根本目标并非修复每个已发现的问题，而是识别并解决最有可能被利用来攻击组织的威胁。因此，在以下情况下应根据优先级采取行动：

组织已经考虑了漏洞利用的普遍性、可用的控制、缓解选项和资产的业务关键性等因素。
优先级明确地阐明了组织优先处理任务或业务关键型系统的方法，从而能够集中精力于高价值资产并展示持续改进。
存在一些不寻常或异常事件，例如零日漏洞或严重漏洞，需要立即响应和优先处理。
范围界定的结果定义了对业务来说什么是最重要的，并被用来创建“业务相关性标签”，以指导和完善优先排序过程，超越纯粹的技术视角。

验证

在安全程序环境中，验证是组织验证潜在攻击者如何利用已识别的漏洞以及监控和控制系统如何做出反应的过程的一部分。

验证通常使用受控模拟或仿真在生产环境中模拟攻击者的技术。虽然“验证”阶段不仅限于攻击者的技术，但通常依赖于手动评估活动（例如红队演习）来扩大其范围。在CTEM环境中，它还包括验证建议的应对措施，不仅要验证其安全有效性，还要验证其组织可行性。

验证应实现三个目标：

通过确认攻击者是否能够真正利用先前发现和优先考虑的漏洞来评估可能的“攻击成功”。
通过超越初始足迹并分析关键业务资产的所有潜在攻击路径来估计“最高潜在影响”。
确定响应和补救已发现问题的流程是否足够快且适合业务。

良好的验证流程需要克服一些挑战。它需要综合运用多种技术评估（例如渗透测试、红队测试和对抗暴露验证）以及组织认可。每个组织都需要确定最低准确度，以说服所有业务利益相关者进行修复。这将影响工具的选择和所需的流程。

此外，验证范围不仅应包括相关的威胁向量，还应涵盖枢转和横向移动的可能性。验证还应超越安全控制测试，评估程序和流程的有效性。

当组织需要明确确认已识别漏洞的可利用性并评估其监控和控制系统如何应对真实攻击时，他们应该采取行动进行验证。

验证行动对于以下方面至关重要：

通过确认攻击者是否能够真正利用先前发现和优先考虑的漏洞来评估攻击成功的可能性。
通过分析所有可能导致关键业务资产受损的潜在攻击路径来估计最大潜在影响，这些攻击路径超出了最初的范围。
确定现有的响应和补救已发现问题的流程是否足够快并且适合业务环境。
验证建议的处理方法不仅要确保其安全有效性，还要确保其组织可行性。
达到最低限度的准确性，以说服所有业务利益相关者（包括非安全团队）继续采取补救措施。这也会影响工具和所需程序的选择。
在范围界定阶段建立的“业务相关性标签”指导哪些优先暴露需要接受验证，确保将精力集中在真正对业务重要的事情上。

动员

为了确保成功，安全运营领导者必须承认并告知所有利益相关者，修复无法完全自动化。许多成熟的组织已经达到了所谓“自动化修复”的极限，因为技术处理通常仅限于补丁、基本威胁检测规则或安全控制配置更改。工具推荐的全自动响应可能适用于最明显且不显眼的问题。这可以作为可接受的第一步，但很少是安全团队遇到困难的地方。

完全依赖计划中自动修复的承诺将导致不可避免的失败，因为任何修复尝试的后果都超出了安全团队的责任范围。工具或安全流程无法猜测其他团队可以接受什么。

为了某个目的而组织或准备某事物（例如一群人）的行为。

CTEM 计划中的安全工具可能只会建议一种解决方案，而实际可能存在多种解决方案。在这些建议的解决方案中进行选择，仅取决于部分可用信息。

“动员”工作的目标是确保团队能够通过减少审批、实施流程和缓解措施部署中的摩擦，将 CTEM 的发现付诸实践。这要求组织定义沟通标准（信息要求）并记录跨团队审批工作流程。此外，还需要业务主管的参与。

在更高的成熟度下，动员还需要工具的演进，以实现更好的集成，以便它们能够在组织的其他部门环境中发挥作用，例如通过网络安全事件响应管理 (CIRM) 技术集成，为事件响应团队提供支持。必须考虑动员在更长远的时间内是否有效，而不仅仅是立即修复，从而永久地消除风险。

向CTEM成熟度迈进

CTEM 计划的动员阶段最基本的形式是，它以 IT 服务管理工具中的工单形式触发后续的处理和优化流程。启动该阶段的目的是通过技术控制措施（例如保护签名（“虚拟补丁”）或系统补丁请求）来实施问题补救措施。支持 CTEM 的各种工具通常会建议这些基本的补救措施。

但为了实现稳健性，安全态势优化需要：

整合 CTEM 项目的经验教训，提高建议治疗的效率
支持多种场景，包括修复既不容易又无法自动化的情况

CTEM 计划的“动员”步骤以批准所需变更、投入必要资源以及商定时间表结束。安全态势的优化始于将这些补救措施整合到规划中，以满足这些时间表。然而，威胁暴露远不止于此。

暴露不仅仅是（你的资产的）姿态

传统上，安全态势指的是组织能够控制并更轻松地改进的内容。它听起来也更积极主动，并引发了供应商和领导层的过度渴求。但这并不意味着很容易，尤其是在安全控制成熟度尚不够的情况下。

随着云服务团队的采用，安全和基础设施团队现在必须监控大量的设置和配置。如果操作不当，可能会暴露敏感数据和服务。因此，管理态势的过程需要正确结合分析攻击面、识别高风险漏洞以及验证对业务重要事项的可见性和响应能力。

但总体风险敞口远不止这些步骤。它还包括无法直接控制的因素，例如合作伙伴在其环境中存储组织数据所带来的供应链风险（见表1）。运行CTEM循环创造了机会，可以将每个步骤中的经验教训融入到未来产品版本的设计中。

表 1：组织直接控制范围之外的持续性和暂时性暴露

长期的	暂时的
选择与业务最相关的控制措施实施和配置控制修补和维护漏洞	识别并缓解身份泄露识别并减少数据暴露识别并降低第三方 SaaS 应用程序中的风险

来源：Gartner

可以通过更改流程、删除/隐藏可见数据以及消除持续性暴露（通过纠正错误配置、修补漏洞和添加控制措施）来减少短暂性暴露的攻击面。这可以更好地应对短暂性暴露的攻击面。

将CTEM与跨团队工作流程集成

组织通常通过扩展现有的漏洞管理计划来开始解决威胁暴露问题，具体方法如下：