Planification et RoE — Démonstration guidée
Un scénario. Une PME. Un chef de projet qui n'y connaît rien. Nous allons rédiger, ligne par ligne, un Rules of Engagement complet, en montrant les endroits où le client vous piégerait sans le vouloir.
Le scénario
Le client : Boutique Éclair, e-commerce québécois, 45 employés, boutique en ligne + application mobile + backoffice interne.
La demande : « On aimerait un pentest de tout notre parc. On a été piraté chez un concurrent l'année dernière, on veut vérifier qu'on est bons. »
Le budget : 15 jours-personne.
Vous : freelance ou prestataire, sur le point de signer.
C'est à ce moment que 90 % des débutants disent oui et commencent à scanner. On va faire l'inverse : poser des questions avant de rédiger.
Étape 1 — Le questionnaire de cadrage
Avant tout RoE, une réunion de cadrage. Douze questions, minimum. Voici les questions exactes à poser à Boutique Éclair, avec leurs réponses probables, et ce que ça change dans le RoE.
Q1 — « Où hébergez-vous chaque composant ? »
Réponse du client : « Notre site web est chez Shopify. L'application mobile pointe sur une API qu'on héberge chez AWS Montréal. Le backoffice tourne dans nos bureaux, sur un vieux serveur. »
Ce que ça change :
- Shopify : impossible à pentester au sens classique. Vous ne pouvez tester que ce qui est déployé par le client (thèmes custom, apps privées). Le reste appartient à Shopify.
- AWS Montréal : test autorisé sans notification préalable pour la plupart des services, mais vérifiez la politique AWS Customer Support au jour de la mission.
- Serveur en bureaux : test permis, avec accord du client sur les fenêtres pour ne pas bloquer l'activité.
Dans le RoE, on va donc avoir trois périmètres distincts, avec trois régimes différents.
Q2 — « Qui est propriétaire du domaine boutique-eclair.ca ? »
Réponse : « C'est chez notre webmaster, il a acheté le nom en son propre nom. »
Ce que ça change : le webmaster doit signer un accord aussi. Sinon, votre attaque sur boutique-eclair.ca n'est pas couverte par une autorisation du propriétaire du nom.
Dans le RoE, ajoutez une clause de garantie que le client détient les droits sur tous les actifs listés.
Q3 — « Quelles données sensibles circulent sur ces systèmes ? »
Réponse : « Des cartes de crédit sur le site, des courriels et adresses des clients dans le backoffice, et des données médicales sur quelques employés (assurance groupe). »
Ce que ça change :
- Cartes de crédit : environnement PCI-DSS. Contraintes fortes.
- Adresses courriel des clients : données personnelles. Loi 25 (Québec) + RGPD si vous touchez des clients européens.
- Données médicales : RSS. Vous ne les touchez pas.
Dans le RoE, section légale complète, et exclusion explicite des systèmes qui stockent les données médicales.
Q4 — « Le pentest est-il grey-box, black-box, white-box ? »
Réponse du client : « C'est quoi ? »
Vous expliquez :
| Approche | Ce que le pentester reçoit du client |
|---|---|
| Black-box | Rien. Il part comme un attaquant externe qui ne sait rien. |
| Grey-box | Un compte utilisateur normal. Il simule un employé mal intentionné ou un client compromis. |
| White-box | Tout : code source, comptes admin, doc d'architecture. Le plus efficace, souvent le plus utile. |
Un client sensé choisit grey-box ou white-box pour son argent. Le black-box coûte cher en temps de reconnaissance sans forcément apporter plus. Pour Boutique Éclair, proposez grey-box sur le site et l'API, white-box sur le backoffice.
Q5 — « Est-ce que je peux tenter du phishing sur vos employés ? »
Réponse : « Oui, sauf sur le PDG, il déteste ça. »
Ce que ça change : liste exclusive dans le RoE, et procédure de post-phishing — un employé qui clique sera-t-il formé, sanctionné, ignoré ? On l'écrit à l'avance.
Q6 — « Quelle est la fenêtre de tolérance à l'incident ? »
Réponse : « Le site ne doit pas tomber en journée. On peut arrêter le backoffice le week-end. »
Ce que ça change : les scans agressifs et les tests de charge sont interdits en journée, autorisés le week-end soir/nuit.
Q7 — Q12 (les autres)
- « Qui prévenez-vous si on trouve une intrusion en cours ? »
- « Combien d'heures avez-vous pour répondre à un appel de nuit ? »
- « Est-ce que je peux créer un compte de test persistant ? »
- « Est-ce que je peux exfiltrer des données de démonstration ? »
- « Où stocke-t-on les preuves pendant la mission ? »
- « Le rapport doit-il être remis chiffré ? »
Chaque réponse fait naître une ligne du RoE.
Étape 2 — Le RoE écrit sous vos yeux
Voici le RoE final, section par section, avec les commentaires qu'un pentester expérimenté glisserait à côté.
2.1. En-tête
Rules of Engagement — Test d'intrusion Boutique Éclair
Version 1.2 — Date : 2026-04-08
Prestataire : Cursor Sécurité inc., NEQ 1234567890
Client : Boutique Éclair inc., NEQ 0987654321
Durée : 15 jours ouvrables, entre le 2026-04-15 et le 2026-05-06
Un numéro de version, une date. Chaque modification fera monter le numéro. La version signée est la seule qui compte.
2.2. Périmètre technique
Périmètre — trois zones distinctes
Zone A — Site e-commerce
- Type : SaaS Shopify + thème custom + 2 apps privées
- Techniques permises : test des apps privées (grey-box, compte fourni),
revue du thème (white-box), test de configuration Shopify (documentation).
- Techniques interdites : tout scan actif contre les IPs Shopify.
Toute exploitation en dehors des composants custom.
Zone B — API applicative mobile
- Domaine : api.boutique-eclair.ca
- IPs : voir Annexe A (5 IPs élastiques AWS ca-central-1)
- Techniques permises : scan actif, exploitation, tests d'authentification.
- Techniques interdites : DoS, injection destructive dans la base.
- Régime : grey-box avec 2 comptes utilisateurs fournis par le client.
Zone C — Backoffice interne
- Domaine : intranet.boutique-eclair.local (accessible via VPN fourni)
- IPs : 10.20.30.0/24
- Techniques permises : scan actif, exploitation, élévation de privilèges,
accès à des fichiers de démonstration.
- Techniques interdites : accès aux dossiers RH_medical/*, accès aux
fichiers de salaires.
- Régime : white-box, code source disponible sur GitLab client.
Exclusions transversales
- Serveur AS/400 (10.20.30.99) — machine legacy critique, non testée.
- Postes de travail des employés — pas de compromission client.
- Toute infrastructure appartenant à Shopify.
Le périmètre tient sur une page. Chaque ligne peut se défendre devant un juge.
2.3. Techniques permises et interdites (résumé de la Zone B, à titre d'exemple)
| Technique | Permis ? | Notes |
|---|---|---|
| Scan de ports actif | Oui | En dehors des heures ouvrables, --max-rate 500 max. |
| Exploitation | Oui | Pas d'écriture destructrice. |
| Injection SQL | Oui | Sur données de démo uniquement. |
| Élévation de privilèges | Oui | Pas de compte persistant après remédiation. |
| Extraction de données | Oui | Maximum 100 lignes par table, redigées après extraction. |
| Attaque par force brute | Oui | Max 5 tentatives par compte. |
| Déni de service | Non | — |
| Ingénierie sociale | Voir Zone D | — |
Zone D est traitée à part parce que le phishing a ses règles propres.
2.4. Zone D — Ingénierie sociale
- Vecteur : phishing par courriel uniquement.
- Cibles : 30 employés listés en Annexe B. PDG exclu.
- Volume : maximum 2 vagues de courriels, à 5 jours d'intervalle.
- Créneau d'envoi : mercredi 09h00 → 11h00 (heure de Montréal).
- Domaine expéditeur : boutique-eclair-support.com (acquis pour l'exercice).
- Post-clic : redirection vers une page de sensibilisation interne
(fournie par le client), pas de vol d'identifiants réels.
- Rapport : liste anonymisée des clics ; noms remis uniquement à la DRH.
Chacune de ces contraintes est une couverture. La ligne « page de sensibilisation, pas de vol d'identifiants » évite un scandale interne.
2.5. Fenêtres d'intervention
Semaine 1 (15-19 avril)
Zone A — revue documentaire, en journée
Zone C — scan initial, mercredi 22h00 → jeudi 06h00
Semaine 2 (22-26 avril)
Zone B — exploitation, mardi et jeudi, 09h00 → 18h00
Zone D — vague de phishing #1, mercredi 09h00 → 11h00
Semaine 3 (29 avril - 3 mai)
Zone C — exploitation profonde, samedi 20h00 → dimanche 08h00
Zone D — vague de phishing #2, mercredi 09h00 → 11h00
Fenêtre tampon : 6-8 mai, rédaction rapport.
Chaque case du calendrier a une intention. Le client sait à quoi s'attendre. Vous savez ce que vous n'avez pas le droit de faire mardi à 14 h.
2.6. Contacts d'escalade
Contact opérationnel — Mme Sophie Tremblay, RSSI
Téléphone : (514) 555-0142 (mobile, joignable 9h-17h HE)
Courriel : sophie.tremblay@boutique-eclair.ca
Escalade urgence (24h/24) — M. Karim Bélanger, DSI
Téléphone : (514) 555-0177 (mobile perso)
Courriel : karim@boutique-eclair.ca
Signal : +1 514 555 0177
Chef de mission (prestataire) — Vous
Téléphone : (514) 555-0100
PGP : voir Annexe C
Trois personnes. Trois numéros de mobile. Aucun standard. Aucun email sans réponse automatique.
2.7. Traitement des situations critiques
Découverte d'une vulnérabilité critique exploitable en production
1. Arrêt immédiat de l'exploitation.
2. Notification à Sophie Tremblay sous 2 heures.
3. Rédaction d'un mini-mémo (1 page) sous 24 heures.
4. Poursuite du pentest sur d'autres axes.
Découverte d'une intrusion préexistante
1. Arrêt complet des tests sur la zone concernée.
2. Appel à Karim Bélanger sous 1 heure, sur son numéro perso.
3. Préservation des indicateurs de compromission (IoC).
4. Basculement vers un mandat de « incident response », avenant à ce contrat.
Découverte d'une fuite de données personnelles
1. Notification à Sophie Tremblay sous 1 heure.
2. Application des obligations Loi 25 : notification à la Commission d'accès
à l'information si la fuite est confirmée et présente un risque sérieux.
Ces procédures ne sont pas des poèmes. Elles sont des arbres de décision. On les répète en réunion de démarrage pour que tout le monde les connaisse par cœur.
2.8. Gestion des preuves
Stockage
- Machine de mission dédiée, chiffrée LUKS (aes-xts-plain64, 256 bits).
- Aucun stockage cloud pendant la mission.
Nommage
- AAAA-MM-JJ_boutique-eclair_<zone>_<cible>_<action>.<ext>
- Ex. : 2026-04-23_boutique-eclair_zoneB_api_login_bruteforce.pcap
Conservation
- 90 jours après remise du rapport final.
- Destruction certifiée par écrasement DBAN + attestation signée.
Remise
- Rapport chiffré PGP, empreinte de la clé client vérifiée par téléphone
avec Sophie Tremblay avant remise.
Un jour, quelqu'un vous demandera « vous en avez fait quoi, de nos mots de passe volés ? ». La réponse est écrite là.
2.9. Livrables
1. Rapport exécutif (2-3 pages), remis à Karim Bélanger.
Date : 2026-05-13.
2. Rapport technique complet, remis à Sophie Tremblay.
Date : 2026-05-13.
Format : PDF chiffré + annexes (fichiers de preuves, scripts, captures).
3. Session de restitution orale : 2026-05-16, 90 minutes, en présentiel.
4. Session de re-test après remédiation : à cadrer sur avenant, dans les
6 mois suivant le rapport, plafond 3 jours-personne.
Étape 3 — Faire relire
Un RoE non relu est un RoE incomplet. Faites-le relire par deux paires d'yeux avant signature :
- Un juriste — clauses de responsabilité, cadre légal, propriété des données.
- Un pair pentester — cohérence technique, réalisme des fenêtres, complétude du périmètre.
Chaque relecture donne 5 à 10 corrections. C'est normal. Un RoE parfait du premier coup, c'est un RoE qu'on n'a pas relu.
Étape 4 — Signature
Signature électronique qualifiée si possible (DocuSign, Notarius). À défaut, signature manuscrite + scan. Jamais un simple « oui, on est d'accord » dans un email.
Une fois signé, le RoE devient l'annexe technique de votre contrat. Toute modification passe par un avenant écrit et signé. Un ajustement en réunion, tracé par un compte-rendu, tient — mais on double toujours par un avenant.
Ce qui vient de se passer
- Vous avez rencontré un client qui, spontanément, aurait produit un RoE d'une demi-page dangereux.
- Vous avez posé douze questions, dont plusieurs déplaisantes.
- Vous avez produit un RoE de trois pages solides, qui tient.
- Vous n'avez toujours pas lancé une seule commande. C'est normal. Un pentest, ça commence sur du papier.
Prochaine leçon : à vous. Vous rédigez un RoE complet pour un scénario différent, imposé, avec des pièges à repérer.