Orchestration de la remédiation : de la vulnérabilité détectée à la correction prouvée

Qu’est-ce que l’orchestration de la remédiation ?

L’orchestration de la remédiation est l’ensemble des règles et des outils qui font passer une vulnérabilité de l’état « détectée » à l’état « corrigée et vérifiée ». Elle ne corrige rien elle-même. Elle décide de l’ordre, désigne qui agit, fixe un délai, trace les écarts et exige une preuve de fermeture.

Dans le cadre CTEM de Gartner, c’est l’étape de mobilisation. Gartner y insiste : la remédiation automatique ne suffit pas, il faut lever les obstacles d’organisation, d’approbation et de déploiement. Autrement dit, le problème n’est presque jamais technique.

La détection produit une liste. L’orchestration doit faire baisser cette liste, dans un ordre défendable et avec des délais tenus.

Pourquoi les vulnérabilités détectées restent-elles ouvertes ?

En mission, nous retrouvons régulièrement des vulnérabilités déjà signalées par un précédent audit ou par le scanner interne. Les causes se répètent :

• personne n’en est propriétaire : le rapport part sur une liste de diffusion, chacun suppose qu’un autre s’en charge ;
• aucun délai n’est opposable : sans engagement écrit, la correction cède à chaque urgence de production ;
• le correctif n’est pas applicable : pas de fenêtre de maintenance, éditeur qui impose sa propre qualification, logiciel en fin de vie ;
• le ticket est fermé sur déclaration : l’équipe a lancé la mise à jour, mais personne n’a vérifié qu’elle avait pris effet.

Le NIST le formule dans sa publication SP 800-40 Rev. 4 : appliquer immédiatement un correctif n’est pas toujours possible, faute de correctif disponible, de support éditeur ou de fenêtre de maintenance. Une orchestration sérieuse prévoit ces cas au lieu de les découvrir ticket par ticket.

Les six étapes d’un cycle orchestré

1. Prioriser par l’exploitabilité et le contexte

Une file ordonnée par score CVSS brut traite d’abord des vulnérabilités qui ne seront jamais exploitées. La priorisation croise la sévérité, la probabilité d’exploitation (EPSS), l’exploitation constatée (catalogue KEV de la CISA) et le contexte de l’actif : exposition, valeur métier, place dans un chemin d’attaque. Nous détaillons cette lecture dans notre guide pour évaluer la criticité d’une CVE.

Le résultat attendu n’est pas un score, mais une catégorie de traitement, qui conditionne le délai.

2. Affecter à un propriétaire

Chaque actif doit être rattaché à une équipe ou à une personne. Sans ce lien, l’affectation automatique est impossible et les tickets partent au mauvais endroit, ou nulle part. C’est l’apport d’un inventaire tenu à jour, tel que le construit un outil de CAASM.

Un ticket utile contient l’actif précis, la raison de la priorité (exploitation constatée, exposition, criticité), la correction recommandée, la mesure de contournement possible et le délai.

3. Fixer un délai selon le scénario

Le NIST propose de raisonner en scénarios plutôt qu’en score, chacun avec son plan de maintenance. La directive BOD 26-04, publiée par la CISA le 10 juin 2026 pour les agences fédérales américaines, suit la même logique : l’urgence dépend de l’exposition de l’actif, de la présence au catalogue KEV, de l’automatisation possible de l’exploitation et de l’impact technique.

Les délais chiffrés de chaque ligne vous appartiennent. Ils doivent être réalistes pour être tenus, validés par la direction et écrits. Un point de la BOD 26-04 mérite d’être repris : le délai démarre à l’ajout au KEV ou à la détection sur l’actif, selon le premier des deux événements, et non à l’ouverture du ticket.

4. Traiter les exceptions et l’acceptation du risque

Toutes les vulnérabilités ne seront pas corrigées dans les délais. Le NIST rappelle les quatre réponses possibles à un risque : l’accepter, l’atténuer, le transférer ou l’éviter (en retirant le logiciel ou l’actif). Corriger n’est qu’une forme d’atténuation.

L’orchestration doit rendre ces choix explicites. Une exception documentée comprend :

1. la vulnérabilité et l’actif concernés ;
2. la raison de l’écart (pas de correctif, contrainte éditeur, fenêtre indisponible) ;
3. la mesure compensatoire en place ;
4. le signataire, qui est le propriétaire métier de l’actif ;
5. une date d’expiration et une date de réexamen.

Le NIST demande de suivre toutes les exceptions et de les revoir régulièrement pour vérifier si le plan normal peut désormais s’appliquer. Une acceptation sans date d’expiration n’est pas une décision, c’est un oubli organisé.

5. Vérifier par rejeu

Un ticket fermé n’est pas une vulnérabilité corrigée. Un correctif peut être partiel, annulé par un retour arrière, écrasé par une réinstallation ou neutralisé par une configuration restée vulnérable.

Le NIST fait de la vérification une phase à part entière : confirmer que le correctif est installé et qu’il a pris effet, puis surveiller dans la durée que personne ne le désinstalle ni ne désactive la mesure compensatoire. En pratique, le ticket ne se clôt que sur le résultat d’un nouveau test : rescan de l’actif, ou rejeu du scénario d’attaque qui avait démontré l’exploitabilité.

6. Mesurer les délais réels

Le MTTR (mean time to remediate) est l’indicateur le plus cité. Seul, il trompe : un MTTR global mélange des vulnérabilités sans rapport et se laisse tirer par quelques dossiers anciens. Le NIST juge d’ailleurs non exploitables les indicateurs trop simples, comme le pourcentage global de vulnérabilités corrigées. Il propose un tableau qui croise l’importance de l’actif et celle de la vulnérabilité, avec pour chaque case la part corrigée dans les délais, le délai moyen et le délai médian.

Quels indicateurs suivre ?

Fixez une fois pour toutes le point de départ (détection, ajout au KEV ou création du ticket) et le point d’arrivée (rejeu réussi). Un indicateur imparfait mais stable vaut mieux qu’un indicateur idéal dont la définition change chaque trimestre.

Dans Beareye, la gestion des vulnérabilités du Command Center transforme chaque vulnérabilité prioritaire en ticket assigné avec un plan d’action, rejoue l’analyse après correction et suit le MTTR et le respect des SLA dans le temps.

Exemple : une vulnérabilité de bordure, du signal à la preuve

Exemple type. Une vulnérabilité affectant le pare-feu de bordure d’une ETI est ajoutée au catalogue KEV un jeudi. Le délai démarre à cette date, conformément à la règle interne calquée sur la BOD 26-04.

Le ticket est créé automatiquement et affecté à l’équipe réseau, propriétaire de l’équipement dans l’inventaire. Il indique le scénario « correctif d’urgence » et l’échéance. L’éditeur n’a pas encore publié de correctif : l’équipe applique la mesure de contournement recommandée et restreint l’accès à l’interface d’administration. Le ticket bascule en « atténuation d’urgence », avec une date de remplacement.

Le correctif sort quatre jours plus tard. Il est appliqué d’abord sur l’équipement de secours, puis sur l’équipement principal. Le rejeu confirme que la vulnérabilité n’est plus exploitable ; la mesure de contournement est retirée et le ticket clos. Une revue des journaux vérifie, en parallèle, l’absence de compromission antérieure.

Ce scénario est construit à partir de situations courantes en mission, pas à partir d’un client identifiable.

Ce que NIS2 attend

La directive NIS2 n’impose aucun outil. Son article 21 range parmi les mesures de gestion des risques « le traitement et la divulgation des vulnérabilités », ainsi que « des politiques et des procédures pour évaluer l’efficacité des mesures de gestion des risques ». Un cycle tracé, avec propriétaires, délais, exceptions signées et preuves de fermeture, fournit cette matière. En France, la loi de transposition n’est pas encore promulguée ; les obligations de la directive sont, elles, connues. BEAROPS vous aide à préparer, documenter et démontrer votre conformité.

Limites de l’approche

L’orchestration dépend de l’inventaire. Un actif inconnu n’a ni propriétaire ni ticket. Sans découverte de la surface exposée et des actifs internes, le meilleur flux ne traite que ce qu’il voit.

Elle ne remplace pas l’arbitrage. Choisir entre une interruption de production et une exposition prolongée reste une décision humaine, qui engage la direction. L’outil documente cette décision, il ne la prend pas.

Elle ne traite que ce qui a été trouvé. Les faiblesses sans CVE, les enchaînements logiques et les erreurs de conception échappent souvent aux scanners. Un test d’intrusion régulier alimente la file avec ce que l’outillage automatique ne cherche pas.

L’automatisation se gagne par paliers. Automatiser la création des tickets et les relances ne présente pas de risque. Automatiser le déploiement des correctifs sur la production ou sur des systèmes industriels en présente un : on commence là où une erreur reste sans conséquence.