Préparer un test d'intrusion
L'utilité d'un test d'intrusion dépend avant tout de son périmètre. Quelques jours de préparation vous permettront d'obtenir un rapport bien plus pertinent.
Un test d’intrusion consiste à rémunérer une équipe qualifiée pour attaquer votre produit, selon des règles convenues, et rapporter ce qu’elle a trouvé. Les clients et les auditeurs en demandent souvent, et c’est l’un des meilleurs moyens de repérer les failles que votre propre équipe ne voit plus. Ce que vous en tirez dépend largement de la préparation.
Définir le périmètre
Listez exactement ce que les testeurs peuvent attaquer : l’application web, les applications mobiles, l’API, les outils d’administration, le compte cloud. Précisez les environnements et les domaines. Tout ce qui ne figure pas sur la liste ne sera pas testé. Incluez donc les éléments qui comptent pour vos clients, pas seulement ceux dont vous êtes sûr. Si un composant est géré par un tiers, vérifiez que vous avez le droit de l’inclure.
Convenir des règles d’engagement
Définissez par écrit la période de test, les adresses d’où partiront les testeurs, ce qui est exclu (déni de service, ingénierie sociale, données réelles de clients) et qui contacter en cas d’interruption de service. Vérifiez la politique de votre hébergeur concernant les tests de sécurité et prévenez-le si nécessaire. Informez les personnes chargées de surveiller vos alertes qu’un test est en cours, afin qu’un véritable incident ne soit pas ignoré.
Préparer l’environnement et les comptes
Tester un environnement de préproduction est généralement plus sûr, tant qu’il correspond fidèlement à la production : même code, même configuration et mêmes paramètres de sécurité. Créez des comptes de test pour chaque rôle, y compris dans deux organisations clientes distinctes, afin que les testeurs vérifient si un client peut accéder aux données d’un autre. Pour un produit mutualisé, c’est souvent le constat le plus important.
Partagez la documentation, les spécifications d’API et les identifiants, sauf si vous souhaitez expressément une approche purement externe. Les testeurs qui disposent des informations internes consacrent leur temps à chercher de vrais problèmes plutôt qu’à redécouvrir les bases.
Corriger selon la gravité et la portée
Le rapport classera les vulnérabilités par niveau de gravité. Corrigez d’abord les failles critiques et élevées, mais examinez aussi ce que chaque faille permet d’atteindre : un problème moyen sur la page de connexion peut avoir plus d’impact qu’un problème élevé sur un outil interne. Consignez une brève note pour chaque correction, car auditeurs et clients voudront peut-être savoir comment elles ont été traitées.
Demander un retest
La plupart des testeurs incluent ou proposent un retest des failles que vous avez corrigées. Profitez-en. Un retest confirme que les correctifs fonctionnent et vous fournit un rapport actualisé attestant de leur résolution, ce que vos clients attendent.
Partager le bon document
Les clients ont rarement besoin du rapport complet, qui décrit en détail comment attaquer votre produit. Demandez aux testeurs une lettre d’attestation : un court résumé du périmètre, des dates et des résultats, que vous pourrez partager librement. Réservez le rapport complet à ceux qui ont strictement besoin d’en connaître.
En résumé
Un périmètre clair, des règles écrites, un environnement identique à la production, des comptes de test pour chaque rôle et un retest après les correctifs. Préparez ces éléments, et le rapport deviendra un plan d’action plutôt qu’une mauvaise surprise.