Utiliser correctement le Sophos Firewall Health Check

Le Sophos Firewall Health Check est un examen intégré de la configuration du pare-feu. Il indique dans le Control Center si les paramètres importants respectent les recommandations de sécurité et les meilleures pratiques. C’est particulièrement utile pour les administrateurs car cela rend visibles les configurations risquées avant qu’elles ne deviennent un problème de sécurité ou d’exploitation.

Pour le contexte global de hardening, consulter le hub Sophos Firewall Hardening : bonnes pratiques pour une configuration sécurisée.

Le Health Check a été introduit avec Sophos Firewall v22. La fonction évalue les configurations par rapport à des meilleures pratiques et des standards tels que les benchmarks CIS. Avec SFOS 22.0 MR1, le contexte CIS sous-jacent a également été mis à jour.

Guide vidéo

Comment utiliser ce guide

Le Health Check fournit une liste, mais pas une décision. Ce guide ajoute donc une évaluation Avanet à chaque point :

• Priorité élevée : le constat concerne une protection ou une fonction opérationnelle fondamentale. L’écart doit être corrigé rapidement ou très bien justifié.
• Selon le contexte : la recommandation est utile, mais ne convient pas de la même manière à chaque règle, flux ou architecture.
• Couvert autrement : l’objectif de sécurité est déjà satisfait par un contrôle équivalent d’un autre fournisseur ou un autre processus d’exploitation. Un override documenté peut alors être approprié.
• Optionnel : le constat évalue surtout une fonction de conformité ou un service Sophos supplémentaire. Un statut rouge ne signifie pas automatiquement que le firewall est mal sécurisé.

Cette classification ne remplace pas l’analyse de risque. Elle évite qu’une faible sévérité Sophos minimise l’importance d’un backup ou qu’une sévérité élevée sur une intégration optionnelle devienne trop vite un projet d’achat.

À quoi sert le Health Check

Le Health Check n’est pas un statut système classique ni un capteur matériel. Il ne vérifie pas si une alimentation est défectueuse ou si un SSD est sur le point de tomber en panne. Pour cela, d’autres vérifications opérationnelles conviennent, par exemple vérifier l’état de santé du SSD ou la surveillance HA et matérielle.

Le Health Check répond plutôt à ces questions :

• Les accès administratifs sont-ils trop ouverts ?
• MFA est-il activé pour les connexions critiques ?
• Les règles de pare-feu sont-elles trop ouvertes ?
• Les sauvegardes, correctifs, journalisation ou fonctions Central sont-ils bien préparés ?
• La configuration s’écarte-t-elle des standards de sécurité recommandés ?
• Y a-t-il des constats à clarifier avant un audit ou une mise en production ?

C’est donc un bon outil pour le renforcement, la révision et le contrôle des changements. Cependant, il ne remplace pas une architecture propre, une documentation des règles et une évaluation manuelle.

⚠️ Un Health Check vert ne signifie pas automatiquement que le pare-feu est bien planifié en termes de sécurité. Il montre si certains paramètres vérifiables sont corrects. La conception du réseau, la logique métier, les exceptions, les groupes d’utilisateurs et les processus opérationnels doivent toujours être évalués professionnellement.

Bien évaluer le score et le statut

Le Health Check est utile, mais ce n’est pas un audit de sécurité indépendant du fournisseur. En plus des fondamentaux, il vérifie l’utilisation de fonctions Sophos supplémentaires comme Sophos Central, DNS Protection, NDR Essentials, MDR threat feeds ou Synchronized Security. Du point de vue d’Avanet, cette sélection comporte une part claire de cross-selling : un constat non conforme peut simplement indiquer qu’un service Sophos n’est pas utilisé alors que l’objectif de sécurité est déjà couvert par Microsoft Defender, un autre EDR/NDR, un SIEM ou un service de sécurité DNS.

La recommandation n’est pas forcément mauvaise. Mais Noncompliant peut décrire deux situations très différentes : une vraie faille, comme WebAdmin exposé à Internet sans MFA, ou la décision de ne pas utiliser un service Sophos optionnel. Le score ne doit donc jamais devenir une fin en soi.

Recommandation Avanet : examiner chaque constat, mais ne pas tous les appliquer sans discernement. Un point rouge concernant WebAdmin, MFA, une authentification non chiffrée, les sauvegardes ou des règles ouvertes mérite une forte attention. Un point rouge concernant un service Sophos non licencié relève d’abord d’une décision d’architecture et de produit, et non d’une faille de sécurité automatiquement démontrée. L’objectif de sécurité, les alternatives existantes et le processus d’exploitation déterminent s’il faut activer, couvrir autrement ou appliquer un override justifié.

