SnortML 与 Agentic AI：入侵检测的架构演进

Cisco Talos 于 2024 年 3 月推出 SnortML，将机器学习推理直接嵌入 Snort 3 检测引擎。几乎同一时期，agentic AI（代理型 AI）概念也开始在安全运营领域引发广泛关注。这两股趋势看似独立，实则指向同一轮变革的不同层面。

SnortML 的核心工作原理

SnortML 并非外接的异常评分系统，也不是依赖云端查询的信誉服务。推理完全在本地完成，与传统规则评估共用同一条处理流水线，单次判决耗时不足 1 毫秒。

两组件协同： snortmlengine 模块在 Snort 启动时加载模型，将预训练的 TensorFlow 模型置入内存并注册为分类器；snort_ml inspector 则通过 Snort 3 内置的发布/订阅接口，订阅来自 HTTP 等服务 inspector 的数据流。HTTP inspector 完成请求解析后，会将 URI 查询字符串和 POST body 发布到事件总线，SnortML inspector 随即取用并运行分类，最终输出一个 0～1 之间的浮点数，代表该内容属于漏洞利用尝试的概率。

模型结构： 采用 Embedding 层 + LSTM + Dense 层的架构。Embedding 层将原始字节值映射为学习得到的向量表示，能够捕捉字节之间的上下文关系——这与 NLP 中的词向量类似，只不过 token 是字节而非单词。例如，0x27（单引号）紧邻 0x4F 0x52（OR）会携带关于 SQL 注入模式的学习上下文。LSTM 则进一步处理序列，捕捉字节排列的时序特征：攻击 Payload 的字节顺序往往具有区别于正常查询字符串的典型模式。最后一层 Dense 将 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 并非要取代传统签名检测，两者并行运行是经过深思熟虑的工程决策，而非过渡方案。

神经网络的误报场景并不罕见——某些合法的流量语法与攻击 Payload 高度相似时，可能触发误判。典型案例是 URL 编码的特殊字符出现在正常数据库查询中。签名与 ML 模型同时运行，意味着两条路径拥有独立覆盖范围和不同的错误特征：ML 负责捕获尚无签名的新型变体，经典匹配则为已知攻击模式提供低噪声的检测基底。当两者同时命中同一 Payload 时，这种关联本身即为高置信信号，对下游安全系统具有重要参考价值。

至于延迟影响：350 微秒的额外开销是真实存在的，需要放在具体场景中理解。当前 Cisco Secure Firewall 设备在高吞吐 Snort 部署下的单包处理预算为数百微秒到数毫秒不等，取决于规则集规模和协议复杂度。增加 350 微秒并非可以忽略的开销，这也正是 XNNPACK 加速如此关键的原因——它将 ML 推理的额外耗时固定在可预测范围内，而非随负载波动。

为什么 SnortML 有天花板：上下文盲区与跨源关联

SnortML 解决了特定问题，但这种专注既是优势也是局限。它能在已知漏洞类别中捕获零日变种，且设备端运行、无外部依赖——在范围内表现优异，但问题恰好出在这个"范围"本身。

单请求检测的局限性体现在：模型只对单个 HTTP 参数打分（URI 查询字符串或 POST body），无法获知该请求之前发生了什么、之后又发生了什么，更无法看到同一来源 IP 过去 20 分钟的行为轨迹。

举个典型攻击链例子：攻击者先发探测请求摸清应用的输入校验逻辑，再发枚举请求定位可注入参数，最后根据前两步情报构造漏洞利用载荷。这三步单独看每条都可能低于阈值放行——但真正危险的恰恰是第三步，正是前两步让它成真。SnortML 看不到这种关系。

检测边界的另一个缺口在于 HTTP 参数空间之外的一切：DNS 隧道外泄、TLS 层协议攻击、SMB 利用、基于时间的隐蔽信道、非 HTTP 服务的协议行为异常——这些都不经过 HTTP 检测通道，SnortML 根本看不见。虽然架构理论上可接入其他检测器，发布/订阅接口也足够通用，但针对这些数据源的训练模型尚不存在，而为冷门协议构建标注语料库更是难上加难。

以上并非缺陷，而是任何"逐包、逐参数"级别检测系统的天然约束。突破这些限制需要另一种推理能力：跨时间保持上下文、关联多观测点信号、不依赖人工阅读报告再触发响应——这正是安全运营中 Agentic AI 的用武之地。

