Surveiller le dark web ne signifie pas « tout voir » : comment les entreprises peuvent agir à partir d’indices de fuite
La valeur de la surveillance du dark web ne tient pas à la promesse de tout voir, mais à la détection précoce d’indices de fuite concernant l’entreprise, à leur vérification et à leur classement par gravité, puis à leur transmission aux équipes capables d’en limiter les conséquences.
Ce que les entreprises veulent vraiment savoir, ce n’est généralement pas « à quel point le dark web est mystérieux », mais quelque chose de bien plus concret : si des identifiants de connexion de salariés, des données clients ou des documents internes sont déjà ouvertement proposés à la vente, peuvent-elles l’apprendre avant que le problème ne prenne de l’ampleur ?
La surveillance du dark web peut aider à repérer des indices, mais elle n’offre pas une vue sur l’ensemble des risques. Une démarche fiable consiste à rapprocher les indices accessibles publiquement ou recueillis par des canaux spécialisés de l’inventaire des actifs de l’entreprise et de ses procédures de gestion des incidents de sécurité, puis à les vérifier un par un.
Qu’est-ce que le dark web, et pourquoi les entreprises doivent-elles s’y intéresser ?
Le dark web désigne généralement un ensemble de services en ligne dont l’accès nécessite un logiciel ou une configuration particulière. On y trouve des forums, des places de marché et des communautés privées. Des identifiants volés, des services liés aux logiciels malveillants, des documents d’entreprise ou des discussions entre attaquants sur leurs cibles peuvent y apparaître. Pourtant, de nombreuses fuites apparaissent d’abord sur des sites web ordinaires, dans des dépôts de code, des groupes de messagerie instantanée ou des circuits de revente de données. Se focaliser sur le seul terme « dark web » peut donc faire manquer des signaux plus précoces et plus fiables.
La première question à se poser : que faut-il protéger ?
L’entreprise peut commencer par répertorier les éléments qui concernent réellement son activité : ses domaines et sous-domaines, les points d’accès aux espaces de connexion des salariés et des clients, ses noms de marque, ses domaines de messagerie, ses clés API, les noms de ses services cloud, ainsi que les documents ou les noms de code de projets qui ne doivent pas être publics. Sans cet inventaire, les outils de surveillance risquent de produire beaucoup de bruit sans rapport avec l’entreprise.
Il faut ensuite définir plusieurs critères précis de déclenchement d’une alerte : la découverte d’identifiants de l’entreprise dont l’authenticité a été vérifiée, d’un nouveau compte à privilèges élevés, d’extraits de documents internes, de discussions sur des attaques visant un système précis, ou d’un échantillon correspondant à un incident connu. Plus ces critères sont précis, plus il est facile pour l’équipe de sécurité de déterminer la suite à donner.
Entre l’indice et la conclusion, la vérification est indispensable
Un message sur un forum, une capture d’écran ou une archive compressée censée contenir des données ne constituent que des indices. L’équipe doit vérifier la date, la source, le format des données, la présence de champs authentiques et la validité actuelle des informations. Des republications successives peuvent donner l’impression de plusieurs incidents alors qu’il ne s’agit que d’un ancien contenu remis en circulation. À l’inverse, un simple échantillon d’identifiants, peu remarquable à première vue, peut suffire à justifier le renouvellement immédiat des mots de passe et des jetons.
Un service de surveillance peut recueillir des indices et émettre des alertes, mais il ne peut pas décider à la place de l’entreprise si l’incident est réel, quels systèmes sont touchés ou qui est habilité à intervenir. Distinguer la « détection » de la « confirmation » permet de réduire les fausses alertes et d’éviter de bloquer précipitamment des utilisateurs légitimes sur la foi d’un contenu non vérifié.
Une démarche vraiment utile : détecter, confirmer, traiter, tirer les enseignements
Détecter : recueillir en continu les indices concernant les actifs de l’entreprise et consigner la date de leur première apparition ainsi que leur source.
Confirmer : faire vérifier les échantillons par les responsables de la sécurité ou des systèmes afin de déterminer quels comptes, systèmes ou données sont touchés.
Traiter : renouveler les identifiants et autres secrets d’authentification, isoler les systèmes concernés, prévenir les personnes qui doivent agir et conserver une trace des mesures prises.
Tirer les enseignements : comprendre pourquoi les dispositifs de contrôle existants n’ont pas détecté le problème à temps, puis ajuster l’inventaire des actifs, les droits d’accès, les journaux et les règles d’alerte.
Quel rapport avec les questions de systèmes abordées par Lu Heng ?
Dans ses Notes, Lu Heng rappelle régulièrement aux lecteurs de distinguer les étiquettes attribuées à un système, les informations qu’il consigne et ses capacités réelles. La surveillance du dark web présente les mêmes limites : un score de risque ou une notification de « détection » ne constitue pas le fait lui-même ; un outil centralisé peut rendre un service sans pour autant avoir le pouvoir de prendre toutes les décisions à la place de l’entreprise.
Une bonne solution de surveillance doit donc permettre à l’entreprise de comprendre ses dépendances, de vérifier les éléments de preuve et de conserver des solutions de rechange, tout en laissant le jugement aux personnes qui assument réellement les conséquences pour l’activité. Sa valeur ne réside pas dans la peur qu’elle suscite, mais dans sa capacité à donner à l’organisation des choix plus éclairés tant qu’il est encore possible de traiter le problème.