Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
Belangrijk
Aangepaste detecties is nu dé beste manier om nieuwe regels te maken in Microsoft Sentinel SIEM en Microsoft Defender XDR. Met aangepaste detecties kunt u de opnamekosten verlagen, onbeperkte realtime detecties krijgen en profiteren van naadloze integratie met Defender XDR gegevens, functies en herstelacties met automatische entiteitstoewijzing. Lees voor meer informatie Aangepaste detecties zijn nu de uniforme omgeving voor het maken van detecties in Microsoft Defender XDR.
Hoewel Microsoft Sentinel data kan importeren uit verbonden databronnen, kan de opnametijd voor elke databron verschillen in verschillende omstandigheden.
In dit artikel wordt beschreven hoe opnamevertraging van invloed kan zijn op uw geplande analyseregels en hoe u deze kunt oplossen om deze hiaten te dichten.
Waarom vertraging aanzienlijk is
U zou bijvoorbeeld een aangepaste detectieregel kunnen schrijven, waarbij u de velden Query elke keer uitvoeren en Gegevens van de laatste ... opzoeken instelt zodat de regel elke vijf minuten wordt uitgevoerd en gegevens van de afgelopen vijf minuten worden opgezocht:
Met de opzoekgegevens uit het laatste veld wordt een instelling gedefinieerd die een terugkijkperiode wordt genoemd. Als er geen vertraging is, mist deze detectie in het ideale gevallen geen gebeurtenissen, zoals wordt weergegeven in het volgende diagram:
De gebeurtenis komt aan wanneer deze wordt gegenereerd en valt binnen de lookback periode.
Stel nu dat er enige vertraging is voor uw gegevensbron. In dit voorbeeld is de gebeurtenis twee minuten nadat deze is gegenereerdopgenomen. De vertraging is twee minuten:
De gebeurtenis wordt gegenereerd binnen de eerste terugkijkperiode, maar wordt tijdens de eerste uitvoering niet opgenomen in uw Microsoft Sentinel-werkruimte. De volgende keer dat de geplande query wordt uitgevoerd, wordt de gebeurtenis opgenomen, maar het tijdgegenereerde filter verwijdert de gebeurtenis omdat deze meer dan vijf minuten geleden heeft plaatsgevonden. In dit geval wordt met de regel geen waarschuwing geactiveerd.
Omgaan met vertraging
Gebruik de volgende methode om rekening te houden met opnamevertraging in geplande analyseregels.
Opmerking
U kunt het probleem oplossen met behulp van het proces dat hieronder wordt beschreven of de nrt-regels (near-real-time detection) van Microsoft Sentinel implementeren. Zie Bedreigingen snel detecteren met nrt-analyseregels (near-real-time) in Microsoft Sentinel voor meer informatie.
Om het probleem op te lossen, moet u weten wat de vertraging is voor uw gegevenstype. In dit voorbeeld weet u al dat de vertraging twee minuten is.
Voor uw eigen gegevens kunt u vertraging begrijpen met behulp van de functie Kusto ingestion_time() en het verschil berekenen tussen TimeGenerated en de opnametijd. Zie Opnamevertraging berekenen voor meer informatie.
Nadat u de vertraging hebt vastgesteld, kunt u het probleem als volgt oplossen:
Verhoog de terugkijkperiode: Basisintuïtie zegt dat het vergroten van de grootte van de terugkijkperiode zal helpen. Aangezien uw terugblikperiode vijf minuten is en uw vertraging twee minuten is, kunt u dit probleem oplossen door de terugblikperiode in te stellen op zeven minuten. Bijvoorbeeld in uw regelinstellingen:
In het volgende diagram wordt getoond hoe de look-pack-periode nu de gemiste gebeurtenis omvat:
* Handel met duplicatie: Alleen het verhogen van de terugkijkperiode kan duplicatie creëren, omdat de terugkijkvensters elkaar nu overlappen. Een andere gebeurtenis kan er bijvoorbeeld uitzien zoals wordt weergegeven in het volgende diagram:
Omdat de gebeurtenis TimeGenered-waarde in beide terugkijkperiodes wordt gevonden, geeft het evenement twee waarschuwingen. U moet een manier vinden om de duplicatie op te lossen.
Koppel het event aan een specifieke lookback-periode: In het eerste voorbeeld miste je events omdat je data niet werd ingevoerd toen de geplande query werd uitgevoerd. U hebt de terugblik uitgebreid met de gebeurtenis, maar dit heeft duplicatie veroorzaakt. U moet de gebeurtenis koppelen aan het venster dat u hebt uitgebreid om deze te bevatten.
Doe dit door in te stellen
ingestion_time() > ago(5m)in plaats van de oorspronkelijke regellook-back = 5m. Met deze instelling wordt de gebeurtenis gekoppeld aan het eerste terugblikvenster. Bijvoorbeeld:
De beperking voor opnametijd beperkt nu de extra twee minuten die u aan de terugblikperiode hebt toegevoegd. En voor het eerste voorbeeld registreert de terugkijkperiode van de tweede uitvoering nu de gebeurtenis:
De volgende voorbeeldquery geeft een overzicht van de oplossing voor het oplossen van problemen met vertraging bij opname:
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)
Zie meer informatie over de volgende items die in het voorgaande voorbeeld worden gebruikt in de Kusto-documentatie:
Innamevertraging berekenen
Standaard zijn de geplande waarschuwingsregels van Microsoft Sentinel ingesteld met een terugblikperiode van vijf minuten. Elke databron kan echter zijn eigen, individuele opnamevertraging hebben. Wanneer u meerdere gegevenstypen wilt samenvoegen, moet u de verschillende vertragingen voor elk gegevenstype begrijpen om de terugkijkperiode correct te configureren.
Het werkruimtegebruiksrapport, dat wordt geleverd in Microsoft Sentinel out-of-the-box, bevat een dashboard met latentie en vertragingen voor de verschillende gegevenstypen die uw werkruimte binnenkomen.
Bijvoorbeeld:
