La distribution et l'application de correctifs logiciels constituent deux des tâches les plus importantes confiées à l'équipe informatique d'une organisation.
De nombreux outils sont conçus pour prendre en charge ces tâches, qui relèvent de la catégorie générale de la gestion des logiciels « » ().
Mais ce que l'on oublie souvent, c'est que, quels que soient les outils choisis par le service informatique pour mener à bien cette tâche, il est nécessaire de régler les problèmes liés aux processus et aux politiques avant qu'une organisation puisse réellement prendre le contrôle de son environnement logiciel.
Et de nombreuses organisations n'ont pas modifié leur approche de la gestion des logiciels depuis le début des années 2000s. Dans cet article, je mets en avant plusieurs de ces aspects liés aux processus et j'explique leur importance.
Liste de contrôle : les pratiques modernes de gestion des logiciels à connaître
Le déploiement et l'application centralisés des correctifs logiciels constituent la solution la plus efficace
D'après mon expérience, les entreprises qui recourent à un modèle décentralisé pour la gestion des logiciels présentent des pratiques de sécurité bien moins rigoureuses que celles qui adoptent un modèle centralisé.
Et par « centralisé », j'entends qu'une organisation peut disposer d'un personnel d'assistance décentralisé, mais qu'il existe une autorité centrale unique qui détermine quels logiciels et quelles mises à jour seront installés, et à quel moment. Les équipes d'assistance décentralisées suivent toutes cette ligne directrice.
La centralisation favorise la rapidité des tests et de l'application des correctifs
L'un des aspects les plus importants de la gestion des logiciels réside dans la rapidité des tests et de l'application des correctifs. Lors de votre transition vers un modèle centralisé, il est préférable de procéder à un déploiement par étapes ou progressif. Vous devriez prévoir plusieurs phases de test avant de passer en production. « Quelques-uns », cela signifie deux ou trois, pas 20 !
Le fait est que vous ne souhaitez pas que vos terminaux restent vulnérables trop longtemps ; vous devez donc déployer ces mises à jour le plus rapidement possible. En général, un délai réaliste est de 7-15 jours, mais il peut être plus court en fonction de l'importance de la mise à jour.
Voilà pour l'aspect stratégique de la gestion des logiciels. Définissez des accords de niveau de service (SLA) pour vos correctifs les plus critiques. Faites en sorte que ce chiffre soit le plus bas possible. Ne basez pas vos chiffres sur ce que vous avez fait au cours des 20 dernières années. Fixez-vous des objectifs ambitieux.
30 jours, c'est long
Si je me rends dans une entreprise dont le cycle de mise à jour dépasse 30 jours, la première étape consiste à faire en sorte que ces mises à jour soient publiées et installées sur tous les appareils en 30 jours. Cela ne devrait pas être pire que cela.
Vous devez comprendre que lorsque ces mises à jour sont publiées, les pirates les voient eux aussi. Ceux qui cherchent à s'introduire dans vos systèmes peuvent consulter la documentation ; ils peuvent voir ce qui fait l'objet d'un correctif et pourquoi. Le compte à rebours commence immédiatement, et vous devez mettre à jour vos logiciels avant que des failles ne soient exploitées. C'est pourquoi je dis que 30 jours, c'est long.
Il se peut toutefois que vous ne souhaitiez pas toujours déployer immédiatement les correctifs sur vos systèmes de production. Peut-être rencontrez-vous des difficultés liées aux dépendances internes de l'application. Par exemple, il se peut que les correctifs .Net ne fonctionnent pas correctement avec l'une de vos applications développées en interne. Ces événements vont se produire.
En général, vous disposez d'un délai d'environ une semaine pour vérifier s'il existe de tels conflits. Et au final, votre objectif est de réduire ces 30 jours pour qu'ils se rapprochent le plus possible d'une semaine. Cela devrait être l'objectif.
À quel point la situation est-elle grave ? L'univers des « correctifs de rattrapage »
Ce qui m'a vraiment ouvert les yeux au fil des années, c'est de constater combien d'entreprises pensent qu'elles s'en sortent très bien, ou du moins pas trop mal. Ils s'attribuent la note « B+ ».
Mais lorsque nous procédons à un audit, nous découvrons des milliers de correctifs critiques remontant parfois jusqu'à 2007. De toute évidence, quelque chose ne fonctionne pas. Il s'agit généralement d'une combinaison d'outils et de processus. Il faut traiter ces deux points.
Pour de nombreuses entreprises, la méthodologie de gestion des correctifs « » qu'elles utilisent aujourd'hui est la même qu'en 2007 ou 2010. Mais le monde dans lequel ils évoluent a changé. Ils ont accumulé l'équivalent d'une décennie, voire plus, de correctifs manquants, qu'ils en aient eu conscience ou non.
Il n'est pas rare de commencer par les mises à jour de sécurité critiques et importantes pour vos systèmes d'exploitation. Ces mises à jour sont toutes associées à un niveau de gravité ; vous pouvez donc vous y référer pour vous faire une idée du degré de vulnérabilité de vos systèmes d'exploitation.
Il existe également des niveaux de gravité associés aux mises à jour d'applications tierces proposées par , telles qu'Adobe Acrobat (consultez notre article de blog sur la fin de vie d'Adobe Flash à l'adresse ), des navigateurs Web comme Chrome et Firefox, ainsi que des applications de productivité telles que Office365.
Pour la « mise à jour de rattrapage », commencez par les mises à jour les plus critiques et les plus importantes. Dans un environnement distribué, cela vous offre le meilleur rapport qualité-prix, mais ne vous arrêtez pas là.
Il est facile de procéder à une évaluation technique des lacunes en matière de gestion des logiciels — mais il n'en va pas de même pour y remédier
Il ne faut pas longtemps pour identifier les lacunes dans les méthodes de distribution des logiciels et d'application des correctifs. Mais parvenir à un consensus sur les politiques et les procédures qui permettront de combler ces lacunes peut s'avérer long et source de controverses.
Les gens construisent leur carrière en agissant toujours de la même manière et, souvent, ils ne souhaitent pas changer. Dans de nombreux cas, tant qu’ils ne commencent pas véritablement à évaluer leurs politiques et à y réfléchir, ils ne se rendent même pas compte que la seule raison pour laquelle ces politiques existent, c’est que « nous avons toujours procédé ainsi ». L'un des domaines dans lesquels vous risquez de rencontrer le plus de résistance concerne les redémarrages du système après une mise à jour.
En effet, le redémarrage du système a des répercussions sur les utilisateurs finaux. Cela peut littéralement prendre des mois aux organisations pour déterminer comment redémarrer les terminaux tout en veillant à les avertir en temps utile — afin de ne pas redémarrer l'appareil d'un utilisateur lorsqu'il s'absente pour déjeuner, au milieu d'une présentation ou alors qu'il travaille sur un document critique.
C'est là qu'un leadership exécutif fort s'avère essentiel pour faire respecter la politique de redémarrage, car, en particulier dans l'environnement Windows, un correctif n'est pas véritablement installé et le code vulnérable n'est remplacé qu'une fois que le système ou l'application a redémarré.
Certaines organisations laissent à l'utilisateur final le soin de redémarrer le système, et aucune notification n'indique qu'un redémarrage est nécessaire. Les utilisateurs finaux s'adapteront à des politiques plus strictes si celles-ci sont appliquées.
Ils apprendront à redémarrer dès la première ou la deuxième notification — peut-être avant le déjeuner — au lieu de cliquer sur « Report » jusqu’à ce que le redémarrage soit imposé à un moment inopportun.
Lorsque nous travaillons avec un client sur la distribution de logiciels, l'une des premières choses que nous vérifions est la date du dernier redémarrage. Et on constate souvent que 75 % des systèmes d'une organisation doivent être redémarrés. Alors, ces correctifs que vous avez appliqués ? Ce n'est vraiment pas le cas.
Le risque fait partie intégrante de toute discussion concernant les correctifs logiciels
La principale raison pour laquelle les entreprises n'appliquent pas rapidement les correctifs est la crainte de provoquer des dysfonctionnements. Lorsque je m'entretiens avec des vice-présidents et des cadres supérieurs au sujet de la mise à jour des logiciels, la question du risque revient systématiquement dans chaque conversation. « Quel est le risque que mon système reste vulnérable pendant 45 jours, par rapport au risque que je déploie une mise à jour au bout de 30 jours et que cela provoque une panne de mon application ? » C'est la peur de l'inconnu. C'est la crainte d'une perturbation de l'activité.
Si vous disposez d'un plan de test et d'indicateurs de performance, vous pouvez atténuer cette crainte. Même si ce plan de test se résume simplement à : « Déployons cette mise à jour sur plusieurs systèmes et voyons si cela provoque des dysfonctionnements. » Mais vous devriez pouvoir vous rendre compte si quelque chose s'est cassé. Vous devriez disposer de ces données sans avoir à compter sur quelqu'un pour ouvrir un ticket d'incident.
Si les responsables d'applications disposent de données concrètes attestant que les correctifs sont sans danger, ils seront plus enclins à donner leur accord lorsque vous leur annoncerez que vous comptez réduire votre cycle de mise à jour de 30 à 15 jours.
Pour découvrir comment Tanium simplifie la gestion des logiciels tiers d' , n'hésitez pas à consulter les pages suivantes : « » et « 9 Ways Tanium Gives You Control of Your Endpoint Software Environment ».
Si vous êtes prêt à le découvrir en action, rendez-vous sur et inscrivez-vous dès aujourd'hui à une démonstration sur .
