Sophos Managed Risk : diagnostiquer systématiquement les analyses et les appliances

Si une analyse Sophos Managed Risk échoue, se bloque ou renvoie étonnamment peu de résultats, un diagnostic par symptôme est plus rapide qu’un redémarrage ou une ouverture étendue du pare-feu. Ce runbook passe en revue quatre domaines de défaillance possibles : l’analyse cloud externe, l’appareil d’analyse interne, l’accessibilité de la cible et l’accès authentifié.

Trouvez la bonne branche de diagnostic en cinq étapes

1. Relevez l’analyse et le scanner concernés, la plage horaire et l’état exact affiché.
2. Sélectionnez la branche de symptômes appropriée dans le tableau suivant.
3. Vérifiez d’abord la portée, le chemin du réseau et la configuration ; n’effectuez qu’une correction limitée à la fois.
4. Validez de nouveau avec la même cible et une plage horaire comparable.
5. Si l’erreur persiste, créez un ensemble de preuves expurgé de tout secret et transmettez-le au bon destinataire.

Enregistrez d’abord l’état initial

Sous My Products > Managed Risk > Scans, ouvrez l’onglet approprié External ou Internal. Avec un scanner interne, déplacez également la souris sur Status et enregistrez l’état détaillé.

Tout d’abord, les informations qui rendent le cas reproductible sont suffisantes :

• ID de locataire ou de compte et région du compte
• Nom de l’analyse et pour les analyses internes, nom du scanner
• Type d’analyse : Discovery, Authenticated ou Unauthenticated
• cible attendue et réellement capturée
• début programmé, début et fin observés avec fuseau horaire
• état complet ou texte d’erreur intégral
• dernière modification concernant l’analyse, la portée, l’exclusion, les informations d’identification, le pare-feu, le VLAN, l’hyperviseur ou l’attribution IP
• une cible affectée et, si disponible, une cible de comparaison fonctionnelle

Ensuite, ne modifiez qu’une seule variable à la fois. Cela montre clairement quelle correction a réellement aidé.

L’analyse externe n’atteint pas la destination

Managed Risk utilise des Tenable Cloud Sensors régionaux pour les analyses de vulnérabilités externes. Les facteurs décisifs sont donc la région du compte et les réseaux de capteurs actuellement publiés - et non une ancienne liste IP issue d’un ticket.

La configuration complète et les limites du périmètre sont décrites dans Configurer les analyses externes Managed Risk. Cette section sert uniquement à isoler la panne indiquée par le symptôme.

1. Dans l’e-mail Welcome to Sophos Managed Risk Service, vérifiez la région du compte Sophos Fusion.
2. Si l’e-mail est manquant, ouvrez le dossier de bienvenue sous Threat Analysis Center > Cases et lisez-y la région.
3. Dans la liste actuelle des Tenable Cloud Sensors, déterminez exactement les plages IP pour cette région.
4. Vérifiez le pare-feu pour voir si les connexions entrantes provenant de ces zones sont autorisées vers les cibles publiques autorisées. Limitez étroitement l’adresse cible et les services publiés.
5. Vérifiez la fenêtre d’événement du pare-feu ou de l’équilibreur de charge disponible pour voir si une connexion a été rejetée par la plage de capteurs attendue. Aucun chemin de journal spécifique au fabricant n’est requis.
6. Après une correction, attendez le prochain scan autorisé ou un test convenu avec l’équipe Managed Risk et vérifiez à nouveau la même cible.

Autoriser temporairement les connexions depuis l’ensemble d’Internet n’est pas un test approprié. N’ajoutez pas non plus à la liste d’autorisation Managed Risk une adresse supplémentaire d’analyse d’applications Web provenant d’un autre dossier de support Tenable.

External n’affiche pas les paramètres d’analyse

Les paramètres d’analyse externe ne sont disponibles qu’après qu’au moins un contact autorisé a été enregistré :

1. Ouvrez My Products > Managed Risk > Settings > Authorized Contacts.
2. Vérifiez qu’un administrateur Sophos Fusion est attribué à Primary et que les coordonnées sont complètes.
3. Sélectionnez Save.
4. Rouvrez My Products > Managed Risk > Scans > External.

Vous ne pouvez pas modifier vous-même les paramètres d’analyse externe déjà enregistrés. Pour une réinitialisation ou une modification sous Threat Analysis Center > Cases > Create case, sélectionnez le type Managed Risk service request. N’essayez pas de contourner la restriction en utilisant un autre périmètre.

La portée est rejetée ou contient des cibles inattendues

Vérifier la portée externe par rapport aux limites

Les limites suivantes s’appliquent sous My Products > Managed Risk > Scans > External :

• Add Domains: maximum de 25 domaines enregistrés publiquement et routables sur Internet
• Add IP addresses: maximum de 100 adresses IP uniques ou plages CIDR
• Plages CIDR externes : aucun préfixe inférieur à /24
• maximum 1 000 appareils externes
• pas d’espaces privés comme 10.0.0.0/8, 172.16.0.0/12 ou 192.168.0.0/16

Un nom comme firma.local ou une adresse IP privée n’est pas une destination externe valide. En cas de message d’erreur, ajoutez les entrées individuellement plutôt que sous forme de grande liste. Cela indique clairement quelle valeur échoue en raison du format, de l’accessibilité publique ou d’une limite. N’utilisez pas une autre adresse IP publique comme espace réservé.

Comparez les cibles internes et les exclusions globales

Les analyses de découverte et de vulnérabilité acceptent les adresses IP, les plages CIDR et les noms d’hôte sous Add scan targets. Une cible syntaxiquement valide peut toujours manquer si elle a été globalement exclue.

Sous Managed Risk > Settings > Global Exclusions, comparez chaque entrée au nom d’hôte, à l’adresse IP et à la plage CIDR parente concernés. Une exclusion globale affecte les analyses internes comme externes. Ne la supprimez donc pas et ne l’élargissez pas précipitamment. Comparez d’abord le nom, la description, Add targets et l’objectif approuvé au périmètre réel. Si une modification est nécessaire, corrigez uniquement la cible erronée, puis contrôlez les deux types d’analyse pour éviter toute couverture involontaire.

Le scanner s’arrête ou apparaît hors ligne

Juste après son ajout, un nouveau scanner affiche Waiting for Deployment. Après le déploiement, il passe par les états visibles Downloaded, Waiting for appliance, Loading plugins, puis Connected. Le statut indique où concentrer le diagnostic.

L’installation et la configuration initiale sont décrites dans Configurer les analyses internes et l’appliance d’analyse. Les contrôles ci-dessous supposent que cette configuration est terminée.

1. Comparez la VM aux versions d’hyperviseur prises en charge et au dimensionnement minimal en vCPU, RAM et stockage indiqué dans le guide de déploiement lié.
2. Vérifiez la génération de processeur effectivement présentée à la VM. Sous VMware, vérifiez aussi que le mode EVC respecte le niveau minimal documenté ; sous Hyper-V, le mode de compatibilité du processeur ne doit pas être activé.
3. Confirmez que l’appliance utilise toujours son adresse DHCP réservée ou son adresse manuelle documentée, et que la passerelle, le DNS et la synchronisation horaire fonctionnent.
4. Dans les événements du pare-feu ou du proxy concerné, vérifiez l’accès sortant uniquement vers les ports et domaines documentés dans le guide de déploiement. Ne remplacez pas cette liste par une autorisation Internet générale.
5. Si la génération de l’image reste en attente plus de quelques minutes, actualisez la page Sophos Fusion comme indiqué dans le guide de déploiement. Si un déploiement VMware doit être recommencé, utilisez une nouvelle OVA à usage unique plutôt que l’ancien fichier.
6. Prévoyez jusqu’à 30 minutes pour le premier démarrage et le chargement initial des plugins. Ne considérez Loading plugins comme bloqué qu’après ce délai ; relevez alors l’état affiché au survol et le temps écoulé au lieu de redémarrer l’appliance.

L’analyse interne dure trop longtemps ou n’atteint pas les cibles

Un périmètre étendu peut donner l’impression que l’appliance est défaillante. Les plages CIDR avec un préfixe /16 ou plus petit peuvent entraîner des délais d’attente car un grand nombre d’adresses sont vérifiées. Divisez ces réseaux en sous-réseaux techniquement pertinents et planifiez les analyses à des jours ou à des heures différents. Aucun réseau non autorisé n’est autorisé à entrer dans le champ d’application.

S’il ne manque que quelques cibles, cette courte vérification du chemin réseau est généralement plus efficace :

1. La cible est-elle saisie dans la bonne analyse de découverte ou de vulnérabilité ?
2. Un Global Exclusion couvre-t-il la cible directement ou via une plage CIDR ?
3. Le scanner continue-t-il à utiliser l’adresse IP réservée ou configurée manuellement ?
4. La cible est-elle sur un autre VLAN ? L’appliance d’analyse a alors besoin d’un accès bidirectionnel complet à tous les ports et protocoles requis pour analyser cette cible.
5. Une liste de contrôle d’accès réseau, un pare-feu hôte, une règle IPS/IDS ou une stratégie de protection des points finaux bloque-t-il l’accès à partir de l’adresse IP du dispositif d’analyse ?

Ne partagez pas de VLAN les uns avec les autres à tous les niveaux. Limitez une règle de l’adresse IP fixe du scanner aux cibles approuvées et validez exactement ces cibles lors de la prochaine analyse. Si même une petite portée accessible reste dans Running ou si aucun rapport n’apparaît sous Managed Risk > Report History une fois terminé, enregistrez le temps, la portée et le statut pour le support produit.

Résultats authentifiés manquants

Une analyse Unauthenticated simule un attaquant externe et détecte généralement moins de vulnérabilités. Une analyse Authenticated obtient un accès plus approfondi et en trouve généralement davantage. Cependant, cela ne fonctionne que si les informations d’identification correctes sont attribuées et que la cible autorise l’accès requis.

Les types d’identifiants, leur création et leur attribution sécurisée sont décrits dans Configurer les identifiants des analyses authentifiées. Cette section diagnostique uniquement pourquoi une attribution existante ne produit pas de résultats authentifiés.

Ouvrez l’analyse de vulnérabilité sous My Products > Managed Risk > Scans > Internal. La configuration n’est correcte que si tous les points suivants sont respectés :

• Scan type est défini sur Authenticated.
• L’identifiant prévu pour la cible est sélectionné sous Select credentials.
• Une analyse utilise un maximum de dix informations d’identification.
• Le Targets facultatif d’un identifiant SSH contient l’hôte affecté ou sa zone.
• Correspondance du type d’identifiant et de la destination : Windows, SSH, SNMPv3 ou VMware ESX SOAP API.
• Les informations d’identification ont été mises à jour après une modification de mot de passe, de clé, de domaine, de KDC ou d’autorisation sous Managed Risk > Settings > Credentials.

Ne supprimez pas les informations d’identification à titre de test. La suppression supprime un identifiant de toutes les configurations d’analyse qui l’utilisent.

Pour Windows, un compte d’administrateur local dédié doit être utilisé pour les systèmes normaux. Les informations d’identification de l’administrateur de domaine appartiennent uniquement à des analyses distinctes et spécialement protégées pour les contrôleurs de domaine. Le pare-feu de l’hôte, les politiques locales ou de domaine, la protection des points finaux, IPS/IDS, WMI, les partages administratifs et Remote Registry ne doivent pas bloquer le chemin d’analyse.

Pour macOS et Linux, vérifiez l’accès SSH, l’authentification sélectionnée, les autorisations et toute élévation de privilèges sur la cible. Avec Kerberos, KDC, domaine, transport et DNS inversé doivent s’intégrer. N’affaiblissez pas globalement les paramètres du système d’exploitation uniquement à des fins de test.

Testez les informations d’identification Windows de manière contrôlée

Les tests documentés suivants s’appliquent uniquement aux informations d’identification Windows. Le point de départ est un système Windows autorisé sur le même sous-réseau que l’appliance d’analyse pour garantir que les conditions du réseau restent comparables. Utilisez une session administrative Command Prompt ou PowerShell et exactement les mêmes informations d’identification que dans Sophos Fusion. Assurez-vous au préalable que ni un historique de commandes persistant ni un enregistrement de session n’enregistrent l’entrée.

Vérifiez d’abord IPC$ et le partage administratif :

net use \\<Target_IP>\ipc$ /user:<username> *
net use \\<Target_IP>\admin$ /user:<username> *

The command completed successfully est attendu dans chaque cas. Le premier succès confirme les fonctionnalités de base du réseau et des informations d’identification, le deuxième l’accès administrateur et l’accès au partage.

Si les deux connexions fonctionnent, Remote Registry et WMI suivent :

reg query \\<Target_IP>\HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion /v ProgramFilesDir
wmic /node:"<Target_IP>" /user:"<username>" /password:* os get name

Un ProgramFilesDir renvoyé confirme que Remote Registry est accessible avec ces informations d’identification. Une sortie du système d’exploitation confirme l’accès WMI. Si une seule de ces étapes échoue, corrigez ce chemin exact (partage, accessibilité du service, règle WMI ou autorisation) sur la cible. N’accordez aucun droit supplémentaire avant d’avoir identifié la cause exacte du refus.

Déconnectez toujours les deux connexions de session après les vérifications - même si une étape partielle échoue :

net use \\<Target_IP>\ipc$ /delete
net use \\<Target_IP>\admin$ /delete

Exécutez ensuite net use et vérifiez qu’aucune connexion à la cible de test ne subsiste. Fermez le shell et assurez-vous qu’aucun mot de passe n’a été enregistré dans les notes ou les pièces jointes de diagnostic. Lancez ensuite une analyse autorisée avec le même identifiant et comparez les résultats.

Classer correctement les résultats divergents

Des résultats différents ne constituent pas automatiquement une erreur. Deux outils ou analyses peuvent utiliser des règles, des plugins et des cycles de mise à jour différents. De plus, le système d’exploitation, les ports ouverts et Scan type déterminent quelles vérifications sont applicables.

