Évaluer l’Identity Risk Score de Sophos ITDR en toute sécurité

L’Identity Risk Score évalue le risque d’une identité utilisateur sur une échelle de 0 à 10. Il combine la probabilité d’un incident de sécurité et l’impact potentiel d’une identité compromise. Une valeur élevée constitue donc un signal de priorité, mais ni une preuve de compromission ni une consigne automatique d’intervention.

Pour le tri quotidien, classez les identités par Risk Score décroissant, examinez les Contributing factors des premières identités, puis traitez en priorité les findings critiques ou élevés encore ouverts et les Security Factors directement maîtrisables. La valeur numérique ne suffit pas à prendre une décision éclairée.

Où trouver le Risk Score

Sophos ITDR affiche la valeur en trois endroits :

• Sous My Products > Identity > Directory > Identities, la table contient la colonne Risk Score. Dans la vue carte, la valeur apparaît en haut à droite de chaque carte.
• Après avoir sélectionné une identité, Identity Details > Summary affiche le panneau Risk Score avec Current score, Contributing factors et l’heure du dernier calcul.
• Sous My Products > Identity > Identity Overview, le widget Top 5 Risky Users associe les scores élevés aux findings ouverts. Chaque entrée indique le nom de l’identité, les findings ouverts par niveau de gravité et le score actuel.

Pour une vérification complète, utilisez Directory > Identities > Identity Details > Summary. Le widget de vue d’ensemble facilite une première hiérarchisation, mais ne remplace pas la vue détaillée.

Interpréter correctement les cinq bandes de scores

Les limites des bandes sont fixes, mais la pondération des facteurs ne l’est pas. Il est donc impossible de calculer un score exact à partir d’une liste d’attributs. Deux utilisateurs exerçant la même fonction peuvent obtenir des valeurs différentes selon leur statut MFA, leurs rôles administratifs, leur statut d’invité, leurs findings, leur lieu de connexion ou leur historique d’alertes et d’investigations.

Un score faible n’est pas non plus une garantie de sécurité. Il reflète la façon dont le modèle évalue les signaux actuellement disponibles. Une télémétrie manquante, une baseline incomplète ou un finding découvert ultérieurement peuvent modifier la classification.

Quelles identités reçoivent un score

Les Risk Scores sont actuellement calculés pour les identités utilisateur Active provenant de Microsoft Entra ID et d’Active Directory local. Aucun Risk Score n’apparaît pour les identités dont le statut chez le fournisseur d’identité est Deleted ou Disabled. Le score exclut actuellement les identités d’application et les principaux de service.

Ce périmètre est important lors des comparaisons : une identité sans valeur n’est pas automatiquement peu risquée. Vérifiez d’abord son type et son statut auprès du fournisseur d’identité connecté. L’absence de valeur ne constitue un indice de diagnostic que s’il s’agit d’une identité utilisateur active.

Distinction entre Security Factors et Profile Factors

Le panneau Contributing factors distingue deux effets :

• Factors raising Risk Score montre des facteurs qui augmentent la valeur actuelle.
• Factors lowering Risk Score montre des facteurs qui la réduisent.

Au sein des deux groupes, Sophos distingue Security Factors et Profile Factors.

Security Factors : intervenez en priorité

Les Security Factors décrivent l’état de sécurité, la configuration et l’activité connue. Les facteurs directement modifiables comprennent :

• absence de MFA ;
• MFA sans méthode sans mot de passe ;
• findings ouverts, désignés dans le panneau par Identity Exposures ;
• rôles d’annuaire administratifs ou privilégiés ;
• statut d’invité ;
• fuites d’identifiants actives ;
• un grand nombre d’adresses e-mail liées.

D’autres signaux comprennent un compte hybride synchronisé depuis un annuaire local ainsi que l’historique des alertes et des investigations. Aucun de ces deux signaux ne peut être éliminé par une simple modification de l’identité : le statut hybride décrit l’architecture de l’annuaire, tandis que l’historique retrace les alertes et investigations antérieures.

Les facteurs qui réduisent le score comprennent l’application de la MFA, une méthode MFA sans mot de passe, un historique sans alerte ou enquête pertinente, les findings corrigés ou marqués Dismissed, la suppression des rôles administratifs inutiles et la réduction du nombre d’adresses e-mail liées. Le modèle pondère ces signaux ; cette liste n’est pas un barème de points additifs.

Profile Factors : du contexte, pas un objectif de correction

Profile Factors se rapportent à des attributs d’identité, par exemple :

• Department;
• Job Title;
• City;
• Employee Type;
• présence ou absence d’un responsable ;
• surveillance VIP, visible dans le panneau sous la forme High-value identity, prioritize monitoring.

Ces caractéristiques peuvent augmenter ou diminuer le score, mais ne constituent généralement pas une mauvaise configuration de sécurité. Le service, la fonction ou le lieu ne doivent pas être modifiés dans le seul but de réduire un chiffre. Corrigez les données de référence erronées ou obsolètes ; conservez les données de profil exactes, qui servent de contexte de risque.