不同检测方法覆盖的攻击面层次各异：SnortML 位于网络层，将 Snort 的已知模式检测扩展到零日变种；Agentic 推理则在更高抽象层运作，以时序上下文和跨源关联为主要工具。

Agentic AI 是什么：它与传统安全工具的本质区别

"Agentic AI"在安全营销中已被泛用，几乎失去意义。严格界定它与传统机器学习模型或自动化 SOAR 剧本的真正区别才有价值。

传统机器学习模型：只对眼前输入打分，无记忆、无主动获取上下文能力、无法决定输出后该做什么。

SOAR 剧本：按预定义步骤序列执行，由告警条件触发，每个步骤都预先设定。一旦情况超出剧本预期的分支，自动化即中断并转交人工。两者的价值都是真实的，但都不是 Agent。

AI Agent 的核心能力：跨多步调查保持状态，根据已发现信息决定下一步查什么，而不是按固定顺序执行。它会调用工具——向 SIEM 查询关联事件、向威胁情报平台查文件哈希、向身份提供商拉取被标记用户近期活动、查来源 IP 是否出现在 BGP 级黑名单。每一次查询都影响下一步行动。当调查到达需要响应的节点时，Agent 或者直接执行，或者带着充分整理的背景信息转交人工——让人看到的是秒级可读完的建议，而非耗时数小时的原始日志堆砌。

商业安全行业为此已经准备了大约两年：IBM 于 2025 年 4 月推出 ATOM（Autonomous Threat Operations Machine），定位为多 Agent 框架，位于 SIEM 分析之上，处理调查和修复工作流；Trend Micro 于 2025 年 8 月发布原生设计的 Agentic SIEM，围绕自主关联和调查构建。这些不是接入了安全领域知识的对话式界面，而是编排平台——专业 Agent 按功能分工调查，相互传递结构化调查结果。

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

理解 adoption 加速要看劳动力市场：全球网络安全人才缺口约 400 万人。2025 年调查显示，82% 的 SOC 分析师因告警量过大而担忧遗漏真实威胁。这些数字描述的是一套结构性承压的系统，单纯堆砌工具未能解决。增加又一个检测能力却不改变分类和调查方式，只会产生更多告警，不会带来更好结果。Agentic AI 被采用不是因为理论优雅，而是因为"雇更多分析师读更多告警"根本不是可持续的扩展路径。

Snort 3 在 Agentic 架构中的定位：传感器层

在这个图景中，集成了 SnortML 的 Snort 3 扮演的角色是传感器——离网线最近、在数据包速度上运行、持续输出一连串代表网络上"实际观察到内容"的事件流。这是高层推理所依赖的事实基础。

这种定位在 Agentic 架构中比传统 SOC 更有价值：传统模式下，Snort 告警进入 SIEM，由分析师分类，分析师同时也是纠错层——读上下文、判研判价值、手动追踪；在 Agentic 架构中，Snort 输出直接喂入自动化推理链。误报不再只是消耗分析师精力，而是消耗 Agent 计算资源、填满调查队列，在配置不当的部署中还可能触发自动化遏制行动——传感器层的准确度要求因此水涨船高。

传统规则匹配给出的只有「是或否」的二元判断，而 SnortML 返回浮点概率值，这为后续决策提供了更丰富的语义信息。比如一次规则命中配合 0.97 的 ML 置信度，与仅有 ML 单独触发且置信度仅 0.61 的告警，处理路径应截然不同。更细腻的置信度数据让基于阈值的升级逻辑可以更精准，而不是一刀切地对待所有告警。

多代理 SOC 架构如何协同

下图展示了多代理 SOC 架构如何在各功能层间协调运转。每个代理负责调查链路的一个环节：初筛分诊、威胁富化、深度关联、历史上下文。

关键设计在于决策分支而非线性流水线：严重性评估和响应处置都存在明确的分支结构，允许根据风险等级决定人工介入的程度，避免将所有告警均质化处理。

集成架构提案：从抓包到推理的完整链路

对于实际部署 Snort 3 的团队，接下来的问题是各层如何串联。以下架构是具体方案而非产品推销——每个组件当下都已存在，核心是组合方式。

抓包层

通过 DAQ 层实现线速数据包采集，根据吞吐量需求选择 AFPacket RSS 队列或 DPDK 驱动，将数据喂给 Snort 分析器线程。

检测层

MPSE Hyperscan 规则引擎与 SnortML LSTM 分类器并行运行，共用统一事件流通道。事件流以 JSON 格式承载告警数据、ML 概率分数和流量元数据。字段命名和取值的一致性至关重要，因为上层的 Agentic 框架需要解析这些数据，格式碎片化会随规模放大而加剧集成摩擦。

Agentic 推理层

事件流分发至专业化代理：

• 初筛代理：去重、过滤、初步严重性评分
• 富化代理：拉取 IOC 数据、IP 信誉、威胁情报
• 调查代理：跨 SIEM 数据、身份提供商日志、端点遥测进行关联
• 上下文代理：将当前活动与历史模式、同一来源的历史告警、已知攻击活动签名进行比对

反馈回路

最关键的结构特征是响应层向 ML 模型和规则引擎反向回传的路径——这正是当前大多数部署缺失的一环。

当前部署的三大空白

1. SnortML 覆盖范围限于 HTTP

当前模型仅检测 HTTP URI 查询字符串和 POST body 中的漏洞利用，虽覆盖大量 Web 应用攻击面，但 DNS 隧道、TLS 层攻击、非 HTTP 服务的协议级注入、SMB 漏洞利用等均超出范围。

架构本身对协议无限制，任何 inspector 都可发布数据供 ML inspector 订阅，真正的约束在于训练数据。HTTP 数据集因多年安全研究积累丰厚，而其他协议的标注语料库构建难度大得多。在这些语料库就绪之前，SnortML 的 ML 覆盖将始终受限于 HTTP 边界。

2. Agentic 协调协议仍在成熟期

当前多代理安全平台依赖私有编排层：IBM ATOM、SentinelOne Purple AI、Torq 多代理系统各自采用内部代理协调规范，彼此无法互通。MCP（Model Context Protocol）和 A2A（Agent-to-Agent Protocol）正在成为潜在标准，但尚未达到主流采用水平。

这意味着 Snort 输出的事件模式需要针对每个代理框架逐一套换，且换到下一个平台要重新做一遍。Snort 端的模式稳定性加上代理端更广泛的 MCP 支持，才能显著降低这种重复劳动。

3. ML 告警的可解释性仍然薄弱

当一个告警触发时，运维人员不仅需要知道「怎么做」，更需要知道「为什么」。当前 ML 模型给出的置信度分数缺乏清晰的决策解释，这在高风险场景下会阻碍人工审核效率，也是下一步需要补齐的方向。

可解释性缺口：模型只知道「检出」，不知道「为何检出」

当 SnortML 触发告警并经调查代理 Escalation 给人类分析师审批时，分析师面临一个合理的问题：究竟是载荷的哪一部分导致了这次检出？不是整个 URI，而是具体哪些字节将评分推过了阈值。单引号字符？一段形似 UNION SELECT 的序列？现有 SnortML 告警输出只提供概率评分和触发载荷内容，并不说明哪些输入区域「贡献」了这个评分。

字节级归因：Integrated Gradients 的应用路径

针对这类序列模型，梯度归因方法（尤其是应用于 LSTM 输入嵌入层的 Integrated Gradients）恰好可以生成字节级重要性评分。这项技术在文本分类任务中已有成熟应用。将其引入 SnortML 的工程路径清晰明确：在推理路径中加入归因计算，并将 GID:411 告警格式扩展以承载这一输出。但截至目前，生产系统尚未构建这些能力。

下图展示了当前告警数据流与缺失部分：左侧路径是分析师和代理目前收到的内容，右侧路径则是引入归因输出后将可用的内容。两条路径源于同一次推理，差距不在架构，而在推理运行后实际暴露给用户的信息。

对抗性鲁棒性：公开研究中的空白

SnortML 通过神经网络检测 SQL 注入，本质上是一个监督学习问题。模型在已知攻击模式语料库上训练，学习将恶意流量与正常流量分开的决策边界。攻击者若知晓 SnortML 的部署，理论上可以系统性地探测这一边界：尝试混淆变体、字符编码技巧、SQL 注释注入、空格填充等规避技术，寻找那些保留漏洞利用功能但评分低于检测阈值的输入。这正是对抗性机器学习在网络安全领域的标准问题，并非理论假设。

真正缺失的是：公开文献中没有任何关于该决策边界位置及其在刻意攻击下稳定性的研究。SnortML 目前已在 Cisco Secure Firewall 生产环境中运行。安全社区需要公开的对抗性鲁棒性评估：哪些攻击类别能够绕过模型？绕过率如何？在何种混淆技术下发生？相关研究尚未公开发布，但应该有所呈现。

值得探索的研究方向

