Normalisatie van innametijd

Parseren tijdens querytijd

Zoals besproken in het ASIM-overzicht, gebruikt Microsoft Sentinel zowel normalisatie van querytijd als opnametijd om te profiteren van de voordelen van elk van deze.

Als u normalisatie tijdens querytijd wilt gebruiken, gebruikt u de unificerende parsers voor querytijd, zoals _Im_Dns in uw query's. Normaliseren door tijdens de query te parseren 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.
  • Potentiële dubbele opslag voorkomen: omdat de genormaliseerde gegevens alleen een weergave van de oorspronkelijke gegevens zijn, hoeft u niet zowel oorspronkelijke als 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 wordt toegepast op bestaande gegevens.

Inslestijd parseren

Hoewel ASIM-querytijdparsers zijn geoptimaliseerd, kan parseren tijdens query-uitvoering query’s vertragen, met name bij grote datasets.

Met parseren tijdens opname kunt u gebeurtenissen omzetten naar een genormaliseerd schema terwijl ze in Microsoft Sentinel worden opgenomen, en ze opslaan in een genormaliseerde indeling. Parseren tijdens opname is minder flexibel en parsers zijn lastiger te ontwikkelen, maar omdat de gegevens in een genormaliseerde indeling worden opgeslagen, levert dit betere prestaties op.

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 tijdens opname:

Het voordeel van ingebouwde genormaliseerde tabellen is dat ze standaard zijn opgenomen in de ASIM-unificatieparsers. Aangepaste genormaliseerde tabellen kunnen worden opgenomen in de parseringsfuncties, zoals beschreven in Parsers beheren.

Normalisatie van opnametijd en querytijd combineren

Query's moeten altijd de parseringsfuncties voor querytijd-uning gebruiken, bijvoorbeeld _Im_Dns om te profiteren van zowel querytijd als opnametijdnormalisatie. 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 geeft een weergave van 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. De ASIM-genormaliseerde tabel wordt door veel bronnen gebruikt en ingest-timeparsers kunnen de versie van hun uitvoer 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 ASIM-eigen tabellen geen filterparser nodig hebben voor betere prestaties, is filtering wel nodig om opname in de uniformerende 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 samenvoegingsparseer zoals beschreven in Parsers beheren. Gebruik de stub-parser voor de systeemeigen tabel, zoals de systeemeigen dns-stub-parser en de bijbehorende tegenhanger voor filteren, 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 vindt u in ASIM-parsers ontwikkelen.

Normalisatie van inleestijd 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. Zie 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 in DCR's wordt gebruikt, verschilt enigszins van de versie die elders in Microsoft Sentinel wordt gebruikt om te voldoen aan vereisten voor de verwerking van pijplijngebeurtenissen. Daarom moet u elke parser voor querytijd aanpassen om die in een DCR te gebruiken. Lees meer over de DCR KQL-beperkingen voor meer informatie over de verschillen en hoe u een queryparser converteert naar een opnameparser.

Verwante onderwerpen

  • Last updated on