Ivanti Blog: Publié par

Processus modernes et efficaces de gestion des correctifs et meilleures pratiques

Thu, 01 Aug 2024 06:01:00 Z

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.

Comment l'implémentation de la gestion des correctifs basée sur les risques permet de prioriser les exploitations actives

Tue, 20 Jun 2023 15:01:46 Z

Même s’ils constituent un point de départ, les scores de gravité fournis par les éditeurs sont souvent insuffisants pour guider des décisions critiques. On résiste toujours au changement, surtout quand on pense que les processus en place sont efficaces et adaptés. C’est précisément ce que pensent de nombreuses entreprises à propos de leur gestion des logiciels — jusqu’au jour où une faille de sécurité ou un incident majeur vient tout remettre en cause.

En réalité, la plupart des stratégies de gestion des correctifs reposent sur des suppositions ou des lignes directrices génériques, plutôt que sur des données concrètes liées aux vulnérabilités réellement exploitées. Face à un paysage de menaces en constante évolution, cette approche n’est plus suffisante. La gestion des correctifs basée sur les risques offre une alternative plus pertinente.

Cet article explique :

Pourquoi il est temps d'abandonner la priorisation classique.
Ce qu'est la gestion des correctifs basée sur les risques (RBPM).
Pourquoi c'est le moment idéal pour adopter la gestion des correctifs basée sur les risques.

Les limites de la priorisation traditionnelle

Les mises à jour logicielles — qu’il s’agisse de correctifs de sécurité, de résolutions de bugs ou d’améliorations fonctionnelles — existent depuis les débuts de l’informatique. Pour aider leurs clients à distinguer les plus urgentes, les éditeurs attribuent généralement un score de gravité ou de criticité à chaque mise à jour.

Le problème ? Ces notations ne sont basées sur aucune norme sectorielle universelle. Chaque fournisseur applique sa propre échelle, ses propres critères, ce qui rend la comparaison et la hiérarchisation des correctifs particulièrement floues. Pire encore, ces scores sont rarement révisés en fonction du contexte de menace réel — notamment lorsqu’une vulnérabilité commence à être activement exploitée.

Non-prise en compte d'une vulnérabilité activement exploitée

Même si c'est mieux que rien, les scores de gravité des fournisseurs sont souvent inadaptés. Prenons l'exemple de la vulnérabilité Follina (CVE-2022-30190), publiée en mai 2022. Cette vulnérabilité de MSDT (Microsoft Windows Support Diagnostic Tool - Outil de diagnostic du Support Microsoft) illustre bien cette faille du système.

Follina permettait l'exécution de code à distance. Cette faille a été activement exploitée pendant plusieurs mois, notamment pour diffuser le ransomware Bisamware, avant que Microsoft ne publie une mise à jour corrective. Pourtant, Microsoft a initialement attribué à Follina un score CVSS v3 de 7,8, avec un niveau de gravité jugé simplement Important, et non Critique. Conséquence : les entreprises qui se contentaient de déployer uniquement les correctifs qualifiés de critiques par leurs fournisseurs ont totalement ignoré cette vulnérabilité… alors même qu’elle était déjà utilisée dans des attaques.

Et ce n’est pas tout : le score CVSS de Follina est resté à 7,8 même après la confirmation de son exploitation active. Une incohérence qui a laissé de nombreuses organisations dangereusement exposées, faute d’une prise en compte dynamique des menaces réelles.

Affichage de l'intelligence des menaces de ransomware associée à CVE-2022-30190 dans Ivanti Neurons for VULN KB

Les lacunes de la notation CVSS

Les scores de gravité sont « augmentés » des scores CVSS de FIRST. Chaque CVE reçoit un score CVSS, comme celui de 7,8 attribué à CVE-2022-30190 dans l'exemple ci-dessus.

L'un des principaux objectifs du calcul du score CVSS réel est de garantir la normalisation, pour que toutes les CVE soient notées de façon cohérente et puissent être correctement comparées. Plus le score CVSS d'une vulnérabilité et du correctif associé est élevé, plus il est essentiel de déployer ce correctif dans la plupart des environnements.

Pour les mises à jour logicielles qui couvrent plusieurs CVE, la priorisation tient généralement compte du score CVSS le plus élevé. Mais cette valeur est-elle exacte ?

Dans un article récent, l'analyse des scores CVSS a montré qu'il existe un écart pour près de 20 % des scores CVSS (25 000). Cette analyse reposait sur une comparaison entre les scores enregistrés dans la base NVD (National Vulnerability Database - Base nationale des vulnérabilités) du NIST et ceux transmis par les fournisseurs eux-mêmes.

