Normalisatie van opnametijd

Parseren van 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 querytijdnormalisatie wilt gebruiken, gebruikt u de parseringsfuncties voor querytijd,zoals_Im_Dns in uw query's. Normalisatie met behulp van querytijdparsering 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.

Opnametijd parseren

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

Met het parseren van opnametijd kunt u gebeurtenissen transformeren naar een genormaliseerd schema wanneer ze worden opgenomen in Microsoft Sentinel en deze opslaan in een genormaliseerde indeling. Het parseren van opnametijd is minder flexibel en parsers zijn moeilijker te ontwikkelen, maar omdat de gegevens in een genormaliseerde indeling worden opgeslagen, bieden ze 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-parseringsparsers. 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 genormaliseerde ASIM-tabel wordt gedeeld door veel bronnen en opnametijdparser's kunnen 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 parseringsfunctie voor unifying 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 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. 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 een querytijdparser wijzigen om deze te gebruiken in een DCR. Lees over de DCR KQL-beperkingen voor meer informatie over de verschillen en hoe u een querytijdparser converteert naar een opnametijdparser.

Volgende stappen

Zie voor meer informatie:

  • Last updated on