En bref
Un rapport de test d’intrusion utile contient une synthèse lisible par la direction, le périmètre et la méthode, et pour chaque constat une description, une preuve reproductible, l’impact démontré, une gravité justifiée et une recommandation précise. Il précise aussi ce qui n’a pas été testé et les conditions du contre-test des correctifs. Un rapport sans requête, sans réponse obtenue et sans impact est un rapport de scan, pas de test d’intrusion.
Pourquoi le rapport est-il le vrai livrable ?
Un test d’intrusion produit de la valeur à deux moments : quand les analystes trouvent un défaut, et quand une équipe le corrige. Le rapport est le pont entre les deux. Un défaut mal décrit n’est pas corrigé, ou l’est de travers. Le guide NIST SP 800-115 consacre une partie à la restitution des résultats, parce que le résultat d’une évaluation de sécurité n’existe qu’à travers ce qui est communiqué.
Le rapport sert aussi à d’autres lecteurs que l’équipe technique : la direction, qui arbitre le budget de correction, un client, un assureur ou un auditeur qui demande une preuve. Il doit donc fonctionner à plusieurs niveaux de lecture.
Quelles sections un rapport doit-il contenir ?
- Une synthèse de direction d’une à deux pages : le niveau d’exposition en langage clair, les trois ou quatre risques majeurs, ce qu’il faut faire en premier, sans jargon.
- Le cadre de la mission : dates, périmètre, niveau d’information fourni (boîte noire, grise ou blanche), comptes utilisés, règles d’engagement et contraintes rencontrées.
- La méthode : référentiels appliqués et familles de vérifications couvertes, pour que le lecteur sache ce qui a été examiné.
- Les constats, un par fiche, classés par gravité.
- Le périmètre non couvert et les limites : ce qui n’a pas été testé et pourquoi, car l’absence de constat n’est pas l’absence de défaut.
- Un plan de correction priorisé qui regroupe les corrections liées.
- Les conditions du contre-test et, après la vérification, un statut par constat : corrigé, partiellement corrigé, non corrigé.
Que doit contenir la fiche d’un constat ?
- 1Un titre qui décrit le défaut et son effet, et non un nom de catégorie seul.
- 2Où il se trouve : le composant, l’URL ou le point d’entrée exact, et le rôle utilisé.
- 3Comment le reproduire : la requête exacte et la réponse obtenue, ou une séquence d’étapes qu’une équipe peut rejouer sans l’analyste.
- 4L’impact démontré : ce qu’un attaquant obtient, avec la donnée ou l’action prouvée.
- 5La gravité et sa justification : un score CVSS peut y figurer, mais il décrit le défaut en lui-même et doit être ajusté selon votre contexte, ce qu’il faut expliquer.
- 6La recommandation : une correction précise, avec une mesure à court terme si la correction définitive demande un chantier.
- 7Les références : la catégorie dans l’OWASP Top 10, l’identifiant de faiblesse CWE si pertinent.
Quels signaux montrent un mauvais rapport ?
- Des centaines de lignes sans preuve : le volume n’est pas un indicateur de qualité.
- Des constats copiés de la documentation d’un outil, identiques d’un client à l’autre.
- Aucune mention de ce qui n’a pas été testé.
- Une gravité identique à celle du scanner, sans ajustement ni explication.
- Aucune recommandation exploitable, seulement « mettre à jour » ou « appliquer les bonnes pratiques ».
- Une conclusion qui affirme que le système est sûr.
Comment un rapport se lit-il selon que l’on est direction ou technicien ?
Un bon rapport se lit en trois temps. La direction lit la synthèse : le niveau d’exposition, les risques majeurs, les décisions à prendre et le budget de correction à prévoir. Elle ne devrait pas avoir à ouvrir les fiches pour comprendre ce qui est grave.
Le responsable de la sécurité lit le plan de correction et le tableau des constats : quelles corrections traitent plusieurs défauts à la fois, lesquelles sont rapides, lesquelles demandent un chantier. C’est ce document qui devient un plan d’action avec des responsables et des dates.
Les développeurs et les administrateurs lisent les fiches : requête, réponse, impact, recommandation. Chaque fiche doit être autonome, car elle sera copiée dans un outil de suivi et lue loin du reste du rapport. Une restitution orale avec les équipes qui corrigeront, en plus du document, évite la plupart des malentendus.
Enfin, l’assureur, le client ou l’auditeur lit surtout le périmètre, la méthode et le statut de correction. Il faut donc pouvoir extraire ces éléments sans exposer le détail des défauts non corrigés, par exemple sous la forme d’une attestation de contre-test.
À retenir
- 1Le rapport est le pont entre la découverte d’un défaut et sa correction : une fiche non reproductible ne sera pas corrigée.
- 2Chaque constat porte une preuve, un impact démontré, une gravité justifiée et une recommandation précise.
- 3Un bon rapport dit ce qu’il n’a pas testé et prévoit le contre-test des correctifs.
- 4La gravité s’ajuste au contexte ; trois défauts faibles qui s’enchaînent forment un constat grave.
Comment juger la gravité sans se faire piéger par un score ?
Le système CVSS : définition note la gravité intrinsèque d’une vulnérabilité sur une échelle de 0 à 10. Il est utile pour comparer, mais il ignore votre contexte : un défaut noté moyen sur le serveur qui héberge vos sauvegardes pèse plus qu’un défaut noté élevé sur une machine de démonstration isolée.
Un bon rapport indique donc la gravité retenue et pourquoi, en tenant compte de l’exposition, de la valeur des données et de la facilité d’exploitation. Il explique aussi les chaînes : trois défauts faibles qui, enchaînés, donnent un accès administrateur forment un constat grave, et doivent être présentés comme tel.