La seule façon fiable de savoir si une défense tient est de l'attaquer. Les tests de sécurité offensifs — pentesting et red teaming — font exactement cela : ils engagent des professionnels pour compromettre les systèmes d'une organisation avec son accord, avant qu'un véritable adversaire ne le fasse sans le demander. Bien qu'ils soient souvent utilisés comme synonymes, ce sont des disciplines distinctes avec des objectifs, une portée et une profondeur différents. Cet article clarifie cette différence, parcourt les phases d'un test d'intrusion, passe en revue les méthodologies standard et aborde le cadre légal qui sépare un test autorisé d'une infraction informatique.
Pentesting versus red teaming : deux objectifs distincts
Un test d'intrusion (pentest) cherche à trouver et à démontrer le plus grand nombre possible de vulnérabilités dans un périmètre délimité — une application web, une plage réseau, une API — dans une fenêtre de temps définie. Sa métrique de succès est la couverture : plus les découvertes sont nombreuses, valides et bien documentées, mieux c'est. L'équipe défensive (blue team) sait généralement que le test est en cours.
Un exercice de red teaming, en revanche, ne cherche pas la couverture mais le réalisme. Il simule un adversaire concret avec un objectif concret — 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 : le blue team ignore généralement l'exercice, ce qui permet d'évaluer véritablement ses contrôles. La différence se résume ainsi : le pentest demande « quelles failles ai-je ? » ; le red team demande « m'apercevrais-je si j'étais attaqué ? ».
| Critère | Pentest | Red Team |
|---|---|---|
| Objectif | Couverture maximale des vulnérabilités | Atteindre un objectif concret comme un adversaire |
| Périmètre | Délimité et connu | Large, souvent toute l'organisation |
| Connaissance du blue team | Généralement informé | Non informé (discrétion) |
| Durée | Jours à semaines | Semaines à mois |
| Mesure | Surface de vulnérabilité | Capacité de détection et de réponse |
Il existe également le purple teaming, où les équipes rouge et bleue collaborent en temps réel pour 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 tests techniques du NIST SP 800-115 — s'accordent sur une séquence essentielle :
- Reconnaissance : collecte d'informations sur la cible, passive (OSINT, registres publics, DNS) et active (scan de ports avec Nmap, fingerprinting des services).
- Analyse des vulnérabilités : identification des faiblesses à l'aide de scanners automatiques et de 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 ici que l'impact réel est démontré, et non seulement le potentiel.
- Post-exploitation : escalade de privilèges, mouvement latéral et persistance. 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 un rapport exploitable, tout ce qui précède ne sert à rien.
Classification du risque et outils
Chaque découverte doit être évaluée selon un critère objectif. Le standard 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 allant de critique à faible. Les vulnérabilités connues sont identifiées par leur CVE (Common Vulnerabilities and Exposures), et les classes de faiblesses par leur CWE. Pour prioriser ce qui doit être corrigé en premier, le catalogue de vulnérabilités activement exploitées (KEV) de l'agence américaine CISA indique lesquelles sont utilisées dans des attaques réelles, ce qui pèse davantage que le score théorique.
L'outillage habituel 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'adversaires dans les exercices de red team. Les tactiques observées sont cartographiées contre MITRE ATT&CK, le catalogue de comportements d'attaquants qui sert de langage commun entre les équipes offensive et défensive.
Les vulnérabilités les plus fréquentes
Bien que chaque environnement soit différent, certaines classes de faiblesses réapparaissent dans la majorité des tests d'applications web. L'OWASP Top Ten les classe par prévalence et impact, et il convient de les connaître car ce sont les premiers éléments qu'examine un évaluateur comme un véritable attaquant :
- Contrôle d'accès défaillant : utilisateurs accédant à des ressources ou fonctions qui ne leur appartiennent pas, 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 aux objets). C'est la catégorie la plus répandue.
- Défaillances cryptographiques : données sensibles transmises ou stockées sans chiffrement adéquat, ou avec des algorithmes obsolètes.
- Injection : SQL, commandes du système d'exploitation ou LDAP, où une entrée non validée est exécutée comme du code. Toujours présente des décennies après sa découverte.
- Conception non sécurisée : failles nées de décisions d'architecture, non d'erreurs d'implémentation, qu'aucune correction ponctuelle ne résout.
- Mauvaise configuration de sécurité : services avec des identifiants par défaut, des permissions excessives ou des messages d'erreur révélant des informations internes.
Une observation récurrente dans les rapports sérieux est que les vulnérabilités de logique métier — des flux permettant, par exemple, d'appliquer une réduction deux fois ou de sauter une étape de validation de paiement — sont les plus précieuses et qu'aucun outil automatique ne les détecte, car elles nécessitent de comprendre ce que l'application devrait faire, pas seulement ce qu'elle fait. C'est là que réside la différence entre un scan et un véritable test d'intrusion exécuté par un professionnel.
Le rapport : là où réside la valeur
Un bon rapport se structure en deux niveaux. Le résumé exécutif, sans jargon, communique le risque métier à la direction : ce que l'organisation pourrait perdre et avec quelle probabilité. Le détail technique documente chaque découverte avec sa description, une preuve reproductible (captures d'écran, requêtes, étapes exactes), son score CVSS, son impact et, surtout, une recommandation de remédiation concrète. Une découverte sans étapes de reproduction ni guide de correction est du bruit. La qualité d'un pentest se juge à l'utilité de son rapport, et non au nombre de vulnérabilités listées.
Erreurs courantes
La première est de ne se fier qu'au scanner automatique : les outils génèrent de nombreux faux positifs et, pire encore, des faux négatifs sur la logique métier qu'aucune machine ne détecte. La deuxième est de ne pas définir le périmètre par écrit, ce qui conduit à des tests sur des actifs non autorisés — un problème légal sérieux. La troisième est de livrer un export du scanner comme rapport, sans priorisation ni contexte métier. La quatrième est de traiter le pentest comme une formalité annuelle de conformité au lieu de l'intégrer dans le cycle de développement ; un test ponctuel photographie un instant, tandis que les menaces sont continues. La cinquième, en red team, est de rompre la discrétion par inadvertance et de contaminer l'évaluation de détection.
Cadre légal : l'autorisation est tout
La frontière entre un test de sécurité légitime et une infraction est un seul document : l'autorisation écrite. Dans la plupart des pays européens, l'accès non consenti à des systèmes informatiques est une infraction pénale, de sorte que sans un contrat définissant le périmètre, la fenêtre temporelle, les actifs inclus et exclus, et une clause de « lettre de mission » protégeant l'évaluateur, tout test offensif est illégal. Les règles d'engagement (Rules of Engagement) doivent fixer quelles techniques sont interdites — typiquement le déni de service et l'ingénierie sociale agressive sauf accord explicite — et à qui notifier si une compromission préexistante est découverte. Lorsque les tests touchent des données personnelles, le RGPD s'applique également, et il convient d'aligner le processus avec les normes de gestion de la sécurité telles que l'ISO/IEC 27001, qui inclut les tests techniques comme contrôle de vérification.
Questions fréquentes
À quelle fréquence dois-je réaliser un pentest ?
Au minimum annuellement et après tout changement significatif dans l'architecture ou dans une application critique. De nombreux cadres de conformité l'exigent, mais la logique de sécurité demande de l'intégrer de manière continue, et non une seule 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 qu'il n'en existe pas d'autres. L'absence de découvertes dans un périmètre délimité n'équivaut pas à une sécurité absolue.
Boîte noire, grise ou blanche ?
En boîte noire, l'évaluateur ne reçoit aucune information préalable (simule un attaquant externe) ; en boîte blanche, il a accès complet au code et à l'architecture (maximise la couverture) ; la boîte grise est un point intermédiaire. Pour la plupart des applications, la boîte grise offre le meilleur équilibre entre réalisme et efficacité.
Puis-je réaliser un pentesting sur 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. Consulter ces règles est obligatoire avant de commencer.
Conclusion
Le pentesting et le red teaming ne sont pas le même outil sous deux noms : le premier inventorie vos faiblesses, le second teste si vous vous rendriez compte d'une attaque réelle. Choisir incorrectement entre les deux gaspille le budget — un red team pour une application fraîchement lancée est excessif, et un pentest délimité ne révèle pas si votre SOC détecte une intrusion discrète. La valeur de l'un ou de l'autre ne réside pas dans la phase d'exploitation spectaculaire, mais dans un rapport que la direction comprend et que l'équipe technique peut exécuter, ainsi que dans une autorisation écrite qui maintient tout l'exercice dans la légalité. Chez Summum Systèmes, nous abordons les tests offensifs dans le cadre d'un cycle continu d'amélioration, avec des règles d'engagement claires et des livrables exploitables, car une vulnérabilité découverte par nous est une crise que votre organisation ne vivra pas.