Exploiter Sophos Firewall NDR et Active Threat Response

Sophos Firewall peut fournir des indications supplémentaires sur le trafic réseau suspect avec NDR Essentials et NDR Active Threat Intelligence. Cela est utile si l’on souhaite non seulement bloquer les attaques, mais aussi les détecter, les examiner et les traiter dans Sophos Fusion (anciennement Sophos Central), XDR, MDR ou un SIEM.

Il est important de gérer les attentes : NDR sur le pare-feu n’est pas un interrupteur magique qui résout automatiquement chaque problème. La fonction nécessite des licences appropriées, un trafic visible, des types de journaux activés, des règles de pare-feu soigneusement choisies et un processus pour évaluer les résultats. Sans cette partie opérationnelle, seuls des journaux supplémentaires sont générés.

Décision rapide pour SFOS 22 : NDR Essentials apprend à partir des flux des interfaces sélectionnées et conserve les IoC IP et domaine détectés dans un feed local. NDR Active Threat Intelligence ne contrôle en revanche que le trafic des règles où Scan with NDR Active threat intelligence est activé. Pour les deux fonctions, Action est fixé sur Log threats ; les modules NDR eux-mêmes ne bloquent donc pas le trafic détecté.

Précision issue de la documentation SFOS 23 : Les alertes de NDR Essentials et NDR Active Threat Intelligence sont journalisées, mais elles ne modifient pas à elles seules l’état Security Heartbeat des endpoints et ne les isolent pas. Toute mesure de confinement nécessaire reste une action à autoriser séparément. Il s’agit d’une limite documentée, pas d’un changement de version testé ici.

Pour les indicateurs classiques de compromission tels que les adresses IP, les domaines ou les URL malveillants, commencez par Configurer et exploiter en toute sécurité les Threat Feeds de Sophos Firewall. Cet article se concentre sur NDR Essentials, NDR Active Threat Intelligence et l’évaluation opérationnelle.

Limite non résolue lors du renvoi vers les Threat Feeds : Dans la documentation Sophos, le texte ATR et la matrice de trafic SVG divergent sur l’applicabilité de Sophos X-Ops à certains sens de correspondance, notamment la destination et la source locale du trafic sortant. Ce désaccord reste non résolu. Seuls les cas établis pour le module et le chemin de trafic concernés peuvent être retenus ; les affirmations sur MDR, NDR ou les Threat Feeds tiers ne prouvent pas un comportement équivalent de X-Ops, y compris pour DNAT/WAF ou le trafic destiné au système. Les cas contestés nécessitent des contrôles restrictifs de pare-feu, DNAT/WAF et d’accès indépendants du feed, ainsi qu’une vérification autorisée et contrôlée du sens de correspondance, du module, des logs et de l’effet réel. Tant qu’une clarification fiable n’est pas disponible, ne pas faire dépendre la protection du comportement contesté du feed.

Distinguer clairement les termes

Sophos utilise plusieurs noms similaires. Pour les administrateurs, il est important de faire la distinction, car chaque fonction fonctionne différemment.

• NDR Essentials: Le pare-feu collecte des métadonnées issues du trafic TLS chiffré et des requêtes DNS, les envoie au service Sophos Cloud pour analyse et détecte des IoC comme des adresses IP ou des domaines. Indications basées sur le réseau sans VM capteur séparée et sans déchiffrement TLS complet pour chaque détection.
• NDR Active Threat Intelligence: Le pare-feu utilise des modèles NDR Taegis sélectionnés, détecte le trafic suspect, enregistre les événements et les envoie au Sophos Data Lake. Détection à fort signal pour XDR, MDR ou opérations de sécurité.
• Sophos NDR: Produit NDR séparé avec sa propre VM capteur, généralement via SPAN, Mirror ou TAP. Vue plus large sur le trafic Est-Ouest, les appareils non gérés et les mouvements internes du réseau.
• Threat Feeds: Les listes IoC telles que les IP, les domaines ou les URL sont vérifiées par rapport au trafic. Bloquer ou surveiller les cibles ou sources malveillantes connues.

NDR Essentials et NDR Active Threat Intelligence élargissent donc la vue du pare-feu. Sophos NDR est une architecture distincte avec un capteur séparé. Les Threat Feeds tiers sont un autre composant : ils fonctionnent sur la base d’indicateurs et peuvent bloquer directement selon l’action.

Quand l’utilisation est-elle judicieuse ?

NDR et Active Threat Response sont particulièrement utiles lorsqu’un pare-feu n’est pas seulement utilisé comme filtre de paquets, mais fait partie d’un processus de détection et de réponse.

Scénarios typiques :

• Le trafic Internet des clients doit être vérifié pour des cibles ou des modèles suspects.
• Les serveurs ou systèmes DMZ doivent fournir des signaux de détection supplémentaires.
• XDR, MDR ou SOC doivent inclure les événements du pare-feu dans les enquêtes.
• Plusieurs pare-feux doivent être évalués de manière centralisée dans Sophos Fusion ou un SIEM.
• Il existe déjà un processus pour les alertes, les tickets, les faux positifs et l’escalade.

L’utilisation est moins judicieuse si personne ne vérifie les événements, si les journaux ne sont pas transférés ou si les règles de pare-feu pertinentes ne sont pas ajustées. Dans ce cas, Rapports de pare-feu Central ou Envoyer les journaux Syslog de Sophos Firewall à un SIEM sont plus importants.

Prérequis

Avant l’activation, ces points doivent être vérifiés :

• Le pare-feu fonctionne sur une version SFOS prise en charge.
• Le Xstream Protection Bundle est actif pour NDR Active Threat Intelligence.
• La subscription exacte est vérifiée pour NDR Essentials. La présentation des bundles Sophos Firewall distingue les offres disponibles, mais ne remplace pas une vérification en temps réel : confirmer la subscription achetée sur le firewall ou auprès du partenaire Sophos, car NDR Essentials peut être attribué différemment de NDR Active Threat Intelligence et les droits peuvent évoluer.
• Si Central Firewall Reporting ou l’analyse XDR/MDR facultative est utilisé pour NDR Active Threat Intelligence, activer Send reports and logs to Sophos Central sous Sophos Central Services. L’analyse dans XDR ou MDR nécessite en plus la licence XDR, MDR Essentials ou MDR Complete appropriée. L’export vers Central n’est pas un prérequis à la détection locale et à l’examen des logs IPS ; la licence Xstream, une plateforme prise en charge, l’activation globale et par règle ainsi que la journalisation IPS restent nécessaires.
• Les types de journaux pertinents sont activés sous System services > Log settings.
• Pour NDR Active Threat Intelligence, le journal IPS est actif.
• Pour NDR Essentials, le journal Active-Threat-Response est actif.
• Il y a un propriétaire défini pour l’examen, l’ajustement, les exceptions et l’escalade.

Avant l’activation, les limites de la plateforme doivent être vérifiées. NDR Essentials est pris en charge sur toutes les XGS Appliances Gen.1 et Gen.2 ainsi que sur VMware, KVM, Hyper-V, Azure, AWS, XEN et les appliances logicielles, mais pas en HA actif-actif. NDR Active Threat Intelligence n’est en outre pas pris en charge sur XGS 87, XGS 87w, XGS 88 et XGS 88w ; les autres plateformes indiquées sont prises en charge. Dans les environnements HA, il convient donc de vérifier d’abord Comprendre les variantes de cluster HA de Sophos Firewall.

La documentation de configuration SFOS 22 et 23 indique également le Xstream Protection Bundle comme prérequis pour NDR Essentials. Toute attribution différente de la subscription doit être confirmée de manière fiable avant le déploiement ; la présentation générale des bundles ne résout pas à elle seule cette divergence. En HA actif-actif, la fonction Essentials est grisée.

Ce guide couvre SFOS 22.0 MR2. NDR Active Threat Intelligence a été ajouté avec 22.0 MR1, qui a aussi étendu NDR Essentials aux XGS Appliances et aux firewalls virtuels, logiciels et cloud. Avant un déploiement sur un ancien build 22.0, suivre la préparation de la mise à jour du firmware Sophos Firewall, noter le build installé et vérifier le chemin de mise à niveau pris en charge ainsi que l’état actuel des problèmes connus dans le firewall et le portail partenaire ou support.

Configurer NDR Essentials

Configurer NDR Essentials sous Protect > Active threat response > NDR Essentials and Active threat intelligence.

Procédure de base :

1. Activer NDR Essentials.
2. Sous Interfaces > Add new item, sélectionner les interfaces pertinentes et confirmer avec Apply selected items. Privilégier les chemins côté client vers des ressources externes susceptibles de transporter du trafic de commande et contrôle.
3. Choisir l’emplacement du centre de données pour l’analyse.
4. Définir consciemment le score de menace minimum.
5. Vérifier l’action. NDR Essentials détecte et enregistre d’abord.
6. Ouvrir System services > Log settings.
7. Activer le journal pour Active threat response.
8. Sélectionner Save, puis vérifier après quelques minutes le Log Viewer, les rapports ou Central.

Pour Data center location, SFOS sélectionne par défaut la région présentant la latence la plus faible. Une modification ultérieure peut faire perdre les analyses en cours. Ne pas utiliser la région comme simple réglage de performance : clarifier d’abord la résidence des données, l’approbation interne et l’accessibilité, documenter la région et l’heure, puis refaire le test après toute modification nécessaire.

Pour les interfaces, il ne faut pas tout sélectionner au hasard. SFOS 22 prend en charge les interfaces physiques, les VLAN directement sur des interfaces physiques, les LAG et les membres de bridge dans les zones LAN et DMZ ; les zones personnalisées restent soumises à la réserve ci-dessous. Les interfaces RED et XFRM, les VLAN sur LAG ou bridge, l’interface d’administration dédiée ainsi que les zones WAN et Wi-Fi ne sont pas pris en charge. Si une interface surveillée est dissociée de sa zone, SFOS la retire de la liste NDR. Le pare-feu ne doit surveiller qu’un seul côté du flux.

Si aucune interface n’est sélectionnée, NDR Essentials ne détecte pas de nouveaux IoC à partir du trafic. Cependant, le pare-feu peut continuer à travailler avec les IoC déjà détectés. Cela peut être facilement négligé en opération.

Ne pas présumer la prise en charge des zones personnalisées : La même page de configuration ne mentionne que LAN et DMZ pour la sélection des interfaces, alors qu’une note ultérieure inclut les zones personnalisées. Cette divergence reste non résolue. Utiliser LAN ou DMZ pour le pilote ; ne prévoir une zone personnalisée qu’après confirmation pour le build installé. Ne pas changer de zone uniquement pour contourner une sélection indisponible.

Pour journaliser les IoC détectés, Sophos mentionne la configuration des règles de pare-feu, DNS, IPS et du déchiffrement en plus du logging ATR. Vérifier ces prérequis pour le chemin de trafic réel. Cela ne signifie pas déchiffrer systématiquement toutes les connexions TLS : l’analyse des métadonnées Essentials et l’inspection ou la journalisation par d’autres modules sont des tâches distinctes.

Pour Minimum threat score, High risk (Score 9 and 10) - Recommended est un bon point de départ. Sophos conserve les IoC à partir du score 6. Le widget Summary affiche les flux surveillés et les IoC uniques regroupés par score ; le nombre d’IoC pouvant être stockés dépend de la taille de l’appliance. Pour le trafic ultérieur, SFOS génère des journaux, des notifications par e-mail ainsi que des rapports locaux et Central selon les destinations configurées.

Chaque IoC possède une TTL et une tâche quotidienne supprime les entrées expirées. Si un IoC reçoit ensuite un score inférieur, le score enregistré reste inchangé et seule la TTL est actualisée. Avec un score supérieur, SFOS met aussi à jour l’évaluation. Sous Threat indicators, la recherche peut porter sur une adresse IP, un domaine ou une chaîne partielle. Cette dynamique doit être comprise avant de transformer une valeur isolée en blocage permanent.

Les scores Essentials vont de 6 à 10 ; aucun IoC n’est conservé en dessous de 6. Selon Sophos, les IoC non malveillants ou faux positifs se situent généralement sous ce seuil, mais un score seul ne remplace pas l’analyse. Le nombre d’IoC du widget Summary est actualisé par le nettoyage quotidien des TTL. Threat indicators dans le menu supérieur affiche les noms des IoC, les scores et les noms des menaces ; par exemple, 100 trouve toutes les entrées contenant cette chaîne.

Sur XGS, Sophos décrit l’extraction des métadonnées comme un moteur léger intégré à l’architecture FastPath, alimentant plusieurs moteurs d’IA dans le cloud. Outre les charges utiles chiffrées suspectes, il peut détecter des domaines nouveaux ou inhabituels générés par algorithme. Cette architecture explique l’approche sans déchiffrement TLS complet ; elle ne constitue pas une garantie de performance mesurée ici pour chaque plateforme.

NDR Essentials reste réglé sur Log threats. Pour bloquer un IoC confirmé, se connecter au firewall en SSH, choisir 5. Device Management, puis 3. Advanced Shell, et consulter le feed avec les commandes en lecture seule cd /content/ndr et cat threatfeed.json. Sous Hosts and services > IP host ou FQDN host, créer l’objet exact, puis l’utiliser comme Destination network dans une règle drop étroite et journalisée sous Rules and policies > Firewall rules, au-dessus d’une règle allow plus générale.

Il s’agit d’une action manuelle contrôlée, pas d’une automatisation du feed. Source, ticket, responsable, date d’expiration et même test de trafic font partie de la validation. Pour revenir en arrière, conserver d’abord les statistiques, désactiver la règle drop, refaire le test, puis ne supprimer l’objet que s’il n’est référencé nulle part ailleurs.

Valider NDR Essentials avec le test Sophos

Sophos fournit un test inoffensif qui simule une communication présentant des caractéristiques de domaine et de certificat suspectes. Il s’exécute sur un poste de test Windows autorisé derrière le pare-feu, dont le trafic traverse réellement l’une des interfaces surveillées. Le fichier doit provenir exclusivement de Sophos Test. Même si la simulation n’est pas malveillante, elle doit être réalisée dans une fenêtre de test annoncée, car elle génère volontairement un événement de sécurité.

1. Sur Sophos Test, ouvrir Network Security > Network Detection and Response et sélectionner Download File. Le test inoffensif simule un téléchargement avec un domaine suspect et un certificat expiré.
2. Extraire l’archive sur le poste de test Windows et démarrer l’invite de commandes en tant qu’administrateur.
3. Dans le répertoire extrait, exécuter NdrEicarClient.exe -- all.
4. Attendre quelques minutes et exécuter une seconde fois la même commande.
5. Rechercher le nouvel IoC sous Threat indicators et l’événement NDR correspondant sous Log viewer > Active threat response.

La première exécution fournit la connexion à l’analyse dans le cloud. Une fois que NDR a classé la destination comme IoC et mis à jour le feed du pare-feu, la seconde exécution confirme la détection et la journalisation locales. Si aucun événement n’apparaît, vérifier d’abord l’interface surveillée, le chemin de sortie réel, la connectivité au cloud, la journalisation Active Threat Response et le délai d’attente. Un commutateur activé ne remplace pas ce test de bout en bout.

Configurer NDR Active Threat Intelligence

NDR Active Threat Intelligence utilise des modèles de détection NDR Taegis sélectionnés. Le pare-feu détecte et enregistre les événements correspondants et les transmet au Sophos Data Lake. Ces signaux peuvent ensuite être examinés dans Sophos Fusion, XDR, MDR ou dans un contexte SOC.

Les modèles typiques comprennent l’utilisation abusive de Certutil pour télécharger des fichiers exécutables, le balayage SSH et les tentatives de force brute provenant d’un hôte déjà compromis, le trafic HTTP GET sur le port DNS standard ou l’exfiltration de données avec des outils légitimes tels que finger. Ces activités ne peuvent pas toujours être immédiatement bloquées comme des menaces confirmées. Ce sont des signaux d’investigation forts qui doivent être corrélés avec les informations sur l’hôte, l’utilisateur et le réseau.

Les modèles Taegis NDR sont aussi connus sous le nom iSensor et sont sélectionnés par Sophos Labs. L’exemple SSH inclut des mouvements latéraux comme ceux du botnet NoaBot ; l’exemple finger concerne des hôtes Windows et peut impliquer des malwares dissimulés dans des fichiers image. Ces exemples expliquent le contexte d’investigation, pas la manière de simuler des attaques.

Procédure de base :

1. Ouvrir Protect > Active threat response > NDR Essentials and Active threat intelligence.
2. Activer NDR Active threat intelligence.
3. Choisir Minimum severity level : Critical (1), Major (2), Moderate (3), Minor (4) ou Warning (5).
4. Vérifier Action. L’action est définie sur Log threats.
5. Ouvrir System services > Log settings.
6. Activer le journal IPS.
7. Enregistrer.
8. Le rappel après Save indique l’activation par règle. Utiliser Go to firewall rules ou Rules and policies > Firewall rules pour modifier une règle pertinente.
9. Sous Other security features, activer l’option Scan with NDR Active threat intelligence.
10. Enregistrer les modifications et valider avec le trafic défini.

Le dernier point est crucial. L’activation globale seule ne suffit pas. NDR Active Threat Intelligence doit être activé dans chaque règle de pare-feu dont le trafic doit être analysé.

Minimum severity level est un seuil cumulatif. Critical (1) inclut uniquement les modèles critiques, tandis que Warning (5) inclut tous les niveaux de Critical à Warning. Le widget Summary affiche le total des sept derniers jours et regroupe les détections par gravité. Le seuil doit correspondre à la capacité d’analyse disponible ; une collecte étendue sans processus de triage ne fait que produire davantage de signaux non traités.

Quelles règles choisir en premier

Un bon déploiement ne commence pas sur toutes les règles en même temps. Il est préférable de commencer par un pilote contrôlé avec un trafic bien compris.

Points de départ judicieux :

• Réseaux clients avec accès Internet.
• Réseaux serveurs avec accès Internet sortant.
• Règles DMZ avec services publiés.
• Règles pour des segments internes particulièrement critiques.
• Règles avec un concept IPS, Web ou TLS Inspection déjà activé.

Les règles sans journalisation claire, sans propriétaire ou avec un trafic très large non classifié ne sont pas un bon point de départ. Il convient d’abord de nettoyer la base des règles. Pour l’analyse des règles et le matching, Tester les règles de pare-feu avec Log Viewer, Policy Test et Packet Capture est approprié.

Un exemple de pilote adaptable est une règle LAN-vers-WAN journalisée pour un réseau de test administré comme 192.0.2.0/24. Remplacer ce réseau de documentation par le vrai réseau de test. Les clients doivent atteindre cette règle de façon vérifiable et le responsable doit analyser les événements IPS supplémentaires.

Visibilité, TLS et DNS

Les signaux NDR ne sont aussi bons que le trafic que le pare-feu voit réellement. Pour NDR Essentials, le point important est que la fonction peut évaluer les métadonnées TLS et les requêtes DNS et fournir ainsi des indices sur une communication chiffrée suspecte sans inspection TLS complète. Cela ne remplace toutefois pas une inspection Web ou TLS correctement planifiée lorsque le contenu, les téléchargements, les catégories Web ou d’autres modules de protection doivent être contrôlés.

Pour NDR Active Threat Intelligence et les autres fonctions de sécurité, la planification des règles et de l’inspection reste déterminante. Si le trafic ne passe pas par la règle de pare-feu attendue, si la journalisation manque ou si le navigateur contourne le chemin prévu, des lacunes apparaissent dans l’évaluation.

Cela ne signifie pas qu’il faut activer l’inspection TLS partout immédiatement. L’inspection TLS est un projet opérationnel à part entière avec des certificats, des exceptions, la protection des données, la performance et le support. Pour un déploiement planifié, Introduire correctement l’inspection TLS de Sophos Firewall est approprié.

Le protocole QUIC et HTTP/3 peuvent également influencer les concepts Web et d’inspection. Si le trafic du navigateur contourne les chemins d’inspection HTTPS classiques, il convient de vérifier Bloquer correctement le protocole QUIC et HTTP/3 de Sophos Firewall.

Journaux et évaluation

Sans évaluation des journaux, NDR est peu utile. Selon la fonction, différentes zones de journaux sont pertinentes.

