Ce qu'un rapport de test d'intrusion devrait vraiment vous dire

On le voit généralement en dix minutes. Ouvrez le rapport, allez à un constat, et posez une seule question : mon ingénieur pourrait-il corriger cela lundi avec uniquement ce qui est écrit ici ? Si la réponse est non, vous n'avez pas acheté un test d'intrusion. Vous avez acheté une licence de scanner avec l'en-tête d'un consultant.

Le signe : de la sévérité sans récit

Un scanner produit une liste. Quarante constats, chacun avec un score CVSS, chacun vrai indépendamment, et aucun relié aux autres. Un testeur produit un récit : ce sous-domaine oublié exposait une page de connexion de préproduction, la préproduction partageait un mot de passe avec la production, et la production n'avait pas de MFA sur les comptes d'administration. Pris séparément : moyen, moyen, faible. Enchaînés, c'est ainsi qu'on prend possession de votre environnement avant le déjeuner.

Si votre rapport ne contient aucune chaîne — aucune phrase commençant par « en combinant les constats 12, 19 et 27 » — personne ne vous a réellement testé. On a pointé un outil vers vous.

Quarante constats classés par score vous disent ce qu'un scanner a remarqué. Neuf constats classés par ce qu'un attaquant en ferait vous disent quoi corriger.

Ce dont chaque constat a besoin

• Des étapes de reproduction que votre ingénieur peut suivre sans appeler le testeur. La requête exacte, le paramètre exact, la condition préalable exacte.
• Des preuves. Une capture d'écran ou une réponse enregistrée prouvant que le problème est réel et non théorique.
• L'impact dans vos termes. Pas « divulgation d'information » — mais « un utilisateur non authentifié peut énumérer toutes les adresses e-mail clients ».
• Un correctif qui nomme la chose. Le fichier, la clé de configuration, l'en-tête. Pas « mettez en place la validation des entrées ».
• Une sévérité honnête, ajustée à votre environnement. Une RCE sur une machine isolée sans données n'est pas une criticité, quoi qu'en dise le scanner.

Les parties que la plupart des rapports omettent

Un bon rapport vous dit aussi ce qui n'a pas été testé, et pourquoi. Les limites du périmètre, les systèmes hors champ, les identifiants jamais reçus, l'environnement indisponible deux jours sur la fenêtre. Ces trous sont un risque que vous portez toujours, et les cacher rend le rapport plus beau tout en vous laissant moins protégé.

Il devrait aussi dire ce qui a tenu. Si votre WAF a bloqué les tentatives d'injection et si votre EDR a tué la charge, cela mérite d'être écrit. Vous l'avez payé ; vous devriez pouvoir prouver que ça marche.

Le contre-test fait partie du travail

Un constat n'est pas clos parce qu'un ticket a été fermé. Il est clos parce que quelqu'un a réessayé l'exploit et qu'il a échoué. Un cabinet qui facture séparément la vérification de ses propres constats a une incitation dont vous ne voulez pas dans la relation. Le contre-test devrait être inclus, et le rapport réédité devrait montrer le constat barré avec la date de vérification.

Une courte checklist

• Y a-t-il au moins un chemin d'attaque enchaîné, écrit comme un récit ?
• Un ingénieur peut-il reproduire le constat principal sans poser de question ?
• Chaque correctif nomme-t-il un fichier, un paramètre ou un en-tête ?
• Y a-t-il une section sur ce qui était hors périmètre ou non testé ?
• Le contre-test est-il inclus, et pour quand ?
• Les constats critiques ont-ils été signalés pendant le test, et non gardés pour la restitution ?

Ce dernier point compte plus que tous les autres réunis. Si un testeur découvre une compromission active ou une criticité exposée sur internet le deuxième jour, vous devez l'apprendre dans l'heure. L'apprendre par un PDF trois semaines plus tard n'est pas un style de reporting. C'est de la négligence.