Tests d'intrusion (pentest) : obligations légales, méthodologie et bonnes pratiques

Les tests d’intrusion – ou pentests – consistent à simuler des attaques informatiques contre les systèmes d’une organisation afin d’identifier les vulnérabilités exploitables avant qu’un attaquant réel ne le fasse. Longtemps réserves aux organisations les plus matures en cybersécurité, les pentests sont devenus une obligation juridique pour un nombre croissant d’acteurs sous l’effet conjugué du RGPD, de la directive NIS2 et des réglementations sectorielles. Cet article analyse le cadre juridique applicable aux tests d’intrusion, les différentes méthodologies disponibles et les conditions de leur mise en oeuvre.

I. Le cadre juridique des tests d’intrusion

A. L’obligation de tester la sécurité sous le RGPD

L’article 32, paragraphe 1, point d) du RGPD impose une “procédure visant à tester, a analyser et à évaluer régulièrement l’efficacité des mesures techniques et organisationnelles pour assurer la sécurité du traitement”. Cette disposition constitue le fondement légal le plus explicité de l’obligation de tester la sécurité, et donc de réaliser des tests d’intrusion.

Les obligations de l’article 32 ne sont pas satisfaites par la seule mise en place de mesures de sécurité : elles exigent que ces mesures soient testées régulièrement. La CNIL a confirmé cette interprétation dans plusieurs décisions. Dans sa délibération SAN-2022-009, elle a retenu comme manquement à l’article 32 l’absence de tests réguliers de sécurité, y compris de tests d’intrusion, sur un système traitant des données sensibles.

B. NIS2 : l’évaluation de l’efficacité des mesures

L’article 21, paragraphe 2, point f) de la directive NIS2 impose des “politiques et procédures visant à évaluer l’efficacité des mesures de gestion des risques en matière de cybersécurité”. Les tests d’intrusion sont l’un des principaux moyens de satisfaire cette exigence. Pour les entités essentielles et importantes, l’autorité compétente peut exiger la réalisation de tests de sécurité dans le cadre de ses pouvoirs de supervision.

Le règlement DORA (Digital Operational Résilience Act), applicable aux entités financières à compter de janvier 2025, va encore plus loin en imposant des tests d’intrusion fondés sur la menace (TLPT – Threat-Led Penetration Testing) pour les entités significatives. Cette approche pourrait inspirer les futures exigences sectorielles sous NIS2.

C. Le cadre pénal : permission et limités

Les tests d’intrusion impliquent l’utilisation de techniques qui, sans autorisation, constitueraient des infractions pénales au sens des articles 323-1 et suivants du Code pénal (accès frauduleux à un système de traitement automatisé de données, maintien frauduleux, entrave au fonctionnement). La frontiere entre un pentest légitime et une infraction repose entièrement sur l’autorisation préalable du propriétaire du système.

Le cadre pénal accessible sur Legifrance exigé que cette autorisation soit formalisée dans un document écrit – généralement appelé “convention de pentest” ou “lettre de mission” – qui définit précisément le périmètre autorisé, les techniques admises, les dates et horaires, les contacts d’urgence et les exclusions. Sans ce document, le pentester s’expose à des poursuites pénales, même si l’objectif était la sécurisation du système.

II. Typologie des tests d’intrusion

A. Selon le niveau d’information fourni

Test en boite noire (black box). Le pentester ne dispose d’aucune information préalable sur les systèmes ciblés, si ce n’est leur existence. Il simule un attaquant externe sans accès privilégié. Cette approche est la plus réaliste pour évaluer l’exposition externe de l’organisation mais ne couvre que les vulnérabilités accessibles depuis l’extérieur.

Test en boite grise (grey box). Le pentester dispose d’informations partielles : comptes utilisateurs, architecture réseau, documentation technique. Il simule un attaquant disposant d’un accès initial (compte compromis, employé malveillant). Cette approche offre un bon équilibre entre realisme et couverture.

Test en boite blanche (white box). Le pentester dispose de l’ensemble des informations : code source, architecture complète, comptes administrateurs. Il peut réaliser une revue de code et tester des scénarios que les approches précédentes ne permettent pas d’atteindre. Cette approche maximise la couverture mais est moins representative d’une attaque réelle.

B. Selon la cible

Test d’intrusion externe. Cible les systèmes exposés sur Internet : sites web, applications SaaS, VPN, serveurs de messagerie, API. L’objectif est de déterminer si un attaquant externe peut pénétrer le système d’information.

