处理计划分析规则中的引入延迟
虽然 Microsoft Sentinel 可以从各种源引入数据,但每个数据源的引入时间在不同情况下可能有所不同。
本文介绍了引入延迟可能会如何影响计划分析规则,以及如何修复这些规则以弥补这些缺陷。
为什么延迟非常重要
例如,你可以编写自定义检测规则,将“运行查询的频率”和“所查找数据的时段”字段设置为每 5 分钟运行一次规则,查找过去 5 分钟的数据 :
“所查找数据的时段”字段定义了一个称为回溯期的设置。 理想情况下,如果没有延迟,此检测不会遗漏任何事件,如下图所示:
事件在生成后到达,并包含在回溯期中。
现在,假定数据源有一些延迟。 在此示例中,假设事件在生成 2 分钟后被引入 。 延迟为 2 分钟:
该事件在第一个回溯期内生成,但在第一次运行时不会引入 Microsoft Sentinel 工作区。 下次运行计划查询时,会引入该事件,但生成时间筛选器会删除该事件,因为其生成时间已超过 5 分钟。 在这种情况下,规则不会触发警报。
如何处理延迟
注意
可以使用下面所述的过程解决此问题,或者实现 Microsoft Sentinel 的近实时检测 (NRT) 规则。 有关详细信息,请参阅使用 Microsoft Sentinel 中的近实时 (NRT) 分析规则快速检测威胁。
若要解决此问题,需要了解数据类型的延迟。 在此示例中,已知道延迟为 2 分钟。
对于自己的数据,可以使用 Kusto ingestion_time()
函数了解延迟,并计算 TimeGenerated 与引入时间之间的差异。 有关详细信息,请参阅计算引入延迟。
确定延迟后,可以按如下方式解决问题:
增长回溯期。 基本直觉告诉你,增长回溯期将会有所帮助。 由于回溯期为 5 分钟,而延迟为 2 分钟,因此将回溯期设置为 7 分钟将有助于解决此问题。 例如,在规则设置中:
下图显示了回溯期现在包含丢失的事件的方式:
处理重复项。 只有增长回溯期才会造成重复,因为回溯期现在重叠了。 例如,另一个事件可能如下图所示:
由于在两个回溯期内都找到了事件 TimeGenerated 值,因此该事件会触发两个警报。 需要寻找一种方法来解决重复项。
将事件与特定的回溯期相关联。 在第一个示例中,你丢失了事件,因为计划查询运行时没有引入你的数据。 你扩展了回溯期以包含该事件,但这会导致重复。 必须将事件与扩展的时段相关联,以包含该事件。
为此,请设置
ingestion_time() > ago(5m)
,而不是设置原始规则look-back = 5m
。 此设置将事件与第一个回溯时段相关联。 例如:引入时间限制现在可将添加到回溯期的额外 2 分钟剪裁掉。 现在,对于第一个示例,第二次运行回溯期将可以捕获事件:
以下示例查询汇总了解决引入延迟问题的解决方案:
let ingestion_delay = 2min;
let rule_look_back = 5min;
CommonSecurityLog
| where TimeGenerated >= ago(ingestion_delay + rule_look_back)
| where ingestion_time() > ago(rule_look_back)
计算引入延迟
默认情况下,Microsoft Sentinel 计划警报规则配置为具有 5 分钟的回溯期。 但是,每个数据源都可能有其单独的引入延迟。 联接多种数据类型时,必须了解每种数据类型的不同延迟,才能正确地配置回溯期。
Microsoft Sentinel 中提供现成的工作区使用情况报表,其中包含一个仪表板,用于显示流入工作区的不同数据类型的延迟。
例如:
后续步骤
有关详细信息,请参阅: