Que contient un rapport de test d'intrusion ?

Un test d'intrusion (pentest) simule, avec votre autorisation écrite, ce qu'un attaquant tenterait contre vos sites, vos applications ou votre réseau. Le livrable n'est pas la liste des outils utilisés : c'est un rapport que votre direction peut lire en dix minutes et que votre équipe technique peut suivre pas à pas. Voici ce qu'il doit contenir, et ce qui doit vous alerter s'il n'y est pas.

1. La portée et la méthode

La première page dit ce qui a été testé, ce qui ne l'a pas été, quand, et selon quelles règles. Une portée honnête nomme les systèmes (domaines, adresses, applications, comptes fournis), la fenêtre de test, les techniques exclues (déni de service, ingénierie sociale, par exemple) et le niveau d'information de départ : boîte noire (aucune information), boîte grise (un compte utilisateur) ou boîte blanche (code source et documentation).

La méthode s'appuie sur des cadres publics. Le guide NIST SP 800-115 décrit les phases d'une évaluation technique (planification, découverte, attaque, rapport) et sert de référence générale. Pour les applications Web, le Web Security Testing Guide de l'OWASP (version stable 4.2, la version 5.0 est en préparation) énumère les catégories de tests : configuration, authentification, gestion de session, validation des entrées, logique d'affaires, et ainsi de suite. Un rapport qui cite le cadre suivi vous permet de comparer deux tests, ou deux fournisseurs, sur la même base.

2. Le sommaire exécutif

Une page, sans jargon. Elle répond à trois questions : un attaquant peut-il entrer, jusqu'où peut-il aller, et qu'est-ce qui l'en empêche aujourd'hui ? Elle donne le nombre de constats par gravité et les deux ou trois décisions à prendre cette semaine. Si le sommaire fait cinq pages ou reprend les détails techniques, il ne remplit pas son rôle.

3. Les constats classés par gravité

Chaque constat porte un titre, une gravité, les systèmes touchés, une description et l'impact concret pour l'entreprise (« un visiteur non authentifié peut lire les factures d'autres clients », plutôt que « injection SQL sur le paramètre id »).

La gravité est notée avec un système reconnu, en général CVSS (Common Vulnerability Scoring System, publié par FIRST). Le score CVSS mesure la sévérité technique ; le rapport doit aussi indiquer le risque dans votre contexte, car une vulnérabilité « critique » sur un serveur de test isolé n'a pas la même urgence que la même faille sur votre portail client. Les deux notes doivent apparaître, avec leur justification.

4. Les preuves

Pour chaque constat : les étapes de reproduction, les requêtes ou commandes utilisées, les captures d'écran, et ce qui a été obtenu. Sans preuves, votre équipe ne peut ni vérifier le constat, ni confirmer la correction. Les preuves doivent être expurgées des renseignements personnels réels ; si le testeur a accédé à des données de clients pour démontrer l'impact, le rapport le dit et précise ce qui a été fait de ces données.

5. Les recommandations et le plan de correction

Une recommandation par constat, formulée pour la personne qui va corriger : quoi changer, où, et comment vérifier que c'est réglé. Les bonnes recommandations distinguent la correction immédiate (fermer la faille) de la cause de fond (le processus qui l'a laissée passer). Le plan ordonne les corrections par risque et par effort, pas par ordre de découverte.

6. Le retest

Un test d'intrusion se termine par une vérification des corrections. Le rapport final, ou un addendum, indique pour chaque constat s'il est corrigé, partiellement corrigé ou toujours ouvert, avec la date du retest. C'est ce document que vous présentez à un client, un assureur ou un auditeur.

Ce que demandent les normes

Si vous traitez des données de cartes de paiement, la norme PCI DSS exige des tests d'intrusion selon une méthodologie définie, sur les réseaux internes et externes du périmètre des données de cartes, et la correction des vulnérabilités exploitables trouvées. Les audits SOC 2 et ISO/IEC 27001 n'imposent pas un format de rapport, mais vos auditeurs voudront voir la portée, la date, les constats, le plan de correction et le retest : exactement les six sections ci-dessus.

Ce qui doit vous alerter

• Un rapport sans portée écrite ni date : vous ne saurez pas ce qui a été couvert.
• Une liste brute de sortie d'outil de balayage présentée comme un test d'intrusion : le balayage automatisé est une étape, pas le test.
• Des gravités sans justification ni score : impossible à prioriser.
• Aucune preuve reproductible : impossible à vérifier.
• Aucune mention des données réelles consultées : un problème de confidentialité et, au Québec, une question de Loi 25.
• Pas de retest prévu : le test mesure un état, il n'améliore rien tant que rien n'est corrigé et vérifié.

Comment nous travaillons

Nos tests d'intrusion suivent cette structure. La portée est convenue par écrit avant le premier paquet envoyé, les constats sont classés avec CVSS et remis dans votre contexte, aucune donnée réelle n'est conservée après la livraison, et le retest fait partie du mandat. Le rapport est écrit pour deux lecteurs : la direction, qui décide, et l'équipe technique, qui corrige.