以下三个方向在现有文献中尚无成熟答案，每个都足够具体，可作为研究项目；每个都足够重要，将影响实际部署系统。

跨请求时序建模：突破单参数检测的结构盲区

当前 LSTM 仅处理单个 HTTP 参数序列。更具意义的架构扩展应基于同一来源 IP 在会话期间的多条请求窗口进行操作。实践中可以是固定窗口（过去 10～20 条请求）或时间窗口（60～120 秒内的活动），取两者中较短者。攻击者在利用前通常会表现出特征性时序模式：先发送探测请求测试输入处理，再发送枚举请求定位可注入参数，最后根据探测结果发送定制化漏洞利用。无论单请求评分多精准，单参数分类器在结构上对这类模式视而不见。

基于 Transformer 的模型在这样的会话窗口上运作，将是检测能力的显著提升。工程挑战是真实的：Snort 当前的数据传递模型将单个参数值传递给 ML 检查器，构建会话级特征向量需要修改检查器缓冲和跨请求累积输入的方式，涉及检查器生命周期管理和内存处理。研究的核心问题是：检测能力的提升是否值得这种架构复杂性。

LLM 辅助 Snort 规则生成：从检测结果到签名硬化

当 SnortML 确认为真阳性时触发告警，触发的 HTTP 参数包含资深规则编写者能立即识别的语法模式。若大语言模型能访问该载荷、熟悉 Snort 规则语法并获得若干优质规则示例，即可尝试起草覆盖同类型攻击的候选签名。该签名经验证后，可将明确的经典覆盖落地，后续同类攻击即便没有 ML 推理也能触发。

这形成了一个真正有用的闭环：ML 检测处理无签名覆盖的新型攻击，已确认检测结果则馈送至管道以硬化经典覆盖。研究问题具体可测：LLM 生成的 Snort 规则与人工编写规则相比，在误报率、载荷变体泛化能力、处理开销方面表现如何？这一比较既有发表价值，也对检测规则管道的 staffing 和自动化方式具有实际指导意义。

代理调查质量评测：行业缺失的基准框架

安全行业正在部署具有真实处置权限的代理式 SOC 平台，但几乎不存在关于这些代理实际调查效果的正式基准测试。厂商提供的指标聚焦于削减量：每小时分诊的告警数、从告警到关闭的时间、节省的分析师工时。这些指标无法回答核心问题——代理的决策质量究竟如何。

更有价值的基准测试框架应直接衡量调查准确度：自动处置动作被确认为误报触发率、真实恶意活动被低严重性分类并自动关闭的概率、在规定时间窗口内代理组合的上下文信息能否导向正确分析决策。构建这一框架需要带有已知 ground truth 的真实事件调查标注数据集，这既是数据收集问题，也是指标设计问题。这项工作是行业刚需，但在当前文献中基本缺失。

部署实操要点

对于正在生产环境部署 Snort 3、以及考虑如何将 SnortML 与 Agent 工具链纳入现有体系的团队，以下列出几条关键经验。

初期被动监听，不做在线阻断

SnortML 的 HTTP 参数分类器误报率虽低，但并非为零。在充分了解模型在自身流量环境中的表现之前，直接启用"检测即阻断"的在线模式，是引发生产事故的捷径。以下几类流量容易被误判为可疑：

• 合法应用使用了非标准编码的参数化查询
• REST API 在 Query String 中传递数据结构
• 某些框架的转义行为与常见攻击模式相似

正确的初始部署方式是被动监听：将 SnortML 告警作为事件记录，持续至少两周（覆盖完整业务周期），统计对已知正常应用流量的误报率，建立基线后才考虑调优阈值或切换为在线阻断。在 Cisco FMC 中，评估期内可将 GID:411 规则设置为仅告警模式。

ML 评分作为复合置信度的一个因子

若在 Snort 之上构建 Agent 调查逻辑，不要将 SnortML 评分 > 0.9 等同于经典签名匹配确认来驱动路由决策。两种检测机制的错误特征完全不同：

• 经典签名：对覆盖到的模式误报极低，但会漏掉变体
• SnortML：对变体和新型模式覆盖更好，但对与攻击语法字节级相似的合法流量存在非零误报率

正确架构是将 ML 评分作为复合置信度计算的输入之一，而非独立触发源。例如：经典签名和 SnortML 同时触发且 ML 评分 0.95 的告警，与仅有 ML 触发且评分 0.72 的告警，应走不同的路由策略。信号组合使用，不相互替代，更不要让 ML 评分独自驱动自动化阻断决策，缺乏佐证不得执行阻断。

