Détection d’anomalies : Falco s’étendra au-delà du cloud et de Kubernetes

Un moteur de détection d’anomalies qui a fait ses preuves

En tant que moteur de détection de comportements anormaux et de menaces de cybersécurité au runtime, Falco a pris de l’ampleur dans les environnements Kubernetes en même temps que son contributeur principal, Sysdig.

Le projet lancé en 2016 a été téléchargé plus de 100 millions de fois. En sus de Sysdig, Amazon, Apple, IBM et Red Hat sont des contributeurs réguliers à Falco. La technologie est adoptée par des entreprises comme Qonto, Thales, Vinted, ou encore Shopify.

« Sans cette communauté, et sans prouver qu’elle existe, il est aujourd’hui impossible pour un projet d’obtenir un certificat, ce badge atteste que le projet est à long terme, durable et suffisamment mûr », signale Loris Degioanni.

Techniquement, Falco est lié à l’écosystème Linux et s’appuie sur eBPF, une sandbox embarquée qui permet de rendre le système d’exploitation open source programmable sans en toucher le kernel. La technologie s’avère particulièrement utile pour remonter des signaux sur le comportement de machines et de les contextualiser en temps réel.

Si certains acteurs, dont Cilium, s’en servent comme d’un outil d’analyse réseau et d’observabilité, d’autres comme Sysdig ont instrumenté eBPF pour propulser « un système de vidéosurveillance du cloud », c’est-à-dire Falco, résume le CTO de Sysdig.

Falco est un agent de détection et de monitoring du kernel Linux qui « surveille les événements comme les syscalls en s’appuyant sur des règles personnalisées ».

La version 0.37 de Falco est disponible depuis le 29 février 2024.

Élargir la portée de Falco

Outre la révision des requêtes et de l’instrumentation de Kubernetes, Sysdig et les autres contributeurs se sont dernièrement concentrés sur le système de plugins dont les fondations ont été entièrement reconstruites. « L’API Plugin vous permet de collecter des logs à partir de sources multiples et elle est souvent intégrée avec des produits comme Okta ou GitHub », explique Loris Degioanni. « Donc aujourd’hui, traditionnellement, vous pourriez utiliser Falco pour détecter des choses comme un utilisateur qui a modifié un fichier binaire dans un conteneur, par exemple ».

Lors de la KubeCon, les responsables du projet ont évoqué les plugins pour les événements d’audit de GKE et de GCP, de Box, les événements en temps réel de Salesforce et la récupération des métadonnées des clusters Kubernetes.

Par ailleurs, l’API Plugin est dotée de nouvelles capacités pour récupérer les événements asynchrones, les logs, d’un système de reconfiguration dynamique et de deux SDK pour Go et C++. Prochainement, ce framework permettra de récupérer des informations sur les fichiers de description (« très utile pour la détection d’anomalies »), des types de données d’états plus complexes (Falco ne supporte actuellement que des integers et des strings), et d’afficher des métriques et prendra en charge davantage de langages de programmation.

« De plus en plus d’attaques dans le cloud proviennent d’une multitude d’endroits. Il est donc important que Falco continue d’élargir son champ d’action pour détecter davantage de choses », affirme Loris Degioanni. « EBPF et les conteneurs sont donc à l’origine de Falco, mais l’objectif de Falco est d’être en mesure d’avoir une visibilité totale de n’importe quel service exécuté dans le cloud et en dehors ».

« Je m’attends à ce que Falco prenne en charge de plus en plus d’applications : Slack, Azure Active Directory, etc. », poursuit-il. « Nous avons créé cette architecture modulaire de plugins qui permet d’étendre Falco assez facilement. Et nous voyons la communauté produire de plus en plus d’intégrations ».

Le CTO évoque l’usage des clients de Sysdig qui non seulement déploie la plateforme CNAPP associée pour surveiller des environnements de cloud hybride, mais aussi qui la déploie sur site, notamment dans le secteur de la défense et dans les instances gouvernementales.

En ce sens, les contributeurs ont déjà en tête la feuille de route vers la version 1.0, perçue comme la « prochaine étape logique » pour la communauté.

Simplifier l’implémentation et l’usage

Les contributeurs veulent d’abord normaliser la gestion de l’adoption et de dépréciation des fonctionnalités « afin de s’assurer que les utilisateurs comprennent quand les fonctionnalités peuvent être considérées comme stables et quand elles sont supprimées ».

Dans un même temps, il s’agit de renforcer les fonctionnalités clés du moteur de détection d’événements au runtime, mieux ordonner le fichier de déploiement falco.yaml, standardiser les args CLI et mieux prendre en charge les métriques.

À terme, Falco devrait bénéficier d’une syntaxe plus lisible afin de simplifier la rédaction de règles, tout en intégrant les ajouts les plus récents du côté d’eBPF.

« Nous travaillons également à notre système de distribution pour l’aligner davantage sur les meilleures pratiques Linux et rendre le déploiement de Falco encore plus convivial et plus sûr », renseignent les porte-parole, lors de la session s’étant déroulée devant une salle pleine à la KubeCon.

Enfin, la communauté continue de développer Falcosidekick, un daemon pour envoyer les événements repérés par le moteur de détection vers des outils d’observabilité (ELK, Dynatrace, Sumo Logic, etc.) ou des data stores et des espaces de stockage (Prometheus, S3, MinIO, IBM Cloud COS, etc.).