分享方式：

處理排程分析規則中的擷取延遲

  • 文章

雖然 Microsoft Sentinel 可以從各種來源擷取資料，但每個資料來源的擷取時間可能會不同。

本文說明擷取延遲可能會對排程分析規則造成什麼影響，以及如何修正這些規則以彌補這些差距。

為什麼延遲很重要

舉例來說，您可以撰寫自訂偵測規則，設定 [執行間隔時間] 和 [查閱過去時間內的資料] 欄位，讓規則每隔五分鐘執行一次、查閱過去五分鐘的資料：

顯示 [分析規則精靈 - 建立新規則] 視窗的螢幕擷取畫面。

[查閱過去時間內的資料] 欄位會定義稱為「回溯」期間的設定。 在沒有發生延遲的理想情況下，此偵測不會遺漏任何事件，如下圖所示：

顯示五分鐘回溯時段的圖表。

事件會在產生時送達，並包含在「回溯」期間內。

現在，假設您的資料來源出現一些延遲。 在此範例中，假設事件在「產生」後「擷取」了兩分鐘。 延遲時間為兩分鐘：

顯示有兩分鐘延遲之五分鐘回溯時段的圖表。

事件會在第一次執行期間產生，但不會在第一次執行時擷取至 Microsoft Sentinel 工作區中。 下次執行排程查詢時，它會擷取該事件，但產生時間篩選條件會移除這個事件，因為發生時間已超過五分鐘前。 在此情況下，規則不會引發警示。

如何處理延遲

注意

您可以使用下面所述的流程解決問題，或實作 Microsoft Sentinel 的近乎即時偵測 (NRT) 規則。 如需詳細資訊，請參閱使用 Microsoft Sentinel 中的近即時 (NRT) 分析規則來快速偵測威脅。

若要解決此問題，您需知道資料類型的延遲時間。 在此範例中，您已經知道延遲時間是兩分鐘。

針對您自己的資料，您可以使用 Kusto ingestion_time() 函式了解延遲時間，並計算 TimeGenerated 與擷取時間之間的差異。 如需詳細資訊，請參閱計算擷取延遲。

判斷出延遲時間後，可以依照下列方式解決問題：

  • 延長回溯期間。 基本直覺告訴您，延長回溯期間會有所幫助。 因為您的回溯期間是五分鐘，而您的延遲時間是兩分鐘，所以將回溯期間設定為七分鐘有助於解決此問題。 例如，在規則設定中：

    顯示將回溯時段設為七分鐘的螢幕擷取畫面。

    下圖顯示回溯期間現在包含遺漏事件的方式：

    顯示有兩分鐘延遲之七分鐘回溯時段的圖表。

  • 處理重複項目。 只有延長回溯期間才可能建立重複項目，因為回溯時段現在會重疊。 例如，不同的事件看起來可能如下圖所示：

    顯示重疊回溯時段如何產生重複項目的圖表。

    由於事件 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)

計算擷取延遲

根據預設，Microsoft Sentinel 排程警示規則會設定為具有 5 分鐘的回溯期間。 不過，每個資料來源可能都有各自的擷取延遲。 聯結多個資料類型時，您必須知道每個資料類型的不同延遲時間，才能正確設定回溯期間。

Microsoft Sentinel 提供現成的工作區使用量報告，包含儀表板，可顯示流入工作區中不同資料類型的延遲時間。

例如：

工作區使用量報告以表格顯示端對端延遲的螢幕擷取畫面

下一步

如需詳細資訊，請參閱