Hantera inmatningsfördröjning i schemalagda analysregler

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 ställa in Körningsfråga var och Uppslagsdata från de sista fälten så att regeln körs var femte minut och söka efter data från de senaste fem minuterna:

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

Händelsen tas emot när den genereras och ingår i lookback-perioden .

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:

Händelsen genereras inom den första återställningsperioden, men matas inte in i Microsoft Sentinel-arbetsytan vid den första körningen. Nästa gång den schemalagda frågan körs matar den in händelsen, 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 en avisering.

Så här hanterar du fördröjning

Anteckning

Du kan antingen lösa problemet med hjälp av processen som beskrivs nedan eller implementera Microsoft Sentinels NRT-regler (near-real-time detection). Mer information finns i Identifiera hot snabbt med analysregler nära realtid (NRT) i Microsoft Sentinel.

För att lösa problemet behöver du veta 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 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 look-back-perioden. Grundläggande intuition säger att det hjälper att öka look-back-periodens storlek. Eftersom din återblicksperiod ä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 regelinställningarna kan du till exempel:

  

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

  

• 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 som i följande diagram:

  

  Eftersom händelsen TimeGenerated-värdet finns i båda look-back-perioderna utlöser händelsen 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 associerar händelsen med det första återblicksfönstret. Exempel:

  

  Begränsningen för inmatningstid trimmar nu de extra två minuterna som du lade till i look-back-perioden. Och i det första exemplet fångar den andra look-back-perioden nu 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)

Beräkna inmatningsfördröjning

Som standard är schemalagda aviseringsregler för Microsoft Sentinel 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 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.

Exempel:

Nästa steg

Mer information finns i:

• Skapa anpassade analysregler för att identifiera hot
• Anpassa aviseringsinformation i Azure Sentinel
• Hantera mallversioner för dina schemalagda analysregler i Azure Sentinel
• Använda arbetsboken för hälsoövervakning
• Inmatningstid för loggdata i Azure Monitor