Générer et vérifier en toute sécurité une détection de test Sophos NDR
Ce test contrôlé permet de vérifier le chemin entre le trafic réseau mis en miroir et Threat Analysis Center > Detections. Il simule un téléchargement depuis un serveur dont le domaine et le certificat présentent des caractéristiques suspectes ; selon Sophos, ce téléchargement n’est pas malveillant. Il génère néanmoins délibérément une détection High Risk. Prévenez donc l’équipe SOC ou MDR responsable avant le test et ne l’exécutez que pendant une fenêtre de test approuvée.
Cette procédure utilise exclusivement Appliance Manager ; aucun téléchargement sur un poste client n’est nécessaire. Une exécution réussie génère la détection NDR-DET-TEST-IDS-SCORE. Ce résultat confirme le fonctionnement du chemin de collecte et de détection testé, mais ne garantit ni une couverture NDR complète ni l’existence d’un véritable incident de sécurité.
Autorisation et prérequis
Avant toute modification technique, consignez les informations suivantes dans un ticket de changement ou de test :
- la personne responsable, l’équipement source ou l’appliance approuvés, ainsi que le capteur NDR concerné ;
- le début, la fin prévue et le fuseau horaire de la fenêtre de test ;
- le nom attendu de la détection,
NDR-DET-TEST-IDS-SCORE, et sa classification High Risk attendue ; - le contact SOC/MDR responsable et la manière convenue de documenter cette détection de test connue ;
- la règle de pare-feu, son responsable et l’heure précise prévue pour sa suppression.
L’équipe SOC ou MDR doit confirmer le démarrage du test. Une simple invitation dans un calendrier ne suffit pas : le test ne doit pas provoquer d’escalade inutile, mais les règles NDR générales, les notifications et la surveillance MDR doivent rester actives. Ne marquez comme attendue que la détection de test pouvant être rattachée à la fenêtre et au périmètre technique approuvés.
Les prérequis suivants doivent également être remplis :
- L’appliance utilisée est configurée dans Sophos Fusion et Appliance Manager est accessible. L’accès à Appliance Manager s’effectue depuis un équipement situé sur le même réseau que Sophos NDR.
- Le trafic à tester est inclus dans la configuration actuelle de mise en miroir des ports. Ne choisissez pas une source arbitraire : utilisez précisément le chemin approuvé dont le test doit démontrer la visibilité.
- Le compte
zadminet le mot de passe correspondant pour Appliance Manager sont disponibles. - Le tenant dispose d’une licence EDR, XDR ou MDR confirmée donnant accès à Threat Analysis Center > Detections. La documentation n’indique pas qu’une licence NDR seule suffit pour accéder à cette vue.
- La personne chargée de la vérification possède un rôle Sophos Fusion autorisant l’affichage de Detections. Le rôle prédéfini ou personnalisé approprié dépend de la licence et de la configuration des rôles ; cette procédure ne présuppose aucun rôle minimal particulier.
Accès réseau réservé à la méthode Appliance Manager
Pendant la seule fenêtre de test, créez sur le pare-feu une règle sortante autorisant le trafic depuis l’appliance NDR sélectionnée vers le FQDN fixe plrqkxqwvmtkm.xyz et l’adresse IP documentée 13.56.99.184, sur TCP 2222. N’utilisez ni une zone utilisateur entière, ni la destination Any, ni une large plage de ports.
Cette combinaison fixe s’applique au test Appliance Manager décrit ici. N’ouvrez pas en plus les destinations régionales utilisées par une autre méthode de test. Une telle méthode exige un périmètre approuvé séparément et uniquement la destination actuellement documentée pour celle-ci ; les deux ensembles de destinations ne peuvent être ouverts que si les deux méthodes ont été approuvées séparément. L’adresse IP et le domaine de destination appartiennent au service de test officiel de Sophos, mais doivent tout de même être traités comme une exception temporaire. Si le pare-feu ne permet pas d’indiquer le FQDN et l’adresse IP dans une même règle, utilisez des règles ou des objets distincts, tout aussi restrictifs. Avant l’exécution, vérifiez que l’adresse de destination effectivement résolue et configurée est comprise dans le périmètre approuvé. Supprimez l’exception après le test, même si aucune détection n’apparaît.
Exécuter le test dans Appliance Manager
- Dans Sophos Fusion, ouvrez Threat Analysis Center > Integrations > Configured.
- Accédez à Integration Appliances.
- Recherchez l’appliance approuvée, ouvrez le menu à trois points dans la colonne de droite, puis sélectionnez Open Appliance Manager.
- Dans la boîte de dialogue, sélectionnez Open.
- Connectez-vous avec le nom d’utilisateur
zadminet le mot de passe de l’appliance. - Sélectionnez Generate Detections.
- Sur la page Generate NDR Detections, cliquez sur Generate Detections.
- Confirmez avec OK le message indiquant qu’une détection va être générée. Notez l’heure exacte de démarrage et attendez dix minutes avant de considérer l’exécution comme un échec.
Ne lancez pas une seconde exécution pendant ce délai. Il serait alors plus difficile de rattacher sans ambiguïté les détections, le flux réseau et la fenêtre de changement.
Valider la détection sans ambiguïté
Une fois le délai écoulé, ouvrez Threat Analysis Center > Detections dans Sophos Fusion. Réglez la période afin qu’elle inclue l’heure de démarrage notée, puis recherchez NDR-DET-TEST-IDS-SCORE.
Ne vérifiez pas seulement le nom. Une détection correspondant au test remplit les critères suivants :
- Elle est nouvelle et son horodatage permet de la rattacher à l’exécution approuvée.
- Elle est classée High Risk.
- Description indique la communication source-destination attendue en TCP/TLS sur le port
2222. - IDS est indiqué comme le principal contributeur à la détection. Dans ce contexte, IDS désigne la liste des certificats bloqués.
- Sous Raw Data,
flow_riskcontient les caractéristiques du test : protocole connu sur un port non standard, certificat autosigné, négociation ALPN inhabituelle, certificat inscrit sur une liste de blocage, forte probabilité d’un domaine généré par algorithme et indices associés à la familleFriendly Chameleon.
Consignez dans le ticket l’heure de la détection, son lien ou son ID, les adresses IP source et de destination observées, le capteur ou l’appliance, ainsi que le résultat de la vérification. Les données brutes sensibles ne doivent être enregistrées que dans le système de tickets approuvé à cet effet.
Une détection n’est pas un incident
NDR-DET-TEST-IDS-SCORE est le résultat attendu d’une simulation autorisée. Une détection est un signal qui mérite une investigation ; à elle seule, elle ne confirme ni une compromission ni un incident. N’associez au test que la détection qui lui correspond exactement. Les détections supplémentaires ou celles dont la source, la destination ou l’horodatage diffèrent doivent suivre le processus de triage habituel de l’équipe SOC ou MDR ; elles ne doivent pas être clôturées sans distinction comme de simples conséquences du test.
Une détection ne crée pas systématiquement un dossier et ne relève pas automatiquement de Sophos MDR. Un dossier issu de détections XDR est Self-managed : il reste sous la responsabilité du client, doit être attribué à un administrateur du client et n’est pas analysé par Sophos. Sophos MDR ne prend en charge qu’un dossier identifié comme Sophos-managed et fondé sur des détections MDR. Les actions que MDR est autorisé à entreprendre dépendent également du mode configuré : Authorize, Collaborate ou Notify Only. Par conséquent, ne marquez ou ne clôturez que la détection ou le dossier de test clairement corrélé, conformément au processus XDR ou MDR déjà en vigueur. Cette procédure confirme uniquement la génération et le contenu de la détection de test.
Si la détection est absente ou ne correspond pas
Commencez par le domaine de défaillance le plus restreint, puis élargissez progressivement vos vérifications. Ne modifiez pas plusieurs composants à la fois.
Appliance Manager ne confirme pas le démarrage
Vérifiez que la bonne appliance a été sélectionnée, qu’Appliance Manager est accessible depuis le réseau local et que la connexion avec zadmin fonctionne. Sans confirmation du démarrage, aucune exécution fiable du test NDR n’a encore eu lieu. Ne modifiez donc ni la mise en miroir des ports ni les paramètres de détection ; rétablissez d’abord l’accès à Appliance Manager ou faites remonter la défaillance de l’appliance.
Le test démarre, mais aucune détection n’apparaît
- Attendez les dix minutes prévues, puis vérifiez la période, les filtres et l’orthographe dans Threat Analysis Center > Detections.
- Dans les journaux du pare-feu correspondant à l’heure de démarrage notée, vérifiez si la source approuvée a effectivement établi une connexion TCP vers la destination de test approuvée sur le port
2222. Un refus ou l’absence de tentative de connexion permet de circonscrire la cause à la règle, au routage, au DNS ou au démarrage du test. - Si la connexion est visible, vérifiez que ce trafic source précis est bien mis en miroir sur le port de commutateur surveillé et transmis au bon capteur NDR. N’élargissez pas la règle de pare-feu à
Anydans le seul but de provoquer une détection. - Vérifiez l’état opérationnel de l’Integration Appliance concernée et du capteur NDR. Le bon fonctionnement de l’appliance ne prouve pas à lui seul que le flux de test parvient au capteur.
- Ne répétez le test qu’après une correction précise et en notant une nouvelle heure de démarrage. Si la détection reste absente, transmettez le ticket, l’horodatage, les observations du pare-feu, la source et la destination du test, ainsi que le capteur concerné, par le canal d’assistance Sophos approprié.
Une détection apparaît, mais ses caractéristiques diffèrent
Comparez d’abord l’heure, la source, la destination et le port. En l’absence d’une corrélation sans ambiguïté, ne considérez pas la détection comme un test réussi. Transmettez toute détection inattendue à l’équipe SOC/MDR afin qu’elle suive le triage habituel. Ne la modifiez pas et ne la clôturez pas uniquement parce que son nom est similaire.
Nettoyage et retour à l’état initial
Le retour à l’état initial fait partie du test et doit être effectué quel qu’en soit le résultat :
- Désactivez ou supprimez la règle de pare-feu sortante temporaire autorisant TCP
2222vers la destination de test. Supprimez également les objets hôte, FQDN ou service créés spécialement à cette fin, sauf s’ils sont utilisés par une autre configuration approuvée. - Vérifiez dans la configuration active du pare-feu que l’accès correspondant depuis la source du test n’existe plus. Un commentaire ou la clôture du ticket de changement ne remplace pas cette vérification technique finale.
- Informez l’équipe SOC ou MDR de la fin du test et communiquez-lui l’ID de la détection, le résultat et l’état du retour à la configuration initiale. Veillez à ce que seule la détection de test clairement corrélée soit documentée comme une simulation autorisée.
- Ne marquez ou ne clôturez la détection de test corrélée et tout dossier qui en résulte que conformément au processus XDR ou MDR applicable. Un dossier XDR Self-managed reste sous la responsabilité de l’administrateur du client auquel il a été attribué ; un dossier MDR Sophos-managed reste dans le processus MDR et demeure soumis au mode de réponse convenu.
- Ne clôturez le ticket qu’après avoir vérifié la suppression de la règle, consigné le résultat, traité l’artefact de test conformément au processus applicable et attribué toute détection inattendue à une personne responsable.
Un test ayant échoué se termine par le même retour à l’état initial. Ne laissez pas l’accès temporaire ouvert en vue d’un dépannage ultérieur : toute nouvelle exécution exige une nouvelle fenêtre de test, ou une prolongation explicite et confirmée de la fenêtre existante.