Diagnostiquer l’appliance d’intégration et le capteur Sophos NDR

Ce runbook permet de circonscrire les dysfonctionnements de l’NDR Integration Appliance et du capteur NDR. Il part de l’état exact affiché dans Sophos Fusion, explique les états et les mesures visibles, puis indique quand collecter les journaux pour Sophos Support.

Un état Connected ou vert ne constitue qu’un contrôle intermédiaire. Il ne prouve ni la couverture complète de la mise en miroir, ni l’envoi réussi de chaque jeu de données, ni le bon fonctionnement de la détection de bout en bout.

Procédure rapide

1. Relevez le nom de l’appliance, le System ID, l’heure d’apparition de l’erreur avec le fuseau horaire et le texte exact du message.
2. Dans Sophos Fusion, vérifiez la couleur et l’état de l’appliance, mais ne redémarrez encore rien.
3. Dans Appliance Manager, consultez Status, NDR, Integrations et Advanced, puis réalisez des captures d’écran horodatées.
4. Rattachez le symptôme à une catégorie d’erreur : plateforme/CPU, sortie/envoi, SPAN, enregistrement ou ressources partagées.
5. N’appliquez qu’une correction réversible relevant de cette catégorie d’erreur.
6. Contrôlez de nouveau les mêmes points de mesure sous une charge comparable.
7. En cas de signaux contradictoires, de conteneurs non opérationnels ou d’absence d’amélioration, collectez les journaux et procédez à une escalade.

Symptôme, contrôle et étape suivante

Interpréter correctement le rouge, le jaune et le vert

Rouge : l’intégration ne fonctionne pas

En cas d’état rouge, le message précis est plus important que la couleur :

• NDR containers not ready, <specific container names>. signifie qu’au moins une application requise n’est pas prête. Si dragonfly est mentionné ou si son état visible est anormal, commencez par vérifier la compatibilité du CPU et les prérequis de la plateforme.
• Upload to s3 failed. Request was received but an error code was returned. Error code: <S3 upload error> signifie que l’appliance a tenté d’envoyer des données vers un compartiment S3 au moyen d’une URL présignée et a reçu un code d’erreur. Il s’agit en premier lieu d’une catégorie d’erreur liée à la sortie ou au proxy.
• spanX: unhealthy span rattache le dysfonctionnement à l’entrée du port SPAN indiqué. Vérifiez d’abord le composant réseau émetteur ou le chemin virtuel de mise en miroir.

Jaune : l’intégration fonctionne avec des erreurs

spanX: packets being dropped s’affiche lorsque plus de 10 % des paquets réseau sont rejetés. La capture et le traitement des paquets sollicitent fortement le CPU. Pour une VM, des vCPU supplémentaires peuvent être nécessaires ; sur du matériel certifié, la charge peut être répartie sur une appliance supplémentaire conformément au plan de couverture approuvé. Les Log Collectors exécutés sur la même appliance peuvent également solliciter ces ressources.

Une simple augmentation de capacité ne corrige toutefois ni les sources de mise en miroir qui se chevauchent, ni un chemin de destination surchargé, ni une configuration SPAN incorrecte. Comparez donc le profil de trafic et la topologie avant toute mise à l’échelle.

Vert : aucune erreur d’intégration actuellement signalée

L’état vert signifie que NDR reçoit le trafic SPAN et traite les données des paquets sans qu’aucun problème ne soit signalé. Le classificateur d’intégrité actuel exige au moins 2 % de paquets monodiffusion pour qu’un port SPAN soit considéré comme sain. Cela ne prouve pas que tous les VLAN, sites, sens ou intervalles temporels souhaités sont couverts. L’ancienne affirmation selon laquelle un port devait afficher 100 % de trafic monodiffusion n’est pas retenue.

Pour une interprétation détaillée des indicateurs d’intégrité et de capacité, consultez « Surveiller l’intégrité et la capacité de Sophos NDR ».

Si les détections attendues restent absentes malgré l’état vert, commencez par exécuter la détection de test NDR sécurisée. Si ce contrôle échoue lui aussi et qu’un problème de VLAN est suspecté, consignez l’intervalle temporel, le port SPAN, le VLAN sélectionné et l’état visible de l’appliance afin de les transmettre à Sophos Support. Ne modifiez VLAN Strip que si l’analyse confirme que le capteur reçoit à la fois le VLAN sélectionné et VLAN0 ; dans le cas contraire, laissez ce paramètre inchangé.

Circonscrire les événements locaux avec NDR Query

Lorsque la capture et le téléversement doivent être vérifiés séparément, NDR Query dans Appliance Manager permet d’examiner les événements locaux. La requête porte sur la base de données des événements NDR de cette VM d’appliance, et non sur le Sophos Data Lake. Cet outil est bien distinct de l’Investigation Console, déployée séparément, qui exploite les données d’une appliance NDR affectée pour le Threat Hunting sur le réseau local.

1. Notez l’appliance concernée et l’intervalle temporel de l’erreur.
2. Ouvrez NDR Query et, sur Query, sélectionnez Example queries.
3. Copiez une requête prédéfinie adaptée avec Copy, collez-la dans le champ de texte, puis exécutez-la avec Go.
4. Enregistrez le résultat affiché sous Query Results avec son horodatage ; réorganisez les colonnes par glisser-déposer si nécessaire.
5. Comparez le résultat avec l’activité affichée sous NDR et l’état de Fusion sur le même intervalle temporel.

Appliance Manager ne prend actuellement en charge ici que les requêtes prédéfinies. N’utilisez ni votre propre requête SQL ni une requête provenant de l’Investigation Console. Si des résultats locaux existent alors que les données sont absentes dans Fusion, poursuivez le diagnostic du téléversement et de la sortie. Si le résultat local est vide, vérifiez d’abord l’entrée SPAN, l’intervalle temporel et la requête prédéfinie choisie ; ce résultat ne prouve pas à lui seul l’existence d’une erreur.

Interpréter les détections Nmap inattendues

Si de nouvelles analyses de système d’exploitation fondées sur Nmap apparaissent dans d’autres produits de sécurité, vérifiez l’état de OS Detection sous Global NDR Settings. Cette option, désactivée par défaut, analyse une fois activée, toutes les deux heures, chaque adresse IP interne observée par NDR. Elle peut ainsi générer des détections dans d’autres produits de sécurité.

Comparez l’heure d’activation, l’appliance concernée, les adresses IP cibles et l’horodatage des détections. Si l’activation n’est pas autorisée, si certaines cibles ne sont pas permises ou si elle a des incidences opérationnelles, désactivez de nouveau OS Detection et consignez l’heure. Vérifiez ensuite qu’aucun nouvel événement d’analyse déclenché par cette fonction n’apparaît ; traitez les alertes existantes selon la procédure propre à chaque outil. Ne répétez pas manuellement les commandes Nmap et ne créez pas d’exceptions dans les autres produits de sécurité dans le seul but de masquer le symptôme. Le maintien de cette fonction exige une autorisation documentée des responsables réseau et sécurité ainsi qu’une validation pendant au moins un intervalle complet de deux heures.

Circonscrire les symptômes liés aux conteneurs et à Dragonfly sans CLI

Dragonfly traite les données NDR. Deux schémas visibles sont pertinents pour le diagnostic :

• Un message rouge signalant des conteneurs non opérationnels peut s’afficher si dragonfly est bloqué dans une boucle de redémarrage parce que les instructions CPU requises sont absentes.
• Si l’appliance apparaît comme Connected dans Fusion, mais que les données n’atteignent pas le Data Lake et que Dragonfly est à l’état Pending sous Advanced, vérifiez le mode EVC dans le cas d’un cluster VMware EVC. Sophos exige Skylake generation or later ; Sandy Bridge n’est pas pris en charge.

Pour les VM NDR sur VMware ESXi ou Hyper-V, les indicateurs CPU pdpe1gb et avx2 doivent être disponibles. pdpe1gb est requis pour la capture de paquets et avx2 pour les fonctions de machine learning. Des vCPU supplémentaires ne compensent pas l’absence de ces indicateurs. Sous Hyper-V, Processor Compatibility Mode n’est pas pris en charge. Pour ESXi, la version 11 ou ultérieure du matériel virtuel ainsi que les exigences de plateforme documentées sont également requises.

Contrôle sécurisé :

1. Sous Advanced, consignez l’état et le nom visible du conteneur concerné.
2. Sous Status, relevez l’utilisation du CPU, la mémoire, le disque racine et le disque de données.
3. Comparez l’hyperviseur, le modèle de CPU, le paramètre EVC ou de compatibilité et les indicateurs fournis à la VM avec la documentation de plateforme approuvée.
4. Ne corrigez un paramètre d’hyperviseur ou de CPU incorrect que pendant une fenêtre de maintenance planifiée ; consignez au préalable la valeur initiale et la procédure de retour arrière.
5. Validez ensuite l’état de la VM et de l’appliance depuis les interfaces d’exploitation habituelles.
6. Si dragonfly reste à l’état Pending, si un conteneur n’est toujours pas prêt ou si une boucle de redémarrage est visible, créez un paquet de journaux et procédez à une escalade.

Les valeurs de plateforme et les prérequis CPU pris en charge sont récapitulés dans « Choisir la plateforme Sophos NDR et dimensionner correctement le capteur ».

Vérifier l’envoi vers S3 et la connexion sortante

Une erreur d’envoi vers S3 ne signifie pas qu’aucun trafic SPAN n’arrive. La capture et l’envoi sont deux étapes distinctes. Dans Appliance Manager, sous NDR, relevez donc l’activité de capture et des flux ainsi que la valeur Uploaded pour le même intervalle temporel.

Vérifiez le chemin de sortie dans l’ordre suivant :

1. La configuration de l’adresse IP MGMT, par DHCP ou manuellement, correspond-elle au réseau de gestion ?
2. La résolution DNS et la synchronisation NTP fonctionnent-elles via les services prévus ?
3. La route par défaut emprunte-t-elle le chemin de sortie Internet ou central prévu ?
4. La Network ACL, le Security Group ou le pare-feu local autorisent-ils le trafic HTTPS sortant ?
5. Le Web Proxy autorise-t-il l’appliance et les destinations requises sans modifier ni bloquer la requête S3 présignée ?
6. Les règles correspondent-elles aux exceptions actuelles de Sophos relatives aux ports et aux domaines ?

Ne recopiez pas la liste des domaines propres à chaque région et sans caractères génériques depuis d’anciens tickets. Au moment du contrôle, comparez-la aux Appliance requirements à jour. Une autorisation temporaire et générale vers l’ensemble d’Internet ne constitue pas un test sûr. Appliquez les modifications une par une et validez chacune d’elles sur le même intervalle temporel que l’erreur.

Retour arrière : après le contrôle, rétablissez la valeur initiale de toute règle de proxy, d’ACL ou de pare-feu modifiée à titre de test, sauf si cette modification est requise de façon permanente. Lors du rétablissement, préservez les chemins de gestion et d’envoi des autres intégrations qui fonctionnaient jusque-là.

SPAN défaillant, paquets rejetés ou flux manquants

spanX: unhealthy span

Pour le port précisément indiqué, vérifiez :

• la source et le sens de mise en miroir attendus ;
• l’interface de destination dédiée et le câblage physique ;
• l’association de la carte réseau de capture, du groupe de ports ou du vSwitch ;
• pour ERSPAN, l’adresse de destination, le routage, la MTU ainsi que les valeurs GRE ou VXLAN ;
• les dernières modifications apportées au VLAN, au trunk, au groupe de ports, au placement de l’hôte ou à la session de mise en miroir ;
• si la même destination est à nouveau mise en miroir par erreur en tant que source.

À l’aide d’un hôte pilote, générez un trafic monodiffusion connu et inoffensif, puis observez, sur le même intervalle temporel, le port SPAN prévu et l’évolution des flux. En l’absence d’activité, poursuivez le diagnostic au niveau de la source, du sens, du filtre, du transport ou de l’association de capture. N’évaluez le traitement et l’envoi qu’une fois la réception du trafic confirmée.

spanX: packets being dropped

Lorsque les paquets rejetés dépassent 10 %, relevez également :

• le nombre de vCPU attribués et l’utilisation du CPU par cœur ;
• la bande passante, les paquets/s et les flux/s ;
• les sources de mise en miroir ajoutées récemment ou qui se chevauchent ;
• l’évolution de la mémoire, du disque racine et du disque de données ;
• tous les Log Collectors de la même appliance, avec Received, Filtered, Accepted et Uploaded.

Pour une appliance partagée, commencez le dimensionnement par NDR, puis tenez compte de la charge des collecteurs. À l’échelle de l’appliance, les autres seuils sont de 8'000 événements de collecteur par seconde au maximum et, avec 16 GB de RAM, de 2 GB au maximum pour les Log Collectors. Même les cœurs CPU sollicités par NDR peuvent être utilisés conjointement par d’autres intégrations, ce qui peut affecter la capacité NDR. S’il faut répartir la charge des collecteurs, définissez d’abord le périmètre de responsabilité et l’appliance de destination, puis suivez le guide générique des intégrations ; ce runbook ne modifie aucune source syslog propre à un fabricant.

