Que devrait démontrer le rapport ?
Votre rapport de test d’intrusion doit expliquer le contrôle défaillant et les conséquences démontrées, et non se contenter d’attribuer un niveau de gravité. Recherchez les paires de tenants, les états des transactions et les autorisations des charges de travail, les observations reproductibles et les responsables concernés. Les lacunes de couverture et les conséquences non vérifiées doivent rester visibles afin que le rapport étaye une décision éclairée.
Une vue d’ensemble destinée à la direction, avec des conclusions délimitées
Identifier à quel moment un appel API légitime devient une opération non autorisée, comment les identifiants des charges de travail peuvent franchir les frontières entre services et ce qu’une correction réaliste doit préserver.
Résumez les fonctions testées, les risques pertinents, les contrôles qui ont résisté et les décisions nécessitant l’attribution d’une responsabilité. Expliquez les hypothèses et l’assistance apportée au lieu d’avancer l’affirmation de compromission la plus large possible.
Un enregistrement technique vérifiable
- Périmètre, versions, dates, rôles et conditions de test autorisées.
- Architecture et chemins de confiance examinés, avec des limites clairement définies.
- Horodatages UTC, requêtes, réponses et extraits de preuves expurgés.
- Constats avec conditions de reproduction, actifs concernés et limites.
- Lacunes de couverture, chemins refusés et actions délibérément non réalisées.
Un plan de traitement pour chaque constat
Distinguez le confinement immédiat de la correction durable. Désignez le responsable du système ou du processus et indiquez les dépendances vis-à-vis des fournisseurs, des mises en production ou des approbations opérationnelles. Définissez ce qui doit être observé avant de clôturer un élément.
Un relevé de validation
Un nouveau test réussi précise la version modifiée, le principal testé et le résultat réel. Un nouveau test proposé est indiqué comme étant en attente. La répétition des tests de détection et les exercices de restauration sont consignés séparément de la clôture des vulnérabilités, car chacun répond à une question différente.
Examiner le format avant l’achat
L’évaluation fictive de Fintech AG compte 68 pages avec des schémas, trois scénarios, douze constats, des éléments de preuve techniques et une correspondance avec les contrôles. Elle illustre le format du rapport et ne rend pas compte de travaux réalisés pour un client réel.
