Examiner et gérer les Findings Sophos ITDR

Dans My Products > Identity > Findings, Sophos ITDR affiche les résultats des contrôles effectués sur l’infrastructure d’identité connectée. Par défaut, le tableau est trié par risque. Un constat ne prouve pas automatiquement une compromission active et ne constitue ni une XDR Detection ni un Case à part entière. ITDR peut regrouper des Findings à haut risque dans des Cases contextualisés ; le constat individuel reste toutefois un élément de travail ITDR qui doit être évalué, traité dans le système d’identité concerné, puis vérifié de nouveau.

La procédure sûre est la suivante :

1. Classer les constats ouverts par Risk et utiliser les filtres pour constituer une file de travail gérable.
2. Lire Finding Details, Description, Definition et Recommendation ; si nécessaire, examiner les données brutes sous Result et les modifications sous History.
3. Évaluer l’impact et les dépendances dans votre environnement avant de modifier une configuration.
4. Corriger la cause dans le système ou le service d’identité concerné, au lieu de simplement modifier le statut ITDR.
5. Valider l’état d’abord chez le fournisseur, puis dans ITDR.
6. Ne définir un constat sur Resolved ou Dismissed qu’à la suite d’une décision réfléchie. Le passer manuellement sur Resolved ne corrige pas le problème.

Interpréter correctement les statuts, les niveaux de risque et les catégories

Statut

ITDR ne considère plus les constats Resolved et Dismissed comme des risques pour l’environnement. Ces statuts restent toutefois distincts sur le plan opérationnel : Resolved correspond à une cause corrigée ou à un risque réduit, tandis que Dismissed correspond à une décision délibérée concernant le risque.

Risque

Le niveau de risque provient du contrôle sous-jacent et facilite la définition des priorités. À niveau égal, examinez d’abord les identités privilégiées exposées, les indices d’identifiants compromis et les constats ayant une large portée. La Recommendation propre au constat reste plus importante qu’une mesure générique.

Catégorie

ITDR utilise les catégories suivantes. Leurs noms restent inchangés dans l’interface Sophos en anglais :

• User Behavior
• Configuration
• Entra Conditional Access Gaps
• Dormant Resources
• Lateral Movement
• Credential Compromise
• Persistence
• Privilege Escalation
• Defense Evasion
• Exfiltration
• VIP Exposure

La catégorie décrit le type de contrôle et peut, le cas échéant, correspondre au modèle MITRE ATT&CK. Elle ne remplace ni l’analyse détaillée ni la vérification du caractère intentionnel d’une configuration observée dans votre environnement.

Filtrer les constats et constituer une file de travail

Le menu de filtres repliable situé à gauche du tableau Identity Findings regroupe les filtres suivants :

• Risk : niveau de risque du constat.
• Status : Open, Resolved ou Dismissed.
• Reference Type : type d’objet concerné.
• Category : catégorie du constat.
• Is New : constats observés pour la première fois au cours des sept derniers jours.
• Affected Provider : fournisseur d’identité pour lequel le Finding a été généré ; Microsoft Entra ID, On-premises Active Directory ou All providers.
• Finding : titre du constat.
• First Seen : date et heure de la première observation.
• Last Seen : date et heure de la dernière observation.
• Last Modified : date et heure de la dernière modification.

Les valeurs exactes disponibles pour Reference Type sont les suivantes :

• User Object
• Application
• Group Object
• Device Object
• Agent Object
• Tenant Configuration
• Unknown

Agent Object limite la liste aux Findings liés aux agents ; cela ne suffit pas à identifier le rôle d’agent concerné. Les détails Directory et NHI distinguent l’identité d’exécution, le Blueprint Principal et l’éventuel compte utilisateur associé, ainsi que les App Owners et les Sponsors. Unknown ne fournit pas une classification d’objet fiable ; l’objet concret doit être identifié dans les détails et Result. Affected Provider aide à choisir le fournisseur responsable pour cette vérification. All providers est un choix de filtre, pas une preuve que le même Finding existe chez les deux fournisseurs.

Les filtres sélectionnés apparaissent au-dessus du tableau. Utilisez X pour supprimer un filtre et Clear All pour les supprimer tous. Le tableau et l’URL sont mis à jour dynamiquement selon la sélection. Vous pouvez donc enregistrer une URL filtrée comme vue de travail ou la partager avec vos collègues. Avant tout partage, vérifiez que les destinataires ont accès au même tenant Sophos Fusion (anciennement Sophos Central) et que l’URL peut figurer dans le ticket prévu.

Une première file de travail utile consiste à choisir Status = Open, puis Risk = Critical ou High. Affinez ensuite les résultats avec Category, Reference Type ou Is New. Les nouveaux risques critiques liés aux identités restent ainsi visibles sans faire disparaître les éléments ouverts plus anciens.

Examiner un constat en détail

Un clic sur le lien de la colonne Findings ouvre le volet de détails. Celui-ci affiche l’objet associé, le risque, First Seen, Last Seen, Last Modified et la recommandation. Utilisez l’icône New Tab pour ouvrir la page complète dans un nouvel onglet.

