Mata in tidsnormalisering
Frågetidsparsning
Som diskussion i ASIM-översikten använder Microsoft Sentinel både frågetid och inmatningstidsnormalisering för att dra nytta av fördelarna med var och en.
Om du vill använda normalisering av frågetid använder du frågetiden för att förena parser, till exempel _Im_Dns i dina frågor. Normalisering med frågetidsparsning har flera fördelar:
- Bevara det ursprungliga formatet: Normalisering av frågetid kräver inte att data ändras, vilket bevarar det ursprungliga dataformat som skickas av källan.
- Undvik potentiell duplicerad lagring: Eftersom normaliserade data bara är en vy över ursprungliga data behöver du inte lagra både ursprungliga och normaliserade data.
- Enklare utveckling: Eftersom frågetidsparsrar visar en vy över data och inte ändrar data är de lätta att utveckla. Du kan utveckla, testa och åtgärda en parser på befintliga data. Dessutom kan parser åtgärdas när ett problem identifieras och korrigeringen gäller för befintliga data.
Mata in tidsparsning
Asim-frågeparsrar är optimerade, men frågetidsparsning kan göra frågor långsammare, särskilt på stora datamängder.
Genom att mata in tidsparsning kan du omvandla händelser till ett normaliserat schema när de matas in i Microsoft Sentinel och lagras i ett normaliserat format. Inmatningstiden är mindre flexibel och parsers är svårare att utveckla, men eftersom data lagras i ett normaliserat format ger bättre prestanda.
Normaliserade data kan lagras i Microsoft Sentinels inbyggda normaliserade tabeller eller i en anpassad tabell som använder ett ASIM-schema. En anpassad tabell som har ett schema nära, men inte identiskt, med ett ASIM-schema, ger också prestandafördelarna med inmatningstidsnormalisering.
För närvarande stöder ASIM följande inbyggda normaliserade tabeller som mål för inmatningstidsnormalisering:
- ASimAuditEventLogs för granskningshändelseschemat .
- ASimAuthenticationEventLogs för autentiseringsschemat .
- ASimDnsActivityLogs för DNS-schemat .
- ASimNetworkSessionLogs för nätverkssessionsschemat
- ASimWebSessionLogs för webbsessionsschemat .
Fördelen med inbyggda normaliserade tabeller är att de ingår som standard i ASIM-enhetliga parser. Anpassade normaliserade tabeller kan inkluderas i enande parser, enligt beskrivningen i Hantera parser.
Kombinera normalisering av inmatningstid och frågetid
Frågor bör alltid använda frågetiden för att förena parser, till exempel _Im_Dns för att dra nytta av både frågetid och inmatningstidsnormalisering. Interna normaliserade tabeller ingår i efterfrågade data med hjälp av en stub-parser.
Stub-parsern är en frågetidsparser som använder som indata för den normaliserade tabellen. Eftersom den normaliserade tabellen inte kräver parsning är stub-parsern effektiv.
Stub-parsern visar en vy för den anropande frågan som lägger till i den inbyggda ASIM-tabellen:
- Alias – för att inte slösa lagring på upprepade värden lagras inte alias i interna ASIM-tabeller och läggs till vid frågetillfället av stub-parsarna.
- Konstanta värden – Precis som alias och av samma anledning lagrar inte heller NORMALISERADE ASIM-tabeller konstanta värden som EventSchema. Stub-parsern lägger till dessa fält. ASIM-normaliserad tabell delas av många källor och inmatningstidsparsers kan ändra sin utdataversion. Därför är fält som EventProduct, EventVendor och EventSchemaVersion inte konstanta och läggs inte till av stub-parsern.
- Filtrering – stub-parsern implementerar också filtrering. Även om interna ASIM-tabeller inte behöver filtreringsparsrar för att uppnå bättre prestanda, krävs filtrering för att stödja inkludering i den enande parsern.
- Uppdateringar och korrigeringar – Med en stub-parser kan du åtgärda problem snabbare. Om data till exempel matades in felaktigt kan det hända att en IP-adress inte har extraherats från meddelandefältet under inmatningen. IP-adressen kan extraheras av stub-parsern vid frågetillfället.
När du använder anpassade normaliserade tabeller skapar du en egen stub-parser för att implementera den här funktionen och lägger till den i de enhetliga parsarna enligt beskrivningen i Hantera parser. Använd stub-parsern för den interna tabellen, till exempel den inbyggda DNS-tabellparsern och dess filtreringsmotsvarighet, som utgångspunkt. Om tabellen är halvnormaliserad använder du stub-parsern för att utföra den ytterligare parsning och normalisering som krävs.
Läs mer om att skriva parsers i Developing ASIM parsers (Utveckla ASIM-parsers).
Implementera inmatningstidsnormalisering
Om du vill normalisera data vid inmatning måste du använda en datainsamlingsregel (DCR). Proceduren för att implementera DCR beror på vilken metod som används för att mata in data. Mer information finns i artikeln Transformera eller anpassa data vid inmatning i Microsoft Sentinel.
En KQL-transformeringsfråga är kärnan i en DCR. KQL-versionen som används i DCR skiljer sig något från den version som används någon annanstans i Microsoft Sentinel för att tillgodose kraven för pipelinehändelsebearbetning. Därför måste du ändra valfri frågeparser för att använda den i en DCR. Mer information om skillnaderna och hur du konverterar en frågetidsparser till en parser för inmatningstid finns i avsnittet om BEGRÄNSNINGAR för DCR KQL.
Nästa steg
Mer information finns i: