Réflexions sur le temps de déploiement des correctifs
Les organisations essaient souvent d'appliquer des correctifs à leurs systèmes "à temps" afin de se protéger contre les nouvelles menaces. Dans ce contexte, "à temps" n'aura pas la même signification pour toutes les organisations - certaines s'efforceront d'appliquer les correctifs dans le mois qui suit la divulgation d'une vulnérabilité, d'autres le feront dès qu'un correctif sera disponible (ce qui est possible avec le correctifs en directpar exemple), tandis que d'autres encore le feront dès que les besoins de l'entreprise permettront le temps d'arrêt nécessaire.
Mais comptons-nous le temps de la bonne façon ? Que signifie vraiment "à temps" lorsqu'on parle de correctifs ?
A l'heure
Prenons l'exemple d'une vulnérabilité quelque peu inoffensive qui vient d'être annoncée : CVE-2023-25136 - une vulnérabilité d'OpenSSH dans le processus de pré-authentification causée par la tentative de "libérer" une variable déjà libérée, causant ainsi potentiellement des problèmes. Elle a été divulguée publiquement le 3 février, et certains registres CVE manquent encore de détails à son sujet.
Sans tenir compte de l'absence (apparente) de risque, et en supposant qu'il s'agisse d'une vulnérabilité à haut risque, que signifierait l'application d'un correctif "à temps" pour cette faille ? Si vous appliquez un correctif aujourd'hui (au moment de la rédaction de cet article), vous le feriez dans la semaine suivant l'annonce publique de la faille, ce qui serait déjà pas mal, et vous pourriez considérer que votre infrastructure est à nouveau sécurisée - ce qui est un délai solide à la lumière d'une étude de l'année dernière montrant qu'une majorité d'organisations prenaient plus d'un mois pour corriger les vulnérabilités à haut risque. Toutes les bonnes cases seraient cochées, votre responsable de la conformité serait très heureux, et vous pourriez retourner à vos activités habituelles.
Considérons maintenant que la vulnérabilité a, en fait, été signalée en janvier à l'équipe OpenSSH, et que des messages ont été échangés dans la liste de diffusion publique à ce sujet autour du 15 janvier. Cela ajoute deux semaines supplémentaires d'information publique sur un bogue potentiellement générateur de crash avant que la divulgation du CVE n'ait lieu. Et il ne s'agit là que de l'aspect visible d'un bug qui déclenche un CVE. L'échelle de temps peut être complètement différente si le bug n'a pas été signalé à la bonne équipe en premier lieu. Par exemple, s'il a été vendu comme un exploit zero-day sur un forum louche quelque part. Dans le cas de cette vulnérabilité spécifique, même si vous la corrigez le jour de l'annonce de la CVE, vous serez potentiellement en danger pendant deux semaines.
CVE surévalués
Ainsi, "à temps" signifie en réalité "depuis qu'il a été officiellement divulgué publiquement" ou "depuis qu'il a reçu un numéro CVE", et non "depuis qu'il est connu". Il y a des situations où les premières informations sur un bogue ont lieu des mois avant l'apparition d'un CVE. Vous vous êtes déjà demandé pourquoi certains CVE ont un indicateur d'année de l'année précédente ? C'est parce qu'ils ont été découverts l'année précédente et que l'ensemble du processus d'analyse, de création de correctifs et de publication a pris plusieurs mois. Et ce processus se déroule souvent au vu et au su de tous, sous la forme de rapports de bogues et de discussions sur github ou sur des listes de diffusion.
Et c'est là que la conversation peut dérailler - vous ne pouvez pas avoir un système non sécurisé s'il n'y a même pas de CVE pour vous en informer, n'est-ce pas ? Malheureusement, c'est la mauvaise question.
Toutes les vulnérabilités n'ont pas de CVE attribué. Par exemple, l'équipe chargée de la sécurité du noyau introduit chaque semaine des correctifs pour de nouvelles vulnérabilités sans qu'aucun CVE (connu du public) ne leur soit attribué - en partie parce que cela fournirait aux acteurs malveillants un vecteur pour les systèmes non corrigés, et en partie parce que le système CVE lui-même présente une série d'inefficacités. Pour en savoir plus ici.
L'industrie de la cybersécurité se concentre sur les CVE. Nous créons, suivons, classons par ordre de priorité, appliquons des correctifs et élaborons des stratégies pour contourner ceux que nous ne pouvons pas corriger, mais les CVE ne sont que la partie émergée de l'iceberg proverbial.
Minimiser la fenêtre de risque
Si votre seule mesure de la sécurité est le nombre de CVE que vous corrigez dans un délai donné, par exemple pour satisfaire aux exigences de conformité, alors vous êtes probablement un peu moins "sûr" que vous ne le pensez. La fenêtre de risque ne commence pas à l'annonce d'un CVE, mais quelque temps avant, et la durée de cette période est incertaine, donc votre meilleure chance est de raccourcir la fenêtre de risque autant que possible. Vous ne contrôlez que l'heure de fermeture de la fenêtre de risque. Ce risque implicite en dit long lorsque les organisations mettent un mois ou plus à appliquer un correctif - en plus de tout ce qui se passe avant.
Bien sûr, il n'est pas vraiment possible d'appliquer un correctif avant qu'il ne soit publié, mais toutes les mesures doivent être prises pour s'assurer que vous appliquez un correctif dès que possible plutôt que de prendre des semaines pour traiter une nouvelle vulnérabilité.
Le délai (parfois long) avant qu'une vulnérabilité ne soit effectivement divulguée devrait être la meilleure raison d'adopter une approche plus rapide des correctifs. Les acteurs de la menace surveillent activement les rapports de bogues à la recherche de nouvelles opportunités et disposent des compétences nécessaires pour "armer" rapidement les bogues.
N'aidez pas les pirates - ils n'en ont pas besoin. Correctif maintenant.