Syslog Sophos Firewall : envoi sécurisé vers un SIEM

Avec Syslog, Sophos Firewall envoie des événements à un serveur de logs externe, un SIEM ou un SOC. Pour que l’intégration soit réellement exploitable, quatre éléments doivent correspondre : le transport, la sélection des logs, le format et l’analyseur. Cet article commence donc directement par la configuration, puis montre comment identifier les logs manquants ou mal interprétés.

Le Log viewer local reste important pour l’analyse en direct. Central Firewall Reporting convient aux rapports dans Sophos Fusion (anciennement Sophos Central) ; Syslog est le bon choix pour une conservation gérée en interne, une corrélation multifournisseur et la détection SIEM.

Configurer le serveur Syslog

Il faut d’abord définir l’adresse IP ou le FQDN de destination, le port, le format de log attendu et un analyseur adapté. Le pare-feu doit disposer d’une route vers le collecteur et les deux systèmes d’une source de temps fonctionnelle. SFOS utilise normalement UDP 514 pour Syslog. Ce formulaire ne propose pas de sélection distincte du transport : Secure log transmission active ou désactive la transmission chiffrée par TLS. L’exemple TLS officiel de Sophos pour syslog-ng utilise le port 6514 ; le port et l’écouteur doivent toujours correspondre au collecteur utilisé.

Ouvrir System services > Log settings.
Sélectionner Add.
Saisir un nom unique tel que siem-primary.
Saisir le collecteur sous IP address/domain.
Sélectionner Port, Facility, Severity level et Format en fonction du système de destination.
Activer Secure log transmission si le collecteur TLS est prêt.
Enregistrer.
Sous Log settings, activer les types de logs souhaités dans la colonne de ce serveur Syslog.

SFOS prend en charge jusqu’à cinq serveurs Syslog externes. Plusieurs destinations sont utiles lorsqu’elles remplissent des rôles différents, par exemple une archive locale et un collecteur MDR. Envoyer tous les logs sans distinction vers chaque destination augmente en revanche le volume, les coûts et les risques liés à la protection des données.

Facility, niveau de gravité et format

Facility : les choix comprennent DAEMON, KERNEL, USER et LOCAL0 à LOCAL7. On peut, par exemple, affecter LOCAL1 et LOCAL2 à deux pare-feu. L’affectation doit rester identique dans le collecteur et la documentation d’exploitation.
Severity level : la sélection correspond à la gravité minimale. Error envoie également Critical, Alert et Emergency, mais aucun événement Information ou Notice. Debug inclut tous les niveaux. Un seuil trop élevé peut donc masquer les connexions et les événements de fonctionnement courants.
Format : les options disponibles sont Standard syslog protocol et Device standard format (legacy). Le format attendu par l’analyseur SIEM est déterminant. Un changement ultérieur peut casser les recherches, les tableaux de bord et les règles de détection.

Les Facilities identifient l’origine d’un log : DAEMON désigne les processus exécutés comme services, KERNEL les processus du noyau et USER les processus démarrés par des utilisateurs connectés. LOCAL0 à LOCAL7 permettent des affectations personnalisées. Pour la gravité, Alert est plus grave que Critical et exige une action immédiate. Standard syslog protocol s’appelait auparavant Central Reporting Format ; Central Reporting utilise exclusivement ce format. Avec Device standard format (legacy), le nombre de champs varie selon le module.

Secure log transmission

TLS est pertinent pour les connexions de production passant par des réseaux non fiables ou partagés, car les logs peuvent contenir des adresses internes, des noms d’utilisateur, des URL et des événements de sécurité. Cocher la case ne suffit toutefois pas : le collecteur doit accepter TLS sur le port sélectionné et les deux côtés doivent pouvoir valider les certificats.

Les conditions suivantes s’appliquent à la connexion Secure Syslog documentée par Sophos :

