当传感器开始思考：SnortML、自主 AI 和入侵检测架构的演变

标题：当传感器开始思考：SnortML、自主人工智能与入侵检测架构的演变

来源 URL：https://stackoverflow.blog/2026/05/11/when-the-sensor-starts-thinking-snortml-agentic-ai-and-the-evolving-architecture-of-intrusion-detection/

每套入侵检测系统（IDS）部署都存在一个漏洞。任何一个运行时间足够长的人都会最终发现它，通常是在最糟糕的时候。这个漏洞存在于你编写规则所针对的内容和攻击者选择采取的不同行动之间。经典的 Snort 签名确实令人印象深刻。一条精心设计的规则可以几乎零误报地捕获已知的漏洞，并且其开销在性能分析器上几乎无法察觉。这种精确性来自于特定性，而正是这种特定性构成了整个问题。为 CVE-2024-12345 编写一条规则后，你就覆盖了该漏洞。但通过稍微不同的路径清除相同脆弱代码路径的修改负载？什么都不会触发。

这不是对签名模型的批评。它完全按照设计工作。签名编码了关于攻击在物理层看起来是什么样子的具体、可验证的知识，而低误报率正是这种特定性的直接产物。真正的限制是更难解决的问题：暴露时间。从新型漏洞出现在野外到研究人员捕获它、逆向工程它、编写规则、针对测试语料库验证规则并将其通过更新通道发布出去，可能需要几天甚至几周的时间。对于常见的软件中被积极利用的漏洞，这个窗口并非假设。

思科 Talos 在 2024 年 3 月直接解决了这个问题，推出了 SnortML，这是一个机器学习检测引擎，原生运行在 Snort 3 内部。与此同时，安全操作领域的更大转变开始获得广泛关注：自主人工智能进入网络防御领域。这两个发展在相同的转变层次上运作，同时考察它们揭示了一些单独观察其中一个时看不到的东西。

在架构和影响之前，机制很重要。SnortML 不是一个附加在 Snort 告警输出上的通用异常评分器，也不是每次请求都向云端声誉服务报告的服务。推理完全在本地设备上进行，在与正常规则评估相同的处理管道内完成，而且在不到一毫秒的时间内得出结论。

两个组件使这一切得以实现。snort_ml_engine 模块在启动时负责加载模型，将预先训练好的 TensorFlow 模型加载到内存中，并在整个会话期间将其作为分类器使用。然后，snort_ml 检查程序通过 Snort 3 已经使用的发布/订阅接口订阅来自 Snort 现有服务检查器的数据流。当 HTTP 检查程序完成解析请求后，它会将 URI 查询字符串和 POST 主体发布到事件总线。SnortML 检查程序接收这些数据，通过分类器运行它们，并返回一个表示内容包含攻击尝试概率的浮点数。

_神经网络不需要看到具体的攻击就可以标记它。它已经学会了 SQL 注入尝试在字节层面的形状，而这种形状在广泛的语法变化中仍然有效。_

模型架构是一个带有嵌入层的 LSTM。嵌入层将原始字节值映射到学习到的向量表示，以捕捉字节之间的关系，这是纯频率分析无法做到的。可以将其类比为自然语言处理中的词嵌入，只是这里的“令牌”是字节而不是单词。0x27（单引号）紧挨着 0x4F 0x52（OR）的字节值携带了关于 SQL 注入模式的学习上下文，嵌入层对此进行了编码。然后，LSTM 处理这些序列并捕获时间结构：字节的顺序很重要，攻击载荷往往具有区分合法查询字符串的特征顺序。

最后一层密集层将 LSTM 的输出压缩为单一的概率浮点数。LibML 是随 SnortML 一起提供的推理库，使用 XNNPACK 进行硬件加速的矩阵运算，以在负载下保持推理时间可预测。在 4.7 GHz 的 AMD 处理器上，一次分类过程大约需要 350 微秒。一个实用的细节值得一提：从 Secure Firewall 10.0.0 开始，SnortML 会根据实际查询长度自动选择适合 256、512 或 1024 字节输入的模型。短查询使用较轻量的模型。只有较长、更复杂的请求才会通过全尺寸推理。对于超过 1024 字节的查询，在分类前会将输入截断到该边界，这一点在处理生成异常长参数字符串的应用程序时值得记住。