Il ne faut donc pas activer chaque recommandation uniquement pour que l’affichage devienne vert. Un exemple est le Login disclaimer : dans les environnements d’audit ou de conformité, un avis de connexion peut être requis. Dans de nombreux environnements opérationnels normaux, il génère surtout un clic supplémentaire à chaque connexion et n’apporte pratiquement aucun gain de sécurité technique. Si cela ne fait qu’augmenter le score du Health Check, la valeur ajoutée est limitée.

Pour DNS Protection, MDR threat feeds, NDR Essentials, Sophos X-Ops, Synchronized Application Control et Sophos Central Reporting, quatre questions s’imposent : quel risque concret est réduit ? Une protection équivalente existe-t-elle déjà ? Quelle licence et quel transfert de données sont nécessaires ? Qui traite les alertes, exceptions et faux positifs ? Sans bonne réponse, un override documenté est souvent plus honnête qu’une fonction inutilisée activée uniquement pour améliorer le score.

Il ne faut pas confondre NDR Essentials et MDR. NDR Essentials analyse certains flux du pare-feu et produit des détections. Sophos MDR signifie Managed Detection and Response et constitue un service payant supplémentaire avec des analystes et des processus d’incident. Les MDR threat feeds ne sont pertinents que si ce service est réellement licencié et intégré à l’exploitation. Un constat NDR ne signifie donc pas automatiquement qu’il faut acheter MDR.

Comme règle générale :

• Accès de gestion exposés à Internet, MFA, hotfixes automatiques, sauvegardes, règles de mot de passe et IPS sont généralement de véritables bases de sécurité ou d’exploitation. Ces points doivent être pris très au sérieux.
• Journalisation, reporting, notifications et NTP sont importants pour l’exploitation et la traçabilité. La voie concrète dépend du modèle opérationnel.
• DNS Protection, NDR, MDR threat feeds, X-Ops, Sophos Central et Synchronized Security sont des solutions possibles, pas des obligations générales. Une alternative efficace compte davantage que le logo Sophos sur la protection.
• Login disclaimer est généralement plutôt une fonction de conformité ou d’information qu’une mesure de protection technique. Il ne faut l’activer que s’il est réellement requis ou souhaité.

Décision rapide : que faut-il réellement mettre en oeuvre ?

Lors de la première ouverture du Health Check, les constats peuvent être répartis en quatre groupes de travail :

• À vérifier immédiatement et généralement à corriger : 8, 9, 11, 13 à 20, 22, 25, 28 et 31. Cela couvre les hotfixes, la protection des connexions, les mots de passe administrateur, MFA, l’authentification chiffrée, SSH, l’exposition WAN, les mises à jour de patterns, IPS, les règles trop larges et l’heure correcte.
• Très importants malgré une gravité Sophos Low ou Medium : 16 et 21. Les sauvegardes nécessitent une restauration testée. Les alertes ont besoin d’un canal opérationnel par e-mail, monitoring, Central ou SIEM.
• À décider selon le flux et l’architecture : 3, 5, 10 et 23 à 27. X-Ops, Heartbeat, les règles de mot de passe utilisateur, Web Policy, Zero-Day Protection, Application Control et TLS Inspection ne sont pas aussi utiles sur chaque règle.
• À activer uniquement avec l’écosystème Sophos adapté ou un choix assumé de service cloud : 1, 2, 4, 6, 12, 29 et 30. Synchronized Application Control, NDR Essentials, MDR threat feeds, Security Heartbeat, DNS Protection et les fonctions Central ne sont pas un socle minimal universel. Le point 7, Login disclaimer, est principalement une décision de conformité.

Cette répartition est volontairement plus directe que la gravité Sophos. Elle évalue ce qui réduit d’abord le risque dans l’environnement réel, et non ce que Sophos peut vendre ou intégrer techniquement.

Ouvrir le Health Check

Le statut du Health Check apparaît dans le Control center. La vue détaillée est également accessible via le menu principal :

Monitor & analyze > Firewall health check

Là, vous voyez le nombre de configurations vérifiées, les points conformes et les points non conformes. Sophos affiche les entrées non conformes par gravité. Les données sont mises à jour lorsqu’une configuration surveillée change. Cela fait du Health Check un bon outil de suivi direct après les modifications.

Pour la révision, il ne faut pas seulement noter le statut global. Ce qui est plus important, ce sont les constats concrets, le contexte de risque et la mesure prévue. Un constat critique unique concernant l’accessibilité WAN de WebAdmin est plus important en opération que plusieurs constats mineurs sans exposition à Internet.

Comprendre le statut, la sévérité et l’override

La vue détaillée indique pour chaque vérification si la configuration est compliant, non compliant ou manuellement remplacée. En exploitation, ces trois états sont plus importants que le simple pourcentage.

• Compliant : la configuration vérifiée respecte la policy correspondante. Après des changements importants, elle doit tout de même être validée techniquement.
• Noncompliant : la configuration vérifiée ne respecte pas la policy. Le risque, l’exposition et la faisabilité doivent être évalués.
• Manual policy status override : la configuration ne respecte pas la policy, mais elle a été marquée manuellement comme compliant. Ce statut ne doit être utilisé qu’avec une justification, un owner et une date de revue.

Sous Action, la vue propose selon le finding des étapes de travail directes. Fix now mène à la page de configuration correspondante, Override status marque manuellement un point non conforme comme compliant et Undo override annule cette dérogation. C’est pratique, mais ne remplace pas l’évaluation : le Health Check ne sait pas automatiquement si un contrôle équivalent est réellement appliqué ailleurs.

La sévérité aide à trier, mais elle ne remplace pas l’évaluation technique. C’est une valeur Sophos statique qui ne connaît ni l’exposition ni les mesures compensatoires. Les constats High avec exposition Internet, accès administrateur, MFA, hotfixes ou règles de firewall doivent être contrôlés en premier. Un constat Low sur l’absence de backup peut être plus urgent qu’un constat Medium sur un service Sophos non utilisé.

Si un constat paraît illogique, il faut aussi vérifier la version du firmware et les problèmes connus. SFOS 22.0 MR1 a corrigé de faux statuts Doesn't comply pour les règles de pare-feu et pour NDR Essentials sur les pare-feu virtuels. Un statut manifestement erroné ne justifie donc ni une modification risquée de la configuration ni un override précipité.

Les fonctions de recherche et de tri du tableau Health Check permettent de regrouper les constats par policy, module, standard ou sévérité. Pour les grandes firewalls, c’est plus pratique que de regarder uniquement la tuile du dashboard.

Évaluation individuelle des vérifications du Health Check

La liste suivante se base sur les 31 vérifications de la vue anglaise utilisées pour cette analyse. Sophos peut modifier le nombre, l’intitulé, le standard ou la gravité lors d’une mise à jour du firmware. Si le pare-feu local affiche des constats supplémentaires ou nommés différemment, son affichage fait foi. Le statut n’est pas indiqué car il varie selon le pare-feu. L’important est de comprendre chaque vérification et de l’évaluer correctement.

Active Threat Response et Advanced Security

• 1. Synchronized Application Control devrait être activé. Standard: Recommended, gravité: Medium. La fonction identifie plus précisément les applications avec Sophos Endpoint et nécessite Security Heartbeat ; lors de la première utilisation, elle doit aussi être activée dans Sophos Central. Évaluation Avanet : optionnel. À activer uniquement avec des endpoints Sophos compatibles et si les applications détectées seront ensuite classées et utilisées dans des Application Filter. Avec Microsoft Defender ou un autre produit endpoint, un override justifié est plus utile qu’une activation sans effet.
• 2. NDR Essentials devrait être activé et surveiller au moins une interface. Standard: Recommended, gravité: Medium. Le firewall analyse le trafic sélectionné via le service cloud Sophos NDR, détecte les IoC et les journalise, mais ne les bloque pas automatiquement. Seules certaines interfaces des zones LAN, DMZ et Custom sont prises en charge ; WAN, Wi-Fi et plusieurs types d’interfaces, comme RED ou XFRM, sont exclus. Active-Active HA n’est pas pris en charge. Les logs Active Threat Response doivent aussi être activés et, selon le type d’IoC, les contrôles firewall, DNS, IPS ou decryption doivent s’appliquer. Évaluation Avanet : selon le contexte à optionnel. À activer seulement lorsque licence, analyse cloud, protection des données, interfaces adaptées et responsabilité des alertes sont clarifiées. Ne pas remplacer un NDR existant uniquement pour obtenir un Health Check vert.
• 3. Sophos X-Ops devrait être activé, Action Log and drop. Standard: CIS, gravité: High. La Threat Intelligence de SophosLabs peut bloquer des IP, domaines et URL malveillants connus. Évaluation Avanet : selon le contexte, avec une forte valeur si la licence requise existe. Vérifier logs et exceptions après activation. Un autre processus efficace peut atteindre le même objectif, même si le score ne le reconnaît pas.
• 4. MDR threat feeds devraient être activés, Action Log and drop. Standard: Recommended, gravité: High. Sophos MDR, l’enregistrement dans Sophos Central et les licences firewall adaptées sont nécessaires. Les analystes MDR peuvent pousser une Threat Intelligence spécifique au client. Évaluation Avanet : optionnel. Sans contrat MDR, ce constat n’est pas une erreur de configuration, mais une recommandation de produit et de service.
• 5. Synchronized Security Heartbeat devrait être utilisé dans une règle de pare-feu. Standard: CIS, gravité: Medium. L’état de santé de l’endpoint peut alors influencer l’accès. Évaluation Avanet : selon le contexte. Très utile avec Sophos Endpoint, mais non pertinent avec Microsoft Defender ou un autre EDR. Un pilote est indispensable : selon la règle, les appareils qui n’ont jamais envoyé de heartbeat peuvent encore accéder au réseau. Les options Block clients with no heartbeat et Block request to destination with no heartbeat imposent le comportement voulu pour ces appareils.
• 6. Security Heartbeat devrait être activé. Standard: CIS, gravité: High. Il relie Sophos Firewall et Sophos Endpoint via Sophos Central. Évaluation Avanet : selon le contexte. Sans Sophos Endpoint, un constat rouge est attendu et ne prouve pas que le firewall est mal sécurisé.
• 12. DNS Protection devrait être configuré et actif. Standard: Recommended, gravité: Medium. Sophos DNS Protection fournit des policies DNS cloud et du reporting. Le statut actif exige la licence appropriée, les résolveurs DNS Protection sur le firewall et l’adresse IP publique du firewall comme Location dans Sophos Central. Évaluation Avanet : optionnel. À activer uniquement si le service est réellement exploité comme couche de sécurité DNS et si ses logs sont examinés. Cisco Umbrella, Cloudflare Gateway, Microsoft ou d’autres filtres DNS peuvent couvrir le même objectif sans rendre le Health Check compliant.

Admin, authentification et Device Access

• 7. Login disclaimer devrait être activé. Standard: CIS, gravité: Medium. Évaluation Avanet : optionnel ou conformité. Il peut être requis, mais ne protège pas techniquement le firewall et ne doit pas être activé uniquement pour le score.
• 8. Hotfix setting devrait être activé. Standard: CIS, gravité: High. Évaluation Avanet : priorité élevée. Dans les versions SFOS 22 actuelles, aucun bloc Hotfix séparé n’apparaît sous Backup & firmware > Firmware. Sophos installe les hotfixes automatiquement par défaut ; vérifier si nécessaire avec system hotfix show dans la Device Console. L’absence de case dans l’interface n’est pas un constat.
• 9. Les sessions inactives devraient être terminées et les connexions bloquées après des tentatives échouées. Standard: CIS, gravité: High. Évaluation Avanet : priorité élevée. Les timeouts et blocages limitent les sessions abandonnées et les tentatives automatisées. Choisir des valeurs qui protègent sans provoquer trop facilement le verrouillage des admins.
• 10. La complexité des mots de passe devrait être configurée pour les utilisateurs. Standard: CIS, gravité: High. Évaluation Avanet : priorité élevée pour les comptes locaux, sinon selon le contexte. Avec Entra ID, AD ou un autre IdP, ses policies de mot de passe, lockout et MFA sont prioritaires. Les comptes locaux d’urgence et de portail restent à contrôler.
• 11. La complexité des mots de passe devrait être configurée pour les administrateurs. Standard: CIS, gravité: High. Évaluation Avanet : priorité élevée. Comptes nominatifs, MFA, réseaux de gestion restreints et suppression des comptes inutilisés comptent davantage que la complexité seule.
• 13. MFA devrait être actif pour les connexions VPN Remote Access. Standard: CIS, gravité: High. Évaluation Avanet : priorité élevée. MFA est un minimum pour SSL VPN et IPsec Remote Access. Prévoir utilisateurs de test, procédure d’urgence et contrôle de tous les chemins d’authentification.
• 14. MFA devrait être actif pour la WebAdmin Console et le VPN Portal. Standard: CIS, gravité: High. Évaluation Avanet : priorité élevée. MFA ne remplace pas les restrictions Device Access et Local Service ACL.
• 15. Les connexions aux serveurs d’authentification devraient être chiffrées. Standard: CIS, gravité: Medium. Évaluation Avanet : priorité élevée. LDAP sans TLS et d’autres méthodes non chiffrées peuvent exposer credentials et données d’annuaire. Tester certificats et comportement en panne.
• 17. L’authentification par clé publique devrait être activée pour SSH. Standard: Recommended, gravité: High. Évaluation Avanet : priorité élevée si SSH est utilisé. Limiter aussi SSH aux réseaux de gestion fiables et désactiver l’accès inutile.
• 18. Le User Portal ne devrait pas être accessible depuis la zone WAN. Standard: Recommended, gravité: High. Évaluation Avanet : priorité élevée avec examen des exceptions. Si l’accès WAN est nécessaire, limiter l’exposition, imposer MFA et surveiller les logs.
• 19. La WebAdmin Console ne devrait pas être accessible depuis la zone WAN. Standard: CIS, gravité: High. Évaluation Avanet : priorité maximale. Ne jamais exposer WebAdmin largement à Internet. Préférer VPN ou ZTNA, un réseau de gestion et des Local Service ACL Exception Rules très limitées.
• 20. MFA devrait être configuré pour l’administrateur par défaut. Standard: CIS, gravité: High. Évaluation Avanet : priorité élevée. Ce compte reste un accès d’urgence sensible. Utiliser des comptes personnels avec rôles adaptés au quotidien.

Sauvegardes, mises à jour, règles et inspection

• 16. Les sauvegardes devraient être planifiées sur le pare-feu ou dans Sophos Central. Standard: CIS, gravité: Low. Évaluation Avanet : priorité opérationnelle élevée. La faible sévérité Sophos ne reflète pas l’impact d’un restore impossible. Chiffrer les backups, les conserver hors du firewall et tester la procédure documentée.
• 21. Les emails de notification devraient être configurés pour les événements système et de sécurité. Standard: CIS, gravité: Low. Sophos Firewall peut envoyer des notifications par e-mail et SNMP ; les événements voulus se sélectionnent sous System services > Notification list. Évaluation Avanet : selon le contexte. Un chemin d’alerte fiable et testé est essentiel. Si Syslog, SIEM, monitoring ou Central Alerts fonctionnent correctement, l’e-mail n’est pas obligatoire. Un serveur SMTP configuré sans événements sélectionnés ni test de livraison ne constitue pas encore un processus d’alerte.
• 22. Les mises à jour automatiques des patterns devraient être activées. Standard: CIS, gravité: High. Évaluation Avanet : priorité élevée. Plusieurs protections perdent leur efficacité sans patterns récents. Les mises à jour sont activées automatiquement par défaut, mais leur statut et la dernière mise à jour réussie doivent tout de même être contrôlés. Le firmware des Access Points et appareils RED est seulement téléchargé puis installé séparément, car il nécessite un redémarrage. Un environnement Air-Gap exige un processus manuel de patterns et de licences documenté.
• 23. Une politique Web devrait être sélectionnée dans une règle de pare-feu. Standard: Recommended, gravité: Medium. Évaluation Avanet : selon le contexte. Souvent utile pour le web utilisateur, mais pas automatiquement pour server-to-server, updates ou trafic spécial. Définir d’abord le flux et le contrôle recherché.
• 24. La protection contre les menaces zero-day devrait être sélectionnée dans une règle de pare-feu. Standard: CIS, gravité: High. Évaluation Avanet : selon le contexte, avec une forte valeur pour les flux web et téléchargements adaptés. Licence, types de fichiers, protection des données, délai et faux positifs doivent convenir.
• 25. IPS devrait être activé et une politique IPS devrait être sélectionnée dans une règle de pare-feu. Standard: CIS, gravité: High. Évaluation Avanet : priorité élevée sur les flux pertinents. Choisir la policy selon client, serveur ou service publié, activer le logging et traiter les faux positifs.
• 26. Une politique de contrôle des applications devrait être sélectionnée dans une règle de pare-feu. Standard: CIS, gravité: Medium. Évaluation Avanet : selon le contexte. Observer d’abord le trafic critique ou inconnu en mode log avant de bloquer.
• 27. Une règle d’inspection SSL/TLS devrait utiliser l’action Decrypt. Standard: CIS, gravité: High. Évaluation Avanet : selon le contexte, ne pas activer aveuglément. Distribution CA, protection des données, Certificate Pinning, exceptions, pilote et support sont nécessaires. Un déploiement ciblé vaut mieux qu’un score vert avec des applications instables.
• 28. Une règle Allow ne devrait pas utiliser Any partout dans les champs réseau et service. Standard: CIS, gravité: Medium. Évaluation Avanet : priorité élevée. Réduire les règles larges par source, destination et service à partir de logs réels. Un Any nécessaire reste possible, mais doit être justifié, journalisé et revu.

Sophos Central et heure

• 29. Le reporting Sophos Central devrait être activé. Standard: Recommended, gravité: Medium. Évaluation Avanet : optionnel. Un Syslog/SIEM correctement exploité peut remplir le même objectif ; un constat rouge n’est alors pas une panne de reporting.
• 30. Le pare-feu devrait être enregistré pour la gestion Sophos Central et la gestion Central activée. Standard: Recommended, gravité: Medium. Évaluation Avanet : optionnel. Gestion centrale, sauvegardes et reporting sont pratiques, mais créent une dépendance cloud et des droits supplémentaires. Les environnements locaux, isolés ou Air-Gap peuvent y renoncer volontairement.
• 31. Un serveur NTP devrait être configuré. Standard: CIS, gravité: Low. Évaluation Avanet : priorité opérationnelle élevée. Une heure correcte est fondamentale pour logs, certificats, MFA, Kerberos et dépannage. Vérifier au moins deux sources fiables et leur accessibilité par le chemin prévu.

Prioriser et traiter les constats

Tous les constats n’ont pas la même importance dans chaque environnement. Une bonne révision trie donc les entrées non seulement par gravité technique, mais aussi par exposition et risque opérationnel.

Cette séquence s’est avérée efficace :

1. Vérifier les accès de gestion et portails exposés à Internet.
2. Vérifier la sécurité MFA et des connexions pour les administrateurs, VPN Portal, User Portal et Remote Access.
3. Nettoyer les règles de pare-feu avec des sources, cibles ou services trop larges.
4. Contrôler les journaux, sauvegardes et correctifs.
5. Vérifier les fonctions de protection par règle, par exemple IPS, politique Web, contrôle des applications, inspection TLS ou protection zero-day.
6. Évaluer les constats Central, reporting ou NDR pour déterminer si la fonction est réellement utilisée et exploitée dans l’environnement.

L’ordre est pragmatique : d’abord les éléments directement visibles sur Internet ou permettant l’accès au pare-feu. Ensuite, l’hygiène des règles et les fonctions de protection. Ensuite, les sujets d’exploitation et d’écosystème.

Constats typiques et mesures appropriées

WebAdmin, User Portal ou VPN Portal est trop accessible

Si les portails administratifs ou proches des utilisateurs sont accessibles depuis trop de zones, le risque augmente en raison des scans, des tentatives de force brute et du credential stuffing. L’article le plus important à ce sujet est Sécuriser l’accès à Sophos Firewall : configurer correctement Device Access.

Pour les environnements de production, il convient de vérifier :

• WebAdmin est-il vraiment nécessaire depuis la zone WAN ?
• Existe-t-il une Local Service ACL Exception Rule pour l’IP de gestion ou le réseau admin ?
• SSH est-il autorisé uniquement depuis des réseaux de confiance ?
• Les User Portal et VPN Portal sont-ils accessibles uniquement là où ils sont nécessaires ?

MFA manque ou n’est pas activé de manière cohérente

MFA doit être appliqué au moins aux accès administratifs et au Remote Access. Si le Health Check montre des constats MFA, il ne faut pas passer aveuglément à tous les utilisateurs en même temps. Mieux vaut un déploiement contrôlé avec un utilisateur de test, un administrateur de secours et un processus de jeton propre.

Le guide pratique se trouve dans Activer MFA pour Sophos Firewall WebAdmin, VPN Portal et Remote Access.

Les règles de pare-feu sont trop ouvertes

Les règles très larges avec Any pour la source, la cible ou le service sont souvent héritées. Toutes les règles larges ne sont pas automatiquement incorrectes, mais chacune doit être justifiée.

Pour le nettoyage, ces questions sont utiles :

• Quelle zone peut vraiment accéder à quelle zone ?
• Les réseaux cibles ou les services peuvent-ils être restreints ?
• La journalisation est-elle active pour rendre les correspondances visibles ?
• Y a-t-il d’anciennes règles de test ou des exceptions temporaires ?
• La règle peut-elle être divisée en plusieurs règles plus compréhensibles ?

Les bases se trouvent dans Comprendre et configurer correctement les règles de Sophos Firewall. Si l’on ne sait pas quelle règle s’applique, Tester la règle de pare-feu avec Log Viewer, Policy Test et Packet Capture peut aider.

Sauvegardes, correctifs et processus de mise à jour manquants

Un Health Check peut indiquer des sauvegardes manquantes ou des sujets de mise à jour/correctifs. Ces points semblent moins spectaculaires que l’exposition des portails, mais sont cruciaux en cas de besoin.

Avant des modifications importantes, il convient de créer une sauvegarde et de savoir comment fonctionne une restauration. La procédure est décrite dans Créer ou restaurer une sauvegarde Sophos Firewall. Pour les sujets de firmware, Mise à jour du firmware Sophos Firewall - Préparation et meilleures pratiques convient.

Journalisation et reporting incomplets

Si les journaux manquent, l’exploitation est aveugle. Le Health Check peut donner des indications sur les sujets de journalisation ou de reporting, mais la décision réelle dépend du modèle opérationnel.

Pour l’analyse locale, Log Viewer, les journaux de service et Packet Capture sont pertinents. Pour une conservation plus longue, Central Firewall Reporting ou Syslog/SIEM sont nécessaires. Si ce ne sont pas des événements de journal individuels, mais des flux de trafic, des pics de bande passante ou des relations de communication inhabituelles qui doivent être examinés, sFlow Monitoring convient en complément. Les bases locales se trouvent dans Dépannage Sophos Firewall : Services et journaux.

Les fonctions de protection ne sont pas actives dans les règles

Un point fréquent concerne les règles sans IPS, politique Web, contrôle des applications, inspection TLS ou protection zero-day. Il ne faut pas activer tout cela aveuglément, mais comprendre le chemin de trafic.

Exemples :

• Le trafic Web des utilisateurs nécessite d’autres contrôles que le trafic serveur-à-serveur.
• L’inspection TLS doit être introduite de manière planifiée car elle peut perturber les applications.
• IPS et Application Control nécessitent une journalisation et une routine de révision.
• Les fonctions NDR ou de flux de menaces ne sont utiles que si les constats sont ensuite évalués.

Pour l’inspection TLS, Introduire correctement l’inspection TLS de Sophos Firewall convient. Pour les flux de menaces, Flux de menaces Sophos Firewall convient.

Documenter et recontrôler la revue

Sophos Firewall permet de surcharger manuellement le statut de certaines vérifications. Cela peut être utile si une recommandation n’est pas mise en œuvre intentionnellement dans son propre environnement.

Cependant, les dérogations ne doivent pas être mal comprises comme une fonction de nettoyage. Elles ne sont pertinentes que si l’exigence est volontairement satisfaite autrement ou si une mesure compensatoire existe. Un exemple est MFA : si un environnement utilise Microsoft Entra ID SSO avec MFA comme contrôle de connexion obligatoire, un finding MFA local peut, selon le design, être justifié par une dérogation. Sans une telle justification, le risque demeure, même si l’affichage Health Check semble meilleur.

Si un point est surchargé, il doit être documenté :

• Pourquoi la recommandation n’est-elle pas appropriée ?
• Qui a approuvé la décision ?
• L’exception est-elle permanente ou seulement temporaire ?
• Quand sera-t-elle réévaluée ?
• Existe-t-il une mesure compensatoire ?

⚠️ Une dérogation n’est pas une correction. C’est une acceptation consciente du risque ou une exception documentée. Sans justification, le Health Check perd de sa valeur.

Documenter proprement le résultat

Une révision du Health Check doit produire un résultat traçable. Sinon, on voit brièvement un tableau de bord, mais on ne sait plus ensuite quelle décision a été prise ni quels points restent ouverts.

Pour les petits environnements, un tableau simple suffit souvent :

• Date: Quand le Health Check a-t-il été vérifié ?
• Firmware: Sur quelle version SFOS a-t-il été évalué ?
• Constat: Quel point non conforme a été signalé ?
• Risque: Pourquoi le point est-il pertinent ou moins pertinent dans cet environnement ?
• Mesure: Qu’est-ce qui sera modifié, testé ou consciemment accepté ?
• Responsable: Qui clarifie le point professionnellement ou techniquement ?
• Délai: Quand la mesure doit-elle être terminée ou réévaluée ?
• Preuve: Capture d’écran, ticket, ID de changement ou référence de journal d’audit

