过滤器生成实践 · 从算法到大语言模型

原创

Securelist
Securelist

网络与信息安全参考

2026年10月31日 10:04
山东

去阅读

安全技术观察2026.10.30

过滤器生成实践 · 从算法到大语言模型

卡巴斯基安全专家详解安全告警过滤器的三种自动生成方案——纯算法、单模型 LLM 与多智能体协作，并给出采用率与误报削减率的实测对比。

档案

每天数千条安全告警，大部分是误报——这篇文章讲如何让机器自己写过滤器

SOCLLM

导读

SECURELIST · 2026.10.30

现代组织依靠一整套安全技术保护自己的信息系统，每天产生的安全告警数以千计。把这些告警放在一起看，会发现其中很大一部分是误报。理想情况下，这些告警应该被自动过滤掉，让分析师能够集中精力处理那些可能指向真实事件的部分。但编写过滤器本身就是一件耗时的工作。

要创建一条正确的过滤器，分析师需要：

• 查阅日志
• 定位活动来源
• 划定过滤边界
• 选择过滤条件
• 编写规则
• 检查过滤器是否稳健

本文要讨论的，正是如何把编写过滤器这件事本身自动化，从而减轻分析师的负担。

01

PART

过滤器的有效性标准

FILTER VALIDITY CRITERIA

在安全告警的语境下，过滤器是若干事件字段值的组合，作用是把某条检测判定为误报，不值得分析师关注。过滤器可以基于任意事件字段组合生成，但不是每种组合都能得出有效的过滤器。所以我们需要先定义有效性标准：一组条件，用来证明某条过滤器确实在消除噪声，而不是在压制有用的告警。

安全系统中的检测规则通常包含一组条件，每个条件都可能触发告警。一个特定的事件会触发检测规则中的某个片段。某个片段所响应的事件集合，我们称之为它的上下文。好的过滤器应该尽可能覆盖整个上下文，同时又不要超出上下文范围。过宽或过窄的过滤器都没有用处。举例来说，只基于 PowerShell 的过滤器会排除掉过多事件，其中一些本应得到分析师的关注，而且被过滤掉的事件大多也与触发规则无关。反过来，只基于某个特定 ID 的过滤器只能覆盖一个事件，而这个事件可能永远不会再次出现。

02

PART

过滤器生成中的问题

PROBLEMS IN FILTER GENERATION

创建过滤器时会遇到一系列问题。首先是事件往往包含过多字段（平均约 400 个），其中大多数对过滤并无必要。与此同时，对这些字段的组合进行生成和排序也相当消耗资源。因此第一步是剔除无关字段，只保留值得写进过滤器的字段。例如，一个事件有 400 个字段，其中 4 个可能就足够完成过滤。

另一个问题是字符串归一化。字段值（比如同一应用程序在不同系统上的路径）会随系统设置、用户文件夹名称等因素而变化。过滤器要覆盖所有这些变化，就必须先对字符串做归一化。特别是文件路径，可以用标准环境变量替换盘符和用户文件夹，并将所有路径统一为同一大小写。

最后，如果过滤器完全复刻检测规则的查询条件，它实际上会让这条规则失效。解决办法是在过滤器中移除检测规则用到的事件字段。例如，如果规则基于文件路径触发，有两种方法可以过滤掉不需要的告警：

• 在过滤器中使用文件路径以外的字段。
• 使用规则未用到的路径片段。例如，对于规则 file\_path: \".../something.exe\"，可以设置一条过滤器，排除文件路径中包含 user/unique\_files/ 目录的事件。

03

PART

用算法过滤安全告警

FILTERING SECURITY ALERTS WITH AN ALGORITHM

针对上面这些问题，安全告警过滤器的自动生成应由以下步骤组成：

STEP 1

分析师收到一条安全告警，评估后认为是误报，于是调用过滤器生成器。

STEP 2

生成器从告警中取出包含 400 个字段的事件以及触发它的规则，确定事件的上下文。

STEP 3

生成器筛选出与过滤器相关的字段。

STEP 4

生成器对字符串进行归一化。

STEP 5

