Aller au contenu

Comment lire un rapport de test d'intrusion sans être technicien

Rapport de test d'intrusion : comment lire le sommaire, interpréter la gravité CVSS, repérer les chaînes d'attaque et transformer les constats en plan d'action.

Par l’équipe Cyber Caribou6 min de lecture

Le président d'une entreprise de transport de Trois-Rivières reçoit un PDF de 64 pages. Deux vulnérabilités critiques, cinq élevées, quatorze moyennes, une vingtaine de faibles, et des annexes pleines de captures d'écran en noir et blanc. Son fournisseur TI lui répond : « On va regarder ça. » Trois mois plus tard, rien n'a bougé.

Ce scénario est plus fréquent qu'on le pense. Le test d'intrusion a coûté plusieurs milliers de dollars, mais le rapport dort dans une boîte courriel parce que personne ne sait par où commencer.

Un rapport de test d'intrusion n'est pourtant pas réservé aux techniciens. Avec quelques repères, une dirigeante de PME peut le lire en une heure, poser les bonnes questions et piloter les corrections. Voici comment.

En bref

  • Lisez d'abord le sommaire exécutif et la portée : ils disent ce qui a été testé, et surtout ce qui ne l'a pas été.
  • La gravité CVSS est un point de départ, pas une vérité absolue; le contexte de votre entreprise compte.
  • Les chaînes d'attaque sont la partie la plus importante : briser un seul maillon peut neutraliser tout le scénario.
  • Un rapport n'est utile que s'il devient un plan d'action avec un responsable et une échéance pour chaque constat.

Les sections d'un bon rapport

La plupart des rapports suivent une structure semblable, qui reprend la dernière phase des méthodologies reconnues comme le NIST SP 800-115. Voici ce que chaque partie vous apprend.

SectionÀ quoi elle sertCe que vous devez y chercher
Sommaire exécutifRésumer le niveau de risque en langage d'affairesUne phrase claire sur ce qu'un attaquant pourrait faire
Portée et méthodologieDéfinir ce qui a été testé, quand et commentLes exclusions et les limites du test
Chaînes d'attaqueRaconter le chemin suivi par le testeurLe point d'entrée et l'objectif atteint
Constats détaillésDécrire chaque vulnérabilitéGravité, systèmes touchés, preuve, correction
RecommandationsPrioriser les correctifsDes actions précises, pas des généralités
AnnexesFournir les détails techniquesUtiles surtout à votre équipe TI

La section portée mérite une attention particulière. Si le test interne a exclu le serveur de paie, ou si l'application Web a été testée sans compte connecté, le rapport ne dit rien sur ces risques. Un « rapport propre » sur une portée étroite n'est pas une garantie.

Inutile de tout lire vous-même : répartissez le travail. À la direction, le sommaire, la portée, les chaînes d'attaque et les recommandations, car c'est là que se prennent les décisions d'affaires. À votre responsable TI ou à votre fournisseur de services gérés, les constats détaillés et les annexes, avec une estimation de l'effort pour chaque correction. Puis assoyez-vous ensemble pour prioriser, afin que personne ne décide seul qu'un constat critique peut attendre au prochain trimestre.

Comprendre la gravité : CVSS, oui, mais avec le contexte

La plupart des fournisseurs notent chaque vulnérabilité avec le CVSS (Common Vulnerability Scoring System), une norme publiée par l'organisation FIRST. Sa version 4.0 date de novembre 2023. L'échelle qualitative est la suivante :

  • Aucune : 0,0
  • Faible : 0,1 à 3,9
  • Moyenne : 4,0 à 6,9
  • Élevée : 7,0 à 8,9
  • Critique : 9,0 à 10,0

Le score de base mesure la gravité technique d'une vulnérabilité, sans connaître votre entreprise. La version 4.0 rend d'ailleurs la chose visible dans l'étiquette du score : « CVSS-B » désigne le score de base seul, tandis que « CVSS-BT », « CVSS-BE » ou « CVSS-BTE » indiquent qu'on a tenu compte de la menace réelle (T), de votre environnement (E), ou des deux. Si votre rapport n'affiche que des scores de base, demandez pourquoi.

Un bon testeur ajuste ou commente la gravité selon votre réalité. Une faille « critique » sur un serveur de test isolé, sans données réelles, peut attendre. À l'inverse, une faille « moyenne » sur le portail que tous vos clients utilisent pour se connecter peut mériter une correction immédiate.

Un autre indice utile : la vulnérabilité figure-t-elle au catalogue des vulnérabilités activement exploitées (KEV) tenu par l'agence américaine CISA ? Si oui, des attaquants s'en servent déjà ailleurs. Elle remonte en haut de la pile.

Les chaînes d'attaque : la page la plus importante

Les constats isolés donnent une liste. La chaîne d'attaque raconte une histoire. Par exemple :

  1. Le testeur intercepte un identifiant sur le réseau grâce à un protocole hérité mal configuré.
  2. Ce compte a un mot de passe faible, cassé en quelques minutes.
  3. Le compte a accès à un partage réseau qui contient un fichier de mots de passe.
  4. L'un d'eux est celui d'un compte administrateur du domaine.

Chaque étape, prise seule, serait cotée « moyenne ». Ensemble, elles mènent au contrôle total du réseau en un après-midi. La bonne nouvelle : il suffit souvent de briser un seul maillon pour neutraliser tout le scénario. Demandez au testeur lequel est le plus facile et le plus rapide à corriger.

Si votre test portait sur une application, les chaînes ressemblent plutôt à celles décrites dans notre article sur le test d'intrusion d'application Web et l'OWASP Top 10.

Du rapport au plan d'action

Le rapport dit quoi corriger. À vous de décider qui, quand et comment. Transformez chaque constat en ligne d'un tableau de suivi avec un responsable, une échéance et un statut.

Voici un exemple de politique interne, à adapter à votre réalité :

Gravité ajustéeDélai cible (exemple)Qui décide
CritiqueQuelques joursDirection et TI, en urgence
ÉlevéeQuelques semainesResponsable TI
MoyenneProchain cycle de maintenanceResponsable TI
FaiblePlanifiée ou acceptéeResponsable TI, avec trace écrite

Ces délais rejoignent ceux de votre politique de gestion des correctifs, si vous en avez une. Si vous décidez de ne pas corriger un constat (coût trop élevé, système remplacé dans six mois), documentez-le comme une acceptation de risque signée par la direction. C'est une décision d'affaires légitime, à condition qu'elle soit consciente.

Distinguez aussi les gains rapides des projets. Désactiver un protocole hérité se fait en une soirée; segmenter le réseau d'une usine prend des mois. Les deux méritent leur place dans le plan, mais pas au même horizon.

Les signes d'un rapport de qualité

Tous les rapports ne se valent pas. Un bon rapport coche ces cases :

  • Un sommaire exécutif compréhensible sans connaissances techniques.
  • Une portée claire, avec les dates, les cibles et les exclusions.
  • Des constats validés manuellement, pas un simple copier-coller d'un outil de balayage.
  • Une preuve pour chaque constat important (capture, requête, extrait).
  • Des étapes de reproduction, pour que votre équipe TI puisse vérifier la correction.
  • Des recommandations précises et adaptées à vos systèmes.
  • Au moins une chaîne d'attaque expliquée de bout en bout, quand le test en a révélé.
  • Ce qui a bien fonctionné : une tentative bloquée par votre antivirus, une alerte reçue par votre fournisseur TI. Ces points positifs vous disent quels investissements protéger.

Si votre rapport ressemble surtout à une liste exportée d'un scanner, vous avez peut-être payé pour un balayage de vulnérabilités plutôt que pour un vrai test d'intrusion.

Le retest : fermer la boucle

Une fois les corrections faites, demandez un retest. Le testeur vérifie que chaque constat est réellement corrigé et met à jour son statut : corrigé, partiellement corrigé ou toujours présent. Sans cette étape, vous ne savez pas si le correctif a fonctionné.

Le retest est souvent facturé à part : vérifiez-le dès la soumission. Pour comparer les offres et comprendre ce qui fait varier les montants, consultez notre article sur le prix d'un test d'intrusion au Québec. Et si vous planifiez déjà le prochain test, notre comparatif externe ou interne vous aidera à choisir la bonne portée.

Besoin d'aide pour passer du rapport aux correctifs ? Notre équipe peut prendre en charge la remédiation et le durcissement de vos systèmes.

Questions fréquentes

Peut-on transmettre notre rapport de test d'intrusion à un client ou à un assureur ?+

Évitez d'envoyer le rapport complet : il décrit précisément comment entrer chez vous. Demandez plutôt à votre fournisseur une lettre d'attestation ou un sommaire destiné aux tiers, qui indique la portée, les dates, la méthodologie et l'état des corrections sans détails exploitables. Si un client exige davantage, encadrez la transmission par une entente de confidentialité.

Comment protéger le rapport de test d'intrusion lui-même ?+

Traitez-le comme un document confidentiel : stockage chiffré, accès limité aux personnes qui doivent agir, et pas de pièce jointe envoyée à une longue liste de distribution. Conservez les rapports précédents de façon tout aussi sécuritaire, car ils permettent de mesurer vos progrès d'une année à l'autre.

Faut-il une rencontre de restitution en plus du rapport écrit ?+

Oui, demandez-la dès la soumission. Une rencontre d'une heure ou deux avec la direction et l'équipe TI permet de poser des questions, de valider les priorités et de clarifier les recommandations ambiguës. C'est souvent là que l'on comprend vraiment ce que le testeur a pu faire.

Sources

  1. 1.FIRST : Common Vulnerability Scoring System v4.0, spécification
  2. 2.CISA : Known Exploited Vulnerabilities Catalog
  3. 3.NIST SP 800-115 : Technical Guide to Information Security Testing and Assessment
  4. 4.Packetlabs : coût moyen d'un test d'intrusion au Canada