Zpracování zpoždění příjmu dat v plánovaných analytických pravidlech

Microsoft Sentinel sice dokáže ingestovat data z různých zdrojů, ale doba 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 můžete opravit, abyste tyto mezery vyřešili.

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:

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

Data vyhledávání 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:

Diagram znázorňující pětiminutové okno pro návrat

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

Teď předpokládejme, že váš zdroj dat má nějaké zpoždění. V tomto příkladu řekněme, že událost byla ingestována dvě minuty po jeho vygenerování. Zpoždění je dvě minuty:

Diagram znázorňující 5minutové ohlédnutové okna se zpožděním dvou minut

Událost se vygeneruje během prvního období zpětného vyhledávání, 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 událost ingestuje, 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.

Zpracování zpoždění

Poznámka

Problém můžete vyřešit pomocí následujícího postupu nebo implementovat pravidla detekce téměř v reálném čase (NRT) služby Microsoft Sentinel. Další informace najdete v tématu Rychlé zjišťování hrozeb pomocí analytických pravidel téměř v reálném čase (NRT) v Microsoft Sentinelu.

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 dobu zpětného vyhledávání. Základní intuitivní instrukce vám říká, že zvýšení velikosti období zpětného vyhledávání vám pomůže. Vzhledem k tomu, že doba zpětného vyhledávání je pět minut a vaše zpoždění je dvě minuty, nastavení doby zpětného vyhledávání na sedm minut vám pomůže tento problém vyřešit. Například v nastavení pravidla:

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

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

    Diagram znázorňující sedmminutové pohledy zpět o okna se zpožděním dvou minut

  • Zpracování duplicit Duplikaci může vytvořit pouze zvýšení období zpětného vyhledávání, protože se teď překrývají okna zpětného vyhledávání. Například jiná událost může vypadat, 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 vyhledávání vytvářejí duplikaci

    Vzhledem k tomu, že se hodnota TimeGenerated události 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 při spuštění naplánovaného dotazu se vaše data neingestovala. Rozšířili jste vyhledávání 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 okně zpětného vyhledávání. Příklad:

    Diagram znázorňující, jak se nastavení omezení předejde duplikaci

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

    Diagram znázorňující, jak nastavení omezení před 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 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ů, abyste mohli správně nakonfigurovat období zpětného vyhledávání.

Sestava využití pracovního prostoru, která je k dispozici od microsoft sentinelu, obsahuje řídicí panel, který zobrazuje latenci a zpoždění různých datových typů, které do pracovního prostoru přetékají.

Příklad:

Snímek obrazovky se sestavou využití pracovního prostoru zobrazující latenci end-to-end podle tabulky

Další kroky

Další informace naleznete v tématu: