L’immense majorité des vulnérabilités sont connues, référencées… mais non-patchées. 75 % des vulnérabilités ciblées par une attaque ont ainsi plus de 2 ans. Et 10 % d’entre elles seraient exploitables par un attaquant peu qualifié, en recourant à un programme d’exploitation public.
L’avenir n’est pas plus rassurant : le cyberassureur Coalition estime qu’en 2023 près de 2 000 vulnérabilités et expositions seront recensées chaque mois, dont 270 failles « de haute gravité » et 155 « critiques ».
Ces chiffres ont de quoi effrayer les RSSI. Ils n’étonneront pourtant pas les équipes de terrain, qui connaissent la difficulté de définir une stratégie de patch management, et surtout de l’appliquer en tenant compte des contraintes opérationnelles et de la complexité croissante des infrastructures IT.
Comment s’améliorer, dans la perspective d’un durcissement à venir des contraintes réglementaires, mais aussi contractuelles et des obligations de conformité qui pèsent sur les SI ? Sans oublier que le patch management n’est pas seulement une affaire de sécurité : mettre à jour ses systèmes permet aussi de bénéficier d’améliorations de performance et de nouvelles fonctionnalités.
Par où commencer ? Quelles sont les stratégies possibles ? Comment les automatiser ?
Des politiques de sécurité inapplicables ?
Si les entreprises sont en général suffisamment outillées pour automatiser les campagnes de patchs des postes de travail, du côté des serveurs la réalité est plus contrastée. En pratique c’est souvent « tout ou rien ».
Les organisations qui disposent de moyens importants n’hésitent pas à monopoliser une partie de leurs équipes IT pour mettre à jour régulièrement leurs machines. Tandis que d’autres ont adopté le « mode pompier » parant seulement au plus urgent, avec le risque d’accumuler un retard difficile à rattraper et laissant parfois tourner des OS obsolètes pour lesquels plus aucun correctif n’est publié.
De plus, les politiques de sécurité des systèmes d’information ont souvent le défaut de placer la barre trop haute en ce qui concerne la gestion des correctifs et mises à jour, sans tenir compte de la réalité d’une infrastructure en production : dette technique, hétérogénéité du parc, potentielles contraintes liées à l’infogérance… voire la perte de conformité, dans le cas où celle-ci exige l’immuabilité de certains éléments du système (un comble !).
En l’absence de stratégies et de moyens adéquats (temps, hommes), il est donc naturel de soupeser les risques de sécurité liés aux vulnérabilités non-patchées et les risques d’indisponibilité ou d’instabilité de tout ou partie du SI que cela peut engendrer. Peu d’organisations sont tout à fait sereines lorsqu’il s’agit de lancer de telles campagnes. Des effets de bord, incompatibilités, régressions sont toujours possibles.
Il n’est d’ailleurs pas rare que, par précaution, on gèle les mises à jour pendant les périodes de forte activité, ou qu’une TMA (Tierce Maintenance Applicative) sur telle ou telle application implique de rester sur telle version d’un OS. Quant aux vulnérabilités et CVE, toutes ne se corrigent pas avec un patch, lequel peut mettre plusieurs jours ou semaines à être diffusé et nécessiter un reboot, donc une période d’indisponibilité. Il faut alors trouver des moyens de contournement : désactivation d’une fonctionnalité, changement de configuration, isolation temporaire de la machine… Des actions chronophages, qui nécessitent une connaissance approfondie du SI sur lequel on opère.
Au-delà d’une certaine échelle, des outils sont donc indispensables pour automatiser ce qui peut l’être, contrôler et aider à la prise de décision. Mais avant de parler des outils, il est nécessaire d’évoquer les différentes stratégies possibles, que les outils vous aideront justement à mettre en œuvre avec succès.
Différentes approches pour définir sa stratégie de patch management
Différentes stratégies de mises à jour sont envisageables et peuvent être ajustées en fonction de vos contraintes et surtout de vos moyens. Nous les avons regroupées en 3 grandes familles, et la liste n’est bien sûr pas exhaustive. Cette sélection reflète les pratiques que nous avons le plus souvent observées, et qui ressortent comme les plus efficaces.
N’oubliez pas l’essentiel : la réalité est imparfaite et votre stratégie le sera également. L’essentiel, en matière de patch management, est la régularité de l’effort (l’automatisation vous y aidera). Plus vous attendez, et plus ce sera complexe de rattraper le retard accumulé : au-delà des problématiques liées à l’utilisation de versions d’OS dépréciées, il y a aussi la question des sauts de versions, qui ne sont pas toujours possibles. En conséquence, certaines mises à jour prendront du temps. Beaucoup de temps.
Ainsi, adopter une approche et l’automatiser vous permettra de gagner en efficacité pour correctement mettre à jour vos systèmes tout en maintenant la continuité des services.
1. L’approche pragmatique
Pour cette première approche, on définit une fréquence à laquelle on se préoccupe des mises à jour — usuellement une fois par mois, sauf vulnérabilité critique dont on aura été alerté. On automatise le déploiement des mises à jour de sécurité, qui ne changent pas le périmètre fonctionnel et présentent peu de risques de régression. On valide manuellement les mises à jour mineures après avoir consulté la documentation et estimé les risques.
Concernant les mises à jour majeures, on prend le temps d’évaluer les risques. Il s’agit ainsi de déterminer si l’on peut la déployer immédiatement ou s’il faut attendre un moment où l’on pourra facilement libérer des ressources pour la résolution d’éventuels problèmes.
2. L’approche Rolling Update
Une approche un peu plus évoluée, nécessitant une bonne connaissance de son infrastructure, s’apparente aux process ITIL (Information Technology Infrastructure Library) et aux méthodes de déploiement continu. Elle consiste à procéder en plusieurs batches pour mettre à jour successivement des sous-parties de l’infrastructure dont la criticité va croissant. On déploie d’abord les patches et mises à jour sur un environnement non critique, puis peu critique pour la production, puis sur des éléments sélectionnés pour être « cassables » avant d’étendre la campagne à l’intégralité des machines.
À chaque étape, on évalue l’impact : on teste, on vérifie la pertinence de la documentation fournie par l’éditeur (parfois la mise à jour suffit, d’autres fois il faudra aussi modifier des éléments de configuration). Avantage : en cas de souci, on limite la casse, et on assure la continuité de service, car on ne traite qu’une partie de l’infrastructure à la fois.
3. L’approche Blue/Green
Cette dernière approche, que nous estimons la plus idéale, n’est pas donnée à tous : il s’agit d’avoir deux environnements identiques qui se répartissent la charge et peuvent prendre le relais l’un de l’autre en cas d’incident.
On bascule intégralement le trafic sur l’environnement considéré comme “blue” et l’on effectue les mises à jour sur l’autre environnement, le “green”. Une fois la mise à jour terminée, on rouvre progressivement le trafic de l’environnement “green”. En cas d’un retour en arrière nécessaire, l’environnement “blue” reste ainsi disponible. Au bout de quelque temps, si aucun dysfonctionnement n’est constaté sur l’environnement “green”, on peut sereinement mettre à jour l’environnement “blue” et le remettre en production.
S’outiller pour mettre en oeuvre sa stratégie de patch management
Une fois votre stratégie définie, il s’agit de s’outiller. Si vous n’avez que quelques machines, qui plus est si elles sont basées sur le même système d’exploitation, l’intérêt est limité. Les outils de mises à jour proposés par les éditeurs suffiront amplement : Windows Server Update Service (WSUS) ou Intune, Red Hat Satellite, Ubuntu Landscape, SUSE Manager… Ils mettent à disposition les paquets et permettent de les installer. Il ne nous en faudra pas davantage pour mettre à jour régulièrement vos machines.
Mais dans le cas où votre infrastructure est complexe, qu’elle soit hétérogène, multi-environnement ou hybride, vous dépendez en conséquence de plusieurs éditeurs pour recevoir les mises à jour. Vous avez donc tout intérêt à envisager le recours à un outil sachant gérer la complexité d’un environnement multi-OS. Vous gagnerez ainsi en temps et en fiabilité.
Rudder fait partie des solutions vous permettant de gérer votre infrastructure multi-systèmes et multi-OS au même endroit. Rudder s’adapte à l’approche qui vous convient, de la plus simpliste à la plus sophistiquée grâce à sa forte adaptabilité.
Comment fonctionne-t-il ?
1.
2.
3.
Une fois ces informations collectées, vous pouvez prendre les bonnes décisions, prioriser et automatiser l’exécution des campagnes de patchs. Ces campagnes s’adaptent parfaitement à votre stratégie : elles peuvent être simples et appliquer tous les patchs disponibles selon une fréquence définie ; mais elles peuvent également être plus sophistiquées et sélectives en appliquant uniquement la mise à jour de certains logiciels sur tels groupes de machines avec reboot ou non.
4.
