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

  • Článek

I když služba Microsoft Sentinel může ingestovat data z různých zdrojů, doba příjmu dat pro každý zdroj dat se může za různých okolností lišit.

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

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

Můžete například napsat vlastní pravidlo detekce, které nastaví data Spustit dotaz vždy a Vyhledávací data z posledních polí tak, aby se pravidlo spouštěla každých pět minut a vyhledal data z těchto posledních pěti minut:

Snímek obrazovky s Průvodcem analytickým pravidlem – okno Vytvořit nové pravidlo

Vyhledávací data z posledního pole definují nastavení označované jako období zpětného pohledu. V ideálním případě, když nedojde ke zpoždění, při této detekci nedojde k žádné události, jak je znázorněno na následujícím diagramu:

Diagram znázorňující pětiminutové okno zpětného pohledu

Událost přijde při vygenerování a je zahrnuta do období zpětného vyhledávání .

Teď předpokládejme, že u zdroje dat došlo k určitému zpoždění. V tomto příkladu řekněme, že událost byla ingestována dvě minuty po vygenerování. Zpoždění je dvě minuty:

Diagram znázorňující pětiminutová okna zpětného pohledu se zpožděním dvou minut

Událost se vygeneruje během prvního období zpětného ohlédnutí, ale není ingestována 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 tomto případě pravidlo neaktivuje výstrahu.

Jak zpracovat zpoždění

Poznámka

Problém můžete buď vyřešit pomocí níže popsaného procesu, nebo implementovat pravidla detekce téměř v reálném čase (NRT) služby Microsoft Sentinel. Další informace najdete v tématu Rychlá detekce hrozeb pomocí analytických pravidel téměř v reálném čase (NRT) ve službě Microsoft Sentinel.

Pokud chcete tento problém vyřešit, potřebujete 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 zjištění zpoždění můžete problém vyřešit následujícím způsobem:

  • Prodlužte období zpětného ohlédnuti. Základní intuice vám řekne, že vám pomůže zvýšit velikost zpětného ohlédnuti. Vzhledem k tomu, že vaše období zpětného vyhledávání je pět minut a zpoždění je dvě minuty, pomůže vám s vyřešením tohoto problému nastavení doby zpětného vyhledávání na sedm minut. Například v nastavení pravidla:

    Snímek obrazovky znázorňující nastavení okna zpětného pohledu na sedm minut

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

    Diagram znázorňující sedmiminutová okna se zpožděním dvou minut

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

    Diagram znázorňující, jak překrývající se okna zpětného pohledu vytvářejí duplikaci

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

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

    Uděláte to tak, že místo původního pravidla look-back = 5mnastavíte ingestion_time() > ago(5m). Toto nastavení přidruží událost k prvnímu oknu zpětného pohledu. Příklad:

    Diagram znázorňující, jak nastavení omezení předcházet duplicitám

    Omezení doby příjmu dat teď oříznou další dvě minuty, které jste přidali do období zpětného pohledu. A v prvním příkladu teď období zpětného pohledu druhého spuštění zaznamenává událost:

    Diagram znázorňující, jak nastavení omezení před rokem zachytí 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 pravidla naplánovaných upozornění služby Microsoft Sentinel nakonfigurovaná tak, aby měla 5minutové období zpětného pohledu. Každý zdroj dat však může mít své vlastní individuální zpoždění příjmu dat. Při spojování více datových typů musíte rozumět různým zpožděním pro každý datový typ, aby bylo možné správně nakonfigurovat období zpětného vyhledávání.

Sestava využití pracovního prostoru, která je součástí služby Microsoft Sentinel, obsahuje řídicí panel, který zobrazuje latenci a zpoždění různých datových typů toků do vašeho pracovního prostoru.

Příklad:

Snímek obrazovky sestavy využití pracovního prostoru zobrazující latenci mezi koncovými body podle tabulky

Další kroky

Další informace naleznete v tématu: