La distribution et l’application de correctifs logiciels sont deux des tâches les plus importantes attribuées à l’équipe informatique d’une organisation.
De nombreux outils sont conçus pour gérer ces tâches, qui relèvent du titre général de la gestion logicielle.
Mais ce qui se passe souvent sans être reconnu, c’est que, quels que soient les outils que l’informatique peut choisir pour le travail, les problèmes de processus et de politique doivent être résolus avant qu’une organisation puisse vraiment prendre le contrôle de son environnement logiciel.
Et de nombreuses organisations n’ont pas changé leur approche de la gestion des logiciels depuis le début de l’année 2000s. Dans ce blog, je souligne plusieurs de ces considérations de processus et explique leur importance.
Liste de contrôle : pratiques modernes de gestion des logiciels à connaître
Le déploiement et les correctifs logiciels centralisés sont les plus efficaces
D’après mon expérience, les entreprises qui utilisent un modèle décentralisé pour gérer les logiciels ont une hygiène de sécurité beaucoup moins bonne que les entreprises qui utilisent un modèle centralisé.
Et par centralisé, je veux dire qu’une organisation peut avoir un personnel d’assistance décentralisé, mais une autorité centralisée qui détermine quels logiciels et mises à jour logicielles seront installés et quand. Les équipes d’assistance distribuée se tournent toutes vers ce batteur.
La centralisation prend en charge la vitesse des tests et des correctifs
L’un des aspects les plus importants de la gestion des logiciels est la vitesse des tests et des correctifs. Lorsque vous passez à un modèle centralisé, vous souhaitez avoir un déploiement par étapes ou par étapes. Vous devez avoir quelques phases de test avant de procéder à la promotion en production. Quelques signifient deux ou trois, pas 20 !
Le point est que vous ne souhaitez pas que vos appareils d’endpoint soient vulnérables trop longtemps, vous souhaitez donc publier ces mises à jour aussi rapidement que possible. En général, un objectif réaliste est de 7-15 jours, et il peut être inférieur en fonction de la criticité de la mise à jour.
C’est l’aspect politique de la gestion des logiciels. Définissez des accords de niveau de service (SLA) pour vos correctifs les plus critiques. Obtenez le nombre le plus bas possible. Ne basez pas un nombre sur ce que vous avez fait au cours des 20 dernières années. Soyez agressif dans vos objectifs.
30 jours est une longue période
Si j’entre dans une entreprise et que son cycle de correction est supérieur à 30 jours, la première étape consiste à publier ces mises à jour et à les installer sur tous les appareils en 30 jours. Cela ne devrait pas être pire que cela.
Vous devez comprendre que lorsque ces mises à jour sortent, les méchants les voient également. Les gars qui souhaitent infiltrer vos systèmes peuvent lire la documentation ; ils peuvent voir ce qui est corrigé et pourquoi. L’horloge tourne immédiatement et vous devez mettre à jour votre logiciel avant que les exploits ne soient développés et utilisés. C’est pourquoi je dis que 30 jours est long.
Désormais, vous ne souhaitez pas toujours déployer des correctifs immédiatement sur vos systèmes de production. Peut-être avez-vous des difficultés avec les dépendances d’applications internes. Par exemple, les correctifs .Net peuvent ne pas jouer bien avec l’une de vos applications personnalisées développées en interne. Ces choses vont se produire.
Il y a généralement une plage d’environ une semaine où vous pouvez tester ces conflits. Et en fin de compte, vous voulez réduire cela de 30 jours à une semaine aussi proche que possible. C’est l’objectif.
Quelle est sa gravité ? Le monde des « correctifs de rattrapage »
Ce qui m’a ouvert les yeux au fil des ans, c’est le nombre d’entreprises qui pensent faire du bon ou du moins pas mauvais. Ils se donnent un « B+ ».
Mais ensuite, nous effectuons une évaluation et découvrons des milliers de correctifs critiques depuis 2007. Évidemment, quelque chose ne fonctionne pas. Il s’agit généralement d’une combinaison d’outils et de processus. Les deux doivent être traités.
Pour de nombreuses entreprises, la méthodologie d’application des correctifs qu’elles utilisent aujourd’hui est la même qu’en 2007 ou 2010. Mais le monde dans lequel ils opèrent a changé. Ils ont une décennie ou plus de correctifs manquants, qu’ils les connaissaient ou non.
Il n’est pas rare de commencer par des mises à jour de sécurité critiques et importantes pour vos systèmes d’exploitation. Ces mises à jour ont toutes des gravités associées, vous pouvez donc les utiliser pour avoir une idée de la vulnérabilité de vos systèmes d’exploitation.
Il existe également des gravités associées aux mises à jour d’applications tierces, telles qu’Adobe Acrobat (voir notre blog sur EOL pour Adobe Flash), les navigateurs Web tels que Chrome et Firefox, et les applications de productivité telles que Office365.
Pour les « correctifs de rattrapage », commencez par les mises à jour les plus critiques et les plus importantes. Dans un environnement distribué, cela vous donne le meilleur rapport qualité-prix, mais ne vous arrêtez pas là.
L’évaluation technique des lacunes en matière de gestion des logiciels est facile : les résoudre n’est pas
Il ne faut pas beaucoup de temps pour identifier les lacunes dans les méthodologies de distribution et d’application de correctifs logiciels. Mais obtenir un consensus sur les politiques et les processus qui combleront ces lacunes peut être chronophage et litigieux.
Les gens construisent des carrières en faisant les choses d’une seule manière et souvent ils ne veulent pas changer. Dans de nombreux cas, jusqu’à ce qu’ils commencent vraiment à évaluer et à réfléchir à leurs politiques, ils ne réalisent même pas que la seule raison pour laquelle ces politiques existent est que « nous l’avons toujours fait de cette manière ». L’un des domaines où vous êtes susceptible de rencontrer le plus grand repoussage est le redémarrage du système après une mise à jour.
En effet, le redémarrage du système affecte les utilisateurs finaux. Les organisations peuvent littéralement prendre des mois pour décider comment redémarrer les endpoints tout en donnant une notification appropriée, ne redémarrant pas quelqu’un lorsqu’elles partent pour le déjeuner ou au milieu d’une présentation ou lorsqu’elles travaillent sur un document critique.
C’est là qu’un leadership exécutif solide est essentiel pour appliquer la politique de redémarrage, car, en particulier dans le monde Windows, un correctif n’est pas réellement installé et le code vulnérable remplacé jusqu’au redémarrage d’un système ou d’une application.
Certaines organisations laissent à l’utilisateur final le soin de redémarrer, et il n’y a aucune notification indiquant qu’un redémarrage est nécessaire. Les utilisateurs finaux s’adapteront à des politiques plus strictes si elles sont appliquées.
Ils apprendront à redémarrer la première ou la deuxième fois qu’ils recevront une notification, peut-être avant le déjeuner, au lieu de cliquer sur « Reporter » jusqu’à ce que le redémarrage soit appliqué à un moment inopportun.
Lorsque nous travaillons avec un client sur la distribution de logiciels, l’une des premières choses que nous recherchons est le dernier redémarrage. Et nous constaterons souvent que 75 % des systèmes d’une organisation sont en attente d’un redémarrage. Donc, ces correctifs que vous avez appliqués ? Ce n’est vraiment pas le cas.
Le risque fait partie de chaque conversation sur l’application de correctifs logiciels
La principale raison pour laquelle les organisations ne corrigent pas rapidement est la peur de briser quelque chose. Lorsque je discute avec des vice-présidents et des cadres supérieurs de la mise à jour des logiciels, le risque entre dans chaque conversation. « Quel est le risque que mon système soit vulnérable pendant 45 jours par rapport au risque que je déploie quelque chose en 30 jours et que je brise mon application ? » C’est la peur de l’inconnu. C’est la peur des perturbations commerciales.
Si vous avez un plan de test et des mesures, vous pouvez réduire cette peur. Même si ce plan de test est simplement « Déployons cette mise à jour sur un tas de systèmes et voyons si quelque chose se casse ». Mais vous devriez être en mesure de savoir si quelque chose s’est cassé. Vous devez disposer de ces données et ne pas avoir à vous fier à quelqu’un qui ouvre un ticket d’incident.
Si les propriétaires d’applications disposent de données matérielles indiquant que les correctifs sont sûrs, ils seront plus disposés à se connecter lorsque vous dites que vous allez réduire votre cycle de correctifs de 30 à 15 jours.
Pour découvrir comment Tanium simplifie la gestion des logiciels tiers, assurez-vous de consulter 9 façons dont Tanium vous donne le contrôle de votre environnement logiciel d’endpoint.
Si vous êtes prêt à le voir en action, inscrivez-vous à une démo dès aujourd’hui.
