Envoyez Sophos Firewall Syslog en toute sécurité à SIEM

Avec le Syslog, un Sophos Firewall peut envoyer des événements à un serveur de journaux externe, à un SIEM ou à une plateforme de sécurité. Ceci est particulièrement important si les journaux doivent être conservés pendant des périodes plus longues, recherchés de manière centralisée, corrélés avec d’autres systèmes ou utilisés pour des audits et des réponses aux incidents.

Le Log viewer local est idéal pour une analyse rapide directement sur le pare-feu. Central Firewall Reporting est pratique lorsque vous utilisez Sophos Central comme plate-forme de reporting. Syslog, en revanche, est le meilleur choix si vous disposez de votre propre SIEM, d’un SOC, d’un processus de détection géré ou d’une architecture de journaux inter-fabricants.

Quel article de journalisation convient ?

La connexion sur Sophos Firewall comprend plusieurs niveaux. Selon la question, Syslog n’est pas toujours la meilleure façon de commencer :

• Analyser une connexion unique, une décision Rule ID ou web/IPS en direct: Test de règles Sophos Firewall avec Log Viewer, testeur de stratégie et Packet Capture
• Attribuer des fichiers journaux et des services locaux: Dépannage Sophos Firewall : Services et journaux
• Sauvegarder les journaux pour assistance ou analyse externe: Sophos Firewall Sauvegarder les journaux à des fins d’assistance et d’analyse
• Suivre les modifications de configuration et les actions d’administration: Sophos Firewall Vérifier les journaux de piste d’audit
• Utiliser les rapports basés sur Sophos Central sur plusieurs pare-feu: Sophos Firewall Activer et exploiter le reporting central
• Envoyer des journaux à long terme vers SIEM, SOC ou serveur de journaux: Cet article
• Analysez les flux de trafic plutôt que les événements de pare-feu individuels: Configurer la surveillance sFlow sur Sophos Firewall
• Vérifier l’état du matériel et de l’interface via la surveillance: Sophos Firewall Configuration de la surveillance du matériel SNMP

Cela permet de maintenir l’évaluation propre : le Log Viewer répond au package ou au cas de politique actuel, les journaux locaux facilitent les diagnostics de module plus approfondis, les rapports centraux sont pratiques pour les évaluations Sophos et le Syslog fournit la couche externe à long terme et SIEM.

Quand Syslog a du sens

Le Syslog n’est pas seulement intéressant pour les grands environnements. Même avec quelques pare-feu, un serveur de journaux central peut aider à conserver les événements plus longtemps et indépendamment de l’appliance.

Cas d’utilisation typiques :

• Stockage central des journaux pendant des semaines, des mois ou des années
• Corrélation avec les journaux de point final, de serveur, d’identité, de proxy, de cloud ou de commutateur
• Cas d’utilisation du SIEM pour les attaques, les analyses de ports, les connexions VPN, les événements WAF ou les accès au flux de menaces
• évaluation externe par SOC, MDR ou équipes de sécurité internes
• Traçabilité après mise à jour du firmware, basculement, restauration ou remplacement de matériel
• Forensics lorsque les journaux du pare-feu local ne suffisent plus

Les journaux locaux restent importants pour les cas de dépannage aigus. Quel fichier journal local appartient à quel module de pare-feu peut être trouvé dans Dépannage Sophos Firewall : Services et journaux. Si vous souhaitez sauvegarder les journaux pour l’assistance ou l’analyse externe, Sophos Firewall Sauvegarder les journaux pour l’assistance et l’analyse convient.

Syslog, Central Reporting ou journaux locaux ?

Les trois approches répondent à des questions différentes. En pratique, plusieurs d’entre elles sont souvent utilisées en parallèle.

• Log viewer : analyse rapide en direct sur le pare-feu, mais pas d’architecture centrale à long terme.
• Fichiers journaux locaux : analyse détaillée via Advanced Shell ou dossier de support, mais dépendante de l’état et du stockage du pare-feu.
• Central Firewall Reporting : rapports Sophos Central et vue simple sur plusieurs pare-feu, mais liés à Sophos Central, à la licence et au cadre de stockage.
• Syslog / SIEM : conservation propre, corrélation, détection et audit. Cela nécessite des parsers, une exploitation, une supervision et des cas d’utilisation clairs.

Syslog ne remplace donc pas le Log Viewer. Il le complète. Le Log Viewer montre rapidement quelle règle ou quel module a pris la décision. Syslog garantit que ces informations restent disponibles plus tard à l’extérieur.

Exigences

Avant la configuration, ces points doivent être clarifiés :

• Le serveur Syslog ou SIEM est accessible.
• L’adresse IP ou FQDN cible est stable et documentée.
• Le port et le transport sont fixes, souvent UDP 514 ou TLS sur son propre port.
• Le pare-feu peut acheminer et atteindre le serveur Syslog.
• Il existe un analyseur approprié ou au moins un stockage de données brutes dans le système cible.
• NTP fonctionne sur le pare-feu et la plateforme cible.
• La durée de conservation et les exigences en matière de protection des données sont définies.
• Il est clair quels types de journaux sont réellement nécessaires.

Pour les destinations SIEM externes ou basées sur le cloud, une attention particulière doit être accordée au cryptage du transport, à l’adresse IP source, au routage, au DNS et à la vérification des certificats. Certains fournisseurs de SIEM ou MDR s’attendent délibérément à ce que le Syslog non chiffré soit envoyé à un collecteur ou à un capteur local qui transmet ensuite les données. Ensuite, l’itinéraire non chiffré doit être court, segmenté en interne et documenté.

Clarifier la protection, le stockage et la responsabilité des données

Syslog n’est pas seulement une redirection technique. Les journaux de pare-feu peuvent contenir des adresses IP internes, des noms d’utilisateur, des systèmes cibles, des URL, des catégories, des connexions VPN, des événements d’administration et des accès de sécurité. Par conséquent, avant la connexion productive, il convient de préciser qui est autorisé à consulter ces données et combien de temps elles seront stockées.

Clarifier avant le déploiement :

• Stockage: Combien de temps les journaux opérationnels, d’audit ou de réponse aux incidents doivent-ils rester disponibles ?
• Accès: Quelles personnes ou équipes peuvent consulter les journaux bruts, les requêtes de recherche et les tableaux de bord ?
• Protection des données: Les journaux contiennent-ils des informations personnelles, des identifiants utilisateur, des adresses IP sources ou des URL ?
• Capacité multi-clients: Les emplacements, les clients, les locataires ou les clusters HA sont-ils clairement séparés dans le SIEM ?
• Coût: Les volumes de logs, EPS, stockage ou requêtes de recherche sont-ils facturés par le fournisseur SIEM ?
• Alerte: Qui répond aux alarmes et dans quels délais ?
• Suppression: Comment les anciens journaux sont-ils supprimés une fois la période de conservation expirée ?

Cette responsabilité ne doit pas être laissée ouverte, notamment avec les modèles MSP, SOC ou MDR. Un SIEM sans propriétaire clair produit des données, mais aucune réponse fiable.

Déploiement du plan par phases

Pour les pare-feu productifs, un petit pilote est préférable à l’envoi immédiat de tous les types de journaux à toutes les destinations. Cela permet de contrôler les analyseurs, les noms de champs, le bruit et les coûts avant que le SIEM ne soit considéré comme une source fiable.

