Les tests d’intrusion – ou pentests – consistent a simuler des attaques informatiques contre les systemes d’une organisation afin d’identifier les vulnerabilites exploitables avant qu’un attaquant reel ne le fasse. Longtemps reserves aux organisations les plus matures en cybersecurite, les pentests sont devenus une obligation juridique pour un nombre croissant d’acteurs sous l’effet conjugue du RGPD, de la directive NIS2 et des reglementations sectorielles. Cet article analyse le cadre juridique applicable aux tests d’intrusion, les differentes methodologies disponibles et les conditions de leur mise en oeuvre.

I. Le cadre juridique des tests d’intrusion

A. L’obligation de tester la securite sous le RGPD

L’article 32, paragraphe 1, point d) du RGPD impose une “procedure visant a tester, a analyser et a evaluer regulierement l’efficacite des mesures techniques et organisationnelles pour assurer la securite du traitement”. Cette disposition constitue le fondement legal le plus explicite de l’obligation de tester la securite, et donc de realiser des tests d’intrusion.

Les obligations de l’article 32 ne sont pas satisfaites par la seule mise en place de mesures de securite : elles exigent que ces mesures soient testees regulierement. La CNIL a confirme cette interpretation dans plusieurs decisions. Dans sa deliberation SAN-2022-009, elle a retenu comme manquement a l’article 32 l’absence de tests reguliers de securite, y compris de tests d’intrusion, sur un systeme traitant des donnees sensibles.

B. NIS2 : l’evaluation de l’efficacite des mesures

L’article 21, paragraphe 2, point f) de la directive NIS2 impose des “politiques et procedures visant a evaluer l’efficacite des mesures de gestion des risques en matiere de cybersecurite”. Les tests d’intrusion sont l’un des principaux moyens de satisfaire cette exigence. Pour les entites essentielles et importantes, l’autorite competente peut exiger la realisation de tests de securite dans le cadre de ses pouvoirs de supervision.

Le reglement DORA (Digital Operational Resilience Act), applicable aux entites financieres a compter de janvier 2025, va encore plus loin en imposant des tests d’intrusion fondes sur la menace (TLPT – Threat-Led Penetration Testing) pour les entites significatives. Cette approche pourrait inspirer les futures exigences sectorielles sous NIS2.

C. Le cadre penal : permission et limites

Les tests d’intrusion impliquent l’utilisation de techniques qui, sans autorisation, constitueraient des infractions penales au sens des articles 323-1 et suivants du Code penal (acces frauduleux a un systeme de traitement automatise de donnees, maintien frauduleux, entrave au fonctionnement). La frontiere entre un pentest legitime et une infraction repose entierement sur l’autorisation prealable du proprietaire du systeme.

Le cadre penal accessible sur Legifrance exige que cette autorisation soit formalisee dans un document ecrit – generalement appele “convention de pentest” ou “lettre de mission” – qui definit precisement le perimetre autorise, les techniques admises, les dates et horaires, les contacts d’urgence et les exclusions. Sans ce document, le pentester s’expose a des poursuites penales, meme si l’objectif etait la securisation du systeme.

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 prealable sur les systemes cibles, si ce n’est leur existence. Il simule un attaquant externe sans acces privilegie. Cette approche est la plus realiste pour evaluer l’exposition externe de l’organisation mais ne couvre que les vulnerabilites accessibles depuis l’exterieur.

Test en boite grise (grey box). Le pentester dispose d’informations partielles : comptes utilisateurs, architecture reseau, documentation technique. Il simule un attaquant disposant d’un acces initial (compte compromis, employe malveillant). Cette approche offre un bon equilibre entre realisme et couverture.

Test en boite blanche (white box). Le pentester dispose de l’ensemble des informations : code source, architecture complete, comptes administrateurs. Il peut realiser une revue de code et tester des scenarios que les approches precedentes ne permettent pas d’atteindre. Cette approche maximise la couverture mais est moins representative d’une attaque reelle.

B. Selon la cible

Test d’intrusion externe. Cible les systemes exposes sur Internet : sites web, applications SaaS, VPN, serveurs de messagerie, API. L’objectif est de determiner si un attaquant externe peut penetrer le systeme d’information.

Test d’intrusion interne. Realise depuis le reseau interne de l’organisation, il simule un attaquant ayant deja un acces au reseau (employe malveillant, visiteur connecte au Wi-Fi, poste compromis par un rancongiciel). L’objectif est d’evaluer la capacite de progression laterale et d’elevation de privileges.

Test d’intrusion d’applications web/mobiles. Focalise sur les vulnerabilites applicatives : injection SQL, cross-site scripting (XSS), defauts d’authentification, references directes d’objets non securisees (IDOR). Le referentiel OWASP Top 10 sert de cadre de reference.

Test d’intrusion Wi-Fi. Evalue la securite des reseaux sans fil : robustesse du chiffrement, segmentation, detection des points d’acces frauduleux.

Test d’ingenierie sociale. Simule des attaques par phishing, pretexting ou manipulation telephonique pour evaluer la sensibilisation des collaborateurs. Ce type de test necessite une attention particuliere aux aspects ethiques et juridiques.

C. Les tests fondes sur la menace (TLPT)

Les TLPT (Threat-Led Penetration Testing) representent l’approche la plus avancee. Ils commencent par une phase de renseignement sur les menaces reelles ciblant l’organisation (Threat Intelligence), puis construisent des scenarios d’attaque realistes bases sur les techniques, tactiques et procedures (TTP) des groupes d’attaquants identifies. Le referentiel europeen TIBER-EU, developpe par la BCE, encadre cette approche pour le secteur financier.

III. Methodologie de conduite d’un pentest

A. Phase 1 : cadrage et contractualisation

Le cadrage definit le perimetre (systemes cibles, adresses IP, applications), les objectifs (evaluation globale ou verification de vulnerabilites specifiques), les contraintes (horaires, techniques exclues, systemes critiques a menager) et les livrables attendus.

La convention de pentest doit preciser l’autorisation legale, les regles d’engagement (rules of engagement), les responsabilites en cas de perturbation accidentelle d’un systeme et les clauses de confidentialite. Le RSSI est le point de contact habituel cote client.

B. Phase 2 : reconnaissance

La reconnaissance consiste a collecter un maximum d’informations sur la cible. En boite noire, cela inclut la decouverte de sous-domaines, l’enumeration des services exposes, l’identification des technologies utilisees, la recherche d’informations publiques (OSINT) et l’analyse des fuites de donnees existantes. Cette phase est passive (sans interaction directe avec les systemes) puis active (scans de ports et de vulnerabilites).

C. Phase 3 : exploitation

L’exploitation consiste a utiliser les informations collectees pour tenter de compromettre les systemes. Le pentester exploite les vulnerabilites identifiees, enchaine les techniques (chaining) pour approfondir sa penetration et documente chaque etape. L’objectif n’est pas de causer des dommages mais de demontrer l’impact potentiel d’une attaque reelle.

Les techniques incluent l’exploitation de vulnerabilites connues (CVE), l’exploitation de defauts de configuration, le cassage de mots de passe, l’injection de code, l’elevation de privileges et le mouvement lateral. Chaque action est tracee dans un journal detaille.

D. Phase 4 : post-exploitation et rapport

La post-exploitation documente l’etendue de l’acces obtenu : quelles donnees sont accessibles, quels systemes peuvent etre controles, quel est l’impact potentiel sur la confidentialite, l’integrite et la disponibilite. Le pentester doit evaluer si les donnees accessibles incluent des donnees personnelles, ce qui impliquerait des obligations au titre du RGPD en cas d’attaque reelle.

Le rapport de pentest est le livrable principal. Il doit contenir un resume executif (destine a la direction), une description detaillee de chaque vulnerabilite (criticite, preuve, impact), des recommandations de remediation priorisees et une synthese des risques. Ce rapport alimente directement l’analyse de risques et le plan de traitement des risques.

IV. Integration des pentests dans la strategie de securite

A. Frequence 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 cibles apres chaque mise en production majeure et des scans de vulnerabilites automatises mensuels ou hebdomadaires entre deux pentests. La checklist de conformite NIS2 integre la planification des tests.

B. Articulation avec les audits de securite

Les tests d’intrusion sont complementaires des audits de securite informatique. L’audit evalue la conformite a un referentiel (ISO 27001, RGPD, NIS2), la documentation et les processus. Le pentest evalue l’efficacite reelle des mesures de securite en conditions operationnelles. Un systeme peut etre conforme sur le papier et vulnerableble dans les faits. L’inverse est egalement possible : un systeme non conforme documentairement peut etre techniquement robuste.

Le RGPD impose un audit regulier qui doit inclure un volet securite technique, idealement alimente par les resultats des pentests. La politique de securite doit definir le cadre et la frequence des tests d’intrusion.

C. Gestion des vulnerabilites identifiees

Le pentest n’a de valeur que si les vulnerabilites identifiees sont corrigees. Le processus de remediation doit etre formalise : priorisation selon la criticite, attribution des actions correctives, delais de correction, verification de la correction (retest). Les vulnerabilites critiques et hautes doivent etre corrigees dans des delais courts (jours a semaines), les vulnerabilites moyennes dans un delai raisonnable (semaines a mois).

Les resultats des pentests doivent alimenter la gestion des incidents de securite lorsqu’ils revelent des compromissions reelles (backdoors, presence d’un attaquant). Dans ce cas, le pentest se transforme 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 delivre la qualification PASSI (Prestataires d’Audit de la Securite des Systemes d’Information) qui atteste de la competence technique et de la rigueur methodologique du prestataire. La qualification PASSI est obligatoire pour certains perimetres (OIV, administrations).

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

B. Criteres de selection

Au-dela de la qualification, les criteres de selection incluent l’experience sectorielle (un pentest en environnement industriel OT n’a rien a voir avec un pentest d’application web), la methodologie documentee, les references verifiables, l’assurance responsabilite civile professionnelle et la capacite a produire un rapport exploitable.

L’ENISA publie des recommandations sur la selection des prestataires d’audit et de test en cybersecurite, utiles pour les organisations qui conduisent cette demarche pour la premiere fois. La couverture des risques lies aux fuites de donnees doit etre explicitement prevue dans le contrat de pentest.

FAQ

Les tests d’intrusion sont-ils legalement obligatoires ?

Oui, indirectement mais clairement. L’article 32-1-d du RGPD impose de “tester, analyser et evaluer regulierement l’efficacite des mesures de securite”, et les tests d’intrusion sont le moyen le plus reconnu de satisfaire cette exigence pour les systemes techniques. NIS2 impose egalement l’evaluation de l’efficacite des mesures de securite. La CNIL a sanctionne des organisations pour l’absence de tests reguliers. Bien que le texte ne mentionne pas le mot “pentest”, l’interpretation concordante des autorites et de la doctrine impose de facto leur realisation.

Quelle est la difference entre un test d’intrusion et un scan de vulnerabilites ?

Le scan de vulnerabilites est un processus automatise qui identifie les failles connues (CVE) en comparant la configuration des systemes a une base de vulnerabilites. Il est rapide et peu couteux mais ne detecte que les vulnerabilites connues et ne valide pas leur exploitabilite. Le test d’intrusion est conduit par un expert humain qui exploite les vulnerabilites, enchaine les techniques et simule une attaque reelle. Il est plus long, plus couteux, mais infiniment plus realiste. Les deux approches sont complementaires : scans frequents entre deux pentests annuels.

Comment cadrer le perimetre d’un test d’intrusion ?

Le perimetre doit etre defini en fonction des risques identifies par l’analyse de risques : les systemes les plus critiques et les plus exposes sont prioritaires. Il faut inclure les adresses IP et domaines autorises, les applications cibles, les comptes de test eventuels (boite grise), les systemes exclus (systemes critiques intolerables a la moindre perturbation), les horaires autorises et les techniques exclues. Tout doit etre formalise dans la convention de pentest signee par les deux parties.

A quelle frequence realiser un test d’intrusion ?

Au minimum une fois par an sur le perimetre global. Des tests complementaires doivent etre realises apres chaque evolution majeure du systeme d’information (nouvelle application, changement d’architecture, migration cloud). Les organisations a haut risque (secteur financier, sante, infrastructures critiques) devraient envisager des tests semestriels. Entre deux pentests, des scans de vulnerabilites automatises mensuels permettent de maintenir la visibilite sur les nouvelles failles.