Le volet et la vue complète contiennent les éléments suivants :

• Finding Details : résumé comprenant le niveau de risque, le statut, les commentaires, les horodatages et les balises.
• Description : description du constat.
• Definition : informations sur le contrôle d’identité associé et ses références.
• Recommendation : recommandation de Sophos pour réduire le risque concerné.

Pour un triage fiable, répondez au minimum aux questions suivantes :

1. Quel objet est concerné et Reference Type correspond-il à l’objet attendu ?
2. La condition décrite dans Description et Definition existe-t-elle toujours chez le fournisseur d’identité ?
3. Quelle est l’étendue des autorisations, des dépendances et des effets possibles d’une modification ?
4. La Recommendation convient-elle à votre environnement et la modification est-elle autorisée en interne ?
5. First Seen, Last Seen et Last Modified indiquent-ils un problème nouveau, récurrent ou déjà traité ?

Finding Details affiche des commentaires et des balises. Toutefois, la documentation de Sophos relative à la page Findings ne décrit ni fonction d’affectation ni commandes permettant de créer ou de modifier ces commentaires et balises. La responsabilité et les preuves des modifications doivent donc être consignées dans le système approuvé de gestion des changements ou des tickets ; les commentaires ne remplacent ni un ticket de changement ni la preuve de la modification dans le système source.

Examiner Result en tant que données brutes

L’onglet Result affiche au format JSON la sortie brute du contrôle exécuté. Il est particulièrement utile lorsque le résumé ne permet pas de déterminer quel attribut, objet ou résultat a conduit à l’évaluation.

Interprétez les clés et les valeurs JSON comme la sortie de ce contrôle précis ; n’en déduisez pas un schéma général. Comparez les identifiants d’objet, les états et les horodatages pertinents avec les informations actuelles du fournisseur d’identité. Les données brutes sensibles ne doivent figurer que dans des tickets ou des notes d’enquête approuvés.

Suivre les modifications avec History

L’onglet History affiche les actions antérieures sur le constat. Sélectionnez View Diff pour ouvrir le détail exact des modifications. Vous pouvez ainsi suivre les changements de statut et les autres étapes de traitement, et distinguer une réouverture inattendue d’un nouveau constat.

Corriger la cause et valider le résultat

⚠️ Vérifier avant d’apporter des modifications : une recommandation Sophos doit être adaptée à votre environnement, à votre tolérance au risque et à votre procédure d’approbation des changements. Les modifications des rôles, de l’authentification, de l’accès conditionnel, des applications ou d’autres objets d’identité peuvent avoir une incidence sur les utilisateurs, les applications et les accès. Clarifiez donc les dépendances et le plan de retour arrière avant la mise en œuvre.

La correction s’effectue dans le système où ITDR a détecté le problème, par exemple le fournisseur d’identité connecté ou le service applicatif concerné. Le statut dans ITDR contrôle uniquement le traitement des constats. Il ne modifie pas la configuration du fournisseur.

Une clôture contrôlée comporte quatre étapes :

1. Vérifier l’état chez le fournisseur : confirmer que la modification autorisée a été enregistrée et qu’elle est effective pour l’objet concerné.
2. Vérifier de nouveau le constat : examiner l’objet associé, Last Seen, Result et History. Un résultat obsolète ou inchangé ne prouve pas la réussite de l’intervention.
3. Attendre le traitement automatique : si le constat n’apparaît plus lors d’un nouveau contrôle, ITDR le résout automatiquement et lui ajoute un commentaire. Les contrôles de posture Entra ID et de ressources inactives s’exécutent généralement toutes les deux heures ; le Risk Posture Score de l’ensemble de l’organisation est mis à jour quotidiennement.
4. Documenter le résultat : consigner les preuves provenant du fournisseur, le statut du constat, l’horodatage et, le cas échéant, View Diff dans le dossier de travail approuvé. Si le constat reste ouvert après l’intervalle de contrôle attendu, comparez de nouveau l’état chez le fournisseur, l’objet concerné et le résultat JSON au lieu de modifier manuellement le statut à plusieurs reprises.

Le système peut repasser sur Open un constat défini manuellement sur Resolved dès qu’ITDR observe de nouveau la même condition. Il ne s’agit pas d’une erreur du modèle de statuts, mais d’une indication que la cause existe toujours, qu’elle est réapparue ou qu’elle reste visible dans les données évaluées par ITDR.

N’utiliser Dismissed que pour une décision réfléchie concernant le risque

⚠️ Dismissed empêche la création d’autres constats : lorsqu’un constat est rejeté, ITDR ne crée plus de nouveaux constats pour ce problème sur l’objet concerné. Le constat reste dans le tableau, mais il est exclu du tableau de bord et du Risk Posture Score de l’ensemble de l’organisation. Un rejet prématuré peut donc masquer dans la vue habituelle un risque toujours présent ou susceptible de redevenir pertinent.