Un processus judicieux :1. Tout d’abord, un pare-feu pilote est sélectionné. 2. Le nom d’hôte, la source de temps, la version du micrologiciel et le format du journal sont documentés. 3. La destination Syslog est configurée avec un transport sécurisé. 4. Cela commence par quelques types de journaux, par exemple le pare-feu, les événements et VPN. 5. Les événements de test définis sont générés et vérifiés dans le système cible. 6. L’analyseur, les champs, l’horodatage, le fuseau horaire et device_name sont validés. 7. Le volume des journaux et le bruit sont observés sur quelques jours. 8. Des types de journaux supplémentaires tels que IPS, Web, WAF, réponse active aux menaces ou santé du système sont ensuite ajoutés. 9. Ce n’est qu’après un projet pilote réussi qu’il sera déployé sur d’autres pare-feu.

Si vous disposez de plusieurs pare-feu, vous ne devez pas simplement vérifier si les données arrivent. Ce qui est important est de savoir si chaque événement est attribué au bon emplacement, appareil, nœud HA, client ou locataire.

Le pilote doit contenir au moins un événement opérationnel normal, un événement de sécurité et un événement d’erreur. Sinon, le transport semble sain, mais les champs importants ultérieurs ne manquent qu’en cas d’urgence.

Ajouter le serveur Syslog

La configuration s’effectue dans l’interface Web Sophos Firewall.

1. Ouvrez System services > Log settings.
2. Sélectionnez Ajouter.
3. Attribuez un nom unique, par exemple siem-primary ou syslog-soc.
4. Saisissez l’adresse IP/domaine du serveur Syslog.
5. Définissez Port pour qu’il corresponde au système cible.
6. Choisissez Installation consciemment.
7. Définissez le Niveau de gravité.
8. Sélectionnez Formater.
9. Activez éventuellement Secure log transmission si la destination prend en charge TLS.
10. Enregistrez.

Sophos Firewall peut configurer plusieurs serveurs Syslog externes. La documentation actuelle prévoit jusqu’à cinq serveurs Syslog. Néanmoins, vous ne devez pas relier chaque objectif au hasard, mais plutôt déterminer le but derrière chaque objectif.

Si vous avez plusieurs cibles, vous devez consciemment séparer la sélection des journaux pour chaque cible. Un serveur de journaux local peut avoir besoin de tous les journaux de pare-feu et VPN, tandis qu’un collecteur MDR n’attend que les types de journaux liés à la sécurité. Si toutes les cibles reçoivent aveuglément les mêmes données, les coûts, les risques liés à la vie privée et le bruit de l’analyseur augmentent.

Paramètres importants

Installation

Cette fonction aide le serveur Syslog à distinguer les sources ou catégories de journaux. Dans des environnements simples, une valeur par défaut est souvent suffisante. Dans des environnements plus grands, il peut être judicieux de séparer les pare-feu ou les groupes d’emplacements en utilisant des valeurs LOCAL0 à LOCAL7 différentes.

Il est important de noter que les règles, les analyseurs et la documentation SIEM utilisent la même logique. Si chaque pare-feu utilise une fonctionnalité différente, l’évaluation devient inutilement difficile.

Niveau de gravité

La gravité détermine la gravité à laquelle les journaux sont envoyés. Pour des raisons de sécurité et de dépannage, un seuil trop élevé est dangereux car des informations importantes ou des événements de notification peuvent passer inaperçus. Cependant, dans les environnements très bruyants, un seuil trop bas peut générer une quantité de bruit inutile.

Il est généralement logique d’avoir un pilote avec une sélection plus large de journaux, puis une réduction consciente basée sur des hits réels et des cas d’utilisation du SIEM.

Le seuil est une gravité minimale. Par exemple, si Error est sélectionné, le pare-feu envoie aussi des messages plus critiques comme Critical, Alert et Emergency, mais pas les événements d’information normaux. Pour de nombreux cas d’usage SIEM, les événements Information et Notice sont justement importants, sinon des connexions VPN, des événements de règle ou des états système peuvent manquer.

Format

Selon la documentation actuelle, Sophos Firewall propose deux formats :

• Protocole Syslog standard
• Format standard de l’appareil (ancien)

Pour les nouvelles intégrations, vous devez d’abord vérifier le format attendu par le système cible ou l’analyseur existant. Si un SIEM dispose déjà d’un analyseur de pare-feu Sophos, ses attentes sont prioritaires. Un changement de format après la mise en ligne peut perturber les tableaux de bord, les requêtes de recherche et les règles de détection.

Secure log transmission

Lorsque Secure log transmission est actif, les journaux sont envoyés cryptés au serveur Syslog. Pour ce faire, le système cible doit accepter TLS sur le port configuré, fournir un certificat de serveur approprié et utiliser une chaîne de certificats à laquelle le pare-feu fait confiance. Avant la mise en ligne, vous devez non seulement vérifier le pare-feu, mais également vérifier le nom du certificat, la chaîne de confiance, le port, l’analyseur et le processus de renouvellement de la cible Syslog.

L’UDP peut techniquement suffire aux laboratoires internes. Cependant, un Syslog non chiffré sur des réseaux non sécurisés ne constitue pas une bonne base pour des connexions SIEM ou SOC productives, car les données de journal peuvent contenir des adresses IP internes, des utilisateurs, des destinations, des URL ou des événements de sécurité.

Avec TLS, le nom de la destination Syslog est important. Sans mode de conformité LINCE activé, Sophos Firewall vérifie le Common Name du certificat par rapport au domaine du serveur Syslog ; dans ce cas standard, le Subject Alternative Name ne sert pas de remplacement. Avec LINCE activé, le Common Name ou le Subject Alternative Name peut correspondre. Si une adresse IP est saisie dans le pare-feu alors que le certificat ne contient qu’un nom DNS, ou si un certificat ne correspond que via SAN, la connexion peut échouer selon le mode. Pour les cibles TLS Syslog productives, il faut prévoir un FQDN stable, un certificat serveur adapté et un processus de renouvellement documenté.

Dans le même temps, le système cible doit réellement comprendre la procédure choisie. Certaines intégrations SIEM nécessitent un collecteur local et ne prennent pas directement en charge le pare-feu Secure log transmission. Dans ce cas, la meilleure solution est souvent la suivante : le pare-feu envoie en interne au collecteur, qui chiffre ensuite vers le cloud ou la plateforme SOC. Cette architecture doit être incluse dans le document d’exploitation, sinon on supposera ultérieurement à tort que tous les tronçons de l’itinéraire sont cryptés.

Sélectionnez les types de journaux

Après l’ajout du serveur Syslog, le travail n’est pas terminé. Vous devez spécifier sous System services > Log settings quels types de journaux sont envoyés à cette destination.

Important : Une règle de pare-feu ne crée des journaux de trafic significatifs que si Log firewall traffic est activé dans la règle. Pour SSL/TLS Inspection, Log connections doit également être actif dans la règle d’inspection correspondante. La sélection de journaux sous Log settings détermine ensuite si ces logs sont envoyés localement, vers Sophos Central ou vers des serveurs Syslog.

Types de journaux typiques pour un SIEM :

• Pare-feu: connexions autorisées et rejetées, correspondance de règles, événements DoS
• IPS: Attaques détectées ou bloquées
• Filtrage Web/Contenu: Trafic Web, catégories, événements liés à la politique Web
• Inspection SSL/TLS: Décisions et erreurs d’inspection TLS
• Protection du serveur Web: Événements WAF pour les services publiés
• Authentification / Événements: Événements administrateur, utilisateur et système
• VPN: Accès à distance et site à site Événements VPN
• Réponse active aux menaces: Accès aux flux de menaces MDR, NDR Essentials, Sophos X-Ops et flux de menaces tiers
• Santé du système: CPU, mémoire, utilisateurs, interfaces et partitions

Si DoS ou des événements d’usurpation d’identité doivent être évalués, le durcissement technique lui-même doit également être testé. Le processus se trouve dans Sophos Firewall Vérifier les paramètres Spoof Protection et DoS.

