Créer, tester et exploiter les Custom Parsers Sophos SIEM

Un Custom Parser associe les champs d’un message de journal aux schémas d’événements standardisés de Sophos XDR. Il est utile lorsqu’une source intégrée n’est pas correctement normalisée. Le travail s’effectue dans Security Operations > Integrations > Custom Parsers : créer le parser, tester différents messages individuels, vérifier le mappage réel, puis seulement l’activer. Une souscription Next-Gen SIEM et le rôle Admin ou Super Admin sont nécessaires ; les autres rôles peuvent uniquement consulter la liste des parsers configurés.

Le parser ne configure pas le transport des journaux. La source doit d’abord fournir des données ; la présentation du SIEM distingue ingestion, normalisation et détection. Pour une intégration déjà prise en charge, commencer par établir le format source attendu plutôt que remplacer prématurément la logique du parser global.

Préparer la source, le schéma et le retour arrière

Avant de commencer, consigner produit source, format, types d’événements, référence temporelle et analyse attendue. Sophos prend en charge CEF, LEEF, JSON, XML et les messages non structurés. Chaque variante pertinente nécessite un exemple expurgé : connexions réussies et échouées, champs facultatifs absents, différentes valeurs d’utilisateur ou d’adresse. Supprimer les secrets tout en conservant la structure nécessaire au parsing.

Le schéma de destination décrit le type d’événement. Une connexion utilisateur peut correspondre à Auth, une connexion réseau à Netflow et une requête DNS à DNS. Les Custom Parsers ne prennent en charge qu’une partie des schémas XDR. Dans Data Lake Search > Schema Library, vérifier schémas et champs interrogeables ; la référence de normalisation indique aussi les champs du parser et les types de données correspondants. Le nom d’un champ ne prouve pas que la source fournisse sa valeur.

Documenter le nom du parser, son responsable, le format source, les champs de destination, les messages de test et le traitement antérieur. Pour un parser existant, sauvegarder le script précédent dans un emplacement à accès restreint. Prévoir un retour arrière sans suppression : garder les nouveaux parsers initialement désactivés, les désactiver à nouveau en cas de problème ou restaurer de manière contrôlée le script sauvegardé. Sophos ne maintient ni ne met à jour les Custom Parsers ; cette responsabilité reste à l’exploitant.

Choisir Standalone, Parent ou Child

Standalone convient à une source avec exactement un type de message et un schéma de destination.
Parent reconnaît la source et prépare les valeurs communes. Sophos recommande scwx.generic comme schéma de destination. Les Child Parsers associés normalisent chaque type d’événement.
Child nécessite un Parent et le bon schéma final. Les variables et champs du Parent sont disponibles pour le Child.

Un pare-feu peut fournir des connexions utilisateur, des connexions réseau et des événements HTTP. Un Parent reconnaît leur format commun ; trois Children traitent les contenus distincts. Un Child Parser personnalisé ne peut pas avoir d’autres Child Parsers. Cette division n’est pas automatiquement nécessaire pour une source simple unique.

Créer le parser et reconnaître précisément la source

Ouvrir Security Operations > Integrations > Custom Parsers, puis Add Custom Parser.
Donner un nom explicite, par exemple EXAMPLE_APP_JSON_AUTH. C’est un exemple libre ; produit, format et fonction doivent être identifiables.
Choisir Parent, Child ou Standalone. Pour Child, sélectionner le bon Parent, puis le format source et le schéma de destination.
Ouvrir l’éditeur avec Create. Le code de base généré contient la fonction de découpage adaptée au format choisi.

