Comment lire un rapport de test d’intrusion

Le rapport est la partie d’un test d’intrusion qui vous reste une fois les testeurs partis. Bien le lire, c’est corriger d’abord ce qui compte et tirer un vrai bénéfice du contre-audit. Cela vous aide aussi à repérer un « test d’intrusion » qui n’était en réalité qu’un scan automatisé doté d’une page de garde.

Ce que contient un bon rapport

L’OWASP Web Security Testing Guide décrit une structure de rapport qui constitue une bonne référence. Chaque partie s’adresse à un lecteur différent, et le guide suggère que les sections puissent être imprimées séparément pour les équipes qui en ont besoin.

Lisez attentivement la section sur les limites. Si des verrouillages de comptes ont interrompu les tests, ou si un serveur a été retiré du périmètre le deuxième jour, le rapport doit le mentionner. Un résultat sans anomalie sur une zone qui n’a jamais été testée ne vous apprend rien.

Le National Cyber Security Centre (NCSC) britannique ajoute deux éléments faciles à oublier. Un bon rapport donne l’avis des testeurs sur la justesse de votre propre évaluation des vulnérabilités, ainsi que des conseils pour améliorer ce processus.

Anatomie d’une bonne fiche de vulnérabilité

Chaque vulnérabilité doit permettre à un ingénieur qui n’a pas participé au projet de comprendre le problème, de le reproduire et de le corriger. Vérifiez la présence de :

• un identifiant unique et un titre clair
• un niveau de sévérité, avec le vecteur CVSS lorsque CVSS est utilisé
• les actifs exacts concernés, comme des hôtes, des URL, des paramètres ou des rôles
• une description de la faiblesse et de son importance pour votre activité
• des preuves, comme des requêtes et des réponses, des captures d’écran ou des sorties de commandes
• les étapes de reproduction
• des recommandations de correction précises, avec des références comme un avis de sécurité de l’éditeur

Voici un exemple condensé de ce que cela donne en pratique :

ID        AF-07  Invoice download does not check ownership
Severity  Medium  CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N (6.5)
Affected  GET /api/v1/invoices/{id}/pdf on portal.example.eu
Evidence  Logged in as customer A, a request for invoice 10452
          (customer B) returned customer B's PDF.
Impact    Any customer can download other customers' invoices,
          including names, addresses and amounts.
Fix       Check on the server that the invoice belongs to the
          logged-in customer for every request.
Retest    Request another customer's invoice and expect 403 or 404.

Dans cet exemple, connecté en tant que client A, le testeur a obtenu la facture PDF du client B : n’importe quel client peut donc télécharger les factures des autres. Le vecteur permet de voir pourquoi le score est moyen : la confidentialité est touchée, l’intégrité et la disponibilité ne le sont pas. Il vous permet aussi d’être en désaccord à bon escient. Comme les factures contiennent des données personnelles, vous pouvez décider que ce problème mérite une priorité plus élevée que ne le suggère le score.

Comment les vulnérabilités sont notées

De nombreux rapports notent les vulnérabilités avec le Common Vulnerability Scoring System (CVSS) maintenu par le FIRST, et le NCSC le cite parmi les systèmes de notation que vous pouvez demander. CVSS v3.1 et v4.0 utilisent les mêmes niveaux qualitatifs :

Trois points aident à lire ces notes :

• Un score de base mesure la gravité, pas votre risque. Le FIRST explique qu’il reflète les caractéristiques intrinsèques de la vulnérabilité dans un pire cas raisonnable, et que ses utilisateurs doivent le compléter par des informations sur leur propre environnement.
• La sévérité est une donnée d’entrée. Le guide OWASP recommande que la synthèse pour la direction le dise explicitement : la note alimente votre processus de gestion des risques, elle ne le remplace pas.
• Les testeurs ne connaissent pas le contexte métier. Le NCSC vous conseille d’évaluer vous-même les vulnérabilités, car les notes peuvent être trop hautes ou trop basses. Il met aussi en garde contre la tentation d’en profiter pour minimiser les problèmes.

Quoi corriger en premier

1. Tout ce qui est exploitable depuis Internet sans authentification, surtout lorsque cela mène à l’exécution de code, à l’accès aux données ou au contrôle administrateur.
2. Les chaînes d’attaque. Un bon rapport montre comment plusieurs vulnérabilités moins bien notées se combinent pour en former une grave. Le NIST SP 800-115 relève que les scanners ne peuvent pas détecter les faiblesses qui n’apparaissent que lorsque des vulnérabilités sont combinées. Trouver ces chaînes est l’essentiel de la valeur ajoutée d’un testeur humain.
3. Les systèmes qui détiennent les clés, comme les fournisseurs d’identité, les serveurs de sauvegarde, les passerelles d’accès à distance et tout ce qui traite des données personnelles.
4. Les gains rapides. Un seul changement de configuration permet parfois de corriger plusieurs vulnérabilités à la fois.
5. Les causes profondes. Le NIST recommande une analyse des causes profondes après une évaluation, car les résultats peuvent révéler des processus défaillants autant que des systèmes vulnérables. Cinq correctifs manquants sur cinq serveurs constituent un seul constat sur la gestion des correctifs, et non cinq problèmes sans lien.

Le NCSC présente le test d’intrusion comme un contrôle de votre propre gestion des vulnérabilités, et non comme le principal moyen de les découvrir. Selon lui, les nouvelles découvertes « devraient être l’exception, pas la règle ». Si le rapport vous surprend, cela vous apprend aussi quelque chose sur vos processus internes.

Le contre-audit

Convenez du contre-audit dès la signature du contrat, y compris de ce qu’il couvre et du délai dont vous disposez pour corriger. Demandez les résultats sous la forme d’un rapport mis à jour ou d’une annexe, avec un statut pour chaque vulnérabilité : corrigée, partiellement corrigée, non corrigée ou risque accepté.

Un contre-audit confirme des corrections précises. Ce n’est pas un nouveau test. Le NCSC rappelle qu’un test ne montre l’état de vos systèmes que le jour où il a été réalisé, et qu’il est courant de laisser un an ou plus entre deux tests. Continuez à vérifier dans l’intervalle.

Les signaux d’alerte d’un « test d’intrusion » au rabais

Le scan automatisé a sa place, et le NIST SP 800-115 le traite comme l’une des techniques d’évaluation standard. Il note aussi que les scanners peuvent produire un taux élevé de faux positifs et qu’il faut une personne compétente pour interpréter leurs résultats. Le problème commence lorsque des résultats de scan non vérifiés sont vendus comme un test d’intrusion. Parmi les signaux d’alerte :

• des vulnérabilités décrites par un texte générique, copié-collé, sans preuve que quelqu’un les a confirmées
• des dizaines de points de faible impact sur les bannières et les suites de chiffrement TLS, mais rien sur le contrôle d’accès, l’authentification ou la logique métier, qui exigent un testeur humain
• des niveaux de sévérité repris tels quels de l’outil ; le NIST indique que les évaluateurs doivent fixer eux-mêmes le niveau de risque au lieu d’accepter les notes du scanner
• pas de section sur le périmètre, la méthodologie ou les limites
• pas d’étapes de reproduction, si bien que votre équipe ne peut pas vérifier une correction
• aucun testeur nommé ni aucune qualification indiquée ; le NCSC précise que les tests ne doivent être réalisés que par du personnel qualifié et expérimenté
• un « contre-audit » qui se résume à relancer le même scan

Par où commencer

Avant votre prochain test, posez ces questions au prestataire :

• Qu’est-ce qui est exactement inclus dans le périmètre, et qu’est-ce qui en est exclu ?
• Les testeurs disposeront-ils d’un compte pour chaque rôle utilisateur à couvrir ?
• Pouvez-vous consulter un exemple de rapport anonymisé ?
• Comment les vulnérabilités sont-elles notées, et chacune comportera-t-elle un vecteur CVSS ?
• Un contre-audit est-il inclus, et dans quel délai ?

Si vous préparez un test et souhaitez d’abord discuter du périmètre, découvrez notre service de tests d’intrusion.