Trois projets EDR open source à considérer : Rustinel, Fibratus, owLSM

Trois projets open source de détection de terminaux circulent chez les défenseurs ce mois-ci, chacun couvrant un angle différent du parc : Rustinel, Fibratus et owLSM. Aucun ne nécessite de contrat fournisseur et tous les trois sont gratuits à auto-héberger et à inspecter.

Ce que chaque outil couvre

Rustinel est un agent multiplateforme pour Windows, Linux et macOS. Il lit la télémétrie que chaque système d’exploitation expose déjà (ETW sous Windows, eBPF et Endpoint Security sous Linux et macOS), la normalise, puis l’évalue au regard de règles Sigma, de signatures YARA et de listes d’IOC. Les alertes sont écrites dans des fichiers locaux ECS NDJSON qui alimentent Elastic, Splunk ou tout pipeline de journaux existant ; rien n’est envoyé vers le cloud d’un fournisseur. Il est distribué sous licence Apache 2.0.

Fibratus est réservé à Windows et repose sur la télémétrie noyau ETW. Il associe un moteur de règles comportementales à un analyseur mémoire YARA qui inspecte les images de processus fraîchement créés, et il prend en charge des « filaments » Python pour les équipes qui veulent écrire leurs propres détections au-dessus du flux d’événements brut.

owLSM, issu du pôle de recherche public de Cybereason, adopte une approche différente : il exécute des règles de type Sigma directement dans le noyau Linux à l’aide de hooks eBPF LSM, avec pour objectif de bloquer l’activité malveillante en temps réel plutôt que de simplement la journaliser après coup. Il ne s’agit pas d’une expérience de laboratoire — Cybereason indique qu’il est déjà déployé dans des environnements clients chez Cybereason et LevelBlue.

Où ces outils trouvent leur place dans une pile MSP

Aucun des trois ne remplace intégralement un EDR commercial. La documentation de Rustinel est explicite sur cette lacune : pas d’autoprotection du noyau, pas de mécanisme anti-altération, si bien qu’un attaquant privilégié peut simplement l’arrêter. Fibratus nécessite des droits administrateur ou SYSTEM pour lire ETW et doit être considéré avant tout comme un outil d’ingénierie de détection et d’investigation numérique plutôt que comme un capteur de production durci. owLSM est le plus avancé en vue d’un usage en production, mais ses règles de prévention doivent encore être ajustées à chaque environnement et les règles Sigma écrites pour la détection à base de journaux ne se transposent pas automatiquement : champs et identifiants doivent être adaptés au format d’owLSM.

Pour un MSP qui évalue l’un des trois, les questions pratiques restent les mêmes : la couverture de la plateforme correspond-elle au parc que vous exploitez réellement, le format des règles recoupe-t-il ce que votre SOC maintient déjà, et déployez-vous l’outil pour l’ingénierie de détection et une couverture pilote ou pour du blocage en production ? Considérez les trois solutions comme un complément à l’outillage existant, et non comme un remplacement, tant que vous ne les avez pas testées dans votre propre environnement.

Sources : Rustinel (GitHub), Fibratus, owLSM (GitHub).