UDM 搜索结果与规则结果的比较

支持的平台:

在 Google Security Operations 中调查安全遥测数据时,您可能会发现统一数据模型 (UDM) 搜索查询返回的事件计数与实时 YARA-L 2.0 检测规则生成的检测结果之间存在差异。

虽然搜索查询和检测规则都使用 UDM 并共享核心 YARA-L 2.0 语法,但它们在不同的执行引擎上运行,评估不同时间窗口的数据,并且以不同的方式处理重复字段和重复数据删除。

以下部分介绍了搜索结果与检测规则提醒之间的差异,以及如何在调查期间协调结果数量。

主要区别总结

下表比较了 UDM 搜索查询与实时 YARA-L 2.0 检测规则的行为:

属性 UDM 搜索和统计查询 YARA-L 2.0 检测规则
执行模型 在搜索时针对历史索引日志的临时查询。 针对流式提取的数据或预定重放进行持续评估。
支持的部分 过滤语句,可选 match、可选 outcome、可选 deduporderlimit。不使用 eventsconditionoption 部分。 metaevents、可选的 matchoutcomecondition(必需)和可选的 option
回溯期 每次执行搜索时,扫描过去最多 90 天的历史已编入索引的数据。 在注入事件时持续评估事件。多事件规则会在配置的 match 时间窗口内进行评估(对于迟到的事件,除非使用 Retrohunt 运行,否则最长为 24 小时)。
结果行数限制 每次统计搜索执行最多返回 10,000 行。 对随时间推移生成的检测结果没有硬性上限,但每次检测最多会针对界面中的每个匹配变量对 10 个基础事件进行抽样。
重复字段 (any) 重复字段会隐式使用 any 评估行为。如果数组中的任何元素满足相应表达式,则条件匹配。 重复字段会展开为单独的行。对于多值重复字段,需要明确指定 any 运算符才能匹配任何项。
窗口化聚合 avg()stddev()max()sum() 等函数在 outcome 部分中不需要 window. 前缀。 outcome 中的统计函数和排序函数需要 window. 前缀(例如 window.avg())才能绑定到 match 窗口。
时间粒度(by** 与 over**) 支持滚动时间分组粒度(by <duration>over every <duration>,例如 by 1h)。不支持滑动窗口相关性(overbeforeafter)。 支持跳跃 (over <duration>)、翻滚 (by <duration>) 和滑动 (over <duration> before/after $pivot) 相关性窗口。
去重行为 返回所有匹配的事件或分组的统计信息行,除非定义了明确的 dedup 部分。 自动删除相邻窗口中具有相同 match 变量的重复检测,以防止出现大量提醒。
解析器和架构版本 使用搜索运行时处于有效状态的解析器归一化和架构表示法来评估数据。 基于事件提取时有效的解析器版本生成的事件表示形式运行。

重复字段和取消嵌套行为

UDM 搜索返回的匹配事件数量多于 YARA-L 检测规则的原因之一是,重复字段(例如 principal.iptarget.file.md5security_result.action 等数组)的评估方式不同。如需了解语法详情,请参阅重复字段

  • UDM 搜索:重复字段隐式使用 any 语义。如果您过滤 principal.ip = "10.0.0.1",搜索会返回 "10.0.0.1" 出现在 principal.ip 数组中任意位置的所有事件。
  • YARA-L 检测规则:重复字段会解除嵌套到单独的评估行中。如果您在编写检测规则条件时未使用明确的 any 量词语法,则针对多值重复字段的相等性检查行为可能与搜索中的行为不同。

包含显式 any 运算符的事件条件示例

为确保检测规则与 UDM 搜索的重复字段条件相匹配,请在事件条件中使用显式 any 运算符:

events:
  // Match if any IP in the repeated array equals the target IP
  any $e.principal.ip = "10.0.0.1"

窗口化聚合和语法差异

将 YARA-L 2.0 统计查询从搜索迁移到检测规则时,请调整 outcomematch 部分中的语法:

  • window. 前缀:在 UDM 搜索中,可以直接调用 $avg_bytes = avg(network.sent_bytes) 等统计函数。在 YARA-L 检测规则中,统计函数(avgstddevpercentilevariance)和排序函数(firstlast)需要 window. 前缀(例如 window.avg($e.network.sent_bytes)),以便将计算与规则的 match 窗口绑定。基本聚合函数(maxminsumcount)不需要前缀。如需了解详情,请参阅结果部分语法
  • 事件变量:检测规则需要将事件分配给事件变量(例如 $e.metadata.event_type = "NETWORK_CONNECTION"),而 UDM 搜索直接引用 UDM 字段,无需变量前缀 (metadata.event_type = "NETWORK_CONNECTION")。
  • 滑动事件窗口:检测规则支持复杂的滑动相关性窗口 ($e1.metadata.event_timestamp.seconds > $e2.metadata.event_timestamp.seconds),而 UDM 会按固定时间间隔 (by 1hover every 1d) 对数据集进行分组。如需了解详情,请参阅窗口化逻辑

去重和提醒抑制

UDM 搜索会报告所选时间范围内的每个匹配事件或汇总的事件桶。相比之下,实时检测引擎会应用自动去重和抽样:

  • 相同的匹配变量:如果检测规则在相邻的时间窗口内针对相同的 match 变量组合(例如,相同的 $hostname$user)触发多次,规则引擎会抑制重复的提醒,以减轻分析师的疲劳。如需了解详情,请参阅在搜索和信息中心中使用去重功能
  • 测试规则与直播引擎:在规则编辑器中手动运行测试规则时,使用的去重限制比直播引擎更宽松。使用历史数据测试规则时,检测次数可能会高于在提取这些事件时生成的实时提醒次数。

回溯期和提取延迟

  • 注入延迟:UDM 搜索统计汇总功能可对编入索引的日志数据运行。最近提取的事件可能需要短暂的索引编制延迟,然后才会显示在汇总搜索查询中。
  • 历史提取窗口:多事件检测规则会通过滚动窗口评估流式数据。如果事件的注入顺序有误,或者在发生时间戳之后超过 24 小时才到达,实时多事件规则可能不会生成检测结果。如需根据新规则或更新后的规则扫描较旧的历史数据,请运行 Retrohunt 作业。如需查看相关说明,请参阅针对历史数据运行规则
  • 解析器随时间的变化:如果解析器更新或更正,UDM 搜索中的历史扫描会立即反映更新后的归一化。实时规则检测结果反映了提取日志时日志的确切解析状态。

在调查期间核对数量

如果您发现 UDM 搜索查询与检测规则之间存在差异,请按以下步骤协调结果:

  1. 检查重复字段:验证您的事件条件是否过滤重复字段,并确保您的规则在适当的情况下明确使用 any
  2. 对齐时间窗口:确保搜索查询的时间范围与规则检测周期的开始和结束时间戳相匹配。
  3. 考虑去重:请注意,搜索次数表示原始事件量或未抑制的分组,而检测次数反映的是针对唯一 match 键的去重提醒。
  4. 验证解析器版本:如果旧事件在搜索结果中显示的 UDM 字段值与在旧提醒中显示的不同,请检查自原始事件被提取以来是否发生了解析器更新。

需要更多帮助?获得社区成员和 Google SecOps 专业人士的解答。