Inntakstidsnormalisering

Tidsanalyse for spørring

Som en diskusjon i ASIM-oversikten bruker Microsoft Sentinel både spørringstid og inntakstidsnormalisering til å dra nytte av fordelene med hver av dem.

Hvis du vil bruke tidsnormalisering for spørring, kan du bruke spørringstiden til å samle parsere, for eksempel _Im_Dns i spørringene. Normalisering ved bruk av spørringstidsanalyse har flere fordeler:

  • Bevarer det opprinnelige formatet: Normalisering av spørringstid krever ikke at dataene endres, og dermed bevarer det opprinnelige dataformatet som sendes av kilden.
  • Unngå potensiell duplisert lagring: Siden de normaliserte dataene bare er en visning av de opprinnelige dataene, er det ikke nødvendig å lagre både opprinnelige og normaliserte data.
  • Enklere utvikling: Siden spørringstidsanalyser presenterer en visning av dataene og ikke endrer dataene, er de enkle å utvikle. Utvikling, testing og reparasjon av en analyse kan alle gjøres på eksisterende data. Analyser kan dessuten løses når et problem oppdages, og løsningen brukes på eksisterende data.

Ta inn tidsanalyse

Selv om ASIM-spørringstidsanalyser er optimalisert, kan spørringstidsanalyse redusere spørringer, spesielt på store datasett.

Inntak av tidsanalyse gjør det mulig å transformere hendelser til et normalisert skjema når de inntar til Microsoft Sentinel og lagrer dem i et normalisert format. Inntak av tidsanalyse er mindre fleksibelt, og analyser er vanskeligere å utvikle, men siden dataene er lagret i et normalisert format, får du bedre ytelse.

Normaliserte data kan lagres i Microsoft Sentinel opprinnelige normaliserte tabeller, eller i en egendefinert tabell som bruker et ASIM-skjema. En egendefinert tabell som har et skjema nær, men ikke identisk, til et ASIM-skjema, gir også ytelsesfordelene ved inntak av tidsnormalisering.

ASIM støtter for øyeblikket følgende opprinnelige normaliserte tabeller som et mål for inntak av tidsnormalisering:

Fordelen med opprinnelige normaliserte tabeller er at de er inkludert som standard i ASIM-samlende parsers. Egendefinerte normaliserte tabeller kan inkluderes i de samlende parserne, som beskrevet i Administrer analyser.

Kombinere inntakstid og normalisering av spørringstid

Spørringer bør alltid bruke spørringstiden for å samle parsere, for eksempel _Im_Dns for å dra nytte av både spørringstid og inntakstidsnormalisering. Opprinnelige normaliserte tabeller inkluderes i spørringsdataene ved hjelp av en stubparser.

Stubparseren er en spørringstidsanalyse som bruker som inndata i den normaliserte tabellen. Siden den normaliserte tabellen ikke krever analyse, er stubparseren effektiv.

Stubparseren presenterer en visning i kallspørringen som legger til den opprinnelige ASIM-tabellen:

  • Aliaser – aliaser lagres ikke i ASIM-opprinnelige tabeller for ikke å kaste bort lagringsplass på gjentatte verdier, og legges til på spørringstidspunktet av stub-parserne.
  • Konstante verdier – som aliaser, og av samme grunn lagrer ikke ASIM-normaliserte tabeller konstante verdier som EventSchema. Stubparseren legger til disse feltene. ASIM-normalisert tabell deles av mange kilder, og inntakstidsanalyser kan endre utdataversjonen. Derfor er felt som EventProduct, EventVendor og EventSchemaVersion ikke konstante og legges ikke til av stubparseren.
  • Filtrering – stubparseren implementerer også filtrering. Selv om ASIM-opprinnelige tabeller ikke trenger filtreringsanalyser for å oppnå bedre ytelse, er filtrering nødvendig for å støtte inkludering i den samlende parseren.
  • Oppdateringer og løsninger – Hvis du bruker en stubparser, kan du løse problemer raskere. Hvis data for eksempel ble tatt feil, kan det hende at en IP-adresse ikke er trukket ut fra meldingsfeltet under inntak. IP-adressen kan trekkes ut av stubparseren ved spørringstidspunktet.

Når du bruker egendefinerte normaliserte tabeller, oppretter du din egen stubparser for å implementere denne funksjonaliteten, og legger den til i de samlende parserne som beskrevet i Administrer analyser. Bruk stubparser for den opprinnelige tabellen, for eksempel dns native table stub parser og dens filtreringsmotpart, som et utgangspunkt. Hvis tabellen er halvnormalisert, kan du bruke stubparseren til å utføre den ekstra parsingen og normaliseringen som kreves.

Mer informasjon om å skrive analyser i Utvikling av ASIM-analyser.

Implementere inntakstidsnormalisering

Hvis du vil normalisere data ved inntak, må du bruke en datainnsamlingsregel (DCR). Fremgangsmåten for å implementere DCR avhenger av metoden som brukes til å inntas dataene. Hvis du vil ha mer informasjon, kan du se artikkelen Transformere eller tilpasse data ved inntakstid i Microsoft Sentinel.

En KQL-transformasjonsspørring er kjernen i en DCR. KQL-versjonen som brukes i DCR-er, er litt annerledes enn versjonen som brukes andre steder i Microsoft Sentinel for å imøtekomme kravene til behandling av datasamlebåndhendelser. Derfor må du endre en hvilken som helst spørringstidsanalyse for å bruke den i en DCR. Hvis du vil ha mer informasjon om forskjellene, og hvordan du konverterer en spørringstidsanalyse til en inntakstidsanalyse, kan du lese om DCR KQL-begrensningene.

Neste trinn

Hvis du vil ha mer informasjon, kan du se:

  • Last updated on