Ce guide détaillé explique pourquoi les équipes de sécurité sont submergées de vulnérabilités, le danger qui se cache derrière le double signalement des vulnérabilités et comment atténuer ces vulnérabilités à l'aide d'outils de correctifs en direct comme KernelCare.
Nous savons que la menace de cybersécurité augmente, avec une croissance correspondante des efforts pour essayer d'atténuer la menace et les coûts associés. Mais les preuves suggèrent que l'atténuation ne progresse pas assez rapidement.
Selon une analyse conjointe réalisé par McAfee et le Centre d'études stratégiques et internationales , 2020 verra le coût mondial de la cybercriminalité dépasser 1 milliard de dollars marquer pour la première fois - une augmentation massive de 50% par rapport au total de 2018. Il s'agit d'un taux de variation nettement supérieur à toute mesure comparable telle que la croissance du PIB ou la croissance des dépenses informatiques.
La sensibilisation n'est pas le problème :après tout, les entreprises dépensent des sommes considérables pour se défendre contre les cybermenaces.
Au lieu de cela, dans cet article, nous soutenons que les acteurs de la cybersécurité sont essentiellement dépassés par les défis auxquels ils sont confrontés. Nous soulignons un événement récent de double signalement de vulnérabilités connues comme preuve évidente.
Continuez votre lecture pour découvrir pourquoi les équipes de sécurité sont submergées par les vulnérabilités, leur impact sur les correctifs et ce que les équipes peuvent faire pour appliquer des correctifs de manière cohérente face à un assaut incessant de vulnérabilités et d'exploits.
Encore une autre vulnérabilité ?
Au cours du second semestre de l'année dernière, une vulnérabilité du noyau Linux a été découverte et signalée. Il a été attribué un C V commun vulnérabilités et E numéro d'exposition (CVE), CVE-2020-29369 , et la vulnérabilité a été corrigée comme prévu. Pour l'instant rien d'inhabituel.
Il n'y avait rien non plus d'extraordinaire dans la vulnérabilité elle-même. Dans n'importe quel système d'exploitation, le noyau doit gérer soigneusement la mémoire - en attribuant (cartographiant) l'espace mémoire lorsqu'une application en a besoin, et en supprimant correctement les allocations et en réattribuant la mémoire libre lorsqu'une application n'en a plus besoin.
Cependant, ce processus de gestion de l'espace mémoire peut être sujet à des problèmes. Lorsqu'ils sont codés sans le soin nécessaire, les processus de gestion de la mémoire du noyau peuvent donner une opportunité aux cybercriminels. Dans le cas de CVE-2020-29369, le problème s'est produit dans la fonction mmap qui est utilisée pour le mappage de la mémoire sous Linux.
La nature de la vulnérabilité signifiait que deux applications distinctes pouvaient demander l'accès au même espace mémoire, ce qui entraînait un plantage du noyau.
Si un attaquant jouait correctement ses cartes - en d'autres termes, créait un exploit - l'attaquant serait capable de saisir des données qui seraient autrement protégées par le noyau. Il peut s'agir de données complètement anodines ou de quelque chose de plus précieux, comme des données personnelles ou des mots de passe précieux.
L'histoire de deux rapports de vulnérabilité
Nous pouvons donc voir qu'une vulnérabilité typique a été signalée et acceptée selon les procédures habituelles. Mais quelque chose de déconcertant s'est produit ensuite.
Quelques mois plus tard, exactement la même vulnérabilité a été signalée. Encore une fois, un numéro CVE a été attribué, cette fois CVE-2020-20200 . Cependant, il s'est rapidement avéré que la nouvelle alerte de vulnérabilité était un doublon d'une autre vulnérabilité - CVE-2020-29369.
Les chercheurs qui ont "trouvé" la vulnérabilité une deuxième fois pour une raison ou une autre n'ont pas réussi à trouver la première instance de la vulnérabilité avant de demander une autre réservation CVE pour ce qu'ils avaient découvert. L'une des principales intentions des bases de données CVE est d'éviter les doubles déclarations, mais dans ce cas particulier, une autre CVE a néanmoins été demandée.
Ce cas de ce qu'on appelle le "double signalement" n'est pas la première ou la seule instance d'une vulnérabilité signalée deux fois. Pire encore, lorsque les enquêtes sur une vulnérabilité arrivent au point où une CVE a été attribuée, la vulnérabilité aura déjà été examinée par de nombreux experts en sécurité hautement qualifiés.
Même les chercheurs en sécurité peuvent tout mélanger
Dans cet exemple de double signalement, il est clair que les chercheurs en sécurité auraient dû être conscients de la vulnérabilité existante ou auraient dû trouver le CVE existant s'ils avaient suffisamment recherché la « nouvelle » vulnérabilité avant de demander un nouveau numéro CVE.
C'est une pensée inquiétante. Cette vulnérabilité de mappage de mémoire se trouve au cœur du noyau Linux, mais les chercheurs en sécurité n'en étaient apparemment pas conscients, d'où la double liste. Pire encore, ce n'est pas comme si chaque liste était séparée d'une décennie ou même d'années :les listes individuelles de la même vulnérabilité ont été faites à quelques mois d'intervalle, une en août 2020 et une en novembre 2020.
Les chercheurs en sécurité sont-ils négligents ? Non. Les chercheurs en sécurité sont tout simplement complètement submergés par le volume des défis en matière de cybersécurité. C'est pourquoi, dans cet exemple, les experts en sécurité du noyau Linux ont manqué un rapport existant sur une vulnérabilité potentiellement critique.
Le danger caché derrière le double signalement des vulnérabilités
Des preuves évidentes que la menace de cybersécurité augmente, combinées à des exemples où même les experts en sécurité se trompent, suggèrent que le double signalement a des implications plus importantes qu'il ne semble en avoir à première vue.
Cela ne signifie pas que les experts en sécurité Linux sont sujets aux erreurs et aux oublis. Cela suggère simplement que le travail de gestion des vulnérabilités de sécurité est devenu si incroyablement difficile que même les experts ont du mal à suivre.
Considérez un instant une équipe technologique interne typique qui a un mandat complet - oui, y compris la sécurité, mais couvrant également la maintenance, les opérations et un nombre infini d'autres responsabilités.
Même lorsque les équipes d'entreprise disposent d'experts en sécurité dédiés, il est probable que cette expertise doive être appliquée à une gamme de menaces et d'outils technologiques. Il serait extrêmement rare, même pour une grande entreprise, d'employer un expert en sécurité du noyau Linux. Et même s'ils le faisaient, comme nous l'avons vu, ces experts en sécurité peuvent se tromper.
Les équipes informatiques ont des temps difficiles à venir
Les équipes sur site géreront toujours les vulnérabilités de sécurité dans une certaine mesure. En répondant aux nouvelles d'exploits majeurs, par exemple, et en appliquant des correctifs en conséquence. Les avertissements des fournisseurs peuvent également inciter à l'action, et la plupart des bons services informatiques auront un certain type de régime de correctifs qui garantit que les correctifs sont appliqués à des intervalles définis.
Mais comment les équipes informatiques peuvent-elles de manière réaliste faire face à une pile croissante de CVE qui affectent les distributions Linux à tous les niveaux, entrant quotidiennement. Par exemple, un régime de correctifs trimestriel offre-t-il vraiment une sécurité suffisante ? Et oui, les correctifs sont importants , mais doit-il dominer l'activité au détriment de tout le reste - ce qui peut facilement arriver compte tenu du volume de correctifs ?
Il est facile de voir que les équipes informatiques auront du mal à garder une longueur d'avance sur la liste sans cesse croissante des vulnérabilités.
Mettez en place votre régime de correctifs
Formaliser votre régime de correctifs est la première étape pour essayer de faire face à la montagne de CVE. Les correctifs ad hoc basés sur des reportages alarmants ne sont pas la solution - il y a tout simplement trop de vulnérabilités, et relativement peu sont largement connues - laissant d'innombrables vulnérabilités cachées et exploits associés qui représentent un danger.
Néanmoins, l'une des étapes clés de la création d'un régime de correctifs consiste à prioriser les correctifs. Les vulnérabilités critiques largement connues doivent être corrigées rapidement, sans délai et en sacrifiant la disponibilité si nécessaire. Des correctifs pour les vulnérabilités à risque moyen et faible peuvent être programmés pour s'adapter aux charges de travail des équipes techniques ou pour éviter les problèmes de disponibilité.
Une autre étape clé consiste à établir un inventaire suffisamment complet du matériel et des logiciels qui nécessitent des correctifs. Certaines cibles à corriger seront immédiatement évidentes, mais d'autres peuvent facilement être manquées.
Lors de la constitution de votre inventaire, vous pouvez également identifier certaines possibilités de normalisation, c'est-à-dire mettre à niveau le logiciel vers la même version ou consolider les fournisseurs pour faciliter la gestion des correctifs.
Enfin, il vaut la peine de codifier votre régime de correctifs dans une politique de correctifs formelle. Il est difficile d'appliquer des correctifs de manière cohérente, et il suffit d'un seul échec pour ouvrir la porte au désastre. Un régime de correctifs codifié peut aider votre équipe à rester sur la bonne voie en matière de correctifs, année après année.
Le compromis avec les correctifs
Avec tout régime de correctifs, il y a généralement un compromis à faire entre la disponibilité et la sécurité. Oui, vous pouvez corriger de manière hautement sécurisée - en appliquant les correctifs dès qu'ils sont publiés. Mais les correctifs ont inévitablement un impact sur la disponibilité, car les correctifs nécessitent souvent des redémarrages du serveur.
En fait, certaines entreprises peuvent avoir des exigences commerciales spécifiques qui empêchent la mise hors service de services ou de serveurs pour appliquer des correctifs même si un CVE critique apparaît, ce qui peut rendre les services vulnérables à un nouvel exploit.
Même lorsque vous pouvez mettre les serveurs hors ligne pour la maintenance, les services sont dégradés et, par conséquent, l'expérience de l'utilisateur final est dégradée. Pensez à un détaillant en ligne avec des milliers de clients en ligne qui met soudainement la moitié de ses serveurs hors ligne pour maintenance, par exemple.
Ensuite, il y a aussi la pression sur les équipes techniques qui sacrifient inévitablement le temps consacré à d'autres tâches pour consacrer du temps aux correctifs. Les équipes de sécurité pourraient simplement être complètement submergées par le fardeau des correctifs. Il existe cependant une alternative.
Envisagez d'utiliser des outils de correction automatisés
Nous avons identifié deux problèmes clés derrière les régimes de correctifs standard :le temps et les efforts requis par les correctifs, et les perturbations associées aux correctifs. Une solution qui mérite d'être envisagée est l'application de correctifs automatisés, et encore plus s'il s'agit d'un correctif automatisé sans redémarrage qui applique les correctifs sans nécessiter de redémarrage du serveur.
Les outils de correctifs automatisés surveillent en permanence les versions de correctifs et appliquent ces correctifs automatiquement sans intervention. Il élimine le besoin de consacrer de la main-d'œuvre aux flottes de serveurs de correctifs - les correctifs se déroulent simplement de manière transparente en arrière-plan. Avec les correctifs automatisés, les équipes techniques ne sont jamais submergées par d'innombrables tâches de correctifs, et les équipes techniques n'ont pas non plus besoin d'essayer de prédire quels correctifs sont les plus importants. Au lieu de cela, tous les correctifs sont appliqués de manière transparente, uniforme et cohérente.
Certains outils de correctifs automatisés tels que KernelCare peut appliquer des correctifs à la volée - en direct, pendant qu'une machine est en cours d'exécution et sans nécessiter de redémarrage. L'application de correctifs en direct limite les perturbations car les machines ne sont pas mises hors ligne pour traiter un correctif. Lorsque le risque d'interruption est minime, la cohérence des correctifs est susceptible d'être améliorée.
En d'autres termes, le bon outil de correction automatisé peut résoudre deux des plus gros problèmes auxquels les entreprises sont confrontées en matière de correction :l'effort requis et les perturbations.
La correction est essentielle, quelle que soit la manière dont vous choisissez de le faire
Quoi que votre entreprise fasse pour se couvrir contre les correctifs ou quelle que soit la manière dont vous organisez votre régime de correctifs, la seule certitude est que les correctifs sont essentiels. Les correctifs doivent être appliqués, mais une décision doit être prise quant à la fréquence et à la manière dont vous corrigez.
Compte tenu de l'ampleur de la menace de cybersécurité, il existe un argument solide en faveur de l'automatisation des correctifs. Les équipes techniques et les chercheurs en sécurité sont de plus en plus débordés et les correctifs automatisés résolvent le problème des ressources et de la disponibilité.
Il est toujours possible d'appliquer simplement plus de main-d'œuvre au défi des correctifs, et pour certaines charges de travail, cela peut être la seule option. Pourtant, dans la plupart des cas, les correctifs automatisés et sans redémarrage peuvent apporter une grande victoire face aux énormes défis actuels en matière de cybersécurité.
Lecture recommandée :
- Mettre à jour GRATUITEMENT le noyau Linux du Raspberry Pi avec KernelCare !
- Détecter les bibliothèques partagées obsolètes en mémoire avec UChecker