Scan de vulnérabilités ou pentest : quelles différences ?

Niveau : débutant à intermédiaire.

Prérequis : comprendre les notions de système, service réseau, vulnérabilité et risque. Aucun outil offensif n'est nécessaire pour l'exercice.

Toute activité de scan actif ou de test d'intrusion doit être limitée à un laboratoire que tu possèdes ou à un système pour lequel tu disposes d'une autorisation explicite. Une cible accessible sur Internet n'est pas une cible autorisée.

Un scanner commence par découvrir ou recevoir une liste d'actifs. Il identifie des services, collecte des caractéristiques et compare les observations à des signatures de vulnérabilités, à des informations de version et à des règles de configuration ou de conformité. Selon le produit et ses droits, le scan peut être externe, interne ou authentifié.

Un scan non authentifié examine ce qui est exposé depuis son point réseau, dans les limites de ses sondes et de sa configuration. Un scan authentifié utilise un compte prévu pour l'évaluation afin d'examiner plus finement les logiciels installés, les correctifs et les configurations. Cette profondeur supplémentaire améliore souvent la détection, mais elle exige une gestion rigoureuse des identifiants et des privilèges.

Le résultat brut est une liste de constats assortis d'une sévérité, d'une preuve technique et parfois d'une recommandation. Un identifiant CVE ou un score CVSS aide à classer, mais ne détermine pas seul le risque métier. L'exposition, les contrôles compensatoires, la valeur de l'actif et la faisabilité réelle comptent aussi.

Le scan se prête bien à la répétition. Il peut détecter l'apparition de nouveaux actifs, vérifier l'application de correctifs ou suivre la réduction d'un stock de vulnérabilités. Cette automatisation facilite les contrôles répétés, mais elle entraîne aussi des limites : les règles automatisées peuvent produire des faux positifs, manquer une logique métier ou signaler une version sans tenir compte d'une correction rétroportée.

Lorsqu’un scanner affiche une sévérité CVSS, vérifie la métrique dans la documentation officielle de FIRST au lieu de l’interpréter comme une preuve automatique d’impact métier.

Un pentest commence avant tout test technique. Le commanditaire et le prestataire définissent les objectifs, les systèmes inclus et exclus, les horaires, les contacts d'urgence, les méthodes permises, les données sensibles, les conditions d'arrêt et la manière de conserver les preuves. L'autorisation formelle rend la mission légitime, tandis que les règles d'engagement en définissent les limites opérationnelles.

Les testeurs recueillent ensuite des informations dans le périmètre, établissent des hypothèses, vérifient manuellement des faiblesses et peuvent démontrer un enchaînement. Par exemple, une mauvaise configuration prise isolément peut sembler mineure, mais devenir importante si elle permet d'accéder à une fonction sensible puis à des données auxquelles le compte ne devrait pas accéder.

La démonstration doit rester proportionnée. Prouver une possibilité ne signifie pas extraire toutes les données, perturber le service ou maintenir un accès. Le niveau de preuve acceptable est convenu avant la mission. Les actions à fort impact peuvent être exclues ou remplacées par une preuve non destructive.

Le pentest dépend du temps, du périmètre et des informations disponibles. Il échantillonne nécessairement. L'ANSSI rappelle qu'un test d'intrusion seul n'a pas vocation à être exhaustif. Un audit de configuration, de code, d'architecture ou d'organisation peut révéler d'autres catégories de problèmes.

Le guide NIST SP 800-115 et la présentation de l’audit de sécurité par l’ANSSI replacent les tests dans un processus cadré, autorisé et documenté.

Dimension	Scan de vulnérabilités	Pentest
Question principale	Quelles faiblesses connues ou configurations suspectes sont détectables ?	Quels scénarios autorisés peuvent être démontrés et avec quel impact ?
Part d'automatisation	Élevée	Automatisation partielle, complétée par une analyse manuelle
Couverture	Large et répétable	Ciblée, dépendante du temps
Validation	Variable, souvent à confirmer	Vérifications manuelles ciblées
Logique métier	Peu ou mal couverte	Peut être étudiée en profondeur
Fréquence	Régulière ou continue selon le contexte	Ponctuelle, après cadrage
Livrable	Résultats, tendances, actifs, priorités de correction	Synthèse, scénarios, preuves, impacts, recommandations
Risque opérationnel	Présent, à encadrer	Plus élevé selon les méthodes, fortement encadré

Cette table décrit des tendances, pas des garanties. Un scan peut inclure des validations sophistiquées. Un pentest utilise presque toujours des scanners pour gagner du temps. La différence se situe dans l'objectif, l'interprétation et le niveau de preuve, pas dans le simple nom de l'outil.

Choisis un scan récurrent lorsque tu dois maintenir un inventaire technique, repérer des correctifs manquants, surveiller un grand parc ou mesurer une tendance. Il faut prévoir la qualification des résultats, l'attribution des corrections et la vérification après remédiation. Accumuler des rapports sans processus de traitement apporte peu de valeur.

Choisis un pentest lorsque tu as besoin d'évaluer un scénario précis, une application critique, une nouvelle exposition ou la possibilité d'enchaîner plusieurs faiblesses. Le système doit être suffisamment stable et le périmètre suffisamment défini pour que le test apporte une réponse utile.

Les deux sont complémentaires. Un scan peut alimenter la gestion continue et préparer certaines hypothèses. Un pentest peut valider l'impact de constats prioritaires et révéler des problèmes de logique absents des signatures. Après correction, une contre-vérification ciblée confirme que le constat initial n'est plus reproductible. Des tests plus larges sont nécessaires pour rechercher d'éventuelles régressions.

Un bon rapport de scan précise la date, la portée, les méthodes, les actifs couverts, les échecs d'authentification, les exclusions et la version des règles. Il sépare les résultats bruts des constats qualifiés et fournit une base pour suivre la remédiation.

Un rapport de pentest comporte généralement une synthèse destinée aux décideurs, une description du périmètre et des limites, la méthodologie suivie et, lorsque cela apporte une information utile, la chronologie des actions, les constats, les scénarios démontrés, les preuves strictement nécessaires, expurgées des données inutiles, les impacts et des recommandations hiérarchisées. Il doit aussi expliquer ce qui n'a pas été testé. Un rapport spectaculaire mais impossible à convertir en actions est un mauvais livrable.

La restitution orale complète le rapport en permettant aux équipes de discuter des constats et des priorités de correction. Elle permet de répondre aux questions, de distinguer une faiblesse théorique d'un risque démontré et de convenir des prochaines vérifications. Les preuves doivent être protégées, car elles peuvent contenir des données sensibles ou des indications directement exploitables.

Pour structurer les vérifications et les livrables, consulte le Web Security Testing Guide de l’OWASP et les référentiels de qualification PASSI de l’ANSSI.

Cet exercice ne lance aucun scan. Travaille sur le cas fictif suivant : une association possède 80 postes, un serveur de fichiers interne et une application Web de dons qui vient d'être modifiée.

1. Pour chaque besoin, choisis « scan », « pentest », « autre audit » ou une combinaison :
   • repérer mensuellement les correctifs manquants sur les postes ;
   • vérifier si un utilisateur peut accéder aux dons d'un autre utilisateur ;
   • examiner les règles du pare-feu interne ;
   • refaire le contrôle qui avait révélé une faiblesse afin de vérifier que le constat initial n'est plus reproductible.
2. Écris pour chaque choix l'objectif, le périmètre, une limite et le livrable attendu.
3. Ajoute trois règles d'engagement pour le pentest de l'application : environnement visé, comptes de test, contact d'arrêt.

Critère de réussite

L'exercice est réussi si le scan est retenu pour la couverture récurrente des postes, si le contrôle d'accès de l'application appelle une vérification manuelle encadrée, si la revue des règles est identifiée comme audit de configuration et si chaque proposition comporte une limite explicite. Plusieurs combinaisons sont acceptables si elles sont justifiées.

L'erreur la plus fréquente consiste à vendre un rapport automatisé comme un pentest. La présence de nombreux résultats ou d'un score élevé ne prouve ni validation manuelle ni scénario d'attaque. Inversement, considérer les scanners comme inutiles ignore leur capacité de couverture et de répétition.

Il ne faut pas non plus assimiler « aucun résultat » à « aucun risque ». L'outil peut ne pas disposer d'identifiants, ne pas reconnaître une technologie ou ne pas tester la logique métier. Un pentest limité dans le temps peut lui aussi manquer une faiblesse.

Enfin, le score technique ne remplace pas une décision de risque. La priorisation doit tenir compte de l'actif, de son exposition et des conséquences. Les rapports contiennent des informations sensibles et doivent être conservés, transmis et détruits selon des règles définies.