Les serveurs ne reçoivent pas de correctifs comme les ordinateurs portables. Une mise à jour qui a échoué sur le poste de travail d'un salarié cause des désagréments à une seule personne. Une mise à jour qui échoue sur un serveur de base de données peut perturber, voire interrompre temporairement, les transactions au sein de toute une unité opérationnelle, ce qui rend indispensable la mise en place d'un plan de restauration.
Les pratiques standard de gestion des appareils, conçues pour les terminaux, ne s'appliquent tout simplement pas aux environnements de serveurs. Les enjeux opérationnels, les chaînes de dépendance et les exigences en matière de disponibilité sont radicalement différents.
Cette différence de rayon d'impact change complètement la manière dont la mise en place des correctifs est planifiée, organisée et exécutée. La gestion des correctifs sur les serveurs implique une coordination tenant compte des exigences en matière de disponibilité, des dépendances entre les applications et des processus de gestion des changements, ce qui n'est généralement pas nécessaire pour l'application de correctifs sur les terminaux.
Ce guide traite des contraintes opérationnelles qui caractérisent la mise à jour des serveurs, depuis l'inventaire et la cartographie des dépendances jusqu'à la hiérarchisation des priorités en fonction des risques, en passant par le déploiement par anneaux, la coordination entre les équipes et la vérification après déploiement.
Pourquoi la mise à jour des serveurs nécessite une approche opérationnelle différente
Une seule mise à jour qui échoue sur un serveur de base de données peut paralyser toute une unité opérationnelle. C'est pourquoi la mise à jour des serveurs ne se résume pas à une simple extension à plus grande échelle de la gestion des correctifs : il s'agit d'une discipline opérationnelle fondamentalement différente.
Le processus général de gestion des correctifs de l' consiste à rechercher les mises à jour manquantes, à tester les correctifs dans un environnement de préproduction, à les déployer pendant les fenêtres de maintenance et à rendre compte des résultats. Parmi les bonnes pratiques en matière d' , on peut citer l'automatisation des tâches répétitives, le respect d'un calendrier régulier de mise à jour (tel que le « Patch Tuesday » de Microsoft pour les environnements Windows), le respect des cycles de publication propres à chaque éditeur pour Linux et d'autres plateformes, ainsi que la création de sauvegardes ou d'instantanés avant l'application des mises à jour.
Mais il s'agit là du cadre standard. La réalité est bien plus complexe pour les équipes d'entreprise chargées de la gestion des serveurs.
Les serveurs exécutent souvent 07/12 charges de travail avec des créneaux de maintenance restreints, fixés plusieurs semaines à l'avance. Si vous manquez cette occasion, la période d'exposition se prolonge de plusieurs semaines, même lorsque les correctifs ont déjà été approuvés et préparés. Dans le cadre de la gestion des terminaux « » standard, les appareils peuvent redémarrer pendant la pause déjeuner sans causer de perturbation notable. Les serveurs ne disposent pas de cette flexibilité.
Et puis, il y a le problème de la dépendance. Les serveurs fonctionnent rarement de manière isolée. Un correctif appliqué à un serveur peut perturber le fonctionnement d'une API dont dépend un autre serveur, ce qui, à son tour, affecte un troisième système en aval. C'est ce réseau interdépendant de services et de dépendances qui rend l'application des correctifs sur les serveurs fondamentalement plus complexe que celle sur les terminaux, et qui explique pourquoi les modifications doivent être soigneusement séquencées plutôt que déployées en bloc.
Les contraintes liées à l'application des correctifs sur les serveurs ne rendent pas cette tâche impossible. Cela leur permet de se démarquer sur le plan opérationnel. Les sections suivantes vous expliquent comment remédier à chaque contrainte de manière à réduire les risques sans créer de nouveaux problèmes opérationnels.
Inventaire des serveurs et cartographie des dépendances
Avant de déployer quoi que ce soit, vous devez savoir sur quoi porte le correctif et quels éléments en dépendent. Un inventaire incomplet des serveurs peut compromettre les efforts de mise à jour avant même que le déploiement ne commence.
Un inventaire des serveurs à des fins de mise à jour va au-delà de la simple identification des actifs. Ces informations comprennent les versions des systèmes d'exploitation, les applications installées, les niveaux de correctifs, ainsi que les fonctions métier prises en charge par chaque serveur. Sans ces informations, les équipes finissent par appliquer des correctifs à l'aveuglette, sans savoir si un serveur donné héberge une charge de travail de test ou une base de données de production.
La cartographie des dépendances ajoute une couche supplémentaire. Les serveurs hébergent souvent des services auxquels d'autres systèmes font appel. Un correctif nécessitant un redémarrage sur un serveur middleware peut interrompre temporairement les connexions vers les applications en aval. Dans les environnements « » (cloud et conteneurs), l'application de correctifs peut également impliquer de reconstruire des images de référence et de redéployer les charges de travail (infrastructure immuable) plutôt que de mettre à jour sur place des instances à longue durée de vie.
Le fait de savoir ce sur quoi chaque serveur a une incidence, et ce qui a une incidence sur lui, permet aux équipes d'enchaîner correctement les correctifs et d'en informer les parties prenantes concernées.
| Élément de stock | Pourquoi est-ce important pour l'application des correctifs ? |
|---|---|
| Version du système d'exploitation et niveau de correctif | Détermine quels correctifs doivent être appliqués et dans quel ordre |
| Applications installées | Identifie les applications tierces et les autres logiciels qui nécessitent également des mises à jour |
| Fonction métier | Permet de définir les priorités et de planifier les créneaux de maintenance |
| Dépendances en amont et en aval | Empêche les défaillances en cascade lors des redémarrages |
| Niveau de criticité du serveur | Détermine à quel anneau de déploiement appartient le serveur |
Les processus d'inventaire manuels peinent à suivre le rythme de la multiplication des serveurs. Dans les environnements cloud, les serveurs sont mis en service et hors service, et l'infrastructure sur site évolue tout aussi fréquemment, par le biais de mises hors service, de reconfigurations et de nouveaux déploiements qui ne sont pas toujours consignés. Les écarts de configuration s'accumulent au fil du temps. Les équipes qui s'appuient sur des audits trimestriels ne découvrent souvent les lacunes qu'après l'échec d'un correctif ou lorsqu'un audit signale une couverture insuffisante.
La solution « », qui offre une visibilité en temps réel sur les ressources, permet de remédier à ce problème en surveillant en permanence l'état des serveurs. Lorsqu'un nouveau serveur est mis en service ou que la configuration d'un serveur existant est modifiée, l'inventaire peut être mis à jour automatiquement, en fonction de la configuration et de la connectivité.
Les logiciels modernes de gestion des correctifs doivent intégrer cette fonctionnalité d'inventaire en temps réel directement dans le processus de déploiement des correctifs, afin d'offrir aux équipes une vue d'ensemble actualisée plutôt qu'un instantané obsolète, et d'éliminer ainsi le rapprochement manuel qui ralentit les approches traditionnelles.
Une fois que vous disposez d'un inventaire complet et d'une cartographie des dépendances, la question suivante se pose : quels serveurs faut-il mettre à jour en priorité ?
Comment hiérarchiser les correctifs des serveurs à l'aide d'EPSS, de CISA KEV et de la criticité des actifs
Toutes les vulnérabilités ne présentent pas le même risque. Un score CVSS (Common Vulnerability Scoring System) de 9,8 sur un serveur de test non connecté au réseau est moins urgent qu'un score CVSS de 7,5 sur un serveur de production traitant les transactions des clients. Une hiérarchisation efficace tient compte à la fois de la gravité des vulnérabilités et du contexte métier. Il s'agit de la pierre angulaire d'un programme de gestion des vulnérabilités mature et « » qui va au-delà de la simple détection des problèmes pour réduire activement les risques d'exploitation.
Trois indicateurs permettent d'affiner la hiérarchisation au-delà des scores CVSS bruts :
- Système d'évaluation de la probabilité d'exploitation des failles (EPSS) : L'EPSS estime la probabilité qu'une vulnérabilité soit exploitée en conditions réelles au cours des 30 prochains jours. Une vulnérabilité présentant un score CVSS élevé mais un score EPSS faible peut s'avérer moins urgente qu'une autre présentant un score CVSS modéré et un score EPSS élevé.
- Catalogue KEV de la CISA : Si une vulnérabilité figure sur la liste KEV de la CISA, cela signifie que des pirates l'exploitent déjà. Les vulnérabilités figurant sur cette liste sont traitées en priorité, quels que soient leurs autres scores. Cela vaut tout particulièrement pour les plateformes serveur largement déployées, notamment Windows Server et les distributions Linux les plus courantes, qui figurent fréquemment dans les listes KEV en raison de leur omniprésence dans les entreprises et sur Internet.
- Importance stratégique des ressources : Le rôle d'un serveur dans les opérations de l'entreprise détermine l'urgence avec laquelle il doit bénéficier d'un correctif. Les serveurs hébergeant des applications génératrices de revenus, des données soumises à une réglementation ou des services destinés aux clients justifient généralement une intervention plus rapide. Elles constituent également les cibles les plus attractives pour les auteurs de rançongiciels, qui recherchent délibérément des systèmes de grande valeur afin de maximiser leur pouvoir de négociation.
Les vulnérabilités répertoriées dans la liste KEV nécessitent souvent de s'écarter du cycle habituel de correctifs. Un programme de correctifs bien rodé prend en charge les interventions hors cycle pour les vulnérabilités répertoriées par le KEV ou présentant un niveau d'exposition élevé, même lorsque cela perturbe le rythme habituel de la maintenance.
La combinaison des signaux permet d'établir une matrice de priorités. Une vulnérabilité présentant un score EPSS élevé, figurant sur la liste KEV de la CISA et affectant un serveur de production de niveau 1 fait l'objet d'une attention immédiate. Une vulnérabilité présentant un score EPSS faible, ne figurant pas sur la liste KEV et se trouvant sur un serveur de développement peut attendre la prochaine fenêtre de maintenance prévue. L'objectif n'est pas de tout corriger d'un seul coup. Il s'agit de réduire systématiquement la surface d'attaque en traitant en priorité les vulnérabilités les plus susceptibles d'être exploitées.
La hiérarchisation des priorités en fonction des risques aide les équipes à concentrer leurs efforts là où cela permet de réduire au maximum l'exposition au risque. Une fois les priorités définies, le prochain défi consiste à déployer les correctifs sans perturber les opérations.
Une hiérarchisation plus pertinente des vulnérabilités grâce à Tanium Comply
Ce n'est pas en travaillant plus dur que l'on réduit le nombre de vulnérabilités en attente, mais en travaillant plus intelligemment. Cet épisode de « Tanium Tech Talks » explique comment Tanium Comply intègre les informations sur les failles d' , les données de l', le niveau de criticité des terminaux et les données relatives aux produits détectés aux scores CVSS, offrant ainsi aux équipes un moyen plus précis et mieux étayé de déterminer les correctifs à appliquer en priorité.
Si votre processus de mise à jour des correctifs sur vos serveurs repose encore sur un tableur et une intuition, cette vidéo mérite votre attention.
Structuration du déploiement des correctifs sur les serveurs à l'aide d'un déploiement par anneaux
Le déploiement simultané de correctifs sur tous les serveurs est la recette idéale pour provoquer des pannes généralisées. Le déploiement en anneau applique les correctifs par étapes à des groupes de plus en plus importants, ce qui permet de détecter les problèmes à un stade précoce, avant qu'ils n'affectent les systèmes critiques pour la production.
Une structure en anneau typique se présente comme suit :
Ring 0 : Canari
Un petit groupe de serveurs non critiques reçoit les correctifs en premier. Les serveurs « Canary » reproduisent les configurations de production, mais ne prennent pas en charge les charges de travail de production. Si une mise à jour pose des problèmes, les dégâts sont limités.
Niveau 1 : Projet pilote
Une fois que les serveurs « canary » ont fonctionné de manière stable pendant une période définie, les correctifs sont déployés auprès d'un groupe pilote. Le groupe pilote comprend un éventail plus large de types de serveurs et peut inclure certains systèmes de production de niveau inférieur. La surveillance s'intensifie au cours de cette phase.
Ring 2 : Déploiement à grande échelle
Les phases « canary » et « pilot » étant terminées, les correctifs sont déployés sur la majorité des serveurs. Cette phase se déroule souvent pendant les créneaux de maintenance programmés et comprend des contrôles d'intégrité automatisés avant et après le déploiement. Les données issues des phases précédentes permettent aux équipes d'affiner le calendrier, la taille des lots et l'ordre de mise en œuvre avant que le déploiement n'atteigne son ampleur maximale.
Anneau 3 : essentiel à la production
Les serveurs les plus sensibles reçoivent généralement les correctifs après validation réussie dans les phases précédentes, sauf si la gravité de la faille et l'exposition au risque nécessitent une correction accélérée. À ce stade, le correctif a fait ses preuves en termes de stabilité sur des centaines, voire des milliers d'autres serveurs.
Des barrières à rétroaction automatisées contrôlent la progression entre les anneaux. Si les taux d'erreur augmentent fortement ou si les contrôles de santé échouent dans un anneau, le déploiement est suspendu avant de poursuivre. Cela permet d'éviter qu'un correctif problématique ne se propage à l'ensemble de la flotte.
Le déploiement par anneaux donne les meilleurs résultats lorsqu'il est intégré aux processus de gestion du changement. Cette coordination constitue la prochaine pièce du puzzle.
Coordination de l'application des correctifs sur les serveurs entre les services informatiques, la sécurité et la gestion des changements
La gestion des correctifs sur les serveurs relève rarement de la seule responsabilité d'une équipe. Dans un environnement informatique complexe, le service de sécurité identifie les vulnérabilités et fixe les délais de correction, tandis que le service des opérations informatiques gère les serveurs et procède aux déploiements ; enfin, la gestion des changements régit le moment et la manière dont les changements sont mis en œuvre. En l'absence d'une coordination claire entre ces différents services, les correctifs restent bloqués dans les files d'attente d'approbation ou sont déployés sans contrôle adéquat.
Il est utile de bien définir les rôles. Un modèle courant répartit les responsabilités de la manière suivante :
- Sécurité : « » identifie les vulnérabilités, établit des critères de priorisation et définit des accords de niveau de service (SLA) pour les mesures correctives
- Opérations informatiques : Gère l'inventaire des serveurs, procède au déploiement des correctifs et surveille l'état de fonctionnement après déploiement
- Gestion du changement : Approuve les modifications, planifie les créneaux de maintenance, consigne les exceptions
L'approbation du comité consultatif des changements (CAB) conditionne souvent l'application des correctifs sur les serveurs, en particulier pour les systèmes de production. L'intégration des processus de mise à jour aux plateformes de gestion des services informatiques (ITSM), telles que ServiceNow, permet de rationaliser ce processus. Les demandes de correctifs sont traitées via des tickets de modification standard, les validations sont acheminées automatiquement en fonction du niveau du serveur, et les mises à jour concernant l'état du déploiement sont enregistrées en temps réel dans le ticket.
Pour les organisations dans lesquelles la mise en place des correctifs est fournie sous forme de service informatique, que ce soit en interne ou par l'intermédiaire d'un prestataire de services gérés, ce type d'intégration des processus permet une exécution cohérente et vérifiable à grande échelle. Les prestataires de services gérés (MSP) tirent tout particulièrement profit de cette intégration, car elle leur permet d'appliquer des normes de mise à jour cohérentes dans plusieurs environnements clients sans avoir à créer de flux de travail personnalisés pour chacun d'entre eux.
De nombreux prestataires de services gérés (MSP) assurent l'application des correctifs via des plateformes de surveillance et de gestion à distance (RMM), qui offrent une visibilité et un contrôle centralisés sur l'ensemble des environnements clients ; toutefois, ces plateformes présentent des capacités variables quant à leur capacité à gérer les dépendances complexes entre serveurs et la logique de déploiement par anneaux.
La gestion des exceptions nécessite également une coordination. Certains serveurs ne peuvent pas être mis à jour dans les délais prévus en raison de contraintes opérationnelles, de dépendances vis-à-vis des fournisseurs ou de limitations techniques. La documentation des exceptions, associée aux contrôles compensatoires, permet de garantir la clarté des pistes d'audit et de s'assurer que les équipes de sécurité comprennent bien le risque résiduel.
Pour les serveurs non mis à jour d' présentant un risque élevé, l'intégration d'alertes dans une plateforme de gestion des informations et des événements de sécurité (SIEM) peut permettre d'assurer la surveillance continue nécessaire à la détection des tentatives d'exploitation jusqu'à ce qu'une correction soit possible.
Une fois les correctifs déployés et les enregistrements de modification mis à jour, la dernière étape consiste à vérifier que tout a bien fonctionné.
Vérifier que le déploiement des correctifs a bien été effectué sur l'ensemble de votre parc de serveurs
Le déploiement d'un correctif ne signifie pas pour autant qu'il a été installé avec succès. Les mises à jour peuvent échouer pour de nombreuses raisons : manque d'espace disque, conflits entre logiciels, interruptions du réseau ou redémarrages requis qui n'ont pas été effectués.
En l'absence de vérification, les équipes se basent sur des hypothèses plutôt que sur des faits. C'est cette différence qui distingue un processus de correction mûr de celui qui donne un faux sentiment de sécurité.
C'est la possibilité d'effectuer des requêtes en temps réel sur l'ensemble de la flotte qui rend la vérification en boucle fermée réalisable à grande échelle. Au lieu de procéder à des contrôles ponctuels sur un échantillon et de faire des suppositions pour le reste, les équipes peuvent vérifier l'état des correctifs sur chaque serveur géré en quelques minutes après leur déploiement, les échecs d'installation étant automatiquement signalés en vue d'une correction.
La vérification post-déploiement permet de répondre à trois questions :
- Le correctif s'est-il installé ? Vérifiez que la mise à jour a bien été enregistrée par le système d'exploitation ou le gestionnaire de paquets et qu'elle correspond bien à l'état attendu du paquet, de la base de connaissances, de la version de compilation ou de la version.
- Le correctif a-t-il pris effet ? Vérifiez que les redémarrages ou les réinitialisations de service requis ont bien été effectués et que la version du noyau ou du service en cours d'exécution correspond bien à la version corrigée.
- Ce correctif a-t-il posé des problèmes ? Vérifiez les contrôles de santé et les indicateurs de niveau de service (journaux, taux d'erreur, latence) et assurez-vous que les procédures de retour en arrière et de basculement sont opérationnelles en cas de problème.
La vérification automatisée permet d'étendre ce processus à de grandes flottes. Plutôt que de procéder à des contrôles ponctuels sur un échantillon de serveurs, les équipes peuvent interroger chaque serveur en temps réel afin de vérifier l'état des correctifs. Les serveurs dont l'installation a échoué sont signalés en vue d'une correction. Les serveurs dont l'installation s'est déroulée avec succès mettent à jour leurs fiches dans la base de données de gestion de la configuration (CMDB).
La vérification permet de boucler la boucle. Cela transforme l'application des correctifs, qui n'est plus une simple opération de déploiement, mais devient une mesure de réduction des risques dont les résultats sont mesurables.
Maintenir la préparation aux audits en matière de conformité des correctifs des serveurs
Les cadres de conformité, notamment les normes PCI DSS, HIPAA et DORA (loi européenne sur la résilience opérationnelle numérique), exigent des organisations qu’elles documentent et démontrent leurs pratiques en matière de gestion des correctifs et des vulnérabilités.
Les auditeurs ne se contentent pas de savoir que des correctifs ont été déployés. Ils veulent des preuves : des journaux de déploiement, des rapports de couverture, une documentation sur les exceptions et des calendriers de correction. Une politique de gestion des correctifs documentée , qui définit les rôles, les délais, les procédures d'exception et les voies de remontée, est souvent le premier document demandé par les auditeurs, et son absence est un constat fréquent lors des contrôles de conformité.
La préparation à un audit commence par une tenue rigoureuse des registres. Chaque déploiement de correctif génère des enregistrements qui répondent aux questions suivantes :
- Quels serveurs ont été pris pour cible ?
- Quels correctifs ont été déployés ?
- Quand ce déploiement a-t-il eu lieu ?
- Quel était le taux de réussite ?
- Quels serveurs ont connu une défaillance, et quelles mesures correctives ont été prises ?
- Quels sont les serveurs qui ont fait l'objet d'une dérogation, et quelles sont les mesures de contrôle compensatoires mises en place ?
L'intégration des outils de gestion des correctifs aux plateformes CMDB et ITSM permet de centraliser ces informations. Lorsqu'un auditeur demande des informations sur le taux de couverture des correctifs sur les serveurs relevant de la norme PCI, la réponse est obtenue à partir d'une requête plutôt que d'un rapprochement manuel dans un tableur.
| Cadre de conformité | Exigences en matière de correctifs | Remarque importante |
|---|---|---|
| PCI DSS | Application en temps opportun des correctifs de sécurité en fonction des risques | Les organisations prévoient généralement un délai de 30 jours pour les vulnérabilités critiques et des délais plus longs pour les problèmes présentant un risque moindre ; toutefois, les délais précis doivent être confirmés auprès de votre évaluateur de sécurité qualifié (QSA). |
| HIPAA | Correction rapide des vulnérabilités affectant les systèmes ePHI | Le règlement ne définit pas de délais précis ; ceux-ci doivent être déterminés à l'issue d'une analyse des risques au sein de l'organisation et confirmés par un conseiller juridique ou un responsable de la conformité. |
| DORA | Exigences en matière de gestion des risques liés aux TIC, englobant les processus de gestion des vulnérabilités et des correctifs | Cette réglementation s'applique aux entités financières opérant dans l'Union européenne et à leurs prestataires tiers désignés comme essentiels dans le domaine des TIC ; les exigences reposent sur des principes et des délais précis pour l'application des correctifs sont définis au sein du cadre de gestion des risques liés aux TIC de chaque organisation. |
| NIST SP 800-40 , rév. 3 | Cycle de vie formel de la gestion des correctifs, assorti de contrôles relatifs aux tests et au déploiement | Fournit un cadre de référence ; les délais et contrôles spécifiques sont définis lors de la mise en œuvre et ne sont pas imposés par le NIST |
La documentation relative aux exceptions mérite une attention particulière. Les auditeurs sont conscients que tous les serveurs ne peuvent pas être mis à jour immédiatement. Ce qu'ils recherchent, ce sont des preuves attestant que les exceptions font l'objet d'un suivi, d'une évaluation des risques et qu'elles sont assorties de contrôles compensatoires.
Un serveur sur lequel il n'est pas possible d'appliquer des correctifs en raison de contraintes imposées par le fournisseur peut bénéficier, à titre de mesures de contrôle compensatoires, d'une segmentation du réseau ou d'une surveillance renforcée.
Comment Tanium facilite la gestion des correctifs des serveurs
La plateforme informatique autonome de Tanium, « », aborde la gestion des correctifs des serveurs comme un processus continu, fondé sur les données. Il interroge directement les points de terminaison plutôt que de s'appuyer sur des instantanés de base de données ou des cycles d'analyse programmés ; ainsi, les décisions sont fondées sur la situation actuelle, et non sur celle qui prévalait lors de la dernière analyse.
Les équipes chargées de l'exploitation et de la sécurité informatiques disposent, depuis une console unique, d'une vue d'ensemble actualisée permettant de savoir quels serveurs ne disposent pas des correctifs nécessaires, lesquels sont prêts à recevoir ces correctifs et lesquels nécessitent un report, que ce soit sous Windows, Linux ou macOS .
- Visibilité en temps réel sur les terminaux : État actuel des correctifs à la demande sur Windows, Linux et macOS, et non pas des résultats d'analyse périodiques
- Hiérarchisation des priorités en fonction des risques : Les données relatives aux vulnérabilités sont combinées avec l'EPSS, le KEV de la CISA, le niveau de criticité des actifs et les scores de confiance afin de concentrer les efforts là où ils permettent de réduire le plus les risques
- Scores de confiance (Windows) : Analyse prédictive de l'impact des déploiements de correctifs Windows , basée sur les taux de réussite d'installation, la fréquence des plantages et les indicateurs de performances, avant un déploiement à grande échelle. Ces scores sont calculés à partir de données télémétriques de déploiement anonymisées provenant des clients participants, de sorte que les résultats reflètent le comportement réel des correctifs, et non des hypothèses.
- de déploiement progressif par anneaux : Déploiements par étapes qui valident les résultats par rapport à des seuils de confiance avant la mise à l'échelle, les serveurs critiques étant mis à jour en dernier, de sorte que les systèmes de production et les systèmes critiques pour l'activité bénéficient de la validation effectuée dans les anneaux précédents avant d'être concernés
- des guides d'automatisation régis : Flux de travail en plusieurs étapes, basés sur des conditions, avec des étapes d'autorisation par l'opérateur et des pistes d'audit complètes
- de mise à jour des logiciels tiers : Modèles intégrés pour la mise à jour des applications et des logiciels tiers, sans avoir à télécharger manuellement les paquets depuis les sites des éditeurs
- Informations sur les menaces Tanium Guardian : Alertes en temps réel et conseils de correction ciblés pour de nombreuses vulnérabilités critiques et de type « zero-day », grâce à Tanium VERT, qui met en évidence les menaces émergentes et fournit des mesures de correction spécifiques directement sur la console, sans avoir à changer d'outil
- Validation en boucle fermée : Vérification, après le déploiement, de l'état des correctifs sur l'ensemble des terminaux gérés, avec mise en évidence rapide des installations ayant échoué
- d'évaluation de la conformité : Évaluations basées sur les modèles SCAP et OVAL, alignées sur les contrôles techniques pertinents pour les normes PCI, HIPAA, SOX et d'autres référentiels, avec des mises à jour quotidiennes du contenu
- Rapports pour la préparation de l'audit : Rapports au niveau de l'organisation et des appareils, avec suivi des exceptions et tableaux de bord de conformité
- Intégration ITSM : Intégrez les workflows de correctifs à ServiceNow et à d'autres outils ITSM, avec des mises à jour automatiques du statut des tickets
- Opérations assistées par l'IA : Requêtes en langage naturel pour la gestion des données des terminaux, des enquêtes et des logiciels, avec un processus d'autorisation impliquant l'intervention humaine qui garantit la maîtrise et l'auditabilité des actions automatisées
Les fonctionnalités et les résultats décrits s'appuient sur la documentation relative aux produits Tanium, sur des études de cas validées par des clients et sur des utilisations concrètes. Les résultats réels peuvent varier en fonction de l'environnement de déploiement, de la configuration et du niveau de maturité de l'organisation.
Résultats concrets : une source unique de référence pour la conformité des correctifs des serveurs
Avant Tanium, Honeywell ne disposait pas d’une méthode fiable pour évaluer la conformité de manière cohérente au sein de toutes les équipes : les équipes de sécurité et d’exploitation informatique suivaient chacune des indicateurs différents, et les désaccords sur les chiffres étaient monnaie courante.
Tanium a permis aux deux équipes d'avoir accès aux mêmes données, de sorte que les chiffres relatifs à la conformité étaient cohérents, qu'ils proviennent du service de sécurité ou du service informatique. Cette cohérence a permis à l'équipe informatique de Honeywell de communiquer en toute confiance des chiffres précis tant aux cadres supérieurs qu'aux responsables de services.
«Avant d’utiliser Tanium, notre taux de conformité en matière de correctifs était faible. » Désormais, grâce à Tanium, nous avons dépassé le seuil de 90 % de conformité aux correctifs pendant trois mois d'affilée. C'est important. »Honeywell IT Director Manish Chopra
FAQ sur la gestion des correctifs des serveurs
La mise à jour des serveurs pose des défis de coordination que les guides généraux sur la gestion des correctifs omettent souvent d'évoquer. Vous trouverez ci-dessous les questions les plus fréquemment posées par les équipes d'entreprise lorsqu'elles mettent en place ou améliorent leurs programmes de mise à jour des serveurs.
En quoi l'application de correctifs sur les serveurs diffère-t-elle de celle sur les terminaux ?
Les serveurs exécutent généralement 07/12 charges de travail avec des créneaux de maintenance très restreints, tandis que les terminaux peuvent redémarrer pendant les périodes d'inactivité des utilisateurs. Les serveurs présentent également des dépendances plus complexes, ce qui signifie qu'un correctif appliqué sur un serveur peut avoir des répercussions sur les applications exécutées sur d'autres serveurs.
L'ampleur des répercussions d'un correctif de serveur défaillant est généralement plus importante que celle d'un correctif de terminal défaillant, ce qui modifie la manière dont les équipes abordent les tests, la mise en préproduction et la planification de la restauration.
Combien de temps les serveurs peuvent-ils fonctionner en toute sécurité sans application de correctifs ?
Il n'y a pas de réponse universelle. Les vulnérabilités critiques figurant sur la liste KEV de la CISA nécessitent une attention immédiate, car des pirates les exploitent activement. Pour les autres vulnérabilités, le calendrier dépend de facteurs tels que l'exposition du serveur, les mesures de contrôle compensatoires et les contraintes opérationnelles.
Les exigences de conformité varient en fonction du référentiel et du contexte de risque. Dans le cadre de la norme PCI DSS, les organisations mettent généralement en œuvre des accords de niveau de service (SLA) relatifs aux correctifs en fonction du niveau de risque (en visant souvent un délai d'environ 30 jours pour les vulnérabilités à haut risque et des délais plus longs pour les problèmes présentant un risque moindre), parallèlement à des exceptions documentées et à des contrôles compensatoires.
Les équipes qui dépassent les délais fixés s'exposent à la fois à des risques de sécurité et à des constatations d'audit.
Que se passe-t-il lorsqu'un serveur ne peut pas être mis à jour dans les délais prévus ?
Consignez l'exception, évaluez le risque résiduel et mettez en place des contrôles compensatoires. Les mesures correctives peuvent inclure la segmentation du réseau afin de limiter l'exposition, une surveillance renforcée pour détecter les tentatives d'exploitation, ou encore des mesures au niveau des applications visant à atténuer l'impact de la vulnérabilité. Les auditeurs s'attendent à prendre connaissance de ces documents, ainsi que d'un plan prévoyant des mesures correctives à mettre en œuvre le cas échéant.
Comment les équipes gèrent-elles les correctifs qui nécessitent un redémarrage sur des serveurs fonctionnant en continu ?
Parmi les options proposées figurent les technologies de correction en temps réel (disponibles pour certaines mises à jour du noyau Linux dans le cadre de distributions et de contrats de support spécifiques), le basculement vers des serveurs redondants pendant la fenêtre de redémarrage, ou encore la planification des redémarrages pendant les périodes de faible trafic, avec notification des parties prenantes.
L'approche à adopter dépend du rôle du serveur, de la tolérance de l'entreprise vis-à-vis des temps d'arrêt et de l'existence ou non d'une redondance. Certaines mises à jour de sécurité nécessitent simplement un redémarrage du système ou des services pour être activées, et la prise en compte de cette réalité fait partie intégrante de la procédure de mise à jour des serveurs.
Un correctif installé mais non appliqué laisse toujours la faille de sécurité ouverte. Dans la pratique, c'est souvent la coordination des redémarrages qui constitue le véritable goulot d'étranglement, et non le déploiement des correctifs en soi, en particulier pour les systèmes en cluster et les services critiques pour l'entreprise.
Pour les services de production, les plans de mise à jour doivent également inclure des critères de retour en arrière et un plan de reprise, tels que des instantanés le cas échéant, ou un basculement dans les environnements en cluster et à haute disponibilité (HA).
Actualités concernant l'application des correctifs sur les serveurs
Les dernières actualités à connaître
La faille « zero-day » de PeopleSoft d'Oracle a-t-elle touché votre organisation ?
Oracle a corrigé une vulnérabilité « zero-day » dans PeopleSoft, exploitée par des acteurs malveillants pour voler des données au sein de dizaines d'organisations ; des correctifs et des mesures de protection sont disponibles pour les instances exposées à Internet.
Vos serveurs Ivanti, Fortinet et SAP ont-ils reçu les correctifs nécessaires pour remédier aux failles classées CVSS 10,0 ?
Fortinet, Ivanti et SAP ont corrigé des failles critiques atteignant un score CVSS de 10,0 dans leurs produits serveurs d'entreprise ; Ivanti Sentry CVE-2026-10520 figure désormais dans le catalogue KEV de la CISA suite à la confirmation de son exploitation.
Quelles ont été les corrections apportées aux serveurs lors de ce « Patch Tuesday » record de Microsoft ?
juin 2026 Le « Patch Tuesday » a corrigé 206 failles, dont une vulnérabilité d'usurpation d'identité sur Exchange Server et une faille RCE au niveau du noyau (CVSS 9,8 ) pouvant donner lieu à la propagation d'un ver ; il s'agit de la plus importante mise à jour unique publiée par Microsoft à ce jour.
Vulnérabilité critique de type « RCE » dans Netlogon (CVE-2026-41089) : ce que les équipes chargées des serveurs doivent savoir
La vulnérabilité CVE-2026-41089, un débordement de pile Netlogon, permet l'exécution de code à distance sans authentification sur les contrôleurs de domaine ; Tanium présente l'étendue de la vulnérabilité et les étapes de correction à suivre pour agir rapidement.
La mise à jour des serveurs à l'échelle de l'entreprise ne se résume pas à une simple liste de contrôle. Cela nécessite une visibilité en temps réel, une hiérarchisation des priorités en fonction des risques, un déploiement par étapes et la vérification que les correctifs ont bien réduit l'exposition aux risques.
Tanium rassemble ces fonctionnalités au sein d'une plateforme unique, permettant ainsi aux équipes informatiques et de sécurité d'appliquer les correctifs aux serveurs en toute confiance, sans avoir à se fier à des suppositions. Prenez rendez-vous pour une démonstration gratuite à l'adresse afin de découvrir Tanium en action dès aujourd'hui.