Containment 决策保留人类判断

Agent 系统若获得阻止 IP、隔离主机或重置凭证的权限，存在一个容易被低估的风险：攻击者若了解你的自动化响应逻辑，可将其武器化。

伪造看似来自合法关键基础设施地址的流量，触发你的自动化阻断阈值——这相当于把自己的响应系统变成了定向 DoS 工具。这不是理论推演，而是有实际记录的针对激进自动化响应组织的技术。

有效的运营姿态是非对称的：调查自动化程度高，响应自动化程度保守。由 Agent 负责消耗大量分析师时间的分类、丰富、关联和上下文整理工作；最终的 Containment 决策留给审核&查验过 Agent 整理上下文的人类。自动化将人工审核&查验时间从数小时压缩到秒级，而人类判断步骤才是对抗韧性的来源。

代理式 SOC：从学术研究到产业落地

学术研究：AI 代理在安全运营中的系统性梳理

2025 年以来，学界对代理式 AI（Agentic AI）在安全运营领域的系统性研究显著增多。其中最具代表性的成果包括： MDPI Systems 于 2025 年 11 月发表的综述论文 [1]，系统梳理了大语言模型（LLM）与 AI 代理在安全自动化中的应用现状，涵盖 SOC 场景下的威胁检测、事件响应与策略编排等核心环节。

arXiv 于 2026 年 1 月发表的综述 [2]，则从更宏观的视角出发，深入分析了代理式 AI 与网络安全的交叉领域，探讨了当前面临的核心挑战、潜在机会以及典型用例原型，为后续研究提供了清晰的路线图参考。

技术底座：高性能检测引擎的 ML 化升级

安全检测引擎正加速拥抱机器学习能力： Snort3/LibML [3]：由 snort3 团队维护的 LibML 项目，将 TensorFlow 与 XNNPACK 推理库深度整合，使 Snort 入侵检测系统获得本地化的 ML 推理能力，降低了对云端依赖。

Cisco Talos 于 2025 年 9 月发布 SnortML [4]：这是 Cisco 自家基于机器学习的检测引擎的重大升级版本，整合了更强大的模型推理管线，显著提升了已知威胁与未知变种的识别精度。

Napatech SmartNIC 加速方案 [5]：硬件层面，Napatech 通过其 SmartNIC 网卡实现了 Suricata 性能 4 倍提升，为高流量场景下的实时检测提供了底层支撑。

产业动向：头部厂商全面拥抱代理式安全运营

IBM [6] 于 2025 年 4 月宣布推出自主化安全运营平台，深度集成代理式 AI 能力，实现威胁发现、研判与响应的全流程自动化。

Trend Micro [7] 于 2025 年 8 月推出 Agentic SIEM，标志着主流安全厂商正式将"主动式代理"理念引入 SIEM 产品路线图，开启从被动日志分析向主动威胁猎杀的范式转变。

Omdia [8] 在 2025 年底的研报中明确提出"代理式 SOC"概念，认为 SecOps 正在向代理式平台演进，AI 代理将在事件分诊、剧本执行与跨系统协同中扮演核心角色。

前沿方向：零信任与联邦学习的融合

学术前沿持续探索安全 AI 的新架构。Singh 等人提出的零信任代理式联邦学习框架 [9]，针对工业物联网（IIoT）场景，构建了一套兼顾隐私保护与威胁防御的分布式 AI 方案，将零信任架构与联邦学习深度融合，为高安全性要求的 IIoT 环境提供了新的技术路径。

延伸阅读

• LibML: TensorFlow + XNNPACK inference library
• IBM delivers autonomous security operations with cutting-edge agentic AI
• Trend Micro launches Agentic SIEM
• The agentic SOC: SecOps evolution into agentic platforms
• AI-Augmented SOC: A Survey of LLMs and Agents for Security Automation
• A Survey of Agentic AI and Cybersecurity: Challenges, Opportunities and Use-case Prototypes
• 4x Suricata Performance Increase for Napatech SmartNICs
• SnortML: Cisco's ML-Based Detection Engine Gets Powerful Upgrade
• Zero-Trust Agentic Federated Learning for Secure IIoT Defense Systems
• Talos 发布全新基于机器学习的漏洞检测引擎
• 用 SnortML 检测零日漏洞
• SnortML：基于机器学习的漏洞检测
• SnortML 官方文档