Préparer son test d'intrusion : 7 décisions qui font la valeur du rapport

Lundi matin, 9 heures. L'équipe d'auditeurs est prête à démarrer un test d'intrusion de cinq jours. À 9 h 15, les comptes de test n'existent pas encore. À 14 heures, le pare-feu applicatif bloque nos adresses IP. Le test commence réellement le mardi midi.

Un jour et demi perdu sur cinq, et ce n'est la faute de personne : le test n'avait simplement pas été préparé.

Notre constat, mission après mission, est clair : la valeur d'un test d'intrusion se joue en grande partie avant le premier jour. Voici les sept décisions qui font la différence, illustrées par des missions récentes que nous avons menées pour nos clients.

1. Définir un objectif, pas seulement un périmètre

« Testez notre application » n'est pas un objectif. La première question que nous posons est toujours : pourquoi faites-vous ce test ?

Retour d'expérience

Un éditeur SaaS engagé dans une certification

Un éditeur de logiciel de gestion des ressources humaines, destiné aux entreprises et aux établissements publics, nous a sollicités dans le cadre d'une démarche de certification de sécurité. Son besoin n'était pas seulement de trouver des vulnérabilités. Il lui fallait aussi une attestation de test d'intrusion par un tiers externe, à présenter à l'auditeur de certification et à ses clients.

Cet objectif a structuré toute la mission. Le périmètre couvrait précisément la solution commercialisée, et pas un environnement de démonstration. La date de livraison était calée sur le calendrier de certification. Le livrable comprenait un document d'attestation distinct du rapport technique, partageable sans exposer le détail des vulnérabilités.

Chaque objectif oriente différemment la mission : exigence contractuelle d'un client, certification (ISO 27001, HDS, référentiel Ségur), validation avant mise en production, évaluation après incident. Le formaliser dès le départ évite de livrer un excellent rapport qui ne répond pas à la bonne question.

2. Délimiter le périmètre avec précision

Le périmètre doit être défini sans ambiguïté : URL, adresses IP, API, applications mobiles, environnements, fonctionnalités incluses et exclues.

Retour d'expérience

Un prestataire logistique et ses API publiques

Pour un prestataire de services logistiques, le périmètre portait sur trois API publiques. L'une d'elles était une déclinaison dédiée à un grand compte partenaire : même socle technique, mais configuration, données et clients distincts. Il était indispensable de la tester à part entière, car une faille sur cette instance aurait directement exposé le partenaire.

Lors du cadrage, nous avons également identifié le site vitrine de l'entreprise. Il était hors du périmètre initial, mais exposé sur Internet sous le même nom de domaine. Nous l'avons proposé en option, chiffrée séparément. Les sites vitrines sont souvent oubliés, alors qu'ils constituent une cible privilégiée et peuvent nuire à l'image de la marque en cas de compromission.

Deux réflexes sont à adopter :

recenser toutes les instances, y compris les déclinaisons partenaires, marques blanches et sous-domaines ;
identifier les composants tiers (fournisseur d'identité, solution de paiement, hébergeur), que l'on ne peut pas tester sans l'accord de leur propriétaire.

3. Choisir entre boîte noire, grise et blanche

Approche	Informations fournies	Ce qu'elle simule
Boîte noire	Aucune, hormis la cible	Un attaquant externe sans accès
Boîte grise	Comptes utilisateurs, documentation	Un client malveillant, un compte compromis
Boîte blanche	Code source, architecture, accès administrateur	Une revue approfondie

Retour d'expérience

Une plateforme de réservation en ligne

Pour un éditeur de plateforme de réservation en ligne, nous avons combiné les deux premières approches. La mission a commencé par une phase en boîte noire, pour mesurer ce qu'un attaquant anonyme peut découvrir et exploiter. Elle s'est poursuivie en boîte grise, avec des comptes de test, pour évaluer les risques entre utilisateurs authentifiés.

Le client nous a également transmis le rapport de son précédent test d'intrusion. C'est une excellente pratique. Elle permet de vérifier que les vulnérabilités déjà identifiées ont bien été corrigées, et d'orienter le temps de test vers les zones nouvelles ou moins couvertes, plutôt que de redécouvrir les mêmes failles.

Pour une application SaaS, la boîte grise est presque toujours indispensable : les vulnérabilités les plus critiques se situent derrière l'authentification.

4. Préparer les comptes et les données de test

C'est la cause la plus fréquente de journées perdues. Il faut prévoir :

plusieurs comptes par profil (utilisateur, gestionnaire, administrateur) ;
au moins deux organisations clientes distinctes ;
des données de test réalistes, sans données personnelles réelles ;
une vérification des accès la veille du démarrage.

Le deuxième point est essentiel pour toute solution multi-clients. Dans la mission de l'éditeur engagé dans une certification, l'API servait de nombreuses entreprises et établissements publics depuis une même infrastructure. La question centrale était donc le cloisonnement : un utilisateur d'un client peut-il, en modifiant une requête, accéder aux données d'un autre ? Cette question ne peut être testée qu'avec au moins deux comptes appartenant à deux organisations différentes.

5. Choisir l'environnement et anticiper les impacts

Tester en production ou en préproduction ? Nos missions récentes illustrent les deux cas.

Retour d'expérience

Deux choix opposés, tous deux justifiés

Pour la plateforme de réservation, le test s'est déroulé exclusivement en préproduction, avec une autorisation de test en heures non ouvrées. Ce choix permettait de tester librement, sans risque pour les utilisateurs. Il supposait en revanche que la préproduction soit à jour et représentative de la production, ce que nous avons vérifié en début de mission.

Pour le prestataire logistique, les API ont été testées en production. C'était le seul moyen d'évaluer la configuration réelle, protections comprises. Ce choix imposait des précautions strictes : aucun test de déni de service, prudence sur les fonctions modifiant des données, et un interlocuteur joignable en permanence.

Dans tous les cas, prévoyez une sauvegarde récente, la mise en liste blanche des adresses IP des auditeurs si l'objectif n'est pas de tester le filtrage, et l'information de votre hébergeur et de vos équipes d'exploitation.

6. Savoir quand un test d'intrusion ne suffit pas

Certaines situations demandent davantage qu'un test d'intrusion classique.

Retour d'expérience

Un serveur de fichiers exposé sur Internet

Un cabinet d'architectes a découvert que son serveur de fichiers, qui hébergeait les plans et les contrats de ses clients, était accessible depuis Internet depuis plusieurs semaines. Durcir la configuration était nécessaire, mais insuffisant : il fallait d'abord savoir si l'exposition avait été exploitée.

Nous avons donc proposé une mission en deux temps. La première partie était une investigation numérique (forensic), pour rechercher d'éventuelles traces de compromission dans les journaux. La seconde était un audit de configuration, pour corriger les faiblesses. Durcir sans investiguer aurait pu laisser en place un attaquant déjà présent, ou des comptes déjà compromis qu'il fallait renouveler.

7. Prévoir le suivi dans le temps

Un test d'intrusion est une photographie. Le système, lui, évolue en permanence.

Au minimum, planifiez dès le départ :

une réunion de restitution avec les équipes techniques ;
le temps de correction dans le planning de développement ;
un contre-audit pour vérifier l'efficacité des corrections, souvent attendu par les clients et les auditeurs de certification.

La check-list à garder sous la main

Objectif du test formalisé (certification, client, mise en production, incident)
Périmètre précis, toutes instances et déclinaisons recensées
Composants tiers identifiés et exclus ou autorisés
Approche choisie (boîte noire, grise ou blanche)
Précédent rapport de test transmis aux auditeurs
Comptes de test vérifiés, sur plusieurs profils et plusieurs organisations
Environnement choisi et représentatif, sauvegarde réalisée
Adresses IP autorisées, hébergeur et équipes prévenus
Interlocuteur technique désigné et joignable
Restitution, corrections, contre-audit et suivi planifiés

← Tous les articles