Comment rédiger un bon rapport de pentest

Une fois votre test d'intrusion terminé, vous devez remettre un rapport détaillé sur la posture de sécurité de votre client.

Dans certains cas, vous serez amené à collaborer avec d'autres pentesteurs pour rédiger ce document.

Je vais vous présenter ici un exemple de rapport type que j'utilise au sein de ma société, Hacking Geek Ltd.

Tout d'abord, on retrouve sur la page de garde le nom de l'entreprise et la mention « Business Confidential », ce qui signifie que la lecture de ce document est strictement réservée aux personnes autorisées.

Dans cet exemple, le rapport est rédigé en anglais.

Nous y trouvons une table des matières (Table of Contents) détaillant toutes les sections et les vulnérabilités qui seront abordées.

Ce modèle fait 20 pages, mais il n'est pas rare de voir des rapports de test d'intrusion dépasser les 200 pages, selon l'étendue du périmètre testé et le nombre de failles identifiées.

Le document commence par une clause de confidentialité (Confidentiality Statement) et une clause de non-responsabilité (Disclaimer), accompagnées de mes coordonnées pour tout contact.

Vient ensuite la vue d'ensemble de l'audit (Assessment Overview), où je présente le contexte général du test d'intrusion.

Dans la section suivante (Assessment Component), je détaille la méthodologie et les types de tests menés (par exemple, un test d'intrusion sur application web ou Web Application Penetration Testing), ainsi que les vecteurs d'attaque autorisés ou exclus.

Ensuite, nous listons les failles découvertes (par exemple, celles identifiées avec Nessus ou Nmap) en précisant pour chacune son niveau de sévérité.

Nous y ajoutons une évaluation des facteurs de risque et des probabilités d'exploitation (Risk Factors et Likelihood), pour évaluer les chances qu'un attaquant réel exploite ces failles.

La section concernant le périmètre (Scope) définit précisément les cibles.

Dans cet exemple, je n'avais pas l'autorisation de mener des attaques d'ingénierie sociale ou de phishing, ni de lancer des attaques par déni de service (DoS).

Si vous identifiez une faille qui pourrait mener à un DoS, vous devez le mentionner dans le rapport sans pour autant tenter de l'exploiter activement.

Le rapport contient également un résumé managérial (Executive Summary) et un résumé technique (Testing Summary) reprenant l'ensemble des vulnérabilités découvertes.

Dans ce cas précis, il s'agit d'un audit de réseau d'entreprise basé sur une architecture Microsoft Active Directory.

On y retrouve donc des vulnérabilités spécifiques à cet environnement, comme les attaques LLMNR ou d'autres faiblesses inhérentes à Active Directory.

La partie finale et la plus importante du rapport concerne les recommandations.

Le but ultime d'un test d'intrusion est d'aider le client à se sécuriser.

Nous devons donc lui proposer des actions correctives concrètes : appliquer des correctifs de sécurité (patchs), effectuer des mises à jour système, modifier des configurations, voire conseiller l'acquisition de nouveaux équipements ou l'optimisation des solutions logicielles existantes.

En tant que pentesteur, vous n'êtes pas chargé d'appliquer vous-même ces correctifs.

Cependant, il est d'usage de proposer un contre-test (un re-test) après un délai de trois à six mois pour vérifier si les équipes du client ont correctement résolu les problèmes identifiés.

Le rapport se termine par un récapitulatif détaillé des vulnérabilités classées par sévérité.

Pour la rédaction de votre rapport, je vous conseille de veiller à utiliser un langage clair et accessible.

Évitez le jargon trop technique ou expliquez-le simplement, surtout si vos interlocuteurs ne sont pas des profils techniques.

L'objectif est que le client comprenne parfaitement la nature et l'impact des risques pesant sur son infrastructure, afin de lui donner les clés et la motivation nécessaires pour corriger ces failles de sécurité.

C'est l'essence même de notre métier.