Test d’intrusion interne. Realise depuis le réseau interne de l’organisation, il simule un attaquant ayant déjà un accès au réseau (employé malveillant, visiteur connecté au Wi-Fi, posté compromis par un rançongiciel). L’objectif est d’évaluer la capacité de progression laterale et d’élévation de privileges.

Test d’intrusion d’applications web/mobiles. Focalise sur les vulnérabilités applicatives : injection SQL, cross-site scripting (XSS), défauts d’authentification, références directes d’objets non sécurisées (IDOR). Le référentiel OWASP Top 10 sert de cadre de référence.

Test d’intrusion Wi-Fi. Évalué la sécurité des réseaux sans fil : robustesse du chiffrement, segmentation, détection des points d’accès frauduleux.

Test d’ingénierie sociale. Simule des attaques par phishing, pretexting ou manipulation téléphonique pour évaluer la sensibilisation des collaborateurs. Ce type de test nécessité une attention particulière aux aspects éthiques et juridiques.

C. Les tests fondés sur la menace (TLPT)

Les TLPT (Threat-Led Penetration Testing) représentent l’approche la plus avancée. Ils commencent par une phase de renseignement sur les menaces réelles ciblant l’organisation (Threat Intelligence), puis construisent des scénarios d’attaque réalistes bases sur les techniques, tactiques et procédures (TTP) des groupes d’attaquants identifiés. Le référentiel européen TIBER-EU, développé par la BCE, encadre cette approche pour le secteur financier.

III. Méthodologie de conduite d’un pentest

A. Phase 1 : cadrage et contractualisation

Le cadrage définit le périmètre (systèmes ciblés, adressés IP, applications), les objectifs (évaluation globale ou vérification de vulnérabilités spécifiques), les contraintes (horaires, techniques exclues, systèmes critiques a ménager) et les livrables attendus.

La convention de pentest doit préciser l’autorisation légale, les règles d’engagement (rules of engagement), les responsabilités en cas de perturbation accidentelle d’un système et les clauses de confidentialité. Le RSSI est le point de contact habituel cote client.

B. Phase 2 : reconnaissance

La reconnaissance consiste à collecter un maximum d’informations sur la cible. En boite noire, cela inclut la découverte de sous-domaines, l’énumération des services exposés, l’identification des technologies utilisées, la recherché d’informations publiques (OSINT) et l’analyse des fuites de données existantes. Cette phase est passive (sans interaction directe avec les systèmes) puis activé (scans de ports et de vulnérabilités).

C. Phase 3 : exploitation

L’exploitation consiste à utiliser les informations collectées pour tenter de compromettre les systèmes. Le pentester exploite les vulnérabilités identifiées, enchaine les techniques (chaining) pour approfondir sa pénétration et documenté chaque étape. L’objectif n’est pas de causer des dommages mais de démontrer l’impact potentiel d’une attaque réelle.

Les techniques incluent l’exploitation de vulnérabilités connues (CVE), l’exploitation de défauts de configuration, le cassage de mots de passe, l’injection de code, l’élévation de privileges et le mouvement lateral. Chaque action est tracée dans un journal détaillé.

D. Phase 4 : post-exploitation et rapport

La post-exploitation documente l’étendue de l’accès obtenu : quelles données sont accessibles, quels systèmes peuvent être contrôles, quel est l’impact potentiel sur la confidentialité, l’intégrité et la disponibilité. Le pentester doit évaluer si les données accessibles incluent des données personnelles, ce qui impliquerait des obligations au titre du RGPD en cas d’attaque réelle.

Le rapport de pentest est le livrable principal. Il doit contenir un résumé exécutif (destiné à la direction), une description détaillée de chaque vulnérabilité (criticité, preuve, impact), des recommandations de remédiation priorisées et une synthèse des risques. Ce rapport alimente directement l’analyse de risques et le plan de traitement des risques.

IV. Integration des pentests dans la stratégie de sécurité

A. Fréquence et planification

Un pentest annuel est le minimum pour satisfaire les exigences du RGPD et de NIS2. Les bonnes pratiques recommandent un pentest externe annuel complet, un pentest interne annuel, des tests ciblés après chaque mise en production majeure et des scans de vulnérabilités automatisés mensuels ou hebdomadaires entre deux pentests. La checklist de conformité NIS2 intègre la planification des tests.

B. Articulation avec les audits de sécurité

Les tests d’intrusion sont complémentaires des audits de sécurité informatique. L’audit évalué la conformité à un référentiel (ISO 27001, RGPD, NIS2), la documentation et les processus. Le pentest évalué l’efficacité réelle des mesures de sécurité en conditions opérationnelles. Un système peut être conforme sur le papier et vulnerableble dans les faits. L’inverse est également possible : un système non conforme documentairement peut être techniquement robuste.

Le RGPD impose un audit régulier qui doit inclure un volet sécurité technique, idéalement alimente par les résultats des pentests. La politique de sécurité doit définir le cadre et la fréquence des tests d’intrusion.

C. Gestion des vulnérabilités identifiées

Le pentest n’a de valeur que si les vulnérabilités identifiées sont corrigées. Le processus de remédiation doit être formalisé : priorisation selon la criticité, attribution des actions correctives, délais de correction, vérification de la correction (retest). Les vulnérabilités critiques et hautes doivent être corrigées dans des délais courts (jours a semaines), les vulnérabilités moyennes dans un délai raisonnable (semaines a mois).

Les résultats des pentests doivent alimenter la gestion des incidents de sécurité lorsqu’ils révèlent des compromissions réelles (backdoors, présence d’un attaquant). Dans ce cas, le pentest se transformé en investigation d’incident.

V. Choix du prestataire et qualifications

A. Qualifications et certifications

Le choix du prestataire de pentest est critique. En France, l’ANSSI délivré la qualification PASSI (Prestataires d’Audit de la Sécurité des Systèmes d’Information) qui atteste de la compétence technique et de la rigueur méthodologique du prestataire. La qualification PASSI est obligatoire pour certains périmètres (OIV, administrations).

Les certifications individuelles des pentesters (OSCP, OSCE, GPEN, CEH) constituent des indicateurs de compétence mais ne remplacent pas la qualification PASSI qui porte sur l’organisation dans son ensemble.

B. Critères de sélection

Au-delà de la qualification, les critères de sélection incluent l’expérience sectorielle (un pentest en environnement industriel OT n’a rien a voir avec un pentest d’application web), la méthodologie documentée, les références verifiables, l’assurance responsabilité civile professionnelle et la capacité a produire un rapport exploitable.

L’ENISA publié des recommandations sur la sélection des prestataires d’audit et de test en cybersécurité, utiles pour les organisations qui conduisent cette démarche pour la première fois. La couverture des risques lies aux fuites de données doit être explicitement prévue dans le contrat de pentest.

FAQ

Les tests d’intrusion sont-ils légalement obligatoires ?

Oui, indirectement mais clairement. L’article 32-1-d du RGPD impose de “tester, analyser et évaluer régulièrement l’efficacité des mesures de sécurité”, et les tests d’intrusion sont le moyen le plus reconnu de satisfaire cette exigence pour les systèmes techniques. NIS2 impose également l’évaluation de l’efficacité des mesures de sécurité. La CNIL a sanctionné des organisations pour l’absence de tests réguliers. Bien que le texte ne mentionné pas le mot “pentest”, l’interprétation concordante des autorités et de la doctrine impose de facto leur réalisation.

Quelle est la différence entre un test d’intrusion et un scan de vulnérabilités ?

Le scan de vulnérabilités est un processus automatisé qui identifie les failles connues (CVE) en comparant la configuration des systèmes à une base de vulnérabilités. Il est rapide et peu coûteux mais ne détecté que les vulnérabilités connues et ne validé pas leur exploitabilité. Le test d’intrusion est conduit par un expert humain qui exploite les vulnérabilités, enchaine les techniques et simule une attaque réelle. Il est plus long, plus coûteux, mais infiniment plus réaliste. Les deux approches sont complémentaires : scans fréquents entre deux pentests annuels.

Comment cadrer le périmètre d’un test d’intrusion ?

Le périmètre doit être défini en fonction des risques identifiés par l’analyse de risques : les systèmes les plus critiques et les plus exposés sont prioritaires. Il faut inclure les adressés IP et domaines autorisés, les applications ciblés, les comptes de test éventuels (boite grise), les systèmes exclus (systèmes critiques intolerables à la moindre perturbation), les horaires autorisés et les techniques exclues. Tout doit être formalisé dans la convention de pentest signée par les deux parties.

À quelle fréquence réaliser un test d’intrusion ?

Au minimum une fois par an sur le périmètre global. Des tests complémentaires doivent être réalisés après chaque évolution majeure du système d’information (nouvelle application, changement d’architecture, migration cloud). Les organisations a haut risque (secteur financier, santé, infrastructures critiques) devraient envisager des tests semestriels. Entre deux pentests, des scans de vulnérabilités automatisés mensuels permettent de maintenir la visibilité sur les nouvelles failles.