Un scan de vulnérabilité sert à repérer rapidement les failles visibles d’un système avant qu’elles ne deviennent un incident. Je vais aller droit au but: ce que cet examen détecte vraiment, en quoi il se distingue d’un pentest, comment le conduire sans bruit inutile, puis comment lire les résultats et les intégrer au pilotage IT.
Les points à garder en tête avant de passer à l’action
- Un scan automatisé cartographie les faiblesses exposées, mais ne remplace ni l’analyse humaine ni le test d’exploitation.
- Le bon niveau de priorité dépend de l’exposition, de la criticité de l’actif, de l’exploitabilité et du coût de correction.
- Un mode authentifié réduit fortement les angles morts, surtout sur les serveurs, les postes et le cloud.
- La fréquence utile n’est pas seulement calendaire: elle doit suivre les changements, les mises en production et les alertes critiques.
- La qualité d’un programme se mesure moins au nombre de résultats qu’au délai réel de correction et au taux de couverture.
Ce que détecte vraiment une analyse de vulnérabilités
Selon le NIST, cette approche vise à identifier les hôtes, leurs attributs et les vulnérabilités associées. En pratique, je regarde d’abord la surface observable: ports ouverts, services actifs, versions, paramètres faibles, bibliothèques obsolètes, exposition Internet et erreurs de configuration. C’est utile parce qu’un système peut paraître « en ordre » tout en accumulant des failles triviales à exploiter.
Je distingue surtout ce qu’elle voit bien et ce qu’elle voit mal.
- Ce qu’elle détecte bien : services inutiles exposés, correctifs absents, composants connus pour être vulnérables, chiffrement mal réglé, identifiants par défaut, configurations trop permissives.
- Ce qu’elle détecte moins bien : logique métier défaillante, chaîne d’attaque complexe, abus de rôle, contournements manuels, comportements dépendants d’un scénario très précis.
Je considère donc le scan comme un radar, pas comme un verdict. Il sert à élargir la visibilité et à hiérarchiser l’effort, puis on passe à l’arbitrage, ce qui nous amène naturellement à la différence avec un pentest.
Pourquoi ce n’est pas la même chose qu’un pentest
Le piège classique consiste à confondre trois besoins qui n’ont pas la même portée. Un scan vise la couverture et la répétabilité. Un pentest cherche à démontrer un scénario d’attaque crédible. Un audit de configuration vérifie si l’environnement respecte un référentiel de durcissement. Les trois sont complémentaires, mais ils ne répondent pas à la même question.
| Méthode | Question posée | Force principale | Limite principale | Quand je la choisis |
|---|---|---|---|---|
| Analyse de vulnérabilités | Quelles failles connues et mal configurées sont visibles ? | Rapidité, répétabilité, large couverture | Peu de contexte métier, faux positifs possibles | Suivi régulier d’un parc, exposition Internet, pilotage de remédiation |
| Pentest | Peut-on transformer une faiblesse en compromission réelle ? | Validation de l’impact, créativité, enchaînements d’attaque | Périmètre plus réduit, coût plus élevé | Validation ciblée avant mise en service, contexte sensible, doute sur l’exploitabilité |
| Audit de configuration | Le système respecte-t-il le niveau de durcissement attendu ? | Lisibilité du niveau de maîtrise, alignement sécurité/gouvernance | Ne teste pas toujours l’exploitabilité réelle | Conformité, standardisation, remise à niveau d’une base technique |
Je résume souvent ainsi: le scan donne l’ampleur du problème, le pentest prouve ce qu’un attaquant pourrait réellement faire, et l’audit de configuration dit si l’environnement est bien tenu. Une fois ce cadrage posé, on peut passer au déroulé concret d’un scan propre.
Comment je déroule un scan exploitable en pratique
Un résultat utile ne dépend pas seulement de l’outil. Il dépend surtout de la préparation. Si le périmètre est flou, si les identités de machines sont mal tenues ou si la base de signatures est obsolète, on obtient du bruit, pas de la décision.
- Cadrer le périmètre : je liste les actifs, les plages IP, les applications, les environnements cloud et les exclusions. Sans inventaire propre, le scan ne couvre jamais vraiment ce que l’équipe croit couvrir.
- Choisir le bon mode : un scan externe mesure ce qui est exposé depuis Internet, un scan interne voit la surface du réseau, et un scan authentifié va plus loin en testant la réalité du système depuis un compte autorisé.
- Préparer la fenêtre d’exécution : je vérifie les horaires, les dépendances, les systèmes fragiles et les seuils de charge. Sur certains environnements, quelques minutes suffisent; sur un parc étendu, cela peut prendre plusieurs heures.
- Lancer avec des signatures à jour : un moteur qui n’a pas été actualisé récemment perd vite de la valeur. Les bases de détection doivent suivre le rythme des vulnérabilités publiées, pas l’inverse.
- Qualifier et ouvrir les tickets : je transforme les résultats en actions traçables, avec propriétaire, échéance et niveau de risque. Sans suivi de remédiation, le scan devient un rapport de plus.
Dans les environnements sensibles, je privilégie toujours le mode authentifié quand c’est possible: il réduit les angles morts et améliore la fiabilité des constats. C’est aussi là que l’on commence à voir la vraie difficulté, à savoir trier ce qui mérite d’être corrigé en premier.
Comment lire les résultats sans se laisser piéger par le bruit
Le score technique ne suffit pas. Un CVSS élevé sur un actif isolé n’a pas la même urgence qu’un score moyen sur un portail exposé publiquement. J’ajoute donc toujours le contexte: exposition, données manipulées, facilité d’exploitation, présence d’un correctif, et possibilité de contournement. CVSS est l’échelle de sévérité; CVE, l’identifiant public d’une vulnérabilité. Les deux aident à parler le même langage, mais ils ne remplacent pas le jugement opérationnel.
| Critère | Ce que j’observe | Pourquoi cela change la priorité |
|---|---|---|
| Exposition | Internet, réseau interne, segment restreint | Plus l’actif est visible, plus la fenêtre d’attaque est large |
| Exploitabilité | Exploit public, preuve de concept, attaque automatisée | Une faille déjà utilisée activement doit remonter dans la file |
| Criticité métier | Données sensibles, service vital, dépendance transverse | Un actif critique mérite une remédiation plus rapide, même pour un score moyen |
| Facilité de correction | Patch simple, désactivation d’un service, segmentation, contournement | Je corrige d’abord ce qui peut être traité vite et proprement |
| Confiance dans le résultat | Faux positif probable, version incertaine, bannière trompeuse | Je valide avant d’engager du temps ou de déclencher une urgence inutile |
Je garde aussi en tête que le scan ne voit pas tout. Les failles logiques, les erreurs de droits, certaines chaînes d’authentification ou les abus de session passent parfois à travers. C’est pour cela que le bruit doit être filtré, mais pas ignoré: un résultat discutable mérite une vérification rapide, pas un abandon.
Le NIST rattache d’ailleurs la fréquence et l’ampleur des contrôles à la catégorisation de sécurité des systèmes, ce qui confirme une idée simple: la priorité ne peut pas être uniforme. Cela m’amène à la question que beaucoup d’équipes posent trop tard, celle du bon rythme de scan et de ses limites réelles.
À quelle fréquence scanner et où les limites apparaissent
Je préfère un rythme adapté au risque plutôt qu’un calendrier rigide. Sur les actifs exposés, un contrôle hebdomadaire ou déclenché après chaque changement majeur est souvent pertinent. Sur le cœur de SI, un cycle mensuel reste un bon point de départ, à condition d’ajouter des scans déclenchés par les mises en production, les changements d’image ou les alertes critiques.
- Externe : utile pour voir ce qu’un attaquant voit depuis l’extérieur et pour suivre la réduction de l’exposition publique.
- Interne : indispensable pour repérer les faiblesses latérales, les versions oubliées et les actifs non déclarés.
- Authentifié : souvent le plus rentable, car il réduit les faux angles morts et améliore la profondeur d’analyse.
- Industriel ou legacy : à traiter avec prudence, dans des fenêtres sûres et parfois avec des techniques moins agressives.
Les limites sont réelles. Un scan actif peut déclencher des alertes, saturer un équipement fragile, provoquer un verrouillage de compte ou perturber une application mal conçue. Dans les environnements OT ou industriels, je suis beaucoup plus conservateur: je privilégie le créneau, la sécurité d’exécution et, si besoin, des méthodes moins intrusives. C’est aussi pour cette raison que le CERT-FR reste utile comme point de veille et de coordination: la surveillance des vulnérabilités ne se résume pas à lancer un outil.
Ce que je verrouille pour en faire un levier de pilotage IT
Quand je veux que le dispositif tienne dans la durée, je le fais reposer sur quelques règles simples.
- Un inventaire fiable : on ne corrige bien que ce qu’on sait compter.
- Un propriétaire par actif : sans responsable identifié, les résultats se perdent.
- Des délais de correction par sévérité : par exemple, quelques jours pour le critique, quelques semaines pour le moyen, avec arbitrage formalisé en cas d’exception.
- Un traitement des exceptions : toute dérogation doit être datée, justifiée et réévaluée.
- Un suivi de la remédiation : je regarde le délai moyen de correction, le taux de réouverture et la part des actifs couverts, pas seulement le nombre brut de vulnérabilités.
- Un lien direct avec le patch management et la CMDB : sinon, la boucle opérationnelle reste incomplète.
En pratique, c’est ce cadrage qui fait la différence entre une démarche cosmétique et un vrai pilotage du risque. Un scan bien intégré n’est pas un rapport annuel qu’on archive; c’est un mécanisme de décision qui aide l’IT à corriger plus vite, à justifier les priorités et à réduire l’exposition de façon mesurable.
