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 Fusion (anciennement 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 dédié.

Un déploiement sûr exige davantage que l’activation d’un commutateur dans WebAdmin. La licence MDR, l’enregistrement dans Sophos Fusion, 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.

Libellés de l’interface : les chemins Sophos Fusion utilisés ici suivent l’aide de SFOS 22. L’aide de SFOS 23 utilise encore Sophos Central pour cette même connexion au cloud. Si votre build affiche ce libellé, ouvrez la page Sophos Central correspondante ; le nom à lui seul ne renseigne ni sur l’enregistrement, ni sur le droit MDR, ni sur la réception du flux. Send reports and logs to Sophos Central reste le nom documenté de l’option de journalisation.

MDR Threat Feeds en huit étapes

1. Vérifier que le Xstream Protection Bundle est présent sur le pare-feu et qu’un droit MDR actif est disponible dans Sophos Fusion.
2. Sous System > Sophos Fusion, confirmer que le bon pare-feu est enregistré dans le bon compte Sophos Fusion.
3. Documenter dans Sophos Fusion 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 les vérifications positive et négative à l’aide du Log Viewer, du contexte endpoint et de Sophos Fusion.
8. Documenter l’Audit ID, les responsables, le processus d’exception, la date de revue et le retour arrière.

Important : les MDR Threat Feeds ne constituent qu’une partie de l’exploitation MDR. Ils ne remplacent ni le contrat MDR, ni les capteurs endpoint, ni la communication sur les incidents, ni des règles de pare-feu restrictives, ni une procédure de restauration testée. Une exception trop large ou une désactivation non contrôlée peut affaiblir une réponse en cours de l’équipe MDR.

Ce que permettent les MDR Threat Feeds

Les analystes Sophos MDR peuvent envoyer directement au pare-feu, via Sophos Fusion, des renseignements sur un incident actif. Le flux est donc davantage adapté au client qu’une liste générale de réputation mondiale. 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 détection, mais autorise le trafic.
• Log and drop journalise et rejette le trafic correspondant.

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

Le Threat response mode dans Sophos Fusion et l’action locale du flux constituent deux niveaux distincts. Le mode Sophos Fusion définit les autorisations de réponse de l’équipe MDR. Log only ou Log and drop définit la manière dont le pare-feu traite un IoC déjà transmis. Avant le déploiement, les deux paramètres doivent être alignés sur le contrat MDR et le processus interne de gestion des incidents. La documentation Sophos actuelle sur le Threat response mode distingue Collaborate, Authorize et Notify Only.

Distinguer la télémétrie du pare-feu de la réponse des analystes

Les données circulent aussi dans l’autre sens : le pare-feu fournit des événements de sécurité pour les investigations MDR. Pour cela, il doit être enregistré dans Sophos Central firewall management ; sur le pare-feu, Sophos Central services doit être activé et Send reports and logs to Sophos Central doit être sélectionné. MDR analyse en continu les logs de sécurité de Advanced Threat Protection (ATP), Intrusion Detection and Prevention (IDP/IPS), Antivirus, Antispam, Sandstorm Sandbox, Web Protection et Application Control. Avec les données des endpoints, des serveurs et d’autres sources intégrées, ces événements aident à identifier les activités malveillantes, les IoC et les tentatives de déplacement latéral. La télémétrie entrante du pare-feu n’est toutefois pas le flux d’IoC propre au client que les analystes MDR renvoient au pare-feu.

Lors d’un incident critique, l’équipe MDR peut, par exemple, mettre fin aux sessions VPN d’utilisateurs compromis. Il s’agit d’une mesure de réponse aux incidents prise par les analystes dans les limites des autorisations accordées, et non d’une conséquence automatique d’une correspondance dans un flux ou d’une procédure locale de clics ou de commandes CLI. Avec Authorize, l’équipe peut répondre aux menaces actives sans consulter au préalable les contacts désignés ; avec Collaborate, la réponse est coordonnée avec ces contacts. Cela n’implique pas une autorisation de réponse illimitée pour tous les appareils ou toutes les intégrations. Les sessions VPN de production ne sont pas interrompues à titre de test fonctionnel.

Pour intervenir via Live Response, Live Response doit être autorisé sur l’appareil concerné. Isoler Sophos Endpoint et investiguer avec Live Response explique les prérequis et la procédure sûre. Les actions Microsoft 365, telles que le blocage ou l’autorisation des connexions, la révocation des sessions actives et la désactivation des Inbox Rules, nécessitent une intégration de réponse configurée ; elles suivent la procédure distincte décrite dans Intégrations MDR et XDR. La journalisation du pare-feu ou la réception d’un IoC MDR n’autorise pas automatiquement ces interventions.

Les cybora.io Threat Feeds utilisés par Avanet pour Sophos Firewall sont, en revanche, des Third-Party Threat Feeds, et non des Sophos MDR Threat Feeds ou des flux MDR créés par Avanet. Leur configuration suit la procédure des flux tiers ; elle n’accorde aucune autorisation de réponse supplémentaire à l’équipe Sophos MDR.

Comprendre l’ordre de traitement et le cycle de vie

SFOS 22 traite Active Threat Response dans l’ordre suivant : MDR, NDR Essentials, Sophos X-Ops, puis Third-Party Threat Feeds. Si un IoC correspond dans MDR avec Log and drop, le pare-feu rejette le trafic, le journalise sous MDR et ne vérifie plus les flux suivants. Avec Log only ou Monitor, des événements distincts peuvent être générés pour MDR, X-Ops et les flux tiers. Une correspondance MDR avec Log and drop arrête la vérification des flux suivants. Avec Log only ou des actions différentes selon les modules, aucune autorisation générale ne doit être déduite ; les autres actions configurées et les preuves de trafic et de journalisation doivent être vérifiées.

Les IoC MDR individuels ne sont ni créés ni modifiés dans WebAdmin. Les analystes MDR les ajoutent et les suppriment via Sophos Fusion. Ces deux opérations sont journalisées avec l’action et l’identité de l’analyste sous la forme d’un audit_ID. Ces événements d’administration doivent être recherchés dans la vue détaillée Admin du Log Viewer ou dans la Sophos Fusion Firewall Task Queue, et ne doivent pas être confondus avec les détections de trafic sous Active threat response. Localement, on contrôle uniquement l’activation du flux MDR et le fait que les détections soient journalisées ou également rejetées. Les Threat Exclusions, en revanche, sont globales et s’appliquent à tous les modules Active Threat Response.

La documentation SFOS 22 ne mentionne aucune durée de validité des IoC MDR configurable par l’administrateur du pare-feu. Il ne faut donc pas déduire de date d’expiration à partir de l’interface locale. Si une entrée est douteuse ou potentiellement obsolète, conservez le audit_ID, l’IoC et l’horodatage, puis clarifiez son statut avec l’équipe MDR. Cela importe aussi pour le retour arrière : passer de Log and drop à Log only affecte tous les IoC MDR actuellement transmis ; une Threat Exclusion peut en outre affaiblir NDR, X-Ops et les flux tiers.

Vérifier rigoureusement les prérequis

Licence et Sophos Fusion

Les MDR Threat Feeds nécessitent le Xstream Protection Bundle sur le pare-feu. Le tableau des licences SFOS 22 mentionne en plus Sophos MDR Essentials ou Sophos MDR Complete dans Sophos Fusion ; la documentation Sophos Fusion actuelle désigne les variantes du service par MDR et MDR Plus. Il faut donc vérifier le droit MDR actif dans votre compte Sophos Fusion, plutôt que déduire ce droit uniquement d’une ancienne désignation de produit. Le bundle Xstream seul ne comprend pas de service MDR.

Le pare-feu doit être enregistré dans le bon compte Sophos Fusion. Sous System > Sophos Fusion, vérifiez l’enregistrement et la transmission des rapports et des logs. La procédure complète de connexion est expliquée dans Connecter Sophos Firewall à Sophos Fusion.

Le service Sophos MDR doit également être configuré. L’enregistrement du pare-feu et la vérification de la licence ne remplacent pas cette configuration. Avant l’activation locale, confirmez avec le responsable MDR que le service est configuré pour le bon client et que le Threat response mode a été choisi de manière délibérée. Sophos exige au moins un contact autorisé avant de pouvoir configurer d’autres paramètres MDR ou utiliser le service. Pour le contexte endpoint supplémentaire fourni par Synchronized Security, le tableau des licences SFOS 22 mentionne également une licence Intercept X dans Sophos Fusion ; ce contexte n’est pas garanti par le seul bundle Xstream.

Sophos MDR : configurer les contacts et Threat Response décrit le parcours central complet, avec rôles des contacts, mécanisme de secours de Collaborate, accès aux appareils et contrôle sûr des valeurs enregistrées. Il ne remplace pas la configuration locale du flux qui suit.

Les responsabilités doivent aussi être clarifiées avant l’activation :

• Qui peut modifier le Threat response mode dans Sophos Fusion ?
• Qui répond à un appel MDR ou à une demande de précisions en dehors des heures de bureau ?
• Qui peut approuver une exception ?
• Où sont documentés l’Audit ID, l’Incident ID et les preuves techniques ?
• Quels systèmes peuvent être isolés en cas de compromission confirmée ?

Activer les destinations des logs

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

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

La colonne Central reporting n’apparaît que lorsque Send reports and logs to Sophos Central est activé sur la page Sophos Fusion. Les XGS 87/87w et 107/107w ne prennent pas en charge le reporting local ; il faut donc utiliser Central Reporting ou Syslog sur ces modèles.

Après avoir sélectionné les destinations des logs sous System services > Log settings, cliquez sur Apply. Rechargez ensuite la page et vérifiez que les destinations prévues sont toujours sélectionnées dans la ligne Active threat response. Cela confirme l’enregistrement de la configuration ; le transport effectif des logs et la réception des notifications d’incident doivent être vérifiés séparément.

Pour les notifications, vérifiez également System services > Notification list. L’activation d’une destination de logs définit le chemin de transport, mais ne prouve ni la réception effective ni le traitement correct des alertes.

Visibilité sur les IP, domaines et URL

Un IoC n’agit que sur le trafic que le pare-feu peut traiter de manière appropriée. Une règle de pare-feu adaptée est nécessaire pour le trafic transféré vers une IP de destination. Les correspondances de domaine nécessitent Application Classification ou une politique IPS dans la règle concernée. Pour un chemin d’URL HTTPS complet, il faut un Web Proxy avec déchiffrement ou une DPI avec une règle SSL/TLS Inspection adaptée.

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

Limite non résolue concernant ATR/X-Ops : la description officielle et la matrice de trafic se contredisent sur les correspondances d’adresse de destination et d’adresse source locale pour Sophos X-Ops. Pour ces cas, ni la prise en charge ni son exclusion ne sont établies de manière fiable ; les indications relatives au trafic et aux modules fournies dans les liens ne constituent pas une base de configuration validée à cet égard. Aucune direction de trafic MDR n’en est déduite et aucun effet de protection n’est présumé pour les cas X-Ops concernés. Toute modification fondée sur ces éléments nécessite au préalable une clarification formelle de Sophos ou un test produit expressément autorisé ; les liens suivants ne résolvent pas cette contradiction.

La logique générale du trafic, des modules et des inspections est décrite dans Configurer et exploiter les Threat Feeds de Sophos Firewall en toute sécurité. Cet article explique aussi pourquoi la détection d’un domaine ou d’une URL peut ne pas se produire sans la classification ou le déchiffrement approprié.

Configurer les MDR Threat Feeds

1. Se connecter à WebAdmin avec un compte administrateur personnel.
2. Ouvrir Protect > Active threat response > MDR threat feeds.
3. Activer MDR threat feeds.
4. Choisir comme Action Log only pour un pilote à durée définie, 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 ont été enregistrés.
7. Vérifier l’horodatage, l’administrateur et la modification dans l’Audit Trail.
8. Dans Sophos Fusion, vérifier que le pare-feu est en ligne et que MDR est associé au bon client ou tenant.

Ne modifiez pas simultanément et à grande échelle la journalisation, les inspections, les exceptions et l’Action. Un déploiement progressif permet de déterminer quelle modification a provoqué une détection ou un effet secondaire.

Valider l’efficacité de manière fiable

L’aide MDR examinée ici ne mentionne aucun indicateur de test MDR inoffensif utilisable de manière générale. Accéder à un véritable domaine de malware ou à une IP malveillante connue n’est donc pas une bonne méthode de validation. Le contrôle technique est divisé en plusieurs niveaux vérifiables. Un test tiers réalisé en interne ne démontre que le chemin de trafic et d’inspection testé, pas la transmission d’un IoC MDR par l’équipe d’analystes.

Configuration et transport

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

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

Examiner les détections dans le Log Viewer

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

• Horodatage, pare-feu et, en HA, nœud ayant traité le trafic
• Action et nom du flux
• IP source et destination, domaine ou URL
• Ports et protocole
• Event ID et autres champs de détail
• Pour MDR, le audit_ID associé provenant de l’événement d’administration ou de la Task Queue

La preuve du trafic et l’action de l’analyste sont deux éléments distincts. L’absence d’un champ audit_ID dans l’entrée de trafic ne constitue pas, à elle seule, une erreur de transmission. Le rapprochement s’effectue à partir de l’IoC, du pare-feu et de la fenêtre temporelle, et doit être confirmé avec MDR en cas de doute.

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 le Log Viewer, les champs Process user et Executable, ainsi que host_process_user, endpoint_id et execution_path dans la vue détaillée, sont pertinents à cet effet. Sur macOS, ces détails de processus n’apparaissent pas ; l’endpoint est alors identifié à partir de l’IP source et des données Sophos Fusion.

Lors d’une détection, le pare-feu interroge les endpoints gérés via Sophos Fusion pour obtenir ces détails. L’aide décrit cet affichage pour Windows 7 et versions ultérieures ; cela ne constitue ni une recommandation d’utiliser Windows 7, ni une garantie de prise en charge actuelle des endpoints pour chaque ancien système Windows. Sur macOS, un message générique tel que Active threat C2/Generic-C deleted peut apparaître à la place. Il ne remplace ni l’identification de l’hôte par l’IP source, ni la preuve de l’action appliquée au trafic par le pare-feu.

La synthèse locale se trouve sous Reports > Network & threats > Active threat response, dans la liste Synchronized IoC. La Vue d’ensemble des services et fichiers de logs de Sophos Firewall précise également le rôle de atr.log. Une entrée de log n’est jamais évaluée isolément : les événements du pare-feu, DNS, Web, IPS, endpoint et Sophos Fusion de la même fenêtre temporelle doivent être examinés ensemble.

Vérifications positive et négative

Un pilote en production doit couvrir au minimum ces deux cas :

1. Positif : pour un IoC ou un incident réel confirmé par l’équipe MDR, conserver séparément une entrée de trafic traçable avec l’Action correcte et l’action de l’analyste associée avec son Audit ID, puis les rapprocher. Aucun trafic supplémentaire vers une infrastructure malveillante ne doit être généré à cette fin.
2. Négatif : un processus métier légitime comparable reste accessible et ne provoque aucun blocage MDR involontaire.

Sans incident réel, aucun IoC MDR n’est créé artificiellement. Vérifiez plutôt la configuration, le traitement des tâches, le transport des logs et la voie de communication. Pour un test de trafic entièrement contrôlable, un flux pilote tiers géré en interne convient mieux qu’une cible malveillante externe.

Traiter une détection MDR comme un incident

Une détection MDR est un signal fort, mais l’entrée de log ne révèle pas à elle seule l’intégralité du chemin d’attaque. Une démarche méthodique consiste à :

1. Conserver l’horodatage, l’Action, l’IoC, le nom du flux, l’Event ID et le audit_ID.
2. Identifier l’hôte et l’utilisateur concernés à l’aide de l’IP source, de DHCP, de Synchronized Security et des données endpoint.
3. Ouvrir dans Sophos Fusion le dossier MDR associé, la détection et les autres événements des appareils.
4. Corréler les logs du pare-feu, DNS, Web, IPS et endpoint dans la même fenêtre temporelle.
5. Clarifier avec l’équipe MDR pourquoi l’IoC a été ajouté et quelle réponse est prévue.
6. En cas de compromission confirmée, déclencher la procédure interne de réponse aux incidents.
7. Décider seulement ensuite du nettoyage, de règles supplémentaires ou d’une exception ciblée.

L’Audit ID identifie l’action de l’analyste MDR. Dans le Log Viewer, cliquez d’abord sur le bouton de vue détaillée, puis choisissez Admin dans la liste déroulante. Conservez-y l’action et le audit_ID de l’ajout ou de la suppression. L’action de l’analyste est également disponible sous My Products > Firewall management > Tasks Queue dans Sophos Fusion. Lors d’une demande de précisions à MDR, joignez au dossier l’Audit ID ainsi que le numéro de série du pare-feu, l’horodatage, l’IoC, l’Event ID et l’Incident ID. Une suppression journalisée prouve une action d’administration, pas le nettoyage de l’endpoint concerné.

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

Sous Protect > Active threat response > Add threat exclusions, il est possible de créer des exceptions d’hôte/réseau et de menace. Ces exceptions s’appliquent à plusieurs modules. Une exception pour une détection MDR peut donc aussi affaiblir X-Ops, NDR ou les Third-Party Threat Feeds.

Avant de créer une exception, documentez l’IoC, le processus métier concerné, le dossier MDR et la confirmation du faux positif. L’exception doit rester aussi ciblée que possible et comporter un motif, un responsable, un ticket ainsi qu’une date de revue ou d’expiration. Exclure des réseaux clients entiers ou de larges ensembles de domaines n’est pas une solution de dépannage rapide appropriée.

Les configurations des Threat Feeds ne peuvent pas être importées ou exportées séparément ; les Threat Exclusions, en revanche, le peuvent. Les paramètres du flux MDR ne peuvent pas non plus être repris via Import existing configuration dans la configuration initiale d’un nouveau groupe de pare-feu Sophos Fusion. Après une migration, une restauration ou un remplacement, il faut donc vérifier explicitement à nouveau la fonction, l’Action, la journalisation et l’association à Sophos Fusion.

Si aucune détection MDR n’apparaît

La vérification ne commence pas par un redémarrage du service. Il faut d’abord distinguer les différentes couches :

1. La licence MDR, le compte Sophos Fusion, l’enregistrement du pare-feu et le Threat response mode sont-ils corrects ?
2. MDR Threat Feeds est-il actif localement et l’Action est-elle enregistrée ?
3. L’IoC concerné a-t-il réellement été transmis par l’équipe MDR pour cet environnement ?
4. La Sophos Fusion Firewall 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 Sophos Fusion ?
6. Le trafic passe-t-il par le pare-feu, la règle et l’inspection attendus ?
7. L’IoC figure-t-il dans des exceptions Active Threat Response, Web ou SSL/TLS ?
8. La fenêtre temporelle et, en HA, le nœud examiné sont-ils corrects ?

Pour l’état du moteur et des flux, atr.log peut être corrélé dans le temps avec le Log Viewer et la Sophos Fusion Firewall Task Queue. Les logs sont uniquement consultés ; les modifications non documentées des données de flux, des bases de données ou des services ne constituent pas une étape standard. Si la cause reste indéterminée, conservez le CTR, les logs pertinents, le Task ID, l’Audit ID, le build et l’horodatage pour Sophos MDR ou Sophos Support.

Retour arrière et contrôle des modifications

Avant l’activation, documentez l’état précédent du commutateur, l’Action, les destinations des logs et les exceptions existantes. En cas de perturbation inattendue de l’activité, ne créez pas immédiatement une exception large.

1. Conserver la détection concernée et l’impact sur l’activité.
2. Informer l’équipe MDR en indiquant l’Audit ID et l’incident.
3. Si les responsables concernés l’autorisent, repasser temporairement l’Action locale de Log and drop à Log only.
4. Uniquement si cela ne suffit pas non plus et que MDR donne son accord, rétablir de manière contrôlée l’état précédent documenté du flux.
5. Après chaque modification, vérifier à nouveau le même processus métier et l’effet sur les logs.
6. Corriger la cause et rétablir la protection en production avec une nouvelle date de revue.

Dans les environnements HA, la configuration et l’état sont vérifiés sur le Primary actuel. Les logs se trouvent sur le nœud qui a traité le trafic. Après un basculement contrôlé, validez à nouveau la connexion Sophos Fusion, l’état du flux, les nouvelles entrées de logs et le trafic réel ; la continuité sans interruption de MDR ou des logs n’est pas présumée.

Liste de contrôle

• Xstream Protection Bundle actif
• Droit MDR actif disponible dans Sophos Fusion
• Pare-feu enregistré dans le bon compte Sophos Fusion
• Threat response mode et voie de contact MDR documentés
• Destination des logs Active Threat Response activée
• MDR Threat Feeds activés
• Action choisie délibérément et pilote à durée définie
• Visibilité sur le trafic IPv4, les domaines et les 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 de gestion des incidents connus
• Contexte endpoint et limites des plateformes vérifiés
• Exceptions assorties d’un responsable et d’une date de revue
• Retour arrière et vérification HA documentés

Questions fréquentes