初始版本专注于 SQL 注入检测。到 2025 年底，覆盖范围扩展到了包括 XSS 和命令注入攻击类别。模型更新通过 Snort 的轻量级安全包系统到达，使用与规则内容相同的更新通道，这意味着 SnortML 可以保持最新状态，而无需单独的更新流程。

技术注释：自适应模型选择

256/512/1024 字节模型选择不仅仅是性能优化。每个模型都是在该长度范围内的输入分布上训练的，因此较小的模型确实是专门为短查询校准的，而不是完整模型的截断版本。这在分析误报行为时很重要：一个看起来有点像注入的 200 字节合法查询会被 256 字节模型评分，该模型在训练期间看到了更多短查询流量的集中分布。理解哪个模型变体在给定警报上触发有助于调整阈值行为。

下面的图表展示了 Snort 的数据包处理管道中 SnortML 分类器的位置。SnortML 分类器与传统的特征匹配并行运行。请注意两条路径从检查器调度中分离的地方以及它们在判决阶段汇合的地方：两条路径中的任意一条都可以独立触发警报，并且当两条路径同时触发时的检测结果比仅由机器学习触发的结果具有显著更高的置信度。

图 1：Snort 3 中的 SnortML 推理管道

SnortML 并未取代特征评估。并行运行这一决定是经过深思熟虑的工程决策，而非过渡性妥协。针对某一漏洞类别训练的神经网络偶尔会对合法流量误报，这些合法流量的语法类似于攻击模式。例如，合法数据库查询中的 URL 编码特殊字符就是一个常见案例。运行特征与机器学习模型并行意味着这两种机制提供了不同错误特征的独立覆盖范围：机器学习捕获了没有相应特征的新型变体，而经典匹配则为已知模式提供了低噪声基线。当两者对相同的有效载荷触发时，这种相关性对下游系统来说是有意义的信号。

延迟影响经过了仔细测试。350 微秒的开销是真实的，需要结合上下文理解。在当前 Cisco Secure 防火墙设备上的高吞吐量 Snort 部署中，每包处理预算从几百微秒到几毫秒不等，这取决于规则集大小和协议复杂性。增加 350 微秒并非可以忽略不计。这就是 XNNPACK 加速至关重要的原因：它使机器学习开销可预测且有限，而不是在负载下变得不可控。

SnortML 是一个专注于特定问题的工程解决方案。这种专注既是它的优势也是它的局限。它能够在设备上捕获已知漏洞类别的零日攻击变体，且无需外部依赖。在这个范围内，它表现良好。但正是这个范围本身让事情变得有趣。

分类器仅针对单个 HTTP 参数运行。一个单独的 URI 查询字符串或 POST 主体进入后会被评分，然后触发或不触发。模型看不到的是该请求之前的内容、之后的内容，或者同一源 IP 在过去二十分钟内的行为。考虑一个简单的三步序列：探测请求以映射应用程序的输入验证行为，枚举请求以识别可注入参数，最后根据前两个探测的结果定制的攻击尝试。每个请求单独来看可能得分低于阈值。由于前两个请求的存在，第三条请求更加危险，而 SnortML 无法看到这种关系。

同样的限制也适用于 HTTP 参数空间之外的内容。DNS 隧道外泄、TLS 层协议攻击、SMB 利用、基于时间的隐蔽通道、非 HTTP 服务中的协议行为异常：这些都不会通过 HTTP 检查器发布路径，因此 SnortML 永远不会看到它们。架构可以容纳其他检查器，发布/订阅接口足够通用以支持这一点。但是，针对这些数据源的训练模型尚不存在，为不太研究的协议组装标记训练语料库比为 HTTP 更加困难。

这都不是缺陷。这些都是任何基于每包、每参数操作的检测系统的自然约束条件。突破这些限制需要一种不同的推理方式：能够跨时间持有上下文，关联来自多个观察点的信号，并且不需要等待人类阅读报告后再行动。这就是安全运营中的主动型人工智能所构建的能力。

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

图 2：特征、SnortML 和代理各自操作的检测覆盖层

“主动型 AI”一词在安全营销中被广泛使用，以至于几乎失去了其原本的意义。有必要明确区分什么是真正的 AI 代理，与传统的机器学习模型或自动化的 SOAR 剧本到底有什么区别。

传统机器学习模型只对眼前的输入进行评分。它没有对先前输入的记忆，也无法去获取更多上下文，也没有机制来决定输出后接下来该做什么。SOAR 剧本采取另一种方式：由警报条件触发的一系列固定步骤，每个步骤都是预定义的。如果情况超出剧本预期的分支，自动化就会停止并转交给人工处理。这两种方法都有实际价值，但它们都不是代理。