Le certificat de serveur du collecteur et sa chaîne de certificats doivent être approuvés par le pare-feu.
Le FQDN configuré doit correspondre au certificat. Sans LINCE, SFOS vérifie le Common Name ; avec LINCE, le Common Name ou le Subject Alternative Name peut correspondre.
Télécharger l’autorité de certification Sophos Default sous Certificates > Certificate authorities. Le collecteur doit approuver le fichier Default.pem extrait, car Sophos utilise cette autorité de certification pour son côté de la connexion.
Activer ensuite seulement Secure log transmission avec le port TLS préparé.

Dans l’exemple officiel syslog-ng, Default.pem et l’autorité de certification externe se trouvent dans le répertoire des autorités de certification du collecteur ; peer_verify(required-trusted) impose la validation des certificats. Les autres produits de collecte utilisent leurs propres magasins de confiance. Un FQDN présent uniquement dans le SAN ne fonctionne pas sans LINCE, et une adresse IP configurée ne correspond pas à un certificat qui contient uniquement un nom DNS.

Avant d’activer LINCE à cette fin, vérifier la limite de certification, les algorithmes autorisés et le redémarrage SSH du mode LINCE. Le mode n’est pas un simple commutateur syslog et ne doit pas être activé sans accès d’administration indépendant.

Si un SIEM cloud ne prend pas directement en charge cette méthode, le pare-feu peut envoyer les logs en interne à un collecteur local, qui les retransmet ensuite de manière chiffrée. Un éventuel segment non chiffré doit être court, segmenté et documenté.

Préparer un collecteur TLS avec syslog-ng

Cet exemple nécessite un collecteur Linux avec syslog-ng, la prise en charge TLS activée et un certificat de serveur émis par une autorité de certification externe. Le pare-feu est le client émetteur. ExternalCertificate.pem est le certificat de serveur, ExternalPrivateKey.key sa clé privée et ExternalCA.pem l’autorité émettrice. Ces noms sont des exemples ; adapter les chemins et certificats au collecteur. Protéger la clé privée sur le collecteur ; la clé privée de l’autorité de certification du pare-feu n’est pas nécessaire.

Vérifier l’autorité existante sous Certificates > Certificate authorities > Default. Son nom ne peut pas être modifié. Country name, State et Locality name décrivent le pays, la région et la ville ; Organization name et Organization unit name, le titulaire et le service. Common name contient un nom ou FQDN, et Email address, un contact. Private key password permet de modifier un mot de passe existant. Key type propose RSA ou Elliptic curve : sélectionner Key length pour RSA ou Curve name pour Elliptic curve ; Secure hash définit l’algorithme de hachage. Key length est la taille de la clé RSA en bits ; des clés plus grandes offrent une marge de sécurité accrue, mais demandent davantage de calcul. Les exemples d’identité de CA sont Example AG, IT Security et fw01.example.com ; les remplacer par le titulaire, le service et la convention de nommage approuvée de l’environnement. Ces attributs ne sont pas le certificat de serveur du collecteur et ne remplacent pas son FQDN correspondant.

Protéger l’autorité existante : Ne pas modifier ni régénérer l’autorité Default uniquement pour Syslog. Planifier tout changement nécessaire avec une sauvegarde, une fenêtre de maintenance et le contrôle des services dépendants ; renouveler l’autorité Default explique les conséquences. Mettre à jour ses paramètres avec Save régénère automatiquement l’autorité Default et change l’ancre de confiance. Enregistrer uniquement les modifications approuvées dans la fenêtre de maintenance prévue. Télécharger ensuite l’archive tar.gz avec le bouton de téléchargement et extraire le certificat public Default.pem.

Sur le collecteur, placer Default.pem et ExternalCA.pem dans /etc/syslog-ng/ca.d/, puis ExternalCertificate.pem et ExternalPrivateKey.key dans /etc/syslog-ng/cert.d/. Vérifier d’abord les répertoires et fichiers existants ; ne pas écraser des certificats sans planification. Seuls le service concerné et les administrateurs autorisés doivent pouvoir lire la clé privée.

