Ce que contient un bon rapport de surveillance dark web

Un rapport de surveillance dark web n’est utile que si un propriétaire peut agir dessus en moins d’une heure. La plupart des rapports hérités de prestataires précédents échouent à ce test. Voici le parcours d’un rapport de surveillance dark web CloudKey anonymisé, section par section, avec une note sur ce que chaque partie est conçue pour répondre.

Ce qu’un rapport de surveillance dark web doit répondre

Un bon rapport permet à un responsable sécurité de répondre à quatre questions sans appel : quels identifiants ont fuité, quels actifs sont exposés, quels CVE sur ces actifs comptent, et ce qui a été corrigé depuis le mois dernier. Les sections ci-dessous correspondent à ces quatre réponses, dans cet ordre.

Synthèse exécutive

Une page. Un score de risque. Trois chiffres qui ont bougé ce mois-ci, trois qui n’ont pas bougé.

Le score de risque se calcule à partir de quatre entrées : nombre d’identifiants fuités, nombre d’actifs exposés, vulnérabilités de périmètre classées par KEV plus EPSS, et faiblesses de configuration sur les services exposés. Borné, et le calcul est documenté en annexe pour qu’un auditeur puisse le reproduire.

Identifiants fuités

Chaque domaine du périmètre est confronté aux corpus de brèches. Les correspondances sont listées avec la source de la brèche, la date de première apparition, et si l’identifiant a été vu dans du trafic actif de credential stuffing.

Ce que cela répond : quels comptes du personnel sont exposés, et avec quelle urgence le mot de passe doit-il être renouvelé.

Surface d’attaque externe

Un inventaire découvert de chaque sous-domaine, IP et certificat associés aux domaines autorisés. Chaque ligne porte la méthode de découverte, la date de dernière observation, et un petit jeu d’empreintes expliquant pourquoi nous estimons l’actif comme vous appartenant.

Les faux positifs sont marqués et étiquetés, pas silencieusement écartés. Si nous nous trompons sur un sous-domaine, vous le signalez une fois et il reste hors du rapport suivant.

Ports ouverts et vulnérabilités de périmètre

Chaque service exposé sur Internet est scanné pour les CVE connus. Les constats sont classés par KEV d’abord, puis EPSS, puis CVSS, puis atteignabilité. La méthode est la même que celle décrite dans notre article CVSS vs EPSS vs KEV.

Registre des re-tests

Chaque constat clos depuis le dernier rapport est listé avec la date d’attestation du correctif, la méthode utilisée pour vérifier, et l’ingénieur qui a signé. C’est la section que les auditeurs demandent en premier.

Ce qui n’est pas dans le rapport

Trois choses explicitement hors périmètre, énoncées en couverture :

• Les constats sur actifs internes. Ils vivent dans VulnMonitor.
• Les constats applicatifs. Ils vivent dans les livrables de tests d’intrusion.
• Tout ce dont nous n’avons pas la preuve. Si un identifiant fuité est invérifiable, il n’entre pas dans le registre.

Cadence et propriété

Un propriétaire nommé par rapport de surveillance dark web. Une date de livraison par mois. Une attestation de re-test par constat clos. Le rapport garde la même forme chaque mois pour que l’équipe qui le lit n’ait pas à le réapprendre.