Planification et RoE — Notions
Vous savez attaquer une machine dans votre lab. Maintenant on rentre dans le vrai monde : celui où le client vous paie pour attaquer le sien. Entre les deux, il y a un papier. Sans ce papier, votre carrière s'arrête au premier scan.
Un pentest sans autorisation écrite est une intrusion informatique. C'est un délit dans toutes les juridictions développées. Pas « ça dépend ». Pas « si je fais gaffe ». Un délit. Le papier existe pour cette raison unique : il transforme votre attaque en service commandé.
Ce que vous saurez faire après cette leçon
- Nommer les cinq pièces contractuelles d'une mission de pentest.
- Distinguer scope, RoE, SOW et contrat de service — quatre documents que 90 % des débutants confondent.
- Rédiger un périmètre qui tient devant un avocat et devant votre équipe technique.
- Anticiper les cas où le client lui-même n'a pas le droit d'autoriser l'attaque (SaaS, hébergement partagé, employés surveillés).
- Savoir ce qu'on fait quand, en pleine mission, on découvre une intrusion préexistante (ça arrive plus qu'on ne le croit).
1. Le vrai patron d'un pentest : les avocats
Sur le papier, le client est votre patron. Dans les faits, celui qui décide où vous avez le droit d'appuyer, c'est le juriste. Un pentester junior qui ne comprend pas ça se met dans deux situations :
- Il signe un truc vague, il fait ce qu'il pense être utile, il dépasse le périmètre, le client râle, le contrat n'était pas assez précis, personne n'est protégé.
- Il refuse tout ce qui n'est pas dans le RoE — même un test évident — parce que le RoE est la loi. C'est cette deuxième posture qu'on adopte. Toujours.
Retenez la règle unique : ce qui n'est pas écrit, n'existe pas. Un accord oral ne survit pas à un incident. Un email non signé non plus.
2. Les cinq pièces contractuelles
Une mission complète comporte cinq documents. Ils ne servent pas la même chose, et il ne faut pas les mélanger.
| Pièce | Rôle | Qui le rédige |
|---|---|---|
| NDA (Non-Disclosure Agreement) | Vous engage au secret. Signé avant même de discuter du périmètre. | Client (souvent), signé par les deux. |
| SOW (Statement of Work) | Ce qu'on fait, pour combien, sur combien de jours. Le devis contractualisé. | Vous (le prestataire). |
| RoE (Rules of Engagement) | Comment on le fait : périmètre technique, fenêtres, escalades. | Vous, validé par le client. |
| Autorisation d'attaque (letter of authorization) | La preuve à sortir si un tiers vous soupçonne (fournisseur cloud, MSSP). | Client, imprimée, signée. |
| Contrat cadre | La responsabilité, l'assurance, la loi applicable. | Juristes des deux côtés. |
Le RoE est votre document de travail au jour le jour. Les autres tournent en arrière-plan, mais ils doivent tous exister avant que vous lanciez nmap.
3. RoE : ce qu'il faut absolument dedans
Un RoE minimal, celui qu'on ne discute pas, contient huit sections. Si l'une manque, refusez de commencer.
3.1. Périmètre — la carte du champ de bataille
Le périmètre n'est jamais « l'infrastructure du client ». C'est :
- Une liste d'adresses IP ou de plages CIDR. Ex. :
203.0.113.0/28,198.51.100.42. - Une liste de noms de domaine et sous-domaines. Ex. :
www.client.com,api.client.com. Tout ce qui n'est pas listé n'est pas ciblable, même si vous le trouvez. - Une liste d'applications. Web, mobile, API, systèmes SCADA. Chacune avec sa version.
- Des comptes de test fournis par le client (login/mot de passe pour un pentest grey-box ou white-box).
- Des exclusions explicites. L'imprimante de la DG, le serveur de paye, le vieux serveur AS/400 qui tourne depuis 1998 et que personne n'ose éteindre.
Un client vous donne « son domaine client.com ». Vous scannez mail.client.com — mais ce sous-domaine pointe en réalité chez Google Workspace. Google ne vous a jamais autorisé. Vous venez de scanner l'infrastructure d'un tiers. C'est illégal. Filtrez les sous-domaines et vérifiez la propriété DNS avant tout scan.
3.2. Techniques permises et interdites
On liste ce qu'on peut faire, et ce qu'on ne peut pas. Exemples de sections classiques :
| Technique | Permis ? | Précision |
|---|---|---|
| Scan de ports actif | Oui | En dehors des heures ouvrables. |
| Exploitation de vulnérabilités trouvées | Oui | Sans écrire dans les bases de production. |
| Élévation de privilèges | Oui | Ne pas créer de compte persistant. |
| Ingénierie sociale par email (phishing) | Oui | Sur une liste d'employés fournie, pas plus de 3 vagues. |
| Ingénierie sociale téléphonique (vishing) | Non | — |
| Déni de service | Non | Jamais en production. |
| Test physique (pénétration bureaux) | Non | Prévu pour une phase 2. |
| Attaques sur l'authentification | Oui | Max 3 tentatives par compte pour éviter les verrouillages. |
Chaque Non peut sauver votre client d'un incident. Chaque Oui mal cadré peut vous en créer un.
3.3. Fenêtres d'intervention
Jamais « pendant la journée ». Toujours des horodatages précis, avec fuseau :
- Scan bruyant : sam. 15 mars 22h00 → dim. 16 mars 06h00 (UTC-05:00)
- Exploitation : sem. du 17 mars, 09h00 → 18h00 (UTC-05:00)
- Phishing : mer. 19 mars, envoi entre 09h00 et 11h00 (UTC-05:00)
Un scan qui déborde d'une heure sur les heures ouvrables et qui fait tomber un serveur, ça se plaide. Un scan qui déborde et qui n'était pas dans la fenêtre autorisée, ça se paye.
3.4. Contacts d'escalade
Trois personnes, minimum, dans le RoE :
- Le point de contact opérationnel côté client. Répond aux questions techniques, joignable 9-17.
- Le point d'escalade d'urgence. Joignable 24 h/24 pendant la fenêtre de test. Numéro de portable perso, pas de standard.
- Votre chef de mission côté prestataire.
Numéros. Emails. Le RoE dit exactement qui appeler quand quelque chose se passe mal.
3.5. Traitement des découvertes critiques
« Si vous trouvez une faille critique en cours de test, que faites-vous ? »
Réponse type :
- Vulnérabilité critique exploitable en production : arrêt immédiat de l'exploitation, notification au contact d'escalade sous 2 h, poursuite du test sur d'autres axes.
- Preuves d'intrusion préexistante (le client a déjà été piraté) : arrêt total, notification sous 1 h, préservation des indicateurs. C'est un cas de response, pas de pentest.
- Fuite de données personnelles identifiée : notification immédiate, dispositions du RGPD / Loi 25 sur la notification à l'autorité.
Ces cas s'écrivent à l'avance. Le jour où ils arrivent, vous n'avez pas la tête à négocier.
3.6. Gestion des preuves
Où stockez-vous les captures, les logs, les hashes récupérés ?
- Chiffrement des preuves : LUKS, VeraCrypt, disque distinct.
- Nommage :
YYYY-MM-DD_client_<cible>_<action>.ext. - Durée de conservation : 30, 60 ou 90 jours après remise du rapport, puis destruction certifiée.
- Restitution au client si demandée, sur canal chiffré (Signal, Wire, ou passage physique de clé USB chiffrée).
Un pentester qui laisse un hashdump sur son bureau non chiffré, c'est un pentester qu'on ne rappelle pas.
3.7. Aspects légaux et réglementaires
Selon la juridiction :
- Canada / Québec — Loi 25. Toute donnée personnelle touchée par le pentest doit être documentée. Le client doit avoir prévu un accord de traitement qui inclut le prestataire de pentest.
- Union européenne — RGPD. Idem, article 28. Le prestataire est sous-traitant, avec un DPA (Data Processing Agreement).
- États-Unis — CFAA. Computer Fraud and Abuse Act. Extrêmement large. Le RoE doit citer « authorized access » en toutes lettres.
- Environnements PCI-DSS. Requièrent un pentest annuel. Contraintes fortes sur qui peut le mener (qualification ASV, PA-QSA).
- Environnements de santé — HIPAA (US), RSS (Canada). Contraintes de journalisation supplémentaires.
Si votre client est sur SaaS (AWS, Azure, GCP), vérifiez la politique du fournisseur. AWS n'exige plus de notification préalable pour la plupart des tests depuis 2019 ; Azure exige toujours une déclaration ; GCP demande un accord. Regardez la doc à jour au moment de la mission, pas ce cours.
3.8. Livrables et deadlines
Ce que vous rendez, et quand :
- Rapport exécutif (2-3 pages).
- Rapport technique complet (30-80 pages).
- Fichiers de preuves.
- Session de restitution orale.
Chaque livrable a une date, un format, un destinataire.
4. Le cas particulier qui rend le client vulnérable : la sous-traitance
Le client vous engage pour pentester son ERP. L'ERP tourne sur un VPS hébergé chez OVH. Est-ce que vous avez le droit d'attaquer le VPS ?
Ça dépend du contrat entre le client et OVH. Certains hébergeurs interdisent les tests d'intrusion sans notification préalable. D'autres l'autorisent sans demander. C'est au client de vérifier — mais c'est vous qui vous ferez couper la connexion et qui recevrez un email d'abus si personne n'a fait le travail.
Ajoutez dans votre RoE une clause type :
« Le client garantit qu'il détient les droits nécessaires à l'autorisation des tests décrits, y compris auprès de ses fournisseurs d'hébergement et de services managés. Toute plainte ou blocage de la part d'un tiers relève de la responsabilité du client. »
Cette phrase, c'est une couverture. Elle ne suffira pas si le client vous ment sciemment, mais elle vous met dans le sens de l'histoire.
5. Les red flags à repérer avant de signer
Refusez la mission, ou renégociez, si vous voyez :
- Un client qui ne veut pas fournir de contact d'escalade 24 h. Il ne prend pas la mission au sérieux.
- Un RoE fourni par le client plus court qu'une page. Il pense qu'un RoE est une formalité. Vous en paierez le prix.
- Une demande explicite de tester des systèmes qui appartiennent à un tiers. C'est le client qui doit régler cela, pas vous.
- Un client qui insiste pour que vous « essayiez d'entrer par surprise, sans prévenir personne ». C'est de la red team — ça a son cadre, plus lourd, pas celui d'un pentest.
- Une mission très courte (2 jours) sur une cible très large (un domaine complet). Vous n'aurez pas le temps de faire un travail utile ; le client se plaindra du rapport ; personne n'y gagne.
6. Les erreurs fréquentes qui coûtent
- Périmètre décrit oralement, jamais consigné. Le jour du litige, vous n'avez rien.
- Aucune procédure pour une intrusion préexistante. Vous entrez dans une infrastructure déjà compromise, vous ne savez pas quoi faire, vous détruisez sans le vouloir des preuves qui auraient servi à une enquête.
- Aucune marge dans les fenêtres. Un scan
nmap -p-peut durer 4 h sur une plage de 256 IPs. Prévoyez 1,5× votre estimation. - Comptes de test créés dans le compte administrateur du client, sans mot de passe fort. À la fin de la mission, ils oublient de les supprimer.
- Utilisation d'outils qui rappellent chez leur éditeur. Certains outils commerciaux téléportent les résultats vers leur cloud. Le RoE n'a peut-être pas prévu cette exfiltration. Configurez tout en local.
7. Ce qu'il faut retenir
- Un RoE, ce n'est pas un papier de plus. C'est le seul document qui rend votre travail légal.
- NDA, SOW, RoE, autorisation, contrat cadre : cinq pièces, cinq rôles. Ne les confondez pas.
- Le périmètre est une liste, pas une phrase.
- Les fenêtres et les contacts s'écrivent à la minute et au numéro près.
- Le cas « intrusion préexistante » et le cas « découverte critique » s'anticipent.
- Le client ne peut vous autoriser à attaquer que ce qui lui appartient.
Prochaine leçon : on prend un scénario réel (une PME de e-commerce), on rédige un RoE complet, et on le fait relire.