Dela via

Hantera inmatningsfördröjning i schemalagda analysregler

  • Artikel

Microsoft Sentinel kan mata in data från olika källor, men inmatningstiden för varje datakälla kan variera under olika omständigheter.

Den här artikeln beskriver hur inmatningsfördröjning kan påverka dina schemalagda analysregler och hur du kan åtgärda dem för att täcka dessa luckor.

Varför fördröjningen är betydande

Du kan till exempel skriva en anpassad identifieringsregel och ange körningsfrågan var och en av uppslagsdata från de sista fälten så att regeln körs var femte minut och leta upp data från de senaste fem minuterna:

Skärmbild som visar guiden Analysregel – Skapa nytt regelfönster.

Uppslagsdata från det sista fältet definierar en inställning som kallas en återblicksperiod . Helst, när det inte finns någon fördröjning, missar den här identifieringen inga händelser, som visas i följande diagram:

Diagram som visar ett fem minuter långt tillbakablicksfönster.

Händelsen tas emot när den genereras och ingår i återställningsperioden .

Anta nu att det finns en viss fördröjning för datakällan. I det här exemplet ska vi säga att händelsen matades in två minuter efter att den genererades. Fördröjningen är två minuter:

Diagram som visar fem minuters tillbakablick av fönster med en fördröjning på två minuter.

Händelsen genereras inom den första återställningsperioden, men matas inte in på din Microsoft Sentinel-arbetsyta vid den första körningen. Nästa gång den schemalagda frågan körs matas händelsen in, men det tidsgenererade filtret tar bort händelsen eftersom den inträffade för mer än fem minuter sedan. I det här fallet utlöser regeln inte någon avisering.

Hantera fördröjning

Kommentar

Du kan antingen lösa problemet med hjälp av den process som beskrivs nedan eller implementera Microsoft Sentinels regler för nästan realtidsidentifiering (NRT). Mer information finns i Identifiera hot snabbt med nrt-analysregler (near-real-time) i Microsoft Sentinel.

För att lösa problemet måste du känna till fördröjningen för din datatyp. I det här exemplet vet du redan att fördröjningen är två minuter.

För dina egna data kan du förstå fördröjning med funktionen Kusto ingestion_time() och beräkna skillnaden mellan TimeGenerated och inmatningstiden. Mer information finns i Beräkna inmatningsfördröjning.

När du har fastställt fördröjningen kan du åtgärda problemet på följande sätt:

  • Öka tillbakablicksperioden. Grundläggande intuition säger att öka look-back-periodens storlek kommer att hjälpa. Eftersom look-back-perioden är fem minuter och fördröjningen är två minuter hjälper det att lösa problemet genom att ställa in återställningsperioden på sju minuter. I dina regelinställningar kan du till exempel:

    Skärmbild som visar inställningen för tillbakablicksfönstret till sju minuter.

    Följande diagram visar hur look-pack-perioden nu innehåller den missade händelsen:

    Diagram som visar sju minuters tillbakablick av fönster med en fördröjning på två minuter.

  • Hantera duplicering. Om du bara ökar look-back-perioden kan du skapa duplicering eftersom tillbakablicksfönstren nu överlappar varandra. En annan händelse kan till exempel se ut som i följande diagram:

    Diagram som visar hur överlappande tillbakablicksfönster skapar duplicering.

    Eftersom händelsen TimeGenerated-värdet finns i båda återblicksperioderna utlöses två aviseringar. Du måste hitta ett sätt att lösa dupliceringen.

  • Associera händelsen med en specifik återblicksperiod. I det första exemplet missade du händelser eftersom dina data inte matades in när den schemalagda frågan kördes. Du utökade tillbakablicken så att den inkluderade händelsen, men detta orsakade duplicering. Du måste associera händelsen med det fönster som du har utökat för att innehålla den.

    Gör detta genom att ange ingestion_time() > ago(5m)i stället för den ursprungliga regeln look-back = 5m. Den här inställningen kopplar händelsen till det första tillbakablicksfönstret. Till exempel:

    Diagram som visar hur du ställer in begränsningen ago undviker duplicering.

    Tidsbegränsningen för inmatning trimmar nu de extra två minuter som du har lagt till i look-back-perioden. Och för det första exemplet fångar den andra look-back-perioden nu händelsen:

    Diagram som visar hur inställningen av begränsningen sedan fångar upp händelsen.

Följande exempelfråga sammanfattar lösningen för att lösa problem med inmatningsfördröjning:

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)

Mer information om följande objekt som används i föregående exempel finns i Kusto-dokumentationen:

Beräkna inmatningsfördröjning

Som standard är schemalagda aviseringsregler i Microsoft Sentinel konfigurerade att ha en 5-minuters återställningsperiod. Varje datakälla kan dock ha sin egen, individuella inmatningsfördröjning. När du ansluter flera datatyper måste du förstå de olika fördröjningarna för varje datatyp för att kunna konfigurera återställningsperioden korrekt.

Användningsrapporten för arbetsytan, som tillhandahålls i Microsoft Sentinel, innehåller en instrumentpanel som visar svarstider och fördröjningar för de olika datatyper som flödar till din arbetsyta.

Till exempel:

Skärmbild av användningsrapporten för arbetsytan som visar svarstid från slutpunkt till slutpunkt efter tabell

Nästa steg

Mer information finns i: