Un rapport automatisé que j’ai eu entre les mains classait « critique » une faille sur un service qui n’écoutait que sur la loopback (l’interface interne de la machine, qui ne sort jamais vers le réseau), donc injoignable de l’extérieur. Trois lignes plus bas, une console d’administration exposée en clair sur Internet passait en « moyen ». L’outil avait inversé la priorité parce qu’il ne lit pas le contexte. C’est pourtant là que se joue tout le métier d’un audit : trier, vous dire où est le vrai risque et quoi corriger d’abord.
Un audit de sécurité utile ne se contente pas de lister les failles : il les trie par exploitabilité réelle, les classe par risque, et chiffre l’effort de correction de chacune.
Pourquoi un scanner ne suffit pas
Lancer un scanner de vulnérabilités prend dix minutes et produit un résultat qui en impose : des centaines de lignes, des CVE partout (les identifiants publics de failles connues, une par référence), beaucoup de rouge. Mais l’outil ne distingue pas ce qui est réellement exploitable chez vous de ce qui reste théorique ou déjà atténué par une autre couche. C’est du bruit. Remettre cette liste brute au client revient à lui refiler le travail d’analyse, c’est-à-dire à ne pas faire l’audit.
Ce travail d’analyse, justement, consiste à juger chaque point sur deux axes. L’impact d’abord : qu’est-ce qui tombe si on l’exploite ? Puis l’exploitabilité : à quel point c’est atteignable ? Deux questions, pas une. Une faille grave mais murée à l’intérieur d’un sous-réseau ne passe pas devant une faille moyenne ouverte à tous les vents. Et à chaque point s’ajoute l’effort de correction, parce qu’un risque élevé qu’on referme en une heure mérite de passer avant un risque moyen qui demande un mois de chantier. Sans cette dimension, on improvise l’ordre des travaux, et on l’improvise mal.
Le livrable doit pouvoir être lu en haut
Un audit dort dans un tiroir quand il ne parle qu’aux techniciens. Le mien tient sur deux niveaux. Une page de synthèse pour le dirigeant : où il en est, ce qui mérite un budget, dans quel ordre, sans jargon à déchiffrer. Et derrière, le détail technique pour ceux qui mettront les mains dedans, de quoi corriger concrètement.
Sur le périmètre, je regarde l’exposition réseau, la gestion des accès, la segmentation, l’état des mises à jour, les secrets. Et un point que je vérifie systématiquement parce qu’on l’oublie presque partout : est-ce que les sauvegardes se restaurent vraiment. J’ai croisé des équipes dont les jobs nocturnes tournaient sans accroc depuis deux ans, sans que personne n’ait jamais relancé une restauration pour de vrai. Le sauvetage n’a jamais été testé. Le jour où ça compte, on découvre une archive illisible ou la base la plus importante manquante. Empêcher l’intrusion ne couvre que la moitié du sujet ; se relever après l’incident est l’autre moitié, et celle-là ne se prouve qu’en testant.
Si vous voulez une première mesure, sans même attendre un prestataire : prenez votre sauvegarde la plus critique et tentez d’en restaurer une partie sur une machine isolée, cette semaine. Le résultat de ce seul test vous en dira plus long sur votre exposition réelle que bien des pages de rapport.