Skapa, testa och förvalta Sophos SIEM Custom Parsers

En Custom Parser mappar fälten i ett loggmeddelande till Sophos XDR:s standardiserade händelsescheman. Den hjälper när en ansluten källa inte normaliseras korrekt. Arbetet görs under Security Operations > Integrations > Custom Parsers: skapa parsern, testa olika enskilda meddelanden, kontrollera den faktiska mappningen och aktivera först därefter. En Next-Gen SIEM-prenumeration och rollen Admin eller Super Admin krävs; andra roller kan bara visa listan över konfigurerade parsrar.

Parsern konfigurerar inte loggtransporten. Källan måste först leverera data; SIEM-översikten skiljer mellan insamling, normalisering och detektion. För en integration som redan stöds bör det förväntade källformatet först säkerställas, i stället för att den globala parserlogiken åsidosätts för tidigt.

Förbered källa, schema och återställningsväg

Dokumentera källprodukt, format, händelsetyper, tidsreferens och önskad analys före start. Sophos stöder CEF, LEEF, JSON, XML och ostrukturerade meddelanden. Varje relevant variant behöver ett rensat exempel: lyckade och misslyckade inloggningar, saknade valfria fält samt olika användar- och adressvärden. Ta bort hemligheter men behåll strukturen som parsningen kräver.

Målschemat beskriver händelsetypen. En inloggning passar exempelvis i Auth, en nätverksanslutning i Netflow och en DNS-fråga i DNS. Custom Parsers stöder bara en del av alla XDR-scheman. Kontrollera sökbara scheman och fält under Data Lake Search > Schema Library; normaliseringsreferensen anger även motsvarande parserfält och datatyper. Ett fältnamn i sig bevisar inte att källan levererar värdet.

Dokumentera parsernamn, ansvarig, källformat, önskade målfält, testmeddelanden och tidigare behandling i ändringen. För en befintlig parser sparas den tidigare skripttexten åtkomstskyddat. Återställningen bör fungera utan radering: håll nya parsrar avstängda till en början, inaktivera dem vid problem eller återställ den sparade skriptversionen kontrollerat. Sophos underhåller eller uppdaterar inte Custom Parsers; ansvaret ligger hos operatören.

Välj Standalone, Parent eller Child

• Standalone passar en källa med exakt en meddelandetyp och ett målschema.
• Parent identifierar källan och förbereder gemensamma värden. Sophos rekommenderar scwx.generic som målschema. Tillhörande Child Parsers normaliserar de enskilda händelsetyperna.
• Child behöver en Parent och rätt slutligt målschema. Variabler och parserfält från Parent är tillgängliga för Child.

En brandvägg kan exempelvis leverera inloggningar, nätverksanslutningar och HTTP-händelser. En Parent identifierar det gemensamma källformatet; tre Children hanterar innehållsskillnaderna. Egna Child Parsers kan inte ha ytterligare Child Parsers. En enda enkel källa kräver inte automatiskt denna uppdelning.

Skapa parsern och identifiera källan entydigt

1. Öppna Security Operations > Integrations > Custom Parsers och välj Add Custom Parser.
2. Ange ett tydligt namn, exempelvis EXAMPLE_APP_JSON_AUTH. Namnet är ett fritt valt exempel; produkt, format och uppgift ska framgå.
3. Välj Parent, Child eller Standalone. För Child väljs rätt Parent, därefter källformat och målschema.
4. Öppna skripteditorn med Create. Den genererade grundmallen innehåller uppdelningsfunktionen för det valda formatet.

Confirm String avgör om ett meddelande tillhör parsern. !CONFIRMWITH=PATTERN väljer ett Go-kompatibelt reguljärt uttryck; !CONFIRMWITH=EXPRESSION ett villkor som ger sant eller falskt. Själva uttrycket anges i båda fallen i !CONFIRMSTRING i skriptets deklarationsblock. Det måste identifiera avsedd källa och eventuell händelsetyp tillräckligt exakt. Ett allmänt ord som ”network” är oftast för brett. Den sammanhängande mallen i det HTTP-/parserexempel som länkas nedan visar läge och matcher tillsammans; dess snäva labbformat är inte utbytbart mot följande example-auth-utdrag.

