Nouvel article aujourd'hui afin de parcourir une des questions les plus sous-estimées lorsqu’on parle de pentest : Comment prépare-t-on un pentest ?
Lors des phases de cadrage, je constate régulièrement la même chose. Dès que l’on commence à parler du périmètre, du type de test, des informations à fournir à l’auditeur, des règles d’engagement ou encore des personnes à prévenir, la réaction est bien souvent celle-ci :
Je vous propose donc de parcourir les principaux éléments à anticiper pour démarrer une mission dans de bonnes conditions et permettre à l’auditeur de consacrer son temps à ce qui compte vraiment : tester votre sécurité.
Et en fin d’article, je vous présenterai également le modèle de préparation que j’utilise pour accompagner mes clients dans le cadrage de leurs missions de pentest.
1. Définir ce que vous cherchez réellement à vérifier
Eh oui, la première étape est tout simplement de savoir pourquoi vous souhaitez réaliser ce test d’intrusion.
Un test d'intrusion intervient généralement dans un objectif bien précis : tester une application fraîchement développée avant sa mise en production, répondre à une exigence réglementaire ou à celle d'un client, valider la sécurité d’un périmètre existant, ou encore éprouver certains mécanismes de sécurité déjà en place.
Cet objectif doit être communiqué clairement avant le début de la mission.
Pourquoi ? Parce qu’un auditeur averti saura adapter son approche pour répondre à votre besoin. Sans objectif clairement défini, il devient beaucoup plus difficile (voire, dans certains cas, impossible) de mener la mission dans la bonne direction et de vous restituer des résultats réellement en phase avec vos attentes.
Et au final, personne n’y gagne : vous risquez de ne pas être pleinement satisfait du résultat, tandis que l’auditeur pourra avoir le sentiment de ne pas avoir rempli correctement son rôle de conseil.
2. Définir précisément le périmètre du test
Maintenant que l’objectif est clair, place à la définition du périmètre.
C’est généralement à ce stade que le tarif du test d’intrusion commence réellement à se dessiner.
Entre un pentest ciblé sur une application web et son API, et un test couvrant l’ensemble d’une infrastructure répartie sur plusieurs sites, avec plusieurs environnements et annuaires à analyser, la charge de travail n’a évidemment rien à voir.
La bonne nouvelle, c’est qu’un objectif bien défini facilite énormément cette étape. Il devient alors beaucoup plus simple d’identifier ce qui doit réellement entrer dans le périmètre, mais aussi ce qui peut en sortir.
Gardez simplement en tête qu’un périmètre plus large, plus complexe ou nécessitant davantage de profondeur demandera mécaniquement plus de temps d’intervention, et aura donc un impact direct sur le chiffrage.
L’objectif n’est donc pas de tester « le plus possible », mais de définir le bon périmètre pour répondre à la question posée au départ.
Exemples d’éléments pouvant entrer dans le périmètre
Selon la mission, le périmètre pourra par exemple inclure :
- une ou plusieurs applications web ;
- des API ;
- des domaines ou sous-domaines ;
- des plages d’adresses IP ;
- des serveurs et équipements réseau ;
- des environnements cloud ;
- un annuaire Active Directory.
Pensez également à identifier clairement les éléments qui doivent rester hors périmètre, notamment lorsqu’ils appartiennent à un prestataire tiers ou présentent un risque particulier pour la production.
3. Choisir le niveau d’information donné au pentester
Ce niveau va notamment dépendre du type de test attendu. Avez-vous déjà entendu parler des notions de Black Box, Grey Box et White Box ?
Je reviendrai plus en détail sur ces trois approches dans un futur article, mais voici l’essentiel à retenir :
- Black Box : l’auditeur dispose de très peu, voire d’aucune information sur le périmètre testé. L’objectif est notamment de se rapprocher de la situation d’un attaquant externe qui découvre sa cible au fur et à mesure.
- Grey Box : l’auditeur dispose d’un certain niveau d’information ou d’accès. Il peut par exemple recevoir plusieurs comptes utilisateurs afin de tester les contrôles d’accès, les différents niveaux de privilèges ou les possibilités d’élévation.
- White Box : l’auditeur dispose d’un niveau d’information beaucoup plus important : architecture, documentation, comptes privilégiés, voire code source lorsque cela est pertinent. L’objectif est ici de maximiser la couverture du test et d’identifier le plus grand nombre de vulnérabilités possible.
De ce choix découle directement la manière dont le temps de pentest va être utilisé.
Prenons un exemple simple. Si vous disposez de plusieurs rôles utilisateurs sur une application et que votre objectif principal est de vérifier les contrôles d’accès entre ces différents rôles, fournir directement les comptes nécessaires à l’auditeur lui permettra de consacrer davantage de temps à ces vérifications.
À l’inverse, dans un test Black Box, une partie du temps sera naturellement consacrée à la reconnaissance, à l’identification des points d’entrée et éventuellement à l’obtention d’un premier accès.
Il n’y a donc pas une approche systématiquement meilleure que les autres. Le bon choix dépend avant tout de ce que vous cherchez à vérifier.
Cette partie du cadrage peut parfois sembler un peu abstraite. Si vous avez des questions ou souhaitez être accompagné pour définir le bon périmètre ou le bon niveau de test, n’hésitez pas à me contacter !
4. Préparer les accès et les informations nécessaires
Si le choix se porte sur un test en Grey Box ou White Box, il va falloir préparer certaines informations à transmettre à l’auditeur afin qu’il puisse réaliser sa mission dans les meilleures conditions.
Tout d’abord, les comptes de test.
Assurez-vous de les créer avant le début de la mission. Cela évitera des échanges inutiles en cours de test et, surtout, de perdre du temps parce qu’un compte n’existe pas, qu’un niveau d’accès n’est pas correct ou qu’un MFA empêche finalement l’authentification.
Pour préparer ces accès, je vous conseille de créer un tableau contenant par exemple :
| Compte | Niveau d’accès | MFA | Informations complémentaires |
|---|---|---|---|
| utilisateur1@entreprise.fr | Utilisateur | Oui | Compte standard |
| manager1@entreprise.fr | Manager | Oui | Accès fonctions de validation |
| admin-test@entreprise.fr | Administrateur | Oui | Compte d’administration de test |
Pour les mots de passe, utilisez des mots de passe forts et uniques, idéalement générés spécifiquement pour la mission. Évitez également de transmettre les identifiants et leurs mots de passe dans le même document ou par le même canal. Un gestionnaire de mots de passe, un partage de secret temporaire ou tout autre canal sécurisé sera préférable.
Pensez également à vérifier les comptes avant le début du pentest. Un compte parfaitement documenté mais impossible à utiliser le lundi matin ne nous avancera pas beaucoup. :)
Pour un test en White Box, il faudra également préparer les éléments nécessaires à l’analyse : documentation technique, schémas d’architecture, documentation API, dépôts de code source ou tout autre document utile selon le périmètre.
Là encore, inutile de transmettre un dossier contenant cinquante fichiers sans explication. Un petit tableau précisant le nom du document, sa description et éventuellement son emplacement permettra à l’auditeur de comprendre rapidement ce qui lui est fourni.
Dans l’idéal, je conseille de transmettre ces éléments 24 à 48 heures avant le début de la mission. Cela laisse suffisamment de temps pour vérifier les accès et corriger un éventuel problème avant que le compteur du pentest ne commence réellement à tourner.
5. Définir les règles d’engagement
Les règles d’engagement permettent de définir clairement ce que l’auditeur peut faire, ce qu’il ne doit pas faire, et dans quelles conditions le test va être réalisé.
L’idée n’est pas d’ajouter une couche administrative supplémentaire, mais simplement de s’assurer que tout le monde partage le même cadre avant le début de la mission.
Certaines actions peuvent en effet avoir un impact réel sur la production. Un test de déni de service, une tentative de brute force trop agressive, la modification de données ou encore certaines techniques d’exploitation peuvent provoquer des effets indésirables si elles ne sont pas encadrées correctement.
Il est donc important de préciser en amont les éléments suivants :
- les dates et horaires autorisés pour les tests
- les systèmes ou fonctionnalités qui ne doivent pas être testés
- les actions explicitement interdites, par exemple le déni de service
- les limites concernant la modification ou la suppression de données
- les conditions d’utilisation d’outils automatisés
- les règles concernant les tentatives d’authentification ou de brute force
- les éventuelles limites liées à l’exfiltration de données
- les coordonnées d’un contact disponible en cas d’incident
- les conditions pouvant entraîner l’arrêt temporaire ou définitif des tests
Un point mérite également d’être clarifié : la présence de prestataires tiers dans le périmètre.
Si une application, une infrastructure ou un service appartient à un hébergeur ou à un prestataire externe, assurez-vous que vous disposez bien de l’autorisation nécessaire avant de l’inclure dans le test.
Enfin, prévoyez un contact capable de réagir rapidement pendant la mission. Si un comportement inhabituel est observé ou si un doute apparaît sur l’impact d’un test, l’auditeur doit pouvoir joindre quelqu’un sans attendre plusieurs heures.
L’objectif des règles d’engagement est finalement assez simple : permettre à l’auditeur de tester suffisamment loin pour produire des résultats utiles, tout en maîtrisant le risque pour votre environnement.
6. Formaliser le cadre de la mission
À ce stade, l’objectif, le périmètre, le type de test et les règles d’engagement sont définis. Il reste maintenant à formaliser tout cela avant le démarrage de la mission.
Plusieurs documents permettent de s’assurer que le client et l’auditeur partagent la même compréhension de la mission et, surtout, que le test est réalisé dans un cadre autorisé et maîtrisé.
L’autorisation de réaliser les tests
C’est probablement le document le plus important.
Il doit permettre d’identifier clairement l’entreprise qui autorise le test, le prestataire qui va le réaliser, le périmètre concerné ainsi que la période pendant laquelle les actions sont autorisées.
Un pentest implique par définition de réaliser des actions qui pourraient être considérées comme malveillantes en dehors de ce cadre. L’auditeur doit donc pouvoir démontrer qu’il dispose bien d’une autorisation explicite pour intervenir sur les systèmes concernés.
Cette autorisation doit également être cohérente avec le périmètre défini précédemment. Si certains actifs appartiennent à un prestataire ou à un tiers, il faudra vérifier que l’entreprise dispose bien de l’autorité nécessaire pour en autoriser le test.
L’accord de confidentialité
Durant un pentest, l’auditeur peut être amené à accéder à des informations particulièrement sensibles : données internes, informations techniques, comptes utilisateurs, configurations, code source ou encore données métier.
Un accord de confidentialité permet de définir la manière dont ces informations devront être manipulées, stockées et protégées pendant et après la mission.
Il peut également préciser les conditions de conservation et de destruction des données collectées au cours du test.
Le résumé du cadrage
Enfin, je recommande de conserver un document synthétique reprenant les principaux éléments définis lors du cadrage :
- l’objectif du test
- le périmètre inclus
- les éléments hors périmètre
- le type de test choisi
- les dates de la mission
- les règles d’engagement
- les contacts utiles
- les accès et documents qui seront fournis
- les livrables attendus
L’objectif est simple : le client et l’auditeur doivent pouvoir relire ce document avant le début de la mission et partager la même compréhension de ce qui va être réalisé.
7. Préparer l’après-pentest avant même de commencer
Un test d’intrusion ne devrait pas se terminer au moment où l’auditeur vous remet son rapport.
Avant même le début de la mission, il est utile de savoir ce que vous allez faire des résultats obtenus.
Qui devra participer à la restitution ? La direction, les équipes techniques, le prestataire qui maintient l’application ? Qui sera responsable du suivi des corrections ? Un re-test est-il prévu une fois les vulnérabilités corrigées ?
Ces questions peuvent sembler prématurées avant le lancement du pentest, mais elles permettent d’éviter qu’un rapport reste plusieurs semaines dans une boîte mail sans réel suivi.
Je vous conseille notamment de définir en amont :
- les personnes qui recevront le rapport
- les participants à la restitution
- les équipes responsables de la remédiation
- la manière dont les vulnérabilités seront suivies
- les modalités d’échange avec l’auditeur pendant la phase de correction
- la réalisation éventuelle d’un re-test après remédiation
La restitution doit également être adaptée aux personnes qui vont recevoir les résultats.
Une direction aura principalement besoin de comprendre les risques, les impacts et les priorités, tandis que les équipes techniques auront besoin de détails suffisamment précis pour reproduire les vulnérabilités et les corriger.
L’objectif est finalement simple : faire en sorte que le pentest débouche sur des actions concrètes, et pas uniquement sur la production d’un rapport.
Conclusion : votre préparation pentest bullet-proof
Vous l’aurez compris, préparer un test d’intrusion ne consiste pas simplement à fixer une date et à transmettre quelques adresses IP à l’auditeur.
L’objectif, le périmètre, le type de test, les accès disponibles ou encore les contraintes de la mission vont directement influencer la manière dont le pentest sera réalisé.
Et surtout, un bon cadrage permet d’éviter de perdre un temps précieux une fois la mission commencée. Le temps prévu pour tester votre sécurité doit, autant que possible, être consacré à cela.
Pour vous aider à préparer ces différents éléments, j’ai regroupé les principales questions à se poser dans un document à compléter avant votre prochain pentest.
Un support pour préparer votre mission
Pour accompagner cette phase, j’ai conçu un modèle de préparation permettant de structurer les principales informations nécessaires avant un test d’intrusion :
- l’objectif du pentest
- le périmètre à tester
- les éventuels éléments hors périmètre
- le type de test envisagé
- les accès et informations disponibles
- la documentation pouvant être fournie
- les contraintes particulières de la mission
- la restitution et la remédiation
Ce document n’a pas vocation à remplacer l’échange de cadrage avec le pentester. Il sert au contraire de support pour arriver à cet échange avec une vision plus claire du besoin et identifier ensemble les éventuels points restant à préciser.
Il est fourni aux entreprises qui souhaitent préparer une mission de test d’intrusion avec Lumerial.
Vous envisagez de réaliser un test d’intrusion ?
Si vous avez déjà identifié un besoin, ou si vous souhaitez simplement déterminer quel périmètre serait pertinent à tester, nous pouvons commencer par un premier échange de cadrage.
L’objectif est de comprendre votre environnement, ce que vous souhaitez réellement vérifier et de définir une mission adaptée à votre besoin.
Pour en savoir plus sur notre manière de travailler :
