Analyse manuelle ou automatisée : les limites des outils
Un correcteur orthographique repère les fautes, mais il ne sait pas si votre texte est convaincant. Les scanners de vulnérabilités sont dans une situation comparable : ils excellent à repérer ce qui est connu et répétitif, et passent à côté de ce qui demande de comprendre. Cette leçon vous apprend à combiner les deux approches avec discernement.
Vous venez de voir ce que les scanners savent faire et leurs limites. Reste à décider, dans une mission, quand faire confiance à l'outil et quand reprendre la main. Un testeur compétent n'oppose pas manuel et automatisé : il les enchaîne, chacun là où il est le plus efficace.
Ce que l'automatisation fait mieux
- Les contrôles répétitifs et à grande échelle : vérifier cent machines, des milliers de ports, des centaines de versions ;
- Les faiblesses connues et documentées : versions vulnérables, configurations par défaut, certificats expirés ;
- La régularité : le scanner n'oublie pas une machine et ne se fatigue pas ;
- La comparaison dans le temps : on mesure ce qui a été corrigé entre deux passes.
Ce que l'analyse manuelle fait mieux
- La logique métier : un processus de commande qui permet de modifier un prix, un parcours de validation qu'on peut contourner. Aucun scanner ne comprend ce que l'application est censée faire.
- Le contrôle d'accès : savoir si l'utilisateur A peut voir les données de l'utilisateur B suppose de comprendre les rôles, ce que l'automatisation ne fait que rarement bien.
- L'enchaînement de failles : plusieurs faiblesses mineures, combinées, peuvent produire un impact majeur. Ce raisonnement est humain.
- La validation : confirmer qu'une alerte est réelle ou fausse, et mesurer son impact dans le contexte.
- Les systèmes atypiques : équipements anciens, protocoles maison, applications sur mesure, que les signatures ne connaissent pas.
- L'adaptation : un humain change de tactique selon ce qu'il observe, un outil suit sa liste.
Un tableau pour décider
| Question | Plutôt automatisé | Plutôt manuel |
|---|---|---|
| Combien de cibles ? | Nombreuses | Peu, mais critiques |
| Type de faille recherchée | Connue, documentée | Logique, spécifique, enchaînement |
| Fragilité du système | Robuste, bien supervisé | Fragile (tests délicats, un à la fois) |
| Objectif | Inventaire, suivi dans le temps | Démonstration d'impact |
| Contrainte de temps | Très courte | Plus souple |
Un exemple pour comprendre
Imaginez une application fictive de réservation, installée dans votre labo. Un scanner web l'analyse et signale trois choses : un en-tête de sécurité absent, un cookie sans attribut particulier, une version de bibliothèque ancienne. Rien de dramatique.
Un testeur, lui, explore l'application avec un proxy et se demande : « Que se passe-t-il si je modifie dans la requête l'identifiant de la réservation pour celui d'un autre utilisateur ? » Il constate qu'il accède à la réservation d'un autre compte. C'est une faille de contrôle d'accès, que le scanner n'a pas vue puisqu'elle suppose de connaître la signification de l'identifiant. Cette faille est bien plus grave que les trois constats du scanner, et elle illustre ce que vous avez vu dans le cours précédent sur les références directes non sécurisées.
La leçon n'est pas « le scanner est inutile » : il a fourni un inventaire de base et des recommandations de durcissement. La leçon est que seul, il aurait donné une fausse impression de sécurité.
Le flux de travail recommandé
La plupart des professionnels suivent une démarche en entonnoir :
- Automatiser l'inventaire : scans de ports, détection de version, scan de vulnérabilités avec un profil adapté ;
- Trier : écarter les constats d'information, regrouper les doublons, repérer les faux positifs probables ;
- Vérifier manuellement les constats prometteurs : comprendre la condition de la faille, valider qu'elle s'applique ;
- Explorer manuellement les zones que l'outil ne couvre pas : logique métier, contrôle d'accès, enchaînements ;
- Documenter : pour chaque piste, ce qui a été vu, comment, avec quel niveau de certitude.
Les biais à surveiller chez le testeur
L'humain aussi a des défauts. Soyez attentif à :
- La confiance aveugle dans l'outil : « le scan est propre, donc tout va bien ». Faux : l'absence de constat n'est pas une preuve d'absence de faille.
- L'ancrage sur la première piste : vous avez trouvé un constat séduisant et vous y passez trois heures en négligeant le reste. Fixez-vous un temps limite par piste.
- Le biais de confirmation : vous cherchez uniquement ce qui valide votre hypothèse. Notez aussi ce qui la contredit.
- L'effet « tunnel » : vous oubliez le périmètre et la finalité de la mission dans l'enthousiasme de la découverte. Revenez régulièrement à votre autorisation.
Le point de vue du défenseur
Un défenseur qui reçoit un rapport de scanner automatisé doit lui aussi garder l'esprit critique. S'il corrige sans réfléchir tous les constats « critiques » d'un outil, il peut passer des semaines sur des faux positifs et négliger une faille de conception. Les cadres de référence comme les guides du NIST (nist.gov) ou la méthodologie OWASP (owasp.org) insistent sur la combinaison des méthodes, car chacune couvre des angles différents.
À vous de jouer : comparer deux approches
Sur une application d'entraînement légale (DVWA, OWASP Juice Shop ou un exercice de la PortSwigger Web Security Academy), faites deux passes de 30 minutes. Première passe : lancez uniquement un scanner automatisé (si vous en avez un) et consignez ses constats. Deuxième passe : explorez manuellement avec votre proxy en cherchant ce que le scanner n'a pas indiqué. Notez dans votre carnet trois différences entre les deux passes. Concluez par un petit paragraphe : « ce que j'ai gagné avec l'automatisation » et « ce que j'ai trouvé seulement à la main ».
Voir une solution
Les différences typiques : le scanner a signalé des en-têtes absents, des versions anciennes et quelques entrées non filtrées en un temps très court ; l'exploration manuelle a permis de comprendre les rôles d'utilisateurs, de tester l'accès aux données d'un autre compte et de repérer des fonctionnalités cachées. Conclusion : l'automatisation donne la largeur, le travail manuel donne la profondeur, et chacun doit alimenter l'autre.
Si votre scanner a trouvé plus que vous, c'est normal sur certaines classes de failles ; si vous avez trouvé plus que lui, regardez quelles classes il ignore et mémorisez-les.
Astuce. Dans votre carnet, ajoutez à chaque piste une étiquette : « automatisé », « manuel » ou « mixte ». À la fin de la mission, ce relevé vous montrera où vous avez réellement apporté de la valeur.
À retenir
- L'automatisation excelle sur les contrôles répétitifs et les faiblesses connues ; l'analyse manuelle sur la logique métier, les droits d'accès et les enchaînements de failles.
- Un scan « propre » ne prouve pas l'absence de faille ; un scan « rouge » ne prouve pas que tout est exploitable.
- La démarche en entonnoir : inventaire automatisé, tri, vérification manuelle, exploration manuelle, documentation.
- Méfiez-vous de vos propres biais : confiance aveugle, ancrage, confirmation, effet tunnel.
- Les référentiels (NIST, OWASP) recommandent de combiner les méthodes.
Il reste une décision à prendre : avec un temps limité, par où commencer ? C'est l'objet de la dernière leçon de ce chapitre.