Lorsqu'un éditeur publie un correctif, les pirates peuvent en tirer des indices sur la vulnérabilité qu'il corrige. C'est dans cet écart entre la publication d'un correctif et sa mise en place vérifiée sur l'ensemble de vos terminaux que le risque s'accumule.
Ce guide explique le fonctionnement technique des correctifs, présente les différents types de correctifs que vous rencontrerez et explique pourquoi la vérification est tout aussi importante que le déploiement.
Ce qu'un correctif logiciel fait réellement
Un correctif logiciel est un petit fragment de code qui modifie un programme ou un système d'exploitation existant. Les correctifs permettent de corriger des bogues, de remédier à des failles de sécurité ou d'améliorer les performances. Contrairement à une mise à jour logicielle complète ou à la sortie d'une nouvelle version, un correctif corrige des problèmes spécifiques sans remplacer l'ensemble de l'application.
Lorsqu'un éditeur découvre une faille, qu'il s'agisse d'une erreur de programmation provoquant des plantages ou de l'une des nombreuses vulnérabilités connues que des pirates pourraient exploiter, il développe un correctif pour y remédier. Ce correctif remplace ou modifie certains fichiers, certaines entrées du registre ou certains paramètres de configuration sur le système cible. C'est un peu comme si vous remplaçiez un seul composant défectueux dans une machine plutôt que de changer tout le moteur.
Les correctifs sont diffusés via les sites Web des éditeurs, les mises à jour automatiques telles que Windows Update, les boutiques d'applications ou les outils de gestion des correctifs d'entreprise. Une fois installé, le correctif modifie le comportement du logiciel en modifiant le code sous-jacent à l'origine du problème.
Voici ce qui distingue les correctifs des autres types de mises à jour :
- Portée : Les correctifs traitent de problèmes spécifiques et ponctuels plutôt que d'apporter des modifications générales aux fonctionnalités
- Taille : . Ils sont généralement de petite taille, souvent de quelques mégaoctets seulement.
- Urgence : Les correctifs de sécurité, en particulier, doivent être installés rapidement, car ils corrigent des failles que les pirates pourraient déjà connaître
Dès qu'un éditeur publie un correctif, la période de vulnérabilité commence pour les organisations qui ne l'ont pas encore appliqué. Les pirates informatiques et autres cybercriminels, y compris ceux appartenant à des réseaux organisés, surveillent souvent la publication des correctifs, car ceux-ci peuvent révéler des indices importants sur l'emplacement d'une vulnérabilité. C'est pourquoi le délai entre la mise à disposition d'un correctif et la vérification de son installation revêt une telle importance.
Maintenant que nous avons abordé les notions de base, la question suivante est la suivante : quels sont les différents types de correctifs, et en quoi diffèrent-ils ?
Une taxonomie précise des types de correctifs logiciels
Les correctifs logiciels ne présentent pas tous le même degré d'urgence ni le même profil de risque. Connaître ces différences vous permet d'organiser les déploiements en fonction de leur impact réel plutôt que de leur ordre d'arrivée.
| Type de correctif | Objectif | Urgence courante | Complexité de la restauration |
|---|---|---|---|
| Correctif de sécurité | Corrige une vulnérabilité spécifique | Élevé à critique | Généralement simple |
| Correctif | Permet de corriger un bug urgent en dehors des cycles de publication habituels | Élevé | Cela varie en fonction du champ d'application |
| Correction d'un bug | Corrige les erreurs fonctionnelles affectant les performances | Moyen | Généralement simple |
| Mise à jour cumulative | Regroupe plusieurs correctifs en un seul fichier | Moyen | Plus complexe |
| Service Pack | Regroupe des correctifs, des corrections de bogues et des améliorations de fonctionnalités | Inférieur | Complexe |
| Mise à jour des fonctionnalités | Ajoute de nouvelles fonctionnalités et de nouvelles possibilités | Inférieur | Variable |
Les correctifs de sécurité, parfois appelés « mises à jour de sécurité », corrigent les failles de sécurité susceptibles de permettre un accès non autorisé, le vol de données ou la compromission du système. Le système commun d'évaluation des vulnérabilités (CVSS) évalue la gravité sur une échelle allant de 0 à 10. Un score CVSS de 9,0 ou plus indique généralement une vulnérabilité critique qui doit être traitée en priorité et sans délai.
Les correctifs d'urgence sont des correctifs à intervention rapide publiés en dehors du calendrier de mise à jour habituel. Les éditeurs publient des correctifs lorsque le fait d'attendre la prochaine version prévue exposerait les systèmes à des menaces actives ou à des bogues critiques.
Les mises à jour cumulatives regroupent plusieurs correctifs dans un seul package. Les mises à jour mensuelles de Microsoft, publiées chaque « Patch Tuesday », prennent souvent cette forme. Bien qu'elles soient pratiques, les mises à jour cumulatives peuvent être plus difficiles à annuler, car elles regroupent de nombreuses modifications.
Conséquence pratique : Les correctifs de sécurité et ainsi que les correctifs d'urgence exigent une réaction immédiate, car ils comblent des failles de sécurité actives. Les mises à jour cumulatives et ainsi que les Service Packs regroupent plusieurs correctifs et améliorations, ce qui rend leur annulation plus difficile à effectuer proprement. Testez-les dans des environnements d'application représentatifs avant de les déployer à grande échelle.
Les mises à jour de fonctionnalités qui introduisent de nouvelles fonctionnalités présentent le niveau d'urgence le plus faible, mais le champ de compatibilité le plus imprévisible.
Maintenant que les différents types de correctifs ont été clarifiés, suivons le parcours d'un correctif, depuis sa publication par le fournisseur jusqu'à son installation sur le terminal.
Le cycle de vie d'un correctif logiciel, de sa publication par l'éditeur à son installation sur les terminaux
Entre le moment où un éditeur publie un correctif logiciel et celui où celui-ci est validé sur vos terminaux, de nombreux problèmes peuvent survenir. Chaque étape du cycle de vie représente un retard potentiel, et chaque retard prolonge le délai dont disposent les pirates pour agir.
1. Découverte : Le fournisseur identifie une faille de sécurité à la suite de tests internes, grâce à des chercheurs en sécurité ou à des signalements de clients. Pour des raisons de sécurité, cela implique souvent une coordination avec des organismes tels que la CISA ou l' u le NIST avant toute divulgation publique.
2. Développement : Les ingénieurs élaborent un correctif, le testent dans différentes configurations, puis le préparent en vue de sa distribution. Cette étape peut prendre plusieurs jours, voire plusieurs semaines, selon sa complexité.
3. Communiqué : Le fournisseur publie le correctif par les voies officielles. Dans le cas de logiciels largement utilisés, cette annonce peut alerter les pirates sur l'existence de cette vulnérabilité.
4. Détection : Votre organisation apprend que de nouveaux correctifs sont disponibles, tant pour les logiciels propriétaires que pour les applications tierces . Cela se fait par le biais d'avis des éditeurs, de notifications automatisées provenant de plateformes de gestion des correctifs, du catalogue « Known Exploited Vulnerabilities » (KEV) de la CISA, de la base de données nationale sur les vulnérabilités (NVD) ou d'outils d'analyse automatisés.
5. Hiérarchisation : Vous évaluez quels terminaux sont concernés et dans quelle mesure le déploiement du correctif est urgent, en fonction de la gravité de la vulnérabilité ( ), de la criticité des actifs () et du contexte métier.
6. Tests : Avant tout déploiement à grande échelle, vous testez les correctifs sur un échantillon représentatif de terminaux afin de détecter d'éventuels problèmes de compatibilité ou des comportements inattendus.
7. Déploiement : Le correctif est distribué aux terminaux ciblés via votre infrastructure de déploiement. Cela pourrait se faire par étapes, en commençant par les systèmes les moins critiques avant de passer aux environnements de production.
8. Vérification : Vous vous assurez que le correctif logiciel a bien été installé sur les terminaux ciblés, en vérifiant que le code ou la bibliothèque vulnérable de l'application a bien été remplacé, et pas seulement que la commande de déploiement a été exécutée.
C'est dans l'intervalle entre l'étape 3 (mise en service) et l'étape 8 (vérification) que les risques s'accumulent. Chaque jour qui s'écoule sans que les terminaux non mis à jour d' ne soient corrigés peut élargir la marge de manœuvre des attaquants.
Conseil : Comparez votre processus actuel de gestion des correctifs à ces étapes. Où les retards surviennent-ils généralement ? C'est là qu'il faut concentrer les efforts d'amélioration.
La période d'exposition et le risque qu'elle comporte
La fenêtre d'exposition correspond à la période comprise entre le moment où un fournisseur publie un correctif et celui où vous avez vérifié qu'il est bien installé sur tous les terminaux concernés. Ce n'est pas un concept abstrait. C'est un risque mesurable.
Les pirates n'attendent pas. Lorsqu'un correctif est publié, il contient souvent des informations détaillées sur la vulnérabilité qu'il corrige. Les chercheurs en sécurité comme les auteurs de menaces peuvent procéder à une ingénierie inverse du correctif afin de comprendre exactement comment exploiter les systèmes non mis à jour. Dans de nombreux cas, ils exploitent rapidement ces informations à des fins malveillantes, en déployant des logiciels malveillants conçus pour cibler la faille récemment révélée avant même que les organisations n’aient eu le temps de réagir.
Chaque jour passé dans cette fenêtre de vulnérabilité est un jour où les pirates peuvent exploiter les informations que votre propre fournisseur leur a fournies lors de la publication du correctif. Réfléchissez à ce qui se passe au cours d'une période d'exposition type :
- Jour 0 : L'éditeur publie un correctif et un avis de sécurité
- Jour 1–3 : Les pirates commencent à développer des exploits en s'appuyant sur les détails du correctif
- Jour 7 : Un code d'exploitation pourrait circuler sur des forums clandestins
- Jour 14 : Des outils d'attaque automatisés intégrant cette faille sont désormais disponibles
- Jour 30 et plus : Votre organisation achève enfin le déploiement
Pendant cette période, les terminaux non mis à jour de peuvent rester vulnérables. Plus la fenêtre reste ouverte longtemps, plus le risque de piratage est élevé. Les vulnérabilités des applications non corrigées constituent de plus en plus souvent des points d'entrée pour les pirates, ce qui accroît le risque de fuites de données pouvant entraîner des conséquences sur le plan réglementaire, financier et en termes de réputation.
La fenêtre d'exposition ne se résume toutefois pas à la vitesse. C'est aussi une question d'exhaustivité. Si vous appliquez rapidement des correctifs à 95 % des terminaux concernés, mais que vous en oubliez 5 %, ces systèmes non pris en compte restent exposés indéfiniment.
Dans une grande entreprise, 5 % pourrait correspondre à des milliers de terminaux vulnérables.
Pour mettre fin à cette vulnérabilité, deux conditions sont nécessaires : déployer rapidement les correctifs logiciels et vérifier qu’ils ont bien été installés sur chaque terminal concerné. La plupart des organisations s'en sortent plutôt bien sur ce premier point. Le deuxième cas est celui où les programmes cessent de fonctionner sans que l'on s'en aperçoive.
Pourquoi le déploiement de correctifs logiciels échoue souvent à grande échelle
Déployer un correctif logiciel sur des milliers de terminaux peut sembler une tâche mécanique. Dans la pratique, c'est là que se creusent discrètement des lacunes de couverture, que se manifestent les failles de sécurité et que les vulnérabilités non corrigées des applications persistent le plus longtemps.
Les points de terminaison ne sont pas toujours accessibles. Les ordinateurs portables se déplacent. Les télétravailleurs se connectent de manière intermittente. Il se peut que les serveurs situés dans des segments de réseau isolés ne reçoivent pas les commandes de déploiement. Si un terminal n'est pas en ligne et connecté au moment où le correctif est déployé, il ne sera pas mis à jour.
Les dépendances sont source de conflits. Un correctif logiciel destiné à une application peut entraîner le dysfonctionnement d'une autre application qui dépend d'une version spécifique ou d'une bibliothèque partagée. Sans avoir une vue d'ensemble des applications installées et de la manière dont elles interagissent, vous ne vous rendrez compte qu'il y a un problème que lorsque quelque chose cessera de fonctionner.
Les environnements hétérogènes accroissent la complexité. Les entreprises exploitent simultanément plusieurs versions d'applications, plusieurs piles de dépendances et plusieurs configurations de systèmes d'exploitation. Un correctif logiciel validé pour une version donnée d'une application peut se comporter différemment avec une autre version. Sans savoir ce qui est réellement installé, vous procédez à un déploiement à l'aveuglette.
Les déclarations des personnes concernées ne sont pas fiables. De nombreux outils de mise à jour indiquent que l'opération a réussi en se basant uniquement sur l'exécution de la commande de déploiement, et non sur le fait que le correctif ait effectivement été installé correctement. Un terminal peut indiquer qu'il est « corrigé » alors que la vulnérabilité sous-jacente persiste.
Les créneaux de maintenance sont limités. Les applications qui ne peuvent pas être redémarrées pendant les heures de travail en raison d'un risque d'interruption de service limitent les créneaux disponibles pour l'application des correctifs. Lorsque ces fenêtres se ferment avant la fin du déploiement, les correctifs logiciels sont mis en file d'attente au lieu d'être appliqués. Le retard accumulé s'aggrave avec le temps, ce qui allonge la période d'exposition pour chaque correctif qui n'a pas été retenu et oblige les équipes de support informatique à se consacrer à des opérations de nettoyage réactives plutôt qu'à un déploiement proactif.
Vérifier qu'un correctif a bien été appliqué
Le déploiement n'est pas la ligne d'arrivée. La vérification consiste à...
Un correctif logiciel déployé sans que son installation ait été vérifiée constitue une question en suspens, et non une vulnérabilité résolue. C'est précisément dans l'écart entre « nous l'avons déployé » et « nous l'avons validé » que les organisations surestiment systématiquement leur taux de couverture réel en matière de correctifs.
La vérification permet de répondre à trois questions :
- Le correctif a-t-il bien été déployé sur le terminal ? Des problèmes de réseau, des appareils hors ligne ou des erreurs de déploiement peuvent empêcher la livraison.
- L'installation des correctifs sur le terminal s'est-elle déroulée avec succès ? Un espace disque insuffisant, des erreurs d'autorisation ou des conflits peuvent entraîner des échecs d'installation, même lorsque le correctif a bien été fourni.
- Cette vulnérabilité a-t-elle réellement été corrigée ? Dans certains cas, un correctif peut s'installer sans pour autant résoudre entièrement le problème, en raison d'exigences de configuration ou de redémarrages en attente.
De nombreuses organisations se fient aux rapports de réussite de leur outil de mise à jour. Mais ces rapports font souvent état de tentatives de déploiement, et non de résultats vérifiés. L'outil indique qu'il a déployé le correctif. Cela ne permet pas de confirmer que le terminal a bien reçu et installé les correctifs, ni que la vulnérabilité sous-jacente a été corrigée.
Pour que la vérification soit efficace, il est nécessaire d'interroger directement les terminaux afin de confirmer leur état actuel. Quelle version de l'application est installée ? La bibliothèque ou le fichier vulnérable est-il toujours présent ? L'application a-t-elle été redémarrée pour activer le code corrigé ?
C'est là que la visibilité en temps réel sur les terminaux proposée par revêt une importance cruciale. Les analyses ponctuelles ne prennent pas en compte les terminaux qui étaient hors ligne au moment de l'analyse.
Ils ne prennent pas non plus en compte les modifications survenues après la fin de l'analyse. Une visibilité en continu vous offre une vue d'ensemble actualisée et précise de l'état des correctifs dans l'ensemble de votre environnement.
Conseil : Après tout déploiement de correctif critique, interrogez directement les terminaux concernés afin de vérifier que le composant vulnérable n'est plus présent. Ne vous fiez pas uniquement aux journaux de déploiement.
La vérification marque la fin du cycle de vie d'un correctif logiciel donné. Mais aucun correctif n'est déployé isolément, et c'est le programme chargé de faire passer les correctifs de la version du fournisseur à l'état « vérifié » sur les terminaux qui détermine si votre couverture reste efficace à grande échelle.
La place des correctifs logiciels dans la gestion des correctifs
Il est essentiel de comprendre ce qu'est un correctif logiciel et comment il fonctionne. Dans un contexte d'entreprise, cependant, les correctifs individuels ne se déploient pas d'eux-mêmes. Elles suivent un processus : détection, hiérarchisation, test, déploiement et vérification.
Ce programme s'appelle la gestion des correctifs, et son efficacité détermine la rapidité avec laquelle votre organisation comble la fenêtre de vulnérabilité après la publication d'un correctif logiciel. Pour en savoir plus sur la manière dont les programmes de gestion des correctifs sont structurés et évalués, consultez notre guide « » consacré à la gestion des correctifs :.
Un correctif logiciel est l'élément concerné. La gestion des correctifs est le système qui assure le parcours de cet élément, depuis sa publication par le fournisseur jusqu'à son installation vérifiée sur des centaines de milliers de terminaux potentiels.
Cette distinction est importante, car de nombreux échecs de mise à jour ne sont pas liés au correctif lui-même. Elles concernent le programme :
- Lacunes en matière de découverte : Vous ignorez qu'un correctif existe ou quels terminaux en ont besoin
- Erreurs de hiérarchisation : Les correctifs critiques sont mis en attente derrière les mises à jour de routine
- Goulets d'étranglement liés aux tests : Le déploiement est retardé car les équipes doivent valider manuellement la compatibilité
- Contraintes de déploiement : Les correctifs ne parviennent pas à tous les terminaux concernés
- Lacunes en matière de vérification : Vous ne savez pas avec certitude si les correctifs ont bien été installés
Chacun de ces éléments constitue un défi au niveau du programme, et non un problème au niveau du correctif.
Le choix d'un logiciel de gestion des correctifs adapté constitue souvent la première étape pour combler ces lacunes de manière systématique, en offrant aux équipes la visibilité, l'automatisation et les rapports dont elles ont besoin pour fonctionner à grande échelle.
Pour les organisations qui gèrent un parc important et dispersé de terminaux, les défis liés à la gestion globale du programme dépassent souvent de loin la complexité technique de n'importe quel correctif pris isolément.
La visibilité en temps réel, le déploiement vérifié, des politiques claires en matière de correctifs d' et des workflows automatisés de gestion des correctifs deviennent des impératifs opérationnels plutôt que de simples atouts, surtout lorsque l'alternative consiste à suivre manuellement l'état des correctifs sur des milliers de terminaux.
Comment Tanium facilite la gestion des correctifs logiciels pour les entreprises
Les défis décrits ci-dessus, notamment une visibilité obsolète, des échecs de déploiement et des mesures correctives non vérifiées, constituent des problèmes au niveau du programme que les correctifs individuels ne peuvent pas résoudre.
La plateforme informatique autonome de Tanium, , s'attaque à ces problèmes à la source : elle interroge directement les terminaux pour connaître l'état des correctifs en temps réel, organise les déploiements en fonction du risque réel à l'aide des scores de confiance d' et des données sur les vulnérabilités, et vérifie que l'installation a bien abouti plutôt que de se fier uniquement aux journaux de déploiement.
Pour les organisations qui gèrent un parc important et dispersé de terminaux, cette combinaison est conçue pour contribuer à combler plus rapidement l'écart entre la publication d'un correctif et la mise en œuvre vérifiée de la correction que ne le permettent généralement les approches basées sur l'analyse, sans nécessiter d'infrastructure secondaire.
La visibilité en temps réel comme fondement
La raison la plus courante pour laquelle les programmes de mise à jour échouent à grande échelle n'est pas un manque d'efforts. C'est le manque de données précises et à jour. La plateforme informatique autonome de Tanium répond directement à ce besoin en offrant une visibilité en temps réel sur l'état des correctifs des s des terminaux sur les appareils Windows, Linux et macOS.
Plutôt que de se fier à des données d'analyse pouvant dater de plusieurs heures, voire de plusieurs jours, les entreprises qui utilisent Tanium peuvent interroger directement les terminaux afin de connaître leur état actuel. Lorsqu'un correctif critique est publié, les équipes informatiques peuvent rapidement identifier les terminaux susceptibles d'être concernés, ceux qui semblent déjà avoir reçu le correctif et ceux pour lesquels il pourrait être nécessaire de reporter l'application, sans attendre la fin d'un cycle d'analyse planifié.
La plateforme informatique autonome de Tanium est conçue pour garantir une visibilité sur l'ensemble des environnements distribués, y compris les terminaux situés dans les succursales, les sites distants et les sites géographiquement dispersés, le tout à partir d'une seule instance Tanium, afin de réduire la dépendance vis-à-vis des serveurs relais, de bases de données ou de distribution secondaires.
L'architecture de la plateforme est conçue pour prendre en charge des environnements à grande échelle, y compris des déploiements comptant des centaines de milliers de terminaux. Cette échelle est importante car les lacunes en matière de correctifs sont rarement uniformes : les points d'extrémité les plus difficiles à atteindre sont souvent ceux qui risquent le plus de ne pas être corrigés.
Hiérarchisation des priorités en fonction des risques avant le déploiement
Tous les correctifs logiciels ne justifient pas le même degré d'urgence. Un déploiement sans hiérarchisation des priorités signifie que vos équipes risquent tout autant de se consacrer à des mises à jour d'applications à faible risque que de combler des failles de sécurité actives.
La plateforme informatique autonome de Tanium permet aux organisations de combiner les données relatives aux vulnérabilités avec les scores de criticité et de fiabilité des terminaux afin de hiérarchiser l'application des correctifs et de se concentrer en priorité sur les failles à haut risque.
Les scores de confiance sont générés grâce à une analyse en temps réel, basée sur l'intelligence cloud, des tendances, notamment les taux de réussite des installations, la fréquence des plantages et l'impact sur les performances. Ils fournissent ainsi aux équipes des données exploitables qui leur permettent de prendre des décisions éclairées concernant l'ordre de déploiement avant qu'un correctif ne soit déployé à grande échelle.
La plateforme permet également aux équipes de s'appuyer sur les indicateurs de risque et le contexte métier pour donner la priorité aux correctifs qui réduisent le plus rapidement possible l'exposition aux risques. Cette approche intègre directement la gestion des correctifs au processus plus large de gestion des vulnérabilités , plutôt que de la considérer comme une tâche isolée relevant des opérations informatiques.
Les équipes peuvent identifier les vulnérabilités pouvant faire l'objet d'un correctif ainsi que les correctifs non programmés les plus importants, ce qui contribue à rationaliser la communication entre les équipes de sécurité et d'exploitation et garantit que les correctifs sont classés par ordre de priorité et appliqués efficacement.
Déploiement contrôlé via des phases de déploiement par anneaux
L'une des fonctionnalités les plus importantes sur le plan opérationnel de la plateforme informatique autonome de Tanium réside dans sa prise en charge d'un déploiement progressif, par anneaux, de type « ». Plutôt que de déployer un correctif sur tous les terminaux simultanément, les entreprises peuvent commencer par un petit groupe de terminaux, valider les résultats obtenus et s'appuyer sur les retours d'expérience de la communauté des clients Tanium pour étendre le déploiement en toute confiance, à mesure que chaque étape répond aux critères de réussite.
Cette approche s'avère particulièrement pertinente dans le cadre de la gestion des vulnérabilités « zero-day » ( ), où la rapidité est essentielle, mais où le risque qu'un correctif défaillant entraîne des perturbations à grande échelle est également élevé.
Les déploiements de correctifs peuvent être soumis à des processus de validation et programmés pendant des fenêtres de maintenance afin de minimiser l'impact sur l'activité. Les équipes peuvent configurer le calendrier de déploiement des correctifs et les workflows afin de les adapter au mode de fonctionnement actuel de leur organisation, en déterminant quels terminaux reçoivent les correctifs et dans quel ordre, ainsi que les conditions dans lesquelles un déploiement passe à la phase suivante.
Les guides d'automatisation créés avec Tanium Automate permettent de gérer en temps réel les workflows de correctifs logiciels sur de vastes parcs de terminaux, en regroupant les étapes de détection, de séquencement du déploiement et de vérification au sein d'un processus unique et reproductible, plutôt que sous la forme d'une série de transferts manuels entre différents outils.
Validation et remédiation en boucle fermée
Le déploiement n'est pas la même chose que la correction. La plateforme informatique autonome de Tanium assure le suivi en temps réel de la réussite des correctifs, des exceptions et des indicateurs de performance, et fournit des rapports détaillés afin de faciliter l'amélioration future des processus en matière de ciblage, de calendrier et d'enchaînement.
À l'issue d'un déploiement, les organisations peuvent vérifier l'état des correctifs et identifier les systèmes qui n'ont pas été mis à jour, en faisant la distinction entre les terminaux sur lesquels le correctif a été transmis mais n'a pas été installé, et ceux qui étaient tout simplement inaccessibles pendant la fenêtre de déploiement.
La solution « Tanium Comply » va plus loin en vérifiant si les vulnérabilités logicielles sont réellement corrigées après l'application d'un correctif, et pas seulement si le déploiement a bien été mené à bien. Les équipes peuvent passer directement de l'identification d'une vulnérabilité logicielle non corrigée au lancement et au suivi des mesures correctives au sein d'une même plateforme, sans avoir à changer d'outil ni à harmoniser les données provenant de systèmes distincts.
Ce cycle « identification – correction – validation » signifie que la gestion des correctifs ne s'arrête pas au déploiement ; elle ne s'achève que lorsque la vulnérabilité est validée comme ayant été corrigée.
Rapports de conformité et préparation aux audits
Il est de plus en plus important de démontrer que les correctifs logiciels ont bien été appliqués, et ce de manière correcte, dans le cadre des programmes d'audit réglementaires de l' , notamment ceux liés à des référentiels tels que l'HIPAA et la norme PCI. Tanium est conçu pour répondre à ces besoins en matière de documentation.
Tanium Patch résume l'état de déploiement de chaque correctif logiciel, en fournissant un retour d'information immédiat sur les réussites et les échecs nécessitant une correction. Lorsque les auditeurs demandent quels correctifs logiciels ont été appliqués et à quelle date, Tanium fournit aux équipes l'historique des déploiements, l'état des redémarrages et la confirmation de la correction nécessaires pour répondre à cette question en s'appuyant sur des données plutôt que sur des estimations.
Des lacunes en matière de conformité à une couverture des correctifs de 90 % : Honeywell
, filiale de Honeywell, était confrontée à de faibles taux d'application des correctifs, ce qui exposait l'entreprise à des risques liés aux ransomwares et à d'autres cyberattaques. Après avoir déployé Tanium, Honeywell a dépassé les 90 % de conformité en matière de correctifs pendant trois mois consécutifs, un niveau de service que l'entreprise n'avait jusqu'alors pas réussi à atteindre.
Tanium a également permis à Honeywell de regrouper, voire dans certains cas de supprimer, d'autres outils de gestion des correctifs, et a fourni une vue d'ensemble unique pour les rapports de conformité destinés à la direction et aux équipes opérationnelles.
[Lire l'étude de cas Honeywell]
«Avant d’utiliser Tanium, notre taux de conformité en matière de correctifs était faible. » Grâce à Tanium, nous avons désormais dépassé le seuil de 90 % de conformité aux correctifs pendant trois mois d'affilée. C'est important. »M. Manish Chopra, directeur informatique chez Honeywell
Le fonctionnement d'un correctif logiciel est simple. La réalité opérationnelle liée à son déploiement sur des milliers de terminaux est tout autre. Vous trouverez ci-dessous les réponses aux questions les plus fréquemment posées.
FAQ sur les correctifs logiciels
Quelle est la différence entre un correctif logiciel et une mise à jour ?
Un correctif est une solution ciblée destinée à résoudre un problème spécifique, généralement un bug ou une faille de sécurité dans un logiciel. Le terme « mise à jour » est un concept plus large qui peut englober les correctifs, les ajouts de fonctionnalités, les améliorations de performances et d'autres modifications. Tous les correctifs sont des mises à jour, mais toutes les mises à jour ne sont pas des correctifs.
Dans quel délai les pirates passent-ils à l'action après la publication d'un correctif logiciel ?
Plus rapidement que la plupart des organisations ne peuvent le mettre en œuvre. Lorsqu'un éditeur publie un correctif logiciel, ce dernier peut révéler des détails sur la faille sous-jacente, offrant ainsi aux pirates une feuille de route pour exploiter les systèmes non mis à jour. Dans le cas de failles logicielles très médiatisées, des codes d'exploitation peuvent apparaître quelques heures seulement après la publication du correctif.
La vulnérabilité 2021 Log4j , une faille dans une bibliothèque de journalisation Java largement utilisée, a fait l'objet de plus de 200 000 tentatives d'attaque dans les 24 heures qui ont suivi sa divulgation, selon Check Point Research. C'est pourquoi le délai entre la publication d'un correctif logiciel et sa mise en place vérifiée constitue un risque quantifiable, et non pas simplement un inconvénient opérationnel.
Est-il possible d'annuler l'application d'un correctif logiciel si un problème survient ?
Cela dépend de la manière dont le correctif a été packagé. La plupart des correctifs logiciels autonomes peuvent être désinstallés via l'application ou votre outil de gestion des correctifs, ce qui permet de rétablir la version précédente. Les mises à jour cumulatives sont plus difficiles à annuler proprement, car annuler une modification implique d'en annuler plusieurs.
Avant de déployer un correctif logiciel à grande échelle, testez-le sur un échantillon représentatif de terminaux et assurez-vous de disposer d'une solution de repli au cas où le correctif entraînerait des problèmes de compatibilité ou un comportement inattendu des applications.
Pourquoi certains correctifs logiciels nécessitent-ils un redémarrage ?
Les correctifs logiciels qui modifient des fichiers d'application ou des bibliothèques partagées actuellement utilisés ne peuvent pas être installés tant que ces fichiers sont actifs. Un redémarrage, ou dans certains cas un redémarrage de l'application, libère ces verrous et permet aux fichiers corrigés de prendre effet. La nécessité d'un redémarrage dépend de ce que modifie le correctif logiciel et de la possibilité de redémarrer l'application concernée en toute sécurité sans avoir à redémarrer l'ensemble du système.
Que se passe-t-il si un terminal ne bénéficie pas du déploiement d'un correctif logiciel ?
Le terminal reste exposé à la faille logicielle que ce correctif était censé corriger. Un déploiement manqué ne constitue pas une lacune mineure. Cela signifie que la faille de code sous-jacente est toujours présente et peut être exploitée. Pour identifier les terminaux non couverts, il faut interroger directement ces derniers afin de connaître la version actuelle du logiciel et l'état des correctifs, sans se fier aux journaux de déploiement qui se contentent de confirmer que le correctif a bien été déployé, sans garantir qu'il ait été correctement installé.
De nombreuses solutions modernes de gestion des correctifs sont conçues pour détecter les déploiements manqués, effectuer automatiquement de nouvelles tentatives et mettre en évidence les lacunes, afin que moins de terminaux restent sans correctif pendant de longues périodes.
Une gestion efficace des correctifs logiciels commence par la compréhension de ce que vous déployez et des raisons pour lesquelles vous le faites, jusqu’aux modifications spécifiques apportées au code par un correctif et aux conséquences en cas d’installation incorrecte. À partir de là, il s’agit de réduire la fenêtre d’exposition aussi rapidement et complètement que possible, puis de vérifier que vous y êtes bien parvenu.
Tanium offre une visibilité en temps réel sur l’état des correctifs logiciels au sein des parcs de terminaux dispersés, permettant ainsi aux équipes d’identifier les lacunes, de procéder au déploiement en toute confiance et de confirmer que les mesures correctives ont bien été mises en œuvre, plutôt que de se contenter de le supposer. Prenez rendez-vous pour une démonstration à l'adresse afin de découvrir comment cela fonctionne à l'échelle de l'entreprise.
