Qu'est-ce que le Live Patching du noyau Linux ?

23 novembre 2022 - L'équipe de relations publiques de TuxCare

Les percées ne sont pas fréquentes dans le domaine de la cybersécurité, mais lorsqu'elles se produisent, elles peuvent constituer une véritable solution miracle.

Le "live patching" du noyau Linux, c'est-à-dire la possibilité d'appliquer un correctif de sécurité du noyau Linux à un noyau Linux en cours d'exécution sans redémarrerest l'une de ces incroyables percées en matière de cybersécurité qui ont véritablement changé la donne dans la lutte contre les acteurs de la menace.

Mais qu'est-ce que le live patching du noyau Linux, quels sont ses avantages pour les équipes informatiques et pour l'ensemble de l'entreprise, et quel est l'avenir du live patching ? Pour le savoir, lisez notre analyse complète du live patching.

La correction du noyau Linux est essentielle - et difficile

Un correctif est un morceau de code qui corrige une vulnérabilité connue en matière de cybersécurité. Lorsqu'un fournisseur, tel que Red Hat ou Canonical, est informé d'une vulnérabilité en matière de cybersécurité, il développe un correctif avec un code modifié qui "corrige" cette vulnérabilité afin qu'elle ne puisse pas être exploitée.

Une fois que le code du correctif est intégré au noyau, le système d'exploitation (SE) est "patché". Un système d'exploitation corrigé est protégé contre toute tentative d'exploitation de la vulnérabilité..

Néanmoins, bien que l'application de correctifs soit une solution viable, les exploits connus constituent la porte d'entrée de nombreuses attaques, car les organisations n'appliquent pas toujours des correctifs de manière cohérente. En fait, un rapport de recherche Check Point de 2021 suggère que 75 % des attaques s'appuyaient sur des vulnérabilités publiées en 2017 et avant.

Si ces vulnérabilités avaient été corrigées, la porte aurait été fermée aux attaques. Alors pourquoi certaines organisations n'appliquent-elles pas toujours des correctifs de manière cohérente ?

Le problème est que l'application de correctifs n'est pas toujours simple. En général, lorsque vous appliquez un correctif à un service - qu'il s'agisse d'une application, d'un pilote ou du système d'exploitation lui-même - vous devez redémarrer le service pour appliquer le correctif.

Cela implique des temps d'arrêt jusqu'à ce que le service soit remis en ligne. Et les temps d'arrêt sont coûteux à plusieurs niveaux.

Un défi qui nécessite une solution

Multipliez le puzzle des correctifs sur des milliers de machines et prenez en compte l'émergence de milliers de vulnérabilités chaque année et vous vous retrouvez rapidement face à un problème difficile, car les parties prenantes ne tolèrent pas les perturbations et les pertes de revenus chaque fois qu'un correctif doit être appliqué.

Cela signifie que les correctifs sont appliqués moins fréquemment que l'idéal. Les organisations prévoient des temps d'arrêt pour l'application des correctifs à un rythme de, disons, une fois par mois - si elles font du bon travail. Cela signifie qu'il y a d'importantes fenêtres entre le moment où une vulnérabilité est identifiée publiquement et celui où un correctif est finalement appliqué.

Cependant, les équipes techniques manquent généralement de ressources, de sorte que la situation peut rapidement empirer et entraîner le report des correctifs pendant des mois et des mois.. Il n'est donc pas étonnant que les cybercriminels aient autant de succès à s'introduire dans les réseaux en raison de vulnérabilités non corrigées : une étude de 2019 du Ponemon Institute montre que 62 % des personnes interrogées ont attribué une violation de données au fait que leur organisation n'a pas appliqué un correctif disponible.

L'histoire des correctifs en direct du noyau Linux

Les redémarrages et les temps d'arrêt du serveur Linux qui y sont associés entraînent une inefficacité des correctifs. En supprimant l'exigence de la fenêtre de maintenance (et la perte de ressources causée par le redémarrage), vous résolvez une grande partie du problème des correctifs.

C'est un chercheur dont le serveur Linux non corrigé a été piraté - Jeff Arnold, du MIT - qui a lancé les recherches sur les correctifs en temps réel en 2006. Qu'est-ce qui l'a motivé ? Eh bien, le serveur Linux d'Arnold a été piraté parce qu'il a retardé une mise à jour de sécurité importante, car il ne voulait pas gêner les autres personnes.... Pour lui, il était évident que les utilisateurs de Linux en entreprise avaient besoin d'une autre méthode d'application de correctifs.

Les recherches menées au MIT ont été le premier tremplin vers les correctifs en direct du noyau. Jeff et certains de ses collègues ont fondé une société appelée KSplice, Inc. qui a été rachetée par Oracle en 2011. D'autres organisations ont suivi lorsque Red Hat et SUSE ont également mené des efforts pour développer le live patching pour les serveurs Linux avec leurs solutions respectives Kpatch et Kgraft, qui ont ensuite été combinées en une seule approche.