Pour les pare-feu en production, la preuve ne doit pas se limiter à une capture d’écran. Si une configuration a été modifiée, le ticket de changement, la piste d’audit, la règle de pare-feu concernée et le résultat du suivi doivent être réunis. Pour les modifications des règles, interfaces, hôtes et services, Vérifier les logs de piste d’audit de Sophos Firewall est particulièrement utile.

Vérifier à nouveau après les modifications

Après une correction, il convient de rouvrir le Health Check et de vérifier si le constat a vraiment disparu. De plus, un test de fonctionnalité technique est nécessaire, car un statut vert seul ne prouve pas que le trafic en production fonctionne toujours correctement.

Exemples :

• Après une modification de Device access, vérifier si l’accès admin depuis le réseau de gestion prévu fonctionne toujours et n’est plus accessible depuis les réseaux indésirables.
• Après des modifications MFA, se connecter avec un utilisateur de test et vérifier séparément l’administrateur de secours.
• Après des modifications des règles, tester Log Viewer, Policy Test et les applications concernées.
• Après des modifications de journalisation ou de reporting, vérifier si de nouveaux événements sont réellement visibles localement, dans Sophos Central ou dans le Syslog.
• Après une dérogation, mettre en place un rappel pour que l’exception ne soit pas oubliée de manière permanente.

Si plusieurs constats sont traités en même temps, il convient de diviser les modifications en petits blocs. Sinon, en cas de problème ultérieur, il est difficile de savoir si Device Access, MFA, les règles de pare-feu, l’inspection TLS ou une autre modification est la cause.

Utiliser le Health Check comme processus opérationnel

Le Health Check est le plus efficace lorsqu’il est exécuté régulièrement et après des changements importants.

Moments opportuns :

• après la configuration initiale ou une mise en production,
• avant et après des modifications importantes des règles,
• avant les mises à jour du firmware,
• après une restauration ou un échange matériel,
• après des migrations ou des changements architecturaux importants,
• avant les audits,
• trimestriellement comme revue de sécurité.

Pour les modifications elles-mêmes, la piste d’audit doit également être utilisée. L’article Vérifier les logs de piste d’audit de Sophos Firewall explique comment évaluer configuration-audit.log et suivre les modifications de configuration.

Processus de révision pratique

Un processus de révision pragmatique du Health Check se déroule ainsi :

1. Ouvrir le Health Check dans le Control Center.
2. Trier les constats non conformes par gravité.
3. Vérifier d’abord les services exposés à Internet et les accès admin.
4. Traiter les sujets de sécurité MFA, de mot de passe et de session.
5. Identifier les règles de pare-feu larges et valider avec Log Viewer.
6. Vérifier les sauvegardes, correctifs, journalisation et reporting.
7. Évaluer les fonctions de protection par règle.
8. Documenter les exceptions justifiées au lieu de les surcharger sans commentaire.
9. Vérifier à nouveau après les modifications.
10. Documenter le résultat avec la date, le responsable et les points ouverts.

Pour les révisions récurrentes, un tableau simple avec constat, risque, mesure, responsable, statut et rappel suffit souvent. L’important est que les constats ne soient pas seulement vus, mais traités ou consciemment acceptés.

Limites

Le Health Check est utile, mais a des limites claires.

• Il ne connaît pas la logique métier complète de l’environnement.
• Il n’évalue pas si une règle est nécessaire professionnellement.
• Il ne remplace pas la segmentation du réseau et le modèle de zones.
• Il ne détecte pas automatiquement chaque cas particulier risqué.
• Il ne remplace pas un audit externe et une vérification manuelle des règles.
• Il ne dit pas si les alertes seront traitées plus tard.

Il faut donc considérer le Health Check comme un point de départ. Il rend les écarts visibles, mais la véritable qualité de sécurité résulte d’une bonne architecture, de processus propres et d’un entretien constant.

Liste de vérification opérationnelle

• Exécuter le Health Check après la mise en production et après des changements importants.
• Prioriser les constats par gravité et exposition.
• Vérifier l’accessibilité WAN de WebAdmin, SSH, User Portal et VPN Portal.
• Activer MFA pour les administrateurs, les portails et le Remote Access.
• Nettoyer ou justifier les règles de pare-feu larges.
• Activer la journalisation dans les règles importantes.
• Vérifier les sauvegardes et le processus de restauration.
• Documenter le processus de correctifs et de firmware.
• Ne définir des dérogations qu’avec une justification.
• Documenter régulièrement le résultat du Health Check.

FAQ