Comprendre les incohérences des scores de gravité fournisseur

Il est essentiel de comprendre que les fournisseurs utilisent généralement leur propre terminologie pour évaluer la gravité des failles. Des termes comme « Critique » ou « Important » sont fréquemment employés, mais ces classifications présentent des limites lorsqu'on souhaite comparer les correctifs de plusieurs fournisseurs. En effet, chaque fournisseur utilisant sa propre terminologie, il est difficile de comparer la gravité des correctifs.

De même, la gravité fournisseur n'est pas toujours un indicateur positif. De nombreuses vulnérabilités Zero Day sont seulement classées « Important » par Microsoft alors qu'elles ont un score CVSS élevé. Ainsi, s’appuyer uniquement sur la gravité définie par le fournisseur ou sur le score CVSS pour prioriser les correctifs revient à prendre des décisions basées sur des hypothèses et des recommandations génériques, ce qui peut rendre votre environnement particulièrement vulnérable.

Pourquoi prioriser les exploitations actives au lieu d'utiliser une autre méthode ?

D'après la CISA (US Cybersecurity and Infrastructure Security Agency), une vulnérabilité activement exploitée est une vulnérabilité « pour laquelle on a une preuve fiable de l'exécution d'un code malveillant par un acteur sur un système sans la permission du propriétaire de ce système ». En d'autres termes, une vulnérabilité activement exploitée est une vulnérabilité ayant été utilisée par un pirate pour réaliser une cyberattaque.

Ainsi, pour limiter les risques d'une attaque, vous devez traiter en priorité les vulnérabilités activement exploitées. C'est une bonne nouvelle, car la majorité des vulnérabilités n'est pas activement exploitée, et ne présente donc pas de danger pour votre entreprise. La gestion des correctifs basée sur les risques vous permet d'identifier celles qui ont été exploitées.

Qu'est-ce que le RBPM (Gestion des correctifs basée sur les risques) ?

Voici la définition qu'en donne notre document « Le guide ultime pour la gestion des correctifs basée sur les risques » :

« La gestion des correctifs basée sur les risques va au-delà des scores CVSS (Common Vulnerability Scoring Systems) et scanners habituels, afin d’identifier et de qualifier les vulnérabilités spécifiques les plus dangereuses pour les périphériques, les données et les utilisateurs d’une entreprise.

Cette extension de la gestion des vulnérabilités basée sur les risques permet d’intégrer un contexte de risques réels dans le processus de gestion des correctifs grâce aux mises à jour prenant en compte les vulnérabilités exploitées connues considérées comme cruciales pour la sécurité d’une entreprise ».

Comment mon entreprise peut-elle intégrer la gestion des correctifs basée sur les risques ?

Pour les entreprises qui souhaitent adopter une approche basée sur les risques pour la gestion des correctifs, le catalogue KEV (Known Exploited Vulnerabilities - Vulnérabilités exploitées connues) de la CISA constitue un bon point de départ. La CISA a fait un grand pas en avant pour faciliter la priorisation des vulnérabilités lorsqu'elle a mis en place la directive opérationnelle contraignante BOD 22-01 et son catalogue KEV.

Lors de sa publication initiale, ce catalogue recensait environ 200 vulnérabilités activement exploitées. Depuis, il s'est considérablement enrichi et compte désormais 900 entrées.

La CISA établit sa liste en sachant que les vulnérabilités qu'elle contient sont exploitées sur le terrain dans des attaques réelles. Cependant, cette liste a ses défauts, car elle exclut actuellement 131 vulnérabilités associées aux ransomwares.

Le catalogue KEV de la CISA est-il la seule ressource disponible pour la gestion des correctifs basée sur les risques ?

Les entreprises dont les pratiques de gestion des correctifs basée sur les risques sont plus matures ont recours à des méthodologies avancées d’évaluation des risques, à la place ou en complément des scores CVSS. Ces méthodologies affectent un score à chaque vulnérabilité identifiée dans l'environnement de l'entreprise, ce qui permet à cette dernière d'étendre son approche basée sur les risques au-delà du CISA KEV.

De nombreux fournisseurs du marché de la gestion des vulnérabilités basée sur les risques ont développé des méthodologies de notation exclusives, dont les scores expriment le risque réel que présente chaque vulnérabilité. Pour ce faire, ils fournissent des évaluations de risque dynamiques qui accordent une pondération supplémentaire aux vulnérabilités activement exploitées.

Par exemple, le système Ivanti Vulnerability Risk Rating (VRR - Score de risque de la vulnérabilité) attribue à Follina le score 10, qui représente la dangerosité de cette vulnérabilité de façon bien plus réaliste que son score CVSS de 7,8.

Différence entre les scores VRR et CVSS v3, et les niveaux de gravité de CVE-2022-30190, telle que présentée dans Ivanti Neurons for VULN KB

Pourquoi c'est le moment est idéal pour adopter la gestion des correctifs basée sur les risques

Si vous avez l'impression d'accumuler du retard dans les mises à jour système ou si vous êtes dépassé par la prolifération de nouveaux systèmes et applications dans votre entreprise, il est temps de prendre les choses en main. La gestion des correctifs basée sur les risques pourrait bien être la solution dont vous avez besoin.

Même si vous pensez avoir mis en place un programme solide basé sur les niveaux de gravité et les scores CVSS, il est temps de revoir votre stratégie. Dépassez votre résistance au changement et lancez-vous dans de nouveaux processus avant que votre entreprise ne soit dévastée par une fuite de données due à une vulnérabilité exploitée.

Commencez par utiliser le CISA KEV pour prioriser vos mises à jour, et par envisager l'achat d'une solution de gestion des vulnérabilités et des correctifs basée sur les risques en budgétant son coût. Une fois les bons outils en place, vous pourrez rapidement identifier les systèmes les plus à risque et les traiter en priorité, puis descendre dans la liste des priorités.

Prêt à franchir le pas ? Plongez-vous dans cet eBook. Vous y trouverez des conseils uniques pour implémenter un programme de gestion des correctifs basée sur les risques.

Patch Tuesday Ivanti - Mars 2020

Thu, 19 Mar 2020 09:42:34 Z

Microsoft résout 115 CVE (vulnérabilités et faiblesses communes), dont 26 sont marquées Critique. On ne compte, ce mois-ci, aucune vulnérabilité à divulgation publique ou dont l’exploitation a d’ores et déjà été constatée. Les mises à jour du mois portent sur Windows, Edge (HTML et Chromium), ChakraCore, Internet Explorer, Microsoft Exchange Server, Microsoft Office, les services et applis Web Office, Azure DevOps, Windows Defender, Visual Studio, le logiciel Open Source, Azure et Microsoft Dynamics. La majorité des CVE du mois concernent l'OS Windows (79 CVE) ou les navigateurs (18 CVE).

Microsoft publie des mises à jour de pile de maintenance pour la plupart des versions de l'OS Windows. Ce mois-ci, les seules exceptions sont Windows 10 version 1703, Server 2008 et Windows 7\2008 R2.

Microsoft annonce qu'il existe une vulnérabilité dans le Gestionnaire de connexions aux services Bureau à distance (CVE-2020-0765), mais affirme qu'aucune mise à jour ne sera publiée pour corriger ce problème. Ce produit est devenu obsolète. Leur conseil : soyez prudent si vous continuez à utiliser l'outil Gestion de connexions aux services Bureau à distance. Mais Microsoft recommande de passer aux clients Bureau à distance pris en charge.

Microsoft résout ce mois-ci plusieurs vulnérabilités de divulgation d'informations portant sur l'OS Windows, dans des composants comme GDI, le composant graphique Windows Graphics, Win32k, le service de programme d'installation des modules Windows, la spécification d'interface de pilote réseau Windows, et le service Expériences des utilisateurs connectés et télémétrie. Ces vulnérabilités pourraient permettre à un pirate de lire dans le système de fichiers, la mémoire non initialisée ou même les composants mémoire dans l'espace de noyau (kernel) à partir d'un processus en mode Utilisateur. Certaines de ces vulnérabilités pourraient aussi permettre à un pirate de collecter des informations servant à prédire l'adressage mémoire.

Une vulnérabilité d'exécution de code à distance Microsoft Word (CVE-2020-0852) pourrait être exploitée via le volet Aperçu d'Outlook, ce qui en fait une cible plus intéressante pour les pirates.

Mozilla publie ce jour des mises à jour pour FireFox et FireFox ESR, qui résolvent un total de 12 CVE uniques. Toutes sont marquées Élevé dans la classification Mozilla, c'est-à-dire un niveau au-dessous de Critique, qui est le niveau le plus grave. Les pires vulnérabilités pourraient permettre l'exécution d'un code arbitraire.

Ivanti vous recommande de vous concentrer sur les mises à jour de l'OS Windows et des navigateurs, ainsi que sur Office. Ce sont les principales priorités du mois.