Examiner le Directory et Identity Details dans Sophos ITDR

Le Directory de Sophos ITDR constitue l’inventaire de travail des identités, groupes, appareils et applications qu’ITDR collecte auprès des fournisseurs d’identité connectés. Les cartes de chiffres clés indiquent le nombre d’objets surveillés ; un clic ouvre la vue correspondante. Pour mener une investigation, il faut passer de cet inventaire global aux données détaillées de l’objet en cliquant sur son nom d’affichage.

Accès rapide : sous My Products > Identity > Directory, commencez par sélectionner le bon onglet, appliquez la recherche et les filtres, puis vérifiez l’origine des données. Pour un utilisateur, ouvrez Display Name, puis vérifiez une hypothèse concrète dans chacune des sections Summary, Activity Log, Findings, Insights, Group Membership et Dark Web Intelligence. Un tag isolé, un Risk Score élevé ou une connexion inhabituelle constitue un signal de priorisation, mais ne prouve pas à lui seul qu’un compte a été compromis.

Clarifier les limites du produit avant l’investigation

Le Directory d’ITDR n’est pas le service d’annuaire de Sophos Fusion (anciennement Sophos Central). Il présente le contexte de sécurité collecté par l’intégration ITDR ou le capteur ITDR. À l’inverse, Global Settings > Platform > Directory service met des utilisateurs et des groupes à la disposition des fonctions et produits Central partagés. Il en découle trois limites importantes :

• Une identité absente du Directory d’ITDR ne réapparaîtra pas à la suite d’une nouvelle synchronisation de l’annuaire Central. Il faut d’abord vérifier l’intégration ITDR, l’inventaire du fournisseur et l’état de sa collecte.
• Un objet du Directory d’ITDR n’est pas automatiquement un utilisateur Central administré et n’implique ni attribution de produit ni installation d’Endpoint.
• Les filtres, les tags et la simple ouverture de pages détaillées dans ITDR ne modifient aucun objet Entra ID, Active Directory, Intune ou d’annuaire Central. Les corrections techniques s’effectuent dans le système de référence, puis sont validées dans ITDR ; indépendamment de cela, des actions de réponse expressément autorisées peuvent être proposées par les points d’entrée Actions prévus à cet effet.

Sophos XDR poursuit également un autre objectif. Le Directory d’ITDR fournit un contexte d’inventaire, de posture et d’identité. Une requête ou une investigation XDR met en corrélation les télémétries et événements issus des sources de données prises en charge. L’Activity Log d’Identity Details n’est donc pas une chronologie XDR complète, et un Finding ITDR n’est pas automatiquement une détection XDR. Pour une investigation de menace couvrant plusieurs dossiers, les indices ITDR confirmés sont mis en corrélation avec les données XDR, Endpoint, Entra et réseau disponibles, sans interpréter une absence de télémétrie comme un résultat normal.

Interpréter correctement l’inventaire du Directory

La page accessible sous My Products > Identity > Directory comporte quatre onglets aux fonctions distinctes :

Les champs de recherche limitent chaque vue en fonction des noms. La recherche et les filtres s’appliquent uniquement aux données affichées et collectées par ITDR. L’absence de résultat ne prouve donc ni que l’objet n’existe pas chez le fournisseur, ni qu’il a été supprimé. Avant toute escalade, vérifiez l’orthographe, l’onglet, les filtres actifs, le tenant du fournisseur et l’heure de la collecte.

Rechercher, trier et filtrer les identités

Identities peut s’afficher sous forme de cartes ou de liste. Par défaut, les utilisateurs sont classés par ordre alphabétique. Le menu de tri permet notamment de sélectionner le Risk Score par ordre décroissant afin d’identifier les identités à examiner en premier. Search Identities filtre les résultats par nom.

