Mais avant de parler du fond, parlons de la forme.
Soignez la forme du rapport
Première étape : vérifier dans le document de cadrage ce qui a été convenu en termes de format : rapport complet texte, diaporama, ou plan d’action au format tableur ?
Vous pouvez même expliquer dans l’introduction que le choix de formalisation a été porté sur tel ou tel format et en préciser les raisons. Un lecteur averti comprendra que le rapport a été coconstruit pour répondre au besoin spécifique du commanditaire, et qu’il ne reflète pas forcément la forme et le contenu d’autres rapports que vous pourriez rédiger.
Votre rapport pourra rapidement contenir beaucoup de pages, notamment à cause des captures ou de l’exhaustivité des tests et des explications. Il est donc important qu’il soit agréable à lire !
En parlant de fautes d’orthographe, j’ai une anecdote à vous raconter :
Dans les premiers mois de ma carrière de consultant, j’ai eu à plusieurs reprises des chefs de projet qui étaient particulièrement regardants sur la forme et le style de rédaction (ces éléments font partie de la qualité globale de la prestation, et sont traités avec la même importance que le fond par la plupart des cabinets de conseil). L’un de ces chefs de projet m’avait même dit “Attention, je suis intransigeant sur la forme et si je vois plus de 3 fautes dans le rapport, je ne lis pas plus loin”. Vous imaginez bien qu’il l’a mis à exécution et que j’ai dû relire plusieurs fois mon rapport avant que lui ne fasse une relecture complète !
Généralement, je relis un livrable au moins 3 fois et le fais relire par quelqu’un d’autre de l’équipe !
Bon ! Passons maintenant au contenu, car si la forme est ce qui fait que votre client trouvera votre rapport agréable à lire, c’est bien le fond qui l'intéresse !
Écrivez un rapport détaillé
En début de chapitre, je vous ai présenté les différentes parties attendues dans un rapport de test d'intrusion :
Intitulé de la section | Objectifs visés et notions abordées | Destinataires principaux |
Synthèse managériale | Donner une vision macro des risques et du niveau de sécurité de l’objet audité | Dirigeants, métiers |
Résultat des tests (vulnérabilités et recommandations) | Lister les vulnérabilités et recommandations associées de manière actionnable pour les équipes du commanditaire | Populations techniques et métiers |
Déroulé des tests | Comprendre en détail le cheminement de l’auditeur | Auditeurs et populations techniques |
Nous allons maintenant détailler ces parties une par une.
Partie n°1 : la synthèse managériale
L’objectif de cette partie est que toute personne ayant accès au rapport comprenne en quelques minutes quelles sont les principales :
Vulnérabilités qui impactent l’application auditée.
Actions pour y remédier et ce, quel que soit son cœur de métier.
Il n’y a pas de structure fixe sur comment rédiger cette partie. Personnellement j’ai appris à commencer par énoncer les points positifs, puis les axes d’amélioration.
Dans les points à corriger, l’idée est de rester très haut niveau et de lier dans la mesure du possible des vulnérabilités identifiées à une problématique ou un risque pour le métier. On pourra parler d’injections SQL ou d'exécution de commande, mais en mettant l’accent sur ce que permettent de faire ces vulnérabilités plutôt que sur la vulnérabilité en elle-même. On ne citera que les points les plus importants, pas les détails qui ne permettent pas d'atteindre réellement l’application.
À la fin de la lecture de la synthèse managériale, le commanditaire, quel qu’il soit, doit avoir compris ce que nous avons réussi à faire sur l’application. Il doit avoir les clés pour décider par exemple si l’application peut passer en production en l’état, ou si des mesures correctives doivent être implémentées avant.
Partie n°2 : le résultat des tests d’intrusion
Elle contient deux sous-parties :
1. Les vulnérabilités, avec :
le nom ou l’intitulé que vous aurez donné à la vulnérabilité ;
le détail de la vulnérabilité, suffisamment exhaustif pour localiser rapidement la vulnérabilité sur l’application ;
la criticité de la vulnérabilité, par exemple selon son score CVSS ou selon l'échelle définie dans le référentiel PASSI.
2. Les recommandations, avec :
le nom ou l’intitulé que vous aurez donné à la recommandation ;
le détail de la recommandation, ce qui est attendu des équipes et un exemple ou un lien vers un article ou des ressources aidant à implémenter la recommandation dans le cas des recommandations techniques ;
l’importance de la recommandation dans le plan d’action global ;
le coût relatif ou la complexité relative que vous estimez pour la mise en œuvre de la correction ;
la référence de la (ou des) vulnérabilité(s) qu’elle corrige ou mitige.
Partie n°3 : le déroulé des tests d’intrusion
Cette partie est généralement la plus conséquente du rapport. Elle détaille et explicite tous les tests qui ont été effectués sur la cible, qu’ils aient mené à la découverte d’une vulnérabilité, ou au contraire amené la preuve de l'absence de vulnérabilité.
Il y a débat entre les pentesters sur le contenu du détail des tests, débat que j’ai moi-même eu avec d’autres collègues ou concurrents, et que j’ai revu passer peu de temps après sur Twitter :
Traduction de cet échange en français :
@CristiVlad25 : Pentesters, qu’écrivez-vous dans votre rapport d’audit lorsque vous n’avez rien trouvé ?
@_nwodtuhs : C’est rarement admis mais un rapport d’audit devrait toujours inclure tout ce qui a été testé ; pas seulement les vulnérabilités qui ont été trouvées mais aussi ce qui s’est révélé conforme. De cette façon, le client sait ce qui a été évalué, et quel qu'en soit le résultat, cela atteste de la qualité du test d’intrusion”.
Quel que soit le niveau de détail retenu, l’approche peut être :
linéaire et chronologique comme le suggère l’ANSSI ;
ou compartimentée en grandes sections selon les typologies de vulnérabilités (comme nous l’avons vu dans ce cours). Le web s’y prête assez bien à la différence d’autres types de tests d’intrusion.
Dans cette partie du rapport, vous mettez :
Toutes les preuves de travail (les vulnérabilités, les payloads – voire les outils ! – utilisés ).
Mais également les preuves de protection ou l'absence de vulnérabilités.
Si un pentester repasse sur l’application quelques mois voire quelques années après vous, il doit être en mesure de comprendre exactement ce que vous avez fait et ce que vous avez trouvé à partir de votre rapport. À aucun moment, il ne doit pouvoir se dire “Mais qu’est-ce qu’il a fait ici ?” ou encore “Mais comment est-il arrivé à ce résultat ?”.
Pour chaque test, je structure mon approche comme ceci :
une explication de ce que je cherche, pourquoi je le cherche et comment ça fonctionne ;
le test de la vulnérabilité en question ;
l'interprétation du résultat des tests, positif ou négatif.
En résumé
Avant de rédiger le rapport, vérifiez avec votre commanditaire que le format prévu est en adéquation avec son besoin.
Par défaut, je vous conseille une approche complète du livrable avec une synthèse managériale, le résultat des vulnérabilités trouvées et des recommandations, puis le déroulé détaillé des tests réalisés. C’est l’approche préconisée également par l’ANSSI dans PASSI.
Prenez soin de la forme du rapport et relisez-vous, plusieurs fois s’il le faut !
Chaque partie du rapport s’adresse à une audience particulière :
la synthèse managériale s’adresse aux fonctions exécutives comme les dirigeants, chefs de services, et aux populations “métier” sans connaissances IT particulières, et encore moins sécurité ;
la liste des vulnérabilités et des recommandations s’adresse aux populations techniques, qui vont devoir implémenter les recommandations et comprendre pourquoi la vulnérabilité existe ;
le détail des tests s’adresse également à la population technique si elle souhaite comprendre tout le cheminement du pentester, mais également aux futurs testeurs ou autres auditeurs qui auraient besoin des résultats de l’audit pour une autre mission.
Dans le chapitre suivant, nous allons voir en détail comment aborder et formuler les recommandations pour qu’elles soient le plus actionnables possible par les équipes du commanditaire.
