Agent AI 重塑入侵检测：从签名到上下文理解

每个 IDS 部署中都存在盲区。任何运行 IDS 足够长时间的人最终都会发现它，而且往往是在最糟糕的时刻。这个盲区就位于你编写规则所覆盖的行为与攻击者实际选择的其他行为之间。经典的 Snort 特征规则确实是令人赞叹的工具。一条精心编写的规则可以捕获某个已知漏洞利用，误报率几乎为零，性能开销小到在分析器中都几乎无法察觉。这种精确性源于针对性，而针对性恰恰也是问题所在。为 CVE-2024-12345 编写一条规则，你获得的就是对该 CVE 的检测能力。至于经过修改、通过略有不同的路径触发同一段易受攻击代码的载荷？什么都不会触发。

这并不是对特征检测模型的批评。它完全按照设计在工作。特征规则编码的是关于攻击在线路层面呈现何种形态的具体、可验证知识，而低误报率正是这种针对性的直接产物。真正的制约因素是一个更难解决的问题：暴露时间。从一种新型漏洞利用首次出现在真实环境中，到研究人员捕获它、对其进行逆向工程、编写规则、使用测试语料库验证该规则，再通过更新通道发布，可能会过去数天甚至数周。对于常见软件中正遭到积极利用的漏洞来说，这个时间窗口绝非假设。

2024 年 3 月，Cisco Talos 通过 SnortML 直接应对了这一问题。SnortML 是一个原生运行在 Snort 3 内部的机器学习检测引擎。大约在同一时期，安全运营领域一场更广泛的变革也开始获得真正的关注：AI 智能体开始进入网络防御。这两项发展作用于同一场转变的不同层面，将它们放在一起审视，可以揭示一些单独观察其中任何一项都无法看出的东西。

第 1 部分：SnortML 究竟做了什么

在讨论架构和影响之前，首先需要理解其工作机制。SnortML 不是一个附加在 Snort 告警输出上的通用异常评分器，也不是一个会在每次请求时连接远程服务器的云端信誉服务。推理完全发生在本地设备上，位于与常规规则评估相同的处理流水线中，并且能够在不到一毫秒的时间内给出判定结果。

这套机制由两个组件共同实现。snort_ml_engine 模块负责在启动时加载模型，将预训练的 TensorFlow 模型载入内存，并在整个会话期间将其作为分类器提供。随后，snort_ml 检查器通过 Snort 3 内部已有的发布/订阅接口，订阅来自 Snort 现有服务检查器的数据流。当 HTTP 检查器完成请求解析后，它会将 URI 查询字符串和 POST 请求体发布到事件总线。SnortML 检查器获取这些数据，将其输入分类器，并返回一个浮点数，表示内容中包含漏洞利用尝试的概率。

模型架构是在嵌入层之后连接一个 LSTM。嵌入层将原始字节值映射为学习得到的向量表示，从而捕获纯频率分析无法识别的字节间关系。可以将其理解为类似 NLP 中的词嵌入，只不过这里的 token 是字节而不是单词。当字节值 0x27（撇号）出现在 0x4F 0x52（OR）旁边时，它携带了关于 SQL 注入模式的已学习上下文，而嵌入层会对这种上下文进行编码。随后，LSTM 处理这些序列并捕获时序结构：字节的排列顺序非常重要，而攻击载荷往往具有某些典型排列，可以据此将它们与合法查询字符串区分开来。

最后一个全连接层将 LSTM 的输出压缩为一个表示概率的浮点数。SnortML 附带的推理库 LibML 使用 XNNPACK 执行硬件加速的矩阵运算，使推理时间在负载下保持可预测。在一颗主频为 4.7 GHz 的 AMD 处理器上，单次分类大约耗时 350 微秒。有一个实际细节值得注意：从 Secure Firewall 10.0.0 开始，SnortML 会根据查询的实际长度，在面向 256、512 或 1024 字节输入的模型之间自动选择。短查询会使用较轻量的模型，只有更长、更复杂的请求才会经过完整规模的推理。对于超过 1024 字节的查询，输入会在分类前被截断至这一边界；如果应用会生成异常长的参数字符串，就需要留意这种行为。

