En bref
Trois choses conditionnent la rentabilité d’un test d’intrusion : des comptes de test sur chaque rôle, dans deux organisations distinctes, disponibles le premier jour ; un périmètre écrit et une autorisation signée, y compris par vos hébergeurs tiers ; un environnement représentatif avec des données ressemblant au réel. Quand ces trois éléments manquent, un tiers du budget part en mise en place au lieu de partir en recherche de vulnérabilités.
Côté technique
- Deux comptes par rôle, dans deux organisations ou locataires différents. Sans cela, aucun défaut de cloisonnement n’est démontrable.
- Un environnement de préproduction représentatif : même code, même configuration, données volumétriquement et structurellement proches du réel.
- Les identifiants et jetons nécessaires, transmis par un canal sûr, valides pendant toute la durée de la mission, y compris après une rotation automatique.
- La documentation d’API si elle existe (OpenAPI, schéma GraphQL), même incomplète ou périmée : c’est un point de départ, pas un engagement.
- Un accès en lecture au code pour les missions en boîte grise, limité dans le temps.
- Le retrait temporaire de votre adresse de test des listes de blocage automatique, ou une liste d’autorisation : sinon la moitié du temps sert à contourner votre propre pare-feu applicatif.
- Les coordonnées d’un contact technique joignable rapidement pendant les heures de test.
Côté organisationnel
- Un périmètre écrit : domaines, adresses IP, dépôts, comptes cloud, applications, et ce qui est explicitement exclu.
- Les fenêtres d’intervention autorisées, et celles qui sont interdites (clôture comptable, pic d’activité, mise en production).
- La liste des personnes informées de la mission. Pour un test d’intrusion classique, informez vos équipes techniques ; pour une mission red team, c’est l’inverse.
- Une procédure d’arrêt immédiat : qui peut interrompre la mission, par quel canal, et qui prévenir.
- La date de restitution bloquée dans les agendas dès le début, avec les équipes de développement présentes : c’est le moment où la mission se transforme en correctifs.
Côté juridique
- L’autorisation de test signée par une personne habilitée, sur un périmètre explicite et daté.
- L’accord écrit de vos hébergeurs et prestataires tiers pour les actifs qu’ils opèrent. C’est un point souvent oublié, qui retarde les démarrages.
- L’accord de confidentialité, et le cas échéant un avenant de traitement des données.
- Les modalités de conservation et de destruction des éléments collectés, écrites dans la convention.
Pendant la mission
Prévoyez un canal de communication direct (messagerie dédiée ou salon partagé) et un point d’avancement court à mi-parcours. Deux raisons : une vulnérabilité critique doit pouvoir vous être signalée dans l’heure, et un blocage technique de notre côté (compte expiré, environnement indisponible) doit se résoudre en minutes et non en jours.
Prévenez aussi vos équipes de détection pour un test classique. Sans cela, elles passeront la semaine à traiter nos requêtes comme un incident réel, ce qui fait perdre du temps à tout le monde. Pour une mission red team, le silence est au contraire la règle : c’est leur réaction que l’on mesure.
Quelles données de test fournir, et lesquelles éviter ?
La question revient à chaque cadrage, et elle mérite une réponse écrite avant le premier jour de test.
- Des données fictives mais structurées comme le réel : mêmes formats, mêmes volumes approximatifs, mêmes relations entre objets. Un jeu de données vide masque les défauts de cloisonnement, puisqu’il n’y a rien à lire chez le voisin.
- Des données anonymisées si vous recopiez de la production. Une anonymisation partielle laisse des données personnelles dans un environnement souvent moins protégé, et ces données restent soumises aux règles de protection des données personnelles.
- Aucun secret de production : clés d’API, jetons et mots de passe de comptes réels n’ont pas leur place dans un environnement de test.
- Des intégrations tierces en mode bac à sable : paiement, messagerie, SMS. Sans cela, une mission peut déclencher de vrais envois ou de vrais débits.
- Des objets de chaque type, créés d’avance par chaque compte, pour que le test de cloisonnement démarre dès le premier jour.
Que faire quand on ne peut pas tester en préproduction ?
Cela arrive : pas d’environnement équivalent, ou un environnement trop éloigné de la production pour que les résultats soient transposables. Le test en production reste possible, à condition de le cadrer pour limiter l’impact. Le guide NIST SP 800-115 rappelle que ces tests peuvent perturber les systèmes évalués, ce qui justifie une planification et des règles d’engagement écrites.
Les points à fixer dans la convention :
- les actions exclues par défaut : suppression de données, envois en masse, tests de charge, sauf accord explicite ;
- des comptes et des objets de test dédiés et identifiables, pour pouvoir les retrouver et les nettoyer ;
- des fenêtres hors période de pointe et un plafond de débit de requêtes ;
- ce qui déclenche un arrêt immédiat, et qui peut le décider ;
- le nettoyage final : qui supprime les comptes et les objets de test, et dans quel délai.
Pourquoi écrire les règles d’engagement ?
Parce qu’elles évitent les deux désaccords classiques : le prestataire qui découvre en cours de route qu’une action lui est interdite, et le client qui découvre dans le rapport qu’une action sensible a été menée. Un paragraphe de convention, relu par la direction technique, coûte moins cher qu’une discussion un vendredi soir.
Prévoyez aussi une ligne sur la remontée des constats critiques : à partir de quelle gravité le prestataire vous prévient sans attendre le rapport, par quel canal, et qui, de votre côté, est autorisé à décider d’une correction d’urgence. Sans cet accord, une faille exploitable à distance peut rester ouverte plusieurs jours, le temps que le rapport soit relu, mis en forme et validé.
À retenir
- 1Deux comptes par rôle dans deux organisations distinctes : c’est la préparation la plus rentable.
- 2L’accord des hébergeurs tiers est un point souvent oublié, qui retarde les démarrages.
- 3Un compte administrateur unique empêche de démontrer élévation de privilèges et cloisonnement.
- 4Bloquez la date de restitution dès le départ, avec les équipes qui corrigeront.