Test d’intrusion : pourquoi le cadre légal commence par l’autorisation
Un test d’intrusion reproduit des techniques d’attaque pour repérer des failles avant qu’elles ne soient exploitées. Mais une intention défensive ne suffit pas à rendre une intervention licite : l’accès aux systèmes doit être autorisé par la personne ou l’organisation qui en a le contrôle.
En France, les articles 323-1 à 323-3 du Code pénal encadrent notamment l’accès frauduleux à un système, l’entrave à son fonctionnement et la modification de données. Selon Légifrance, c’est le caractère frauduleux de l’accès ou de l’action qui compte ; l’absence d’autorisation écrite peut donc exposer à un risque pénal et compliquer la preuve du mandat. Une autorisation préalable écrite constitue une protection essentielle pour le client comme pour le prestataire.
La loi Godfrain, adoptée en 1988 puis intégrée au Code pénal, forme l’un des repères historiques de ce cadre. Selon l’ANSSI, un test doit être préparé et défini avec soin : lancer un scan par curiosité sur le réseau d’un tiers n’équivaut pas à une mission autorisée.
Les garanties à obtenir avant le premier test :
- Autorisation écrite signée par une personne habilitée
- Périmètre du test défini et vérifiable
- Dates, horaires et limites d’intervention convenus
- Contacts d’urgence et procédure d’arrêt identifiés
Contrat de prestation : définir le périmètre et les règles d’engagement
Une fois l’autorisation envisagée, le contrat de prestation transforme l’accord de principe en consignes opérationnelles. Il doit nommer les parties, désigner le signataire habilité et décrire sans ambiguïté les systèmes concernés : domaines, adresses IP, applications, interfaces de programmation et environnements cloud.
Imaginons qu’une société autorise l’audit de son portail client hébergé chez un fournisseur externe. Cette permission ne couvre pas automatiquement les infrastructures du prestataire cloud, ni les services SaaS accessibles depuis le portail. Il faut vérifier les règles du fournisseur et obtenir les autorisations requises avant tout essai sur des systèmes tiers.
Le document précise aussi les méthodes permises, les actions interdites et les conditions d’interruption. Un test de déni de service, une suppression de données ou une modification en production peuvent entraîner des dommages ; ils ne doivent jamais être déduits d’une autorisation générale.
Les clauses qui rendent le mandat exploitable :
- Actifs inclus et exclusions explicites
- Plages horaires et durée de la mission
- Techniques autorisées et actions prohibées
- Règles d’escalade en cas de découverte critique
Selon l’ANSSI, la formalisation de la mission aide à encadrer les tests et leur déroulement. Les modalités doivent également traiter la responsabilité juridique, l’assurance du prestataire, l’accord de confidentialité et la propriété intellectuelle des scripts, preuves et livrables.
| Clause contractuelle | Précision attendue | Risque réduit |
|---|---|---|
| Autorisation | Signataire et systèmes autorisés | Contestations sur le mandat |
| Périmètre | Actifs inclus et exclusions | Test hors cible |
| Règles d’engagement | Horaires, limites et arrêt d’urgence | Interruption non maîtrisée |
| Confidentialité | Accès, conservation et diffusion des résultats | Exposition d’informations sensibles |
Protection des données : encadrer les découvertes sensibles
Le périmètre peut inclure des environnements où circulent des données personnelles. Dans ce cas, le client et le prestataire doivent anticiper la protection des données : limiter l’accès au strict nécessaire, éviter les copies inutiles et sécuriser les éléments de preuve recueillis.
Selon le RGPD, le rôle du prestataire doit être évalué au regard des opérations réellement effectuées. Lorsqu’il traite des données personnelles pour le compte du client, les exigences applicables à la relation de sous-traitance, notamment celles de l’article 28, doivent être examinées. La mission peut aussi nécessiter une documentation dans les processus de conformité réglementaire de l’organisation.
Supposons qu’un auditeur repère des journaux accessibles contenant des coordonnées d’utilisateurs. Il doit prévenir le contact désigné, éviter de télécharger davantage de fichiers et produire une preuve réduite ou pseudonymisée. Le client évalue ensuite si l’incident répond à la définition d’une violation de données et si une notification est requise ; le délai de 72 heures concerne la notification à l’autorité de contrôle lorsqu’elle est exigée par l’article 33.
Les mesures de protection à prévoir dans la mission :
- Accès limité aux données nécessaires à la vérification
- Preuves expurgées ou pseudonymisées dans les livrables
- Conservation et destruction définies contractuellement
- Notification rapide au contact de sécurité désigné
Rapport d’audit : transformer les constats en corrections utiles
Lorsque les essais se terminent, le rapport d’audit doit permettre aux équipes techniques et aux décideurs d’agir. Une simple liste de vulnérabilités ne suffit pas : chaque constat gagne à relier une preuve maîtrisée, un scénario d’exploitation, un impact métier et une recommandation concrète.
La criticité technique ne raconte pas toujours toute l’histoire. Une faille importante sur un service isolé, sans données sensibles ni connexion à d’autres systèmes, peut présenter un impact opérationnel différent d’une faiblesse exploitable sur une application exposée reliée aux comptes clients. Le rapport doit expliciter cette différence sans minimiser le risque technique.
Selon l’OWASP Testing Guide, les tests s’inscrivent dans une démarche structurée plutôt que dans l’usage isolé d’outils. La restitution peut ainsi classer les constats, préciser les limites du test et proposer des corrections ordonnées. Le suivi doit ensuite vérifier les correctifs, sans présumer qu’une vulnérabilité a disparu avant un contrôle approprié.
Les éléments essentiels d’une restitution exploitable :
- Résumé des risques destiné aux responsables métier
- Description reproductible des vulnérabilités constatées
- Évaluation de l’impact et des conditions d’exploitation
- Correctifs priorisés et vérification après intervention
| Élément du rapport | Question traitée | Utilité opérationnelle |
|---|---|---|
| Contexte et périmètre | Qu’a couvert la mission ? | Comprendre les limites des résultats |
| Preuve de vulnérabilité | Quel défaut a été observé ? | Reproduire et confirmer le constat |
| Impact métier | Quelles conséquences sont plausibles ? | Arbitrer les priorités de correction |
| Recommandations | Quelle mesure réduit le risque ? | Planifier les travaux et leur contrôle |
Conformité réglementaire : organiser le suivi après le test
Le cadre ne s’arrête pas à la remise du rapport. L’organisation doit décider qui corrige, dans quel ordre et selon quel calendrier, puis conserver les éléments utiles pour démontrer son obligation de sécurité. Cette démarche relie les constats techniques à la gouvernance des risques et aux exigences applicables à son secteur.
Une entreprise soumise à des exigences particulières peut intégrer le test dans ses contrôles périodiques, sans considérer qu’un pentest garantit à lui seul la conformité. Le périmètre, la méthode et les preuves doivent correspondre à l’objectif poursuivi. Les résultats restent sensibles : l’accès au rapport doit être limité aux personnes qui en ont besoin.
Le responsable sécurité peut, par exemple, attribuer chaque constat à une équipe, fixer une échéance selon sa gravité et programmer une vérification ciblée. Ce suivi évite qu’un rapport techniquement solide reste sans effet et permet de documenter les arbitrages lorsque certaines corrections demandent davantage de temps.
Les pratiques de suivi à inscrire dans la gouvernance :
- Responsables nommés pour chaque action corrective
- Échéances adaptées à la gravité et au contexte
- Accès restreint au rapport et aux preuves
- Contrôle documenté des corrections appliquées
Un test d’intrusion bien encadré associe donc mandat vérifiable, périmètre précis, traitement maîtrisé des données et restitution suivie d’actions. Cette cohérence protège les personnes, les systèmes et les équipes qui conduisent l’évaluation.
Sources : Code pénal, articles 323-1 à 323-3, Légifrance ; Règlement (UE) 2016/679, articles 28, 30, 32 et 33 ; ANSSI, Guide relatif aux tests d’intrusion ; OWASP, Testing Guide.
Transformer l’analyse en décision
Les meilleures décisions reposent sur un cadre compréhensible, quelques critères vérifiables et une étape suivante clairement définie. Testez la méthode à petite échelle, mesurez le résultat puis ajustez avant de généraliser.
Votre checklist
- Définir le résultat attendu
- Identifier trois critères prioritaires
- Prévoir une mesure de contrôle
- Fixer une date de réévaluation