Pour une comparaison fiable, notez les points suivants :

• Produit et type de scan des deux comparaisons
• Temps d’analyse et portée cible
• authentifié ou non authentifié
• Identifiant utilisé avec succès, sans secret
• services accessibles et changements entre les exécutions
• Vulnérabilité affectée ou CVE et texte de justification visible

Managed Risk n’évalue pas les vulnérabilités des applications Web ou des API. L’absence d’un résultat concernant une application Web ou une API ne prouve donc pas qu’une analyse de vulnérabilité réseau est défectueuse. À l’inverse, un scan Authenticated avec plus de résultats ne prouve pas que le scan Unauthenticated précédent était défectueux.

Si un résultat spécifique reste flou malgré des conditions comparables, demandez un examen technique par l’équipe Managed Risk dans Threat Analysis Center > Cases > Create case > Managed Risk service request.

Rassemblez un ensemble de preuves sans secrets

Le dossier de preuves doit limiter les demandes d’informations complémentaires sans créer de nouveaux risques. Il comprend :

• ID de locataire ou de compte et région du compte
• Nom du scan et du scanner
• statut visible et texte d’erreur complet
• Heure de début, de fin et de reproduction avec fuseau horaire
• Type d’analyse, cibles et exclusions pertinentes
• pour les problèmes d’appliance : hyperviseur et version, version matérielle de la VM, modèle de CPU ou mode EVC, vCPU, RAM, stockage et type d’allocation IP
• pour les problèmes de réseau : IP du scanner, cible affectée, VLAN et résultat de la vérification du pare-feu/ACL
• pour les problèmes d’informations d’identification : nom et type d’informations d’identification, affectation à l’analyse et résultat de IPC$, ADMIN$, Remote Registry et WMI
• derniers changements pertinents et impact commercial
• Correction sécurisée déjà effectuée et résultat du test répété

N’incluez pas : les mots de passe, les hachages NTLM, les clés privées, les phrases secrètes, les secrets KDC, les données de session ou les sorties système complètes inutiles. Les captures d’écran et les journaux peuvent contenir des adresses IP internes, des noms d’hôte et des noms d’utilisateur et ne sont transmis que via le canal d’assistance protégé convenu.

Choisissez la bonne voie d’escalade

Pour créer, transmettre de manière sécurisée et suivre les dossiers, consultez Créer et gérer les dossiers Managed Risk.

Équipe Managed Risk

Les questions concernant le service, la couverture de l’analyse, les résultats ou les rapports, ainsi que les modifications apportées aux paramètres d’analyse externe enregistrés doivent faire l’objet d’un dossier Managed Risk :

Threat Analysis Center > Cases > Create case > Managed Risk service request

Utilisez un nom de dossier explicite et joignez le dossier de preuves expurgé. La liste commune regroupe les dossiers XDR, MDR et Managed Risk ; vérifiez donc que Case type indique Managed Risk. Seules les équipes Sophos traitent les dossiers Managed Risk.

Assistance produit

Une panne reproductible d’un produit ou d’un appareil fait partie du support produit. Il s’agit notamment d’une appliance qui ne devient pas Connected malgré le respect des exigences de plate-forme et de réseau, un état intermédiaire persistant ou une erreur technique dans l’interface. Dans Sophos Fusion, ouvrez l’icône Aide, sélectionnez Create support case et envoyez le package de preuves nettoyé.

Opérations MDR

Transmettez à MDR Operations uniquement les incidents MDR actifs. Une analyse de vulnérabilité en échec, un paramètre d’analyse ou une appliance défectueuse doit suivre la voie Managed Risk ou Support produit indiquée ci-dessus.

Assistance à distance uniquement pour un cas de support spécifique

N’activez l’assistance à distance que lorsque le support produit le demande pour un dossier existant. Pour cela, l’appareil doit être en ligne.

1. Ouvrez My Products > Managed Risk > Scans > Internal.
2. Ouvrez le menu à trois points dans la rangée du bon appareil à l’extrême droite.
3. Sélectionnez Remote Assistance.
4. Activez Enable dans la boîte de dialogue.
5. Cochez la case Sophos Group Privacy Notice et sélectionnez Save.
6. Attendez que Sophos Fusion affiche Access ID.
7. Envoyez le Access ID uniquement via le canal d’assistance convenu et uniquement pour le cas concerné.

L’assistance à distance se termine automatiquement après sept jours. Si ce n’est plus nécessaire, désactivez l’option Enable dans la boîte de dialogue Remote Assistance. Si Access ID ne peut pas être obtenu, confirmez d’abord que l’appareil est en ligne ; puis ajoutez l’erreur visible au dossier de support produit existant. Ne redémarrez pas et n’effacez pas l’appliance pour forcer l’assistance à distance.