Sophos SIEM Custom Parser erstellen, testen und betreiben

Ein Custom Parser ordnet die Felder einer Logmeldung den standardisierten Ereignisschemas von Sophos XDR zu. Er hilft, wenn eine angebundene Quelle nicht passend normalisiert wird. Die Arbeit erfolgt unter Security Operations > Integrations > Custom Parsers: Parser anlegen, mit unterschiedlichen Einzelmeldungen testen, das tatsächliche Mapping prüfen und erst danach einschalten. Eine Next-Gen-SIEM-Subscription sowie Admin oder Super Admin sind erforderlich; andere Rollen können nur die Liste konfigurierter Parser ansehen.

Der Parser richtet den Logtransport nicht ein. Zuerst muss die Quelle Daten liefern; die SIEM-Einordnung trennt Datenaufnahme, Normalisierung und Erkennung. Für eine bereits unterstützte Integration sollte man zunächst deren erwartetes Quellformat herstellen, statt voreilig die globale Parserlogik zu überschreiben.

Quelle, Schema und Rückweg vorbereiten

Vor Beginn hält man Quellprodukt, Format, Ereignistypen, Zeitbezug und die benötigte Auswertung fest. Sophos unterstützt CEF, LEEF, JSON, XML und unstrukturierte Meldungen. Für jede relevante Variante braucht man eine bereinigte Beispielmeldung: beispielsweise erfolgreiche und fehlgeschlagene Anmeldung, fehlende optionale Felder sowie abweichende Benutzer- oder Adresswerte. Secrets werden entfernt; die für das Parsing benötigte Struktur muss erhalten bleiben.

Das Zielschema beschreibt den Ereignistyp. Eine Anmeldung passt beispielsweise zu Auth, eine Netzwerkverbindung zu Netflow und eine DNS-Anfrage zu DNS. Custom Parser unterstützen nur einen Teil aller XDR-Schemas. Unter Data Lake Search > Schema Library prüft man die suchbaren Schemas und Felder; die Normalisierungsreferenz enthält zusätzlich die jeweiligen Parserfelder und Datentypen. Ein Feldname allein belegt nicht, dass die Quelle den Wert liefert.

Für den Change dokumentiert man Parsername, Eigentümer, Quellformat, gewünschte Zielfelder, Testmeldungen und die bisherige Verarbeitung. Bei einem vorhandenen Parser wird der bisherige Skripttext zugriffsgeschützt gesichert. Der Rückweg soll ohne Löschen auskommen: neue Parser zunächst deaktiviert halten, bei Problemen wieder deaktivieren beziehungsweise den zuvor gesicherten Skriptstand kontrolliert zurückspielen. Sophos pflegt oder aktualisiert Custom Parser nicht; diese Verantwortung bleibt beim Betreiber.

Standalone, Parent oder Child wählen

• Standalone passt zu einer Quelle mit genau einem Meldungstyp und einem Zielschema.
• Parent erkennt die Quelle und bereitet gemeinsame Werte vor. Als Zielschema empfiehlt Sophos scwx.generic. Zugehörige Child Parser normalisieren die einzelnen Ereignistypen.
• Child benötigt einen Parent und das passende endgültige Zielschema. Variablen und Parserfelder des Parents stehen dem Child zur Verfügung.

Eine Firewall kann beispielsweise Anmeldungen, Netzwerkverbindungen und HTTP-Ereignisse liefern. Ein Parent erkennt das gemeinsame Quellformat; drei Children behandeln die unterschiedlichen Inhalte. Eigene Child Parser können keine weiteren Child Parser besitzen. Für eine einzelne einfache Quelle ist eine solche Aufteilung nicht automatisch erforderlich.

Parser anlegen und die Quelle eindeutig erkennen

1. Security Operations > Integrations > Custom Parsers öffnen und Add Custom Parser wählen.
2. Einen nachvollziehbaren Namen vergeben, etwa EXAMPLE_APP_JSON_AUTH. Der Name ist ein frei gewähltes Beispiel; Produkt, Format und Aufgabe sollten erkennbar sein.
3. Parent, Child oder Standalone auswählen. Bei Child den richtigen Parent wählen; anschliessend Quellformat und Zielschema festlegen.
4. Mit Create den Skripteditor öffnen. Das erzeugte Grundgerüst enthält die zum gewählten Format passende Aufteilungsfunktion.

Die Confirm String entscheidet, ob eine Meldung diesem Parser zugeordnet wird. !CONFIRMWITH=PATTERN wählt eine Go-kompatible reguläre Expression; !CONFIRMWITH=EXPRESSION eine Bedingung mit Wahr-/Falsch-Ergebnis. Der eigentliche Ausdruck steht jeweils in !CONFIRMSTRING im Deklarationsblock des Skripts. Er muss die beabsichtigte Quelle und gegebenenfalls den Ereignistyp ausreichend genau erkennen. Ein allgemeines Wort wie „network“ ist dafür meist zu breit. Die zusammenhängende Vorlage im unten verlinkten HTTP-/Parser-Praxisbeispiel zeigt Modus und Matcher gemeinsam; dessen enges Laborformat ist nicht mit dem folgenden example-auth-Ausschnitt austauschbar.

