Examiner et corriger les alertes Sophos ITDR Dark Web Intelligence

Dark Web Intelligence affiche les enregistrements de fuites que Sophos a collectés pour les domaines configurés. L’objectif de ce runbook n’est pas d’assimiler chaque résultat à un accès actuel au compte. Vérifiez d’abord l’identité, le contexte temporel, le type de mot de passe et le statut de la fuite. N’intervenez ensuite que selon le processus approuvé pour l’identité réellement associée.

Les Credential Leaks Active augmentent le Risk Score d’une identité. Les enregistrements historiques restent toutefois visibles, même lorsqu’ils sont inactifs. Le tableau sert donc à la fois de vue de travail des risques actuels et de preuve des découvertes antérieures.

Flux rapide

1. Ouvrez My Products > Identity > Dark Web Intelligence et documentez les filtres par défaut.
2. Priorisez un enregistrement actif et enregistrez Source, identité liée, type de mot de passe et Publish Date, Leaked Date et Breach Date.
3. Vérifiez pourquoi l’enregistrement est Active ; n’assimilez pas chaque ligne à un compte ou à un mot de passe unique.
4. Pour un Finding associé, comparez la gravité affichée à la matrice selon le type de compte, le type de mot de passe et la robustesse de la MFA.
5. Confirmez la responsabilité et l’approbation. Ce n’est qu’ensuite que vous devez exécuter la réponse appropriée déjà autorisée.
6. Remédiez aux identifiants dans l’Identity Provider responsable selon le processus approuvé. Ne substituez pas le statut du Finding ou de la fuite à cette remédiation.
7. Après au moins un cycle de 15 minutes, réexaminez le statut, le Finding et le Risk Score, puis documentez les preuves.

Vues et filtres par défaut

Entrée directe

My Products > Identity > Dark Web Intelligence

Lors de l’ouverture directe de cette page, le tableau est filtré sur le statut de fuite Active et le statut d’identité Active. Avant d’examiner, enregistrez une capture d’écran ou notez les filtres actifs. Une vue par défaut vide ne prouve pas qu’il n’y a pas de données de fuite historiques ; pour cette vérification, élargissez volontairement les filtres de statut.

Accès via Identity Overview

Identity Overview > Credential Leaks

Cliquer sur une métrique dans le widget Credential Leaks ouvre Dark Web Intelligence avec une vue correspondant à cette métrique :

Breached Email Accounts et Unique Passwords Breached sont des métriques agrégées calculées sur les données sous-jacentes. Aucun filtre supplémentaire du tableau ne reproduit entièrement leur logique de déduplication. Il est donc impossible de reconstituer exactement ces métriques à partir des lignes affichées après le clic.

Interpréter correctement les métriques

Les métriques affichées en haut de Dark Web Intelligence se rapportent aux fuites actives :

Ces valeurs utilisent différentes unités : sources, enregistrements de fuites, comptes et mots de passe uniques. Elles ne peuvent pas être additionnées ou validées simplement en comptant les lignes du tableau.

Examiner un enregistrement de fuite

1. Définir la portée

Tout d’abord, notez les filtres et le tri. Pour le premier triage, au moins ces caractéristiques sont pertinentes :

• Statut de la fuite Active ou Inactive
• Statut d’identité et identité liée
• Plaintext ou Hashed
• Admin, non-admin ou contexte VIP, si indiqué
• Source
• Publish Date, Leaked Date et Breach Date
• Finding associé, si présent

Ne définissez pas les priorités d’après le seul horodatage le plus récent du tableau. Un enregistrement doté d’une nouvelle Publish Date peut contenir des données plus anciennes, notamment dans le cas des combolists.

2. Ouvrir les détails

Cliquez sur le champ Source. Le panneau de détails affiche des informations supplémentaires sur la fuite et, si disponible, l’identité liée. Avant de répondre, la ligne du tableau et le panneau de détails doivent se référer à la même source et à la même identité.

Si aucune identité n’est attribuée, l’enregistrement reste pertinent pour l’enquête historique, mais est considéré comme inactif. Actions est désactivé dans ce cas. N’attribuez pas d’identité sur la base d’une supposition et n’intervenez pas sur un compte portant un nom similaire.

3. Distinguer les champs de date

Publish Date

Le moment où Sophos a découvert pour la première fois l’enregistrement de fuite dans les données qu’il a analysées. Il ne fait référence ni au moment de la disponibilité publique ni nécessairement au moment de l’incident.

Leaked Date

La date à laquelle l’ensemble de données est devenu public. Cette date est comparée à la dernière modification du mot de passe afin d’évaluer si le risque lié aux identifiants est actuel.

Breach Date

Le moment où la violation sous-jacente s’est produite. Il fournit le contexte de l’incident, mais peut être indisponible.

L’absence de Breach Date ne fait pas de Leaked Date le moment confirmé de la violation. De même, une nouvelle Publish Date ne prouve pas que le mot de passe a été compromis récemment. Pour la logique de statut, il est crucial de savoir si le dernier changement de mot de passe a eu lieu avant ou après le premier moment de fuite pertinent.

4. Interpréter les doublons et les combolists

La même personne peut apparaître dans plusieurs lignes d’une même source. Les raisons courantes incluent :

• la personne apparaît plusieurs fois dans l’ensemble de données original ;
• le même contenu a été détecté dans une source générique telle qu’une combolist ;
• d’anciennes données divulguées deviennent à nouveau visibles dans une collection trouvée ultérieurement.

Plusieurs lignes n’indiquent donc pas automatiquement plusieurs comptes compromis ni plusieurs compromissions de mot de passe en cours. Comparez la source, la date, le type de mot de passe et l’identité liée pour chaque ligne. Les métriques Emails et Unique Passwords appliquent une logique de déduplication ; les lignes du tableau ne sont pas dédupliquées de la même manière.

Quand une fuite est Active ou Inactive

Une fuite est Active si les deux conditions sont remplies :

1. L’enregistrement peut être lié à une identité active dans un Identity Provider configuré.
2. Le dernier changement de mot de passe du compte associé est antérieur au premier moment de fuite.

Active désigne donc un risque lié aux identifiants qui reste pertinent. Le statut seul ne prouve pas une connexion réussie par un tiers ni une attaque en cours.

Une fuite est Inactive si au moins l’un des scénarios documentés s’applique :

• Il n’y a aucune identité correspondante dans les Identity Providers configurés.
• Le changement de mot de passe le plus récent est après le moment de la fuite.
• Le mot de passe du compte a été changé récemment.
• Le compte a été désactivé ou supprimé.
• Un Finding associé a reçu le statut Resolved ou Dismissed.

Les données historiques relatives aux domaines surveillés continuent d’être collectées et conservées. Un jeu de données inactif n’est donc ni erroné ni sans intérêt du seul fait de son ancienneté. Il peut expliquer pourquoi la même personne ou source apparaît plusieurs fois.

Quand un Finding est créé

Sophos décrit le traitement suivant pour les Findings de compromission de compte :

1. Sophos vérifie si une identité active existe dans les Identity Providers configurés.
2. Sophos détermine à partir des données historiques disponibles quand la valeur en texte clair ou le hachage a été divulgué pour la première fois. Cela vise à reconnaître le contenu ancien dans de nouvelles listes de combinaisons.
3. Pour une valeur en texte clair, Sophos la compare aux exigences globales de complexité des mots de passe de Microsoft Entra ID afin d’écarter les valeurs non valides.
4. Sophos compare le premier moment de fuite du mot de passe avec le dernier changement de mot de passe. Si la première fuite est postérieure à ce changement, Sophos crée un Finding.

Les Findings sont créés uniquement pour les identités actives. Les données brutes restent visibles sur Dark Web Intelligence même si aucune identité active n’est liée.

Matrice de gravité pour la compromission de compte

Selon Sophos, la gravité du Finding dépend du type de compte, du type de mot de passe et de la robustesse de l’authentification multifacteur (MFA) :

La matrice priorise le travail, mais ne remplace pas une évaluation du cas individuel. En particulier pour les comptes administrateur, l’association réelle du compte doit être confirmée avant toute intervention. Un niveau de gravité inférieur ne signifie pas qu’aucune correction n’est nécessaire.

Gestion des valeurs de mot de passe

Sophos déclare ne stocker ni les mots de passe en clair ni les valeurs de hachage. Sophos affirme également ne pas pouvoir collecter ces valeurs depuis les Identity Providers. Lors de la collecte, Sophos applique son propre hachage aux valeurs observées, puis classe l’enregistrement comme Plaintext ou Hashed. Selon Sophos, cette méthode permet de déterminer des valeurs uniques et des indicateurs dérivés sans conserver la valeur de mot de passe sous-jacente.

Opérationnellement, cela signifie :

• Plaintext décrit le type de contenu de fuite observé, et non un mot de passe disponible dans Sophos Fusion (anciennement Sophos Central).
• N’essayez pas de récupérer la valeur originale depuis Sophos Fusion, les captures d’écran ou les exportations.
• Ne copiez pas de mots de passe supposés, de valeurs de hachage ou de nouvelles informations d’identification dans les tickets, notes ou messages de chat.
• Définissez un nouveau mot de passe exclusivement via le processus approuvé de l’Identity Provider et gérez-le dans le système de mots de passe prévu.

Réponse et remédiation autorisées

Décidez avant de prendre toute mesure

Avant d’utiliser Actions, toutes les conditions suivantes doivent être réunies :

• L’identité liée est clairement confirmée par le panneau de détails.
• Le propriétaire du compte, le type de compte et la fonction commerciale sont connus.
• Le statut actuel de la fuite, le type de mot de passe et les trois champs de date ont été vérifiés.
• Les Response Actions sont autorisées pour le tenant.
• La personne accomplissant l’action est autorisée pour l’identité spécifique et l’impact attendu.
• Pour les comptes privilégiés ou partagés, le responsable du service ou du système est impliqué.

Si l’une de ces conditions est manquante, aucune action n’est déclenchée. L’enregistrement est transmis à la personne responsable de l’équipe Identité ou Sécurité avec l’horodatage, l’état du filtre et les détails de l’approbation manquante.

Répondre dans Dark Web Intelligence

Si les Response Actions sont autorisées, elles sont disponibles pour les identités liées dans le tableau ou dans le détail de la fuite :

1. Ouvrez la ligne correcte ou le panneau de détails de l’identité confirmée.
2. Sélectionnez Actions.
3. Sélectionnez uniquement la Response Action déjà approuvée.
4. Examinez et suivez toutes les instructions et confirmations à l’écran.
5. Documentez l’action, l’opérateur, le moment, l’identité de la cible et le résultat visible, mais ne capturez pas les informations d’identification.

Seules les Response Actions proposées dans le tenant et autorisées par l’organisation peuvent être utilisées. Si aucune identité appropriée n’existe, Actions restera désactivé ; cela ne doit pas être contourné.

Remédier au risque lié aux identifiants

La remédiation technique s’effectue via l’Identity Provider responsable du compte et selon le processus approuvé de gestion des identifiants :

1. Vérifiez le dernier changement de mot de passe et l’état du compte de l’identité confirmée par rapport au moment de la fuite.
2. S’il n’est pas possible d’exclure que les données de connexion observées dans la fuite sont encore valides, initiez ou effectuez un changement de mot de passe autorisé pour exactement ce compte.
3. Si un compte est désactivé ou supprimé, confirmez son état auprès du fournisseur au lieu de le réactiver à des fins de remédiation.
4. Si l’enregistrement n’est lié à aucune identité, considérez-le comme une fuite historique et inactive et ne tentez pas de deviner l’identité du compte.
5. Ne traitez un Finding associé selon le processus prévu qu’une fois la remédiation réelle des identifiants documentée. Utilisez Dismissed uniquement après une décision techniquement justifiée et documentée, et non pour raccourcir la file d’attente.

Ne déduisez aucun changement supplémentaire de compte, de session, de MFA ou d’annuaire à partir de l’enregistrement de la fuite. De telles mesures nécessitent une raison confirmée séparément et l’approbation requise pour celles-ci.

Cadence et validation de 15 minutes

Sophos vérifie Dark Web Intelligence toutes les 15 minutes. Sophos surveille et collecte les résultats des fuites en continu ; si une fuite active est détectée, un Finding est généralement généré dans les 15 minutes. « Généralement » n’est pas un délai maximum garanti.

Après la correction, n’enregistrez pas immédiatement un succès final. Au lieu de cela :

1. Enregistrez l’heure d’achèvement du changement de mot de passe ou du changement de compte confirmé avec le fuseau horaire.
2. Attendez au moins un cycle complet de 15 minutes. Tenez compte du fait que l’intégration par Sophos des données mises à jour de l’Identity Provider peut demander davantage de temps.
3. Rouvrez My Products > Identity > Dark Web Intelligence.
4. Recherchez la même identité et la même source avec les mêmes filtres.
5. Vérifiez si la fuite est passée de Active à Inactive et si le statut d’identité affiché est correct.
6. Vérifiez le Finding associé séparément. L’absence d’un nouveau Finding ne constitue pas une preuve suffisante si la fuite est toujours Active.
7. Surveillez le Risk Score de l’identité comme un signal de suivi. Ce n’est pas la preuve principale du changement de mot de passe.
8. Documentez l’état initial, l’action, l’heure d’achèvement, l’heure de validation et le statut final.

Critères d’acceptation

Le traitement n’est terminé que lorsque :

• L’identité et la source de la fuite sont clairement documentées ;
• les champs de type mot de passe et date ont été évalués ;
• la remédiation des identifiants est confirmée dans l’Identity Provider compétent ou le compte a été manifestement désactivé ou supprimé ;
• le dossier de fuite remédié n’est plus Active après traitement ;
• le Finding associé a été traité par un processus contrôlé ;
• aucune valeur secrète ne figure dans la documentation.

Si l’enregistrement reste Active après plusieurs cycles de 15 minutes, vérifiez d’abord le dernier changement de mot de passe réel, le statut du compte et l’identité liée à nouveau. Si ces informations sont correctes et que le statut ne peut toujours pas être expliqué, l’état du filtre, la source, les trois champs de date, la référence de l’identité, la référence Finding et l’horodatage doivent être enregistrés. Ensuite, contactez le support Sophos. Ne procédez à aucun autre changement de compte basé sur une supposition.

Dossier de triage

Tenant / environnement :
Heure de validation avec fuseau horaire :
Chemin et filtres actifs :
Source:
Identité liée :
Statut d'identité :
Type de compte : Administrateur / Non-administrateur / incertain
Surveillance VIP : oui / non / peu clair
Type de mot de passe : Plaintext / Hashed
État de la fuite avant action :
Publish Date:
Leaked Date:
Breach Date : Valeur / non disponible
Contexte de plusieurs lignes ou de combolist :
Référence Finding et gravité :
Dernier changement de mot de passe selon Identity Provider :
Approbation de la réponse :
Action autorisée effectuée :
Heure d'achèvement avec fuseau horaire :
Validation après un cycle de 15 minutes :
État de la fuite après la mesure :
Statut de Finding après l'action :
Risk Score comme signal de suivi :
Déviation / escalade ouverte :

Évitez les erreurs courantes

• Compter chaque ligne du tableau comme un compte distinct : Les doublons et les combolists peuvent créer plusieurs lignes pour la même personne.
• Lire Publish Date comme Breach Date : Les trois champs de date décrivent des événements différents ; Breach Date peut être absent.
• Interpréter Inactive comme « supprimé » : Les données historiques sont conservées et peuvent rester visibles.
• Interpréter l’absence de lignes avec les filtres par défaut comme une absence de risque : L’accès direct n’affiche par défaut que les fuites actives associées à des identités actives.
• Fermer manuellement un Finding au lieu de le corriger : Un changement de statut ne modifie aucune donnée de connexion dans le Identity Provider.
• Forcer Actions sans identité liée : Sans identité correspondante, le bouton est intentionnellement désactivé.
• Confondre Plaintext avec un mot de passe récupérable : Sophos indique qu’aucune valeur en clair ni valeur de hachage n’est stockée.
• S’attendre à une mise à jour immédiate : La vérification s’exécute selon un cycle de 15 minutes ; les données d’identité en amont peuvent nécessiter un temps de traitement supplémentaire.