Avec 4 vCPU, DPDK maintient généralement un cœur à 100 % ; avec 8 vCPU, deux cœurs restent à 100 %. Ce seul constat est normal. Un problème de capacité est avéré lorsqu’il s’accompagne de paquets rejetés, d’autres cœurs saturés, d’une baisse des envois ou d’une modification de l’évolution des flux.

La chaîne de mise en miroir, la validation avec un hôte pilote et une procédure de retour arrière limitée sont décrites dans « Planifier et valider la mise en miroir du trafic pour Sophos NDR ».

Diagnostiquer l’enregistrement et l’état Connected

Une nouvelle appliance apparaît d’abord à l’état Waiting for deployment. Une fois l’amorçage et le chemin de gestion opérationnels, l’état de cette appliance passe à Connected sous Threat Analysis Center > Integrations > Configured > Integration Appliances.

Si ce changement d’état ne se produit pas :

1. identifiez la bonne appliance d’après son nom, sa plateforme et l’image ou la configuration seed générée ;
2. vérifiez si le démarrage de la VM reste bloqué dans une boucle d’erreurs ou de redémarrages ;
3. vérifiez l’adresse IP MGMT, le VLAN, le DHCP ou les valeurs manuelles, la passerelle et le DNS ;
4. contrôlez le NTP et la sortie requise par rapport aux exigences actuelles de l’appliance ;
5. pour ESXi, n’utilisez l’OVA générée depuis Fusion que pour une seule tentative de déploiement. Pour les autres plateformes, consultez la procédure de déploiement en vigueur ;
6. consignez l’heure, l’état visible et la dernière sortie de l’amorçage sans inclure de secrets.

Ne supprimez et ne réinstallez pas l’appliance. Ce runbook n’inclut volontairement aucune procédure de démantèlement ou de remplacement. L’état Connected confirme la connexion centrale et l’association, mais pas la couverture SPAN, l’envoi ou la détection.

Si l’appliance était déjà à l’état Connected et perd cet état, vérifiez d’abord le chemin de gestion, la sortie et la disponibilité de l’appliance. Les paramètres de mise en miroir ne constituent pas la première piste, car SPAN et la gestion empruntent des chemins distincts.

Vérifier l’accès à Appliance Manager plutôt qu’une erreur du capteur

Si Open Appliance Manager s’ouvre, mais que la connexion avec zadmin échoue, il s’agit d’abord d’un problème d’authentification, et non d’une preuve concernant SPAN, l’envoi ou Dragonfly. En cas d’oubli du mot de passe, utilisez le lien reset it dans la boîte de dialogue de confirmation de Open Appliance Manager, puis définissez un nouveau mot de passe. Enregistrez immédiatement le nouveau mot de passe dans le système de gestion des mots de passe ; ni l’ancien ni le nouveau ne doivent figurer dans une capture d’écran, un journal d’exploitation ou un dossier de support.

Si le compte a été verrouillé après un trop grand nombre de saisies de mot de passe incorrectes, l’autre méthode documentée consiste à utiliser la console Web de l’hyperviseur qui héberge l’appliance : sélectionnez-y Unlock Account dans la Weblink interface. Cette solution de secours suppose que vous disposez déjà d’un accès autorisé à cette console Web de l’hyperviseur ; ce runbook n’ajoute aucune commande dans le shell, via SSH ou dans la console et ne permet pas d’en déduire un autre moyen d’accès. Testez ensuite une seule fois la connexion avec le mot de passe conservé en lieu sûr. Si le compte reste verrouillé, n’essayez aucun autre mot de passe : consignez l’heure et le message visible, puis faites appel à Sophos Support.

Configuration de gestion hors ligne comme ultime étape locale de récupération

Dans Appliance Manager, Actions > Settings > Management ne doit être modifié localement que si la VM n’a aucune connexion réseau. Si la connectivité existe, la modification doit s’effectuer dans Sophos Fusion. Le fait que la VM soit hors ligne ne crée pas en soi un nouvel accès : la correction locale suppose une procédure de récupération existante et autorisée. Sans cet accès, relevez l’adresse IP MGMT actuelle, le dernier état connu dans Fusion et les informations de la plateforme, puis procédez à une escalade.

