Patch Tuesday, le jour où Microsoft publie ses mises à jour logicielles, vient une fois par mois comme le travail d’horloge. Presque tout le monde (du moins dans le monde de la cybersécurité) le sait, vous pensez donc que les équipes informatiques mettront à jour leurs systèmes dès qu’elles recevront l’alerte.
Sauf si ce n’est pas le cas. Une étude récente 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’autres admettent prendre jusqu’à un mois.
À une époque où les acteurs malveillants développent de nouvelles attaques ciblant les vulnérabilités, cette approche lente de la gestion des correctifs expose d’innombrables réseaux et données à un risque plus élevé. C’est comme conduire une voiture avec le voyant de service allumé : vous savez qu’il y a un problème, mais parce que la voiture fonctionne toujours, il est facile de la remettre à plus tard.
Une voiture peut mettre des semaines ou des mois à échouer après l’allumage de ce témoin de service. En matière de sécurité, lorsque l’avis de correctif arrive, vous disposez de quelques secondes pour résoudre le problème, s’il n’est pas déjà trop tard, car les méchants recherchent continuellement des vulnérabilités connues.
« Même si vous êtes derrière un réseau d’entreprise et que les choses sont pare-feu, il ne s’agit que d’une question de temps jusqu’à ce que quelqu’un entre dans le périmètre et trouve cette vulnérabilité », a déclaré David Brumley, conseiller en agence de renseignement sur la sécurité logicielle, professeur de cybersécurité à l’Université Carnegie Mellon et PDG de ForAllSecure. « Du point de vue de la sécurité, vous souhaitez appliquer des correctifs aussi rapidement que possible. »
Raisons de la lenteur des correctifs
Au cours de l’année passée, les équipes informatiques et de sécurité ont été confrontées à des vulnérabilités telles que MOVEit, un défaut zero-day de transfert de fichiers qui pouvait permettre aux attaquants de prendre le contrôle d’un système ; curl, une attaque zero-day contre un outil open-source qui utilise la syntaxe URL pour transférer des données ; et l’exploit Apache Superset , une vulnérabilité zero-day exposant les configurations et les bases de données. Bien que moins de 100 nouvelles attaques zero-day aient été introduites chaque année, elles ont tendance à causer des dommages considérables, car elles ne ciblent pas seulement une seule organisation, mais toutes les personnes qui utilisent le logiciel. La capacité à frapper autant de cibles avec un effort minimal en fait un vecteur d’attaque populaire pour les États-nations et les gangs de cybercriminels.
« Même si vous êtes derrière un réseau d’entreprise et que les choses sont protégées par un pare-feu, ce n’est qu’une question de temps avant que quelqu’un n’entre dans le périmètre et ne trouve cette vulnérabilité. »David Brumley, conseiller et professeur en sécurité logicielle, Carnegie Mellon University
Alors, pourquoi faut-il autant de temps aux équipes informatiques et de sécurité pour appliquer des correctifs lorsqu’ils sont introduits ?
Le premier défi concerne la visibilité : les équipes de sécurité doivent connaître le nombre et les types d’actifs et d’endpoints qui sont réellement utilisés sur un réseau, à la fois l’équipement officiellement sanctionné de l’entreprise et les nombreux autres appareils et applications que les employés introduisent eux-mêmes. La vulnérabilité pourrait être dans l’ informatique parallèle utilisée par les employés et non révélée au personnel informatique, par exemple. Ou l’équipe DevOps peut utiliser des environnements s’appuyant sur des outils non pris en charge.
Un second facteur qui retarde les correctifs concerne la visibilité des logiciels, en particulier les composants du logiciel où se trouve la vulnérabilité. Trop souvent, lorsqu’une vulnérabilité zero-day est annoncée, les équipes de sécurité réalisent qu’elles n’en savent pas assez sur leur chaîne d’approvisionnement logicielle et doivent s’efforcer de 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 défendre votre chaîne d’approvisionnement logicielle]
C’est ce qui s’est passé décembre 2021 lorsqu’une vulnérabilité zero-day a été identifiée dans Apache Log4j, la bibliothèque de journalisation Java open source populaire utilisée dans des dizaines de milliers d’applications. Les correctifs ont été publiés peu de temps après et pourtant, plus de deux ans plus tard, un nombre choquant d’entreprises n’ont pas corrigé la vulnérabilité. (Une enquête récente a révélé que 38 % des applications utilisant Log4j dépendent d’une version non sécurisée.)
Pour localiser ces composants responsables, les entreprises se tournent de plus en plus vers une nomenclature logicielle (SBOM), qui énonce les composants ou les ingrédients de toutes les applications et programmes logiciels utilisés par une organisation. « Pensez aux différents éléments de votre garde-manger », a expliqué Melissa Bischoping, directrice de la recherche sur la sécurité des endpoints chez Tanium (qui possède ce magazine). Chaque ingrédient de chaque article est bien suivi par les fabricants alimentaires, ce qui leur permet, dans le cas d’une épidémie de listéria ou d’E. coli, de déterminer exactement quand et où un ingrédient contaminé a été mélangé à leur produit. De même, une SBOM facilite le suivi des composants de construction logicielle et rend ces informations plus facilement disponibles lorsqu’une vulnérabilité est détectée.
Une troisième raison potentielle de la lenteur des correctifs se résume à l’activité.
« L’entreprise doit continuer, et de nombreux systèmes nécessitent des pannes, des temps d’arrêt ou des redémarrages », a déclaré Bischoping. « Cela peut entraîner un repoussage de la part des chefs d’entreprise ou des équipes opérationnelles qui disent que le correctif doit attendre. »
Ensuite, il y a des moments où une vulnérabilité est connue et où les dirigeants d’entreprise sont informés et engagés à faire le correctif, mais rien ne peut être fait jusqu’à ce que le fournisseur publie ce correctif. Il s’agit particulièrement d’un problème dans les logiciels ou systèmes open source qui utilisent des composants open source.
« Vous devez attendre que les fournisseurs mettent à jour leur logiciel », ajoute Bischoping. « Cela signifie attendre qu’un écosystème entier rende ces mises à jour disponibles, puis avoir les processus, technologies et politiques en place pour faciliter les mises à jour dans notre environnement. »
Pourquoi un correctif lent est parfois si tentant
Certains procrastinateurs de correctifs affirment qu’ils ont une excuse : ils craignent que l’application immédiate du correctif puisse finir par faire plus de mal.
« Les pannes, les temps d’arrêt ou les redémarrages... peuvent entraîner un repoussage de la part des chefs d’entreprise ou des équipes opérationnelles qui disent que le correctif doit attendre. »Melissa Bischoping, directrice de la recherche sur la sécurité des endpoints, Tanium
« L’application de correctifs introduit des inconnues », a déclaré Brumley. En tant qu’utilisateur, vous ne savez pas combien de temps la mise à niveau prendra, si les systèmes se briseront en appliquant la solution, ou quel problème vous résolvez ou prévenez.
Du point de vue du développeur, il peut être difficile de maintenir la stabilité du code existant. « Lorsque vous avez écrit le code, cela fonctionnait bien. Mais maintenant, lorsque vous devez mettre à jour, le développeur ne sait pas où la dépendance a une nouvelle instabilité », a-t-il noté.
Les développeurs reçoivent des messages contradictoires lorsqu’on leur demande d’appliquer un correctif. L’une consiste à mettre à niveau toutes les pièces vulnérables le plus rapidement possible, et l’autre consiste à s’assurer que rien ne casse. Le second, a ajouté Brumley, est la manière dont les développeurs évaluent leur travail : ils veulent créer un code solide plutôt que d’avoir à le corriger.
Pour alléger une partie du fardeau des développeurs et réduire la tentation d’attendre que les correctifs inconnus soient vérifiés, les équipes informatiques et de sécurité pourraient (et devraient) déployer une approche de sécurité dès la conception . Cette approche vise à éliminer les vulnérabilités autant que possible grâce à des tests continus et à l’intégration de protections 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 la Cybersecurity and Infrastructure Security Agency (CISA), devenir sécurisé par conception permettra de mieux combler les lacunes en matière de cybersécurité, y compris cet espace entre une version de correctif et une application de correctif.
Jusqu’à ce que nous ayons atteint un point où la sécurité dès la conception est la norme dans toutes les organisations, nous aurons besoin d’une sorte de processus qui fonctionnera pour les équipes informatiques, de sécurité et de développement pour s’assurer que les correctifs prennent le rythme.
L’application de correctifs commence par des politiques
Contrairement à une personne assise sur un ordinateur personnel et appliquant des mises à jour à Chrome et Windows, traiter les correctifs dans un contexte commercial commence par la création de politiques, selon Kyle Miller, un partenaire du groupe mondial de confidentialité et de cybersécurité des données de Dentons.
« Si un outil surveille 80 % de vos applications, 20 % de vos applications présenteront un risque considérable d’être non sécurisé car elles ne sont pas dans votre outil de gestion des correctifs. »Kyle Miller, partenaire, Dentons
« Le point de départ consiste à documenter les politiques et procédures de gestion des correctifs », a déclaré M. Miller. Cela fournit un contrôle organisationnel pour s’assurer que quiconque met en œuvre le correctif connaît les attentes de l’entreprise.
« La plupart des entreprises avec lesquelles je travaille mettront de côté une fenêtre en dehors des heures ouvrables pour appliquer des correctifs de routine », a déclaré M. Miller. « Mais ils ont également besoin d’un processus pour approuver l’application de correctifs aux vulnérabilités critiques si nécessaire, et parfois aussi rapidement que possible. » Cela nécessite d’effectuer un inventaire des systèmes afin que vous puissiez identifier les risques potentiels et la source du correctif.
L’une des raisons pour lesquelles les correctifs sont effectués en dehors des heures ouvrables est qu’ils réduisent les temps d’arrêt impliqués. Et si les correctifs sont effectués manuellement, un processus long, c’est souvent le seul moment où les équipes de sécurité peuvent y accéder.
Cela vaut à la fois pour l’ automatisation et l’IA. L’automatisation du processus d’application de correctifs réduira non seulement le besoin d’intervention manuelle sur une tâche autrement répétitive, mais permettra également une attention plus rapide aux mises à jour, ce qui, à son tour, raccourcit la fenêtre de vulnérabilité. L’automatisation du processus d’application de correctifs peut également améliorer la position de l’entreprise sur les objectifs de conformité en réduisant le risque d’exploitation entraînant une violation de données. Les organisations peuvent également se tourner vers l’IA, qui peut hiérarchiser les vulnérabilités en fonction des risques critiques et atténuer les correctifs en fonction de cette priorité.
Il existe un éventail d’outils de gestion des correctifs disponibles, mais Miller avertit que pour que tout outil soit efficace, il doit être adapté à vos besoins spécifiques.
« Si un outil surveille 80 % de vos applications, alors 20 % de vos applications présenteront un risque exagéré d’être non sécurisé car elles ne sont pas dans votre outil de gestion des correctifs », a déclaré Miller. De même, les outils de gestion des correctifs qui peuvent aider à identifier les anciennes versions de vos systèmes internes ne sont utiles que si un membre du personnel de sécurité examine ces notifications et met ces systèmes à jour.
Cela dit, vous devez également faire attention à la prolifération des outils. Un trop grand nombre d’outils peut en fait entraver l’application efficace de correctifs et la cybersécurité globale. Pour le processus d’application de correctifs le plus efficace, les équipes informatiques et de sécurité voudront évaluer les outils dont elles disposent déjà, identifier les redondances et tous les domaines non couverts, déterminer l’efficacité de chacun (les outils répondent même aux problèmes de sécurité que vous avez aujourd’hui ou travaillent avec les systèmes actuellement en place) et déterminer comment les outils peuvent le mieux réduire les tâches manuelles grâce à des processus d’application de correctifs automatisés.
« Il doit y avoir une combinaison d’acquisition de l’outil et de s’assurer qu’il est adapté à votre système et mis en œuvre de manière appropriée, puis surveillé par votre équipe informatique interne », a déclaré M. Miller.
Améliorer votre culture d’application de correctifs
Quels que soient les outils utilisés, les politiques mises en place ou la solidité du code au stade du développement, les vulnérabilités apparaîtront toujours. Reconnaissant cette réalité, les entreprises doivent changer leur culture autour de l’application de correctifs. Une façon de le faire est de créer un programme de gestion des vulnérabilités .
« La création d’un programme réel de gestion des vulnérabilités fait partie de la création d’un programme efficace de gestion des correctifs », a déclaré Bischoping de Tanium.
Ils peuvent sembler identiques, mais ce n’est pas le cas. La gestion des vulnérabilités évalue les menaces et la manière dont chacune peut affecter votre environnement. Certaines peuvent être extrêmement dangereuses pour la sécurité de votre organisation, tandis que d’autres vulnérabilités de haute gravité peuvent ne pas être exploitables dans votre système.
Outre la création de programmes de gestion des vulnérabilités, les organisations doivent améliorer la formation globale à la sensibilisation à la sécurité. Montrer aux utilisateurs les effets des systèmes non sécurisés, souligner les dangers des vulnérabilités non corrigées et élaborer des politiques et procédures qui rationalisent le système aidera les équipes informatiques et de sécurité à mieux relever les défis qui empêchent l’application de correctifs en temps opportun.