• NDR Essentials: Journaux de réponse aux menaces actives, indicateurs de menace, reporting central ou SIEM.
• NDR Active Threat Intelligence: Journaux IPS, filtre Log Viewer Category is NDR Active threat intelligence, reporting de pare-feu central.
• Évaluation XDR/MDR: Sophos Fusion Threat Analysis Center, détections ou cas.
• Corrélation à long terme: Syslog, SIEM, plateforme SOC ou MDR.

Pour les rapports locaux, le chemin est Reports > Network & Threat > Intrusion attacks. Dans Sophos Fusion, les événements se trouvent sous My Products > Firewall Management > Report Generator ; sous Report templates, sélectionner le rapport IPS. Ces deux vues complètent le filtre Log Viewer, mais ne remplacent pas le contrôle du chemin de trafic réel et de la règle de pare-feu correspondante.

Dans le menu supérieur, Logs ouvre les événements Essentials. Dans Log viewer > Active threat response, Detailed view affiche davantage de détails ; examiner le score de l’entrée avant de modifier le seuil. Pour ATI, ouvrir NDR Active threat intelligence logs ou définir Field: Category, Condition: is, Value: NDR Active threat intelligence sous Log viewer > Add filter. La documentation SFOS 22 nomme le portail central Sophos Fusion (anciennement Central), tandis que la documentation SFOS 23 utilise ici Sophos Central ; cela ne démontre pas un changement de livraison des logs.

Pour Sophos Fusion, le pare-feu doit envoyer les journaux et rapports à Central. La procédure est décrite dans Activer et exploiter le reporting de pare-feu Central de Sophos Firewall. Pour un SIEM propre, le type de journal approprié doit être transféré via Syslog et analysé dans le système cible. Activer la fonction ne prouve donc pas que les détections seront trouvables plus tard.

Points de vérification après l’activation :

• Les entrées de journal locales apparaissent-elles dans le Log Viewer ?
• Les journaux Active-Threat-Response ou IPS sont-ils envoyés à Central ?
• Les journaux arrivent-ils dans le SIEM ?
• Les champs comme Source, Destination, Firewall, Rule ID et catégorie sont-ils correctement reconnus ?
• Y a-t-il un tableau de bord ou une recherche pour les résultats NDR/ATR ?
• Est-il clair qui évalue les résultats ?

Pour la recette de NDR Active Threat Intelligence, un rapport vide ne prouve rien. Vérifier d’abord le réglage global, le logging IPS, l’envoi vers Central si l’évaluation Central/XDR/MDR est utilisée et le compteur de la règle pilote réellement atteinte. Une détection n’est un critère de bout en bout que si elle provient d’un test documenté par Sophos ou d’un événement existant et compris. Les simulations d’exploit ou de malware non vérifiées n’ont pas leur place en production.

Que faire en cas de résultat

Un résultat est d’abord un signal d’enquête. Chaque résultat n’est pas automatiquement une attaque confirmée, mais chaque résultat pertinent nécessite un processus.

La documentation SFOS 23 le précise pour les deux fonctions NDR : une alerte seule ne modifie pas l’état Security Heartbeat d’un endpoint et ne déclenche pas son isolation. Toute isolation ou tout blocage manuel nécessaire après l’analyse doit être autorisé et exécuté séparément, puis contrôlé pour confirmer son effet réel.

Processus minimal :

1. Enregistrer l’IP source, l’IP de destination, l’utilisateur, la règle et l’heure.
2. Vérifier dans le Log Viewer quelle règle et quel module étaient impliqués.
3. Rechercher dans Central, XDR, MDR ou SIEM d’autres événements du même hôte.
4. Corréler les journaux Endpoint, DNS, Web et d’authentification.
5. Décider si une isolation Endpoint, un blocage de firewall étroit ou une analyse supplémentaire est nécessaire. N’envisager une Threat Exclusion qu’après confirmation d’un faux positif et documentation de son impact.
6. Documenter le résultat.

En cas de faux positifs répétés, il ne faut pas immédiatement définir une exception large. Il est préférable de définir une exception étroite avec une raison, un ticket et une date de révision. Les exceptions dans Active Threat Response peuvent supprimer l’effet de protection et doivent donc faire partie d’un processus contrôlé.