Exécuter ces commandes sur le collecteur Linux, pas dans SFOS Device Console. La première lit le certificat. La seconde crée un lien symbolique dans le répertoire des autorités et nécessite le droit d’écriture :

cd /etc/syslog-ng/ca.d/
openssl x509 -noout -hash -in Default.pem

Utiliser le hachage réellement renvoyé, pas aveuglément 52412b66. Pour la sortie d’exemple 52412b66, la commande est :

ln -s Default.pem 52412b66.0

Si une entrée .0 existe déjà, vérifier sa cible au lieu de l’écraser. Contrôler à nouveau le hachage et l’association après un changement de certificat.

Cet exemple de syslog-ng.conf présente un écouteur TLS et deux sorties locales. @version: 3.15 est la déclaration de version de l’exemple documenté, pas une recommandation d’installer une version obsolète. Vérifier la syntaxe, les modules et la déclaration avec la version installée avant utilisation. Intégrer cet exemple à la configuration existante sans remplacer ses autres sources et destinations.

@version: 3.15
@include "scl.conf"
source s_src {
    network(ip(0.0.0.0) port(6514)
        transport("tls")
        tls( key-file("/etc/syslog-ng/cert.d/ExternalPrivateKey.key")
             cert-file("/etc/syslog-ng/cert.d/ExternalCertificate.pem")
             ca-dir("/etc/syslog-ng/ca.d")
             peer_verify(required-trusted))
    ); };
destination d_local {
    file("/var/log/messages");
    file("/var/log/messages-kv.log" template("$ISODATE $HOST $(format-welf --scope all-nv-pairs)\n") frac-digits(3));
};
log { source(s_src);
    destination(d_local);
};

0.0.0.0 lie toutes les adresses IPv4 du collecteur. En production, privilégier l’adresse de réception prévue et limiter TCP 6514 aux pare-feu émetteurs via le pare-feu de l’hôte. Le port 6514 doit correspondre à l’entrée SFOS. key-file et cert-file indiquent l’identité du serveur, et ca-dir, les deux certificats d’autorité ; ne pas désactiver peer_verify(required-trusted) pour contourner des erreurs. Les destinations fournissent les logs bruts et une sortie clé-valeur supplémentaire avec une précision à la milliseconde ; adapter chemins, droits, rotation et stockage à l’exploitation.

Avant le démarrage, vérifier la configuration avec la fonction de validation de la version installée. Démarrer le service ou appliquer les changements de façon contrôlée dans une fenêtre approuvée ; en cas de problème, revenir à la configuration sauvegardée. Dans SFOS, configurer ensuite le collecteur, le port 6514 et Secure log transmission sous System services > Log settings > Add, puis cliquer sur Save. Sélectionner les modules nécessaires dans la colonne du serveur. Le succès exige une connexion TLS sans erreur de confiance, un événement de pare-feu volontairement généré dans les fichiers de sortie et des champs correctement analysés dans le SIEM.

Définir les types de logs et leur visibilité

La destination est activée en deux étapes :

La règle ou la fonction concernée doit générer l’événement. Les règles de pare-feu nécessitent Log firewall traffic et les règles d’inspection SSL/TLS Log connections.
Sous System services > Log settings, le type de log correspondant doit être sélectionné dans la colonne du serveur Syslog.

Si l’une des deux étapes manque, le collecteur ne peut pas recevoir l’événement. Un ensemble volontairement limité suffit pour un pilote :

Firewall et Events : événements de règles, activité des administrateurs et des utilisateurs, ainsi que des événements d’authentification, VPN, DHCP et DNS.
IPS, Content filtering, Web server protection et Zero-day protection : décisions de sécurité et de stratégie.
Active threat response : correspondances de MDR, NDR Essentials, Sophos X-Ops et Third-Party Threat Feeds.
System health, Wireless, Heartbeat et SD-WAN : état opérationnel supplémentaire lorsque ces modules sont utilisés.

Les autres modules ne sont ajoutés que s’ils répondent à un besoin de recherche, d’alerte ou d’audit. Pour analyser les événements DoS, il faut également vérifier la configuration contre l’usurpation et les DoS. Les Third-Party Threat Feeds ainsi que NDR et Active Threat Response nécessitent, en plus du transport des logs, des requêtes de recherche et des alertes concrètes.

Périmètre d’ATR : Activer la journalisation des sources distantes uniquement pour les combinaisons de module et de chemin de trafic dont la prise en charge est établie. Le texte ATR de Sophos et sa matrice SVG de trafic se contredisent sur les directions de correspondance de X-Ops ; ce conflit reste non résolu. Les affirmations concernant MDR, NDR ou les feeds tiers ne prouvent pas une prise en charge équivalente par X-Ops. Maintenir des contrôles restrictifs de pare-feu, DNAT/WAF et Device Access indépendants du comportement contesté du feed. Les cas contestés nécessitent une vérification autorisée et contrôlée du module, de la direction de correspondance, des journaux et de l’effet réel, ainsi qu’une clarification fiable ; jusque-là, la protection ne doit pas dépendre de ce comportement. NDR et Active Threat Response explique le contexte sûr.

API XML : distinguer collecteur, sélection des logs et suppression des événements répétés

Toute gestion de Syslog via l’API XML doit traiter séparément ces trois niveaux. Les exemples d’ajout et de mise à jour pour SFOS 22.0 et SFOS 23.0 distinguent :

Paramètres du collecteur : l’adresse de destination, le port, TLS, Facility, le niveau de gravité et le format déterminent le destinataire et la transmission. La création ou la sélection d’un collecteur n’active pas automatiquement tous les logs.
Envoi par groupe et sous-module : dans LogSettings, SendLogs correspond au niveau du groupe ; les sous-modules individuels peuvent remplacer cette sélection. L’exemple avertit expressément de ne pas spécifier SendLogs lorsque tous les sous-modules sont répertoriés. Il ne faut donc pas assimiler ces formes à une activation globale. Pour PolicyRules, le commentaire de l’exemple indique Disable comme valeur par défaut ; cela n’implique pas l’activation automatique de l’envoi de tous les événements de règles. La journalisation dans la règle concernée reste également nécessaire.
Suppression des événements répétés : dans l’exemple, Log_suppress figure séparément de l’envoi. Le regroupement d’événements répétés n’est pas équivalent à la sélection de leur destinataire ou d’un filtre de gravité.

Le tableau des paramètres mentionne deux fois Name et décrit la deuxième ligne comme l’état de suppression des événements répétés ; il indique en outre littéralement uiui comme valeur par défaut. Cela ne constitue pas une base fiable pour définir une valeur par défaut en exploitation ou renommer implicitement le champ. Ne pas en déduire une charge utile complète pour la suppression des événements répétés ; clarifier d’abord les champs API ambigus à l’aide de l’aide du build concerné ou auprès du support Sophos. Avant et après une modification approuvée, générer les mêmes événements représentatifs et comparer les logs bruts sur le collecteur, les champs de l’analyseur dans le SIEM, ainsi que les types de logs attendus et log_occurrence. Une connexion établie ne prouve pas à elle seule que les bons logs sont sélectionnés.

Pièges fréquents concernant la visibilité

Log Suppression : SFOS peut regrouper des événements de pare-feu identiques et consécutifs. Cela affecte Log Viewer, Sophos Fusion et Syslog. Les analyseurs et les détections doivent donc également tenir compte de log_occurrence.
Active Threat Response : Remote Source Match pour le trafic DNAT ou WAF entrant n’est pas activé par défaut. Sans cette sélection, les correspondances de sources concernées manquent pour les modules et chemins de trafic pris en charge. Respecter aussi le périmètre d’ATR ci-dessus lors de l’analyse de types de correspondance manquants ; sélectionner l’option ne prouve pas la prise en charge des directions contestées de X-Ops.
Wireless : les logs des points d’accès et des SSID ne sont pas disponibles dans le Log Viewer local. Ils doivent être envoyés de manière ciblée à Sophos Fusion ou à Syslog et y être contrôlés.
Content filtering et SSL/TLS : le type de log sélectionné ne remplace pas la journalisation dans la règle de pare-feu ou d’inspection correspondante.
Proxy web : pour le trafic web sur les ports 80 ou 443, le log Firewall peut indiquer Allowed alors que Web Filter bloque la même requête. Il faut corréler les événements Firewall et Web Filter pour déterminer la décision de stratégie réellement appliquée.

Vérifier le format et l’analyseur

Un test d’analyseur ne doit pas seulement démontrer qu’un texte quelconque arrive. Les valeurs essentielles doivent pouvoir être recherchées comme des champs distincts. Cet exemple abrégé et anonymisé correspond au Standard syslog protocol pour un événement de règle de pare-feu :

device_name="BRANCH-01" timestamp="2026-08-03T09:15:21+0200" device_model="XGS136" device_serial_id="C00000000000000" log_id="010101600001" log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" log_version=1 severity="Information" fw_rule_id="12" fw_rule_name="LAN_to_WAN_Web" nat_rule_id="4" src_ip="10.10.20.25" dst_ip="203.0.113.10" protocol="TCP" src_port=53144 dst_port=443 con_event="Stop" log_occurrence="1"

Le format legacy utilise en revanche notamment device, date, time, timezone, device_id et priority. Des champs tels que status, user_name, nat_rule_id ou log_occurrence dépendent en outre du type de log et de l’événement. Ils ne doivent pas être considérés comme obligatoires pour chaque événement au format standard. La liste suivante est une liste de contrôle dépendant du cas d’usage, pas un schéma obligatoire universel. Définissez les champs requis séparément pour chaque type de journal activé, à partir de son schéma correspondant à la version et d’un événement réel représentatif. Les champs de règle et de NAT ne s’appliquent qu’aux types d’événements correspondants confirmés ; exploitez les champs de connexion et d’utilisateur ainsi que log_occurrence uniquement lorsqu’ils sont fournis. L’absence de champs non applicables au type d’événement ne doit ni entraîner le rejet d’événements valides ni être considérée comme une erreur du parseur.

Selon le cas d’usage, les champs suivants sont particulièrement importants pour la recette :

Identité : device_name, device_model, device_serial_id
Classification : log_id, log_type, log_component, log_subtype, severity
Stratégie : fw_rule_id, fw_rule_name, nat_rule_id
Connexion : src_ip, dst_ip, ports, protocole et utilisateur
Temps et fréquence : timestamp, fuseau horaire et log_occurrence

log_id contient le type de log, le composant, le sous-type, la gravité et l’ID de message. Les règles de détection sont ainsi plus stables que de simples recherches en texte libre. Les champs fournis par un module particulier doivent néanmoins être vérifiés à l’aide d’un événement réel de ce type de log.

Les douze caractères occupent des positions fixes : les caractères 1 et 2 forment le Log Type ID, 3 et 4 le Component ID, 5 et 6 le Subtype ID, le caractère 7 le Priority ID et les caractères 8 à 12 le Message ID. Ainsi, 010101600001 se lit 01 / 01 / 01 / 6 / 00001. Le parseur doit conserver les zéros initiaux et les largeurs de champ fixes ; pour le contrôle, il faut aussi analyser log_type, log_component, log_subtype et severity.

Le module Syslog Events n’est pas identique à configuration-audit.log. Les valeurs avant/après n’y sont disponibles que pour les objets clés pris en charge, tels que les règles de pare-feu, les interfaces et les hôtes IP, et non pour chaque modification de configuration. La portée et l’analyse sont traitées dans l’article consacré aux logs Audit Trail.