Auch ein syntaktisch gültiger Parser kann fremde Meldungen erfassen. Sophos garantiert keine feste Reihenfolge für alle möglichen Parserkollisionen. Deshalb testet man zusätzlich mindestens eine ähnliche Meldung, die nicht zum neuen Parser gehören soll. Im extractor path wird später kontrolliert, welcher Parent und welcher Child tatsächlich verwendet wurden.

Felder zuordnen und Zeitstempel prüfen

Das Skript unterscheidet lokale Variablen von Parserfeldern, die mit $ enden. Nur zum Zielschema passende Parserfelder werden normalisiert; ein beliebiger eigener Feldname mit $ erzeugt kein neues Schemafeld. Schemafelder sind häufig in snake_case, Parserfelder in camelCase geschrieben. Die genaue Schreibweise ist anhand des gewählten Schemas zu prüfen.

Dieses fiktive JSON zeigt einen kleinen Ausgangspunkt für ein Auth-Mapping:

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

192.0.2.25 ist eine Dokumentationsadresse, kein produktives Ziel. Ein auf JSON bezogener Skriptausschnitt kann Benutzer und Quelladresse wie folgt auslesen:

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

Eine vollständige Vorlage für ein eng definiertes synthetisches Format mit Zeitstempel, Enum-Zuordnung und Suchabnahme steht im HTTP-/Parser-Praxisbeispiel.

Der Ausschnitt ist noch keine vollständige Parserdefinition. Confirm String, Schema, Zeitstempel, Auth-Aktion und Ergebnis fehlen bewusst noch und müssen zum tatsächlichen Quellformat passen. Insbesondere wird der Text success nicht ungeprüft in ein numerisches Enum-Feld kopiert. Im Auth-Schema sind etwa SUCCESS und FAILED definierte Werte für action_result; ihre Parserzuordnung wird ausdrücklich geprüft.

Für den Zeitstempel vergleicht man Rohwert, Zeitzone und normalisierten event_time_usec. Die Parserfunktion DATETIME() verwendet Go-Zeitformatvorlagen. Ein Zeitwert ohne passende Zone kann eine technisch erfolgreiche, aber zeitlich falsche Auswertung erzeugen. Die vom Root Parser ermittelten gemeinsamen Werte sind ebenfalls gegen die Quelle zu prüfen.

Wiederholte Felder wie mehrere Anhänge, Indikatoren oder Metadatensätze benötigen zum Schema passende Objektlisten. Eine kommaseparierte Zeichenfolge ersetzt keine solche Struktur. ADDFIELD() kann Arrays zu wiederholten Objekten verbinden; bei JSON-Arrays müssen zusammengehörige Positionen erhalten bleiben. Fehlende Werte dürfen nicht dazu führen, dass beispielsweise ein Hash dem falschen Dateityp zugeordnet wird.

Mit Einzelmeldungen testen und Ergebnisse lesen

Wenn die Quelle bereits sendet, kann man unter Data Lake Search mit FROM generic WHERE sensor_id='[my data source]' nach passenden Rohmeldungen suchen. Der Platzhalter wird durch die anhand der tatsächlichen Ereignisse geprüfte Quellenkennung ersetzt. In den Ereignisdetails Original Data > Copy Original Data wählen und den Inhalt in Sample Message des Parsereditors einfügen. Alternativ eine einzelne bereinigte Logzeile verwenden, keine ganze Logdatei.

1. Mit Parse Message zunächst die Zerlegung prüfen. Parsed Source Message zeigt Schlüssel/Werte strukturierter Formate beziehungsweise die indizierten Teile unstrukturierter Meldungen.
2. Unter Source Destination Mapping kontrollieren, welche Quellwerte in welche Schemafelder gelangen. Benutzer, Quell-/Zieladresse, Zeit, Aktion und Ergebnis einzeln mit der Rohmeldung vergleichen.
3. Den extractor path prüfen. Er muss den vorgesehenen Parserpfad zeigen. Eine Warnung zu einem anderen Parser ist kein kosmetischer Hinweis.
4. Weitere repräsentative und absichtlich nicht passende Meldungen hinzufügen. Bei Parent/Child sowohl die gemeinsame Erkennung als auch die Child-Zuordnung testen.
5. Run Test für alle hinterlegten Beispiele ausführen und Schema, Feldwerte sowie Parserpfad vergleichen. Sophos empfiehlt wiederholte Tests, etwa 12 bis 15 Läufe, um wechselnde Fehlzuordnungen zu erkennen. Eine bestimmte Laufzahl garantiert keine korrekte Verarbeitung aller zukünftigen Meldungen.

