01Ce qu'est un test d'intrusion – et ce qu'il n'est pas
Un test d'intrusion est un audit de sécurité mandaté et limité dans le temps, au cours duquel les testeurs identifient, enchaînent et exploitent manuellement des vulnérabilités de manière contrôlée afin d'en démontrer le risque réel. Il faut clairement le distinguer du scan de vulnérabilités : celui-ci recherche de façon automatisée et à grande échelle des schémas de vulnérabilités connus, mais ne vérifie pas les résultats et produit régulièrement des faux positifs – il fait partie de la gestion continue des vulnérabilités et ne remplace pas un pentest. Le red teaming poursuit quant à lui un autre objectif : il simule de manière furtive une attaque réaliste contre des actifs critiques définis (« crown jewels ») et éprouve également les capacités de détection et de réaction des défenseurs, tandis qu'un test d'intrusion examine un périmètre délimité de la manière la plus exhaustive possible à la recherche de vulnérabilités.
02Types de tests : de l'application web au Wi-Fi
Les tests d'applications web et d'API portent notamment sur l'authentification, la gestion de session, le contrôle d'accès et les vulnérabilités d'injection. Les tests d'infrastructure externes ciblent la surface d'attaque accessible depuis Internet ; les tests internes partent d'un attaquant présent dans le réseau et examinent par exemple l'élévation de privilèges, les mouvements latéraux et les faiblesses d'Active Directory. Les pentests cloud se concentrent sur les erreurs de configuration ainsi que sur les modèles d'identités et d'autorisations dans le cadre de la responsabilité partagée avec le fournisseur. Les tests d'applications mobiles couvrent le stockage local des données, les mécanismes de protection de la plateforme et les interfaces backend ; les tests Wi-Fi vérifient l'authentification, le chiffrement et la segmentation du réseau sur site.
03Black box, grey box, white box : le niveau d'information
Cette classification décrit la quantité d'informations préalables fournies aux testeurs. Dans un test black box, ils démarrent sans aucune information interne – réaliste du point de vue de l'attaquant, mais chronophage et avec une couverture moindre, car une partie du temps de test est consacrée à la collecte d'informations. Dans un test white box, la documentation d'architecture, les configurations ou le code source sont disponibles, ce qui permet la plus grande profondeur de test par unité de temps. L'approche grey box se situe entre les deux, typiquement avec des comptes de test et de la documentation ; dans la pratique, elle s'est imposée comme le standard efficace pour la plupart des objectifs de test. Indépendamment de cela, la perspective (externe/interne) et le degré d'annonce préalable sont définis lors du cadrage.
04Méthodologies : OWASP WSTG, PTES et guide du BSI
Des méthodologies reconnues rendent les tests d'intrusion traçables et comparables. Pour les applications web et les API, l'OWASP Web Security Testing Guide (WSTG) fait référence ; la version stable actuelle 4.2 est parue en décembre 2020, la version 5.0 est en cours de développement. Le Penetration Testing Execution Standard (PTES, version 1.0) structure l'ensemble du processus en sept phases, des interactions de pré-engagement à la rédaction du rapport, en passant par la collecte d'informations, le threat modeling, l'analyse des vulnérabilités, l'exploitation et la post-exploitation. Pour l'espace germanophone, le guide du BSI « Praxis-Leitfaden für IS-Penetrationstests » (édition 2016) décrit une démarche structurée et apporte notamment une aide à la commande. Les prestataires sérieux indiquent dans leur rapport la méthodologie utilisée.
05Déroulement et base juridique
Un test d'intrusion commence par le cadrage : objectifs, systèmes, fenêtres de test, exclusions et contacts d'urgence sont fixés par écrit. Suivent la collecte d'informations et l'analyse des vulnérabilités, l'exploitation contrôlée des découvertes pertinentes, puis le rapport avec synthèse pour la direction, détails techniques, évaluation des risques et recommandations de mesures priorisées ; un retest après correction clôt le cycle. Sur le plan juridique, l'autorisation écrite préalable du responsable habilité (« permission to test ») est indispensable : sans elle, les actions de test peuvent constituer des infractions pénales au sens des §§ 202a ff. StGB du code pénal allemand (espionnage et interception de données). Les systèmes de tiers – par exemple chez des prestataires d'hébergement, de cloud ou de SaaS – ne peuvent être testés qu'avec leur accord ou dans le cadre de leurs politiques de test ; des accords de confidentialité et de protection des données doivent figurer dans chaque contrat.
06Fréquence et déclencheurs réglementaires : NIS2, DORA, TISAX
Il n'existe pas de fréquence obligatoire universelle ; la pratique établie consiste en un test au moins annuel des systèmes critiques, complété par des tests ponctuels après des modifications majeures de l'architecture ou des applications. NIS2 (directive (UE) 2022/2555) exige à l'art. 21, paragraphe 2, point f) des politiques et procédures visant à évaluer l'efficacité des mesures de gestion des risques – les tests d'intrusion sont un moyen éprouvé à cet effet. Pour le secteur financier, DORA (règlement (UE) 2022/2554, applicable depuis le 17 janvier 2025) cite expressément les tests d'intrusion comme composante du programme de tests de résilience (art. 25) ; les entités financières désignées à cet effet par les autorités doivent en outre réaliser au moins tous les trois ans des tests de pénétration fondés sur la menace (TLPT) conformément à l'art. 26. Dans le secteur automobile, les évaluations TISAX fondées sur le catalogue VDA ISA (version 6 ; pour les évaluations commandées à partir de 2027, le catalogue successeur ISA 2027) attendent la preuve de contrôles techniques réguliers et d'une gestion efficace des vulnérabilités – les tests d'intrusion en sont un moyen de preuve courant.
