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

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 fonctionnement sans redémarrer, est l'une de ces incroyables avancées en matière de cybersécurité qui ont véritablement changé la donne dans la lutte contre les acteurs de la menace.Le "live patching" du noyau Linux est 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 en sont les avantages pour les équipes informatiques et l'ensemble de l'organisation, et quel est l'avenir du live patching ? Poursuivez la lecture de notre analyse détaillée du live patching pour en savoir plus.

Les correctifs du noyau Linux sont essentiels - et difficiles à mettre en œuvre

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é de manière à ce 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 (OS) est "patché". Un système d'exploitation patché est protégé contre toute tentative d'exploitation de la vulnérabilité.

Néanmoins, bien que les correctifs soient une solution viable, les exploits connus sont la porte d'entrée de nombreuses attaques car les organisations ne procèdent pas toujours à des correctifs de manière cohérente. En fait, un rapport de recherche de rapport de recherche de Check Point de 2021 que 75 % des attaques s'appuient sur des vulnérabilités publiées en 2017 ou 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 corrigez 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 à son tour des temps d'arrêt jusqu'à ce que le service soit remis en ligne. Et les temps d'arrêt sont coûteux à bien des égards.

Un défi à relever

Multiplier le casse-tête des correctifs sur des milliers de machines et prenez en compte l'apparition 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 tout simplement 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 souvent que l'idéal. Les organisations prévoient des temps d'arrêt pour l'application des correctifs à un rythme, disons, d'une fois par mois - si elles font du bon travail. Cela signifie qu'il existe d'importantes périodes de latence entre le moment où une vulnérabilité est identifiée publiquement et celui où un correctif est finalement appliqué.

Cependant, les équipes techniques manquent souvent de ressources, de sorte que la situation peut rapidement s'aggraver, entraînant le report des correctifs pendant des mois et des mois.. Il n'est donc pas étonnant que les cybercriminels parviennent à s'introduire dans les réseaux en raison de vulnérabilités non corrigées : une étude réalisée en 2019 par l'Institut Ponemon 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 du live patching du noyau Linux