Även en syntaktiskt giltig parser kan fånga andra källors meddelanden. Sophos garanterar ingen fast ordning vid alla möjliga parserkollisioner. Testa därför minst ett liknande meddelande som inte ska tillhöra den nya parsern. Kontrollera senare i extractor path vilken Parent och Child som faktiskt användes.

Mappa fält och kontrollera tidsstämplar

Skriptet skiljer mellan lokala variabler och parserfält som slutar med $. Bara parserfält som passar målschemat normaliseras; ett valfritt eget fältnamn med $ skapar inget nytt schemafält. Schemafält använder ofta snake_case, parserfält camelCase. Kontrollera exakt stavning mot det valda schemat.

Detta fiktiva JSON-meddelande är en liten utgångspunkt för en Auth-mappning:

{"product":"example-auth","user":"pilot-user","src_ip":"192.0.2.25","time":"2026-10-27T10:15:00Z","result":"success"}

192.0.2.25 är en dokumentationsadress, inget produktionsmål. Ett JSON-skriptutdrag kan läsa användare och källadress så här:

json = JSON(originalData$)
sourceUserName$ = json["$.user"]
sourceAddress$ = json["$.src_ip"]

En fullständig mall för ett snävt definierat syntetiskt format med tidsstämpel, enum-mappning och sökverifiering finns i det praktiska HTTP-/parserexemplet.

Detta är ingen fullständig parserdefinition. Confirm String, schema, tidsstämpel, autentiseringsåtgärd och resultat saknas avsiktligt och måste passa det faktiska källformatet. Kopiera framför allt inte texten success okontrollerat till ett numeriskt enumfält. Auth-schemat definierar exempelvis SUCCESS och FAILED för action_result; kontrollera deras parsermappning uttryckligen.

Jämför råvärde, tidszon och normaliserat event_time_usec för tidsstämpeln. Parserfunktionen DATETIME() använder Go-formatmallar för tid. Ett tidsvärde med fel zon kan ge tekniskt lyckad men tidsmässigt fel analys. Kontrollera även gemensamma värden som Root Parser har tagit fram mot källan.

Upprepade fält, exempelvis flera bilagor, indikatorer eller metadataposter, kräver objektlistor som passar schemat. En kommaseparerad sträng ersätter inte en sådan struktur. ADDFIELD() kan förena arrayer till upprepade objekt; i JSON-arrayer måste tillhörande positioner bevaras. Saknade värden får exempelvis inte göra att en hash kopplas till fel filtyp.

Testa enskilda meddelanden och läs resultaten

Om källan redan skickar data kan passande råmeddelanden sökas under Data Lake Search med FROM generic WHERE sensor_id='[my data source]'. Ersätt platshållaren med källidentifieraren som har kontrollerats mot faktiska händelser. Välj Original Data > Copy Original Data i händelsedetaljerna och klistra in i Sample Message i parsereditorn. Använd annars en enskild rensad loggrad, inte en hel loggfil.

1. Kontrollera först uppdelningen med Parse Message. Parsed Source Message visar nyckel/värde-par för strukturerade format eller indexerade delar för ostrukturerade meddelanden.
2. Kontrollera under Source Destination Mapping vilka källvärden som hamnar i vilka schemafält. Jämför användare, käll-/måladress, tid, åtgärd och resultat var för sig mot råmeddelandet.
3. Kontrollera extractor path. Den måste visa avsedd parserväg. En varning om en annan parser är ingen kosmetisk detalj.
4. Lägg till fler representativa och avsiktligt icke-matchande meddelanden. Testa både gemensam identifiering och Child-tilldelning vid Parent/Child.
5. Kör Run Test för alla sparade exempel och jämför schema, fältvärden och parserväg. Sophos rekommenderar upprepade tester, omkring 12 till 15 körningar, för att upptäcka växlande feltilldelningar. Ett visst antal garanterar inte korrekt behandling av alla framtida meddelanden.