Si des Flux de menaces tiers, NDR et Active Threat Response ou WAF sont utilisés, le SIEM doit évaluer spécifiquement ces événements. Il ne suffit pas d’envoyer des journaux. Cela nécessite des requêtes de recherche, des alarmes, des responsabilités claires et une protection contre les fausses alarmes.

Vérifier volontairement les champs du parser

Les événements Syslog Sophos contiennent des champs différents selon le type de log. Pour les parsers et les tableaux de bord, log_id, log_type, log_component, log_subtype, severity, status, device_name, device_model, device_serial_id, fw_rule_id, fw_rule_name, nat_rule_id, src_ip, dst_ip, user_name et les horodatages sont particulièrement importants.

log_id n’est pas un simple nombre aléatoire. L’ID se compose du type de log, du composant, du sous-type, de la gravité et de la Message ID. C’est utile lorsqu’un SIEM doit construire des règles de détection, des tableaux de bord ou des normalisations stables au lieu de seulement rechercher du texte libre.

Pour la réception, il ne suffit donc pas de vérifier que des données brutes arrivent. Le point décisif est de savoir si les champs arrivent vraiment comme champs séparés dans le SIEM. Si fw_rule_id ou nat_rule_id restent seulement dans le texte brut, les recherches et alertes ultérieures fonctionnent souvent moins bien que prévu.

Un événement firewall anonymisé peut par exemple ressembler à ceci au format brut :

date=2026-07-01 time=14:23:11 log_type="Firewall" log_component="Firewall Rule" log_subtype="Allowed" status="Allow" device_name="SFOS-XGS" device_serial_id="C00000000000000" 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" dst_port="443" user_name="AVANET\\test.user"

Cet exemple ne remplace pas la référence officielle des champs. Il montre quelles informations doivent être visibles comme champs séparés lors du test du parser.

Kit de démarrage typique pour le pilote SIEM

Pour un pilote, un petit set de départ délibéré vaut mieux qu’une activation complète sans évaluation.

• Démarrer: Pare-feu, événements, VPN. Vérifiez le bruit de fond, les événements de règles, l’administrateur et la visibilité VPN
• Sécurité: IPS, Web, protection des serveurs Web, réponse active aux menaces. Valider les cas d’utilisation de la sécurité et les champs de l’analyseur
• Opération: Santé du système, DHCP, DNS, authentification. Ajouter un contexte opérationnel et identitaire
• Mise au point: modules supplémentaires selon les besoins. activer uniquement s’il y a un objectif de recherche, d’alarme ou d’audit

Après chaque phase, il convient de vérifier si le SIEM reconnaît correctement les champs et si quelqu’un utilise réellement les nouveaux événements. Les types de journaux non cochés ne constituent pas une valeur ajoutée, mais simplement un volume supplémentaire.

Pièges de visibilité importants

Dans les projets Syslog, de nombreuses lacunes ne surviennent pas dans le transport, mais au préalable : le pare-feu ne génère pas du tout l’événement attendu, le type de journal n’est pas envoyé au serveur Syslog ou le SIEM interprète mal les champs.

Journalisation des règles et des modules

Les règles de pare-feu et les règles d’inspection SSL/TLS doivent générer elles-mêmes la journalisation. Sous System services > Log settings, vous pouvez choisir si ces journaux sont envoyés localement, dans Sophos Central ou vers le serveur Syslog. Si une règle de pare-feu n’a pas Enregistrer le trafic du pare-feu, le serveur Syslog ne peut pas afficher un historique complet du trafic du pare-feu.

Pour les événements de politique Web, il est également pertinent de savoir si la règle de pare-feu associée génère une journalisation du trafic. Sinon, vous risquez de voir moins d’événements de filtrage Web ou de contenu dans le SIEM que prévu.

Suppression des journaux

