Priorise les corrections selon criticité, exploitation et contexte

L’idée reçue

« Il suffit de trier les vulnérabilités par CVSS décroissant et d’installer tous les correctifs. »

Le patch management est une maintenance préventive gouvernée. Il faut savoir ce qui est affecté, ce qui est exposé, ce qui est exploité, ce qui peut être corrigé et comment vérifier sans interrompre la mission.

01Construis une priorité contextuelle

Sévérité technique
+ exploitation connue ou active
+ exposition
+ criticité de l'actif
+ contrôles compensatoires
+ ancienneté et disponibilité du correctif
= priorité de traitement

Cette combinaison produit une décision explicable, pas une vérité mathématique universelle.

02Utilise l’exploitation observée

Le catalogue KEV de CISA recense des vulnérabilités pour lesquelles une exploitation dans la nature est connue.

Présence dans KEV
→ signal fort de priorité

Absence de KEV
→ ne prouve pas l'absence d'exploitation

Preuve d'exploitation interne
→ déclenchement possible d'une réponse incident

Le catalogue est une entrée du processus, pas sa seule source.

03Vérifie l’exposition réelle

Exposition

Question

Effet sur la priorité

Internet

le composant vulnérable est-il accessible directement ?

augmente souvent l’urgence

Interne

quels comptes ou segments peuvent l’atteindre ?

dépend du mouvement latéral possible

Restreinte

le filtrage et l’identité sont-ils prouvés ?

réduit sans supprimer le risque

Inactive

la fonctionnalité affectée est-elle réellement désactivée ?

peut rendre le cas non applicable

Un « serveur interne » n’est pas automatiquement sûr.

04Choisis l’action adaptée

Patch disponible et urgence élevée
→ tester rapidement, appliquer, vérifier

Patch indisponible
→ réduire l'exposition, désactiver la fonction, filtrer ou isoler

Produit obsolète
→ planifier retrait ou remplacement

Risque limité et accepté
→ propriétaire, justification, échéance et revue

Une mitigation temporaire doit avoir un propriétaire et une date de sortie.

05Prépare le changement

Périmètre exact
Pré-requis et dépendances
Environnement de test
Sauvegarde ou snapshot adapté
Fenêtre de changement
Plan de rollback
Critères de succès
Surveillance après changement

Le rollback ne doit pas annuler une correction au prix d’une réexposition silencieuse.

06Observe le plan synthétique

lab=/tmp/soria-cyber-vulnerability-resilience-$USER
bash module3-cyber-vulnerability-resilience.sh setup "$lab"
bash module3-cyber-vulnerability-resilience.sh run "$lab"
column -s, -t "$lab/output/vulnerability-priority.csv"

Résultats clés :

VULN-101 → EMERGENCY_PATCH
VULN-103 → EMERGENCY_PATCH
VULN-108 → TRACK_AND_MITIGATE

VULN-108 est active mais sans patch. Le lab exige une mitigation suivie au lieu de prétendre installer un correctif inexistant.

07Vérifie après correction

Avant
→ version, configuration, exposition et preuve

Pendant
→ résultat du déploiement, erreurs et rollback éventuel

Après
→ version corrigée, fonctionnalité disponible, scan ou contrôle ciblé, logs et métriques

« Job terminé avec succès » ne prouve pas toujours que tous les actifs ont reçu le correctif.

08Mesure le processus

- couverture de l'inventaire
- délai entre publication et qualification
- délai entre qualification et traitement
- vulnérabilités exploitées non traitées
- exceptions ouvertes
- échecs de déploiement
- preuves de vérification manquantes

La quantité totale de CVE ne suffit pas pour piloter la réduction du risque.

Mission

Défends le plan de patching

À partir du lab, présente les deux urgences, justifie le traitement différé de VULN-102, et construis pour VULN-108 une mitigation temporaire avec propriétaire, preuve et échéance.

✓À retenir

La priorité vient de l’intersection entre menace, exposition, mission et capacité de traitement. Patcher signifie identifier, prioriser, préparer, appliquer et vérifier.