Dans l’exemple documenté 010101600001, le premier 01 signifie Security policy, le deuxième 01, Firewall rule, le troisième 01, Allowed, 6, Information, et 00001, Firewall traffic allowed. Les identifiants à positions fixes et les champs de texte émis ont des rôles différents ; ne pas déduire les champs de texte d’un identifiant numérique sans vérification. Les autres Message IDs nécessitent un catalogue de référence Syslog correspondant à la version SFOS utilisée ; cette décomposition n’explique pas tous les types d’événements.

Plusieurs pare-feu et HA

Dans un environnement comportant plusieurs appliances, chaque événement doit pouvoir être attribué clairement à un pare-feu, un site, un client et un cluster HA. Le nom d’hôte, le numéro de série, le modèle et le champ Facility doivent donc être documentés et filtrables dans le SIEM. Depuis SFOS 22.0, device_name identifie le nom d’hôte du pare-feu qui a produit le log. Après une mise à niveau, il faut vérifier que le parseur ingère ce champ au lieu de continuer à utiliser uniquement device_serial_id ou l’en-tête Syslog comme clé d’asset.

Après un basculement HA, une restauration ou un remplacement matériel, il faut vérifier si les événements restent affectés à l’asset existant ou apparaissent comme un système nouveau ou dupliqué. Il en va de même après une modification du nom d’hôte ou du format Syslog.

Tester l’intégration avec des événements réels

Un état vert du collecteur ne prouve ni que les bons logs sont sélectionnés ni que l’analyseur fonctionne. Pour la recette :

Documenter un pare-feu pilote et l’état initial : nom du serveur, destination, port, TLS, Facility, Severity, Format et tous les types de logs activés dans la colonne de ce serveur.
Envoyer d’abord Firewall et Events vers la destination.
Déclencher une règle de test journalisée avec une source, une destination et un service définis.
Vérifier dans le SIEM l’appareil, l’heure, le type de log, l’action, le Rule ID, la source et la destination.
Générer un blocage défini ainsi qu’une connexion et une déconnexion VPN.
Tester au moins un événement de sécurité provenant de IPS, Content filtering ou Active threat response, à condition que le module soit utilisé en production.
Activer ensuite progressivement d’autres types de logs et observer le volume ainsi que le résultat de l’analyseur.

Pour le test des règles, consulter le guide sur Log Viewer, Policy Test et Packet Capture. Un test négatif est également important : une connexion attendue est volontairement bloquée et doit apparaître comme un blocage avec la bonne règle.

Pour les projets HA ou de migration, la recette doit inclure un test de basculement, de restauration ou de remplacement matériel. Le SOC doit ensuite toujours pouvoir déterminer quel appareil et quel site ont généré l’événement.

Revenir sur une modification sans créer d’interruption des données

Ne pas modifier simultanément le format, la gravité minimale et la sélection des logs. Si l’un des cinq emplacements de serveur est libre, ajouter une seconde destination pour une migration de parseur ou de collecteur et exploiter d’abord les deux en parallèle. On peut ainsi comparer les données brutes, les champs renseignés, les horodatages et le volume sans toucher à la destination qui fonctionne.

Ce n’est qu’après la recette qu’il faut désactiver les types de logs dans la colonne de l’ancienne destination. Conserver son entrée de serveur pendant une période d’observation convenue. Si des événements manquent, si l’analyse échoue ou si le volume est inattendu, y réactiver exactement les types de logs précédemment documentés et annuler la sélection sur la nouvelle destination. Si aucun emplacement n’est libre, consigner les valeurs existantes avant chaque modification individuelle et les restaurer intégralement en cas d’échec ; ne pas supprimer l’entrée ni changer le parseur en même temps.

Une suppression via l’API ne désactive pas la colonne des logs : les tableaux de suppression pour SFOS 22.0 et SFOS 23.0 mentionnent uniquement Name comme non obligatoire, mais le décrivent comme l’état de suppression des événements répétés et ne présentent aucun sélecteur de cible. Ce tableau contradictoire ne démontre ni qu’une cible peut être sélectionnée de manière sûre lorsque le nom est omis, ni que la suppression du collecteur équivaut à la désactivation de ses types de logs. Conserver le collecteur fonctionnel pendant la migration. Avant toute suppression via l’API, l’identité univoque et approuvée de l’entrée à supprimer ainsi que la syntaxe de suppression doivent être clarifiées à partir de l’aide API du build concerné ou auprès du support Sophos ; ne pas deviner de sélecteur.