首个版本以 SQL 注入检测为目标。到 2025 年末，检测范围已经扩展到 XSS 和命令注入攻击类别。模型更新通过 Snort 的 Lightweight Security Package 系统交付，与规则内容使用相同的更新通道。这意味着 SnortML 可以持续保持最新，而无须建立单独的更新工作流。

下图展示了它在 Snort 数据包处理流水线中的位置。SnortML 分类器与传统特征匹配并行运行。请注意，这两条路径从检查器分发阶段开始分离，并在判定阶段汇合：任何一条路径都能独立触发告警；如果两条路径同时触发检测，其置信度会显著高于仅由机器学习触发的检测。

为什么并行架构如此重要？

SnortML 并不会取代特征评估。让二者并行运行是一项经过深思熟虑的工程决策，而不是过渡阶段的妥协。针对某类漏洞训练的神经网络偶尔会在与攻击语法相似的合法流量上误判。合法数据库查询中经过 URL 编码的特殊字符就是一种常见情况。让特征规则与机器学习模型同时运行，意味着两种机制能够以不同的错误特征提供彼此独立的检测能力：机器学习负责捕获尚无任何特征规则的新型变体，而经典匹配则为已知模式提供低噪声的基础检测能力。当二者针对同一载荷同时触发时，这种相关性对下游系统而言是一个有意义的信号。

延迟影响经过了仔细测试。350 微秒的开销确实存在，需要结合具体环境理解。当前 Cisco Secure Firewall 设备上的高吞吐量 Snort 部署，每个数据包的处理时间预算通常从几百微秒到几毫秒不等，具体高度取决于规则集规模和协议复杂度。增加 350 微秒并非可以忽略不计。这也正是 XNNPACK 加速非常重要的原因：它让机器学习的额外开销在负载下保持可预测且有明确上限，而不会发生波动。

第 2 部分：嵌入式机器学习的局限，以及为什么下一步是 AI 智能体

SnortML 是针对特定问题设计的一套聚焦型工程解决方案。这种聚焦既是优势，同时也是限制。它能够在设备本地捕获已知漏洞类别中的零日漏洞利用变体，并且不依赖任何外部服务。在这个范围内，它表现良好。有意思的地方恰恰在于这个范围本身。

分类器处理的是单个 HTTP 参数。系统接收一个 URI 查询字符串或 POST 请求体，对其进行评分，然后决定是否触发检测。模型无法看到该请求之前或之后发生了什么，也无法了解同一源 IP 在此前二十分钟内执行过哪些操作。设想一个简单的三请求序列：第一个是用于摸清应用输入验证行为的探测请求，第二个是用于识别可注入参数的枚举请求，最后才是根据前两次探测结果定制的漏洞利用尝试。如果单独查看，每个请求的评分都可能低于阈值。这个序列中的第三个请求之所以更加危险，恰恰是因为前两个请求的存在，而 SnortML 无法看到这种关联。

相同的边界也适用于 HTTP 参数空间之外的所有内容。DNS 隧道数据外泄、TLS 层协议攻击、SMB 漏洞利用、基于时序的隐蔽信道，以及非 HTTP 服务中的协议行为异常：这些数据都不会经过 HTTP 检查器的发布路径，因此 SnortML 根本看不到它们。从架构上说，系统可以接入其他检查器，发布/订阅接口也足够通用，能够支持这种扩展。但目前尚不存在面向这些数据源的已训练模型，而且为研究较少的协议构建带标签的训练语料库，要比为 HTTP 构建语料库困难得多。

这些都不是缺陷，而是任何工作在单数据包、单参数层级的检测系统所具有的自然限制。要突破这些限制，需要一种不同类型的推理方式：它能够跨时间保存上下文、关联来自多个观测点的信号，并且无须等待人类阅读报告便可采取行动。这正是安全运营中的 AI 智能体要做的事情。

下图展示了不同检测方法如何覆盖攻击面的不同层级。SnortML 位于线路层，将 Snort 的检测范围从已知模式扩展到零日变体。AI 智能体推理则工作在更高的抽象层，在这里，时间上下文和跨数据源关联成为主要工具。

第 3 部分：AI 智能体对网络防御意味着什么

“AI 智能体”一词在安全营销中的应用过于宽泛，以至于它可能彻底失去原本的含义。我们有必要准确界定：AI 智能体究竟与传统 ML 模型或自动化 SOAR 剧本有何不同。