La Confirm String détermine si un message correspond au parser. !CONFIRMWITH=PATTERN sélectionne une expression régulière compatible Go ; !CONFIRMWITH=EXPRESSION une condition évaluée à vrai ou faux. Dans les deux cas, l’expression proprement dite figure dans !CONFIRMSTRING, dans le bloc de déclarations du script. Elle doit identifier assez précisément la source et éventuellement le type d’événement. Un terme général comme « network » est généralement trop large. Le modèle complet de l’exemple pratique HTTP/parser lié ci-dessous présente ensemble le mode et le matcher ; son format de laboratoire étroit n’est pas interchangeable avec l’extrait example-auth suivant.

Même un parser syntaxiquement valide peut capter les messages d’autres sources. Sophos ne garantit pas d’ordre fixe pour toutes les collisions possibles. Tester également au moins un message similaire qui ne doit pas correspondre au nouveau parser. Vérifier ensuite dans l’extractor path quels Parent et Child ont réellement été utilisés.

Mapper les champs et vérifier les horodatages

Le script distingue les variables locales des champs du parser terminés par $. Seuls les champs correspondant au schéma de destination sont normalisés ; un nom arbitraire avec $ ne crée pas un nouveau champ de schéma. Les champs de schéma emploient souvent snake_case, ceux du parser camelCase. Vérifier l’orthographe exacte dans le schéma choisi.

Ce JSON fictif constitue un petit point de départ pour un mappage Auth :

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

192.0.2.25 est une adresse de documentation, pas une cible de production. Un extrait de script JSON peut lire l’utilisateur et l’adresse source ainsi :

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

Une définition complète pour un format synthétique strictement défini, avec horodatage, correspondance des enums et validation par recherche, figure dans l’exemple pratique HTTP/parser.

Le fragment suivant n’est pas une définition complète de parser. Confirm String, schéma, horodatage, action d’authentification et résultat manquent volontairement et doivent correspondre au format réel. En particulier, ne pas copier sans contrôle le texte success dans un champ enum numérique. Le schéma Auth définit notamment SUCCESS et FAILED pour action_result ; vérifier explicitement leur mappage.

Pour l’horodatage, comparer valeur brute, fuseau horaire et event_time_usec normalisé. La fonction DATETIME() utilise les modèles de format temporel Go. Un fuseau incorrect peut produire une analyse techniquement réussie mais temporellement fausse. Vérifier aussi les valeurs communes extraites par le Root Parser face à la source.

Les champs répétés, comme plusieurs pièces jointes, indicateurs ou enregistrements de métadonnées, nécessitent des listes d’objets adaptées au schéma. Une chaîne séparée par des virgules ne remplace pas cette structure. ADDFIELD() peut combiner des tableaux en objets répétés ; les positions correspondantes doivent rester alignées dans les tableaux JSON. Une valeur absente ne doit pas, par exemple, associer un hash au mauvais type de fichier.

Tester des messages individuels et lire les résultats

Si la source envoie déjà des données, rechercher des messages bruts adaptés dans Data Lake Search avec FROM generic WHERE sensor_id='[my data source]'. Remplacer le paramètre par l’identifiant source vérifié dans les événements réels. Dans les détails, choisir Original Data > Copy Original Data, puis coller dans Sample Message dans l’éditeur. Sinon, utiliser une seule ligne de journal expurgée, pas un fichier entier.

Vérifier d’abord le découpage avec Parse Message. Parsed Source Message montre les paires clé/valeur des formats structurés ou les parties indexées des messages non structurés.
Dans Source Destination Mapping, contrôler quelles valeurs sources alimentent quels champs. Comparer séparément utilisateur, adresses source/destination, heure, action et résultat au message brut.
Vérifier l’extractor path. Il doit montrer le chemin attendu. Un avertissement signalant un autre parser n’est pas cosmétique.
Ajouter des messages représentatifs et d’autres volontairement non concordants. Avec Parent/Child, tester reconnaissance commune et affectation au Child.
Exécuter Run Test pour tous les exemples enregistrés et comparer schéma, valeurs et chemin. Sophos recommande des tests répétés, environ 12 à 15 exécutions, pour repérer les correspondances incorrectes variables. Un nombre donné ne garantit pas le traitement correct de tous les futurs messages.