Sophos Firewall peut supprimer plusieurs entrées de journal consécutives identiques. Cela permet d’économiser de la mémoire et du traitement, mais peut prêter à confusion dans les cas d’utilisation du SIEM lorsque les valeurs de comptage, la fréquence ou le comportement en rafale doivent être évalués. La fonction fonctionne sur les serveurs Log Viewer, Sophos Central et externes Syslog.

Avant un déploiement productif du SIEM, vous devez donc déterminer :

• Quels événements de pare-feu peuvent être supprimés ?
• De quelles règles de détection chaque connexion individuelle a-t-elle besoin ?
• Le SIEM fonctionne-t-il avec des valeurs comptées ou uniquement avec des événements individuels ?
• Comment est-il documenté que la suppression des journaux est active ?

Active Threat Response

Les journaux Active Threat Response sont particulièrement utiles lors de l’utilisation de flux de menaces, de NDR Essentials ou de flux externes. Sophos différencie les différents types de correspondance, par exemple les hits cibles pour le trafic sortant et les hits sources pour le trafic entrant.

Important : La correspondance de source distante pour le trafic entrant n’est pas automatiquement activée. Si le trafic WAF ou DNAT doit être surveillé par rapport aux flux de menaces, cette visibilité doit être consciemment vérifiée. Dans le cas contraire, les hits entrants auxquels un SOC s’attend souvent manqueront.

Journaux sans fil

Les journaux sans fil ne sont pas automatiquement visibles dans le Log Viewer local. Les journaux du point d’accès et du SSID doivent être envoyés spécifiquement au Sophos Central ou au Syslog et examinés séparément dans le système cible si les événements sans fil sont pertinents pour les opérations, le support ou la conformité.

Environnements multi-pare-feu

Dans les environnements dotés de plusieurs pare-feu, chaque événement doit être attribué de manière unique à une appliance. Le nom d’hôte, le numéro de série, le modèle et d’autres champs sont pertinents pour cela. Selon le type de journal, des champs tels que device_name, device_model et device_serial_id peuvent apparaître dans les événements Syslog. Le SIEM doit non seulement stocker ces champs, mais également les rendre utilisables pour les filtres, les tableaux de bord et les alarmes.

Recommandations pratiques :

• Définissez proprement le nom d’hôte du pare-feu.
• Tenez compte de l’emplacement ou du rôle dans le nom d’hôte.
• Définir une installation ou une stratégie de marquage uniforme.
• Dans le SIEM, vérifiez si les événements peuvent être filtrés par pare-feu, emplacement et cluster.
• Distinguez clairement les clusters HA des pare-feu autonomes.

Cette affectation est particulièrement importante après un remplacement ou une restauration matérielle. Sinon, les événements du SIEM ressemblent à des systèmes nouveaux ou en double.

Pour les clusters HA, il convient également de tester la façon dont les événements apparaissent après un basculement. Ce qui compte est de savoir si les opérations et le SOC continuent de reconnaître le même emplacement ou si un nom d’hôte, un numéro de série ou un nouvel actif différent apparaît soudainement dans le SIEM.

Tester la configuration

Après la sauvegarde, la connexion doit être délibérément testée. Un système cible vert ne prouve pas à lui seul que les bons journaux avec les bons champs arrivent.

Points de test :

1. Ouvrez System services > Log settings sur le pare-feu.
2. Assurez-vous que le serveur Syslog est visible.
3. Pour un type de journal sécurisé, activez Syslog à titre de test.
4. Déclenchez une action définie, par exemple une règle de pare-feu enregistrée ou un test d’accès.
5. Vérifiez dans le système cible si l’événement arrive.
6. Vérifiez les champs tels que l’heure, le nom d’hôte, device_name, la source, la destination, Rule ID, l’action et le type de journal.
7. Vérifiez l’horodatage et le fuseau horaire dans le SIEM.
8. Pour les événements firewall, vérifiez si fw_rule_id, fw_rule_name, nat_rule_id, src_ip, dst_ip, status et log_occurrence sont recherchables séparément.

Pour tester les règles, Tester la règle de pare-feu avec Log Viewer, Policy Test et Packet Capture est utile. Si aucun événement ne se produit, la cause n’est souvent pas le transport Syslog, mais plutôt une journalisation désactivée en règle générale ou un type de journal incorrect.

Événements de test significatifs

Un bon test d’acceptation ne crée pas n’importe quel journal, mais exactement les événements qui seront recherchés ultérieurement.

• La règle de test enregistrée autorise une connexion: Source, Destination, Service, Action, Rule ID et Pare-feu clairement visibles
• Hits de règle de suppression définis: L’événement Drop apparaît avec la direction et l’heure correctes
• L’utilisateur VPN se connecte et se déconnecte: L’utilisateur, le type de tunnel, l’heure et le pare-feu sont détectés
• Politique Web ou événement de test IPS: Le type, la catégorie ou la signature du journal est correctement résolu par l’analyseur
• Test ATR ou flux de menace si disponible: Le hit apparaît dans le cas d’utilisation attendu et ne génère pas de fausse alarme
• Test de basculement ou de restauration HA si prévu: Les événements restent attribués de manière traçable à l’emplacement, au cluster et à l’appliance. Pour des règles SIEM productives, vous devez également documenter un résultat de test négatif : que se passe-t-il si un événement attendu ne se produit pas ? Ce n’est qu’alors qu’il sera évident plus tard si un analyseur, un collecteur ou un type de journal a échoué silencieusement.

Opérations et suivi

Une connexion Syslog n’est pas une capture ponctuelle. Le fonctionnement doit être surveillé et vérifié régulièrement.

Au moins ces points doivent être documentés :

• Qui est le propriétaire de la plateforme de journalisation ?
• Quels pare-feu envoient des logs ?
• Quels types de journaux sont envoyés ?
• Quelle durée de conservation s’applique ?
• Quels analyseurs, tableaux de bord et alarmes y sont attachés ?
• Comment reconnaître que les logs n’arrivent plus ?
• Comment les changements de format sont-ils vérifiés après les mises à jour du firmware ?
• Comment les expirations de certificats, les mises à jour des collecteurs et les modifications de l’analyseur sont-elles surveillées ?
• Qui évalue les faux positifs et ajuste les règles SIEM ?

Après les mises à jour du micrologiciel, des contrôles aléatoires doivent être effectués pour voir si les événements importants sont toujours analysés correctement. Cela est particulièrement vrai pour les règles productives SIEM qui reposent sur des noms de champs, des types ou des formats de journaux spécifiques.

Détecter une panne silencieuse des logs

Pour l’exploitation, il faut disposer d’un indicateur simple de panne :

• Par firewall : définir un nombre minimal attendu d’événements par période, par exemple des événements Firewall ou System.
• Par type de log important : vérifier si Firewall, VPN, Web, IPS ou Active threat response fournissent encore régulièrement des événements.
• Par parser : surveiller si les champs centraux comme device_name, Source, Destination, Action et Rule ID restent renseignés.
• Par collector : détecter si un collector local n’accepte plus de données ou ne les transmet plus.
• Après des changements : utiliser mise à jour firmware, mise à jour parser, changement de certificat, restore firewall et failover HA comme occasion de refaire un test d’acceptation.

Une bonne exploitation SIEM n’alerte donc pas seulement sur des événements suspects, mais aussi sur des événements manquants. Si un firewall de production cesse soudainement d’envoyer des logs, c’est aussi un événement opérationnel.

Dépannage

Aucun journal n’arrive dans le SIEM

Vérifiez d’abord l’adresse IP, le port, le routage et les règles de pare-feu entre le serveur Sophos Firewall et Syslog. Vérifiez ensuite si le type de journal correct est activé pour le serveur Syslog sous System services > Log settings.