Une Threat Exclusion retire une source ou une destination de l’analyse de tous les modules Active Threat Response, y compris NDR Active Threat Intelligence. Elle ne vise pas une seule signature et peut donc aussi affaiblir d’autres Threat Feeds. Examiner d’abord le contexte. Une exclusion d’hôte, réseau, adresse IP, domaine ou URL aussi étroite que possible ne doit être envisagée que si le faux positif est confirmé et si l’effet sur tous les modules est acceptable ; sinon, demander au support Sophos d’examiner les logs et les informations du pattern. Uniquement après cet examen et l’approbation de l’exclusion, cliquer sur Add threat exclusions dans le menu supérieur de la page NDR.

Revenir en arrière en toute sécurité

Le retour en arrière doit supprimer de manière ciblée la nouvelle analyse, sans désactiver d’autres modules de protection.

1. Documenter la période, les règles pilotes, les interfaces, les seuils et les derniers résultats pertinents.
2. Pour NDR Active Threat Intelligence, retirer d’abord Scan with NDR Active threat intelligence des seules règles pilotes, puis désactiver le réglage global si nécessaire.
3. Pour NDR Essentials, retirer les interfaces surveillées ou désactiver la fonction. Sans interface sélectionnée, les IoC déjà détectés peuvent encore être appliqués ; contrôler donc Threat indicators et Log viewer > Active threat response.
4. Désactiver et tester séparément les règles drop manuelles ; l’arrêt de NDR Essentials ne les supprime pas.
5. Contrôler séparément les Threat Exclusions créées pendant le pilote et ne les retirer que si aucun autre cas d’usage approuvé n’en dépend.
6. Ne retirer le logging IPS, Central Reporting ou Syslog que si aucune autre fonction n’en dépend.

Le retour est réussi si la règle pilote traite encore le trafic attendu, si NDR Active Threat Intelligence n’y est plus activé et si aucune règle de blocage manuelle ni exclusion pilote ne reste active par erreur. Avec NDR Essentials, des IoC déjà détectés peuvent continuer à produire des logs jusqu’à leur expiration ; ces entrées ne signifient donc pas automatiquement que le retour a échoué.

Erreurs typiques

• NDR Active Threat Intelligence est activé globalement, mais pas dans les règles de pare-feu.
• NDR Essentials est activé, mais aucune interface appropriée n’est sélectionnée.
• Le journal IPS ou Active-Threat-Response n’est pas actif.
• Le reporting central ou Syslog n’est pas configuré, bien qu’une évaluation centrale soit attendue.
• Des détections sont générées, mais personne ne les vérifie.
• La gravité ou le score de menace est défini trop sensible et génère du bruit inutile.
• Les exceptions sont définies trop largement.
• Active-Active HA ou les petits modèles XGS Appliance sont planifiés, bien que la fonction ne soit pas prise en charge.
• L’inspection TLS est traitée comme un détail secondaire, au lieu d’être planifiée correctement.

Deux problèmes corrigés dans les premiers builds SFOS 22.0 peuvent aussi induire en erreur : NC-152904 affichait des interfaces non prises en charge dans la sélection NDR et NC-165825 affichait à tort Doesn’t comply dans Firewall Health Check pour les firewalls virtuels. Les deux ont été corrigés dans le build 411. Si le symptôme apparaît, utiliser l’ID comme clé de recherche dans le portail partenaire ou support actuel, comparer localement le build installé et suivre le chemin de mise à jour pris en charge au lieu de contourner les limites de plateforme.

Liste de contrôle

• Version SFOS et licence vérifiées.
• Appareil ou plateforme pris en charge confirmé.
• Mode HA vérifié.
• Enregistrement Sophos Fusion vérifié, si le reporting central, XDR ou MDR est utilisé.
• Types de journaux pertinents activés sous System services > Log settings.
• Interfaces NDR Essentials sélectionnées consciemment.
• Emplacement du centre de données et score de menace minimum documentés.
• NDR Active Threat Intelligence activé.
• Règles de pare-feu pertinentes avec Scan with NDR Active threat intelligence appliquées.
• Log Viewer, reporting central ou SIEM vérifiés pour les résultats.
• Propriétaire, alerte, processus de faux positifs et intervalle de révision documentés.

Questions fréquentes