Les redémarrages et les temps d'arrêt du serveur Linux qui en découlent conduisent à des correctifs inefficaces. En supprimant l'exigence de la fenêtre de maintenance (et l'épuisement des ressources causé par le redémarrage), on résout une grande partie du problème des correctifs.

C'est un chercheur dont le serveur Linux non patché a été piraté - Jeff Arnold, du MIT - qui a lancé la recherche sur les correctifs en direct en 2006. Qu'est-ce qui l'a motivé ? Le serveur Linux de Jeff Arnold a été piraté parce qu'il avait retardé une mise à jour de sécurité importante pour ne pas gêner les autres.. Pour lui, il était évident que les utilisateurs de Linux en entreprise avaient besoin d'une autre méthode d'application des correctifs.

Les recherches menées au MIT ont été le premier pas vers l'application de correctifs au noyau en direct. 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 des correctifs en direct pour les serveurs Linux avec leurs solutions respectives Kpatch et Kgraft, qui ont ensuite été combinées en une seule approche.

Passer à un système simple et abordable de "live patching" partout

La correction en direct du noyau Linux, également connue sous le nom de correction dynamique du noyau, est généralement liée à une seule distribution Linux d'entreprise et n'est souvent disponible 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 live patching KernelCare pendant près d'une décennie, avec le soutien de l'équipe de CloudLinux. Nous avons veillé à ce que les correctifs en direct du noyau puissent être appliqués à toutes les principales distributions Linux d'entreprise, ce qui a donné lieu à un service de correctifs en direct universel et abordable qui n'est pas limité à une seule distribution telle que Red Hat ou SUSE Linux.

De plus, KernelCare a introduit le "persistent live patching". La méthode originale de live patching, appelée temporary live patching, entraînait une réduction des performances au fil du temps, car les correctifs étaient appliqués à l'aide d'une technique qui accumulait les correctifs les uns sur les autres.

En revanche, le live patching persistant contient un correctif cumulatif dans un binaire, de sorte qu'il n'y a pas de baisse de performance. Grâce à plusieurs innovations technologiques brevetées et en instance de brevet, KernelCare offre un correctif en direct sans redémarrage et sans baisse de performance.. Cette approche est complétée par des correctifs virtuels, qui renforcent encore la sécurité sans nécessiter de temps d'arrêt du système.

De plus, nous avons étendu la possibilité d'appliquer des correctifs en direct au-delà du noyau Linux, afin d'inclure des correctifs en direct pour les bibliothèques partagées, les serveurs de bases de données et les environnements de virtualisation.

Comment fonctionne le live patching du noyau Linux dans la pratique

Le principe du live patching est simple, mais il s'agit d'une gymnastique technique compliquée qui se déroule en arrière-plan.

Voici une explication simplifiée. Le service de correctifs 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 ne doit pas être redémarré, ce qui signifie également que l'ensemble du système évite un redémarrage. 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. Qu'il s'agisse d'une correction d'une seule ligne ou de plusieurs fonctions, le processus est toujours le même. C'est un peu comme de la magie, et la correction en direct du noyau a des implications pratiques majeures pour les efforts quotidiens de correction sur le terrain.

Sans live patching, 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 parcs technologiques, il s'agit d'un processus compliqué qui ne manquera pas de contrarier quelqu'un, à un moment ou à un autre, 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 la dégradation des performances reste un effet secondaire.

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

Dès qu'un correctif est publié en réponse à une vulnérabilité, il est appliqué par la technologie "live patching". 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 assurer la conformité

Le live patching étant très réactif (rappelons qu'il n'y a pas de calendrier de maintenance ni de temps d'arrêt), cela signifie que les correctifs sont appliqués de manière cohérente et qu'il n'y a pas de période de latence pendant laquelle les attaquants peuvent exploiter une vulnérabilité publiée.

La nature cohérente et sans faille des correctifs en direct a une implication importante dans le monde hautement réglementé d'aujourd'hui, et les correctifs en direct changent la donne pour les organisations qui ont des obligations en matière 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 le mois qui suit leur publication. Si vous appliquez un correctif après ce délai, vous ne respectez pas les exigences de la norme PCI DSS, ce qui peut avoir des conséquences importantes, notamment de lourdes amendes, voire pire, en cas d'infraction. Des normes telles que la norme ISO 27001 et le cadre de cybersécurité du NIST comportent des exigences similaires en matière de correctifs.

Les organisations qui utilisent des correctifs en direct 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 devez respecter est automatiquement respecté.

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

Au niveau de la direction, la conformité est vraiment importante, mais le live patching 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 sécurité globale.

Les parties prenantes sont également plus heureuses, car les fenêtres de maintenance ont tendance à perturber tous les membres de l'organisation. Les temps d'arrêt sont synonymes de flux de revenus perturbés, de clients mécontents et d'employés frustrés. Ces problèmes appartiennent au passé grâce au live patching, qui réduit le besoin de fenêtres de maintenance.

Et il y a, bien sûr, l'avantage principal d'une sécurité grandement améliorée. En utilisant le live patching pour réduire la fenêtre de correction à quelques jours (voire quelques heures), vous minimisez les possibilités pour les attaquants d'exploiter une vulnérabilité et de causer des dommages en cours de route..

Le live patching du noyau Linux présente-t-il des inconvénients ?

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

Cela dit, le correctif de sécurité en direct KernelCare de TuxCare est abordable, à seulement 59,50 $ par an et par machine. C'est un petit prix à payer si l'on considère le temps économisé en essayant d'organiser les fenêtres de maintenance et de patcher les vulnérabilités manuellement. C'est sans compter le coût potentiel d'une cyber-attaque réussie parce que vous n'avez pas appliqué les correctifs.

Alors que les performances étaient auparavant un problème avec les correctifs temporaires, l'émergence du correctif 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 grande victoire 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 élargie 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, puisque nous offrons maintenant des correctifs en direct pour QEMU via notre service QEMUCare. À chaque étape, nous vous rapprochons de l'allègement des charges de travail et de la 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 d'appliquer des correctifs en direct pour voir comment ils peuvent améliorer votre position en matière de cybersécurité.. Avec des intégrations faciles dans des outils tels que Nessus, Qualys, Rapid7, Puppet, Ansible, Chef, Datadog et Crowdstrike, il n'y a tout simplement pas d'excuse. Pour en savoir plus sur notre gamme de solutions de live patching, cliquez ici.