Préparer un test d’intrusion : ce qu’il faut savoir avant de commencer

1. Fixer l’objectif

Pourquoi faites-vous ce test ? La réponse oriente tout le reste :

• avant une mise en production : vérifier qu’une nouvelle application ne présente pas de faille majeure ;
• exigence d’un client, d’un régulateur ou d’un assureur : produire un rapport reconnu ;
• après un incident : comprendre comment l’attaquant est entré et s’assurer que la porte est fermée ;
• contrôle périodique : mesurer votre niveau de sécurité dans le temps.

2. Délimiter le périmètre

Listez précisément ce qui sera testé, et ce qui ne le sera pas :

• applications web et API (URL, environnements, rôles utilisateurs) ;
• applications mobiles (iOS, Android) ;
• adresses IP et services exposés sur Internet ;
• réseau interne et annuaire (Active Directory) ;
• Wi-Fi, accès physiques, ingénierie sociale (hameçonnage simulé), le cas échéant.

Ce qui n’est pas écrit dans le périmètre ne doit pas être testé. Écrivez aussi la liste des exclusions : elle évite les malentendus.

3. Choisir l’approche

Boîte noire

Le testeur ne dispose d’aucune information, comme un attaquant externe. Réaliste, mais une partie du temps passe en reconnaissance.

Boîte grise

Le testeur reçoit des comptes utilisateurs et une documentation de base. C’est le meilleur compromis pour la plupart des applications.

Boîte blanche

Le testeur a accès au code, à l’architecture et aux configurations. Couverture maximale, idéale avant une mise en production critique.

4. Obtenir les autorisations écrites

Un test d’intrusion sans autorisation est un accès frauduleux à un système informatique, puni par la loi (au Maroc, articles 607-3 et suivants du Code pénal, issus de la loi 07-03 ; en France, article 323-1 du Code pénal). Avant de commencer, il faut :

• une lettre d’autorisation signée par une personne habilitée à engager l’entreprise sur les systèmes concernés ;
• l’accord des tiers qui hébergent une partie du périmètre : hébergeur, fournisseur cloud, éditeur SaaS. Chacun a sa propre politique ; certains demandent d’être prévenus ;
• les dates, horaires et adresses IP d’où partiront les tests, pour que vos équipes puissent les reconnaître.

5. Préparer l’environnement

• Production ou pré-production ? La pré-production limite les risques, à condition d’être identique à la production.
• Sauvegardes vérifiées juste avant le test, avec une restauration testée.
• Comptes de test pour chaque rôle (utilisateur, gestionnaire, administrateur), sans données réelles si possible.
• Fenêtres horaires : éviter les pics d’activité et les périodes de clôture.
• Prévenir ou non vos équipes de supervision ? Les prévenir évite les fausses alertes ; ne pas les prévenir permet de tester aussi votre capacité de détection. Décidez-le à l’avance.

6. Organiser les contacts

• un référent technique disponible pendant toute la durée du test ;
• un numéro d’urgence des deux côtés, et une procédure d’arrêt immédiat ;
• une règle claire : toute faille critique découverte est signalée immédiatement, sans attendre le rapport.

7. Exiger des livrables utiles

Un bon rapport se lit à deux niveaux :

• une synthèse pour la direction : niveau de risque global, failles majeures, priorités ;
• un détail technique pour chaque vulnérabilité : description, preuve, niveau de criticité (par exemple selon le barème CVSS), impact, recommandation de correction.

Demandez une réunion de restitution et prévoyez dès le départ un contre-audit pour vérifier que chaque correction est efficace.

Combien de temps ça prend ?

Selon le périmètre, comptez de 5 à 15 jours de test, plus quelques jours pour le rapport. Une application web de taille moyenne en boîte grise se situe généralement dans le bas de cette fourchette ; un réseau interne étendu dans le haut.

La check-list en résumé

1. Objectif du test écrit et partagé.
2. Périmètre et exclusions listés.
3. Approche choisie (noire, grise, blanche).
4. Lettre d’autorisation signée ; tiers informés.
5. Environnement, sauvegardes et comptes de test prêts.
6. Dates, horaires et IP sources communiqués.
7. Contacts, numéro d’urgence et procédure d’arrêt définis.
8. Format du rapport, restitution et contre-audit prévus.

FIDO TEAM réalise des tests d’intrusion sur applications, API, infrastructures et réseaux internes, et vous accompagne jusqu’au contre-audit. Parlons de votre périmètre.