Plan de remédiation : structurer la correction après un audit ou
un pentest

Un plan de remédiation prend une liste de findings, issue d'un audit, d'un pentest ou d'un scan, et attache à chacun une priorité, un responsable, un délai et un mode de vérification. La liste décrit le risque ; le plan décide de ce qu'on en fait, dans quel ordre, et comment on saura que c'est refermé.

Plutôt qu'un modèle vide, voici un plan construit sur un vrai export : celui de notre plateforme EASM, avec son module de pentest, sur son compte de démonstration. Le tri qui précède, c'est-à-dire comment 28 findings "critiques" se réduisent à quatre constats prouvés, est détaillé dans le guide de la gestion des vulnérabilités. Ici, on part du résultat de ce tri pour écrire le plan.

Le plan, ligne par ligne

Quatorze lignes couvrent 80 des 616 findings : les 28 critiques, plus les élevés et moyens qui partagent une cause avec eux, et ceux dont la preuve enregistrée tient déjà seule, comme le .git/ de BrokenCrystals ou l'injection CRLF de ginandjuice.shop. D'autres élevés passent d'abord par une confirmation (un indice d'XXE sur rest.vulnweb.com, par exemple, n'est encore qu'un écho de requête) ; le reste, en grande majorité faible ou informatif, relève de l'hygiène et se traite par lots au cycle courant. La colonne à lire en premier est la quatrième : la sévérité après tri s'écarte de la sévérité annoncée sur sept lignes sur quatorze.

Pourquoi cet ordre

Les secrets d'abord, et la révocation avant le correctif. Les quatre lignes à 24 h ont un point commun : n'importe qui peut lire le fichier, sans compte ni interaction, et une fois lu, le retirer ne sert plus à rien. Retirer le config.json ferme la fuite ; seul le changement des mots de passe annule ce qui a déjà fuité. C'est aussi pourquoi aucune de ces lignes ne relève d'un patch : ce sont des erreurs de déploiement, qu'une mise à jour ne corrige pas.

Un chemin d'attaque "prouvé" par l'outil reste une affirmation à vérifier. L'outil a calculé trois chemins, et n'en marque qu'un comme prouvé :

Sur le papier, ce chemin ferait monter tout ce qu'il traverse. Nous l'avons donc vérifié avant de lui confier l'ordre du plan, et il ne tient pas en l'état. Le pivot repose sur un hébergement partagé, or testasp.vulnweb.com résout vers 44.238.29.244 et répond en IIS 8.5 sur Windows Server, quand rest.vulnweb.com résout vers 18.215.71.186 et répond en Apache 2.4.25 sur Debian, avec PHP 7.1.26 : ni adresse ni pile en commun. La "preuve" enregistrée pour ce lien se résume à une phrase de synthèse, sans requête, et aucun finding d'injection SQL sur testasp ne figure dans l'export. La ligne 5 existe donc pour rejouer l'injection et le pivot, pas pour corriger : un ticket de correction ne s'ouvrira que si l'un des deux se confirme. Le db.sql reste à 24 h sans l'aide de ce chemin, pour la raison donnée plus haut : n'importe qui peut le télécharger. Les deux autres chemins sont marqués inférés, et l'un d'eux passe par le /.svn/wc.db de BrokenCrystals, que nous avons remonté en critique sur sa propre preuve. La leçon vaut pour tout outil : un libellé "prouvé" posé automatiquement se vérifie comme n'importe quel autre constat avant de décider des priorités.

Une faille confirmée n'est pas forcément la plus urgente. La XSS DOM est le seul constat du lot rejoué dans un navigateur, et elle passe pourtant après les fichiers exposés : elle demande qu'une victime suive un lien piégé, là où le config.json se lit d'une requête. Sept jours, pas vingt-quatre heures. La CSP de la ligne 12 commence par ginandjuice.shop pour la même raison : sur cet hôte, elle réduit l'impact d'une XSS déjà prouvée.

L'effort compte. Le info.php ne vaut qu'une sévérité moyenne après tri, c'est une fuite d'informations de configuration, mais sa correction consiste à supprimer un fichier. Il passe à 72 h devant des chantiers plus graves et plus longs, comme la sortie d'un serveur en fin de support. Pourquoi le score de gravité seul ne tranche pas ces arbitrages est développé dans le guide de la gestion des vulnérabilités.

Une ligne par cause, pas par finding

Les 80 findings tiennent en quatorze lignes parce que le plan suit les causes. Un seul info.php produit huit findings, parce que cinq détecteurs le voient et que le même service est inventorié sous deux noms d'actif. Une seule bannière IIS produit dix CVE. Et trois lignes (config.json, .env, chaîne de connexion) partagent la même cause racine : des artefacts de développement qui partent en production. Les corriger un par un ferme la fuite ; ajouter à la chaîne de build un contrôle qui refuse ces fichiers empêche la suivante. Quand une cause est diffuse dans le code, un pentest avec accès au code source en retrouve toutes les occurrences, là où un test externe n'en voit que celles qui répondent sur une URL.

Assigner, dater, vérifier

La colonne responsable nomme un type d'équipe parce que l'organisation est fictive ; dans un vrai plan, elle porte un nom de personne. Les délais s'alignent sur vos fenêtres de maintenance et votre capacité de retour arrière, ce que détaille l'article sur le patch management. Deux lignes du tableau sont d'ailleurs des candidates naturelles à une acceptation de risque temporaire, documentée et datée : les deux serveurs en fin de vie, le temps que la migration se fasse.

La vérification est la condition de clôture, et l'export montre pourquoi. Sur les 39 findings passés "corrigés", une partie vient d'une réconciliation automatique : un scan postérieur n'a pas reproduit le constat, ce qui ne prouve pas qu'il a disparu. Le db.sql est ainsi marqué corrigé sur un actif et ouvert sur l'autre, alors que c'est le même fichier. Un ticket ne se ferme qu'après avoir rejoué la preuve d'origine : la même requête sur le même chemin, et pour la ligne 5, l'injection puis le pivot annoncés par l'outil. C'est pour cela que le retest fait partie d'un pentest bien mené et qu'il pèse dans le prix d'un test d'intrusion.

Un plan de remédiation se refait à chaque rapport. Branché sur une découverte continue des actifs, comme le fait l'EASM, il part à chaque fois d'un périmètre à jour. Si vous avez un rapport en attente et besoin d'aide pour le trier et en tirer un plan tenable, la page contact est le plus court chemin.

Questions fréquentes sur le plan de remédiation