Rédiger un rapport de Pentesting

Le pentesting et l’écriture d’un rapport est un art qu’il faut maîtriser à la perfection. On doit expliquer clairement à chacun depuis l’équipe IT, chargée de corriger les vulnérabilités jusqu'aux dirigeants de l’entreprise en cause, ce que l’on a découvert en ne mentionnant pas d’acronyme compréhensibles que par certains, mais en détaillant les données privées que l’on a pu accéder ou modifier. Par exemple, il a été possible de lire vos courriels résonne beaucoup plus aux oreilles de chacun que n’importe quelle autre explication technique.

Le rapport global est un document (le plus souvent au format PDF non modifiable), rédigé en anglais ou en français et mentionnant en filigrane le statut ‘Confidentiel’ puisque le rapport contient des informations susceptibles de s’introduire dans le système informatique de l’entreprise visée. De plus, un rapport cohérent doit inclure à la fois un sommaire exécutif explicite, appelé rapport d’exécution,  mais aussi un rapport technique détaillé. Le rapport d’exécution doit contenir les rubriques suivantes :

• Background : description du but des tests et les définitions de tout terme non explicite à un exploitant. Par exemple, définir les termes suivants : vulnérabilité et contre-mesure.
• Posture globale : vue d’ensemble de l’efficacité des tests, les solutions trouvées (par exemple, l’exploitation de la vulnérabilité Microsoft MS08-056) et les cas généraux permettant l’exploitation de vulnérabilités (cas du manque de mise à jour ou de patch).
• Profil du risque : classification générale de la posture sécuritaire de l’organisation en la comparant à des sites similaires en les mesurant avec des indicateurs explicites du type ‘high’, ‘medium’, ‘low’. On peut introduire une description de la classification en question.

REMARQUE : il peut être intéressant de résumer le nombre de failles trouvées dans un format tabulaire de synthèse, de trier par sévérité, priorité et difficulté de correction. Par exemple, on pourrait classer les lignes du document de la façon suivante :

• Découvertes générales : un descriptif général de ce que l’on a découvert avec des statistiques et des métriques sur l’efficacité des contre-mesures déployées.
• Recommandations sommaires : vue de haut niveau des tâches requises pour corriger les problèmes découverts durant ces tests.
• Plan stratégique : fournit au client les objectifs court et long termes pour renforcer leur sécurité.

De même, le rapport technique, doit quant à lui contenir au minimum, les chapitres suivants :

• Introduction : avec l’inventaire des détails tels que  le périmètre du pentest, le(s) contact(s)…
• Récolte d’information : détails des informations récupérées durant la phase information-gathering. Il peut être intéressant ici, de mentionner l’empreinte Internet du client.
• Évaluation de vulnérabilités : détails des découvertes durant la phase vulnerability-analysis du test.
• Vérification vulnérabilité/exploitation : détails  des découvertes durant la phase d’exploitation du test.
• Post exploitation : détails des découvertes de la phase post-exploitation du test.
• Risques & dangers : une description détaillée des risques encourus. Cette section doit mettre en lumière les pertes possibles en cas d’attaque avérée par une personne malveillante.
• Conclusion : description globale des résultats du test.

Le rapport doit s’appuyer  sur un audit de sécurité pouvant s’effectuer en plusieurs phases, dont le test d’intrusion. Parmi les autres phases, on trouve généralement :

• la correspondance orale des membres du système d’information (noté SI), de la direction (noté DSI) et du responsable Sécurité (noté RSSI) ainsi que des membres de l’équipe technique.
• l’audit de configuration des services (ainsi que des serveurs, des composants réseau…)
• l’audit de code pour les applications utilisées, déployées ou développées en interne par la firme.

Afin de réaliser ces différentes étapes, on doit s’appuyer sur des référentiels prévus pour ce genre d’activité (audit sécurité) :

• ISO 27000 et ISO 27001
• Référentiel général de sécurité de l’ANSSI
• Le référentiel COBIT
• Normes type SOX
• Normes PCI-DSS

En termes de représentation, on peut facilement résumer le cycle des différentes phases de pentesting d’un client (hors tests externes), décrites précédemment par le schéma ci-dessous :

Pour plus d’information concernant les techniques de pentesting, on peut visiter l’excellent site Penetration Testing Execution Standard (abrégé en PTES) à l’adresse www.pentest-standard.org.

IMPORTANT : s’il y a bien une chose à retenir c’est que le test d’intrusion est une partie seulement de l’audit de sécurité qui est plus complet. Et, il est possible de formaliser le PTES de la façon suivante :