Sdílet prostřednictvím


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:

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 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 zpětného vyhledávání

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:

Diagram znázorňující pětminutový pohled zpět okna se zpožděním dvou minut

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í

Poznámka:

Problém můžete 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é 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 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:

    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 období sady look-pack teď obsahuje zmeškanou událost:

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

  • 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:

    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 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:

    Diagram znázorňující, jak se 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í. V prvním příkladu teď druhé období zpětného běhu zachycuje událost:

    Diagram znázorňující, jak nastavení omezení před zaznamenává 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:

Snímek obrazovky se sestavou využití pracovního prostoru zobrazující koncové latence podle tabulky

Další kroky

Další informace naleznete v tématu: