跳转至

A Framework for AI Threat Readiness

Ch12.002 A Framework for AI Threat Readiness

📊 Level ⭐ | 10.4KB | entities/ai_threat_readiness_framework.md

核心要点

  • AI 正在加速漏洞发现与利用的整个生命周期，前沿模型已能自主发现零日漏洞、生成可用的利用代码、并链接多个弱点形成攻击链
  • 安全响应窗口大幅压缩，组织需要在识别、验证和修复之间建立更快的闭环
  • 四大支柱框架：消除关键风险、加速打补丁、深挖 AI 代码分析、实时检测与响应
  • Wiz 数据显示 30% 的云环境至少有一台高影响机器暴露在外，19% 的组织在拥有 IAM 权限的系统上有暴露软件，6% 的组织暴露软件可直接获得管理员权限

深度分析

AI 驱动威胁的本质转变

这篇文章揭示了安全领域正在发生的结构性转变：AI 将漏洞发现和利用的速度提升到了前所未有的量级。传统安全模型假设漏洞发现是相对缓慢、需要人工参与的过程，而现在前沿模型已经能够在短时间内自主完成从发现到利用的完整链路。 这种转变的深远影响在于安全工作的底层逻辑需要重塑。过去安全团队可以依赖较长的响应窗口——从漏洞披露到实际被利用之间可能有数天甚至数周。现在这个窗口正在压缩到小时甚至分钟级别。文章引用 Zeroday Clock 的数据明确指出，发现与利用之间的时间差将持续缩短。这意味着被动防御的思路已经不够用了，组织必须建立主动的、持续验证的运营模型。

双轴驱动框架的核心洞察

Wiz 提出的 AI Threat Readiness 框架基于两个维度：速度（Speed of Action）和可见性（Breadth of Visibility）。这两个轴构成了一切安全运营工作的基础坐标。 速度轴的核心问题是：组织能否在攻击者之前完成识别-验证-修复的完整闭环？随着 AI 加速漏洞发现，这个闭环的各个阶段都需要重新优化。传统的离散流程（发现是一个团队、验证是一个团队、修复是另一个团队）现在成为瓶颈，因为每个环节之间的延迟都可能被攻击者利用。 可见性轴则关注组织是否真正知道自己暴露了什么。Wiz 的数据揭示了一个关键洞察：危险的往往不是已知的高危漏洞，而是那些被遗忘的暴露面。30% 的云环境有高影响机器暴露在外，这不是因为这些机器上有已知的 CVE，而是因为它们暴露在互联网上，而软件版本可能包含未知漏洞。更值得注意的是，19% 的暴露软件存在于拥有 IAM 权限的系统上，这意味着攻击者可以利用这些系统作为跳板访问敏感内部资产。

四大支柱的递进关系

框架的四个支柱并非孤立措施，而是一个递进的防护体系： 第一支柱：消除暴露 — 这是最根本的层面。组织首先需要确保敏感资产不可从互联网到达，无论其补丁状态如何。这包含一个重要但反直觉的理念：不应该仅仅依赖补丁来保证安全，而应该假设任何暴露的软件都可能在某个时刻变得可利用。这个支柱强调 AI 驱动的持续扫描——不仅要发现暴露面，还要验证其可利用性，并理解如果被利用会允许攻击者做什么。 第二支柱：加速修复 — 当暴露无法完全消除时（这在实际环境中是常态），关键变成能否比攻击者更快地完成修复。这需要建立清晰的ownership、优先级排序和执行路径。文章特别强调了区分三类不同漏洞的重要性：第三方软件漏洞（CVE）、环境中该漏洞的实例、以及第一方代码中的漏洞。每类需要不同的检测、优先级和修复策略。 第三支柱：深度代码分析 — 这是将 AI 能力应用于防御侧的主动举措。前沿模型已在网络靶场中完成近一半的挑战，证明它们能够发现复杂逻辑漏洞（如 IDOR）和跨越应用流、依赖、API 和信任边界的不安全行为。关键在于这些 AI 发现的能力不仅限于传统 SAST 能找到的问题，还包括传统工具难以识别的"不可发现"风险——那些需要深入推理应用程序逻辑才能识别的漏洞。 第四支柱：实时检测与响应 — 即便前三道防线都做到极致，仍然会有风险转化为活跃威胁。AI 时代要求检测与响应不能再依赖人工调查，因为调查速度跟不上攻击速度。这支柱强调全上下文关联——跨代码、云、运行时、身份、网络、工作负载和数据的完整可见性——以及自动化响应工作流，能够在人类批准下快速隔离工作负载、撤销权限、阻止通信、轮换密钥。

