入侵检测系统正从几乎完全依赖已知签名，转向结合传统匹配、机器学习和代理式调查的混合架构。Stack Overflow 博客上发布的一篇分析认为，SnortML 代表了 Snort 3 内部的低层感知层，而代理式人工智能则负责跨时间和来源关联事件，并决定调查中的下一步行动。
传统签名的问题不在于它们不准确，而在于它们只对其设计目标保持准确。例如，针对某个特定漏洞（如 CVE-2024-12345）的规则，可能以极低的误报率捕获已知利用，但对于经过修改、仍通过同一脆弱代码路径的载荷，可能无法做出响应。从新的利用在实际环境中出现，到完成分析、编写规则、测试规则并进行分发，可能需要数天或数周；当漏洞正在被实际利用时，这是一段危险的时间差。
SnortML 如何在 Snort 3 中运行？
Cisco Talos 于 2024 年 3 月推出 SnortML 引擎，并将其描述为原生运行于 Snort 3 内部的机器学习检测引擎。该引擎不依赖外部云服务，而是在与规则评估所使用的同一处理路径中进行本地推理，并在不到 1 毫秒内输出结果。
该实现由 snort_ml_engine 模块和 snort_ml 检查器组成。前者在启动时加载预先训练的 TensorFlow 模型，后者通过发布—订阅接口从 Snort 3 中现有的服务检查器接收数据。当 HTTP 检查器完成请求分析后，它会将查询字符串和 POST 内容发送到事件总线，随后由 SnortML 对其进行分类，并返回一个概率值，表示其中可能包含利用尝试的可能性。
该模型采用 LSTM 网络，前置嵌入层会将原始字节值转换为向量表示，从而捕捉字节之间的关系和上下文；随后由 LSTM 处理其顺序和序列。最后的全连接层将结果压缩为单一概率值。SnortML 随附的 LibML 使用 XNNPACK 库加速矩阵运算。根据该材料，在频率为 4.7 GHz 的 AMD 处理器上，单次分类耗时约为 350 微秒。
从 Secure Firewall 10.0.0 开始，SnortML 会自动为 256、512 或 1024 字节的长度选择合适的模型。超过 1024 字节的请求会在分类前截断至该长度。首个版本从 SQL 注入检测开始，到 2025 年底，覆盖范围已扩展至 XSS 和命令注入；模型更新通过 Lightweight Security Package 系统下发，该系统也用于分发规则内容。
混合方法的优势与局限
SnortML 与签名匹配并行工作，而不是取代后者。该模型能够捕捉属于已知类别攻击的新变体，而传统签名则为已确认的模式提供低噪声检测线。当两条路径对同一载荷同时发出告警时，这可以被视为比仅由机器学习发出的告警更强的信号，同时每种机制仍具有不同的错误特征。
但 SnortML 分析的是单个 HTTP 参数，例如 URI 查询字符串或 POST 内容；它不知道请求之前或之后发生了什么，也不知道源地址在前几分钟内做过什么。因此，一系列侦察、枚举和定制化利用可能在每个单独步骤都未超过检测阈值的情况下通过。当前模型也无法观察 DNS 隧道、TLS 层攻击、SMB 利用或非 HTTP 协议中的异常行为，因为现有模型与 HTTP 检查器的数据路径相关联。
此外，约 350 微秒的处理时间会带来实际开销，尽管借助 XNNPACK，这种开销有限且可预期。因此，不应脱离规则集规模、协议复杂度以及防护设备的处理预算来单独看待模型性能。
代理式人工智能增加了什么？
该分析区分了三类系统：只评估眼前内容的机器学习模型；按照固定步骤执行的 SOAR 运行手册；以及能够保存多阶段调查状态，并根据此前结果决定接下来应检查什么的代理。按照提出的设想，代理可以从 SIEM 查询相关事件，通过威胁情报平台检查文件指纹，从身份提供商检索用户活动，然后汇总上下文，再建议响应措施或将其提交给人工分析师。
文章提到 IBM 于 2025 年 4 月推出 ATOM（Autonomous Threat Operations Machine）平台，以及 Trend Micro 于 2025 年 8 月推出 Agentic SIEM。这些系统被描述为多代理协调与调查平台，而不仅仅是配备安全信息的聊天界面。该分析将它们的普及与人才短缺压力联系起来：全球网络安全领域约有 400 万个职位空缺；此外，2025 年的一项调查显示，82% 的安全运营中心分析师担心由于告警数量过大而漏掉真实威胁。
在这一架构中，Snort 3 和 SnortML 成为靠近网络的传感器，向更高层的推理层提供实际观察到的信息。但自动化程度越高，传感器的准确性就越重要：误报不仅会占用分析师时间，还会消耗代理资源，并可能在配置不当的环境中触发遏制措施。SnortML 的概率结果还可以用于构建综合置信度评分；例如，同时包含传统签名和 0.97 ML 分数的告警，应与仅由 ML 以 0.61 分数触发的告警区别处理。
集成架构与反馈回路问题
文章提出的架构从通过 DAQ 进行的数据包捕获层开始，根据吞吐量要求使用 AFPacket RSS 或 DPDK；随后是检测层，并行运行 MPSE Hyperscan 引擎和 SnortML。两层都会将包含告警、概率分数和流数据的 JSON 事件发送到统一的遥测总线。
之后，任务分配给专门的代理：负责分类、去重和严重性评估的代理；负责富化和威胁情报的代理；负责关联 SIEM、身份提供商和端点数据的调查代理；以及将活动与历史模式和已知活动进行比较的上下文代理。该设想强调，必须将已确认调查的结果反馈给模型引擎和规则引擎，而不能让流程在响应阶段停止。
那些已被证实为攻击、但获得较低分数或未匹配任何签名的载荷，可以转化为训练数据，或成为制定新规则的输入。不过，这一流程需要人工验证以及训练数据投毒检测机制；攻击者可能试图操纵自动化调查结果，将污染样本引入重新训练过程。
部署限制与实用建议
该分析还指出了其他缺口，包括当前 SnortML 的覆盖范围仅限于 HTTP 参数、代理协调协议尚不成熟，以及模型告警的可解释性较弱。目前的输出会显示概率分数和触发告警的载荷，但不会说明输入中的哪些字节或区域影响了结果。此外，根据该材料，在已发布的评估中，模型抵御混淆、编码、空格操纵以及 SQL 注释注入的稳健性尚未得到公开说明。
实际上，文章建议在监控端口上以仅告警模式启动 SnortML，而不是将其置于带有阻断功能的直通路径中。应至少用覆盖常规工作周期的两周时间，在已知应用流量上测量误报，然后在启用选择性 inline 部署之前调整阈值。此外，还应将 ML 分数作为复合置信度计算中的一个因素，而不是传统签名的替代方案，也不应将其作为触发阻断的单一条件。
至于阻断 IP 地址、隔离设备或重置凭据等高影响遏制措施，则应继续置于人工审核环节之内。分析的核心结论是，自动化可以高效地承担分流、信息丰富、关联和上下文汇总工作，而最终响应决策在由人类根据代理收集的上下文进行审核时，仍然更加安全。