Préparer un test d’intrusion : périmètre, déroulement et coûts
Un test d’intrusion examine des systèmes autorisés du point de vue d’une attaque. Son utilité repose sur des résultats exploitables dans votre activité, plutôt que sur le nombre de constats. Décrivez l’objectif et les limites pour que les prestataires chiffrent le même travail. Le résultat concerne une période et un périmètre définis, pas toutes les évolutions futures.
Relier le test à une décision concrète
Une mise en service, un changement important ou la vérification de corrections appellent des travaux différents. Indiquez la décision attendue et les processus importants. Un scan automatisé de vulnérabilités et un test manuel ne présentent pas la même profondeur.
Une liste de faiblesses ne décrit pas à elle seule leur impact. Demandez une vérification des relations utiles, notamment les rôles et les droits d’accès. Un audit organisationnel complet ou une certification ne sont pas automatiquement inclus.
Délimiter clairement les systèmes à examiner
Comptez séparément les applications et les cibles réseau. Des rôles, interfaces et parcours complexes peuvent peser davantage qu’un hôte simple supplémentaire. Définissez ce que représente chaque cible dans l’offre.
| Périmètre | À préciser pour l’offre |
|---|---|
| Application web / API | Applications, rôles, interfaces et parcours importants |
| Réseau interne / externe | Hôtes, réseaux et services expressément autorisés |
| Configuration cloud | Comptes, responsabilités et autorisations |
| Application mobile | Plateformes, versions et services associés |
Convenir des autorisations et des règles avant le début
Le mandat doit autoriser explicitement l’examen des systèmes concernés. Clarifiez les plateformes tierces et les services externalisés : leur utilisation n’autorise pas une inspection de toute leur infrastructure. Les cibles détaillées et les accès éventuels seront transmis ultérieurement par un canal sûr.
Fixez les plages horaires, méthodes exclues, limites de charge, contacts d’urgence et règles d’arrêt. Les essais de disponibilité, l’ingénierie sociale et autres méthodes particulières demandent un accord explicite. Une demande d’offre ne constitue pas encore un mandat technique.
Choisir les informations et l’environnement adaptés
Un examen externe avec peu d’informations et un test avec comptes ou données d’architecture ont des objectifs différents. Demandez pourquoi la méthode proposée correspond à votre besoin. Réduire les informations du testeur ne garantit pas une meilleure couverture.
Un environnement de test peut réduire le risque opérationnel, à condition de représenter les réglages pertinents. En production, la surveillance et les mesures de protection demandent une attention particulière. Préparez des données neutres et des comptes dédiés sans joindre de dossiers clients au formulaire.
Exiger un rapport utilisable
Le rapport doit indiquer périmètre, date, méthode et limites. Les constats confirmés nécessitent des éléments reproductibles, leurs effets et des pistes de correction. Une synthèse compréhensible et des détails techniques peuvent servir des destinataires différents.
Classez les constats selon le risque réel dans votre environnement. Un score technique ou leur nombre ne suffit pas. Conservez des règles claires pour la transmission confidentielle, la conservation, la suppression des documents et l’annonce des constats urgents.
Comparer une profondeur et des livrables équivalents
Les coûts varient avec le périmètre, la complexité, les informations fournies, les travaux manuels et la documentation. Séparez préparation, examen, rapport, restitution et retest. Une offre de scan peut couvrir moins de travail qu’une analyse de la logique métier.
Comparez les mêmes systèmes et exclusions. Précisez la facturation de cibles supplémentaires, des obstacles imprévus et des changements de date. La correction et la surveillance continue restent distinctes sauf inclusion explicite.
| Poste de coût | Délimitation comparable |
|---|---|
| Préparation | Périmètre, autorisations et accès de test |
| Examen | Profondeur manuelle, rôles, systèmes et horaires |
| Résultat | Rapport, priorités et restitution |
| Retest | Corrections concernées et délai prévu |
| Travaux supplémentaires | Extension, correction et tests ultérieurs séparés |
Traiter les constats et vérifier les corrections
Attribuez les constats importants à un responsable et suivez les corrections. Un retest porte sur les corrections convenues ; il ne remplace pas automatiquement un nouvel examen intégral. Définissez le périmètre et les preuves attendues dans l’offre.
Pour une première demande, indiquez objectif, types et nombre de cibles, environnement et calendrier. Des changements importants ou de nouvelles interfaces peuvent justifier une nouvelle évaluation. Le rapport précédent décrit seulement l’état alors examiné.
Questions fréquentes
Un scan équivaut-il à un test d’intrusion ?
Un scan détecte certains motifs connus. Un test peut aussi analyser manuellement les relations et les impacts. Le périmètre convenu fait la différence.
Peut-on tester la production ?
Cela peut être adapté, avec horaires, protections et règles d’arrêt convenus. Une absence totale de perturbation ne peut être garantie.
Un résultat favorable prouve-t-il une sécurité complète ?
Non. Il concerne le périmètre et la période convenus. Des zones non examinées, de nouvelles faiblesses et des changements restent possibles.
Une certification est-elle incluse ?
Un rapport n’est pas une certification automatique. Les critères, le périmètre et la reconnaissance d’un justificatif particulier doivent être précisés.
Faut-il transmettre des mots de passe dans la demande ?
Non. Une description non confidentielle suffit. Les accès de test nécessaires sont convenus séparément et transmis de façon sûre après autorisation.
Quand prévoir un retest ?
Après correction de constats importants. Précisez les corrections vérifiées et les examens complémentaires éventuels.
