Préparer un test d’intrusion : objectifs, périmètre, règles d’engagement et livrables

Pourquoi la préparation fait-elle la valeur d’un test d’intrusion ?

Un test d’intrusion simule les actions d’un attaquant sur un périmètre défini, dans un cadre autorisé, pour mesurer ce qu’il pourrait réellement atteindre. Le commanditaire apporte la question à trancher, les actifs, les contraintes, les autorisations et les comptes. Ce qui n’est pas fixé avant se règle pendant la mission, au détriment du temps de test.

Le NIST décrit ce travail préalable dans son guide SP 800-115, consacré à la planification et à la conduite des tests de sécurité. Il y définit les règles d’engagement comme les consignes et contraintes détaillées qui encadrent l’exécution du test : elles sont établies avant son démarrage et donnent à l’équipe l’autorité de mener les activités définies sans permission supplémentaire. Autrement dit, tout ce qui n’y figure pas n’est pas autorisé.

Dans nos missions, les difficultés de démarrage tiennent rarement à la technique : une adresse oubliée, un compte de test absent, un hébergeur non consulté. Elles se préviennent avec une liste.

Quelle question le test doit-il trancher ?

Un test d’intrusion répond à une question. Si elle n’est pas écrite, le rapport répondra à une autre. Quelques formulations utiles :

• Que peut atteindre un attaquant depuis Internet, sans compte ? C’est la question d’un test externe en boîte noire.
• Un client authentifié peut-il accéder aux données d’un autre client ? C’est la question d’un test applicatif en boîte grise, avec deux comptes au moins.
• Jusqu’où irait un attaquant qui a pris la main sur un poste ? C’est la question d’un test interne, qui mène souvent à l’annuaire, comme nous le détaillons dans notre article sur Active Directory et Entra ID.
• La nouvelle version est-elle prête pour la mise en production ? C’est la question d’un test applicatif ciblé sur les fonctions modifiées.

La question détermine le périmètre, le niveau d’information, la durée et les livrables. Si elle devient « nos équipes détecteraient-elles une vraie attaque ? », ce n’est plus un test d’intrusion mais un exercice Red Team, qui se prépare autrement : voir notre comparatif Red Team et pentest.

Quel périmètre choisir ?

Le périmètre se décrit en actifs, pas en intentions : noms de domaine, adresses, URL, versions d’application, abonnements cloud. « Le site » ne suffit pas.

Deux listes complètent le tableau. La liste d’exclusions nomme ce qui ne doit pas être touché : un automate de production, l’application d’un partenaire hébergée sur la même plage d’adresses. La règle pour les actifs inconnus dit quoi faire de ce que la reconnaissance fera remonter : signalement seul, ou extension du périmètre après autorisation.

Boîte noire, grise ou blanche ?

Le niveau d’information donné aux testeurs découle de la question posée.

• Boîte noire. Les testeurs partent sans information, comme un attaquant externe. Elle mesure ce qu’un inconnu peut découvrir et atteindre, au prix d’une partie du temps passée en reconnaissance.
• Boîte grise. Les testeurs disposent d’un accès limité : un compte utilisateur, un compte partenaire, un poste standard. C’est l’approche courante pour un test applicatif ou interne : elle montre ce que ferait un utilisateur malveillant ou un attaquant muni d’un compte volé.
• Boîte blanche. Les testeurs disposent de la documentation, voire du code source et des configurations. Elle permet un examen approfondi d’un composant et se rapproche de l’audit de code ou de configuration.

BEAROPS pratique la boîte noire et la boîte grise. Le WSTG de l’OWASP note que le test d’intrusion est souvent assimilé à la boîte noire, et décrit la boîte grise comme un test avec une connaissance partielle de l’application. Les deux se combinent souvent : une phase externe sans information, puis une phase authentifiée.

Que doivent fixer les règles d’engagement ?

Les règles d’engagement fixent au minimum :

• Les fenêtres d’intervention. Jours, heures, fuseau horaire. Les tests qui risquent de perturber le service (balayages larges, tests de force brute sur l’authentification) se placent en heures creuses ; les tests qui demandent une réaction des équipes se placent en heures ouvrées.
• Les contacts d’urgence, des deux côtés. Un nom, un téléphone, une plage de disponibilité. Côté commanditaire, quelqu’un qui peut décider d’arrêter le test ; côté testeurs, quelqu’un qui peut l’arrêter immédiatement.
• La procédure d’arrêt et de signalement. Ce qui déclenche un arrêt (indisponibilité constatée, découverte d’une compromission antérieure) et ce qui déclenche un signalement immédiat (vulnérabilité critique exploitable depuis Internet, données sensibles exposées).
• Les actions interdites. Déni de service, modification ou suppression de données réelles, ingénierie sociale si elle n’est pas prévue, persistance au-delà de la mission, rebond vers un tiers.
• Le traitement des données de production. Si un testeur atteint des données personnelles ou métier, il en apporte la preuve minimale (une capture, un enregistrement masqué), sans extraction massive. Le WSTG recommande de masquer les données sensibles dans le rapport. Les éléments collectés sont détruits à la fin de la mission, selon une procédure convenue.
• L’environnement visé. Recette ou production, et pour chacun les règles propres. Une recette représentative accueille les tests à effets de bord, comme ceux décrits dans notre article sur les race conditions ; la production reste nécessaire pour ce qui n’existe qu’elle, comme le filtrage réseau réel.
• Les adresses source des testeurs, pour distinguer le test d’une attaque réelle.

Reste la question du SOC. Pour un test d’intrusion, on le prévient en général, puisque le test mesure la résistance, pas la détection. Pour un exercice où la détection fait partie de la question, le cadre européen TIBER-EU de la BCE illustre l’autre logique : une petite équipe de contrôle, seule au courant du test au sein de l’entité, le pilote.

Quelles autorisations écrites réunir ?

En droit français, l’article 323-1 du Code pénal réprime l’accès ou le maintien frauduleux dans un système de traitement automatisé de données. C’est l’autorisation du propriétaire qui fait la différence entre un test et une intrusion.

Le propriétaire des actifs. La signature vient d’une personne habilitée à engager l’organisation qui détient les actifs, et l’autorisation reprend le périmètre, les exclusions, les fenêtres et l’identité des intervenants. Quand le périmètre couvre une filiale, une entité sœur ou un client, chacune signe pour ce qui la concerne.

L’hébergeur, l’infogérant, l’éditeur SaaS. Un serveur hébergé ou une application en SaaS restent soumis au contrat du prestataire : on le vérifie, et on obtient son accord si le contrat l’exige ou reste muet.

Les fournisseurs cloud. Les trois principaux publient leur politique :

• AWS liste les services que ses clients peuvent tester sans approbation préalable (EC2, RDS, Lambda, CloudFront, API Gateway, entre autres) et demande de passer par son support pour les autres. Il interdit notamment le déni de service, même simulé, et le flooding. Les exercices Red Team et le phishing simulé passent par un formulaire d’événement simulé, à déposer au moins deux semaines avant le début ; une infrastructure de commande et contrôle exige une approbation préalable.
• Microsoft publie des règles d’engagement qui s’appliquent au propriétaire de la ressource comme à ses mandataires. Les tests restent dans votre propre tenant ; sont interdits, entre autres, le déni de service, le fuzzing générant un trafic excessif et toute tentative sur un tenant que vous ne possédez pas.
• Google Cloud indique qu’il n’est pas nécessaire de le contacter pour tester votre propre infrastructure, à condition de respecter sa politique d’utilisation acceptable et ses conditions d’utilisation, et de veiller à ce que les tests n’affectent que vos projets.

Ces politiques évoluent : on les relit au cadrage et on archive la version consultée.

Quels comptes de test préparer ?

En boîte grise, les comptes conditionnent la profondeur du test. On les vérifie la veille.

• Un compte par rôle, et deux comptes pour le même rôle quand la question porte sur le cloisonnement entre clients : c’est ce qui permet de tester l’accès aux données d’un autre utilisateur.
• Des comptes dédiés, nominatifs pour le test, jamais des comptes de collaborateurs réels.
• Les seconds facteurs prévus : un téléphone de test, une application d’authentification enrôlée, ou une exception documentée.
• Des données de test réalistes pour exercer les parcours métier.
• La désactivation de tous les comptes à la fin de la mission, avec une date écrite.

Quels livrables exiger ?

Le rapport est ce qui reste de la mission. La liste ci-dessous s’appuie sur la structure proposée par le chapitre Reporting du WSTG :

• Une synthèse pour la direction, sans jargon, qui rappelle l’objectif, présente les constats par impact métier et formule des recommandations stratégiques.
• Le rappel du périmètre et des limites : ce qui a été testé, ce qui ne l’a pas été, et pourquoi (accès manquant, fonction indisponible, manque de temps).
• Des constats reproductibles. Pour le WSTG, chaque constat doit contenir de quoi comprendre la vulnérabilité, la reproduire et la corriger : étapes, requêtes, preuves.
• Une criticité par constat, appuyée sur la probabilité d’exploitation et l’impact, sur une échelle explicite (informatif, faible, moyen, élevé, critique). Le score CVSS peut s’y ajouter ; il ne remplace pas l’évaluation du contexte.
• Un plan de correction : des recommandations concrètes, classées, que les équipes peuvent transformer en tickets.
• Une réunion de restitution, technique et direction.
• Un contre-audit après correction, qui vérifie que chaque constat est bien fermé. Le WSTG prévoit pour ce cas une section qui reprend l’état de chaque constat du test précédent.

La checklist de préparation

À cocher avant le premier jour de test :

• La question à laquelle le test doit répondre est écrite en une phrase.
• Le type de test est choisi : externe, applicatif, interne, cloud, mobile, ou une combinaison.
• Le périmètre est décrit en actifs : domaines, adresses, URL, versions, abonnements.
• La liste d’exclusions est validée par l’exploitation.
• Le niveau d’information est choisi : boîte noire, grise, ou les deux par phases.
• Les fenêtres d’intervention sont fixées, avec le fuseau horaire.
• Les contacts d’urgence des deux côtés sont joignables, avec une personne habilitée à arrêter le test.
• Les actions interdites et la procédure d’arrêt sont écrites.
• Les règles sur les données de production sont fixées : preuve minimale, masquage, destruction.
• L’environnement est choisi (recette, production, les deux) et la recette est représentative.
• L’autorisation écrite du propriétaire des actifs est signée.
• Les accords des tiers (hébergeur, infogérant, éditeur SaaS) et les politiques cloud sont vérifiés.
• Le SOC est prévenu et connaît les adresses source des testeurs.
• Les comptes de test, seconds facteurs et données de test sont prêts et vérifiés.
• Les livrables attendus sont listés, avec la date de restitution.
• La date du contre-audit est prévue.

Exemple : préparer le test d’une plateforme client

Exemple type. Une société de services ouvre à ses clients un portail web et une application mobile, hébergés sur AWS, avec une API commune. Son plus gros client exige un test d’intrusion avant la mise en production.

La question retenue : un client authentifié peut-il accéder aux données d’un autre client, et que voit un attaquant sans compte ? Le périmètre réunit deux domaines, l’API, les applications Android et iOS et le compte AWS de production. Le prestataire de messagerie transactionnelle, qui envoie les courriels du portail, est exclu.

La mission se mène en deux phases : boîte noire depuis Internet, puis boîte grise avec deux comptes par rôle. Les tests de création et de suppression de dossiers ont lieu en recette, alignée sur la production ; la reconnaissance externe et la revue cloud portent sur la production. La politique d’AWS, relue, confirme que les services concernés sont testables sans approbation préalable. Le SOC de l’infogérant reçoit les adresses des testeurs.

Le rapport attendu comprend une synthèse lisible par le client final, des constats reproductibles et un contre-audit trois semaines après la restitution.

Ce scénario est construit à partir de situations courantes en mission, pas à partir d’un client identifiable.

Où intervient BEAROPS ?

Nos tests d’intrusion commencent par ce cadrage : question, périmètre, règles d’engagement et autorisation écrite signée avant toute action. Ils s’appuient sur les référentiels OWASP WSTG, NIST SP 800-115, ANSSI et TIBER-EU. Pour les entités financières, nos tests d’intrusion et exercices Red Team s’inscrivent dans votre programme de tests de résilience au titre des articles 24 et 25 de DORA.

Limites de l’approche

Un test d’intrusion est un instantané. Il mesure un périmètre, à une date, avec un temps et un niveau d’information donnés. Une mise en production le lendemain, un nouveau sous-domaine ou une règle de pare-feu modifiée peuvent rendre une partie du rapport caduque. Le WSTG rappelle, en citant Gary McGraw, qu’en pratique un test d’intrusion ne peut identifier qu’un petit échantillon représentatif des risques de sécurité d’un système.

Une bonne préparation ne compense pas un périmètre trop étroit : un test qui exclut l’API ne dira rien de l’API. Et les règles d’engagement limitent le testeur là où un attaquant réel n’a ni fenêtre ni liste d’exclusions.

Enfin, l’absence de constat critique prouve seulement qu’une équipe, dans un temps donné, n’en a pas trouvé. Le contre-audit et le suivi de l’exposition entre deux tests transforment l’instantané en démarche.