Correctifs de sécurité : décider quoi traiter en premier

Le rapport de vulnérabilités arrive alors que la fenêtre de maintenance est déjà remplie. L’équipe peut intervenir sur une partie du parc, le métier refuse l’arrêt de son application et le prestataire attend un accord. Trier la liste par sévérité semble régler le problème. Cela produit un ordre, mais pas forcément celui dont l’entreprise a besoin.

Je préfère partir des décisions à prendre : quel équipement protéger maintenant, quelle intervention préparer et quel report faire assumer. Le livrable utile est une liste de travaux réalisables, avec les risques qui restent visibles. Voici comment je construirais cette liste dans une DSI à équipe restreinte.

Vérifier que la vulnérabilité concerne réellement le parc

Avant de réserver une intervention, je demande une confirmation du produit, de la version installée et des conditions décrites dans l’avis de l’éditeur. Un nom de logiciel présent dans l’inventaire ne suffit pas. Le composant vulnérable peut être absent, désactivé ou livré dans une version corrigée que la détection reconnaît mal.

Cette vérification ne doit pas devenir un prétexte pour attendre. Sur un équipement exposé dont la version reste inconnue, je conserve une incertitude à lever en priorité. Je ne transforme pas l’absence d’information en absence de risque. La personne chargée de vérifier reçoit une échéance et sait qui prévenir si elle ne peut pas conclure.

Je regroupe ensuite les occurrences par intervention possible : même paquet à déployer, même équipement à mettre à niveau, même application à tester. Une correction peut traiter plusieurs vulnérabilités. À l’inverse, une même faille peut nécessiter des interventions différentes selon les sites ou les dépendances. Ce regroupement permet de discuter du travail réel au lieu de compter seulement les lignes du rapport.

Croiser sévérité, exploitation et exposition locale

Le CVSS présenté par FIRST caractérise la sévérité d’une vulnérabilité. Je conserve cette information, mais je ne demande pas au score de base de représenter à lui seul notre situation. Il ne dit pas quel équipement porte la facturation, ni quelles protections sont effectivement en place chez nous.

Le catalogue KEV de la CISA recense des vulnérabilités dont l’exploitation est connue. J’utilise cette présence comme un signal fort pour remonter les équipements concernés dans la file de traitement. L’absence du catalogue ne constitue pas une preuve de sécurité : elle ne permet pas d’écarter une alerte de l’éditeur ou une exposition dangereuse.

Le modèle EPSS de FIRST estime la probabilité qu’une vulnérabilité soit exploitée dans la nature au cours des trente prochains jours. Ce n’est pas la probabilité que notre entreprise soit compromise. Je m’en sers pour éclairer les cas encore incertains, sans laisser une estimation faible annuler une exploitation déjà constatée.

J’ajoute enfin le contexte local : accès depuis Internet, chemins accessibles depuis les postes internes, privilèges obtenus et conséquences possibles pour l’activité. Un serveur interne n’est pas automatiquement protégé. Je veux savoir ce qui empêche effectivement d’atteindre le composant vulnérable, et sur quelle vérification repose cette affirmation.

Transformer le classement en décisions exécutables

Je propose une grille commune à la sécurité, à l’exploitation et aux responsables des services concernés. Elle doit déboucher sur une prochaine action, pas sur une nouvelle couleur dans le tableau de bord. Les situations suivantes sont des exemples de décision, à adapter au parc.

Je n’imposerais pas ici un délai universel. L’urgence dépend de la menace, de l’exposition et des possibilités de protection. En revanche, chaque ligne doit recevoir une date, un responsable et un décideur capable de débloquer l’intervention. Une priorité sans échéance laisse le technicien arbitrer seul entre la sécurité et le planning.

Le classement doit aussi pouvoir changer entre deux revues. Une exploitation nouvellement signalée, une ouverture réseau ou l’échec d’une protection temporaire justifient de reprendre la décision sans attendre la réunion suivante.

Donner une limite explicite aux reports métier

Le responsable métier peut avoir une raison sérieuse de refuser l’intervention proposée. Une opération indispensable est en cours, le prestataire applicatif n’est pas disponible ou l’environnement de test ne permet pas de vérifier la compatibilité. Je demande que cette contrainte soit décrite précisément, avec la première possibilité de traitement.

En face, la DSI expose ce qui reste vulnérable et propose une protection vérifiable : désactiver une fonction concernée, restreindre un accès ou isoler un équipement, lorsque les recommandations de l’éditeur et l’architecture le permettent. Une surveillance supplémentaire peut aider à détecter un problème ; elle ne supprime pas la vulnérabilité.

Un report de correctif est une décision temporaire sur un risque identifié, avec un responsable et une date de fin.

Je consigne le motif, le périmètre, la mesure appliquée, sa preuve de fonctionnement et la personne habilitée à accepter le risque restant. Si aucune protection acceptable n’est possible, il faut arbitrer une restriction ou un arrêt. Le silence du métier ne vaut pas acceptation.

Pour une application durablement impossible à maintenir, les reports successifs doivent déboucher sur une décision de remplacement ou de retrait. C’est alors un sujet de dette technique à rendre arbitrable, et plus seulement une opération de maintenance à déplacer.

Préparer le déploiement et contrôler la correction

Le guide du NIST sur la gestion des correctifs inclut la priorisation, l’installation et sa vérification dans un même processus de maintenance préventive. Je retiens surtout cette continuité : le travail ne se termine pas quand l’outil annonce que le paquet a été envoyé.

Avant de déployer, je fais préciser les prérequis, les redémarrages, le contrôle métier et les conditions d’arrêt. Un essai sur un périmètre représentatif aide à repérer une régression, sans garantir que tout le parc réagira de la même façon. En urgence, le périmètre d’essai peut être réduit ; cette limite doit rester explicite.

Le retour arrière mérite lui aussi une décision. Revenir à la version précédente peut réintroduire la faille. Il faut donc prévoir la protection à appliquer dans ce cas, et vérifier que la reprise envisagée est réalisable. Un test de restauration du service peut contribuer à cette préparation, sans remplacer les vérifications propres au correctif.

Après l’intervention, je contrôle la version réellement active, les réglages nécessaires et le fonctionnement du service. Je rapproche le résultat de la liste des équipements attendus. Une machine injoignable reste à traiter ; elle ne disparaît pas du périmètre parce que la campagne est terminée. Si des indices de compromission apparaissent, la correction ne remplace pas le traitement de l’incident.

Installer une revue courte des exceptions et des échecs

Pour commencer la semaine prochaine, je choisirais un périmètre connu : les équipements exposés et leurs dépendances immédiates. L’équipe construirait une file commune avec les avis applicables, les décisions, les échéances et les preuves. Le reste du parc conserverait son cycle régulier de maintenance ; ce premier tri ne doit pas devenir une dispense permanente pour les autres systèmes.

La revue porterait d’abord sur les corrections urgentes encore ouvertes, les déploiements en échec et les reports arrivant à échéance. Je demanderais ce qui empêche de terminer et quelle décision manque. Un pourcentage global de conformité peut masquer précisément l’équipement qui mérite l’attention du DSI.

Si la file ne diminue pas, je regarderais les causes : créneaux refusés, versions non maintenues, absence de relais chez le prestataire ou capacité technique insuffisante. Le tri rend ces obstacles visibles. Il ne fournit ni les compétences ni les fenêtres d’arrêt manquantes. Le DSI doit alors obtenir un arbitrage sur les moyens ou le service rendu, plutôt que demander un nouveau classement du même retard.