Gestion des correctifs et des accords de niveau de service

La priorisation vous indique quoi corriger ; la gestion des correctifs est le processus rigoureux qui permet effectivement de mener ces corrections à terme, dans les délais et sur l’ensemble du parc.

Les SLA (accords de niveau de service) définissent le délai dans lequel les différents niveaux de gravité doivent être corrigés. Sans eux, les corrections urgentes prennent du retard et la responsabilité disparaît.

Un cycle reproductible permet de maintenir les systèmes à jour :

• Identifiez les correctifs disponibles (avis des fournisseurs, résultats d’analyse).
• Évaluez la pertinence et le risque liés à leur application.
• Testez dans un environnement hors production.
• Déployez par vagues contrôlées.
• Vérifiez que le correctif a été appliqué et que le système fonctionne correctement.

Chaque étape a des responsables et des éléments probants, à l’image du cycle de vie plus large de VM.

Un SLA transforme une intention en échéance. Il définit le délai maximal autorisé entre la découverte et la remédiation, selon le niveau de gravité. Exemples d’objectifs :

• Critique / KEV : 7 à 15 jours (ou moins pour les actifs accessibles depuis Internet).
• Élevé : 30 jours.
• Moyen : 90 jours.
• Faible : au mieux / cycle suivant.

Les SLA rendent l’ancienneté des constats mesurable et incitent à les clôturer, pas seulement à les prendre en compte.

Faites dépendre le délai du risque réel, pas seulement du CVSS. Une vulnérabilité critique répertoriée dans KEV ou accessible depuis Internet doit avoir un SLA plus court qu’une vulnérabilité moyenne interne.

Les référentiels sont utiles : CISA impose aux agences fédérales de remédier aux vulnérabilités de KEV dans des délais fixés, et de nombreuses entreprises adoptent des délais accélérés similaires pour les vulnérabilités activement exploitées, quel que soit leur CVSS.

Les correctifs peuvent provoquer des dysfonctionnements. Les tests en préproduction détectent les régressions avant leur arrivée en production :

• Appliquez d’abord le correctif à un groupe de test représentatif.
• Validez les fonctionnalités critiques et les performances.
• Vérifiez l’absence de conflits avec les logiciels existants.

Trouvez l’équilibre entre rapidité et sécurité : pour une vulnérabilité de KEV exploitée dans le monde réel, acceptez davantage de risques et corrigez plus rapidement que pour une mise à jour de routine.

Déployez par vagues (déploiement par anneaux) : groupe pilote, puis anneaux plus larges, puis l’ensemble du parc. Surveillez l’état du système à chaque étape avant de poursuivre.

Prévoyez toujours un plan de retour arrière : instantanés, rétrogradation d’un paquet ou restauration de la configuration. Si un correctif provoque une interruption de service, vous devez pouvoir revenir rapidement à l’état précédent pendant que vous recherchez la cause.

La gestion manuelle des correctifs ne passe pas à l’échelle. Utilisez des outils centralisés :

• WSUS / SCCM / Intune pour Windows.
• Gestion de configuration (Ansible, Puppet, Chef) pour les parcs Linux.
• Images de référence ou de base reconstruites avec les correctifs pour les environnements en nuage et les conteneurs.

L’automatisation impose la cohérence et réduit le délai entre la publication d’un correctif et son déploiement.

Il est parfois impossible d’appliquer immédiatement un correctif : retard du fournisseur, ancien système fragile ou disponibilité requise. Appliquez des mesures compensatoires pour réduire le risque dans l’intervalle :

• Segmentation réseau / règles de pare-feu.
• Correctifs virtuels au moyen de signatures WAF ou IPS.
• Désactivation de la fonctionnalité ou du service vulnérable.

Ces mesures vous donnent du temps, mais ne remplacent pas durablement la véritable correction.

Les systèmes en fin de vie peuvent ne disposer d’aucun correctif. Plusieurs options sont possibles :

• Isolez-les sur un segment réseau restreint.
• Protégez-les par des contrôles d’accès stricts et une surveillance renforcée.
• Planifiez leur migration ou leur mise hors service avec une échéance.
• Acceptez formellement le risque résiduel, avec une date d’expiration.

Documentez tout ; un système impossible à corriger qui n’est pas documenté représente un risque d’audit et de compromission.

Suivez le respect effectif des engagements du programme :

• MTTR selon la gravité, comparé à l’objectif du SLA.
• Taux de respect des SLA (pourcentage de constats clôturés dans les délais).
• Constats en retard / selon leur ancienneté par équipe et par actif.
• Couverture des correctifs (pourcentage du parc à jour).

Présentez les résultats par équipe responsable afin que la responsabilité soit visible et que les secteurs plus lents reçoivent l’attention nécessaire.

Après le déploiement, vérifiez : effectuez une nouvelle analyse pour confirmer que la CVE a disparu et que le système fonctionne correctement, puis clôturez le constat avec des éléments probants. Réinjectez les problèmes récurrents (une bibliothèque qui réapparaît sans cesse, une équipe constamment en retard) dans l’amélioration des processus.

Une gestion des correctifs bien menée transforme un risque priorisé en réduction mesurable du risque, obtenue dans les délais.

Vérifiez le rôle des SLA de remédiation.

La gestion des correctifs mène les constats prioritaires à leur terme grâce à l’identification, l’évaluation, les tests, le déploiement progressif et la vérification, avec l’appui de plans de retour arrière et de l’automatisation. Les SLA fixent des échéances selon la gravité et le risque (plus courtes pour KEV et les actifs accessibles depuis Internet), afin que les corrections soient effectuées dans les délais.

Lorsque l’application d’un correctif est impossible, utilisez des mesures compensatoires et une acceptation documentée du risque, limitée dans le temps. Mesurez le MTTR, le respect des SLA et la couverture, puis réinjectez les enseignements dans le cycle de vie.