AI 代理在整个多步调查过程中保持状态。它根据已经发现的内容决定下一步要看什么，而不是遵循预先设定的顺序。它调用工具：查询 SIEM 获取相关事件，对照威胁情报平台查找文件哈希，从身份提供者拉取被标记用户的近期活动，检查源 IP 是否出现在 BGP 级黑名单中。每次查询都会影响后续步骤。当调查达到需要响应的阶段时，代理要么执行操作，要么移交足够的上下文信息，使得审查其建议的人类只需几秒钟而不是几个小时。

商业安全行业大约花了两年时间走向这一目标。IBM 在 2025 年 4 月推出了自主威胁操作机器（ATOM），将其定位为一个多代理框架，位于 SIEM 分析之上，用于处理调查和修复工作流。趋势科技在 2025 年 8 月发布了他们的自主 SIEM，从底层设计围绕自主关联和调查展开。这些不是带有安全领域知识的对话界面，而是专门的代理通过功能划分来分工协作，并在彼此间传递结构化结果的编排平台。

从劳动力市场的角度来看，这种采用速度就更有意义了。全球网络安全人才缺口约为四百万个未填补的职位。2025 年的一项调查显示，82% 的 SOC 分析师表示，仅因警报量大而担心会错过真实威胁。这些数字描述了一个处于结构性压力下的系统，而工具并未解决这个问题。增加另一种检测能力而不改变如何进行初步评估和调查的方式只会产生更多警报，而不是更好的结果。因此，采用生成式人工智能并不是因为它理论上优雅，而是因为另一种选择——让更多的分析师阅读更多的警报——不是一个可行的扩展路径。

在这个背景下，Snort 3 配合 SnortML 扮演了一个特定且重要的角色：传感器。它是离实际网络线缆最近的地方，以数据包速度运行，持续生成代表网络上实际观察到事件的事件流。这个事件流是高层次推理所依赖的真实依据。

在生成式架构中，这种定位比传统 SOC 中更有价值。在传统设置中，Snort 警报到达 SIEM，分析师对其进行初步评估。分析师也是错误修正层：他们阅读上下文，决定警报是否值得调查，并手动追踪它。在生成式架构中，Snort 的输出直接喂入自动化推理链。误报不会简单地消耗分析师的注意力，它们会消耗代理计算资源，填满调查队列，并可能在配置不当的情况下触发自动隔离操作。传感器层的准确性要求提高了。

SnortML 的概率性输出在这方面提供了具体帮助。由于分类器返回的是浮点数而非二进制匹配，生成式层可以将该概率纳入其自身的置信评分中。一个结合经典签名匹配和 0.97 SnortML 得分的警报与仅由 ML 触发得分为 0.61 的警报会被路由到不同的地方。更丰富的输出给下游推理提供了更多信息，使基于阈值的升级逻辑更加精细。

下图展示了多代理 SOC 架构如何跨专业功能协调。每个代理负责调查的一个环节：初步评估、丰富、深度关联、上下文历史。注意严重性评估和响应中的决策点：两者都是明确的分支结构，而不是线性管道，这使得可以根据风险级别进行适当的人类参与，而不是对每个警报一视同仁。

图 3：生成式人工智能 SOC 架构，多代理协作模型

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

捕获层通过 DAQ 层处理线级数据包获取，根据吞吐量需求通过 AFPacket RSS 队列或 DPDK 将数据提供给 Snort 的分析线程。检测层并行运行 MPSE Hyperscan 规则引擎和 SnortML LSTM 分类器，两者都通过遥测总线馈送到统一的事件流中。该流携带 JSON 格式的警报数据、ML 概率得分和流元数据。这里模式很重要，因为无论什么生成式框架位于其上，都需要解析和推理这些数据：不同警报类型字段命名的一致性或值的差异会在规模扩大时造成集成摩擦。

生成式推理层接收该事件流，并按功能分配给专门的代理。初步评估代理负责去重、过滤和初始严重性评分。丰富代理拉取 IOC 数据、IP 声誉和威胁情报。调查代理跨 SIEM 数据、身份提供商日志和端点遥测进行关联。上下文代理将当前活动映射到历史模式、来自同一来源的先前警报和已知活动签名。

下图显示了从捕获层到生成式推理再到反馈回路的完整集成。最重要的结构特征是从响应层返回到 ML 模型和规则引擎的路径。这个反馈连接是大多数现有部署所缺失的。

