Delen via

Normalisatie van opnametijd

  • Artikel

Querytijd parseren

Als discussie in het ASIM-overzicht gebruikt Microsoft Sentinel zowel querytijd als opnametijdnormalisatie om te profiteren van de voordelen van elk van deze functies.

Als u de normalisatie van querytijd wilt gebruiken, gebruikt u de querytijd die parsers samenvoegt, zoals _Im_Dns in uw query's. Normaliseren met het parseren van querytijd heeft verschillende voordelen:

  • Behoud van de oorspronkelijke indeling: normalisatie van querytijd vereist niet dat de gegevens worden gewijzigd, waardoor de oorspronkelijke gegevensindeling behouden blijft die door de bron wordt verzonden.
  • Mogelijke dubbele opslag vermijden: omdat de genormaliseerde gegevens alleen een weergave van de oorspronkelijke gegevens zijn, hoeft u zowel oorspronkelijke als genormaliseerde gegevens niet op te slaan.
  • Eenvoudiger ontwikkelen: aangezien parsers voor querytijd een weergave van de gegevens presenteren 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 wordt de oplossing toegepast op bestaande gegevens.

Opnametijd parseren

Hoewel ASIM-querytijdparsers zijn geoptimaliseerd, kan het parseren van querytijd query's vertragen, met name voor grote gegevenssets.

Bij het parseren van opnametijd kunnen gebeurtenissen worden omgezet in een genormaliseerd schema, omdat ze worden opgenomen in Microsoft Sentinel en in een genormaliseerde indeling worden opgeslagen. Opnametijd parseren 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 dicht bij, maar niet identiek, aan een ASIM-schema biedt ook de prestatievoordelen van opnametijdnormalisatie.

Momenteel ondersteunt ASIM de volgende systeemeigen genormaliseerde tabellen als bestemming voor opnametijdnormalisatie:

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

Normalisatie van opnametijd en querytijd combineren

Query's moeten altijd gebruikmaken van de querytijd die parsers samenvoegt, bijvoorbeeld _Im_Dns om te profiteren van zowel querytijd als opnametijdnormalisatie. Systeemeigen genormaliseerde tabellen worden opgenomen in de opgevraagde gegevens met behulp van een stubparser.

De stub-parser is een querytijdparser die wordt gebruikt als invoer voor de genormaliseerde tabel. Omdat de genormaliseerde tabel geen parsering vereist, is de stubparser efficiënt.

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

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

Wanneer u aangepaste genormaliseerde tabellen gebruikt, maakt u uw eigen stubparser om deze functionaliteit te implementeren en voegt u deze toe aan de samenvoegingsparsers, zoals beschreven in Parsers beheren. Gebruik de stub-parser voor de systeemeigen tabel, zoals de stubparser van de DNS-tabel en de bijbehorende filterteer, als uitgangspunt. Als uw tabel semi-genormaliseerd is, gebruikt u de stubparser om de extra parsering en normalisatie uit te voeren die nodig zijn.

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

Opnametijdnormalisatie implementeren

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

Een KQL-transformatiequery is de kern van een DCR. De KQL-versie die in DCR's wordt gebruikt, 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 querytimeparser wijzigen om deze te gebruiken in een DCR. Lees voor meer informatie over de verschillen en hoe u een parser voor querytijd converteert naar een opnametijdparser, meer informatie over de KQL-beperkingen van DCR.

Volgende stappen

Zie voor meer informatie: