Un pentest vise une couverture maximale des vulnérabilités dans un périmètre défini, et l'équipe de défense sait généralement qu'un test est en cours ; le red teaming simule une attaque réelle avec un objectif précis et une discrétion totale, pour mesurer la capacité réelle de détection et de réponse de l'organisation.
La seule façon fiable de savoir si une défense tient est de l'attaquer. Les tests de sécurité offensifs — le pentesting et le red teaming — font exactement cela : ils engagent des professionnels pour compromettre les systèmes d'une organisation avec son consentement, avant qu'un véritable adversaire ne le fasse sans celui-ci. Bien que les deux termes soient souvent utilisés indifféremment, ce sont des disciplines distinctes avec des objectifs, un périmètre et une profondeur différents. Cet article clarifie cette différence, détaille les phases d'un test d'intrusion, passe en revue les méthodologies standard et aborde le cadre juridique qui sépare une évaluation autorisée d'une infraction pénale.
Pentesting versus Red Teaming : deux objectifs différents
Un test d'intrusion (pentest) vise à trouver et à démontrer autant de vulnérabilités que possible dans un périmètre défini — une application web, une plage réseau, une API — pendant une fenêtre de temps fixe. Sa mesure de succès est la couverture : plus il y a de constats valides et bien documentés, mieux c'est. L'équipe de défense (blue team) sait généralement que le test a lieu.
Un exercice de red team, en revanche, ne porte pas sur la couverture mais sur le réalisme. Il simule un adversaire spécifique avec un objectif précis — par exemple exfiltrer la base de données clients ou compromettre le domaine Active Directory — et mesure la capacité réelle de détection et de réponse de l'organisation. La discrétion est essentielle : la blue team ignore généralement l'exercice, ce qui permet une évaluation authentique de ses contrôles. La différence peut se résumer ainsi : le pentest demande « quelles failles ai-je ? » ; le red team demande « m'en apercevrais-je si j'étais attaqué ? ».
| Critère | Pentest | Red Team |
|---|---|---|
| Objectif | Couverture maximale des vulnérabilités | Atteindre un objectif précis comme le ferait un adversaire |
| Périmètre | Défini et connu | Large, souvent l'organisation entière |
| Connaissance de la blue team | Généralement informée | Non informée (discrétion) |
| Durée | Jours à semaines | Semaines à mois |
| Mesure | Surface de vulnérabilité | Capacité de détection et de réponse |
Il existe aussi le purple teaming, où les équipes red et blue collaborent en temps réel afin que chaque technique offensive améliore immédiatement une capacité défensive.
Les phases d'un test d'intrusion
Les méthodologies reconnues — l'OWASP Web Security Testing Guide, le PTES (Penetration Testing Execution Standard) et le cadre de test technique NIST SP 800-115 — convergent toutes vers une séquence essentielle :
- Reconnaissance : collecte d'informations sur la cible, à la fois passivement (OSINT, registres publics, DNS) et activement (scan de ports avec Nmap, identification des services).
- Analyse des vulnérabilités : identification des faiblesses à l'aide de scanners automatisés et d'une vérification manuelle. Le scanner génère des hypothèses ; l'analyste confirme lesquelles sont réelles.
- Exploitation : tirer parti d'une vulnérabilité pour obtenir un accès. C'est là que l'impact réel est démontré, et non plus seulement potentiel.
- Post-exploitation : élévation de privilèges, mouvement latéral et persistance. Elle répond à la question « une fois à l'intérieur, jusqu'où puis-je aller ? ».
- Rapport : la phase la plus importante et la plus négligée. Sans rapport exploitable, tout le reste ne compte pour rien.
Classification des risques et outils
Chaque constat doit être noté selon un critère objectif. La référence de facto est le CVSS (Common Vulnerability Scoring System), qui attribue un score de 0 à 10 selon des vecteurs d'exploitabilité et d'impact, traduisible en catégories de sévérité allant de critique à faible. Les vulnérabilités connues sont identifiées par leur identifiant CVE (Common Vulnerabilities and Exposures), et les classes de faiblesses par leur CWE (Common Weakness Enumeration). Pour prioriser ce qu'il faut corriger en premier, le catalogue Known Exploited Vulnerabilities (KEV) tenu par l'agence américaine CISA indique quelles vulnérabilités sont activement utilisées dans des attaques réelles — un facteur qui pèse plus lourd que le seul score théorique.
La boîte à outils standard comprend Nmap pour la découverte réseau, Burp Suite pour les tests d'applications web, Metasploit comme framework d'exploitation, et Cobalt Strike ou Sliver pour la simulation d'adversaire dans les exercices de red team. Les tactiques observées sont cartographiées par rapport à MITRE ATT&CK, le catalogue des comportements d'attaquants qui sert de langage commun entre l'attaque et la défense.
Les vulnérabilités les plus fréquentes
Bien que chaque environnement soit différent, certaines classes de faiblesses reviennent dans la plupart des évaluations d'applications web. L'OWASP Top Ten les classe par prévalence et impact, et il vaut la peine de les connaître car c'est le premier endroit où regarderont aussi bien un évaluateur qu'un véritable attaquant :
- Contrôle d'accès défaillant : des utilisateurs accédant à des ressources ou des fonctions auxquelles ils n'ont pas droit — par exemple en modifiant un identifiant dans l'URL pour voir les données d'un autre client (référence directe non sécurisée à un objet). C'est la catégorie la plus répandue.
- Défaillances cryptographiques : des données sensibles transmises ou stockées sans chiffrement adéquat, ou utilisant des algorithmes obsolètes.
- Injection : SQL, commandes système d'exploitation ou LDAP, où une entrée non validée est exécutée comme du code. Cette classe persiste depuis des décennies depuis sa découverte.
- Conception non sécurisée : des failles qui découlent de décisions architecturales, et non d'erreurs d'implémentation, et qu'aucun correctif ciblé ne peut résoudre.
- Mauvaise configuration de sécurité : des services fonctionnant avec des identifiants par défaut, des permissions excessives ou des messages d'erreur qui révèlent des informations internes.
Une observation récurrente dans les rapports sérieux est que les vulnérabilités de logique métier — des flux qui permettent, par exemple, d'appliquer une remise deux fois ou de contourner une étape de validation de paiement — sont les constats les plus précieux et ceux qu'aucun outil automatisé ne détecte, car ils exigent de comprendre ce que l'application devrait faire, pas seulement ce qu'elle fait. C'est la différence entre un scan et un véritable test d'intrusion mené par un professionnel compétent.
Le rapport : là où réside la valeur
Un bon rapport est structuré sur deux niveaux. Le résumé exécutif, exempt de jargon, communique le risque métier à la direction : ce que l'organisation pourrait perdre et la probabilité que cela arrive. Le détail technique documente chaque constat avec sa description, des preuves reproductibles (captures d'écran, requêtes, étapes exactes), le score CVSS, l'impact et, surtout, une recommandation concrète de remédiation. Un constat sans étapes de reproduction ni indication de remédiation n'est que du bruit. La qualité d'un pentest se juge à l'utilité de son rapport, pas au nombre de vulnérabilités listées.
Erreurs courantes
La première est de s'appuyer uniquement sur des scanners automatisés : les outils génèrent d'abondants faux positifs et, pire encore, des faux négatifs sur la logique métier qu'aucune machine ne peut détecter. La deuxième est de ne pas définir le périmètre par écrit, ce qui conduit à tester des actifs non autorisés — un problème juridique grave. La troisième est de livrer un export brut de scanner en guise de rapport, sans priorisation ni contexte métier. La quatrième est de traiter le pentest comme une formalité de conformité annuelle plutôt que de l'intégrer au cycle de développement ; un test ponctuel capture un instant, alors que les menaces sont continues. La cinquième, dans les exercices de red team, est de briser accidentellement la discrétion et de contaminer l'évaluation de la détection.
Cadre juridique : l'autorisation est essentielle
La frontière entre une évaluation de sécurité légitime et une infraction pénale tient à un seul document : l'autorisation écrite. L'accès non autorisé à des systèmes informatiques est une infraction pénale dans la plupart des juridictions — en Espagne, elle est couverte par l'article 197 bis et les dispositions connexes du Code pénal — ce qui signifie que sans un contrat définissant le périmètre, la fenêtre temporelle, les actifs inclus et exclus et une clause de protection de l'évaluateur, tout test offensif est illégal. Les Rules of Engagement doivent préciser quelles techniques sont interdites — typiquement le déni de service et l'ingénierie sociale agressive sauf accord explicite — et qui prévenir si une compromission préexistante est découverte. Lorsque les tests touchent des données personnelles, le RGPD s'applique en plus, et il est conseillé d'aligner le processus sur des normes de management de la sécurité comme l'ISO/IEC 27001, qui traite les tests techniques comme un contrôle de vérification.
Questions fréquentes
À quelle fréquence dois-je réaliser un pentest ?
Au minimum, une fois par an et après tout changement significatif de l'architecture ou d'une application critique. De nombreux référentiels de conformité l'exigent, mais une logique de sécurité solide impose de l'intégrer en continu, pas seulement une fois par an.
Un pentest garantit-il que mon système est sécurisé ?
Non. Il démontre que certaines vulnérabilités existent, pas que d'autres n'existent pas. L'absence de constats dans un périmètre défini n'équivaut pas à une sécurité absolue.
Boîte noire, boîte grise ou boîte blanche ?
Dans un test en boîte noire, l'évaluateur ne reçoit aucune information préalable (simulant un attaquant externe) ; dans un test en boîte blanche, il a un accès complet au code et à l'architecture (maximisant la couverture) ; la boîte grise est un juste milieu. Pour la plupart des applications, la boîte grise offre le meilleur équilibre entre réalisme et efficacité.
Puis-je réaliser des pentests contre des services cloud ?
Oui, mais les grands fournisseurs ont des politiques spécifiques sur ce qui peut être testé et ce qui nécessite une notification préalable. Vérifier ces règles avant de commencer est obligatoire.
Conclusion
Le pentesting et le red teaming ne sont pas un seul et même outil sous deux noms : le premier inventorie vos faiblesses, le second teste si vous remarqueriez une attaque réelle. Mal choisir entre les deux gaspille du budget — un exercice de red team pour une application récemment lancée est excessif, et un pentest cadré ne révèle pas si votre SOC peut détecter une intrusion discrète. La valeur de l'une ou l'autre approche ne réside pas dans la phase spectaculaire d'exploitation, mais dans un rapport que la direction comprend et sur lequel l'équipe technique peut agir, et dans une autorisation écrite qui maintient tout l'exercice dans la légalité. Chez Summum Sistemas, nous abordons les tests offensifs comme faisant partie d'un cycle d'amélioration continue, avec des Rules of Engagement claires et des livrables exploitables, car une vulnérabilité que nous trouvons est une crise que votre organisation n'aura jamais à vivre.