Activer et vérifier les MDR Threat Feeds sur Sophos Firewall

Les MDR Threat Feeds relient le service Sophos MDR à Sophos Firewall. Les analystes MDR peuvent transmettre au pare-feu, via Sophos Central, des adresses IPv4, des domaines et des URL liés à un incident actif dans l’environnement du client. Le pare-feu journalise ou bloque ensuite le trafic correspondant sans qu’il soit nécessaire de gérer manuellement un fichier de flux.

Un déploiement sûr exige davantage que l’activation d’un commutateur dans WebAdmin. La licence MDR, l’enregistrement dans Central, l’action locale, la visibilité nécessaire sur le trafic, les destinations des logs et la voie de contact avec l’équipe MDR doivent être cohérents. Un état local Log and drop ne prouve pas encore qu’un IoC précis est arrivé ni que le flux concerné traverse les inspections requises.

MDR Threat Feeds en huit étapes

1. Vérifier que le Xstream Protection Bundle est actif sur le pare-feu et que Sophos Central dispose de Sophos MDR Essentials ou Sophos MDR Complete.
2. Sous System > Sophos Central, confirmer que le bon pare-feu est enregistré dans le bon compte Central.
3. Documenter dans Sophos Central le Threat response mode prévu et la voie opérationnelle de contact MDR.
4. Sous System services > Log settings, activer au moins une destination de logs exploitable pour Active threat response.
5. Ouvrir Protect > Active threat response > MDR threat feeds et activer la fonction.
6. Choisir Log only pour un pilote bref et contrôlé, ou Log and drop pour la protection en production après une validation réussie, puis cliquer sur Apply.
7. Effectuer des tests positifs et négatifs avec Log Viewer, le contexte endpoint et Sophos Central.
8. Documenter l’Audit ID, les responsables, le processus d’exception, la date de révision et le rollback.

Important : Les MDR Threat Feeds ne sont qu’une partie des opérations MDR. Ils ne remplacent ni le contrat MDR, ni les capteurs endpoint, ni la communication en cas d’incident, ni des règles de pare-feu restrictives, ni une voie de récupération testée. Une exception large ou une désactivation non contrôlée peut affaiblir une réponse en cours de l’équipe MDR.

Fonction des MDR Threat Feeds

Les analystes Sophos MDR peuvent envoyer directement au pare-feu, via Sophos Central, des renseignements sur un incident actif. Le flux est donc plus spécifique au client qu’une liste de réputation globale. Un IoC transmis peut être une adresse IPv4, un domaine ou une URL.

L’action locale du pare-feu détermine ce qui se produit en cas de correspondance :

• Log only journalise la correspondance mais autorise le trafic.
• Log and drop journalise et rejette le trafic correspondant.

Sophos recommande de bloquer les IoC connus. Un bref pilote Log only peut néanmoins être utile si un environnement existant doit d’abord vérifier la visibilité, la journalisation et les effets secondaires possibles. Ce pilote doit avoir une date de fin fixe. Sans transition planifiée, une intégration MDR active peut sinon rester durablement sans effet de blocage local.

Le Threat response mode dans Sophos Central et l’action locale du flux sont deux niveaux distincts. Le mode Central définit les pouvoirs de réponse de l’équipe MDR. Log only ou Log and drop détermine la manière dont le pare-feu traite un IoC déjà transmis. Avant le déploiement, les deux paramètres sont comparés au contrat MDR et au processus interne de gestion des incidents.

Vérifier correctement les prérequis

Licence et Sophos Central

Les MDR Threat Feeds nécessitent le Xstream Protection Bundle sur le pare-feu. Sophos Central doit en outre disposer de Sophos MDR Essentials ou Sophos MDR Complete. Le bundle Xstream seul n’inclut pas un service MDR complet.

Le pare-feu doit être enregistré dans le bon compte Sophos Central. Sous System > Sophos Central, vérifier l’enregistrement et la transmission des rapports et des logs. Connecter Sophos Firewall à Sophos Central décrit le processus complet.

