Zpracování zpoždění příjmu dat v pravidlech plánované analýzy

Microsoft Sentinel sice dokáže ingestovat data z různých zdrojů, ale čas příjmu dat pro každý zdroj dat se může lišit za různých okolností.

Tento článek popisuje, jak může zpoždění příjmu dat ovlivnit plánovaná analytická pravidla a jak je opravit, abyste tyto mezery pokryli.

Proč je zpoždění významné

Můžete například napsat vlastní pravidlo detekce, nastavit dotaz Spustit každých a vyhledávací data z posledních polí, aby se pravidlo spustilo každých pět minut, a vyhledat data z těchto posledních pěti minut:

Vyhledávací data z posledního pole definují nastavení označované jako období zpětného vyhledávání . V ideálním případě tato detekce nezpožďuje žádné události, jak je znázorněno v následujícím diagramu:

Událost dorazí, jak se vygeneruje, a je součástí období zpětného vyhledávání .

Teď předpokládejme, že u zdroje dat dochází k nějaké prodlevě. V tomto příkladu řekněme, že událost byla ingestována dvě minuty po vygenerování. Zpoždění je dvě minuty:

Událost se vygeneruje během prvního období zpětného vyhledávání, ale neingestuje se v pracovním prostoru Služby Microsoft Sentinel při prvním spuštění. Při příštím spuštění naplánovaného dotazu ingestuje událost, ale časově vygenerovaný filtr událost odebere, protože k ní došlo před více než pěti minutami. V takovém případě pravidlo neaktivuje výstrahu.

Zpracování zpoždění

Pokud chcete tento problém vyřešit, musíte znát zpoždění datového typu. V tomto příkladu už víte, že zpoždění je dvě minuty.

U vlastních dat můžete pochopit zpoždění pomocí funkce Kusto ingestion_time() a vypočítat rozdíl mezi TimeGenerated a časem příjmu dat. Další informace najdete v tématu Výpočet zpoždění příjmu dat.

Po určení zpoždění můžete problém vyřešit následujícím způsobem:

• Zvyšte období zpětného vyhledávání. Základní intuitivně vám říká, že zvýšení velikosti období zpětného vyhledávání vám pomůže. Vzhledem k tomu, že období zpětného vyhledávání je pět minut a vaše zpoždění je dvě minuty, nastavení období zpětného vyhledávání na sedm minut pomůže tento problém vyřešit. Například v nastavení pravidla:

  

  Následující diagram znázorňuje, jak období sady look-pack teď obsahuje zmeškanou událost:

  

• Zpracování duplicit Duplikaci může vytvořit pouze zvětšení období zpětného vyhledávání, protože okna zpětného vyhledávání se teď překrývají. Například jiná událost může vypadat, jak je znázorněno v následujícím diagramu:

  

  Vzhledem k tomu, že hodnota TimeGenerated události se nachází v obou obdobích zpětného vyhledávání, událost aktivuje dvě výstrahy. Potřebujete najít způsob, jak duplikaci vyřešit.

• Přidružte událost ke konkrétnímu období zpětného vyhledávání. V prvním příkladu jste zmeškali události, protože data nebyla ingestována při spuštění naplánovaného dotazu. Vyhledávání jste rozšířili tak, aby zahrnovala událost, ale způsobila to duplikaci. Událost musíte přidružit k oknem, které jste rozšířili, aby ji obsahovalo.

  Udělejte to nastavením ingestion_time() > ago(5m)místo původního pravidla look-back = 5m. Toto nastavení přidruží událost k prvnímu vyhledávacímu okně. Příklad:

  

  Omezení doby příjmu dat teď oříznou další dvě minuty, které jste přidali do období zpětného vyhledávání. V prvním příkladu teď druhé období zpětného běhu zachycuje událost:

  

Následující ukázkový dotaz shrnuje řešení problémů se zpožděním příjmu dat:

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)

Výpočet zpoždění příjmu dat

Ve výchozím nastavení jsou naplánovaná pravidla upozornění služby Microsoft Sentinel nakonfigurovaná tak, aby měla 5minutové období zpětného vyhledávání. Každý zdroj dat ale může mít vlastní, individuální zpoždění příjmu dat. Při připojování více datových typů musíte porozumět různým zpožděním jednotlivých datových typů, aby bylo možné správně nakonfigurovat období zpětného vyhledávání.

Sestava využití pracovního prostoru, která je k dispozici v microsoft Sentinelu, obsahuje řídicí panel, který zobrazuje latenci a zpoždění různých datových typů, které do vašeho pracovního prostoru proudí.

Příklad:

Další kroky

Další informace naleznete v tématu:

• Vytváření vlastních analytických pravidel pro detekci hrozeb
• Přizpůsobení podrobností upozornění ve službě Azure Sentinel
• Správa verzí šablon pro plánovaná analytická pravidla ve službě Azure Sentinel
• Použití sešitu monitorování stavu
• Protokolování času pro příjem dat ve službě Azure Monitor