Normalisatie van opnametijd

  • Artikel

Parseren van querytijd

Zoals besproken in het ASIM-overzicht, maakt Microsoft Sentinel gebruik van normalisatie van zowel querytijd als opnametijd om te profiteren van de voordelen van beide.

Als u normalisatie van querytijd wilt gebruiken, gebruikt u de parsers voor het samenvoegen van querytijd, zoals _Im_Dns in uw query's. Het normaliseren van het parseren van querytijd heeft verschillende voordelen:

  • Behoud van de oorspronkelijke indeling: voor normalisatie van querytijd hoeven de gegevens niet te worden gewijzigd, waardoor de oorspronkelijke gegevensindeling die door de bron is verzonden, behouden blijft.
  • Mogelijke dubbele opslag vermijden: omdat de genormaliseerde gegevens alleen een weergave van de oorspronkelijke gegevens zijn, is het niet nodig om zowel de oorspronkelijke als de genormaliseerde gegevens op te slaan.
  • Eenvoudiger ontwikkelen: Omdat querytijdparseers een weergave van de gegevens bieden en de gegevens niet wijzigen, zijn ze eenvoudig te ontwikkelen. Het ontwikkelen, testen en herstellen van een parser kan allemaal worden uitgevoerd op bestaande gegevens. Bovendien kunnen parsers worden opgelost wanneer een probleem wordt gedetecteerd en de oplossing van toepassing is op bestaande gegevens.

Opnametijd parseren

Hoewel ASIM-querytijdparser is geoptimaliseerd, kan het parseren van query's query's vertragen, met name voor grote gegevenssets.

Met het parseren van opnametijd kunnen gebeurtenissen worden getransformeerd naar een genormaliseerd schema wanneer ze worden opgenomen in Microsoft Sentinel en in een genormaliseerde indeling worden opgeslagen. Het parseren van opnametijd is minder flexibel en parsers zijn moeilijker te ontwikkelen, maar omdat de gegevens worden opgeslagen in een genormaliseerde indeling, bieden betere prestaties.

Genormaliseerde gegevens kunnen worden opgeslagen in de systeemeigen genormaliseerde tabellen van Microsoft Sentinel of in een aangepaste tabel die gebruikmaakt van een ASIM-schema. Een aangepaste tabel met een schema dat dicht bij een ASIM-schema ligt, maar niet identiek is, biedt ook de prestatievoordelen van normalisatie van de opnametijd.

Momenteel ondersteunt ASIM de volgende systeemeigen genormaliseerde tabellen als bestemming voor normalisatie van opnametijd:

Het voordeel van systeemeigen genormaliseerde tabellen is dat ze standaard worden opgenomen in de ASIM unifying parsers. Aangepaste genormaliseerde tabellen kunnen worden opgenomen in de samenvoegende parsers, zoals besproken in Parsers beheren.

Normalisatie van opnametijd en querytijd combineren

Query's moeten altijd gebruikmaken van de parseringsfuncties voor querytijd, bijvoorbeeld _Im_Dns om te profiteren van normalisatie van zowel querytijd als opnametijd. Systeemeigen genormaliseerde tabellen worden opgenomen in de opgevraagde gegevens met behulp van een stub-parser.

De stub-parser is een querytijdparser die als invoer de genormaliseerde tabel gebruikt. Omdat de genormaliseerde tabel niet hoeft te worden geparseerd, is de stub-parser efficiënt.

De stub-parser biedt een weergave voor de aanroepende query die wordt toegevoegd aan de systeemeigen ASIM-tabel:

  • Aliassen : om opslag niet te verspillen aan herhalende waarden, worden aliassen niet opgeslagen in systeemeigen ASIM-tabellen en worden ze tijdens de query toegevoegd door de stub-parsers.
  • Constante waarden : net als aliassen en om dezelfde reden slaan genormaliseerde ASIM-tabellen ook geen constante waarden op, zoals EventSchema. Met de stub-parser worden deze velden toegevoegd. Genormaliseerde ASIM-tabel wordt gedeeld door veel bronnen en opnametijdparser kan hun uitvoerversie wijzigen. Daarom zijn velden zoals EventProduct, EventVendor en EventSchemaVersion niet constant en worden ze niet toegevoegd door de stub-parser.
  • Filteren : de stub-parser implementeert ook filteren. Hoewel systeemeigen ASIM-tabellen geen filterparsers nodig hebben om betere prestaties te bereiken, is filteren nodig om opname in de unifying parser te ondersteunen.
  • Updates en oplossingen: met behulp van een stub-parser kunt u problemen sneller oplossen. Als gegevens bijvoorbeeld onjuist zijn opgenomen, is er tijdens de opname mogelijk geen IP-adres uit het berichtveld geëxtraheerd. Het IP-adres kan tijdens de query worden geëxtraheerd door de stub-parser.

Wanneer u aangepaste genormaliseerde tabellen gebruikt, maakt u uw eigen stub-parser om deze functionaliteit te implementeren en voegt u deze toe aan de samenvoegende parsers, zoals besproken in Parsers beheren. Gebruik de stub-parser voor de systeemeigen tabel, zoals de systeemeigen dns-tabel-stub-parser en de bijbehorende filterte tegenhanger, als uitgangspunt. Als uw tabel semi-genormaliseerd is, gebruikt u de stub-parser om de benodigde extra parsering en normalisatie uit te voeren.

Meer informatie over het schrijven van parsers in ASIM-parsers ontwikkelen.

Normalisatie van opnametijd implementeren

Als u gegevens bij opname wilt normaliseren, moet u een regel voor gegevensverzameling (DCR) gebruiken. De procedure voor het implementeren van de DCR is afhankelijk van de methode die wordt gebruikt om de gegevens op te nemen. Raadpleeg het artikel Gegevens transformeren of aanpassen tijdens opnametijd in Microsoft Sentinel voor meer informatie.

Een KQL-transformatiequery is de kern van een DCR. De KQL-versie die wordt gebruikt in DCR's is iets anders dan de versie die elders in Microsoft Sentinel wordt gebruikt om te voldoen aan vereisten voor de verwerking van pijplijngebeurtenissen. Daarom moet u een querytijdparser wijzigen om deze te gebruiken in een DCR. Lees meer over de KQL-beperkingen van DCR voor meer informatie over de verschillen en het converteren van een querytijdparser naar een opnameparser.

Volgende stappen

Zie voor meer informatie: