🚀 Pour des rapports actionnables

Dans un précédent billet, nous vous avions parlé de l’importance d’exprimer, entre autres, un besoin de “lisibilité” du rapport de pentesting. Ces deux items ont particulièrement été suggérés dans une “checklist” type pouvant vous assister dans la rédaction de votre cahier des charges :

✅ Quels sont les lecteurs potentiels du rapport final de tests ?
✅ Est-ce que le rapport de pentesting devrait être « business readable », à savoir compréhensible par des interlocuteurs non techniques ?

🤔 Soit … mais que veut-on dire par là ?

A ce propos, avez-VOUS déjà été destinataire d’un rapport de pentesting ? VOUS, lecteurs de ce billet, qui êtes d’ailleurs des professionnels de la cybersécurité ou de l’informatique peut être, mais pas forcément.

Avez-vous lu une “fiche de vulnérabilité” ?

Avez-vous parcouru ces listes à la Prévert de vulnérabilités affectant des adresses IP et des technologies, clignotant en rouge ou en orange avec des “impacts” et des “compétences requises pour exploiter la vulnérabilité” ? 

Avez-vous compté le nombre de pages, souvent en dizaines, qui énumèrent des “ports” ouverts, TCP ou UDP, et qui peuvent très facilement migrer en Annexe de ces (trop) longs rapports ? 😵

Comme on l’a dit dans un précédent billet, le rapport de pentesting est censé se déverser dans la phase “Check” d’un Système de Management de la Sécurité de l’Information (SMSI), il doit donc pouvoir éclairer le lecteur sur l’efficacité réelle des mesures de sécurité mises en place. Ce rapport doit justement permettre de voir si les chemins d’attaque, imaginés peut être en ateliers Hacker Stories©: 

• existent bel et bien 
• sont susceptibles de conduire aux biens à valeur que l’organisation doit protéger 
• peuvent être empruntés par tel profil d’attaquant ou de menace, selon ses moyens et ses capacités…

👩‍🎨Il faudrait donc que ce rapport soit également lisible par des non techniciens 

Du moins certaines sections devraient l’être, bien au-delà de ce “sommaire exécutif” qui ne remplace pas un contenu mais le synthétise… Autrement dit, le sommaire exécutif d’un rapport technico-technique restera forcément technico-technique… 🤓

Il s’agit de quantifier les impacts potentiellement induits par les vulnérabilités et les chemins d’attaque identifiés, dans un langage qui sert l’appréciation et la gestion des risques, c’est à dire dans un langage compréhensible des parties prenantes “métier”, d’où le terme de “Business Readable”. L’impact à identifier est in fine “métier”, bien au-delà de ses sous-jacents techniques. C’est ainsi que le “Check” gagne toute son efficacité, c’est là que les priorités se dessinent et sont plus susceptibles d’être avalisées par les métiers et/ou la Direction Générale. 

Pour ce faire, une checklist vaut mieux qu’un long discours, pour espérer aboutir à des rapports de pentesting qui soient “Business Readable” :

✅ En tant que pentester, ai-je développé une empathie métier vis-à-vis de mon client ?
✅ Me suis-je suffisamment intéressé à son activité, son écosystème ?
✅ Ai-je pris connaissance de ses analyses de risque ?
✅ Ai-je eu l’opportunité de participer aux ateliers et/ou aux résultats d’ateliers HackerStories© ?
✅ Ai-je impliqué un représentant métier côté client dans l’élaboration de certaines sections du rapport ?
✅ Me suis-je mis tour à tour dans le rôle de différentes fonctions dans l’entreprise : le donneur d’ordre, les personnels IT, les équipes sécurité, l’audit interne, les responsables (“métiers”) des traitements pouvant être impactés par les vulnérabilités remontées ?
✅ Ai-je conçu le rapport de pentesting selon une architecture de l’information qui permettrait justement de proposer plusieurs grilles et prismes de lecture, adaptés aux différents acteurs qui jalonnent cette chaîne d’approvisionnement du pentesting ?
✅ Suis-je en mesure de quantifier la contribution métier précise d’une adresse IP ?
✅ Ai-je fait évoluer mes fiches de vulnérabilité et mes rapports de pentesting afin d’y refléter toute la panoplie d’impacts métier pouvant être induits et les types d’attaquants qui pourraient convoiter ces biens valeur, nom qu’on donne dans EBIOS Risk Manager pour désigner ce qu’une organisation souhaite protéger ?

🤷‍♂️Le pentester n’est pas un expert du métier, et n’a pas vocation à l’être, alors comment faire ?

Chez Knock Knock nous pensons que la clé est une collaboration transverse, pluridisciplinaire.

Le métier doit être représenté par l’interlocuteur client lors du cadrage du pentest, pour définir les périmètres concernés, les processus critiques (ex : une plateforme de e-commerce), les données sensibles (ex : données personnelles, données financières, propriété intellectuelle…). 

“En utilisant ce chemin d’attaque, le hacker peut rendre les paiements inopérables”

Ensuite, la constitution du rapport doit se faire de manière collaborative : le pentester est à même d’évaluer la criticité technique, mais c’est au client de se prononcer sur la criticité métier. Nous considérons nécessaire une boucle d’échange intermédiaire entre le début de la rédaction et la livraison finale :

1. Rédaction du rapport technique : la partie classique, on recense les vulnérabilités, leurs impacts techniques, leur complexité d’exploitation (la vraisemblance du diagramme de Farmer, pour les intimes)… classique ! A ce stade on peut commencer à connecter les vulnérabilités aux processus et aux données identifiées en cadrage.
2. Attribution de la valeur métier : un atelier (~1h) avec le client pour terminer d’associer les vulnérabilités aux process & données métier, recenser ceux qui n’avaient éventuellement pas été identifiés en phase de cadrage, et affecter une priorité métier (la gravité)
3. Élaboration des recommandations : un atelier (~1h) impliquant des représentants de l’IT et des métiers pour identifier le plan d’action métier, fonctionnel et technique.
4. Finalisation du rapport : on met à jour le diagramme de Farmer ainsi que la roadmap de sécurisation
   

Il faudra être vigilant à ce que le rapport de pentesting soit pensé, élaboré, consommé dans une logique de chaîne d’approvisionnement du pentest :

Si vous aussi vous trouvez que les rapports de pentesting se ressemblent tous
et surtout qu’ils ne constituent pas des leviers efficaces d’aide à la priorisation,
à la décision et à la réduction des risques :

contactez-nous !