Passage à un système de connexion en direct simple et abordable partout

Les correctifs en direct du noyau Linux, également appelés correctifs dynamiques du noyau, sont généralement liés à une seule distribution Linux d'entreprise et ne sont souvent disponibles que dans le cadre de contrats d'assistance coûteux pour les serveurs Linux.

Chez TuxCare, nous avons développé de manière indépendante la solution brevetée de correctifs en direct KernelCare depuis près de dix ans, avec le soutien de l'équipe de CloudLinux. Nous avons veillé à ce que les correctifs de noyau en direct puissent être appliqués à toutes les principales distributions Linux d'entreprise, ce qui a donné naissance à un service de correctifs en direct universel et abordable qui n'est pas limité à une seule distribution comme Red Hat ou SUSE Linux.

De plus, KernelCare a introduit les correctifs persistants en temps réel. La méthode originale de correction en direct, appelée correction en direct temporaire, entraînait une baisse des performances au fil du temps, car les correctifs étaient appliqués à l'aide d'une technique qui les accumulait les uns sur les autres.

En revanche, les correctifs persistants en direct contiennent un correctif cumulatif dans un seul binaire, de sorte que les performances ne sont pas affectées. Grâce à plusieurs innovations technologiques brevetées et en attente de brevet, KernelCare fournit un live patching sans redémarrage et sans perte de performance..

Et, comme prochaine étape majeure dans l'application de correctifs en direct, nous avons maintenant élargi la possibilité d'appliquer des correctifs en direct au-delà du noyau Linux pour inclure également des correctifs en direct des bibliothèques partagées, des serveurs de bases de données et des environnements de virtualisation.

Comment les correctifs en direct du noyau Linux fonctionnent en pratique

Le principe de la correction en direct est simple, mais une gymnastique technique complexe se déroule en arrière-plan.

Voici une explication simplifiée. Le service de correction en direct crée un correctif à partir du code corrigé afin que ce dernier puisse être chargé dans la mémoire du noyau en cours d'exécution. L'exécution du code est alors redirigée de la version vulnérable du code vers la version corrigée du code pendant que le noyau est en cours d'exécution.

Cela signifie que le noyau n'a pas besoin d'être redémarré, ce qui permet également d'éviter un redémarrage de l'ensemble du système. Néanmoins, même si le système n'a jamais été redémarré, la version corrigée du code est maintenant utilisée et le système est à l'abri de la vulnérabilité.

Le correctif peut être aussi complexe ou aussi simple que nécessaire. D'un simple correctif d'une ligne à de multiples fonctions, le processus est toujours le même. C'est un peu comme de la magie, et l'application de correctifs en direct sur le noyau a des implications pratiques majeures pour les efforts quotidiens de correction sur le terrain.

Sans les correctifs en direct, les administrateurs système doivent planifier et programmer des fenêtres de maintenance pour mettre les serveurs Linux d'entreprise hors ligne. Pour les grands patrimoines technologiques, il s'agit d'un processus compliqué qui ne manquera pas de contrarier quelqu'un, quelque part en cours de route, car personne n'aime les temps d'arrêt. Certes, l'équilibrage des charges et la redondance peuvent atténuer les temps d'arrêt, mais ils ont toujours pour effet secondaire une dégradation des performances.

Cependant, Toutefois, lorsque vous utilisez un logiciel de correction en direct, vous simplifiez les mises à jour de sécurité en exécutant quelques étapes en ligne de commande pour configurer les correctifs en direct. en exécutant seulement quelques étapes en ligne de commande pour configurer le live patching.. Les serveurs et les applications, comme les bases de données, ne doivent plus être mis hors ligne pour l'application des correctifs. Cela signifie que les administrateurs système n'ont pas à se soucier des calendriers de maintenance et que les parties prenantes n'entendent jamais les mots "temps d'arrêt" ou "perturbation".

Dès qu'un correctif est publié en réponse à une vulnérabilité, il est appliqué par la technologie de correctifs en direct. Grâce à la possibilité d'appliquer un correctif en direct sur le noyau, il n'y a aucune période d'attente et aucune interruption du service en cours.

Les correctifs en direct sont essentiels pour la conformité

Comme les correctifs en direct sont très réactifs (n'oubliez pas qu'il n'y a pas de calendrier de maintenance ni de temps d'arrêt), les correctifs sont appliqués de manière cohérente et il n'y a pas de périodes où les attaquants peuvent exploiter une vulnérabilité publiée.

La nature cohérente et sans faille du "live patching" a une implication importante dans le monde hautement réglementé d'aujourd'hui, et le "live patching" change la donne pour les organisations qui ont des obligations de conformité.

En fait, le déploiement de correctifs de sécurité par le biais d'un mécanisme de correctifs en direct est le moyen le plus rapide actuellement disponible pour sécuriser un système contre les nouvelles menaces..

Prenons l'exemple de la norme PCI DSS (Payment Card Industry Data Security Standard), qui s'applique aux organisations qui traitent les paiements.

La norme PCI DSS exige dans la section 6.2 de ses règles que les correctifs de sécurité critiques soient appliqués dans un délai d'un mois après leur publication. Si vous appliquez les correctifs plus tard, vous ne respectez pas les exigences de la norme PCI DSS, ce qui peut avoir des conséquences importantes, notamment de lourdes amendes, ou pire, en cas de violation. Des normes telles que l'ISO 27001 et le NIST Cyber Security Framework comportent des exigences similaires en matière de correctifs.

Les organisations qui utilisent les correctifs dynamiques du noyau réduisent au minimum le risque d'enfreindre les règles de conformité car l'application des correctifs ne dépend plus d'une intervention manuelle ou de fenêtres de maintenance longues et peu fiables. Le délai de conformité que vous êtes tenu de respecter est automatiquement respecté.

Cela fait aussi une grande différence pour les équipes informatiques

Au niveau de la direction, c'est la conformité qui compte vraiment, mais l'application de correctifs en direct a également des implications pratiques importantes et positives pour les équipes techniques. Comme les mises à jour du noyau se font automatiquement en arrière-plan, les administrateurs système peuvent consacrer leur temps à des tâches de plus haut niveau qui contribuent à la posture de sécurité globale.

Cela implique également des parties prenantes plus heureuses, car les fenêtres de maintenance ont tendance à perturber tout le monde dans l'organisation. Les temps d'arrêt signifient des flux de revenus perturbés, des clients mécontents et des employés frustrés. Ces problèmes appartiennent au passé grâce au "live patching", car celui-ci réduit la nécessité des fenêtres de maintenance.

Et il y a, bien sûr, l'avantage principal d'une sécurité considérablement améliorée. Utilisez les correctifs en direct pour réduire la fenêtre d'application des correctifs à quelques jours (voire quelques heures) et vous minimisez les possibilités pour les attaquants d'exploiter une vulnérabilité et de causer des dommages en cours de route..

Y a-t-il des inconvénients à l'application de correctifs en direct sur le noyau Linux ?

Le live patching n'est pas gratuit, il y a donc un facteur coût à prendre en compte lors de la souscription à un service de live patching. Pour Kpatch et d'autres services de correctifs en direct sponsorisés par des fournisseurs, les coûts peuvent être importants, car les correctifs en direct sont inclus dans les plans de support. Prenez par exemple le prix de 1 299 $ par machine et par an pour le support premium de Red Hat.

Cela dit, le correcteur de sécurité en direct KernelCare de TuxCare est abordable, à seulement 59,50 dollars par an et par machine. C'est un petit prix à payer si l'on considère le temps gagné à organiser les fenêtres de maintenance et à corriger les vulnérabilités manuellement. Sans parler du coût potentiel d'une cyberattaque réussie parce que vous n'avez pas appliqué de correctif.

Alors que les performances étaient auparavant un problème avec le live patching temporaire, l'émergence du live patching persistant breveté de KernelCare a éliminé le problème des performances, car les systèmes sont simplement corrigés pendant qu'ils fonctionnent - et continuent ensuite à fonctionner comme avant, sans perte de performances.

Conclusion

Les correctifs de sécurité en direct : une victoire majeure pour la cybersécurité. Il facilite l'application des correctifs du noyau aux serveurs d'entreprise Linux, une tâche qui est généralement difficile et qui prend du temps. De plus, la solution de correctifs en direct de TuxCare s'est étendue pour inclure une large gamme de services de correctifs en direct - couvrant les bibliothèques avec LibCare et les bases de données avec DBCare.

TuxCare vous couvre même pour la virtualisation, car nous offrons maintenant des correctifs en direct de QEMU via notre service QEMUCare. À chaque étape, nous vous rapprochons d'une charge de travail allégée et d'une conformité totale.

Si vous utilisez des charges de travail Linux d'entreprise telles que Red Hat ou Oracle, il est impératif que vous envisagiez l'application de correctifs en direct pour voir comment elle peut améliorer votre posture de cybersécurité.. Grâce à des intégrations faciles avec des outils tels que Nessus, Qualys, Rapid7, Puppet, Ansible, Chef, Datadog et Crowdstrike, vous n'avez aucune excuse. Pour en savoir plus sur notre gamme de solutions de correctifs en direct, cliquez ici.