Dismissed ne convient que si la condition est attendue, si sa correction est manifestement impossible ou injustifiable sur le plan opérationnel et si la partie responsable accepte le risque résiduel. Documentez au minimum, en dehors d’ITDR, l’objet, la justification, les contrôles compensatoires, l’approbation et la date de réexamen. Un constat techniquement impossible à résoudre peut aussi rester Open ; le risque demeure alors visible dans le score et dans la surveillance continue.

Donner la priorité à Credential Compromise

Les constats relatifs aux comptes compromis ne sont générés que pour les identités actives. ITDR vérifie notamment si une identité active existe, à quelle date un mot de passe en texte clair ou un hash a été divulgué pour la première fois et si cette date est postérieure au dernier changement du mot de passe. Une valeur en texte clair est également comparée aux exigences globales de complexité des mots de passe de Microsoft Entra ID. Les données brutes peuvent rester visibles sous Dark Web Intelligence, qu’un constat soit généré ou non.

Lorsqu’un constat est généré, ITDR détermine le niveau de risque selon le type de compte, le type de fuite et la robustesse de la MFA :

Pour définir les priorités, traitez d’abord les constats Critical, puis les constats High ; à niveau égal, examinez en priorité les comptes privilégiés et les fuites en texte clair. Une classification inférieure en présence d’une MFA ou d’une MFA résistante au phishing ne signifie pas que le constat peut être ignoré. Appliquez les mesures de protection et de correction approuvées dans le système d’identité concerné et conformément à votre procédure de réponse aux incidents. Validez ensuite l’état chez le fournisseur, le constat et son historique comme décrit plus haut. Le statut ne suffit pas à confirmer qu’une identité est sécurisée.

Distinguer les responsabilités du client, de MDR et de XDR

Sophos ITDR est une solution surveillée par le client. Même si Sophos MDR fait l’objet d’une licence distincte, le triage et la gestion courante des constats restent à la charge du client. Le MDR Operations Team se concentre sur les menaces actives visant les identités et peut intégrer à son enquête certains constats critiques ou à risque élevé s’ils indiquent une menace active. Cela n’entraîne ni la prise en charge automatique de tous les constats ni l’exécution de modifications chez le fournisseur d’identité.

Pour chaque constat transmis à un niveau supérieur, il convient donc d’indiquer clairement :

• qui est responsable du triage et des décisions concernant le risque ;
• qui autorise et exécute les modifications dans le système d’identité ;
• si un indice de menace active a été transmis dans le cadre de la procédure MDR convenue ;
• qui procède à la validation finale de l’effet technique et du statut ITDR.

Les constats ITDR restent des éléments de travail distincts des XDR Detections et du Case qui les regroupe. Le contexte d’identité et les Findings regroupés peuvent contribuer à une enquête plus approfondie. Toutefois, le statut, les commentaires et la clôture d’un constat ITDR individuel ne se confondent pas avec les workflows XDR, Case ou MDR.

Bien situer les Cases et la réponse directe

Sophos décrit le regroupement automatique de Findings à haut risque dans des Cases contextualisés. Ceux-ci établissent les liens entre les identités, les Detections et d’autres facteurs de risque pour l’investigation. Un Case complète les constats individuels ; il ne remplace ni l’examen de leurs onglets Result et History ni la preuve qu’une cause a été corrigée. L’annonce ne permet pas de déduire ici des seuils fixes de regroupement, des chemins de menu pour les Cases, une reprise automatique des statuts ou des interventions automatiques sur les comptes.

Les possibilités de réponse directe depuis ITDR comprennent la réinitialisation des mots de passe et la révocation des sessions actives. Sophos mentionne également l’application de la MFA et la désactivation de comptes. Ces possibilités ne sont pas garanties pour chaque fournisseur ou type d’objet : la réponse technique doit être configurée pour l’environnement concerné. La documentation actuelle sur la réponse décrit à cet effet des connexions, des Actions et des Playbooks, par exemple via le Microsoft Graph API Connector pour Entra ID. La seule intégration de données ITDR ou un capteur AD en lecture seule n’accorde pas de droits d’écriture pour la réponse.

Pour une réponse approuvée, consignez l’identifiant du Finding et, le cas échéant, du Case, l’identité concernée, l’état initial, l’heure et le résultat. Vérifiez ensuite d’abord auprès du fournisseur que la modification prévue est effective, puis contrôlez le même constat dans ITDR. Une réinitialisation de mot de passe ne prouve pas à elle seule la révocation des sessions ; un Case fermé ne prouve pas qu’une correction technique a été effectuée. Ne répétez pas aveuglément les actions échouées ou dont le résultat est incertain : transmettez-les à l’équipe d’administration des identités responsable avec le résultat observé.

Si une réponse automatisée est configurée ultérieurement, son déclencheur doit être examiné séparément : la documentation actuelle recommande Created pour les nouveaux Identity Findings. Updated peut se déclencher plusieurs fois par jour lors des contrôles de posture récurrents et, par exemple, réinitialiser les mots de passe à répétition. Le seul regroupement automatique des Cases ne constitue pas une autorisation d’activer une telle automatisation de réponse.