Avant de sélectionner Save, comparez les anciennes et les nouvelles valeurs de IP Assignment, IPv4/Netmask, Gateway IP, DNS, DNS 2 ainsi que, le cas échéant, Enable Web Proxy, Web Proxy Type, Proxy URL et Port Number. Les identifiants du proxy restent dans le système de gestion des mots de passe. Ne modifiez que la valeur dont l’erreur est avérée. Si l’interface demande de confirmer un redémarrage, il s’agit d’un redémarrage de l’appliance : NDR et tous les Log Collectors sont interrompus. Consignez donc d’abord les charges de travail partagées, la fenêtre de maintenance, la nouvelle adresse IP attendue et la procédure de retour arrière.

Une fois la modification appliquée, vérifiez l’accessibilité à la nouvelle adresse IP, l’état dans Fusion, la capture et le téléversement NDR ainsi que tous les Log Collectors. Si l’accès de récupération autorisé reste disponible et que la vérification échoue, annulez exactement la dernière modification en rétablissant les valeurs initiales relevées. Si l’interface n’est plus accessible, ne tentez pas de deviner des adresses ou des valeurs de proxy ; procédez à une escalade en indiquant l’état de référence, l’heure et l’incidence. L’ensemble des contrôles préalables et ultérieurs figure dans « Exploiter l’appliance et le capteur Sophos NDR en toute sécurité ».

Appliance partagée : protéger les autres intégrations

Avant tout redémarrage ou toute modification des ressources dans Fusion, ouvrez la flèche en regard du nom de l’appliance et relevez toutes les intégrations exécutées sur cette même appliance. Dans Appliance Manager, Integrations affiche leur état, leur dernier redémarrage ainsi que les compteurs syslog.

• Un Log Collector peut être redémarré individuellement au moyen de Restart ; NDR et les autres intégrations restent actifs.
• Restart All concerne tous les Log Collectors, mais pas NDR.
• Restart NDR concerne le capteur NDR, mais pas les Log Collectors.
• Actions > Restart concerne toute la VM et interrompt NDR ainsi que tous les Log Collectors.
• Actions > Shutdown arrête toute la VM et toutes les intégrations ; une procédure de remise sous tension vérifiée séparément est nécessaire.

Un redémarrage global de la VM n’est pas une première étape de diagnostic. Relevez d’abord les états et les mesures, puis déterminez le plus petit composant concerné. Les conséquences et la séquence d’exploitation sûre sont décrites dans « Exploiter en toute sécurité l’appliance et le capteur Sophos NDR ».

Collecter les données de diagnostic et les journaux

Ensemble de base

Avant toute modification, relevez :

• le nom de l’appliance, le System ID, la Version, la K3S Helm Chart version et l’Uptime ;
• l’état dans Fusion et le texte exact de l’erreur ;
• l’heure de début, l’heure de reproduction et le fuseau horaire ;
• sous Status, le CPU par cœur, la mémoire, le disque racine et le disque de données ;
• sous NDR, la capture pour chaque port SPAN configuré, la valeur Uploaded et l’évolution des flux ;
• sous Integrations, tous les Log Collectors exécutés sur la même appliance, avec leur état et leurs compteurs ;
• sous Advanced, l’état visible des conteneurs et l’heure du dernier redémarrage visible ;
• la plateforme, les ressources de la VM, le profil de trafic et les dernières modifications ;
• le résultat attendu, le résultat réel et l’impact sur l’activité.

Si Appliance Manager n’est pas accessible

1. Dans Fusion, ouvrez Threat Analysis Center > Integrations > Configured > Integration Appliances.
2. Dans le menu à trois points de l’appliance concernée, sélectionnez Collect logs.
3. Dans la colonne Log requested, ouvrez la bulle d’information et notez le nom du fichier qui y est affiché.
4. Transmettez ce nom de fichier, accompagné de l’appliance, de l’intervalle temporel et du texte de l’erreur, à Sophos Support.

Si Appliance Manager est accessible

1. Dans le menu à trois points, sélectionnez Open Appliance Manager, puis Open.
2. Dans Appliance Manager, sélectionnez Actions > Download Log File.
3. Transmettez l’archive de journaux au dossier existant uniquement par le canal convenu avec le support.

