Contenu d'un rapport de test d'intrusion : guide de l'acheteur

Définition

Un rapport de test d'intrusion est un compte rendu écrit de ce qui a été testé, comment, dans quelles conditions, et de ce qui a été trouvé. Il doit être lisible par deux publics. Les parties prenantes non techniques ont besoin d'une courte synthèse du risque global, des problèmes les plus importants et des priorités recommandées. Les équipes techniques ont besoin, pour chaque constatation, de suffisamment de détails pour la comprendre, la reproduire dans un environnement sûr et la corriger. Un bon rapport consigne aussi ses propres limites : ce qui était hors périmètre, ce qui n'a pas pu être testé et les conditions qui ont affecté la couverture, comme des comptes de test indisponibles ou une fenêtre raccourcie. Sans ces limites, les lecteurs risquent de supposer que le rapport couvre davantage qu'en réalité.

Public concerné

Ce guide est utile pour :

• Les acheteurs qui comparent des propositions et veulent savoir quel livrable ils recevront réellement
• Les responsables techniques qui recevront les constatations et devront planifier la remédiation
• Les managers qui doivent partager une synthèse avec un client, un partenaire, un auditeur ou un conseil d'administration sans exagérer le résultat
• Les équipes qui ont reçu un précédent rapport et l'ont trouvé difficile à exploiter

Ce qu'il aide à clarifier

Connaître la structure attendue vous permet de vérifier :

• Si le périmètre et les règles d'engagement figurant dans le rapport correspondent à ce qui a été convenu
• Si chaque constatation comporte des preuves, un niveau de gravité clair et des recommandations de remédiation concrètes
• Quels problèmes exigent une action immédiate et lesquels peuvent être planifiés dans les cycles de développement habituels
• Quelles informations peuvent être partagées à l'extérieur sans risque et lesquelles doivent rester réservées au personnel technique

Ce qui est inclus

• Synthèse pour la direction : vue d'ensemble, constatations les plus importantes et priorités recommandées, en langage clair
• Périmètre et règles d'engagement : cibles, environnements, rôles utilisateurs, dates, fenêtre de test et exclusions
• Résumé de la méthodologie : l'approche et les référentiels utilisés, comme les recommandations OWASP pour les applications web
• Registre des constatations : chaque problème avec un titre, une gravité, l'actif concerné, une description, une référence de preuve et l'impact métier
• Détails techniques : les étapes permettant à votre équipe de comprendre et de reproduire le problème en toute sécurité
• Recommandations de remédiation : corrections concrètes et, si utile, mesures d'atténuation à court terme
• Limites : ce qui n'a pas pu être testé et pourquoi
• Section contre-test : l'état des constatations convenues après correction par votre équipe, lorsqu'un contre-test est inclus

Ce qui n'est pas inclus

• Une déclaration selon laquelle le système est sécurisé ou ne présente plus aucune vulnérabilité après les tests
• Des constatations hors du périmètre convenu présentées comme si elles avaient été testées
• Une certification, une approbation de conformité ou une opinion d'audit formelle
• La mise en œuvre des corrections, sauf accord distinct

Quand le choisir

Lisez ce guide avant de signer une proposition de test, afin de pouvoir demander un exemple de rapport et en confirmer la structure. Il est également utile à la réception d'un rapport : utilisez les sections ci-dessus comme liste de contrôle pour voir s'il manque quelque chose. Si une partie prenante vous a demandé d'« envoyer le rapport de pentest », déterminez à l'avance si elle a besoin du document technique complet ou d'une synthèse pour la direction accompagnée d'une lettre sur l'état de la remédiation. Diffuser largement l'intégralité des détails techniques accroît le risque, car ils décrivent les faiblesses de vos systèmes.

Notre approche

Demandez des précisions sur l'échelle de gravité avant le début des tests. De nombreux prestataires utilisent une échelle fondée sur la probabilité et l'impact, parfois en se référant au CVSS ; l'essentiel est qu'elle soit cohérente et expliquée. Convenez de la manière dont les preuves seront conservées et partagées, et de l'identité de vos contacts désignés. À la réception du rapport, organisez une réunion de restitution pour que les développeurs puissent poser leurs questions tant que le contexte est encore frais. Transformez le registre des constatations en tickets avec des responsables et des dates cibles, et corrigez d'abord les problèmes les plus graves. Demandez ensuite un contre-test des constatations convenues afin que le rapport consigne ce qui a été résolu. Notre service Penetration Testing fournit une synthèse pour la direction, un résumé du périmètre et des règles d'engagement, un registre des constatations classées par gravité avec références de preuve, des détails techniques pour chaque constatation, une feuille de route de remédiation priorisée et le résultat du contre-test lorsqu'un contre-test est inclus. Quel que soit le prestataire choisi, conservez chaque version du rapport, consignez les constatations acceptées comme risques plutôt que corrigées, et notez qui a pris cette décision. Ce registre est souvent aussi précieux que le test lui-même la prochaine fois que quelqu'un vous interroge sur votre niveau de sécurité.

Penetration Testing

Foire aux questions

Articles connexes