Si le serveur Syslog est accessible via un tunnel VPN ou un réseau de gestion distinct, vérifiez également la route, la politique SD-WAN, le NAT source et le pare-feu du compteur. Du point de vue de Sophos Firewall, Syslog correspond au trafic sortant normal ; il doit effectivement parvenir au collectionneur.

Seuls certains événements manquent

Ensuite, le module ou la journalisation des règles n’est souvent pas actif. Pour les règles de pare-feu, Enregistrer le trafic du pare-feu doit être défini. Pour les événements Web ou SSL/TLS, la journalisation de la politique ou des règles d’inspection appropriée doit également être générée.

Les journaux arrivent mais ne sont pas analysés correctement

Vérifiez le format, la version de l’analyseur et la version du micrologiciel. Si vous basculez entre le Protocole Syslog standard et le Format standard de l’appareil (ancien), l’analyseur SIEM doit y correspondre.

TLS-Syslog ne se connecte pas

Vérifiez le FQDN, le certificat, le Common Name, le Subject Alternative Name, le mode LINCE, la chaîne de certificat et le port. Dans la plupart des environnements sans LINCE, le Common Name doit correspondre au domaine configuré ; un nom qui ne correspond que dans le SAN ne suffit pas. Si le pare-feu attend un nom DNS, mais que le serveur Syslog n’a été saisi que via l’adresse IP, la vérification du certificat peut également échouer. Vérifiez aussi si le système cible accepte réellement TLS sur le port configuré.

Si un fournisseur SIEM ne prend pas directement en charge Secure log transmission, il ne faut pas essayer de sauver l’analyseur avec des formats aléatoires. Il est préférable d’avoir un collecteur local pris en charge, une conception de transport différente ou une décision claire quant à l’itinéraire interne qui reste non crypté.

Les horodatages sont incorrects

Vérifiez NTP sur le pare-feu, le fuseau horaire dans SIEM et la logique de l’analyseur. Des heures incorrectes rendent la corrélation avec les journaux de point final, de serveur ou d’identité peu fiable.

Trop de journaux ou trop de bruit

Ne désactivez pas tout immédiatement. Vérifiez d’abord quels types de journaux sont réellement nécessaires, quelles règles sont consignées inutilement et si la suppression des journaux est logique. Réduisez ensuite spécifiquement.

Liste de contrôle

• Le serveur Syslog ou SIEM est accessible.

• Le transport, le port et le cryptage sont corrigés.

• Pour TLS : FQDN, certificat, chaîne de confiance et renouvellement sont vérifiés.

• Le format correspond à l’analyseur SIEM.

• La stratégie de l’établissement est documentée.

• Les types de journaux pertinents sont activés sous System services > Log settings. - Les règles de pare-feu importantes ont Enregistrer le trafic du pare-feu actif.

• Les règles d’inspection SSL/TLS génèrent leurs propres journaux si nécessaire.

• La suppression des journaux est consciemment évaluée et documentée.

• Les types de correspondance de réponse active aux menaces correspondent aux cas d’utilisation du SIEM.

• La protection des données, l’accès et la durée de conservation ont été clarifiés.

• Le pare-feu pilote, les événements de test et l’analyseur SIEM ont été validés.

• Les événements de test arrivent dans le système cible.

• Les champs tels que Nom d’hôte, device_name, Source, Destination, Action et Rule ID sont reconnus correctement.

• Les champs importants du parser comme log_id, log_type, log_component, fw_rule_id, nat_rule_id, src_ip, dst_ip, user_name, severity et status sont recherchables séparément.

• HA, un scénario de restauration ou de remplacement de matériel est inclus dans le modèle de mappage SIEM si nécessaire.

• L’horodatage et le fuseau horaire sont corrects.

• La surveillance détecte quand plus aucun journal n’arrive.

• La fonction de l’analyseur est vérifiée après les mises à jour du firmware.

• La supervision détecte les défaillances silencieuses de types de logs importants ou de champs de parser.

FAQ