Aller au contenu
Avanet

Examiner et gérer les constats 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 XDR Case. Il s’agit d’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

StatutSignification
OpenLe constat n’a pas encore été traité ou la condition existe toujours dans l’environnement. Les nouveaux constats commencent avec ce statut.
ResolvedLe constat a été traité ou le risque a été réduit. ITDR peut également attribuer automatiquement ce statut aux constats qui ne se produisent plus.
DismissedLa condition est attendue dans le contexte évalué et ne sera pas corrigée.

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

RisqueSignification pour le triage
CriticalRisque important ; à traiter immédiatement.
HighÀ traiter immédiatement.
MediumÀ traiter, même si la classification n’indique pas de risque important.
LowRisque faible.
InfoRisque faible ou nul ; à vérifier si le temps le permet.

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.
  • 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
  • Tenant Configuration

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 :

Type de compteType de mot de passeSans MFAMFA activéeMFA résistante au phishing activée
Admin AccountplaintextCriticalHighMedium
Admin AccounthashHighMediumLow
Non-admin AccountplaintextHighMediumLow
Non-admin AccounthashMediumLowLow

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 distincts des XDR Detections et des XDR Cases. Le contexte d’identité peut contribuer à une enquête plus approfondie. Toutefois, le statut, les commentaires et la clôture du constat ITDR relèvent toujours du flux de travail ITDR et ne se confondent pas avec le flux de travail XDR ou MDR.