Comment se préparer à un test d'intrusion : guide pour les entreprises

Sommaire

Vous avez décidé de faire réaliser un test d’intrusion sur votre système d’information. Excellent choix. Mais avant que le pentester ne commence son travail, une phase de préparation est essentielle pour garantir le succès de la mission. Une bonne préparation permet d’optimiser le temps d’audit, de limiter les risques d’incidents et d’obtenir des résultats réellement exploitables.

Ce guide détaille tout ce que vous devez savoir et préparer avant, pendant et après un test d’intrusion.

Avant le test : la phase de cadrage

Définir le périmètre (scope)

La première étape, et sans doute la plus importante, consiste à définir précisément ce qui sera testé. Un périmètre mal défini entraîne soit un test trop superficiel (trop large pour le temps alloué), soit un test qui ne couvre pas les actifs critiques.

Le périmètre peut inclure :

Applications web : URLs précises, environnements (production, préproduction, staging)
Réseau externe : adresses IP publiques, plages d’adresses, noms de domaine
Réseau interne : sous-réseaux, VLANs, segments spécifiques
Applications mobiles : iOS, Android, versions à tester
APIs : endpoints, documentation (Swagger/OpenAPI), comptes de test
Infrastructure cloud : tenant Azure/AWS/GCP, services spécifiques
Active Directory : domaine(s), forêts, relations d’approbation
Wi-Fi : SSID à tester, localisation géographique des bornes

Soyez le plus précis possible. Par exemple, au lieu de dire « testez notre site web », précisez : « testez l’application accessible sur https://app.exemple.com, incluant les fonctionnalités authentifiées avec les rôles utilisateur, manager et administrateur ».

Définir les exclusions

Tout aussi important que le périmètre, les exclusions définissent ce que le pentester ne doit pas tester ou faire :

Systèmes critiques qui ne supportent pas les tests (dispositifs médicaux, systèmes industriels OT/ICS sensibles)
Attaques par déni de service (DoS/DDoS) — généralement exclues sauf demande explicite
Ingénierie sociale sur certaines personnes (direction, personnalités publiques)
Exploitation destructrice : suppression de données, chiffrement (simulation de ransomware)
Systèmes tiers hébergés sur la même infrastructure mais appartenant à d’autres clients
Plages horaires sensibles : périodes de forte activité, clôtures comptables, événements importants

Documentez les exclusions par écrit dans la convention de test. Si un système est fragile et pourrait tomber en panne lors d’un test, signalez-le explicitement au pentester.

Choisir le type de test

Le type de test influence directement la préparation nécessaire :

Test en boîte noire (black box) :

Le pentester n’a aucune information préalable
Simule un attaquant externe sans connaissance de l’infrastructure
Préparation côté client : minimale (juste le périmètre et les exclusions)
Idéal pour : évaluer la surface d’attaque vue de l’extérieur

Test en boîte grise (grey box) :

Le pentester dispose d’informations partielles : comptes utilisateurs, documentation, architecture réseau
Simule un attaquant ayant déjà un premier accès ou un insider malveillant
Préparation côté client : créer des comptes de test, fournir la documentation technique
Idéal pour : évaluation approfondie des applications web et des réseaux internes

Test en boîte blanche (white box) :

Le pentester a accès au code source, à l’architecture complète, aux comptes à privilèges
Permet l’analyse la plus approfondie possible
Préparation côté client : accès au code source, documentation complète, comptes admin de test
Idéal pour : revue de sécurité avant mise en production, audit de conformité

Le choix du type de test dépend de vos objectifs. Pour une première évaluation, un test en boîte grise offre généralement le meilleur rapport entre profondeur d’analyse et réalisme.

Informations à fournir au pentester

Selon le type de test choisi, voici les informations typiquement nécessaires :

Pour tous les types de tests :

Périmètre et exclusions documentés
Contacts d’urgence (technique et décisionnel)
Plages horaires autorisées pour les tests
Contraintes particulières (systèmes fragiles, périodes sensibles)
Autorisations légales signées (lettre de mission, convention de test)

Pour les tests en boîte grise (en plus) :

Comptes utilisateurs de test avec différents niveaux de privilèges
Documentation de l’architecture réseau (schéma réseau, VLANs)
Documentation des applications (guides utilisateur, spécifications fonctionnelles)
Accès VPN si le test inclut le réseau interne

Pour les tests en boîte blanche (en plus) :

Accès au code source (repository Git)
Documentation technique détaillée (architecture, modèle de données)
Comptes administrateurs de test
Accès aux logs et aux outils de monitoring

Les documents contractuels indispensables

Avant tout test d’intrusion, plusieurs documents doivent être signés :

La convention de test (ou lettre de mission) : Ce document formalise l’accord entre le client et le prestataire. Il doit contenir :

L’identité des parties
Le périmètre exact du test
Les exclusions
Les dates et horaires autorisés
Les contacts d’urgence
Les obligations de confidentialité
La clause de non-responsabilité pour les incidents liés au test
L’autorisation explicite de réaliser des tests d’intrusion

L’autorisation du propriétaire de l’infrastructure : Si vous utilisez des services hébergés (cloud, hébergement mutualisé), vous devez obtenir l’autorisation écrite du propriétaire de l’infrastructure. La plupart des fournisseurs cloud (AWS, Azure, GCP) ont des procédures spécifiques pour autoriser les tests d’intrusion sur leurs plateformes.

Sans ces documents, le test d’intrusion pourrait être considéré comme une infraction pénale au titre de l’article 323-1 du Code pénal (accès frauduleux à un système de traitement automatisé de données).

Pendant le test : communication et réactivité

Désigner un point de contact

Identifiez une personne côté client qui sera le point de contact unique du pentester pendant toute la durée de la mission. Cette personne doit :

Être joignable rapidement (téléphone, messagerie instantanée)
Avoir l’autorité pour prendre des décisions techniques (débloquer un compte, fournir un accès)
Comprendre le périmètre et les objectifs du test
Pouvoir distinguer les actions du pentester d’une vraie attaque dans les logs

Prévenir les équipes concernées

Informez (ou non, selon les objectifs) les équipes qui pourraient être impactées :

Équipe IT / SOC : pour éviter qu’ils ne bloquent les adresses IP du pentester en pensant à une vraie attaque. Selon les objectifs, vous pouvez choisir de ne pas les prévenir pour tester leur capacité de détection
Hébergeur : si les tests sont réalisés sur une infrastructure hébergée
Équipe métier : si les tests portent sur des applications critiques en production
Direction : pour valider que le test a été autorisé

Gérer les découvertes critiques

Établissez un protocole pour les vulnérabilités critiques découvertes pendant le test. Le pentester doit pouvoir alerter immédiatement si une faille permet un accès non autorisé à des données sensibles ou représente un risque immédiat pour l’entreprise.

Ce protocole doit définir :

Qui est alerté (contact technique + contact décisionnel)
Par quel canal (appel téléphonique pour les urgences)
Quelles actions immédiates prendre (isoler le système, appliquer un correctif temporaire)
Si le test doit être suspendu en attendant la correction

Ne pas modifier l’environnement pendant le test

Pendant la durée du test, évitez de :

Déployer des mises à jour ou des correctifs de sécurité
Modifier la configuration du pare-feu ou des règles de détection
Ajouter ou supprimer des services
Changer les mots de passe des comptes de test

Ces modifications fausseraient les résultats du test et pourraient faire perdre du temps au pentester.

Après le test : exploitation des résultats

Le rapport de test d’intrusion

Un rapport de pentest professionnel contient généralement :

Synthèse managériale : résumé des principaux risques en langage non technique, destiné à la direction
Méthodologie : description de l’approche utilisée et des outils employés
Inventaire des vulnérabilités : chaque faille documentée avec sa criticité (CVSS), sa description technique, les preuves d’exploitation (captures d’écran, extraits de code), et les recommandations de correction
Scénarios d’attaque : démonstration des chaînes d’exploitation (comment un attaquant pourrait combiner plusieurs failles)
Plan de remédiation priorisé : liste des actions correctives classées par criticité et facilité de mise en œuvre

Prioriser les corrections

Toutes les vulnérabilités ne doivent pas être corrigées avec la même urgence. Utilisez une matrice de priorisation basée sur :

La criticité technique (score CVSS)
L’impact métier : quelle est la conséquence si cette faille est exploitée ?
La facilité d’exploitation : est-elle exploitable depuis Internet ou uniquement en interne ?
Le coût de correction : certaines corrections sont simples (changer un paramètre), d’autres nécessitent un développement important

Commencez par les failles critiques et faciles à corriger, puis planifiez les corrections plus complexes.

Planifier un retest

Après avoir corrigé les vulnérabilités, planifiez un retest pour vérifier que les corrections sont effectives et qu’elles n’ont pas introduit de nouvelles failles. Le retest est généralement plus court et moins coûteux que le test initial car il se concentre uniquement sur les points identifiés.

Le délai idéal entre le rapport et le retest est de 4 à 8 semaines, le temps de mettre en œuvre les corrections prioritaires.

Intégrer les résultats dans votre stratégie de sécurité

Le rapport de pentest ne doit pas rester dans un tiroir. Utilisez-le pour :

Alimenter votre registre des risques et mettre à jour votre analyse de risques
Justifier des investissements en cybersécurité auprès de la direction
Former vos développeurs aux bonnes pratiques de développement sécurisé
Améliorer vos processus : revue de code, tests automatisés, CI/CD sécurisé
Planifier le prochain test en identifiant les nouveaux périmètres à couvrir

Checklist récapitulative

Voici une checklist pratique à suivre avant votre prochain test d’intrusion :

En suivant ce guide, vous maximiserez la valeur de votre test d’intrusion et obtiendrez des résultats directement exploitables pour renforcer votre sécurité. Chez Expert Intrusion, nous accompagnons nos clients tout au long de ce processus, de la phase de cadrage jusqu’au retest final.