En bref
Une autorisation de test d’intrusion est un écrit signé par une personne habilitée à engager l’organisation, qui délimite ce que le prestataire a le droit de faire. Elle indique le périmètre et ses exclusions, les fenêtres horaires, les adresses IP sources des tests, les contacts joignables, la clause d’arrêt immédiat, le traitement des données et les signataires. Sans elle, un accès à un système d’information peut être poursuivi sur le fondement de l’article 323-1 du code pénal. Faites relire le texte par un juriste avant de le signer.
Pourquoi faut-il une autorisation écrite avant un test d’intrusion ?
Un test d’intrusion reproduit les gestes d’un attaquant : contourner une authentification, lire des données qui ne sont pas les siennes, tenter d’élever ses droits. Ce qui distingue le test de l’attaque tient à une seule chose, l’accord préalable de quelqu’un qui avait le pouvoir de le donner. Sans cet accord, le prestataire n’a aucune justification à opposer.
L’article 323-1 du code pénal punit le fait d’accéder ou de se maintenir frauduleusement dans tout ou partie d’un système de traitement automatisé de données. Les articles suivants visent notamment le fait d’entraver ou de fausser le fonctionnement d’un tel système (article 323-2), et celui d’y introduire, d’en extraire ou d’en modifier frauduleusement des données (article 323-3). Le texte figure au livre III, titre II, chapitre III du code pénal, que l’on lit sur Légifrance.
C’est le caractère frauduleux de l’accès qui fait la différence, et c’est l’autorisation écrite qui l’écarte. Elle protège les deux parties : le client, qui sait ce qui sera tenté et dans quelles limites, et le prestataire, qui peut prouver qu’il n’a agi que dans ce cadre.
Que doit contenir une autorisation de test d’intrusion ?
Une page, signée et datée, suffit si chaque rubrique est précise. Elle comprend les éléments suivants.
- Les parties : raison sociale, représentant légal et identité du prestataire, avec la référence du contrat ou de la commande auquel l’autorisation se rattache.
- Le périmètre : noms de domaine, adresses IP ou plages, applications, API, comptes cloud, dépôts de code. Une liste vaut mieux qu’une description du type « notre site », qui laisse un doute sur les sous-domaines et les environnements.
- Les exclusions : systèmes, données ou actions interdits, nommés avec la même précision que le périmètre. Le guide NIST SP 800-115 recommande de lister aussi les systèmes exclus, au minimum par adresse IP et de préférence par nom.
- Les actions autorisées et interdites : types de tests permis, niveau d’information fourni (boîte noire, grise ou blanche), et interdits écrits en toutes lettres, comme le déni de service, la destruction ou la modification de données de production, ou l’envoi de messages en masse.
- Les fenêtres : dates de début et de fin, plages horaires autorisées, périodes interdites (clôture comptable, pic d’activité, mise en production).
- Les adresses IP sources : celles depuis lesquelles le prestataire émettra ses tests, pour que vos équipes distinguent le test d’une attaque réelle et puissent, si l’objectif de la mission le permet, les placer sur une liste d’autorisation.
- Les contacts : un référent technique joignable pendant les fenêtres, un suppléant, un contact côté prestataire, avec un numéro et un canal d’urgence. La liste des personnes informées de la mission, et de celles qui ne le sont pas.
- La clause d’arrêt : qui peut suspendre ou arrêter la mission, par quel canal, avec quel effet immédiat, et ce que fait le prestataire s’il découvre un incident réel ou la trace d’une intrusion antérieure.
- Le traitement des données : ce que le prestataire peut consulter, copier ou conserver, où, sous quelle protection, pendant combien de temps, et comment il détruit les éléments en fin de mission.
- Les tiers : l’accord écrit de l’hébergeur, de l’infogéreur ou de tout opérateur dont les systèmes figurent dans le périmètre.
- Les signataires : leur nom, leur qualité, la date, et la contresignature du prestataire.
Qui peut signer, et pourquoi la qualité du signataire compte ?
Le signataire doit avoir le pouvoir d’autoriser un accès aux systèmes visés : le représentant légal, ou un délégataire dont la délégation couvre ce périmètre. Un responsable informatique peut avoir la main technique sans avoir le pouvoir d’engager la société, et un chef de projet ne peut pas autoriser l’accès à un système qui appartient à quelqu’un d’autre.
Quand les systèmes appartiennent à un tiers, hébergeur, filiale ou client dont vous êtes le prestataire, c’est le propriétaire qui autorise, ou qui donne son accord écrit à votre autorisation. Le guide NIST SP 800-115 le dit ainsi : si l’organisation ne contrôle pas une partie de son réseau, le propriétaire de cette partie doit en général consentir par écrit au plan d’évaluation.
En cas de doute sur l’étendue du pouvoir de signature, faites signer deux personnes : la direction, qui engage l’organisation, et le responsable technique des systèmes, qui connaît ce qui s’y trouve.
Quelle différence entre autorisation, convention et règles d’engagement ?
La convention, ou le contrat, fixe le prix, la responsabilité, la confidentialité et la propriété du rapport. L’autorisation est la pièce courte que l’on peut montrer à un hébergeur, à un centre de supervision ou à un tiers qui s’inquiète d’un trafic inhabituel : elle prouve que le test est voulu.
Les règles d’engagement détaillent la conduite des tests et prolongent l’autorisation. Le guide NIST SP 800-115 distingue le plan d’évaluation et les règles d’engagement : ces dernières contiennent les mêmes informations, et autorisent en plus des actions que la politique de l’organisation interdit d’ordinaire, comme compromettre des systèmes. Il suggère aussi une note d’une ou deux pages que les évaluateurs peuvent présenter aux utilisateurs concernés, avec un contact à joindre.
Chez Reconmind, rien ne démarre avant une autorisation écrite précisant le périmètre, les horaires et les actions interdites. Ces rubriques sont passées en revue au cadrage, avant toute action technique.
Quelle trame suivre pour un document d’une page ?
- 1Objet de l’autorisation et référence du contrat.
- 2Parties et signataires, avec leur qualité.
- 3Périmètre : domaines, adresses, applications, comptes, dépôts.
- 4Exclusions et actions interdites.
- 5Fenêtres autorisées et périodes interdites.
- 6Adresses IP sources et identifiants des intervenants.
- 7Contacts, canal d’urgence et personnes informées.
- 8Clause d’arrêt et conduite à tenir en cas d’incident réel.
- 9Données : accès, conservation, chiffrement, destruction, et mentions de sous-traitance si des données personnelles sont concernées.
- 10Accord des tiers concernés, signatures et dates.
Que dire des données personnelles que le test peut atteindre ?
Un test peut rendre visibles des données personnelles : fichiers clients, comptes d’utilisateurs, échanges. Dès que le prestataire peut y accéder pour votre compte, il agit comme sous-traitant au sens du RGPD, et le contrat doit comporter les mentions qui encadrent cette situation. La CNIL publie des clauses types et des fiches pratiques pour la relation avec un sous-traitant.
Le plus simple est de limiter l’exposition : environnement de recette, données fictives ou anonymisées, comptes de test. Le guide NIST SP 800-115 rappelle aussi que des captures de trafic peuvent contenir des données sensibles qui n’appartiennent pas à l’organisation, ou des données personnelles de salariés, et que le service juridique doit définir les règles de manipulation avant le début.
Quels pièges retrouve-t-on le plus souvent ?
- Un périmètre écrit en langage courant, sans noms de domaine ni adresses, qui laisse un doute sur les sous-domaines et les environnements.
- Un actif hébergé chez un tiers qui n’a jamais été prévenu : le test déclenche son alerte, et ses conditions d’utilisation peuvent interdire les tests non annoncés.
- Des adresses IP sources absentes : le centre de supervision traite le test comme une attaque réelle, coupe l’accès ou déclenche une procédure de notification.
- Une fenêtre trop large, qui recouvre une période de production sensible.
- Aucun contact joignable le soir ou le week-end alors que la fenêtre y est ouverte.
- Des données personnelles accessibles sans clause de sous-traitance.
- Une autorisation signée par quelqu’un qui n’avait pas le pouvoir de la donner, découverte le jour où un hébergeur la conteste.
À retenir
- 1L’autorisation écrite est ce qui distingue un test d’une intrusion : elle précède toute action technique.
- 2Elle contient au minimum les parties, le périmètre, les exclusions, les fenêtres, les adresses IP sources, les contacts, la clause d’arrêt, le traitement des données, l’accord des tiers et les signataires.
- 3Le signataire doit pouvoir engager l’organisation sur les systèmes visés, et l’accord écrit des hébergeurs tiers est un point souvent oublié.
- 4Ce guide ne remplace pas la relecture par un juriste : faites valider le texte avant de le signer.
Sources citées
- SP 800-115, Technical Guide to Information Security Testing and Assessment, NIST
- Rules of Engagement (ROE), glossaire, NIST, Computer Security Resource Center
- Travailler avec un sous-traitant, CNIL