Hantera inmatningsfördröjning i schemalagda analysregler

Viktigt

Anpassade identifieringar är nu det bästa sättet att skapa nya regler i Microsoft Sentinel SIEM-Microsoft Defender XDR. Med anpassade identifieringar kan du minska kostnaderna för inmatning, få obegränsade identifieringar i realtid och dra nytta av sömlös integrering med Defender XDR data, funktioner och reparationsåtgärder med automatisk entitetsmappning. Mer information finns i den här bloggen.

Även om Microsoft Sentinel kan mata in data från olika källor kan inmatningstiden för varje datakälla 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 som anger körfrågan var och uppslagsdata från de sista fälten så att regeln körs var femte minut och söker efter data från de senaste fem minuterna:

Skärmbild som visar guiden Analysregel – Fönstret Skapa ny regel.

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 uppslagsfönster.

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

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

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

Händelsen genereras inom den första återblicksperioden, men matas inte in i 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

Obs!

Du kan antingen lösa problemet med hjälp av den process som beskrivs nedan eller implementera Microsoft Sentinel nästan realtidsidentifieringsregler (NRT). Mer information finns i Identifiera hot snabbt med analysregler nära realtid (NRT) 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öjningen med hjälp av Kusto-funktionen 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 återblicksperioden. Grundläggande intuition säger dig att öka look-back-periodens storlek kommer att hjälpa. Eftersom look back-perioden är fem minuter och fördröjningen är två minuter kan du 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 hur du ställer in look-back-fönstret på sju minuter.

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

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

  • Hantera duplicering. Att bara öka look-back-perioden kan skapa duplicering, eftersom tillbakablicksfönstren nu överlappar varandra. En annan händelse kan till exempel se ut så som visas i följande diagram:

    Diagram som visar hur överlappande återblicksfö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 till fönstret 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 associerar händelsen till det första återblicksfönstret. Till exempel:

    Diagram som visar hur du undviker duplicering genom att ange begränsningen ago.

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

    Diagram som visar hur inställningen av begränsningen ago 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 Microsoft Sentinel schemalagda aviseringsregler konfigurerade att ha en 5-minuters återblicksperiod. Varje datakälla kan dock ha en egen, individuell inmatningsfördröjning. När du ansluter till 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 finns i Microsoft Sentinel out-of-the-box, 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:

  • Last updated on