Inmatningstidsnormalisering

Frågetidsparsning

Som diskussion i ASIM-översikten använder Microsoft Sentinel både frågetids- och inmatningstidsnormalisering för att dra nytta av fördelarna med var och en.

Om du vill använda tidsnormalisering för frågor använder du frågetidens enande parsrar, 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 dataformatet som skickas av källan.
  • Undvika 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ågetidsparsers visar en vy över data och inte ändrar data är de enkla att utveckla. Du kan utveckla, testa och åtgärda en parser på befintliga data. Dessutom kan parsers åtgärdas när ett problem identifieras och korrigeringen tillämpas på befintliga data.

Parsning av inmatningstid

Medan ASIM-frågeparsrar är optimerade kan frågetidsparsning göra frågor långsammare, särskilt för 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 lagrar dem i ett normaliserat format. Parsning vid inmatning är mindre flexibel och tolkarna är svårare att utveckla, men eftersom datan lagras i ett normaliserat format ger det bättre prestanda.

Normaliserade data kan lagras i Microsoft Sentinel interna 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.

ASIM stöder för närvarande följande interna normaliserade tabeller som mål för inmatningstidsnormalisering:

Fördelen med interna normaliserade tabeller är att de ingår som standard i ASIM-enande parsrar. Anpassade normaliserade tabeller kan inkluderas i de unifierande parserna, som beskrivs i Hantera parser.

Kombinera inmatningstid och normalisering av frågetid

Frågor bör alltid använda frågetiden för att förena parsrar, 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.

Stubbparsern är en parser som körs vid frågetillfället och använder den normaliserade tabellen som indata. Eftersom den normaliserade tabellen inte kräver parsning är stub-parsern effektiv.

Stubbtolken tillhandahåller den anropande frågan en vy som utökar 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 ASIM-normaliserade 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 utdataversionen. 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 ASIM:s interna tabeller inte behöver filtreringsparsers för att uppnå bättre prestanda, krävs filtrering för att de ska kunna ingå i den enhetliga parsern.
  • Uppdateringar och korrigeringar – Med en stub-parser kan du åtgärda problem snabbare. Om data till exempel matades in felaktigt kanske 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 enande parsarna enligt beskrivningen i Hantera parser. Använd stub-parsern för den interna tabellen, till exempel den interna 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 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 inmatningstid 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 bearbetning av pipelinehändelser. Därför måste du ändra alla parser som körs vid frågetid så att de kan användas i en DCR. Om du vill ha mer information om skillnaderna och om hur du konverterar en parser vid frågetillfället till en parser vid inmatning kan du läsa om begränsningarna för DCR KQL.

Relaterat innehåll

  • Last updated on