Les outils testent le contenu actuel de l’éditeur sans l’enregistrer. Un parser invalide désactivé peut être enregistré ; l’enregistrement seul ne constitue donc pas une validation fonctionnelle. Si des champs manquent, vérifier d’abord contenu source, type de données, noms exacts et éventuel découpage du message.

Enregistrer et activer de manière contrôlée

Pour un nouveau parser, Save and Continue enregistre le brouillon. Les nouveaux parsers sont désactivés par défaut. Après validation, quitter avec Exit, sélectionner l’icône Play dans Actions de la liste, puis confirmer Enable. Activer le Parent avant les Children.

Après activation, générer un événement source inoffensif autorisé ou corréler sans ambiguïté un événement déjà attendu. Rechercher les résultats normalisés par source, heure, schéma et champs prévus. Sophos donne par exemple WHERE sensor_type=[your_sensor_type] ; le paramètre représente le type réellement présent et n’est pas une requête complète prête à copier.

Le traitement vers les schémas supplémentaires se fait parallèlement aux événements génériques. Un résultat prouve d’abord seulement la normalisation vérifiée. Les détecteurs automatiques ne sont pas garantis pour chaque source personnalisée. Les chemins documentés comprennent DGA et Domain Watchlist via DNS query_name, et IP Watchlist via les adresses source/destination dans NIDS ou Netflow. Valider séparément la détection attendue ; un événement de test ordinaire n’a pas forcément à créer une alerte.

Respecter les règles client et les responsabilités MDR

is_custom_alert, ou vendor_alert_details.is_custom_alert pour Email, identifie l’origine d’une règle d’alerte. Selon l’aide des schémas, les détections ainsi marquées Custom Alert avec true sont envoyées directement au tenant pour traitement autonome et n’entrent pas dans la file du service MDR ; leur gravité reste inchangée. Ne pas positionner ce marqueur pour faire passer une alerte client pour une détection fournisseur non modifiée.

Cela ne signifie pas que tout message normalisé par un Custom Parser relève automatiquement de cette exclusion. Événement source, détection résultante et responsabilité du cas restent distincts. L’article Cases et Rules explique la limite existante des Self-managed Cases issus de règles client.

Dépanner et revenir en arrière en sécurité

Mauvais parser dans extractor path : Comparer les Confirm Strings concernées. En cas de collision avec un parser global, demander à Sophos Support de vérifier la spécificité au lieu d’empiler d’autres overrides trop larges.

Message uniquement dans generic : Vérifier transport et message brut, puis Confirm String, parser actif et schéma. L’absence seule de résultat normalisé ne prouve pas une panne de transport.

Script valide, valeurs fausses : Comparer message brut et mappage champ par champ, surtout heure et enums. Pour un parser actif, restaurer de façon contrôlée la version sauvegardée après une modification erronée, puis revérifier.

Désactiver un nouveau parser défectueux avec l’icône Pause et Disable. Dans une hiérarchie, tous les Children doivent être désactivés ou supprimés avant de désactiver le Parent. La normalisation supplémentaire cesse immédiatement, mais les événements génériques continuent d’être créés. Ce retour arrière ne corrige pas automatiquement les données historiques mal normalisées ni les détections qui en résultent.

La suppression avec l’icône corbeille et Delete est irréversible. Une désactivation suffit généralement pour un premier retour arrière. Décider la suppression définitive après sauvegarde, clarification des dépendances et validation.

Les parsers globaux ne sont pas modifiables directement. Un Override remplace leur traitement pour un cas précis, une Extension ajoute des types d’événement jusque-là non normalisés. Tous deux nécessitent la bonne association au Parent global et une maintenance propre. Sans nom univoque et mappage vérifié, conserver le chemin global ; ne pas corriger en production un fuseau ou un nouveau format par un Override non testé.