红队的真实世界实验

文章透露了 Wiz Red Agent 的运营数据，这是一个外部 AI 攻击agent，在超过 150,000 个生产 Web 应用和 API 上每周进行扫描。这个 agent 每周处理超过 1000 亿 token，横跨数百个企业环境，已从发现基本结构漏洞进化到每周稳定发现超过 3,000 个高危和关键可利用逻辑漏洞。这个数字具有重要意义：这些是手动和传统扫描方法通常遗漏的"不可发现"风险。 这个数据点揭示了一个现实：AI 驱动的攻击已经在规模化运营，而防御方必须具备同等量级的 AI 能力才能跟上。

实践启示

建立持续发现-验证-修复的运营飞轮

组织需要将安全运营理解为持续运转的飞轮，而不是线性的项目。这个飞轮包含四个阶段：持续发现暴露、验证可利用性、优先排序真实运营风险、在环境和新漏洞出现时以机器速度修复。这不是一个一次性项目，而是需要嵌入到日常运营中的操作系统。 关键实践：建立一个自动化的资产发现和暴露监控机制，不仅监控已知资产，还要能发现影子 API 和未文档化的服务。同时，建立明确的 ownership 映射——每个暴露资产应该映射到具体的负责人、服务和代码仓库。

将补丁响应升级为零日响应能力

从"打补丁"到"零日响应"的升级是组织能力的重大跨越。传统补丁管理假设有足够的响应时间（数天到数周），而零日响应要求在数小时甚至更短时间内完成从发现到修复的全过程。 关键实践：为高曝光技术建立清晰的补丁流程和 ownership；使用 AI 驱动的分析来识别受影响的系统和自动修复路径；建立零日响应工作流，包括优先级排序、路由和执行。所有高曝光技术应该有预先定义的响应 playbook，而不是等到漏洞出现才开始协调。

构建分层代码扫描策略

AI 代码分析需要分层策略，而不是对所有代码一视同仁。首先确定优先级：面向客户的应用程序、互联网暴露的服务、敏感数据流、认证和授权逻辑、以及其他业务关键系统。这些应该是最深度 AI 扫描的目标。 关键实践：建立一个代码优先级机制，基于代码来源、暴露程度和业务关键性进行排序。同时建立从检测到验证到修复的完整生命周期，确保 AI 发现的高影响问题能够快速移动。每个发现都需要验证和优先级排序，然后路由到正确的工程 owner，并在源头修复。

建立上下文关联的检测能力

实时检测需要从孤立的告警转向上下文关联的调查能力。没有上下文的安全团队面对的是隔离的告警，需要人工关联；有了上下文，检测可以更精确，调查可以自动化，响应可以根据实际风险和影响范围进行路由。 关键实践：建立完整的环境可见性，摄取云和工作负载遥测，包括运行时遥测以获得丰富上下文；使用 AI 自动执行多个调查步骤以给出最终裁决（恶意、安全测试、未确定）；建立自动化响应 playbook，定义隔离工作负载、撤销数据访问、阻止进程等操作的触发条件；保留取证证据以支持事后分析。

治理与指标体系

框架最后强调了治理的重要性：建立明确的 ownership、定义预期结果、并用清晰的指标追踪进度。这些指标包括 SLA 遵守率、异常数量、资产和环境覆盖范围、以及针对定义安全结果的进展。 关键实践：建立定义清晰的委员会、角色和决策流程；定义结果和关键指标以追踪进展并向执行层报告；创建策略、SLA 和异常流程以确保风险被一致地处理。指标体系应该覆盖从暴露发现到修复完成的全流程时间（MTTR），以及各层次的覆盖率。

相关实体

→ 原文存档

关联阅读