Le « Patch Tuesday », jour où Microsoft publie ses mises à jour logicielles, a lieu une fois par mois, avec une régularité d'horloge. Presque tout le monde (du moins dans le monde de la cybersécurité) le sait, on pourrait donc penser que les équipes informatiques mettraient à jour leurs systèmes dès qu'elles reçoivent l'alerte.
Sauf que ce n'est pas le cas. Une récente étude intitulée « » ( ), menée par Synopsys, a révélé que 28 % des professionnels de l'informatique mettent au moins trois semaines à corriger les vulnérabilités critiques, tandis que 20 % d'entre eux admettent mettre jusqu'à un mois.
À l'heure où les cybercriminels mettent au point de nouvelles attaques ciblant les vulnérabilités, cette approche trop lente de la gestion des correctifs d' expose d'innombrables réseaux et données à un risque accru. C'est comme conduire une voiture dont le voyant d'entretien est allumé : vous savez qu'il y a un problème, mais comme la voiture roule encore, il est facile de remettre la réparation à plus tard.
Une voiture peut mettre des semaines, voire des mois, à tomber en panne après l'allumage du voyant d'entretien. En matière de sécurité, lorsque l'avis de correctif est publié, vous ne disposez que de quelques secondes pour résoudre le problème – si ce n'est pas déjà trop tard –, car les pirates recherchent en permanence les vulnérabilités connues.
« Même si vous êtes protégé par un réseau d’entreprise et que tout est protégé par un pare-feu, ce n’est qu’une question de temps avant que quelqu’un ne parvienne à franchir le périmètre et ne découvre cette vulnérabilité », a déclaré David Brumley, conseiller auprès d’une agence spécialisée dans le renseignement en matière de sécurité logicielle, professeur de cybersécurité à l’université Carnegie Mellon et PDG de ForAllSecure. « Du point de vue de la sécurité, il est préférable d'appliquer les correctifs le plus rapidement possible. »
Les raisons expliquant la lenteur de la mise en place des correctifs
Au cours de l’année écoulée, les équipes informatiques et de sécurité ont été confrontées à des vulnérabilités telles que MOVEit, une faille « zero-day » de MOVEit, un logiciel de transfert de fichiers , susceptible de permettre à des attaquants de prendre le contrôle d’un système ; curl, une attaque « zero-day » visant un outil open source utilisant la syntaxe des URL pour transférer des données ; et l’exploit Apache Superset , une vulnérabilité « zero-day » exposant des configurations et des bases de données. Bien que moins de 100 nouvelles attaques « zero-day » aient été recensées chaque année, celles-ci ont tendance à causer des dégâts considérables, car elles ne visent pas une seule organisation, mais tous les utilisateurs du logiciel. La capacité à toucher un si grand nombre de cibles avec un minimum d'efforts en fait un vecteur d'attaque très prisé des États-nations et des groupes de cybercriminels.
«Même si vous êtes derrière un réseau d’entreprise et que tout est protégé par un pare-feu, ce n’est qu’une question de temps avant que quelqu’un ne parvienne à franchir le périmètre et ne découvre cette vulnérabilité. »David Brumley, conseiller en sécurité informatique et professeur à l'université Carnegie Mellon
Alors, pourquoi les équipes informatiques et de sécurité mettent-elles autant de temps à appliquer les correctifs dès leur publication ?
Le premier défi concerne la visibilité sur l’ : les équipes de sécurité doivent connaître le nombre et les types d’actifs et de terminaux effectivement utilisés sur un réseau, qu’il s’agisse des équipements officiellement autorisés par l’entreprise ou des nombreux autres appareils et applications que les employés utilisent de leur propre initiative. Cette vulnérabilité pourrait provenir, par exemple, d'un « shadow IT » ( ) utilisé par les employés et dont le service informatique n'a pas été informé. Il se pourrait également que l'équipe DevOps utilise des environnements reposant sur des outils qui ne sont plus pris en charge.
Un deuxième facteur qui retarde l'application des correctifs est lié à la visibilité du logiciel – plus précisément, aux composants du logiciel dans lesquels se trouve la vulnérabilité. Trop souvent, lorsqu’une vulnérabilité « zero-day » est annoncée, les équipes de sécurité se rendent compte qu’elles ne disposent pas d’informations suffisantes sur la chaîne d’approvisionnement logicielle de leurs applications et doivent alors se démener pour déterminer si un composant infecté est intégré à l’une des applications utilisées sur leur réseau.
[À lire également : 7 façons de sécuriser votre chaîne d'approvisionnement logicielle]
C'est ce qui s'est passé sur décembre 2021 lorsqu'une vulnérabilité « zero-day » a été identifiée dans Apache Log4j, la célèbre bibliothèque de journalisation Java open source utilisée dans des dizaines de milliers d'applications. Des correctifs ont été publiés peu après, et pourtant, plus de deux ans plus tard, un nombre choquant d'entreprises n'ont toujours pas corrigé cette vulnérabilité. (Une récente enquête menée par l' , disponible à l'adresse , a révélé que 38 % des applications utilisant la version Log4j s'appuient sur une version non sécurisée.)
Pour identifier ces composants incriminés, les entreprises ont de plus en plus recours à une « liste des composants logiciels » (SBOM, ), qui répertorie en détail les composants ou éléments constitutifs de toutes les applications et de tous les programmes utilisés par une organisation. « Pensez aux différents produits qui se trouvent dans votre garde-manger », a expliqué Melissa Bischoping, directrice de la recherche en sécurité des terminaux chez Tanium (propriétaire de ce magazine). Chaque ingrédient présent dans chaque produit fait l'objet d'un suivi rigoureux de la part des fabricants agroalimentaires, ce qui leur permet – en cas, par exemple, d'épidémie de listériose ou d'E. coli – de déterminer avec précision quand et où un ingrédient contaminé a été incorporé dans leur produit. De même, une SBOM facilite le suivi des composants entrant dans la composition d'un logiciel et rend ces informations plus facilement accessibles lorsqu'une vulnérabilité est détectée.
Une troisième raison potentielle expliquant la lenteur de l'application des correctifs est d'ordre commercial.
« L'activité doit se poursuivre, et de nombreux systèmes nécessitent des coupures, des temps d'arrêt ou des redémarrages », a déclaré M. Bischoping. « Cela peut susciter des réticences de la part des chefs d'entreprise ou des équipes opérationnelles, qui estiment que l'application du correctif doit être reportée. »
Il arrive également qu'une vulnérabilité soit connue, que les dirigeants de l'entreprise en soient informés et qu'ils s'engagent à appliquer le correctif, mais qu'il ne soit pas possible d'agir tant que le fournisseur n'a pas publié ce correctif. Ce problème se pose tout particulièrement dans le cas des logiciels libres ou des systèmes utilisant des composants libres.
« Il faut attendre que les fournisseurs mettent à jour leurs logiciels », ajoute M. Bischoping. « Cela signifie qu’il faut attendre qu’un écosystème tout entier rende ces mises à jour disponibles, puis disposer des processus, des technologies et des politiques nécessaires pour faciliter leur mise en œuvre dans notre environnement. »
Pourquoi un moment de répit est parfois si tentant
Certains de ceux qui tardent à installer les correctifs prétendent avoir une excuse : ils craignent que l'application immédiate du correctif ne finisse par causer davantage de dégâts.
«Les pannes, les temps d’arrêt ou les redémarrages… peuvent susciter des réticences de la part des chefs d’entreprise ou des équipes opérationnelles, qui estiment que l’application du correctif doit attendre. »Melissa Bischoping, directrice de la recherche en sécurité des terminaux chez Tanium
« L'application de correctifs introduit des inconnues », a déclaré M. Brumley. En tant qu'utilisateur, vous ne savez pas combien de temps la mise à jour va prendre, si l'application du correctif risque de perturber le fonctionnement des systèmes, ni quel problème vous résolvez ou prévenez.
Du point de vue d'un développeur, il peut s'avérer difficile de préserver la stabilité du code existant. « Lorsque vous avez écrit le code, il fonctionnait très bien. » « Mais désormais, lorsque vous devez effectuer une mise à jour, le développeur ne sait pas où cette dépendance présente une nouvelle instabilité », a-t-il fait remarquer.
Les développeurs reçoivent des messages contradictoires lorsqu'on leur demande d'appliquer un correctif. D'une part, il s'agit de mettre à jour tous les éléments vulnérables le plus rapidement possible, et d'autre part, de veiller à ce que rien ne tombe en panne. « C'est justement cela, a ajouté Brumley, qui permet aux développeurs d'évaluer leur travail : ils souhaitent créer un code robuste plutôt que d'avoir à le corriger. »
Afin d'alléger la charge de travail des développeurs et de réduire la tentation d'attendre que les correctifs dont on ignore les effets soient vérifiés, les équipes informatiques et de sécurité pourraient (et devraient) adopter une approche « sécurité dès la conception » ( ) . Cette approche vise à éliminer autant que possible les vulnérabilités grâce à des tests continus et à l'intégration de mesures de protection en matière d'authentification dans le processus de développement. La stratégie nationale de cybersécurité « » (), publiée par la Maison Blanche en 2023, recommande vivement aux organisations d'adopter des protocoles de « sécurité dès la conception ». Selon l'Agence américaine pour la cybersécurité et la sécurité des infrastructures (CISA), l'adoption d'une approche « sécurisée dès la conception » permettra de mieux combler les lacunes en matière de cybersécurité, notamment le délai qui s'écoule entre la publication d'un correctif et son application.
Tant que nous n'aurons pas atteint un stade où la « sécurité dès la conception » sera la norme dans toutes les organisations, nous aurons besoin d'un processus adapté aux équipes informatiques, de sécurité et de développement afin de garantir une accélération du rythme des correctifs.
La mise à jour des correctifs commence par la définition de règles
Contrairement à un particulier qui, depuis son ordinateur personnel, installe les mises à jour de Chrome et de Windows, la gestion des correctifs dans un environnement professionnel commence par l'élaboration de politiques, selon Kyle Miller, associé au sein du groupe mondial chargé de la protection des données et de la cybersécurité chez Dentons.
«Si un outil surveille 80 % de vos applications, alors 20 % de vos applications présenteront un risque disproportionné de vulnérabilité, car elles ne figurent pas dans votre outil de gestion des correctifs. »Kyle Miller, associé chez Dentons
« Il faut commencer par consigner par écrit les politiques et les procédures relatives à la gestion des correctifs », a déclaré M. Miller. Cela permet d'assurer un contrôle organisationnel afin de garantir que toute personne chargée de la mise en œuvre du correctif connaisse les attentes de l'entreprise.
« La plupart des entreprises avec lesquelles je travaille prévoient une plage horaire en dehors des heures de travail pour installer les correctifs de routine », a déclaré M. Miller. « Mais ils ont également besoin d'un processus permettant d'approuver la correction des failles critiques lorsque cela s'avère nécessaire, et parfois, cela doit se faire le plus rapidement possible. » Pour cela, il est nécessaire de dresser un inventaire des systèmes afin de pouvoir identifier les risques potentiels et l'origine du correctif.
L'une des raisons pour lesquelles les mises à jour sont effectuées en dehors des heures de travail est qu'elles permettent de réduire les temps d'arrêt qui en découlent. Et si les correctifs sont appliqués manuellement – ce qui est un processus fastidieux –, c'est souvent le seul moment où les équipes de sécurité peuvent s'en occuper.
Cela plaide en faveur à la fois de l'automatisation des processus métier ( ) et de l' par l'IA. L'automatisation du processus d'application des correctifs permettra non seulement de réduire le recours à l'intervention manuelle pour une tâche par ailleurs répétitive, mais aussi de traiter plus rapidement les mises à jour, ce qui, par conséquent, réduira la durée d'exposition aux vulnérabilités. L'automatisation du processus de correction peut également renforcer la position de l'entreprise en matière d'objectifs de conformité, en réduisant le risque qu'une faille de sécurité ne conduise à une fuite de données. Les organisations peuvent également recourir à des solutions d' basées sur l'IA, qui permettent de hiérarchiser les vulnérabilités en fonction des risques critiques et d'appliquer les correctifs en fonction de cette hiérarchie.
Il existe toute une gamme d'outils de gestion des correctifs, mais M. Miller souligne que, pour qu'un outil soit efficace, il doit être adapté à vos besoins spécifiques.
« Si un outil surveille 80 % de vos applications, alors 20 % de celles-ci présenteront un risque disproportionné de vulnérabilité, car elles ne figurent pas dans votre outil de gestion des correctifs », a déclaré M. Miller. De même, les outils de gestion des correctifs qui permettent d'identifier les anciennes versions de vos systèmes internes ne sont utiles que si un responsable de la sécurité examine ces notifications et met ces systèmes à jour.
Cela dit, vous devez également vous méfier de la prolifération des outils d' . Un nombre trop élevé d'outils peut en réalité nuire à l'efficacité de la mise à jour des correctifs et à la cybersécurité en général. Pour optimiser le processus de mise à jour, les équipes informatiques et de sécurité auront tout intérêt à évaluer les outils dont elles disposent déjà, à identifier les redondances et les lacunes éventuelles, à déterminer l'efficacité de chacun (ces outils permettent-ils réellement de résoudre les problèmes de sécurité auxquels vous êtes confrontés aujourd'hui ou sont-ils compatibles avec les systèmes actuellement en place ?) et à déterminer comment ces outils peuvent au mieux réduire les tâches manuelles grâce à des processus de mise à jour automatisés .
« Il faut à la fois acquérir l’outil, s’assurer qu’il est adapté à votre système et qu’il est mis en œuvre de manière appropriée, puis veiller à ce qu’il soit surveillé par votre équipe informatique interne », a déclaré M. Miller.
Améliorer votre culture de la correction
Quels que soient les outils utilisés, les politiques mises en place ou la qualité du code au stade du développement, des vulnérabilités apparaîtront toujours. Conscientes de cette réalité, les entreprises doivent faire évoluer leur culture en matière d'application des correctifs. Une façon d'y parvenir consiste à mettre en place un programme de gestion des vulnérabilités .
« La mise en place d’un véritable programme de gestion des vulnérabilités fait partie intégrante de la mise en place d’un programme efficace de gestion des correctifs », a déclaré M. Bischoping, de Tanium.
On pourrait croire que c'est la même chose, mais ce n'est pas le cas. La gestion des vulnérabilités consiste à évaluer les menaces et leur impact potentiel sur votre environnement. Certaines peuvent représenter un danger extrême pour la sécurité de votre organisation, tandis que d'autres vulnérabilités de gravité élevée ne sont peut-être pas exploitables dans votre système.
Outre la mise en place de programmes de gestion des vulnérabilités, les organisations doivent améliorer la formation à la sensibilisation à l' de la sécurité en général. Montrer aux utilisateurs les conséquences de systèmes non sécurisés, insister sur les dangers liés aux vulnérabilités non corrigées et mettre en place des politiques et des procédures visant à rationaliser le système aideront les équipes informatiques et de sécurité à mieux relever les défis qui empêchent l'application des correctifs en temps voulu.