Les champs vides tels que Department, Employee Type ou Job Title ne sont pas nécessairement neutres. Le modèle peut interpréter les informations manquantes en s’appuyant sur des identités similaires et en déduire un contexte de risque. Des données d’annuaire complètes et exactes fournissent donc un contexte plus précis, sans garantir un score particulier ni le sens de son évolution.

Selon Sophos, les fuites d’identifiants actives, le statut hybride et la surveillance VIP peuvent augmenter le score, mais ne contribuent pas à le réduire. Cela ne signifie pas qu’il faut supprimer la surveillance VIP : cette étiquette rend volontairement une identité sensible plus visible et ne doit pas être retirée uniquement pour améliorer le score.

Que signifie No data

Si une section du panneau Risk Score affiche No data, aucun facteur n’est répertorié dans cette catégorie précise. Cela ne signifie pas automatiquement qu’aucune donnée n’existe pour l’identité dans son ensemble ni que l’intégration est défaillante.

Vérifiez donc les points suivants, dans l’ordre :

1. No data apparaît-il uniquement dans une sous-section, par exemple celle des Profile Factors qui réduisent le score ?
2. Y a-t-il des facteurs dans les autres groupes ?
3. L’heure du dernier calcul affichée au bas du panneau est-elle plausible ?
4. L’identité est-elle une identité utilisateur active ?
5. Les attributs d’annuaire et les findings attendus figurent-ils aux emplacements prévus ?

Ne vérifiez la transmission des données de l’intégration que si plusieurs sections attendues sont absentes, si l’heure du calcul est invraisemblable ou si une identité utilisateur active ne reçoit aucun score.

Tenir compte de la baseline et des cycles de calcul

Pour un nouveau tenant ou une identité utilisateur récemment ajoutée, ITDR commence par établir un profil comportemental. De nombreuses nouvelles identités peuvent donc rester dans la bande Informational jusqu’à 30 jours. Il s’agit d’une possible phase d’établissement de la baseline, et non d’un délai pendant lequel les findings peuvent être ignorés : des findings ouverts peuvent augmenter le score même pour une nouvelle identité.

Les scores sont soumis à un cycle d’évaluation quotidien. Un nouveau calcul peut également avoir lieu lorsque ITDR détecte une modification du compte ou d’un finding. Un score peut évoluer d’un jour à l’autre sans changement visible dans l’annuaire, car le modèle tient compte de l’historique des alertes et des investigations et fait évoluer leur pondération dans le temps.

Après la correction d’un finding, une valeur actualisée peut apparaître rapidement. Les findings corrigés continuent toutefois d’influer sur le score avec une pondération réduite jusqu’au cycle quotidien suivant ; leur effet complet n’est donc visible que dans le score du lendemain. Ces deux mécanismes ne permettent de garantir ni une heure précise de mise à jour ni une variation exacte du nombre de points.

Limites du modèle ML

Le Risk Score provient d’un modèle d’apprentissage automatique, et non d’une liste de contrôle fixe. Les facteurs ne sont pas pondérés de façon égale, de sorte que les mêmes facteurs visibles ne produisent pas nécessairement le même score ou le même changement pour deux identités.

Selon Sophos, le modèle est entraîné sur des signaux agrégés de comportement et de compte issus de la clientèle ITDR ; le score d’une identité est calculé à partir des données actuelles de son propre tenant. Des limites opérationnelles claires subsistent néanmoins :

• Le score indique une priorité, pas la cause d’un incident. Pour établir cette cause, il faut examiner les findings et les résultats d’investigations complémentaires.
• Une valeur élevée ne prouve pas une compromission. Une identité privilégiée dont la posture est faible peut être classée à haut risque même sans activité suspecte observée.
• Une valeur faible ne prouve pas l’absence de risque.
• Les facteurs affichés sont l’explication opérationnelle de cette identité, mais pas une formule à partir de laquelle la valeur numérique peut être reproduite.
• Un changement de score ne prouve pas à lui seul qu’une mesure a été techniquement réussie.

L’approche sûre consiste donc à identifier la cause dans le panneau, à vérifier séparément la configuration ou le finding sous-jacent, puis à utiliser le score comme indicateur complémentaire de l’effet obtenu.

Hiérarchiser les identités en toute sécurité

Un tri fondé uniquement sur la valeur numérique la plus élevée peut masquer un contexte important. Suivez cette procédure :

1. Sous Directory > Identities, triez par Risk Score dans l’ordre décroissant.
2. Ouvrez Identity Details > Summary pour les identités les mieux classées.
3. Sous Contributing factors, vérifiez si des Identity Exposures critiques ou élevées sont ouvertes.
4. Donnez la priorité aux findings critiques ou élevés et aux fuites d’identifiants actives plutôt qu’au seul contexte du profil.
5. À niveau d’urgence égal, examinez d’abord les identités privilégiées, administratives et surveillées comme VIP en raison de leur impact potentiel.
6. Pour chaque mesure, consignez la valeur initiale, la bande, l’horodatage et le facteur précis qui augmente le score.
7. Corrigez uniquement la cause sous-jacente ; ne cherchez pas à améliorer artificiellement le score.

Les mesures sûres habituelles consistent à corriger la cause des findings critiques et élevés, à imposer la MFA et, si possible, à proposer une méthode MFA sans mot de passe. Traitez les fuites d’identifiants actives selon le processus d’incident approuvé. Révoquez les rôles administratifs inutiles et supprimez les adresses e-mail liées devenues superflues ; le cas échéant, convertissez les comptes invités en comptes gérés. Chaque modification exige les validations habituelles de votre organisation et un contrôle fonctionnel distinct.

Valider l’effet après une mesure

Un contrôle robuste sépare l’efficacité technique de la réponse du modèle :

1. Consigner l’état initial : Notez l’identité, Current score, la bande, Factors raising Risk Score, les findings ouverts et l’horodatage du dernier calcul.
2. Corriger la cause : Par exemple, imposez effectivement la MFA chez le fournisseur d’identité ou retirez un rôle inutile après validation. Ne modifiez pas plusieurs facteurs indépendants simultanément si l’effet doit rester traçable.
3. Vérifier l’état technique : Contrôlez dans le système concerné que la modification est effective. Le Risk Score n’en est pas la preuve principale.
4. Vérifier les données ITDR : Dans Identity Details > Summary, confirmez que le facteur ou le finding concerné s’affiche correctement après traitement.
5. Attendre le recalcul : Vérifiez l’horodatage au bas du panneau. Après avoir corrigé un finding, contrôlez la mise à jour à court terme et attendez le cycle quotidien suivant pour en évaluer l’effet complet.
6. Comparer le résultat : Comparez le score, la bande et les facteurs à l’état initial. Attendez-vous à une représentation cohérente de la cause corrigée, et non à un score prédéterminé.
7. Traiter les causes restantes : Si la valeur demeure élevée, examinez les autres Security Factors, les findings ouverts, puis le contexte du profil.

La validation est terminée lorsque trois points sont confirmés : la mesure technique est efficace, ITDR affiche correctement le facteur sous-jacent et le calcul du score suivant est plausible au regard des signaux restants.

Dépannage des scores inattendus

Le score augmente brusquement

Ouvrez d’abord la vue détaillée et recherchez sous Factors raising Risk Score de nouvelles Identity Exposures, notamment des findings critiques ou élevés. Comparez ensuite la MFA, les rôles, le statut d’invité, les fuites d’identifiants et l’heure du calcul. Une hausse ne prouve pas un incident, mais une bande critique ou élevée exige une enquête rapide.

Le score ne diminue pas comme prévu après la correction

Vérifiez que le changement est effectivement efficace chez le fournisseur d’identité pertinent et que ITDR montre déjà le facteur mis à jour. Un finding corrigé peut conserver une pondération résiduelle réduite jusqu’au cycle quotidien suivant. Si le score reste ensuite élevé, examinez les autres facteurs ; n’attendez pas une baisse fixe du nombre de points à la suite d’une seule mesure.

Le score change sans changer le répertoire

Ce n’est pas nécessairement une erreur. Le recalcul quotidien, ainsi que l’ajout ou le vieillissement des alertes et investigations, peuvent modifier la valeur. Consignez l’ancien et le nouveau score, les deux heures de calcul et les facteurs affichés. N’examinez plus avant l’intégration qu’en cas de données contradictoires ou d’horodatage invraisemblable.

Une identité utilisateur active n’a pas de score

Commencez par confirmer auprès du fournisseur d’identité le statut Active, le type d’identité User et le rattachement à la source Entra ID ou Active Directory connectée. Vérifiez ensuite si d’autres attributs actuels de cette identité apparaissent dans ITDR. Les identités Deleted ou Disabled, les applications et les principaux de service sont exclus du périmètre actuel du score.

De nombreuses nouvelles identités demeurent Informational

Vérifiez la date d’intégration et les findings ouverts. Cette situation peut être normale pendant la phase de baseline, qui peut durer jusqu’à 30 jours. Les findings ouverts doivent néanmoins être traités immédiatement. Si de nombreuses identités restent dans la bande Informational après 30 jours, vérifiez l’heure du calcul, les facteurs affichés et l’actualité des données afin de déterminer si ITDR traite les signaux attendus.

Si un état inattendu reste inexpliqué, consignez l’identifiant de l’identité sans données personnelles supplémentaires inutiles, sa source, son statut, son score, sa bande, les facteurs visibles, l’heure du calcul, les ID de finding pertinents et l’heure de la dernière modification approuvée. Ces informations permettent une escalade ciblée sans déduire du score lui-même une cause non établie.