Les responsabilités doivent également être claires avant l’activation :

• Qui peut modifier le Threat response mode dans Central ?
• Qui répond à un appel ou à une demande MDR hors des heures ouvrables ?
• Qui peut approuver une exception ?
• Où l’Audit ID, l’Incident ID et les preuves techniques sont-ils documentés ?
• Quels systèmes peuvent être isolés après confirmation d’une compromission ?

Activer les destinations de logs

Sous System services > Log settings, activer au moins une des destinations suivantes dans la ligne Active threat response :

• Local reporting pour Log Viewer et les rapports locaux
• un Syslog server configuré pour le SIEM ou le SOC
• Central reporting pour Sophos Central

La colonne Central reporting n’apparaît qu’après l’activation de Send reports and logs to Sophos Central sur la page Sophos Central. Les XGS 87/87w et 107/107w ne prennent pas en charge le reporting local ; Central Reporting ou Syslog est donc nécessaire sur ces modèles.

Pour les notifications, vérifier également System services > Notification list. L’activation d’une destination de logs prouve uniquement le chemin de transport, pas le traitement correct des alertes.

Visibilité des adresses IP, domaines et URL

Un IoC n’agit que sur le trafic que le pare-feu peut traiter de manière appropriée. Le trafic transféré vers une adresse IP de destination nécessite une règle de pare-feu correspondante. Les correspondances de domaine requièrent Application Classification ou une stratégie IPS dans la règle concernée. Pour voir un chemin d’URL HTTPS complet, il faut Web Proxy avec déchiffrement ou DPI avec une règle SSL/TLS Inspection adaptée.

Le trafic destiné au système vers des services sous Administration > Device access, tels que WebAdmin, VPN Portal et VPN, peut être comparé à une adresse IPv4 source malveillante. Pour le trafic DNAT ou WAF entrant et transféré, Remote source match (inbound traffic) doit aussi être activé sous System services > Log settings > Active threat response afin d’obtenir la visibilité attendue dans les logs.

Configurer et exploiter en toute sécurité les Threat Feeds sur Sophos Firewall explique la logique générale du trafic, des modules et de l’inspection. L’article précise aussi pourquoi la détection d’un domaine ou d’une URL peut échouer sans classification ou déchiffrement approprié.

Configurer les MDR Threat Feeds

1. Se connecter à WebAdmin avec un compte d’administrateur personnel.
2. Ouvrir Protect > Active threat response > MDR threat feeds.
3. Activer MDR threat feeds.
4. Sous Action, choisir Log only pour un pilote limité dans le temps ou Log and drop après une validation réussie.
5. Enregistrer avec Apply.
6. Recharger la page et vérifier que le commutateur et l’action sont enregistrés.
7. Vérifier l’horodatage, l’administrateur et la modification dans l’Audit Trail.
8. Dans Sophos Central, confirmer que le pare-feu est en ligne et que MDR est affecté au bon client ou tenant.

Ne pas modifier simultanément et à grande échelle la journalisation, l’inspection, les exceptions et l’action. Un déploiement progressif permet d’identifier la modification qui a causé une correspondance ou un effet secondaire.

Valider l’effet de manière fiable

Sophos ne publie pas d’indicateur de test MDR général et inoffensif. Appeler un vrai domaine de malware ou une adresse IP malveillante connue n’est donc pas une validation appropriée. La vérification technique est séparée en plusieurs niveaux démontrables.

Configuration et transport

1. Vérifier le commutateur MDR et l’action souhaitée sur le pare-feu.
2. Contrôler l’enregistrement Central et la licence MDR.
3. Confirmer la journalisation Active Threat Response vers la destination attendue.
4. Dans Central, vérifier si les tâches MDR ou de pare-feu ont été traitées avec succès.
5. Lors d’un incident MDR réel, confirmer l’IoC attendu et l’Audit ID associé avec l’équipe MDR.

La Sophos Central Firewall Task Queue affiche les tâches MDR et API. Success confirme le traitement de la tâche dans Central, mais pas son effet sur un flux de trafic précis. En cas de Partial Success ou Failed, conserver le pare-feu concerné, l’Entity, l’Action et le Credential ID, puis les comparer à la configuration locale.

Analyser une correspondance dans Log Viewer

Sous Log viewer > Active threat response, conserver au minimum les informations suivantes :

• horodatage, pare-feu et, en HA, nœud ayant traité le trafic
• action et nom du flux
• adresse IP source et destination, domaine ou URL
• ports et protocole
• Event ID et autres champs détaillés
• audit_ID pour MDR

Avec Synchronized Security, le pare-feu peut également afficher l’utilisateur, l’hôte et le processus pour les endpoints Windows gérés. Dans Log Viewer, les champs pertinents sont Process user et Executable, ainsi que host_process_user, endpoint_id et execution_path dans la vue détaillée. Ces détails de processus ne sont pas visibles sur macOS ; l’endpoint y est identifié à l’aide de l’adresse IP source et des données Central.

Le récapitulatif local se trouve sous Reports > Network & threats > Active threat response, dans la liste Synchronized IoC. La vue d’ensemble des services et fichiers journaux de Sophos Firewall décrit également atr.log. Ne jamais analyser une entrée isolément : corréler les événements du pare-feu, DNS, web, IPS, endpoint et Central de la même fenêtre temporelle.

Test positif et négatif

Un pilote en production doit inclure au moins les deux cas suivants :

1. Positif : Un IoC ou incident réel confirmé par l’équipe MDR produit sur le pare-feu attendu une entrée traçable avec l’action et l’Audit ID corrects.
2. Négatif : Un processus métier légitime comparable reste accessible et ne déclenche pas de blocage MDR involontaire.

Sans incident réel, aucun IoC MDR artificiel n’est créé. La configuration, le traitement des tâches, le transport des logs et la voie de communication sont vérifiés à la place. Pour un test de trafic totalement contrôlé, un flux pilote tiers propre est plus sûr qu’une cible malveillante externe.

Traiter une correspondance MDR comme un incident

Une correspondance MDR est un signal fort, mais l’entrée de log seule n’explique pas le chemin d’attaque complet. Une démarche sereine consiste à :

1. Conserver l’heure, l’action, l’IoC, le nom du flux, l’Event ID et l’audit_ID.
2. Identifier l’hôte et l’utilisateur concernés à l’aide de l’adresse IP source, DHCP, Synchronized Security et des données endpoint.
3. Ouvrir dans Sophos Central le cas MDR associé, la détection et les autres événements de l’appareil.
4. Corréler les logs pare-feu, DNS, web, IPS et endpoint de la même fenêtre temporelle.
5. Demander à l’équipe MDR pourquoi l’IoC a été ajouté et quelle réponse est prévue.
6. Déclencher le processus interne de réponse aux incidents après confirmation d’une compromission.
7. Décider seulement ensuite de la remédiation, de règles supplémentaires ou d’une exception restrictive.

L’Audit ID identifie l’action de l’analyste MDR. Il apparaît dans la vue détaillée Admin de Log Viewer et sous My Products > Firewall management > Tasks Queue dans Sophos Central. L’inclure avec le numéro de série du pare-feu, l’horodatage, l’IoC, l’Event ID et l’Incident ID dans toute demande adressée à MDR.

Gérer les exceptions de manière contrôlée

Sous Protect > Active threat response > Add threat exclusions, il est possible d’ajouter des exceptions d’hôtes/réseaux et de menaces. Ces exceptions s’appliquent à tous les modules. Une exception pour une correspondance MDR peut donc aussi affaiblir X-Ops, NDR ou les Threat Feeds tiers.

Avant d’ajouter une exception, documenter l’IoC, le processus métier concerné, le cas MDR et la confirmation du faux positif. Limiter l’exception au strict nécessaire et lui attribuer un motif, un responsable, un ticket et une date de révision ou d’expiration. Des réseaux clients entiers ou de larges plages de domaines ne constituent pas une correction rapide appropriée.

Les configurations de Threat Feeds ne peuvent pas être importées ou exportées séparément, contrairement aux Threat Exclusions. Les paramètres MDR ne peuvent pas non plus être transférés via Import existing configuration vers la configuration initiale d’un nouveau groupe de pare-feu Central. Après une migration, une restauration ou un remplacement, revérifier explicitement la fonction, l’action, la journalisation et l’affectation Central.

Lorsqu’aucune correspondance MDR n’apparaît

Le contrôle ne commence pas par le redémarrage d’un service. Séparer d’abord les niveaux :

1. La licence MDR, le compte Central, l’enregistrement du pare-feu et le Threat response mode sont-ils corrects ?
2. MDR Threat Feeds est-il activé localement et l’action a-t-elle été enregistrée ?
3. L’équipe MDR a-t-elle réellement envoyé l’IoC concerné à cet environnement ?
4. Central Task Queue affiche-t-elle Success, Partial Success, Failed ou encore Pending ?
5. Les logs Active Threat Response sont-ils activés localement, vers Syslog ou dans Central ?
6. Le trafic traverse-t-il le pare-feu, la règle et l’inspection attendus ?
7. L’IoC figure-t-il dans une exception Active Threat Response, web ou SSL/TLS ?
8. La fenêtre temporelle et, en HA, le nœud examiné correspondent-ils ?

Pour l’état du moteur et du flux, corréler atr.log, Log Viewer et Central Task Queue dans le temps. Les logs sont uniquement lus ; les modifications non documentées des données de flux, bases de données ou services ne constituent pas une étape standard. Si la cause reste inconnue, collecter un CTR, les logs pertinents, le Task ID, l’Audit ID, le build et l’horodatage pour Sophos MDR ou Sophos Support.

Rollback et contrôle des modifications

Avant l’activation, documenter l’état précédent du commutateur, l’action, les destinations de logs et les exceptions existantes. Ne pas créer immédiatement une exception large en cas d’impact métier inattendu.

1. Conserver la correspondance concernée et l’impact métier.
2. Informer l’équipe MDR avec l’Audit ID et l’incident.
3. Si cela est autorisé, repasser temporairement l’action locale de Log and drop à Log only.
4. Seulement si cela ne suffit pas et avec l’accord de MDR, rétablir de manière contrôlée l’état précédent documenté du flux.
5. Revérifier le même processus métier et l’effet dans les logs après chaque modification.
6. Corriger la cause et rétablir la protection en production avec une nouvelle date de révision.

Dans les environnements HA, vérifier la configuration et l’état sur le Primary actuel. Les logs se trouvent sur le nœud qui a traité le trafic. Après un failover contrôlé, valider à nouveau la connexion Central, l’état du flux, les nouvelles entrées de logs et le trafic réel ; ne pas présumer une continuité MDR ou des logs sans interruption.

Liste de contrôle

• Xstream Protection Bundle actif
• Sophos MDR Essentials ou MDR Complete actif
• pare-feu enregistré dans le bon compte Central
• Threat response mode et voie de contact MDR documentés
• destination de logs Active Threat Response activée
• MDR Threat Feeds activé
• action choisie consciemment et pilote limité dans le temps
• visibilité du trafic IPv4, domaine et URL vérifiée
• Remote source match activé pour DNAT/WAF si nécessaire
• Task Queue et état local comparés
• Audit ID et processus d’incident connus
• contexte endpoint et limites de plateforme vérifiés
• exceptions assorties d’un responsable et d’une date de révision
• rollback et contrôle HA documentés

Questions fréquentes