处理计划分析规则中的数据引入延迟

虽然 Microsoft Sentinel 可以从各种源引入数据，但每个数据源的引入时间在不同情况下可能有所不同。

本文介绍了引入延迟可能会如何影响计划分析规则，以及如何修复这些规则以弥补这些缺陷。

为什么延迟非常重要

例如，你可以编写自定义检测规则，将 Run query every 和 Lookup data from the last 字段设置为使该规则每五分钟运行一次，并查找过去五分钟内的数据：

查找过去字段定义了称为回溯期的设置。 理想情况下，如果没有延迟，此检测不会遗漏任何事件，如下图所示：

事件在生成时即到达，并包含在 lookback 时间段内。

现在，假定数据源有一些延迟。 在此示例中，假设事件在生成 2 分钟后被引入 。 延迟为 2 分钟：

该事件是在第一个回溯时间范围内生成的，但在首次运行时不会被引入到 Microsoft Sentinel 工作区中。 下次运行计划查询时，会引入该事件，但生成时间筛选器会删除该事件，因为其生成时间已超过 5 分钟。 在这种情况下，规则不会触发警报。

如何处理延迟

使用以下方法将计划分析规则中的数据引入延迟考虑在内。

若要解决此问题，需要了解数据类型的延迟。 在此示例中，已知道延迟为 2 分钟。

对于你自己的数据，可以使用 Kusto ingestion_time() 函数来了解延迟情况，并通过计算 TimeGenerated 与数据引入时间之间的差值来进行分析。 有关详细信息，请参阅计算引入延迟。

确定延迟后，可以按如下方式解决问题：

• 延长回溯期。 凭基本直觉也能判断，增大回溯期长度会有所帮助。 由于回溯期为 5 分钟，而延迟为 2 分钟，因此将回溯期设置为 7 分钟将有助于解决此问题。 例如，在规则设置中：

  

  下图展示了回溯期现在如何包含遗漏的事件：

  

• 处理重复项。 只有增加回溯周期才会导致重复，因为这些回溯窗口现在会相互重叠。 例如，另一个事件可能如下图所示：

  

  由于在两个回溯周期内都找到了事件的 TimeGenerated 值，因此该事件会触发两个警报。 你需要想办法解决重复问题。

• 将事件与特定的回溯期相关联。 在第一个示例中，你漏掉了一些事件，因为计划的查询运行时，你的数据尚未被摄取。 你扩展了回溯期以包含该事件，但这会导致重复。 必须将该事件关联到你为容纳它而扩展的窗口。

  为此，请设置 ingestion_time() > ago(5m)，而不是设置原始规则 look-back = 5m。 此设置将事件关联到第一个回溯窗口。 例如：

  

  数据引入时间限制现在会裁掉你在回溯时间范围中添加的额外两分钟。 对于第一个示例，第二次运行的回溯期现在可以捕获该事件：

  

以下示例查询汇总了解决引入延迟问题的解决方案：

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)

有关上述示例中使用的以下项的详细信息，请参阅 Kusto 文档：

• let 语句
• where 运算符
• ago（） 函数

计算摄取延迟

默认情况下，Microsoft Sentinel 计划警报规则配置为具有 5 分钟的回溯期。 但是，每个数据源都可能有其单独的引入延迟。 联接多种数据类型时，必须了解每种数据类型的不同延迟，才能正确地配置回溯期。

Microsoft Sentinel 开箱即用提供的 工作区使用情况报告 包含一个仪表板，用于显示流入你的工作区的不同数据类型的延迟和滞后情况。

例如：

后续步骤

有关详细信息，请参见:

• 创建自定义分析规则以检测威胁
• 在 Azure Sentinel 中自定义警报详细信息
• 在 Azure Sentinel 中管理计划分析规则的模板版本
• 使用“健康监视”工作簿
• Azure Monitor 中的日志数据引入时间