传统 ML 模型只会对摆在眼前的内容进行评分。它不会记住之前的输入，无法主动收集更多上下文，也没有机制根据自己的输出决定下一步该做什么。SOAR 剧本采用另一种方式：由告警条件触发一套固定的步骤序列，其中每个步骤都是预先定义的。如果实际情况超出剧本预期的分支，自动化流程就会停止并转交给人工处理。这两种方式都有实际价值，但它们都不是智能体。

AI 智能体能够在多步骤调查过程中维持状态。它会根据已经发现的信息决定接下来检查什么，而不是遵循预先确定的步骤序列。它会调用工具：查询 SIEM 中的相关事件、在威胁情报平台中查找文件哈希、从身份提供商处获取被标记用户近期的活动记录、检查源 IP 是否出现在 BGP 级别的黑名单中。每一次查询的结果都会影响下一步行动。当调查进行到需要响应的阶段时，智能体既可以直接执行响应，也可以将任务移交给人工，并附上足够完整的上下文，让审核其建议的人只需几秒钟而不是几小时就能做出判断。

商业安全行业大约在过去两年里一直朝着这个方向发展。IBM 于 2025 年 4 月推出 ATOM（Autonomous Threat Operations Machine，自主威胁运营机器），将其定位为一个构建在 SIEM 分析之上的多智能体框架，用于处理调查和修复工作流。Trend Micro 于 2025 年 8 月发布 Agentic SIEM，该产品从一开始就是围绕自主关联和调查而设计的。它们并不是附加了安全领域知识的对话式界面，而是编排平台：专门化智能体按照职能划分调查工作，并在彼此之间传递结构化的调查结果。

SOC 分析师短缺才是真正的驱动力

观察劳动力市场后，这种采用速度就更容易理解了。全球网络安全人才缺口约为 400 万个未填补的岗位。2025 年的一项调查发现，82% 的 SOC 分析师担心，仅仅由于告警数量过多，他们就可能漏掉真正的威胁。这些数字描述的是一个承受结构性压力的系统，而现有工具并未解决这一问题。如果不改变分流和调查的工作方式，只是增加另一项检测能力，产生的只会是更多告警，而不是更好的结果。AI 智能体得到采用，并不是因为它在理论上很优雅，而是因为另一种选择——让更多分析师阅读更多告警——并不是一条可行的规模化路径。

Snort 3 作为智能体技术栈中的传感器层

在这一架构中，搭载 SnortML 的 Snort 3 承担着一个明确且重要的角色：传感器。它位于最接近实际网络链路的位置，以数据包处理速度运行，持续生成代表网络上确切观测结果的事件流。这条事件流是上层推理赖以构建的事实依据。

在智能体架构中，这一定位比在传统 SOC 中更有价值。在传统部署中，Snort 告警会进入 SIEM，再由分析师进行分流。分析师同时也是纠错层：他们阅读上下文，判断告警是否值得调查，然后手动追查。在智能体架构中，Snort 的输出会直接进入自动化推理链。误报不再只是消耗分析师的注意力，还会浪费智能体的计算周期、塞满调查队列，并且在配置错误的部署中，甚至可能触发自动遏制操作。因此，对传感器层准确性的要求会更高。

SnortML 的概率输出在这里提供了具体帮助。由于分类器返回的是浮点数，而不是二元匹配结果，因此智能体层可以将该概率纳入自身的置信度评分。一个同时满足传统签名匹配且 SnortML 评分为 0.97 的告警，其路由方式会与仅由 ML 以 0.61 的评分触发的告警截然不同。更丰富的输出为下游推理提供了更多可用信息，也让基于阈值的升级逻辑更加细致。

下图展示了多智能体 SOC 架构如何在不同专业职能之间进行协调。每个智能体负责调查的一个层面：分流、信息补充、深度关联和上下文历史。请注意严重性评估和响应处的决策点：二者都是明确的分支结构，而不是线性流水线。正是这种设计，使系统能够根据风险等级按比例引入人工参与，而不是以相同方式处理每一条告警。

第 4 部分：一种建议的集成架构

对于任何实际运行 Snort 3 部署的人来说，现实问题都是如何连接这些层。下面的架构是一项具体建议，而不是厂商产品推介。其中的每个组件如今都已存在，问题在于如何将它们组合起来。

捕获层通过 DAQ 层处理线速数据包采集，并根据吞吐量要求，经由 AFPacket RSS 队列或 DPDK 将数据送入 Snort 的分析器线程。检测层并行运行 MPSE Hyperscan 规则引擎和 SnortML LSTM 分类器，二者都通过遥测总线将结果送入统一事件流。该事件流携带 JSON 格式的告警数据、ML 概率评分和流元数据。这里的数据模式非常重要，因为无论上层采用哪种智能体框架，都需要解析这些数据并据此推理：如果不同告警类型的字段命名方式或所含值不一致，就会造成集成阻力，而且这种阻力会随着规模扩大而不断累积。

智能体推理层接收这条事件流，并按照职能将任务分派给专门化智能体。分流智能体负责去重、过滤和初始严重性评分。信息补充智能体获取 IOC 数据、IP 信誉和威胁情报。调查智能体在 SIEM 数据、身份提供商日志和端点遥测之间进行关联。上下文智能体则把当前活动与历史模式、来自同一来源的既往告警以及已知攻击活动签名进行映射。

下图展示了从捕获层到智能体推理层，再到反馈循环的完整集成。最重要的结构特征，是从响应层返回 ML 模型和规则引擎的路径。大多数当前部署所缺失的，正是这条反馈连接。

反馈循环问题

大多数当前部署都止步于检测层向智能体层的移交。智能体接收 Snort 输出、开展调查并采取行动，却没有任何信息回流来改进 Snort 的检测能力。智能体完成的每一次已确认攻击调查，都包含 ML 训练流水线可以利用的信息：评分低于阈值但最终确认是真实攻击的有效载荷、没有任何签名覆盖的变体，以及分类器错误地给出低分的新型混淆模式。这些经过标注和结构化的数据都是训练信号，但目前都被丢弃了。

捕获这些数据的技术路径并不复杂。已确认事件中的 HTTP 参数数据本来就存在于告警遥测中。将其提取出来，经过人工验证步骤，再送入周期性再训练任务。Cisco 的 LSP 交付机制可以通过与规则更新相同的渠道推送更新后的模型。围绕这一流程的组织工作比技术实现更困难，尤其是人工验证步骤。理论上，如果攻击者能够通过精心构造的活动模式，让自动化分析误以为攻击成功，从而操纵调查智能体确认的内容，那么随着时间推移，他们就可能向流水线中注入被投毒的训练样本。针对这种威胁模型，不仅要对实时流量运行异常检测，还需要对再训练输入运行异常检测。

第 5 部分：当前差距以及仍需构建的能力

以下内容是对当前尚不可用之处的实际梳理，以及这些差距为何会影响当下部署这些系统的人。

SnortML 目前仅覆盖 HTTP

当前的 SnortML 模型检测 HTTP URI 查询字符串和 POST 正文中的漏洞利用。这覆盖了 Web 应用攻击面中的很大一部分，但 DNS 隧道、TLS 层攻击、非 HTTP 服务中的协议级注入、SMB 漏洞利用，以及 HTTP 参数空间之外的任何其他内容，都完全不在其范围内。发布/订阅架构与协议无关：任何检查器都可以发布供 ML 检查器订阅的数据。真正的限制是训练数据。与 HTTP 数据集相比，较少受到研究的协议更难构建带标签语料库；多年来的安全研究已经为 HTTP 生成了大量公开数据集合。在这些语料库出现之前，SnortML 的 ML 覆盖范围仍将局限于 HTTP。

智能体协调协议仍在走向成熟

多智能体编排与互操作性

当今的多智能体安全平台运行在专有编排层上。IBM 的 ATOM、SentinelOne 的 Purple AI 和 Torq 的多智能体系统都各自构建了内部智能体协调能力，且彼此之间没有互操作性。Model Context Protocol 和 Agent-to-Agent Protocol 正作为潜在标准出现，但采用水平还未达到足以合理地预期某个特定厂商平台会支持它们的程度。对于以 Snort 为中心的部署，这意味着 Snort 产生的事件格式需要显式映射到各个智能体框架预期的输入格式，且每次集成都需要重复这项映射工作。Snort 端的格式稳定性和智能体端更广泛的 MCP 采用都能有效降低这一负担。