Die Testwerkzeuge prüfen den aktuellen Editorinhalt, speichern ihn aber nicht. Ein ungültiger deaktivierter Parser kann gespeichert werden; das Speichern allein ist deshalb keine fachliche Abnahme. Fehlen Felder, prüft man zuerst Quellinhalt, Datentyp, exakte Parserfeldnamen und gegebenenfalls die Aufteilung der Meldung.

Speichern und kontrolliert aktivieren

Bei einem neuen Parser speichert Save and Continue den Entwurf. Neue Parser sind standardmässig ausgeschaltet. Nach erfolgreicher Prüfung den Editor mit Exit verlassen, in der Parserliste das Play-Symbol in Actions wählen und mit Enable bestätigen. Bei Parent/Child zuerst den Parent, danach die Children aktivieren.

Nach dem Einschalten ein freigegebenes harmloses Quellereignis erzeugen oder ein ohnehin erwartetes Ereignis eindeutig korrelieren. Die normalisierten Ergebnisse anhand von Quelle, Zeit, Schema und den vorgesehenen Feldern suchen. Sophos nennt dafür beispielsweise WHERE sensor_type=[your_sensor_type]; der Platzhalter steht für den tatsächlich vorhandenen Sensortyp und ist keine kopierbare fertige Abfrage.

Die Verarbeitung in zusätzliche Schemas erfolgt neben den generischen Ereignissen. Ein Suchtreffer belegt zunächst nur die geprüfte Normalisierung. Automatische Detektoren werden nicht pauschal für jede Custom-Quelle garantiert. Die dokumentierten unterstützten Pfade umfassen DGA und Domain Watchlist über DNS query_name sowie IP Watchlist über Quell-/Zieladressen in NIDS oder Netflow. Eine gewünschte Detection wird getrennt abgenommen; ein gewöhnliches Testereignis muss keinen Alarm erzeugen.

Kundenregeln und MDR-Zuständigkeit beachten

Die Felder is_custom_alert beziehungsweise bei Email vendor_alert_details.is_custom_alert kennzeichnen die Herkunft einer Alarmregel. Laut Schemahilfe werden entsprechend als Custom Alert markierte Detections bei true zur Selbstbearbeitung an den Tenant geschickt und nicht in die MDR-Servicequeue aufgenommen; ihr Schweregrad wird dadurch nicht verändert. Die Kennzeichnung darf nicht so gesetzt werden, dass ein Kundenalarm fälschlich wie eine unveränderte Herstellererkennung erscheint.

Das bedeutet nicht, dass jede per Custom Parser normalisierte Meldung automatisch derselben Ausschlussregel unterliegt. Quellereignis, daraus erzeugte Detection und Case-Zuständigkeit bleiben getrennte Fragen. Der Cases- und Rules-Artikel erklärt die bestehende Grenze für aus Kundenregeln entstehende Self-managed Cases.

Fehler beheben und sicher zurücknehmen

Falscher Parser im extractor path: Confirm Strings der betroffenen Parser vergleichen. Bei einer Kollision mit einem globalen Parser Sophos Support um Prüfung der Spezifität bitten, statt weitere breite Overrides aufzuschichten.

Meldung nur in generic: Transport und Rohmeldung prüfen; danach Confirm String, eingeschalteten Parser und gewähltes Schema kontrollieren. Kein normalisierter Treffer beweist für sich allein keinen Transportausfall.

Skript gültig, Werte falsch: Rohmeldung und Mapping Feld für Feld vergleichen, besonders Zeit und Enum-Werte. Bei aktiven Parsern eine fehlerhafte Änderung kontrolliert auf den gesicherten Stand zurücksetzen und erneut prüfen.

Ein neuer fehlerhafter Parser wird über das Pause-Symbol und Disable ausgeschaltet. Bei einer Hierarchie müssen alle Children deaktiviert oder gelöscht sein, bevor der Parent deaktiviert werden kann. Nach dem Abschalten endet die zusätzliche Schemanormalisierung sofort; generische Ereignisse werden weiter erstellt. Der Rückweg behebt nicht automatisch bereits falsch normalisierte historische Daten oder daraus entstandene Detections.

Löschen über das Papierkorbsymbol und Delete ist nicht wiederherstellbar. Für einen ersten Rückbau genügt normalerweise Deaktivieren. Erst nach gesicherter Konfiguration, geklärten Abhängigkeiten und abgeschlossener Abnahme über die endgültige Entfernung entscheiden.

Globale Parser selbst lassen sich nicht bearbeiten. Ein Override ersetzt deren Verarbeitung für den eigenen Anwendungsfall, eine Extension ergänzt bislang nicht normalisierte Ereignistypen. Beide benötigen die korrekte globale Parent-Zuordnung und eigene Wartung. Ohne eindeutigen Parsernamen und belegte Feldzuordnung bleibt der vorhandene globale Pfad erhalten; eine abweichende Zeitzone oder ein neues Quellformat wird nicht durch einen ungetesteten Override produktiv korrigiert.