Le choix des filtres pertinents dépend de l’investigation. Pour une première priorisation, Status permet de limiter les résultats selon le statut du compte signalé par le fournisseur d’identité, et Risk Severity selon la plage du Risk Score calculé. Is Admin correspond au contexte d’administration défini par le fournisseur ou à partir des rôles privilégiés détectés, Is VIP à la sélection pour VIP Monitoring et Is Compromised à la présence de fuites actives d’identifiants. Is Dormant recherche les comptes pour lesquels aucune connexion n’a été collectée depuis plus de 90 jours.

Pour caractériser le compte, Department et Employee Type fournissent des attributs organisationnels lorsque le fournisseur les transmet. Is Guest identifie un compte invité chez le fournisseur d’identité ; Is Cloud Only, un compte qui existe uniquement chez le fournisseur d’identité cloud et ne possède aucun identifiant local. Le contexte MFA est fourni par Has MFA, Has Passwordless MFA, Primary MFA Method et MFA Method. Country et Region filtrent les attributs géographiques renseignés chez le fournisseur.

Un filtre vide ne constitue pas un résultat négatif. Si le fournisseur ne transmet pas un attribut, si la licence restreint l’accès à l’API ou si Microsoft n’a pas encore fourni les données actualisées, ITDR ne peut pas remplir le champ de manière fiable. Cette limite concerne tout particulièrement les données MFA, d’administration, d’appareils et d’activité.

Dans la vue en cartes, la flèche située au bas de la carte affiche des informations supplémentaires ; une seule carte à la fois peut être développée. Dans la vue en liste, la flèche à gauche développe une ligne. Le menu des colonnes permet d’épingler les colonnes, d’ajuster automatiquement leur taille, de les réinitialiser, d’en ajouter ou d’en supprimer. Ces paramètres d’affichage ne modifient ni l’objet ni son évaluation.

Si des actions de réponse ont été autorisées au préalable, elles sont accessibles pour un utilisateur via Actions dans la carte développée ou la colonne Actions de la vue en liste. La disponibilité d’un point d’entrée ou d’une action dépend du statut de l’identité et de la configuration ; son exécution requiert en outre les droits opérateur nécessaires et le processus d’approbation interne. Les filtres, les tags et l’ouverture des détails demeurent des fonctions distinctes qui ne modifient rien. Après l’exécution d’une action, vérifiez son résultat dans le fournisseur de référence, puis l’état actualisé dans ITDR.

Utiliser les icônes et les tags comme contexte, pas comme verdict

Les icônes désignent les catégories User, MFA User, Deleted User, Locked User, Admin, Guest ou Service. Les tags supplémentaires décrivent différentes propriétés et ne doivent pas être interprétés comme une évaluation globale du risque : Admin signifie que le compte a été reconnu comme administrateur, Guest désigne un invité du tenant, Deleted User un compte supprimé chez le fournisseur et Locked User un compte désactivé.

MFA User indique que la MFA est activée, Compromised signale une fuite active d’identifiants et Dormant Account une identité sans connexion collectée au cours des 90 derniers jours. Cloud Only signifie qu’aucun identifiant local n’est présent ; avec Hybrid, des identifiants locaux existent et sont synchronisés entre le cloud et l’environnement local. Human classe l’identité comme utilisateur humain, tandis que VIP indique la configuration pour VIP Monitoring.

Il ne faut pas confondre Human et Non-Human Identity (NHI). Un compte humain représente une personne. Les NHI comprennent notamment les Service Principals, les applications et les autres identités de machine. Une icône Service fournit ce contexte dans la vue des identités ; les Enterprise Applications locales au tenant sont examinées dans l’onglet Apps. Le fait qu’un nom d’affichage ressemble au nom d’une personne ou d’un service ne constitue pas une classification fiable.

Distinguer Application Object et Service Principal

Un Application Object Microsoft Entra est la définition globale d’une application enregistrée dans son Home Tenant. Il décrit notamment la configuration d’identité de l’application et possède une App ID, également appelée Client ID. Dans le cas d’un Service Principal de type Application, le Service Principal est l’instance locale concrète de cette application dans un tenant donné. Ce type fait référence à l’Application Object et détermine, dans le tenant concerné, ce que l’application est autorisée à faire, qui peut y accéder et à quelles ressources elle peut accéder. Cette correspondance ne s’applique pas à tous les types de Service Principal : un Service Principal de type Managed identity n’a pas d’Application Object associé ; un Service Principal Legacy n’a pas d’enregistrement d’application associé.

L’onglet Apps affiche les Enterprise Applications récupérées par ITDR dans le tenant Entra surveillé, c’est-à-dire des instances locales au tenant liées à des applications, et non une simple deuxième liste des enregistrements d’applications globaux. Il ne faut en conclure ni que tous les types de Service Principal d’Entra y figurent, ni que chaque contexte NHI affiché possède un enregistrement d’application. Une application multitenant peut posséder un Application Object dans le Home Tenant, mais un Service Principal distinct de type Application dans chacun des tenants consommateurs. Il faut donc comparer ensemble le Display Name, le tenant, l’App/Client ID, l’Object ID, l’Owner et les autorisations. Des noms identiques ne désignent pas nécessairement le même objet ; différents Service Principals locaux de ce type peuvent faire référence à la même application globale.

Cliquez sur Display Name pour ouvrir App Details. Examinez-y les métadonnées récupérées par ITDR ainsi que les tableaux consacrés aux Owners de l’application, aux Findings associés et aux autorisations. Toute autorisation inhabituelle doit être validée chez le fournisseur au regard de l’objectif métier prévu, du Publisher, du Consent et de l’Owner responsable. L’affichage du Directory ne révoque aucun Consent et ne supprime aucune autorisation.

Examiner les groupes et les appareils

Sous Groups, quatre filtres permettent de limiter la recherche : Deleted désigne les groupes supprimés chez le fournisseur, Mail Enabled ceux qui peuvent recevoir des e-mails et Security Enabled ceux qui peuvent contrôler l’accès à des ressources. Assignable to Roles identifie les groupes auxquels des rôles peuvent être attribués.

Un clic sur Group Name ouvre Group Details, qui contient les métadonnées de groupe récupérées ainsi que les tableaux des utilisateurs, groupes et applications associés. Lors d’un contrôle d’accès, confirmez le type de groupe, l’Owner, les relations directes et imbriquées ainsi que la nécessité métier auprès du fournisseur de référence. Mail Enabled n’indique pas si un groupe sert à gérer des autorisations ; le critère pertinent à cet égard est Security Enabled.

Sous Devices, vous pouvez rechercher des appareils et les filtrer selon State, Ownership, Operating System, Architecture, Manufacturer, Model, Rooted, Managed et Compliant. Cette vue inclut les appareils personnels et professionnels enregistrés dans Microsoft Entra ID. Un objet appareil est une identité chez le fournisseur ; Microsoft Entra registered, Microsoft Entra joined et Microsoft Entra hybrid joined correspondent à des contextes d’enregistrement ou de jonction distincts et ne signifient pas qu’un Sophos Endpoint Agent est installé.

Cliquez sur Display Name pour ouvrir Device Details. Selon le type d’appareil, la page affiche les métadonnées récupérées, les identités associées, les Findings pertinents et d’autres informations disponibles. Managed, Compliant, Rooted et Ownership sont des informations fournies par le fournisseur. Si elles sont absentes, documentez la valeur comme indisponible ou inconnue pour les besoins de l’investigation. Il ne faut pas en déduire pour autant les états « unmanaged », « non-compliant » ou « not rooted », ni une propriété personnelle ou professionnelle. Une valeur absente ne doit pas non plus être assimilée à une valeur Unknown expressément signalée par le fournisseur.

Examiner méthodiquement Identity Details

Dans Identities, un clic sur Display Name ouvre la page Identity Details. Plutôt que de parcourir chaque onglet sans hypothèse, suivez la méthode ci-dessous :

1. Confirmer l’objet : comparez le nom d’affichage, le statut, le type, les adresses e-mail et le contexte du fournisseur avec l’utilisateur attendu.
2. Comprendre la priorité : examinez le Risk Score, ses facteurs contributifs, les Findings ouverts, Compromised, Admin, ainsi que le contexte MFA et Dormant. Un score permet de hiérarchiser l’investigation, mais ne la remplace pas.
3. Vérifier la cohérence du profil et des assets : comparez le rôle, le service, la région, la structure organisationnelle et les appareils Intune associés avec le profil attendu.
4. Examiner l’activité : définissez la période, puis recherchez les écarts dans les connexions réussies et échouées, les horaires, les pays, les adresses IP et les ASN.
5. Ouvrir les éléments de preuve associés : examinez séparément les Findings, les Detections, les groupes et les données du Dark Web, au lieu de déduire la cause à partir d’un résumé.
6. Valider dans le système de référence : contrôlez les informations dans Entra ID, l’AD local, Intune et, le cas échéant, la télémétrie XDR. Effectuez ensuite les modifications techniques dans le système de référence concerné. Si une réponse ITDR expressément approuvée est prévue à la place, utilisez un point d’entrée Actions disponible.
7. Actualiser le résultat : après la correction ou la réponse, contrôlez de nouveau le résultat chez le fournisseur et dans ITDR, puis documentez quel affichage a déjà été mis à jour et lequel attend encore le prochain cycle de collecte.

Summary

Summary réunit le profil, la priorité et l’activité récente. Sous Details figurent les informations Entra ID disponibles, telles que le rôle, le service, le statut, le pays et la région, les dates de création et de modification, la dernière modification du mot de passe ainsi que les autres adresses e-mail associées. Assets présente les appareils Intune associés à l’utilisateur dans Entra ID. Multi-Factor Authentication indique le fournisseur MFA, la méthode MFA principale et les autres types de MFA configurés. Organization fournit le contexte organisationnel avec les responsables, les collaborateurs directs et la structure de l’organisation ; un clic sur une personne l’ouvre dans un nouvel onglet.

Pour l’évaluation de sécurité, Recent Detections affiche les Open Detections des sept derniers jours et les Closed Detections des 30 derniers jours ; View All mène à Insights. Risk Score contient le score actuel et ses principaux facteurs contributifs. Top Sign-in Locations résume les lieux de connexion les plus fréquents en distinguant l’activité des adresses IP publiques et privées. Lorsque des données sont disponibles, Commonly Used Entities ventile les authentifications réussies des 30 derniers jours selon IP Addresses, Browser, Asset Name et OS Version.

Sous Top Sign-in Locations > View Details, les informations relatives aux 30 derniers jours comprennent notamment le lieu géographique, l’ASN et la fréquence des principales adresses IP. IP type et Login outcome servent alors de filtres ; ils ne sont pas nécessairement affichés comme colonnes de résultats. Les adresses IP privées ne doivent pas être interprétées géographiquement comme les adresses publiques. Une ville fréquente peut résulter d’une sortie VPN ou cloud ; un pays inconnu peut justifier une vérification, mais ne constitue pas encore un incident en l’absence de contexte temporel, matériel et fournisseur.

Activity Log

Activity Log affiche l’activité d’authentification pour la période sélectionnée en haut à droite. Total Activities, Successful Logins et Failed Logins fournissent d’abord les volumes. Pour le contexte géographique, Top sign-in locations présente les pays, les adresses IP, leur nombre et la répartition entre adresses IP publiques et privées. Authentication locations complète ces données avec les authentifications les plus fréquentes des 30 derniers jours, classées par adresse IP et ASN, ainsi qu’une recherche par lieu, IP ou ASN. Logins per day, avec une distinction entre connexions réussies et échouées, et l’Activity map, sous forme de carte thermique par jour de la semaine et heure de la journée, représentent l’évolution temporelle.

Cette vue ITDR résume des agrégats et des tendances. Elle ne présente pas un tableau d’événements réunissant toutes ces informations pour chaque connexion. Browser, Asset Name et OS Version doivent plutôt être évalués comme des agrégats de profil sur 30 jours portant sur les authentifications réussies sous Summary > Commonly Used Entities et ne doivent pas être attribués à une entrée particulière de l’Activity Log. Pour corréler des événements selon l’heure exacte et le fuseau horaire, le résultat, l’adresse IP source, l’ASN, le pays, l’appareil, le navigateur, le système d’exploitation ou les Detections voisines, consultez les journaux d’événements Entra ou XDR disponibles. Des échecs fréquents dans les agrégats ITDR peuvent correspondre à des erreurs utilisateur, à des identifiants obsolètes ou à une attaque ; seule la corrélation avec les preuves événementielles permet de trancher.

Findings, Insights, Group Membership et Dark Web Intelligence

Findings répertorie les Findings de cette identité en fonction du risque. Le texte intégral de Recommendation apparaît au survol ; un clic sur le nom du Finding ouvre ses détails. Vérifiez alors le statut, le risque, la catégorie, les éléments de preuve concernés et la correction recommandée. La modification manuelle d’un statut n’équivaut pas à la correction technique chez le fournisseur.

Par défaut, Insights présente les Open Detections des sept derniers jours ; la période peut être modifiée au moyen du Date Picker. Closed Detections couvre les 30 derniers jours. Une période par défaut vide n’exclut donc pas une activité plus ancienne.

Group Membership répertorie les groupes de l’utilisateur. Le champ de recherche limite la liste ; un clic sur Group Name ouvre le groupe et ses autres membres. Les appartenances privilégiées, assignables à des rôles, imbriquées, inattendues ou qui ne répondent plus à un besoin métier sont particulièrement importantes. Les modifications s’effectuent chez le fournisseur de référence.

Dark Web Intelligence affiche les données de fuite associées à l’identité. Ouvrez l’enregistrement concerné via Breach Source. Un enregistrement documente la divulgation d’identifiants. Pour l’évaluer, examinez conjointement la date de la fuite, le contexte de publication ou de compromission, le statut du compte et la date de la dernière modification du mot de passe. Cet enregistrement ne prouve pas automatiquement que les identifiants actuellement utilisés sont valides ni qu’une connexion a eu lieu.

Tenir compte des limites des fournisseurs et des délais d’actualisation

Sophos ITDR prend en charge Microsoft Entra ID et l’Active Directory local, mais tous les fournisseurs ne transmettent pas les mêmes objets et champs. Des données propres au cloud, telles que les assets Intune, les Service Principals Entra, les méthodes MFA ou l’activité de connexion Entra, peuvent manquer dans une intégration exclusivement fondée sur un AD local. À l’inverse, le capteur ITDR local collecte d’autres types d’objets AD pour les contrôles de posture, ce qui ne rend pas automatiquement les onglets cloud exhaustifs.

Après la collecte initiale complète d’Entra, ITDR vérifie les mises à jour à des intervalles différents selon le type de données : les détails des utilisateurs, Service Principals, applications, groupes et appareils environ toutes les dix minutes, la configuration MFA environ toutes les 15 minutes, la dernière connexion des utilisateurs environ toutes les six heures et les données des domaines environ toutes les 24 heures. Il s’agit d’intervalles de collecte, et non d’une garantie que Microsoft fournisse déjà une information source modifiée par son API.

Entra ID P1 ou P2 est requis pour l’étendue de données prévue dans ITDR. Avec Entra ID Free, les API et les contrôles de posture sont limités ; une intégration peut donc afficher Provisioning Failed. Après une mise à niveau de licence, les informations d’administration ou de MFA peuvent rester obsolètes chez Microsoft pendant une semaine au maximum. Dans ce cas, vérifiez d’abord le rapport d’activité Microsoft Entra correspondant. Si l’affichage du fournisseur lui-même n’est pas encore actualisé, ITDR ne peut pas présenter un état plus récent.

Une MFA tierce dans une ancienne configuration Okta ou Duo peut également être signalée comme non protégée, car Entra n’enregistre pas les informations MFA au niveau de l’utilisateur. Une valeur Has MFA = false ne doit donc pas être considérée isolément comme la preuve de l’absence de contrôle MFA. La configuration du fournisseur, Conditional Access, les External Authentication Methods actuelles et un test de connexion contrôlé doivent être cohérents.

Validation et résolution des problèmes

L’objet est absent ou apparaît dans le mauvais onglet

1. Réinitialisez la recherche et les filtres actifs, puis vérifiez l’orthographe et les autres noms d’affichage possibles.
2. Vérifiez si Identities, Groups, Devices ou Apps correspond bien au type d’objet recherché.
3. Confirmez le tenant et le fournisseur d’identité de référence ; pour les applications, distinguez Application Object, Service Principal, App/Client ID et Object ID.
4. Recherchez directement l’objet chez le fournisseur et vérifiez son statut, sa suppression et son contexte Guest, Cloud, Hybrid ou Service.
5. Dans les paramètres de l’intégration ITDR, vérifiez l’état et la dernière collecte réussie. Ne relancez pas Central Directory Sync à la place.
6. Attendez la fin de la fenêtre de collecte propre au type de données avant de vérifier de nouveau, puis documentez les horaires.

Un filtre ou un champ MFA, d’administration ou d’appareil est vide ou inattendu

• Supprimez les filtres et vérifiez l’attribut brut chez le fournisseur.
• Contrôlez la licence Entra, la disponibilité de l’API et l’état de l’intégration.
• Pour la MFA, vérifiez également le fournisseur, la méthode principale, les autres méthodes et la configuration tierce.
• Pour les appareils, distinguez l’enregistrement ou la jonction, la gestion Intune, la conformité et la protection Sophos Endpoint.
• Après une modification de licence ou d’attribut, ne validez pas uniquement ITDR : vérifiez d’abord l’affichage actualisé du fournisseur.
• Documentez « vide », No data ou un tag absent comme une valeur inconnue, et non comme « non ».

Un lieu de connexion ou une tendance d’activité paraît suspect

Dans l’Activity Log, commencez par comparer la période, le volume de connexions, les agrégats de réussite et d’échec, les pays, les adresses IP, les ASN ainsi que les tendances selon le jour et l’heure. Sous Top Sign-in Locations, IP type et Login outcome peuvent servir de filtres.

Évaluez séparément Browser, Asset Name et OS Version sous Commonly Used Entities, en tant qu’agrégats sur 30 jours. Mettez ensuite en corrélation, dans les journaux d’événements Entra ou XDR disponibles, l’heure exacte et le fuseau horaire ainsi que le résultat, l’appareil, le navigateur et le système d’exploitation d’une connexion donnée. Examinez également les Findings et Insights associés.

Le NAT, les VPN, les réseaux mobiles, les sorties cloud et les déplacements peuvent modifier le lieu affiché. Si le risque est confirmé, n’exécutez les mesures de réponse que conformément au processus interne de gestion des incidents et avec les autorisations requises.

Vérifier l’affichage après une correction

Confirmez d’abord la modification technique dans le système de référence. Attendez ensuite l’heure de collecte ITDR prévue, réinitialisez les filtres, puis rouvrez la même identité ou le même objet. Vérifiez le champ corrigé, les tags dépendants, les Findings associés et la période d’investigation pertinente. Le Risk Score, les Findings et les attributs du fournisseur peuvent suivre des cycles d’actualisation différents ; un score encore inchangé ne réfute pas la réussite de la modification à la source. Si l’affichage reste incorrect au-delà de la fenêtre attendue, conservez, en vue de l’escalade, la preuve issue du fournisseur, le tenant, l’Object ID, l’heure de la modification, l’état de l’intégration et des captures d’écran.

Clore l’investigation de manière traçable

Pour terminer, documentez l’objet, le tenant, le fournisseur et le type d’identité. Consignez également la recherche et les filtres utilisés, la période d’investigation, les sections détaillées contrôlées, les données manquantes du fournisseur ainsi que les résultats de la validation dans le système de référence et dans ITDR. Le contexte Human et NHI, de même que l’Application Object et le Service Principal, doivent rester clairement distincts.