Exploitation, conservation et pannes

Une intégration Syslog doit avoir un responsable, une durée de conservation définie et une procédure de réaction aux alertes. Il faut également préciser qui évalue les faux positifs et adapte les règles de détection. Les logs du pare-feu peuvent contenir des données personnelles, des adresses internes, des noms d’utilisateur, des URL et des activités VPN. Les droits d’accès, les délais de suppression, la séparation des clients et les coûts du SIEM doivent donc être clarifiés avant un déploiement à grande échelle.

L’exploitation doit détecter non seulement les attaques, mais aussi l’absence de données :

Surveiller un niveau d’activité minimal attendu pour chaque pare-feu.
Contrôler séparément la fraîcheur des types de logs importants comme Firewall, Events, IPS ou Active threat response.
Surveiller les champs centraux de l’analyseur afin de détecter les valeurs vides ou soudainement renommées.
Surveiller par des alertes l’expiration des certificats et l’état du collecteur.
Générer à nouveau des événements de test après les mises à jour du firmware, de l’analyseur et des certificats.

La surveillance elle-même doit également être testée : si les données d’un type de log attendu ou d’un pare-feu sont volontairement interrompues, l’alerte de panne définie doit se déclencher.

Des données brutes sans champs analysés constituent également une panne. Une mise à jour de l’analyseur peut laisser le transport intact alors que les tableaux de bord et les règles de détection ne renvoient plus aucun résultat.

Syslog ne remplace ni les logs de service locaux ni une archive de dépannage pour le support. NetFlow convient aux enregistrements v5 issus de règles de pare-feu journalisées de manière ciblée, tandis que sFlow convient aux échantillons d’interface et aux modèles de trafic. L’état du matériel et des interfaces peut en outre être surveillé avec SNMP.

Isoler les erreurs de manière ciblée

Aucun log n’arrive : vérifier la destination, le port, le transport, le routage et le pare-feu distant. Contrôler ensuite si le type de log souhaité est activé dans la colonne Syslog. Si le collecteur se trouve derrière un VPN ou un réseau de management, tenir également compte de la route, de la stratégie SD-WAN et du Source NAT.

Seuls certains événements manquent : vérifier d’abord la journalisation dans la règle de pare-feu ou d’inspection concernée, puis le type de log sous Log settings. Pour ATR, contrôler également le type de correspondance requis.

Établir d’abord si le module et le chemin de trafic sont pris en charge. Respecter le périmètre d’ATR ci-dessus : l’absence de journaux ne résout pas le conflit X-Ops, et les directions contestées ne justifient pas d’activer simplement d’autres types de correspondance.

Les logs bruts arrivent, mais des champs manquent : comparer le format configuré, la version de l’analyseur et la version du firmware. Les champs standard et legacy ne doivent pas être attendus dans le même profil d’analyseur.

TLS ne se connecte pas : vérifier le port TLS et le service du serveur, puis la chaîne de certificats, le FQDN, le Common Name, le SAN et le mode LINCE. Le collecteur doit en outre approuver l’autorité de certification Sophos Default.pem. Lors des changements de certificats, contrôler les deux magasins de confiance et le processus de renouvellement.

Les horodatages sont incorrects : vérifier NTP sur le pare-feu et le collecteur, le fuseau horaire du SIEM ainsi que la normalisation de l’analyseur. Des heures incorrectes empêchent une corrélation fiable avec les logs des endpoints, des serveurs et des identités.

Trop de logs ou trop de bruit : ne pas tout désactiver sans distinction. Évaluer d’abord les types de logs inutilisés, les règles inutilement bruyantes, les cas d’usage SIEM et log_occurrence, puis réduire la sélection de manière ciblée.