Envoyer Windows Event Log à Sophos XDR et SIEM

Microsoft Windows Event Log peut être transmis par un forwarder pris en charge, au format Snare-over-syslog, à un Sophos XDR Data Collector. Ce chemin est distinct de l’agent Sophos Endpoint : une Event ID locale ou un état Endpoint vert ne prouve pas que l’événement a été collecté par cette intégration.

Le parcours consiste à déployer le collecteur, définir événements et audit Windows, diriger le forwarder au bon format vers UDP/514, puis vérifier un événement précis dans Sophos.

Confirmer périmètre et licences avant déploiement

Selon les événements réellement transmis, l’intégration peut recevoir authentisations, changements de comptes/groupes, processus, détections Defender, changements administratifs, audits d’annuaire et autres événements. Les schémas documentés sont auth, process, antivirus, managementevent, cloudaudit, thirdpartyalert, encrypt et netflow.

La licence SIEM concerne la télémétrie netflow, par exemple les connexions Windows Filtering Platform comme l’événement 5156. Cela ne rend pas tous les autres événements cités dépendants de SIEM. Les droits d’intégration et de source nécessaires au tenant XDR/MDR doivent néanmoins être présents. L’article SIEM et le guide d’intégration expliquent cette vérification.

Préparer collecteur, forwarder et protection des données

Il faut un XDR Data Collector opérationnel, un chemin réseau approuvé depuis Windows et un logiciel capable d’émettre du Snare-over-syslog. Sophos cite notamment Snare Enterprise, NXLog Enterprise, TIBCO Universal Collector, Syslog-ng Agent for Windows et NXLog Community Edition. Cela ne signifie pas qu’ils partagent champs, licences et fichiers de configuration.

Le runbook du collecteur couvre ressources, DNS, heure et uplinks. Ici, autoriser UDP/514 entrant uniquement depuis les réseaux Windows prévus. UDP ne confirme pas chaque message ; un test réseau ou de port ne remplace pas une preuve événementielle.

Avant configuration, documenter ordinateurs ou contrôleurs de domaine sources, Event IDs requises, audit existant, équipe responsable et ancien chemin. Les événements peuvent contenir noms d’utilisateurs, chemins et arguments de processus. Limiter la collecte au contenu autorisé et ne pas joindre logs bruts ou identifiants à des tickets publics.

Configurer la transmission Windows

Dans le bon tenant Sophos, identifier le collecteur sous Security Operations > Integrations > Data Collectors. Utiliser son IP joignable depuis Windows, pas une adresse régionale d’upload Sophos ou une autre appliance.
Installer le forwarder choisi sur un ordinateur pilote approuvé selon sa documentation. Sauvegarder sa configuration existante et identifier les autres sorties avant de modifier un fichier partagé.
Choisir explicitement Snare-over-syslog. Sophos exige ce format ; JSON arbitraire, CEF ou XML Windows Event ne sont pas des remplaçants confirmés pour ce chemin.
Configurer comme destinataire l’IP réelle du collecteur et le port UDP 514. Canaux et filtres doivent inclure les événements nécessaires.
Émettre les horodatages en UTC et vérifier la synchronisation Windows. L’affichage local d’Event Viewer ne prouve pas le fuseau effectivement transmis.
Activer la configuration et examiner les erreurs locales du forwarder. Valider les événements ci-dessous avant d’étendre à d’autres ordinateurs.

Pour NXLog CE, téléchargez le modèle de configuration nxlog_wel.txt fourni par Sophos. Ce modèle sert de point de départ pour le format Snare documenté, et non de remplacement sans vérification de toute configuration NXLog existante. La cible du Collector, les événements sélectionnés et les sorties existantes doivent correspondre à l’environnement.

Le modèle actuellement lié définit define PORT 601 et utilise, dans le bloc MSWINEVENTLOGOUT, Module om_tcp ; il ne convient donc pas sans modification au chemin UDP/514 décrit ici. Pour ce chemin :

Dans define XDR A.B.C.D, remplacez uniquement l’espace réservé A.B.C.D par l’IP réelle du Collector ; conservez define XDR.
Définissez la ligne du port sur define PORT 514.
Dans le bloc de sortie MSWINEVENTLOGOUT, commentez la ligne Module om_tcp et activez la ligne existante Module om_udp. Ne laissez qu’un seul module de sortie actif dans ce bloc ; préservez séparément les autres sorties existantes.

Vérifiez ensuite la syntaxe et la livraison des événements lors du pilote. Sophos propose une assistance best effort ; les problèmes plus avancés du forwarder relèvent de son fournisseur.

Ligne de commande du processus pour l’événement 4688

Certaines détections nécessitent des champs non journalisés par défaut. Pour ajouter la ligne de commande à la création du processus dans l’événement 4688, Sophos indique cette policy Windows :

Administrative Templates > System > Audit Process Creation > Include command line in process creation events

Ne l’activer que dans le périmètre autorisé après examen du contenu. Les lignes de commande peuvent contenir des données sensibles. Ce réglage ne remplace ni la création requise des événements d’audit de processus ni le filtre 4688 du forwarder.

Pour vérifier, lancer un processus autorisé et inoffensif sans secret dans ses arguments. Confirmer d’abord la ligne attendue dans l’événement Windows 4688, puis comparer le process normalisé dans Sophos. Un champ absent à la source ne peut pas être reconstitué par le collecteur.

Prouver la collecte avec un événement source

Une connexion autorisée avec un compte de test dédié convient pour commencer. Les événements 4624 et 4625 peuvent prouver réussite ou échec d’authentisation ; un échec délibéré ne doit pas provoquer de verrouillage de compte. Utiliser uniquement un événement réellement produit dans le scope d’audit et de forwarding choisi.

Noter dans Windows Event ID, ordinateur, utilisateur, résultat et heure. Ne conserver que des valeurs nettoyées dans le protocole de test.
Vérifier que le forwarder émet cette catégorie sans erreur locale de format, droits ou connexion.
Dans le bon tenant Sophos, examiner le flux source puis le record dans le schéma attendu. Comparer ordinateur, heure, utilisateur et résultat à Windows. Un login relève de auth, l’événement 4688 de process.
Répéter pour les autres catégories requises. Un login ne prouve pas la collecte de findings Defender, d’audits d’annuaire ou de netflow.
Comparer les nouveaux événements pendant une période adaptée et documenter scope, responsable et prochain contrôle pour la validation.

L’événement ne doit pas nécessairement créer une détection ou un case MDR. Une collecte réussie aujourd’hui ne prouve ni complétude historique ni rétention garantie pour toutes les données. Vérifier séparément licences et conservation.

Rechercher les champs manquants et interruptions

Aucun événement Windows : vérifier d’abord audit, canal sélectionné et activité réelle. Sans événement source, rien ne peut être transmis.

Événement source présent mais rien dans Sophos : comparer filtres, format Snare-over-syslog, UTC, IP et réseau UDP/514. Examiner ensuite collecteur et flux pendant la bonne période. Ne pas ajouter préventivement un deuxième forwarder au même flux.

Événement présent mais champ requis absent : comparer Windows original, sortie du forwarder et record normalisé. Pour les arguments, contrôler 4688 et la policy approuvée. Ne pas inventer de valeur par défaut.

Seul netflow manque : vérifier séparément événements Windows Filtering Platform, sélection du forwarder et entitlement SIEM. Le fonctionnement du chemin login ne prouve pas ce scope supplémentaire.

Annuler le pilote ou transférer l’exploitation

Pour revenir en arrière, arrêter uniquement la nouvelle sortie ou le filtre pilote et restaurer de façon contrôlée la configuration sauvegardée. Conserver autres sorties et collecteurs partagés. Une policy d’audit ne doit être annulée qu’après comparaison avec son état initial documenté et autorisation ; d’autres exigences de sécurité ou de preuve peuvent en dépendre.

Vérifier ensuite que l’ancien chemin nécessaire fonctionne et qu’aucune double collecte involontaire n’existe. Arrêter le forwarder ne restaure pas les événements UDP perdus et ne prouve pas la suppression des données envoyées. En exploitation, l’équipe désignée reste responsable du périmètre, de l’heure, du flux, des modèles et des mises à jour du forwarder.