Toutes les organisations savent qu’il faut appliquer les correctifs. Presque toutes ont du retard. L’écart entre les deux ne s’explique pas par un manque d’outillage.
Pourquoi ça bloque réellement
Personne ne veut porter l’interruption. Redémarrer un serveur de production a un coût immédiat et visible. Ne pas le redémarrer a un coût potentiel et invisible. L’arbitrage penche mécaniquement du mauvais côté tant qu’il reste au niveau technique.
Les fenêtres de maintenance sont trop rares. Une fenêtre trimestrielle signifie qu’une vulnérabilité critique publiée le lendemain attend trois mois.
L’application ne supporte pas la mise à jour. Un logiciel métier certifié sur une version ancienne, un éditeur qui ne suit plus, un développement interne dont plus personne n’a le code.
L’inventaire est incomplet. On ne corrige pas ce qu’on ignore posséder. C’est le point de départ de tout, et le plus souvent négligé.
Ce qui débloque
Une politique de délais écrite et validée en comité
Par exemple : correctif appliqué sous 72 heures si la vulnérabilité est exploitée activement et le système exposé, sous 30 jours si elle est critique sans exploitation connue, au cycle trimestriel sinon.
L’important n’est pas le chiffre. C’est que la règle soit validée par une instance qui assume l’interruption — voir le rôle du comité sécurité. Le responsable technique cesse alors de porter seul l’arbitrage.
Des fenêtres fréquentes et prévisibles
Une fenêtre mensuelle courte, planifiée un an à l’avance, provoque moins de résistance qu’une demande exceptionnelle. Les métiers s’organisent autour de ce qui est prévisible.
Une procédure d’urgence distincte
Pour les cas qui ne peuvent pas attendre le cycle : qui décide, quel délai de préavis, quel retour arrière. Sans procédure d’urgence, l’urgence devient une négociation.
Un traitement séparé de ce qui ne peut pas être corrigé
Un système non patchable n’est pas un échec de la gestion des correctifs : c’est un risque à traiter autrement. Cloisonnement réseau strict, accès restreint, surveillance renforcée, et acceptation formelle du risque résiduel par la direction.
Le cloisonnement est ici la mesure compensatoire principale — voir la segmentation.
Prioriser sans se noyer
Quatre mille correctifs en attente ne se traitent pas par ordre de score. La priorisation utile croise l’exploitation réelle, l’exposition et la valeur de l’actif — méthode détaillée dans pourquoi le CVSS ne suffit pas.
Règle simple à fort rendement : une vulnérabilité figurant au catalogue des vulnérabilités activement exploitées de la CISA, présente sur un système exposé, passe devant tout le reste.
Ce que demandent les référentiels
La mesure 8.8 d’ISO/IEC 27002:2022 demande d’obtenir l’information, d’évaluer l’exposition et d’agir. Un auditeur n’attend pas zéro vulnérabilité : il attend que vous sachiez expliquer pourquoi telle faille est encore ouverte et depuis quand.
Un risque accepté, tracé et daté est conforme. Un retard subi, non documenté, ne l’est pas.
L’article 21 de NIS 2 cite explicitement le traitement des vulnérabilités parmi les mesures exigées.
Les quatre indicateurs qui comptent
- Le délai moyen d’application sur les systèmes exposés — le seul que regardera un assureur.
- Le nombre de systèmes non patchables, et leur couverture par des mesures compensatoires.
- Le taux de couverture de l’inventaire.
- Le nombre de risques acceptés formellement, en tendance.
Le quatrième surprend souvent : une hausse n’est pas un mauvais signe. Elle indique qu’on documente au lieu de subir.
Les systèmes qu’on ne peut pas redémarrer
Toute organisation en a : un serveur applicatif dont personne ne sait s’il redémarrera, un automate en production continue, une machine sous un système hors support qui pilote un équipement de mesure. Ils concentrent une part importante du risque résiduel, et le discours habituel — « il faut les mettre à jour » — n’a aucun effet parce qu’il ignore la contrainte réelle.
Le traitement efficace ne passe pas par le correctif mais par la réduction d’exposition. Quatre leviers, par ordre de coût croissant :
- Retirer les accès inutiles. Un système non corrigeable joignable depuis l’ensemble du réseau est un problème très différent du même système joignable depuis trois adresses identifiées. C’est la mesure la moins chère et la plus efficace.
- Supprimer les usages annexes. Ces machines servent souvent aussi de relais de fichiers ou de poste de consultation. Chaque usage supplémentaire ajoute une voie d’entrée sans rapport avec leur fonction.
- Surveiller spécifiquement. Puisqu’on ne peut pas empêcher, il faut voir. Une alerte sur toute connexion inhabituelle vers ces systèmes est peu coûteuse et immédiatement exploitable.
- Documenter et faire porter la décision. L’acceptation du risque doit être écrite, datée, portée par un responsable métier, et réexaminée chaque année. Cela ne réduit pas le risque, mais cela évite qu’il reste orphelin — et c’est ce qui déclenche généralement le budget de remplacement.
Les correctifs qui cassent
La crainte de la régression est la première cause de retard, et elle n’est pas irrationnelle : les incidents provoqués par une mise à jour existent réellement, et l’équipe qui les subit s’en souvient plus longtemps que des vulnérabilités évitées.
Trois pratiques réduisent le risque sans revenir à l’immobilisme.
Le déploiement progressif. Un premier groupe volontaire — souvent l’équipe informatique elle-même — puis un service pilote, puis le reste. Un problème détecté sur trente postes se corrige ; détecté sur mille, il devient un incident majeur. Cela n’ajoute pas de charge, seulement du séquencement.
La capacité de retour arrière testée. Elle est presque toujours supposée et rarement vérifiée. Un retour arrière qui n’a jamais été exécuté n’existe pas. Le tester une fois, hors urgence, change complètement la confiance des équipes.
La distinction entre correctif de sécurité et montée de version. Elles sont fréquemment confondues, ce qui pénalise les deux : un correctif de sécurité, ciblé et de faible ampleur, se retrouve bloqué par le processus de validation d’une montée de version majeure. Les séparer permet d’appliquer des délais très différents.
Les composants tiers, le sujet qui échappe au processus
Le processus de correctifs couvre généralement les systèmes d’exploitation et les logiciels achetés. Il ne couvre presque jamais les bibliothèques embarquées dans les applications développées en interne — alors que c’est là que se situe une part croissante des vulnérabilités exploitées.
Deux différences structurelles rendent le traitement plus difficile : il n’y a pas de mécanisme de mise à jour automatique, et la correction suppose de reconstruire puis redéployer l’application. Une organisation dont la chaîne de déploiement demande trois semaines et une validation manuelle ne pourra pas corriger dans un délai raisonnable, quelle que soit la qualité de sa détection.
Le préalable est un inventaire des composants par application. Sans lui, la question « sommes-nous concernés par cette vulnérabilité ? » se traite à la main, application par application, et prend plusieurs jours — pendant lesquels l’exposition demeure.
Le rythme réel des attaquants
L’écart entre la publication d’un correctif et l’apparition d’un code d’exploitation public se compte désormais fréquemment en jours pour les vulnérabilités les plus exposées, et les campagnes d’exploitation de masse suivent de près. Cet écart s’est réduit continûment, alors que les délais internes de déploiement, eux, sont restés à peu près constants.
C’est ce décalage qui rend la politique de délais indispensable : elle n’est pas un formalisme documentaire, c’est le seul moyen de rendre visible, avant l’incident, un arbitrage qui se prendra de toute façon — mais qui se prendra alors dans l’urgence et sans arbitre.
Sources
- ISO/IEC 27002:2022, mesure 8.8
- CISA — Known Exploited Vulnerabilities Catalog
- CERT-FR — avis et alertes
Aller plus loin
Le suivi dans la durée relève de notre maintien en condition de sécurité. L’évaluation de l’existant se fait par l’audit 360.