Testverktygen kontrollerar aktuellt editorinnehåll men sparar det inte. En ogiltig avstängd parser kan sparas; enbart sparande är därför ingen teknisk acceptans. Om fält saknas kontrolleras först källinnehåll, datatyp, exakta parserfältnamn och eventuell uppdelning av meddelandet.

Spara och aktivera kontrollerat

För en ny parser sparar Save and Continue utkastet. Nya parsrar är avstängda som standard. Lämna editorn med Exit efter godkända tester, välj Play-symbolen under Actions i parserlistan och bekräfta med Enable. Aktivera Parent före Children i en Parent/Child-struktur.

Skapa efter aktivering en godkänd ofarlig källhändelse eller korrelera en redan förväntad händelse entydigt. Sök de normaliserade resultaten utifrån källa, tid, schema och önskade fält. Sophos anger exempelvis WHERE sensor_type=[your_sensor_type]; platshållaren betecknar den faktiska sensortypen och är ingen färdig fråga att kopiera.

Behandling till ytterligare scheman sker parallellt med generiska händelser. En sökträff bevisar först bara den kontrollerade normaliseringen. Automatiska detektorer garanteras inte för varje egen källa. Dokumenterade vägar omfattar DGA och Domain Watchlist via DNS query_name, samt IP Watchlist via käll-/måladresser i NIDS eller Netflow. Acceptera en önskad detektion separat; en vanlig testhändelse behöver inte skapa ett larm.

Beakta kundregler och MDR-ansvar

is_custom_alert, eller för Email vendor_alert_details.is_custom_alert, anger larmregelns ursprung. Enligt schemahjälpen skickas detektioner som på detta sätt märkts som Custom Alert med true direkt till tenanten för egen hantering och går inte in i MDR-servicekön; allvarlighetsgraden ändras inte. Flaggan får inte sättas så att ett kundlarm felaktigt ser ut som en oförändrad leverantörsdetektion.

Det betyder inte att varje meddelande som normaliseras av en Custom Parser automatiskt omfattas av samma undantag. Källhändelse, resulterande detektion och ärendeansvar är olika frågor. Artikeln om Cases och Rules beskriver den befintliga gränsen för Self-managed Cases från kundregler.

Felsök och återställ säkert

Fel parser i extractor path: Jämför berörda parsrares Confirm Strings. Be Sophos Support granska specificiteten vid kollision med en global parser, i stället för att lägga fler breda overrides ovanpå.

Meddelandet finns bara i generic: Kontrollera transport och råmeddelande, därefter Confirm String, aktiverad parser och valt schema. Enbart avsaknad av en normaliserad träff bevisar inte transportfel.

Giltigt skript, fel värden: Jämför råmeddelande och mappning fält för fält, särskilt tid och enumvärden. Återställ en felaktig ändring i en aktiv parser kontrollerat till den sparade versionen och kontrollera igen.

Stäng av en ny felaktig parser med Pause-symbolen och Disable. I en hierarki måste alla Children vara avstängda eller raderade innan Parent kan stängas av. Då upphör ytterligare schemanormalisering omedelbart; generiska händelser skapas fortfarande. Återställningen korrigerar inte automatiskt tidigare felnormaliserade historiska data eller detektioner som dessa orsakat.

Radering via papperskorgssymbolen och Delete kan inte ångras. Inaktivering räcker normalt vid en första återställning. Besluta om permanent borttagning först när konfigurationen säkrats, beroenden klarlagts och acceptansen slutförts.

Globala parsrar kan inte redigeras direkt. En Override ersätter deras behandling för det egna fallet, en Extension lägger till tidigare onormaliserade händelsetyper. Båda kräver korrekt global Parent-koppling och eget underhåll. Utan entydigt parsernamn och verifierad fältmappning behålls den globala vägen; korrigera inte en avvikande tidszon eller ett nytt källformat i produktion med en oprövad Override.