图 4：完整集成，Snort 3 + SnortML 喂入生成式 SOC 流程

大多数现有部署在检测到生成式交接处中断。代理接收 Snort 输出，进行调查并采取行动。没有任何东西返回来改进 Snort 的检测能力。每个代理完成的确认攻击调查都包含 ML 训练管道可以使用的信息：低于阈值但实际上是真实的负载、未被任何签名覆盖的变体、分类器学习到的新伪装模式。这些数据，经过标记和结构化，目前被丢弃，是训练信号。

捕获它的技术路径并不复杂。已确认事件中的 HTTP 参数数据已经存在于告警遥测中。提取这些数据，通过人工验证步骤，并将其输入到周期性重新训练作业中即可。Cisco 的 LSP 交付机制可以通过与规则更新相同的渠道推送更新的模型。围绕这一过程的组织流程比技术方面更难，特别是人工验证步骤。理论上，对手可以通过精心设计的活动模式（看起来像是成功的攻击）来操纵调查代理的确认，从而随着时间推移将中毒的训练样本引入管道。这种威胁模型需要在重新训练输入上运行异常检测，而不仅仅是对实时流量进行检测。

开放研究问题：反馈安全

从生产流量中获取数据的自动化模型更新管道面临一类与规避问题不同的对抗性攻击。通过协调活动导致虚假确认的攻击者可以在不直接接触推理路径的情况下引入损坏的训练样本。重新训练管道需要自己的异常检测层。Singh 等人（arXiv 2512.23809）在联邦入侵检测系统环境中使用 SHAP 权重拜占庭检测解决了该问题的分布式版本，这是目前最完整的已发表处理方法。在集中式架构中，这仍然没有得到解决。

以下是尚未实现的内容及其对当前部署这些系统的人员的重要性。

当前的 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 广泛采用都将大大减轻这种负担。

当 SnortML 触发并且调查代理将发现升级给人类分析师进行最终批准时，该分析师有一个合理的问题：哪个部分的负载触发了这个？不是整个 URI，而是具体哪些字节使分数超过了阈值。是一个单引号字符的存在吗？还是一个特定的序列，类似于 UNION SELECT 模式？当前的 SnortML 告警输出提供了概率分数和触发负载内容。它没有提供关于该分数如何归因于特定输入区域的信息。

基于梯度的归因方法，特别是应用于 LSTM 输入嵌入层的综合梯度，可以为此类顺序模型生成字节级别的重要性评分。该技术已被很好地理解，并已应用于具有类似架构的文本分类任务。为 SnortML 实现它意味着在推理路径中添加归因计算，并扩展 GID:411 告警格式以携带该输出。工程路径是明确的。所有这些都没有被构建到当前的生产系统中。

下图显示了当前告警数据流与缺失的部分对比。左侧路径是分析人员和代理今天接收到的内容。右侧路径是如果实现了归因输出后可用的内容。两条路径都源自相同的推理传递，因此差距不是架构上的。这只是关于从推理运行中展示什么的问题，而这些信息已经具备计算条件。

图 5：SnortML 告警数据流，当前输出与缺失内容

通过神经网络检测 SQL 注入是一个监督学习问题。该模型是在一组已知攻击模式的语料库上训练的，并学会了一种决策边界，将它们与良性流量区分开来。理论上，意识到 SnortML 已部署的对手可以系统地探测这条边界：尝试模糊变体、字符编码技巧、SQL 注释注入、空白字符操作以及其他规避技术，以找到在保留漏洞功能的同时得分低于检测阈值的输入。这是标准的对抗性机器学习问题应用于网络安全领域。这不是理论上的。

缺失的是任何关于这条边界位置的公开描述以及在故意攻击下的稳定性。SnortML 当前正在生产中的 Cisco Secure 防火墙部署中运行。运营安全社区应获得公开的对抗性鲁棒性评估：哪些攻击类别逃避了模型，以何种速率，在何种混淆技术下。这项工作尚未公开出现。它应该出现。

以下五个方向在现有文献中没有明确的答案。每个方向都足够具体，可以作为研究项目进行探索，并且在部署的系统中具有足够的意义。

目前的 LSTM 只处理单个 HTTP 参数序列。一个有意义的架构扩展是在同一会话内来自相同源 IP 的请求窗口上运行。实际上，这可能意味着固定窗口中最近的 10 或 20 个请求，或者活动时间为 60 到 120 秒的时间窗口，以较短者为准。在利用侦察阶段的攻击者表现出特征性的时序模式：探测请求测试输入处理，一次或多次枚举请求识别可注入参数，然后根据探测结果定制的攻击。无论单参数分类器的每次请求评分有多好，它在结构上对这种模式是盲的。

基于 Transformer 的模型在这样的会话窗口上运行将是检测能力向前迈出的重要一步。工程上的挑战是真实的：Snort 当前的数据传递模型将单个参数值传递给机器学习检查器。构建会话级别的特征向量需要更改检查器如何跨多个请求缓冲和累积输入的方式，这涉及到检查器生命周期管理和内存处理。研究的问题在于检测改进是否值得这种架构复杂性。

当 SnortML 在确认的真阳性触发时，触发的 HTTP 参数包含语法模式，经验丰富的规则编写者在起草签名时会立即注意到这些模式。拥有访问该有效载荷、熟悉 Snort 规则语法以及一些精心编写的现有规则示例的大型语言模型可以尝试起草覆盖相同情况的候选签名。生成的签名一旦验证通过，就会为该攻击模式提供明确的经典覆盖，因此未来的实例即使没有机器学习推理也会触发。

这形成了一个真正有用的循环：机器学习检测处理没有签名覆盖的新案例，而确认的检测反馈到一个管道中，从而加强经典覆盖。研究问题具体且可衡量：LLM 生成的 Snort 规则与手动编写的规则在误报率、有效负载变体的泛化能力和处理开销方面相比如何？这个比较有可发表的答案，并对检测规则管道的人员配置和自动化方式产生实际影响。

安全行业正在部署具有真实遏制决策权限的主动式 SOC 平台，但几乎没有正式基准来衡量这些代理的实际调查效果。供应商提供的指标主要关注数量减少：每小时处理的警报数、从警报到关闭的时间、节省的分析师工时。这些都无法告诉你代理是否做出了正确的决定。

一个更有用的基准框架应直接测量调查准确性：自动遏制操作由确认的误报触发的比例，真正恶意活动被归类为低严重性并自动关闭的比例，以及在定义的时间窗口内代理组装的上下文包导致正确分析师决策的比例。构建该框架需要带有已知地面真相的真实事件调查数据集，这既是数据收集问题，也是指标设计问题。这项工作是必要的，但在现有文献中几乎不存在。

对于今天部署 Snort 3 并试图了解 SnortML 和主动工具如何融入其堆栈的团队，有几个运营经验值得提前了解。

SnortML 的 HTTP 参数分类器虽然误报率较低，但并非为零。在不了解其针对特定流量配置文件的行为之前，将其在线运行并在检测到时阻止是一种导致生产中断的简单方法。使用非标准编码的参数化查询的合法应用程序、在查询字符串中传递数据结构的 REST API 或具有非标准转义行为的框架都可能生成得分高于默认阈值但并不恶意的输入。

正确的初始部署是被动的。捕获 SnortML 警报作为事件，至少在两个涵盖正常业务周期的星期内测量其对已知良好应用程序流量的误报率，并在启用阻止功能之前建立对模型在其特定协议和应用程序模式下行为的基本理解。在 Cisco FMC 中，在此评估期间将 GID:411 规则设置为仅报警。一旦建立了基线，就可以进行阈值调整和选择性在线部署。

如果你正在基于 Snort 构建主动调查逻辑，切勿将 SnortML 分数高于 0.9 的情况视为与经典签名匹配的确认事件同等处理。这两种检测机制具有结构上不同的错误特征。经典签名在覆盖的模式上产生非常低的误报率，并且会遗漏变体。SnortML 在变体和新颖模式的覆盖方面表现更好，但在合法流量上以字节级攻击语法相似性为代价，携带非零的误报率。数据库查询中的 URL 编码特殊字符以及某些 REST API 身份验证方案可能会导致中等范围的分数。

正确的架构应将 ML 分数作为复合置信度计算的一个因素，而不是单独触发器。一个同时触发经典签名和 SnortML 的警报（两者均为 0.95）应与仅 ML 触发（0.72）的情况路由不同。结合信号，不要用一种替代另一种，也不要让 ML 分数单方面驱动自动化阻止决策，除非有佐证证据。

拥有权限阻止 IP、隔离主机或重置凭据的主动系统引入了一个容易低估的风险：了解你自动化响应逻辑的攻击者可以将其武器化。构造看似来自合法关键基础设施地址的流量并触发你的自动化阻止阈值，会使你的响应系统变成有针对性的拒绝服务能力。这不是理论上的假设；这是对采用积极自动化响应的组织已知的攻击者技术。

有效的运营姿态是不对称的：大量自动化调查，保守地自动化响应。让代理处理那些消耗分析员时间且不需要高风险判断的初步分类、丰富、关联和上下文构建工作。将最终遏制决策留给已经审查过代理收集上下文的人类。自动化将该审查的时间成本从小时减少到秒；人类判断步骤才是增加对抗韧性的地方。

从仅基于签名检测到混合 ML-签名覆盖的转变，以及从人工节奏调查到主动推理管道的转变，并不是一次性完成的。它是在逐步推进，每个阶段都依赖于其下一层的可靠性和输出质量。SnortML 代表了一个成熟的第一个阶段：一个生产部署的 ML 组件，解决了特定且明确的问题，而没有影响 Snort 部署始终依赖的性能或操作可靠性属性。

其上的主动层还不够成熟，但推动其采用的操作压力不会消失。警报量持续增长，分析师能力未能跟上步伐，新型攻击技术出现的速度超过了手动规则开发周期的跟踪速度。在过去十八个月里，商业平台已经足够成熟，可以用于生产部署。大多数组织目前发现自己处于数据包级 ML 检测与主动调查集成的阶段：意识到两层的存在，仍在努力可靠地连接它们。

反馈回路，其中确认的事件流回改进 ML 模型和规则覆盖范围，由人类监督但自动执行，是更长期的难题，也是最有价值的解决方向。一个能够更有效地捕捉攻击者实际行为而非一年前行为的检测系统，以有意义的方式改变了进攻和防御的经济性。Singh 等人的关于分布式入侵检测环境的拜占庭容错联邦学习的工作指出了当该循环大规模运行时需要具备的弹性：不仅仅是规避检测器，还包括主动操纵改进机制本身。

Snort 3 带有 SnortML 具备了正确的基础。剩余的工程工作不是关于传感器的检测能力。而是关于将传感器观察到的内容连接到智能行动推理系统的管道，以及将这些行动转化为随着时间推移不断改进的系统反馈路径。

参考文献

[1] Stultz, B. (2024, March 15). Talos 推出新的基于机器学习的漏洞检测引擎. Snort 博客. blog.snort.org

[2] Cisco. (2024). 使用 SnortML 检测零日漏洞. 白皮书. cisco.com

[3] Cisco Secure Firewall. (2024). SnortML：基于机器学习的漏洞检测. secure.cisco.com

[4] Snort 3 规则编写指南. (2024). SnortML 文档. docs.snort.org

[5] snort3/libml. (2024). LibML：TensorFlow + XNNPACK 推理库. GitHub.

[6] IBM 新闻室. (2025, April 28). IBM 提供尖端主动安全运营的自主 AI. newsroom.ibm.com

[7] Trend Micro. (2025, August 15). 趋势科技推出主动 SIEM. trendmicro.com

[8] Omdia. (2025). 主动 SOC：SecOps 进化为主动平台. omdia.tech.informa.com

[9] 多位作者. (2025, November). AI 增强 SOC：LLM 和代理用于安全自动化的调查. MDPI 系统, 5(4), 95.

[10] 多位作者。(2026年1月)。[代理人工智能与网络安全调查：挑战、机遇及用例原型][A Survey of Agentic AI and Cybersecurity: Challenges, Opportunities and Use-case Prototypes]。arXiv:2601.05293。

[11] Napatech。(2024)。[Napatech SmartNIC 四倍 Suricata 性能提升][4x Suricata Performance Increase for Napatech SmartNICs]。[napatech.com][https://www.napatech.com/support/resources/solution-descriptions/4x-suricata-performance-increase-for-napatech/]。

[12] Cisco Talos Blog。(2025年9月)。[SnortML：基于 Cisco 的 ML 检测引擎获得强大升级][SnortML: Cisco's ML-Based Detection Engine Gets Powerful Upgrade]。[blogs.cisco.com][https://blogs.cisco.com/security/snortml-cisco-ml-based-detection-engine-gets-powerful-upgrade]。

[13] Singh, S. K. 等人。(2025)。[用于安全 IIoT 防御系统的零信任代理联邦学习][Zero-Trust Agentic Federated Learning for Secure IIoT Defense Systems]。arXiv:2512.23809。