Les archives de journaux peuvent contenir des adresses IP, des noms d’hôtes et d’autres données d’exploitation confidentielles. Le mot de passe zadmin, les jetons, les clés privées, les identifiants du proxy et les autres secrets ne doivent jamais figurer dans un ticket, une capture d’écran ou une pièce jointe.

Autoriser Remote Assistance de manière contrôlée

N’activez Remote Assistance que pour un dossier de support précis. L’appliance doit être en ligne.

1. Dans Fusion, ouvrez Threat Analysis Center > Integrations > Configured > Integration Appliances.
2. Dans le menu à trois points, sélectionnez Remote Assistance.
3. Dans la boîte de dialogue, activez Enable.
4. Cochez la confirmation relative à la Sophos Group Privacy Notice, puis sélectionnez Save.
5. Attendez qu’un Access ID s’affiche.
6. Envoyez uniquement cet Access ID à Sophos Support par le canal convenu.

L’autorisation prend automatiquement fin au plus tard après sept jours. Si l’analyse est terminée plus tôt, désactivez Enable dans la même boîte de dialogue et consignez l’heure de fin. Remote Assistance ne remplace ni un dossier de support ni l’ensemble de diagnostic.

Valider la correction en toute sécurité et revenir en arrière

Ne modifiez qu’une seule hypothèse par cycle. Consignez au préalable la valeur initiale, la personne responsable, la fenêtre de maintenance et la procédure de retour arrière. Vérifiez ensuite, sous une charge comparable, que :

• le précédent message rouge ou jaune ne réapparaît pas ;
• l’état attendu de l’appliance et le chemin de gestion sont stables ;
• chaque port SPAN prévu affiche une activité correspondant au trafic pilote ;
• l’évolution des flux et l’envoi restent stables sur un intervalle temporel significatif ;
• aucun message signalant plus de 10 % de paquets rejetés ne réapparaît ;
• le CPU en dehors des cœurs DPDK attendus, la mémoire et le stockage disposent d’une marge suffisante ;
• tous les Log Collectors exécutés sur la même appliance continuent de traiter les données ;
• toute modification de la plateforme fournit les indicateurs CPU requis et un mode pris en charge.

Si le contrôle échoue ou si de nouveaux effets apparaissent, annulez précisément la dernière modification effectuée. S’il est impossible de rétablir l’état initial, n’apportez aucune autre modification, collectez les données de diagnostic et ouvrez un dossier auprès de Sophos Support.

Après la correction technique, une intégration verte ne constitue toujours pas une preuve de détection. Une fois seulement la chaîne de mise en miroir et d’envoi stabilisée, suivez la procédure « Générer et vérifier une détection de test Sophos NDR sécurisée ».

Procéder à une escalade vers Sophos Support

Ouvrez un dossier auprès de Sophos Support dans les cas suivants :

• NDR containers not ready persiste, ou dragonfly reste visiblement à l’état Pending ou dans une boucle de redémarrage ;
• les indicateurs CPU requis ne sont pas disponibles malgré l’utilisation de la bonne plateforme ;
• une erreur d’envoi vers S3 persiste alors que le DNS, le proxy, le pare-feu et le chemin de sortie ont été confirmés ;
• spanX: unhealthy span persiste malgré la vérification de la source, du sens et de l’association de destination ;
• les paquets rejetés réapparaissent après une adaptation appropriée de la capacité ou de la répartition de la charge ;
• l’état Connected, l’envoi local et la réception dans le Data Lake se contredisent ;
• l’amorçage n’aboutit pas à l’enregistrement ou l’appliance passe de manière inattendue d’un état à l’autre ;
• une correction sûre nécessiterait une intervention de bas niveau sur les conteneurs, Kubernetes ou Dragonfly.

Joignez au dossier l’ensemble de base, le nom du fichier de journaux ou l’archive de journaux, les étapes exactes et les résultats mesurables. Indiquez clairement les hypothèses déjà écartées. Sophos Support prend en charge les problèmes du produit liés à l’installation, l’administration et l’exploitation ; le dossier ne constitue pas une demande d’examen d’une détection.

Une détection fondée sur XDR et gérée par le client reste sous la responsabilité de celui-ci. Seul un dossier MDR géré par Sophos est examiné et traité par Sophos MDR. Pour créer un dossier et procéder à une escalade, consultez « Ouvrir un ticket auprès de Sophos Support avec Support Assistant ».