生成器基于所选字段构建不同的组合。为此，我们在前文确定的上下文上应用了 FP-Growth（频繁模式增长）算法。FP-Growth 从数据集（本文中即上下文）构建频繁出现项（字段）的树，并丢弃出现不够频繁的项。这减少了需要检查的组合数量，也就降低了找出最相关组合的成本。

STEP 6

生成器对生成的组合排序，为分析师提供排名前三的候选。

例如，考虑下面这个用 JSON 描述的事件：

算法方法示例：触发检测规则的安全事件（JSON 格式，部分字段高亮）

生成并对组合排序后，我们得到三个基于文件路径的过滤器：

• processcmdline:(\"nodejs\\
  ode.exe\" AND \"\\\\\*\\appdata\\roaming\\
  pm\/node\_modules\/pi-coding-agent\/dist\/cli.js\")
• file\_path:\"\\\\\*/.pi\\agent\\bin\\fd.exe\"
• processcmdline: \"programfiles\\
  odejs\\
  ode.exe\"

最后一个过滤器过于宽泛，分析师把另外两个标记为有效。

优缺点算法方法的优势与不足

算法方案有几个优点。第一，简单且确定：同一条告警总是产生相同的结果。第二，可解释：我们能看清某个组合为什么排在候选列表前列，也能弄清某个字段为什么根本没进候选字段列表。第三，流程的各个阶段相互独立，可以单独改进和调整个别步骤，不用担心破坏算法的其他部分。最后，它不依赖外部组件或模型，可以方便地部署在任何客户环境中。

但它也有缺点。第一个是依赖上下文。如果由于某种原因没有上下文——例如规则第一次被触发——就无法创建过滤器。第二个问题是字符串归一化：很可能遇到归一化规则没有覆盖的非典型情况，这类情况往往无法被正确描述，因为它们彼此矛盾。

这些问题可以交给大语言模型（LLM）解决。由 LLM 生成过滤器时不需要上下文，因为它不会遍历组合，也不会给组合排序。LLM 处理字符串归一化的方式也更灵活，非标准情况也能应对。话虽如此，LLM 也不必参与生成过程的每个阶段。我们决定在算法擅长的环节继续用算法。例如，一个简单算法筛选合适字段从不出错，所以我们没有把这一阶段交给模型。

04

PART

用大语言模型生成过滤器

FILTER GENERATION WITH AN LLM

基于 LLM 的过滤器生成流程是这样的：

LLM 过滤器生成流程：算法阶段负责候选字段筛选（与原方案一致），LLM 阶段基于所选字段生成三个过滤器选项，并附基于推理的说明

输入仍然是一条告警，其中包含一个 400 个字段的事件，以及触发该事件的规则。然后由算法为过滤器筛选出最合适的字段。接下来，LLM 处理这些输入——事件、所选字段和检测规则——生成三个过滤器选项，并各附一份解释。解释能帮助分析师理解为什么会推荐这几条过滤器，从而做出有依据的选择。

考虑下面这个 JSON 格式的事件：

LLM 方法示例：安全事件（JSON 格式，部分字段高亮）

LLM 给出了三个过滤器选项，都包含同一段命令行片段：

• file\_path: \"\\WindowsPowerShell\\powershell.exe\" AND filecmdline: \"Get-VM -Name kafka\\*\"
• filecmdline: \"Get-VM -Name kafka\\*\"
• filecmdline: \"kafka\*\"

和上一个例子一样，三个输出过滤器中有两个有效，最后一个太宽泛、用不了。分析师选了第一条，只做了小幅修改：

file\_path: \"powershell.exe\" AND filecmdline: \"Get-VM -Name kafka\\*\"

优缺点LLM 方案的优势与不足

LLM 解决了纯算法方案的两个问题：对上下文的依赖，以及字符串归一化中的错误。不过，单请求方案也有自己的短板。首先，它没有输出验证：LLM 原样返回过滤器，没有语法检查，也没有纠错机制。其次，与算法版本不同，所有过滤器生成任务都压在同一个系统提示词里。结果是，一处的小改动可能弄坏另一处的逻辑。

05

PART

使用多个 AI 智能体

USING MULTIPLE AI AGENTS

为了解决单模型、单系统提示词的问题，我们尝试把任务分派给不同的 LLM 智能体。在这个版本里，早在筛选相关字段的阶段就引入了智能体。整条链一共四个智能体：

Selector（选择器）

筛选相关字段。

Generator（生成器）

生成过滤器。

Validator（验证器）

评估生成的过滤器。如果过滤器无效，它把任务退回生成器；如果发现所选字段不相关，它就启动新一轮字段筛选；如果过滤器通过验证，或者达到重新生成次数上限，有效的过滤器（或当前可用的最佳过滤器）会被交给分析师。

Commentator（评论器）

分析输出的过滤器，解释用到了哪些字段值、为什么用。

对于下面这个 JSON 事件，智能体产出了三个基于文件路径的有效过滤器：

多智能体方法示例：安全事件（JSON 格式，部分字段高亮）

这几条过滤器的差别在于支撑检测的附加参数不同：

• file\_path:\"sysvol\\domain\\scripts\\logon.bat\"
• file\_path:\"sysvol\\domain\\scripts\\logon.bat\" AND file\_md5:\"0x7..6E\"
• autorun\_entry: \"Group Policy\\State\" AND file\_path: \"SYSVOL\\domain\\scripts\\logon.bat\"

优缺点智能体方案的优势与不足

LLM 智能体给了一套能验证并纠正过滤器的系统，模块化架构也让我们可以独立调优和改进生成过程的不同阶段。不过，这种方案比前两种发起更多次 LLM 调用，系统更慢；它还依赖模型的可用性，而在组织的隔离环境里，模型不一定能访问。

06

PART

评估过滤器生成系统

EVALUATING THE FILTER GENERATION SYSTEM

为了评估过滤器生成系统的实际效果，我们使用两个主要指标：

采用率（approval rate）

对每条安全告警，系统给出三个过滤器。如果分析师至少选中其中一个，本次生成即计为成功。例如在下图的案例中，采用率是 2/3。

采用率计算示例：三条告警中两条成功选用过滤器，采用率为 2/3

误报削减率（FP drop）

这个指标显示的是一条过滤器对减少误报数量的帮助。它只能随时间推移来测量，因为需要对比过滤器部署前后、固定时间段内收到的误报数量。

下面是三种过滤器生成方法在这两项指标上的对比：

三种过滤器生成方法的评估结果对比

结果显示，LLM 显著提升了过滤器生成的效率。同时，无智能体的 LLM 方案与基于智能体的方案表现几乎一致。因此我们选择了更简单、更快的选项：单一系统提示词的 LLM。最终结果是，误报减少了 99%，每天生成的过滤器数量增加了 28%，分析师的告警处理效率提升了 17%。

///

END

要点总结

TAKEAWAYS

实践表明，过滤器生成可以有效自动化。我们考察了为误报安全告警自动生成过滤器的三种方案：纯算法方案、基于 LLM 的方案，以及基于一组 LLM 智能体的方案。它们都能生成有效过滤器，都能让分析师的工作轻松不少，但各有长处和短处。

算法方案在评估指标上得分较低，但仍有三分之二的情况下能产出令分析师满意的过滤器。当已经积累了一批待过滤的相似事件、上下文足够充分时，它的效果尤其好。算法生成器还可以部署在任何环境中。独立 LLM 方案和多智能体 LLM 方案都表现出高准确率，结果相差很小，因此在这个阶段，更慢的智能体方案显得有些多余。

如果能用上 LLM，最佳选择似乎是由单一模型处理生成周期中的几个阶段。

AArtemy Obukhov ｜ 卡巴斯基 Securelist

本文译自卡巴斯基 Securelist 文章《Filter generation in practice: from algorithms to LLMs》（2026 年 10 月 30 日发布），原文链接：https://securelist.com/practical-filter-generation/121697/ 。译文仅供学习交流，观点与结论归原作者及卡巴斯基所有。

如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见

赞

在看

收藏

THANKS FOR READING

更多 山东区域  卡巴斯基 KAIP 安全解决方案 详情，请联系：

高进 - 186 6376 1060