Pour préparer un pentest, définissez la question à vérifier, les systèmes autorisés, les limites opérationnelles et les livrables attendus. Ces éléments permettent de demander des devis comparables et de préparer les corrections. « Tester notre sécurité » est trop vague : précisez ce qu'un attaquant ne doit pas pouvoir atteindre.
Partir d'une question métier
Un portail client doit-il empêcher un utilisateur de consulter les dossiers d'un autre client ? Un accès distant pourrait-il ouvrir un chemin vers une application sensible ? Formuler une question concrète aide le prestataire à proposer des scénarios pertinents et à expliquer ce que le test pourra démontrer.
Si la demande vient d'un client, récupérez ses critères avant le devis : périmètre attendu, destinataire du rapport et éventuelle vérification des corrections. Si vous cherchez plutôt un état des lieux général, comparez d'abord pentest et audit de sécurité. Un test ciblé ne remplace pas une évaluation de toute l'organisation.
Décrire le périmètre sans ambiguïté
Listez les domaines, adresses, applications, API et environnements concernés. Indiquez les rôles utilisateurs à tester et les fonctions sensibles : exports, facturation, administration ou partage de documents. Précisez les dépendances à un hébergeur, un éditeur ou un autre prestataire.
Le nombre de pages d'une application explique rarement sa complexité. Les profils d'accès, les échanges entre systèmes et les règles métier influencent aussi l'effort. Une application avec plusieurs rôles demande notamment de vérifier les droits entre ces rôles, pas seulement sa page de connexion.
Fixer les autorisations et les exclusions
Avant le démarrage, faites valider par les responsables habilités les cibles et les règles d'engagement. Identifiez les accords nécessaires pour les systèmes de tiers. Un domaine accessible sur Internet ne constitue pas à lui seul une autorisation de le tester.
- Environnement : production ou préproduction, différences connues et données utilisables.
- Limites : actions interdites, systèmes exclus, plages de test et conditions d'arrêt.
- Coordination : contacts disponibles, signalement d'une faille critique et procédure en cas de perturbation.
- Preuves : modalités de collecte, protection, transmission, conservation et suppression.
Ne supposez pas que les tests de déni de service, le phishing ou les intrusions physiques sont inclus. Ils demandent un cadrage spécifique. Pour les données sensibles, convenez de preuves suffisantes sans collecte inutile. Le test doit rester dans les limites approuvées.
Préparer les accès et les équipes
En boîte noire, le test démarre avec peu d'informations. En boîte grise, des accès ou informations ciblés sont fournis. En boîte blanche, l'équipe dispose d'une connaissance plus étendue du système. Choisissez selon la question à résoudre ; le mode le moins informé n'est pas automatiquement le plus utile.
Pour un test authentifié, préparez des comptes adaptés aux rôles prévus, des données de test et une documentation des parcours importants. Vérifiez les accès avant la fenêtre convenue. Informez les personnes chargées de l'exploitation selon les règles retenues, et organisez la révocation des comptes après la mission.
Exiger des livrables qui permettent de corriger
La proposition doit décrire un rapport avec le périmètre réellement testé, les limites rencontrées, les constats, leurs preuves et des recommandations exploitables. Demandez une priorisation qui explique l'impact dans votre contexte et une restitution adaptée aux équipes techniques comme à la direction.
Prévoyez qui recevra les constats urgents sans attendre le rapport final. Le rapport complet contient des informations sensibles : définissez ses destinataires et son canal de partage. Une synthèse destinée à un client peut nécessiter un contenu distinct du rapport technique.
Prévoir la suite et le retest
Désignez un responsable des corrections avant de lancer le test. Le retest vérifie ensuite les corrections sur les constats convenus ; il ne vaut pas automatiquement nouveau pentest complet. Faites préciser s'il est inclus, son périmètre, ses conditions et le document remis après vérification.
Scénario fictif — exemple pédagogique, pas une mission client
Une PME souhaite tester son portail documentaire avant de l'ouvrir à de nouveaux clients. Elle fournit des comptes de test associés à des organisations distinctes et demande de vérifier la séparation des dossiers et les droits d'administration. Le prestataire de paiement reste hors périmètre.
Le cahier des charges décrit les parcours autorisés, les contacts en cas de problème et les preuves attendues. Après restitution, l'équipe produit traite les corrections. Un retest peut être commandé ou activé selon l'accord initial. Ce scénario illustre un cadrage ; il ne rapporte aucun résultat de mission.
Questions fréquentes
Un pentest sans faille critique garantit-il la sécurité ?
Non. Les conclusions valent pour le périmètre, la période et les conditions du test. Le rapport doit rendre visibles les exclusions et les limites, notamment les parcours qui n'ont pas pu être examinés.
Peut-on comparer uniquement les prix ?
Comparez d'abord les mêmes cibles, rôles, scénarios, restitutions et conditions de retest. Notre guide sur le prix d'un pentest entreprise explique les facteurs d'effort à examiner.
Pour cadrer votre demande, consultez notre service de test d'intrusion. Si les actifs et les priorités restent à identifier, un audit 360° peut aider à préparer le périmètre.
Équipe Securigeek
Équipe éditoriale