Lorsqu’un fournisseur publie un correctif, les attaquants peuvent obtenir des indices sur la vulnérabilité qu’il corrige. Cet écart entre la publication des correctifs et l’installation vérifiée sur vos endpoints est l’endroit où le risque s’accumule.
Ce guide explique comment les correctifs fonctionnent techniquement, les différents types de correctifs que vous rencontrerez et pourquoi la vérification est aussi importante que le déploiement.
Ce qu’un correctif logiciel fait réellement
Un correctif logiciel est un petit code qui modifie un programme ou un système d’exploitation existant. Les correctifs corrigent les bugs, traitent les vulnérabilités de sécurité ou améliorent les performances. Contrairement à une mise à jour logicielle complète ou à une nouvelle version, un correctif cible des problèmes spécifiques sans remplacer l’ensemble de l’application.
Lorsqu’un fournisseur découvre un défaut, qu’il s’agisse d’une erreur de codage qui provoque des plantages ou d’une des nombreuses vulnérabilités connues que les attaquants pourraient exploiter, il développe un correctif pour le corriger. Le correctif écrase ou modifie des fichiers, des entrées de registre ou des paramètres de configuration spécifiques sur le système cible. Pensez-y comme remplacer un seul composant défectueux dans une machine plutôt que d’échanger l’ensemble du moteur.
Les correctifs sont distribués via les sites web des fournisseurs, les mises à jour automatiques telles que Windows Update, les magasins 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 qui a causé le problème.
Voici ce qui distingue les correctifs des autres types de mise à jour :
- Champ d’application : les correctifs traitent des problèmes spécifiques et étroits plutôt que d’introduire des changements généraux de fonctionnalité
- Taille : ils sont généralement petits, souvent seulement quelques mégaoctets
- Urgence : les correctifs de sécurité en particulier sont sensibles au temps car ils ferment les vulnérabilités que les attaquants peuvent déjà connaître
Une fois qu’un fournisseur publie un correctif, la fenêtre d’exposition commence pour les organisations qui ne l’ont pas encore appliqué. Les pirates informatiques et autres attaquants, y compris les cybercriminels organisés, surveillent souvent les versions de correctifs, car ils peuvent révéler des indices importants sur l’emplacement d’une vulnérabilité. C’est pourquoi le délai entre la disponibilité des correctifs et l’installation vérifiée est si important.
Avec les bases couvertes, la question suivante est : quels types de correctifs existent et en quoi diffèrent-ils ?
Une taxonomie précise des types de correctifs logiciels
Tous les correctifs logiciels n’ont pas le même profil d’urgence ou de risque. Connaître les différences vous aide à séquencer les déploiements par impact réel plutôt que par ordre d’arrivée.
| Type de correctif | Objectif | Urgence typique | Complexité de la restauration |
|---|---|---|---|
| Correctif de sécurité | Ferme une vulnérabilité spécifique | Élevé à critique | Généralement simple |
| Correctif | Résout un bug urgent en dehors des cycles de publication normaux | Élevé | Varie selon le champ d’application |
| Correction des bugs | Corrige les erreurs fonctionnelles affectant les performances | Moyen | Généralement simple |
| Mise à jour cumulative | Regroupe plusieurs correctifs dans un seul package | Moyen | Plus complexe |
| Service Pack | Combine 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 | Inférieur | Varie |
Les correctifs de sécurité, parfois appelés mises à jour de sécurité, corrigent les vulnérabilités qui pourraient permettre un accès non autorisé, le vol de données ou la compromission du système. Le système CVSS (Common Vulnerability Scoring System) évalue la gravité sur une échelle de 0 à 10. Un score CVSS de 9,0 ou plus signale généralement une vulnérabilité critique qui doit être prioritaire rapidement.
Les correctifs sont des correctifs à réponse rapide publiés en dehors du calendrier de mise à jour normal. Les fournisseurs émettent des correctifs lorsque l’attente de la prochaine version planifiée laisserait les systèmes exposés aux menaces actives ou aux bugs critiques.
Les mises à jour cumulatives regroupent plusieurs correctifs en un seul package. Les versions mensuelles de Microsoft Patch Tuesday prennent souvent cette forme. Bien que pratiques, les mises à jour cumulatives peuvent être plus difficiles à annuler car elles regroupent de nombreux changements.
L’implication pratique : les correctifs et correctifs de sécurité exigent la réponse la plus rapide car ils ferment les fenêtres de vulnérabilité actives. Les mises à jour cumulées et les Service Packs regroupent plusieurs correctifs et améliorations, ce qui les rend plus difficiles à annuler proprement. Testez-les par rapport à des environnements applicatifs représentatifs avant de les utiliser à grande échelle.
Les mises à jour de fonctionnalités qui introduisent de nouvelles fonctionnalités présentent la plus faible urgence, mais la surface de compatibilité la plus imprévisible.
Une fois les types de correctifs clarifiés, retraçons le chemin suivi par un correctif de la version du fournisseur à l’installation des endpoints.
Le cycle de vie des correctifs logiciels, de la version du fournisseur à l’installation des endpoints
Entre le moment où un fournisseur expédie un correctif logiciel et le moment où il est vérifié sur vos endpoints, beaucoup de choses peuvent mal se passer. Chaque étape du cycle de vie est un retard potentiel, et chaque retard prolonge la fenêtre que les pirates informatiques doivent agir.
1. Découverte : le fournisseur identifie un défaut de sécurité par le biais de tests internes, de chercheurs en sécurité ou de rapports client. Pour les problèmes de sécurité, cela implique souvent une coordination avec des organisations telles que CISA ou NIST avant la divulgation publique.
2. Développement : les ingénieurs créent un correctif, le testent par rapport à diverses configurations et le conditionnent pour la distribution. Cette étape peut prendre des jours ou des semaines en fonction de la complexité.
3. Version : le fournisseur publie le correctif via les canaux officiels. Pour les logiciels largement utilisés, cette annonce peut alerter les attaquants de l’existence de la vulnérabilité.
4. Détection : votre organisation apprend que de nouveaux correctifs existent, à la fois pour les logiciels internes et les applications tierces. Cela se produit par le biais de conseils aux fournisseurs, de notifications automatisées provenant de plateformes de gestion des correctifs, du catalogue KEV ( Known Exploited Vulnerabilities) de la CISA, de la base de données nationale des vulnérabilités (NVD) ou d’outils d’analyse automatisés.
5. Hiérarchisation : vous évaluez les endpoints affectés et l’urgence avec laquelle le correctif doit être déployé en fonction de la gravité de la vulnérabilité, de la criticité des actifs et du contexte commercial.
6. Test : avant un déploiement étendu, vous testez des correctifs sur un échantillon représentatif d’endpoints pour détecter les problèmes de compatibilité ou les comportements inattendus.
7. Déploiement : le correctif est distribué aux endpoints ciblés via votre infrastructure de déploiement. Cela peut se produire par phases, en commençant par des systèmes moins critiques avant de passer aux environnements de production.
8. Vérification : vous confirmez que le correctif logiciel a été installé avec succès sur les endpoints ciblés, en vérifiant que le code d’application ou la bibliothèque vulnérable a été remplacé, et pas seulement que la commande de déploiement a été exécutée.
L’écart entre l’étape 3 (libération) et l’étape 8 (vérification) est l’endroit où le risque s’accumule. Chaque jour passé avec des endpoints non corrigés peut étendre la fenêtre d’opportunité pour les attaquants.
Conseil : associez votre workflow de processus d’application de correctifs actuel à ces étapes. Où les retards se produisent-ils généralement ? C’est là que se concentrent les efforts d’amélioration.
La fenêtre d’exposition et le risque qu’elle comporte
La fenêtre d’exposition est la période entre le moment où un fournisseur publie un correctif et le moment où vous avez vérifié qu’il est installé sur chaque endpoint affecté. Ce n’est pas un concept abstrait. C’est un risque mesurable.
Les pirates informatiques n’attendent pas. Lorsqu’un correctif est publié, il inclut souvent des détails sur la vulnérabilité qu’il corrige. Les chercheurs en sécurité et les acteurs malveillants peuvent inverser l’ingénierie du correctif pour comprendre exactement comment exploiter les systèmes non corrigés. Dans de nombreux cas, ils arment rapidement ces connaissances, en déployant des logiciels malveillants conçus pour cibler la faiblesse nouvellement divulguée avant que les organisations n’aient eu la possibilité de réagir.
Tous les jours, dans cette fenêtre d’exposition, les attaquants peuvent agir en fonction des informations que votre propre fournisseur leur a fournies lorsqu’ils ont publié le correctif. Réfléchissez à ce qui se passe pendant une fenêtre d’exposition typique :
- Jour 0 : le fournisseur publie des correctifs et des conseils
- Jour 1–3 : les attaquants commencent à développer des exploits en fonction des détails des correctifs
- Jour 7 : le code d’exploitation peut circuler dans les forums souterrains
- Jour 14 : des outils d’attaque automatisés intégrant l’exploit deviennent disponibles
- Jour 30+ : votre organisation termine enfin le déploiement
Pendant cette fenêtre, les endpoints non corrigés peuvent rester vulnérables. Plus la fenêtre reste ouverte, plus la probabilité de compromission est élevée. Les vulnérabilités d’applications non corrigées deviennent de plus en plus des points d’entrée actifs pour les attaquants, augmentant le risque de violations de données qui ont des conséquences réglementaires, financières et sur la réputation.
La fenêtre d’exposition ne concerne pas seulement la vitesse. Il s’agit également d’exhaustivité. Si vous corrigez rapidement 95 % des endpoints affectés, mais que vous manquez 5 %, ces systèmes négligés restent exposés indéfiniment.
Dans une grande entreprise, 5 % peuvent signifier des milliers d’endpoints vulnérables.
La fermeture de la fenêtre d’exposition nécessite deux choses : déployer rapidement des correctifs logiciels et confirmer qu’ils sont réellement installés sur chaque endpoint affecté. La plupart des organisations sont raisonnablement bonnes en premier lieu. Le second est l’endroit où les programmes se décomposent silencieusement.
Pourquoi le déploiement de correctifs logiciels échoue souvent à grande échelle
L’envoi d’un correctif logiciel à des milliers d’endpoints semble mécanique. En pratique, c’est là que les lacunes de couverture se forment silencieusement, que les failles de sécurité prennent forme et que les vulnérabilités d’applications non corrigées persistent le plus longtemps.
Les endpoints ne sont pas toujours joignables. Les ordinateurs portables voyagent. Les télétravailleurs se connectent par intermittence. Les serveurs dans des segments de réseau isolés peuvent ne pas recevoir de commandes de déploiement. Si un endpoint n’est pas en ligne et connecté lorsque le correctif est poussé, il n’est pas corrigé.
Les dépendances créent des conflits. Un correctif logiciel pour une application peut en briser une autre qui dépend d’une version spécifique ou d’une bibliothèque partagée. Sans visibilité sur ce qui est installé et sur la manière dont les applications interagissent, vous ne saurez pas qu’il y a un problème jusqu’à ce que quelque chose cesse de fonctionner.
Les environnements hétérogènes multiplient la complexité. Les entreprises exécutent simultanément plusieurs versions d’applications, piles de dépendances et configurations de système d’exploitation. Un correctif logiciel validé par rapport à une version d’application peut se comporter différemment par rapport à une autre. Sans visibilité sur ce qui est réellement installé, vous déployez des stores.
L’auto-déclaration n’est pas fiable. De nombreux outils d’application de correctifs rapportent la réussite selon que la commande de déploiement a été exécutée, et non selon que le correctif a été installé correctement. Un endpoint peut signaler « corrigé » tant que la vulnérabilité sous-jacente reste.
Les créneaux de maintenance sont limités. Les applications qui ne peuvent pas être redémarrées pendant les heures ouvrables en raison d’un temps d’arrêt potentiel créent des fenêtres de correctifs étroites. Lorsque ces fenêtres se ferment avant la fin du déploiement, les correctifs logiciels sont mis en file d’attente plutôt que d’être appliqués. Les retards se compliquent au fil du temps, élargissant la fenêtre d’exposition pour chaque correctif qui n’a pas fait la différence et amenant les équipes d’assistance informatique à un nettoyage réactif plutôt qu’un déploiement proactif.
Validation de l’application effective d’un correctif
Le déploiement n’est pas la ligne d’arrivée. La vérification l’est.
Un correctif logiciel qui s’est déployé sans installation vérifiée est une question ouverte, et non une vulnérabilité fermée. L’écart entre « nous l’avons poussé » et « nous l’avons confirmé » est l’endroit où les organisations surestiment constamment leur couverture réelle des correctifs.
La vérification répond à trois questions :
- Le correctif a-t-il atteint l’endpoint ? Les problèmes de réseau, les appareils hors ligne ou les erreurs de déploiement peuvent empêcher la livraison.
- L’endpoint a-t-il installé des correctifs avec succès ? Un espace disque insuffisant, des erreurs de permission ou des conflits peuvent entraîner des échecs d’installation même lorsque le correctif a été livré.
- La vulnérabilité est-elle réellement corrigée ? Dans certains cas, un correctif peut s’installer mais ne pas résoudre complètement le problème en raison des exigences de configuration ou des redémarrages en attente.
De nombreuses organisations s’appuient sur les rapports de réussite de leur outil d’application de correctifs. Mais ces rapports reflètent souvent les tentatives de déploiement, et non les résultats vérifiés. L’outil dit qu’il a poussé le correctif. Il ne confirme pas que l’endpoint a effectivement reçu et installé correctement les correctifs, ou que la vulnérabilité sous-jacente est fermée.
Une vérification efficace nécessite d’interroger directement les endpoints pour 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 des endpoints devient essentielle. Les analyses ponctuelles manquent les endpoints qui étaient hors ligne pendant l’analyse.
Ils manquent également les modifications qui se sont produites après la fin de l’analyse. Une visibilité continue fournit une image actuelle et précise du statut des correctifs dans l’ensemble de votre environnement.
Conseil : après tout déploiement de correctifs critiques, interrogez directement les endpoints affectés pour confirmer que le composant vulnérable n’est plus présent. Ne vous fiez pas uniquement aux journaux de déploiement.
La vérification ferme la boucle sur un correctif logiciel individuel. Mais aucun correctif unique n’est expédié isolément, et le programme responsable du déplacement des correctifs de la version du fournisseur à l’état vérifié du endpoint est ce qui détermine si votre couverture est maintenue à l’échelle.
Où les correctifs logiciels s’intègrent dans la gestion des correctifs
Comprendre ce qu’est un correctif logiciel et comment il fonctionne est fondamental. Cependant, dans un contexte d’entreprise, les correctifs individuels ne se déploient pas eux-mêmes. Ils passent par un programme : détecté, priorisé, testé, déployé et vérifié.
Ce programme est la gestion des correctifs, et son fonctionnement détermine la vitesse à laquelle votre organisation ferme la fenêtre d’exposition 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 mesurés, consultez notre guide sur la gestion des correctifs.
Un correctif logiciel est l’artefact. La gestion des correctifs est le système qui obtient cet artefact de la version du fournisseur à l’installation vérifiée sur des centaines de milliers d’endpoints potentiels.
La distinction est importante car de nombreux échecs de correctifs ne concernent pas le correctif lui-même. Ils concernent le programme :
- Écarts de découverte : vous ne savez pas qu’un correctif existe ou quels endpoints en ont besoin
- Échecs de hiérarchisation : les correctifs critiques attendent en file d’attente derrière les mises à jour de routine
- Tester les goulots d’étranglement : le déploiement est retardé tandis que les équipes valident manuellement la compatibilité
- Limitations de déploiement : les correctifs ne peuvent pas atteindre tous les endpoints affectés
- Écarts de vérification : vous ne savez pas si les correctifs sont réellement installés
Chacun de ces éléments est un défi au niveau du programme, et non un problème au niveau du correctif.
La sélection du bon logiciel de gestion des correctifs est souvent la première étape pour combler ces lacunes systématiquement, offrant aux équipes la visibilité, l’automatisation et le reporting dont elles ont besoin pour fonctionner à grande échelle.
Pour les organisations gérant de grands parcs d’endpoints distribués, les défis au niveau du programme évitent souvent la complexité technique de n’importe quel correctif individuel.
Une visibilité en temps réel, un déploiement vérifié, des politiques d’application de correctifs claires et des workflows de gestion automatisée des correctifs deviennent des éléments opérationnels indispensables plutôt que des éléments agréables à avoir, en particulier lorsque l’alternative consiste à suivre manuellement l’état des correctifs sur des milliers d’endpoints.
Comment Tanium prend en charge la gestion des correctifs logiciels pour les entreprises
Les défis décrits ci-dessus, y compris la visibilité obsolète, les échecs de déploiement et la remédiation non vérifiée, sont des problèmes au niveau du programme que les correctifs individuels ne peuvent pas résoudre.
La plateforme informatique autonome de Tanium les traite à la source : interroger directement les endpoints pour connaître le statut des correctifs en temps réel, séquencer les déploiements en fonction du risque réel à l’aide des scores de confiance et des données de vulnérabilité, et confirmer l’installation réussie plutôt que de s’appuyer uniquement sur les journaux de déploiement.
Pour les organisations gérant de grands parcs d’endpoints distribués, cette combinaison est conçue pour aider à combler l’écart entre la publication des correctifs et la remédiation vérifiée plus rapidement que les approches basées sur l’analyse ne le permettent généralement, sans nécessiter d’infrastructure secondaire.
Visibilité en temps réel comme base
La raison la plus courante pour laquelle les programmes de correctifs échouent à grande échelle n’est pas un manque d’efforts. C’est un manque de données précises et actuelles. La plateforme informatique autonome de Tanium s’attaque directement à cela en fournissant une visibilité en temps réel sur le statut des correctifs des endpoints sur les appareils Windows, Linux et macOS.
Plutôt que de s’appuyer sur des données d’analyse qui peuvent dater de plusieurs heures ou jours, les organisations utilisant Tanium peuvent interroger directement les endpoints pour comprendre leur état actuel. Lorsqu’un correctif critique est publié, les équipes informatiques peuvent rapidement identifier les endpoints susceptibles d’être affectés, ceux qui semblent déjà corrigés et ceux qui peuvent nécessiter un report, sans attendre la fin d’un cycle d’analyse planifié.
La plateforme informatique autonome de Tanium est conçue pour maintenir la visibilité sur les environnements distribués, y compris les endpoints des succursales, des sites distants et des sites géographiquement dispersés, le tout à partir d’une seule instance Tanium, conçue pour réduire la dépendance aux serveurs de relais, de base de données ou de distribution secondaires.
L’architecture de la plateforme est conçue pour prendre en charge les environnements à grande échelle, y compris les déploiements avec des centaines de milliers d’endpoints. Cette échelle est importante car les écarts de correctifs sont rarement uniformes : les endpoints les plus difficiles à atteindre sont souvent ceux qui sont les plus susceptibles de ne pas être corrigés.
Hiérarchisation basée sur les risques avant le déploiement
Tous les correctifs logiciels ne garantissent pas la même urgence. Le déploiement sans hiérarchisation signifie que vos équipes sont tout aussi susceptibles de rechercher des mises à jour d’applications à faible risque qu’elles ferment des fenêtres de vulnérabilité actives.
La plateforme informatique autonome de Tanium permet aux organisations de combiner les données de vulnérabilité avec les scores de criticité et de confiance des endpoints pour hiérarchiser les correctifs et se concentrer d’abord sur les lacunes à haut risque.
Les scores de confiance sont générés grâce à une analyse en temps réel des tendances par l’intelligence du cloud, y compris les taux de réussite de l’installation, la fréquence des pannes et l’impact sur les performances, donnant aux équipes des données exploitables pour éclairer les décisions de séquençage avant qu’un correctif ne soit largement déployé.
La plateforme permet également aux équipes d'utiliser des signaux de risque et un contexte commercial pour hiérarchiser les correctifs qui réduisent d'abord le plus d'exposition. Cette approche connecte la gestion des correctifs directement au workflow plus large de gestion de l’exposition plutôt que de la traiter comme une tâche d’opérations informatiques isolée.
Les équipes peuvent identifier les vulnérabilités pouvant faire l’objet de correctifs et les principaux correctifs non planifiés, ce qui aide à rationaliser la communication entre les équipes de sécurité et d’exploitation et garantit que les correctifs sont priorisés et appliqués efficacement.
Déploiement gouverné via des déploiements basés sur des anneaux
L’une des capacités les plus significatives sur le plan opérationnel de la plateforme informatique autonome de Tanium est sa prise en charge du déploiement progressif basé sur l’anneau. Plutôt que d’appliquer simultanément un correctif à tous les endpoints, les organisations peuvent commencer par un petit groupe d’endpoints, valider les résultats et utiliser les informations de la communauté de clients Tanium pour faire évoluer le déploiement en toute confiance à chaque étape, conformément aux critères de réussite.
Cette approche est particulièrement pertinente pour les vulnérabilités zero-day, où la vitesse est essentielle, mais le risque d’un correctif problématique entraînant une perturbation généralisée est également élevé.
Les déploiements de correctifs peuvent être acheminés via des workflows d’approbation et placés dans des fenêtres de maintenance pour minimiser l’impact commercial. Les équipes peuvent configurer la planification des correctifs et les workflows pour s’adapter au fonctionnement actuel de leur organisation, en régissant les endpoints qui reçoivent les correctifs dans quel ordre et dans quelles conditions un déploiement progresse vers l’anneau suivant.
Les playbooks d’automatisation créés avec Tanium Automate peuvent gérer les workflows de correctifs logiciels sur de grands parcs d’endpoints en temps réel, en gérant les étapes de détection, de séquençage de déploiement et de vérification comme un processus reproductible unique plutôt qu’une série de transferts manuels entre les outils.
Validation et remédiation en boucle fermée
Le déploiement n’est pas la même chose que la remédiation. La plateforme informatique autonome de Tanium suit le succès des correctifs, les exceptions et les mesures de performance en temps réel, et fournit des rapports détaillés pour soutenir les améliorations futures des processus de ciblage, de calendrier et de séquençage.
Après un déploiement, les organisations peuvent confirmer l’état des correctifs et identifier les systèmes qui n’ont pas pu être mis à jour, en distinguant les endpoints où le correctif a été livré, mais pas installé, et les endpoints qui étaient simplement inaccessibles pendant la fenêtre de déploiement.
Tanium Comply étend cela en évaluant 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 est terminé. Les équipes peuvent passer directement de l’identification d’une vulnérabilité logicielle non corrigée au lancement et au suivi de la remédiation au sein de la même plateforme, sans changer d’outils ou rapprocher les données de systèmes distincts.
Cette boucle identification-to-remediation-to-validation signifie que la gestion des correctifs ne se termine pas au déploiement ; elle se termine lorsque la vulnérabilité est validée comme corrigée.
Rapports de conformité et préparation à l’audit
Démontrer que les correctifs logiciels ont été appliqués et correctement est de plus en plus pertinent pour les programmes d’audit réglementaire, y compris ceux liés à des cadres tels que HIPAA et PCI. Tanium est conçu pour répondre à ces besoins de documentation.
Tanium Patch récapitule le statut de déploiement pour tout correctif logiciel, fournissant un retour immédiat sur les réussites et les échecs nécessitant une remédiation. Lorsque les auditeurs demandent quels correctifs logiciels ont été appliqués et quand, Tanium donne aux équipes l’historique du déploiement, le statut du redémarrage et la confirmation de remédiation nécessaires pour répondre à cette question avec des données plutôt que des estimations.
De l’écart de conformité à une couverture des correctifs de 90 % : Honeywell
Honeywell a été confrontée à de faibles taux de conformité aux correctifs qui exposent l’entreprise à un risque de rançongiciel et d’autres cyberattaques. Après avoir déployé Tanium, Honeywell a dépassé 90 % de conformité aux correctifs pendant trois mois consécutifs, un niveau de service que l’entreprise n’avait pas pu atteindre auparavant.
Tanium a également permis à Honeywell de consolider et, dans certains cas, d’éliminer d’autres outils d’application de correctifs, et a fourni une vue unique pour le reporting de conformité exécutive et opérationnelle.
[Lire l’étude de cas Honeywell]
« Avant d’utiliser Tanium, notre conformité aux correctifs était faible. Maintenant, avec Tanium, nous avons dépassé la marque de conformité aux correctifs de 90 % pendant trois mois consécutifs. C’est important. »Manish Chopra, directeur informatique de Honeywell
Les mécanismes d’un correctif logiciel sont simples. La réalité opérationnelle du déploiement d’un sur des milliers d’endpoints ne l’est pas. Vous trouverez ci-dessous les réponses aux questions qui se posent le plus souvent.
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 pour un problème spécifique, généralement un bug ou une vulnérabilité de sécurité dans le logiciel. Une mise à jour est un terme plus large qui peut inclure des correctifs, des ajouts de fonctionnalités, des améliorations de performance et d’autres modifications. Tous les correctifs sont des mises à jour, mais toutes les mises à jour ne sont pas des correctifs.
À quelle vitesse les attaquants agissent-ils après la publication d’un correctif logiciel ?
Plus rapide que la plupart des organisations ne peuvent déployer. Lorsqu’un fournisseur publie un correctif logiciel, le correctif lui-même peut révéler des détails sur le défaut sous-jacent, donnant aux attaquants une feuille de route pour exploiter les systèmes non corrigés. Pour les vulnérabilités logicielles de haut niveau, le code d’exploitation peut apparaître dans les heures suivant la publication du correctif.
Selon Check Point Research, la vulnérabilité 2021 Log4j , un défaut dans une bibliothèque de journaux Java largement utilisée, a vu plus de 200 000 tentatives d’attaque dans les 24 heures suivant la divulgation. C’est pourquoi l’écart entre la version des correctifs logiciels et l’installation vérifiée est un risque mesurable, et pas seulement un inconvénient opérationnel.
Un correctif logiciel peut-il être inversé en cas de problème ?
Cela dépend de la façon dont le correctif a été emballé. La plupart des correctifs logiciels autonomes peuvent être désinstallés via l’application ou votre outil de gestion des correctifs, restaurant ainsi la version précédente. Les mises à jour cumulatives sont plus difficiles à inverser proprement, car annuler un changement signifie en annuler plusieurs.
Avant de déployer un correctif logiciel de manière générale, testez-le par rapport à un échantillon représentatif d’endpoints et confirmez que vous disposez d’un chemin de restauration si le correctif cause des problèmes de compatibilité ou un comportement inattendu de l’application.
Pourquoi certains correctifs logiciels nécessitent-ils un redémarrage ?
Les correctifs logiciels qui modifient les fichiers d’application ou les bibliothèques partagées actuellement utilisées ne peuvent pas terminer l’installation tant que ces fichiers sont actifs. Un redémarrage, ou dans certains cas un redémarrage d’application, libère ces verrouillages et permet aux fichiers corrigés de prendre effet. La nécessité d’un redémarrage dépend de ce que le correctif logiciel modifie et si l’application affectée peut être redémarrée en toute sécurité sans redémarrage complet du système.
Que se passe-t-il si un endpoint manque un déploiement de correctifs logiciels ?
L’endpoint reste exposé à la vulnérabilité logicielle que le correctif devait fermer. Un déploiement manqué n’est pas un écart mineur. Cela signifie que le défaut de code sous-jacent est toujours présent et exploitable. L’identification des endpoints manqués nécessite de les interroger directement pour les versions logicielles actuelles et l’état du correctif, sans dépendre des journaux de déploiement qui confirment uniquement que le correctif a été poussé, et non qu’il a été installé correctement.
De nombreuses solutions modernes de gestion des correctifs sont conçues pour suivre les déploiements manqués, réessayer automatiquement et combler les lacunes afin que moins d’endpoints ne soient pas corrigés pendant de longues périodes.
Une gestion efficace des correctifs logiciels commence par comprendre ce que vous déployez et pourquoi, jusqu’à la modification de code spécifique qu’un correctif effectue et ce qui se passe s’il ne s’installe pas correctement. À partir de là, il s’agit de fermer la fenêtre d’exposition aussi rapidement et complètement que possible, puis de vérifier que vous avez réussi.
Tanium fournit une visibilité en temps réel sur le statut des correctifs logiciels sur les parcs d’endpoints distribués, permettant aux équipes d’identifier les lacunes, de déployer en toute confiance et de confirmer la remédiation plutôt que de l’assumer. Planifiez une démo pour voir comment elle fonctionne à l’échelle de l’entreprise.
