Kommentar
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
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 Anpassade identifieringar är nu det enhetliga sättet att skapa identifieringar i Microsoft Defender XDR.
Även om Microsoft Sentinel kan ta in data från anslutna datakällor, kan insamlingstiden för varje datakälla skilja sig åt i olika situationer.
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 detekteringsregel och ange fälten Kör fråga varje och Sök data från de senaste så att regeln körs var femte minut och hämtar data från de senaste fem minuterna:
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:
Händelsen kommer in när den genereras och ingår i tillbakablicksperioden.
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 tillbakablicksperioden, men intas inte 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
Använd följande metod för att ta hänsyn till inmatningsfördröjning i schemalagda analysregler.
Obs!
Du kan antingen lösa problemet med hjälp av processen som beskrivs nedan, eller införa Microsoft Sentinels regler för detektering i nära realtid (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 tillbakablicksperioden: Grundläggande intuition säger att en ökning av tillbakablicksperioden 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:
Följande diagram visar hur look pack-perioden nu innehåller den missade händelsen:
* Hantera duplicering: Att bara öka den retrospektiva perioden kan skapa dubbleringar, eftersom de retrospektiva tidsfönstren nu överlappar varandra. En annan händelse kan till exempel se ut så som visas i följande diagram:
Eftersom händelsevärdet TimeGenerated hittas i båda tillbakablicksperioderna, utlöser händelsen två varningar. Du måste hitta ett sätt att lösa dupliceringen.
Koppla händelsen till en specifik återblicksperiod: I det första exemplet missade du händelser eftersom din data inte togs 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 regelnlook-back = 5m. Den här inställningen associerar händelsen till det första återblicksfönstret. Till exempel:
Begränsningen för inläsningstid tar nu bort de extra två minuter som du lade till i återblicksperioden. Och i det första exemplet fångar den andra körningens tillbakablicksperiod 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)
Se mer information om följande objekt som användes i föregående exempel i Kusto-dokumentationen:
Beräkna inmatningsfördröjning
Som standard är Microsoft Sentinel schemalagda varningsregler konfigurerade med en fem minuters återblicksperiod. Dock kan varje datakälla ha sin egen individuella fördröjning för intagning. 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:
