L'exécution d'un programme de gestion des vulnérabilités basée sur les risques est indispensable pour maintenir un environnement informatique sécurisé. Dans un précédent billet de blog, intitulé « Comment l'implémentation de la gestion des correctifs basée sur les risques permet de prioriser les exploitations actives », je vous ai donné mon point de vue sur la façon de prioriser les vulnérabilités. Ajuster l'aspect opérationnel de la sécurisation de vos systèmes est essentiel dans ce processus. 

En entreprise, l'exécution des opérations liées aux correctifs peut être un processus complexe. Même si vous êtes suffisamment à l'aise avec la priorisation des vulnérabilités, il est essentiel de prendre en compte les éléments suivants :

  • Fréquence de publication des correctifs,
  • Politiques d'application des correctifs permettant d'assurer l'efficacité de ce processus,
  • Campagnes de déploiement des mises à jour,
  • SLA (Accords de niveau de service) et mesures de conformité.   

Vous trouvez que cela fait beaucoup de choses à concilier ? Certes, mais un système suffisamment flexible pour gérer les événements planifiés et s'adapter aux imprévus vous procurera un contrôle total. 

Êtes-vous en mesure de tout contrôler ? 

Vous pouvez planifier certaines facettes de la publication des correctifs, mais pas d'autres.   

Prenons l'exemple de la fréquence de publication des correctifs de sécurité. Lors du Patch Tuesday, le deuxième mardi de chaque mois, Microsoft publie ses mises à jour les plus récentes. Cela inclut des mises à jour pour les systèmes d'exploitation, Office et d'autres applications utilisateur, pour des outils de développement comme Visual Studio et pour des composants Cloud dans Azure, entre autres.  

Le Patch Tuesday, qui a fêté son 20e anniversaire en octobre 2023, est une référence pour de nombreux programmes de publication des correctifs. En effet, il fixe une date pour la distribution de toutes les mises à jour Microsoft les plus récentes et des mises à jour tierces disponibles. Aucun autre fournisseur n'a eu un impact aussi marquant sur l'orientation des programmes de patching dans les entreprises. Aujourd'hui encore, le cycle mensuel d'application des correctifs, ancré sur le Patch Tuesday, reste la norme du secteur. 

D'autres fournisseurs ont tenté de l'imiter et de publier leurs mises à jour selon un calendrier précis : 

  • Oracle publie ses mises à jour CPU (Critical Patch Update) une fois par trimestre. 
  • Adobe publie généralement ses mises à jour une fois par mois, souvent en même temps que le Patch Tuesday. 
  • Google a récemment commencé à publier une seule mise à jour chaque semaine.   

Cependant, la plupart des fournisseurs publient des mises à jour de sécurité dès que possible et aussi souvent qu'ils le peuvent, pour s'assurer de traiter les vulnérabilités au plus vite. Il en résulte un flux aléatoire et incessant de mises à jour, qu'il faut sans cesse prioriser et distribuer dans toute l'entreprise.  

Processus de gestion des correctifs pour les politiques et les campagnes de patching

Comment contrôler ce chaos ? Il faut définir clairement des règles et mettre en place l'infrastructure nécessaire. Dans l'univers des correctifs, cela se traduit en politiques et campagnes d'application des correctifs (ou poliques et campagnes de patching).  

En plus de la priorisation des vulnérabilités, une politique d'application des correctifs doit prendre en compte de nombreux aspects, notamment, l'impact des mises à jour sur les opérations de l'entreprise, l'applicabilité aux différents types de systèmes, le degré de contrôle des mises à jour et d'autres facteurs.   

Les politiques d'application des correctifs varient en fonction de chaque entreprise. Dans le cas d'un serveur hébergeant des applications d'entreprise critiques, on définira une politique rigoureuse : un jeu de mises à jour clairement défini avec un contrôle strict de la configuration, qui s'exécute uniquement lors d'une fenêtre de maintenance spécifique et lance toujours un redémarrage à la fin du traitement pour garantir que le système est entièrement mis à jour. En revanche, la politique de patching de l'ordinateur portable d'un utilisateur marketing sera plus légère : identification d'une série d'applications dont les mises à jour approuvées sont parfois présentes, parfois non, en laissant à l'utilisateur la possibilité de reporter ces mises à jour et le redémarrage à sa convenance.  

Les campagnes de patching prennent ces politiques en compte mais permettent aussi de contrôler la multitude de correctifs publiés en permanence. 

Les meilleures pratiques de gestion moderne des correctifs exigent d'appliquer les correctifs plus souvent qu'une fois par mois. Les correctifs Google Chrome sont publiés toutes les semaines et des correctifs Zero Day peuvent être publiés à tout moment. Avec une campagne mensuelle, de nombreux systèmes restent vulnérables pendant de longues périodes.  

Définir 3 types de campagnes de patching

L'une des meilleures pratiques consiste à définir trois types de campagnes : maintenance régulière, mises à jour prioritaires et déploiements critiques.  

Campagnes de maintenance régulière 

Les campagnes de maintenance régulière appliquent la série standard de correctifs publiés chaque mois, que la plupart des entreprises utilisent actuellement. Ce type de campagne inclut : 

  • Des tests initiaux en environnement contrôlé pour garantir que les correctifs s'installent comme prévu. 
  • Un déploiement dans un groupe pilote élargi, pour des utilisateurs disposés à signaler les problèmes potentiels. 
  • Un déploiement dans des groupes prédéfinis de systèmes de production pour une distribution globale.   

Une campagne de maintenance contient généralement des mises à jour de sécurité publiées plus rarement, comme les publications du Microsoft Patch Tuesday, ainsi que les mises à niveau de performances ou d'applications. Ce type de campagne cible généralement des systèmes ayant une fenêtre de maintenance limitée, qui ne peuvent pas être interrompus sans un impact majeur sur l'entreprise. La plupart des correctifs seront généralement intégrés à une campagne de mises à jour prioritaires. 

Campagne de mises à jour prioritaires 

Une campagne de mises à jour prioritaires est conçue pour traiter rapidement les systèmes constamment exposés à de nouvelles vulnérabilités, mais qui peuvent être mis à jour plus fréquemment. Les systèmes utilisateur qui exécutent des applications de productivité et les navigateurs entrent dans cette catégorie de campagnes. Ils présentent souvent les plus grands risques d'exposition à l'hameçonnage, aux malwares et aux ransomwares.  

Les correctifs associés à une telle campagne ont souvent une priorité maximale, en raison de vulnérabilités dont l'exploitation est connue, mais peuvent aussi avoir un impact relativement faible sur l'entreprise parce qu'ils nécessitent uniquement le redémarrage d'un navigateur ou d'une application. Par conséquent, les politiques peuvent connaître un cycle de test plus court avant publication, et peuvent être plus rapidement distribuées à des groupes de systèmes plus nombreux, non critiques pour l'entreprise. Par exemple, un navigateur n'est pas toujours installé sur les serveurs, mais les membres de l'équipe Ventes en ont un sur leur ordinateur portable. 

Campagne de réponse Zero Day 

Les campagnes de réponse Zero Day sont réservées aux déploiements de correctifs d'urgence (« la maison brûle ») exigés par l'entreprise ou le secteur d'entreprise, qui doivent être exécutés dans un délai très court. Ce type de campagne a priorité sur tous les autres.   

Pour ce type de campagne, il convient de raccourcir les délais ou d'assouplir les règles entre deux phases de déploiement progressif... ou même de les ignorer totalement, selon le SLA à respecter. Aspect le plus important des campagnes de réponse Zero Day : Il s'agit toujours d'une distribution contrôlée des correctifs, et toutes les activités font toujours l'objet de rapports pour un suivi exact des événements de la campagne jusqu'à son achèvement. 

La durée d'exposition détermine la conformité 

Si l'on mesure la conformité en nombre de machines totalement patchées, cette métrique souligne que la majorité des systèmes ne restent conformes que pendant quelques heures chaque mois. Même si cet indicateur est techniquement exact, il représente mal la sécurité du système au fil du temps dans le cadre d'un programme basé sur les risques. Montrer la « durée d'exposition » à une vulnérabilité ou à un groupe de vulnérabilités spécifique est un meilleur indicateur. 

Voici un exemple : la vulnérabilité CVE-2024-4761 a été signalée comme corrigée lors d'une mise à jour Google Chrome publiée le 14 mai, qui se trouvait être le Patch Tuesday de mai. Le lendemain, ce correctif Chrome a été ajouté à une campagne de mises à jour prioritaires qui incluait une période de distribution de deux semaines sur les 500 systèmes du groupe 1 et les 1 000 systèmes du groupe 2. En supposant que la plupart des systèmes ont été mis à jour avec succès au cours de ces deux semaines, un rapport montrera le moment où chaque système a été mis à jour, mais surtout, la durée pendant laquelle chacun de ces 1 500 systèmes est resté sans correctifs, c'est-à-dire exposé à la vulnérabilité et en danger. 

C'est un exemple simple, avec une seule vulnérabilité et un seul correctif. Mais si la campagne inclut plusieurs correctifs avec plusieurs vulnérabilités, les informations peuvent être regroupées pour offrir une vue plus complète. Si plusieurs campagnes ont été exécutées au cours de la même période, les résultats peuvent se chevaucher ou se combiner pour permettre une évaluation des risques encore plus précise.   

Armé de ces données, vous pouvez montrer à un chargé d'audit l'état de sécurité réel de vos systèmes. Plus important, vous pouvez commencer à évaluer les résultats, et à améliorer l'efficacité de votre processus de gestion moderne des correctifs. À ce stade, c'est vous qui contrôlez le processus... et pas l'inverse.