ML 告警的可解释性发展不足

当 SnortML 触发并且调查智能体将发现升级给人工分析师进行最终审批时，分析师会有一个合理的疑问：是 payload 中的哪一部分触发了这个告警？不是整个 URI，而是特别是哪些字节使分数超过了阈值。是单引号字符的出现？还是某个类似 UNION SELECT 模式的特定字节序列？当前的 SnortML 告警输出提供了概率分数和触发的 payload 内容，但完全没有说明该分数对特定输入区域的归因。

基于梯度的归因方法，特别是应用于 LSTM 输入嵌入层的 Integrated Gradients，能为这类序列模型生成字节级的重要性分数。这项技术已广为人知，并已被应用于架构类似的文本分类任务。为 SnortML 实现它意味着在推理路径中添加归因计算，并扩展 GID:411 告警格式来承载该输出。工程路径很清晰。但这些工作都还没有被集成到当前的生产系统中。

下图展示了当前的告警数据流与缺失部分的对比。左边的路径是分析师和智能体今天接收的内容。右边的路径是若实现了归因输出将可用的内容。两条路径都来自同一个推理过程，所以这不是架构问题，而是关于从已有足够信息计算该值的推理运行中，什么会被暴露出来的问题。

公开测试中对抗输入下的模型健壮性缺失

通过神经网络进行 SQL 注入检测是一个监督学习问题。该模型在已知攻击模式的语料库上训练，学会了一个决策边界来区分攻击和良性流量。原则上，知道 SnortML 已部署的对手可以系统地探测这个边界：尝试混淆的变体、字符编码技巧、SQL 注释注入、空格操纵和其他规避技术，找到保留漏洞功能同时分数在检测阈值以下的输入。这是应用于网络安全的标准对抗 ML 问题，并非理论问题。

缺失的是关于该边界位置及其在有意攻击下稳定性的任何公开评估。SnortML 今天正在 Cisco Secure Firewall 生产部署中运行。运营安全社区应该获得公开的对抗健壮性评估：哪些攻击类别逃脱了检测、规避率如何、采用了什么混淆技术。这项工作至今还未公开发表，应该被发表。

第 6 部分：具有真正新颖性的研究方向

以下五个方向在当前文献中都没有明确的答案。每个方向都足够具体以成为可行的研究课题，又足够重要以影响已部署的系统。

SnortML 中的跨流时间建模

当前的 LSTM 处理单个 HTTP 参数序列。一个有意义的架构扩展是在会话内来自同一源 IP 的请求窗口上操作。实际上，这可能意味着来自给定源的最后 10 或 20 个请求的固定窗口，或 60 到 120 秒活动的时间限制窗口（二者取其短）。进行利用前侦察的攻击者表现出特征性的时间模式：先发送一个探针请求来测试输入处理，再发送一个或多个枚举请求来识别可注入的参数，最后发送针对探针所披露内容定制的漏洞。单参数分类器无论单个请求的评分有多好，在结构上都无法察觉这种模式。

在会话窗口上操作的基于 Transformer 的模型将是检测能力的有意义进步。工程挑战很真实：Snort 当前的数据交付模型将单个参数值传递给 ML 检查器。构建会话级特征向量需要改变检查器如何跨多个请求缓冲和累积输入的方式，这涉及检查器生命周期管理和内存处理。研究问题是：检测改进是否足以证明这种架构复杂性的合理性。

从 SnortML 检测生成 LLM 辅助的 Snort 规则

当 SnortML 在已确认的真正正例上触发时，触发的 HTTP 参数包含语法模式，经验丰富的规则编写者在起草签名时会立即想到这些。一个有权访问该 payload、熟悉 Snort 规则语法、掌握几个精心编写的现有规则示例的 LLM 可以尝试起草一个覆盖同一情况的候选签名。验证后，该签名将为该攻击模式提供显式的经典覆盖，使未来实例即使不经过 ML 推理也能被触发。

这创造了一个真正有用的循环：ML 检测处理没有签名覆盖的新颖情况，已确认的检测为强化经典覆盖的流水线提供数据。研究问题是具体且可测量的：相比手工编写的 Snort 规则，LLM 生成的 Snort 规则在误报率、跨 payload 变体的泛化和处理开销方面的表现如何？这个比较有一个可发表的