Drei Open-Source-EDR-Projekte, die einen Blick wert sind: Rustinel, Fibratus, owLSM

Unter Defender-Teams machen in diesem Monat drei Open-Source-Projekte zur Endpoint-Erkennung die Runde, die jeweils einen anderen Bereich der Flotte abdecken: Rustinel, Fibratus und owLSM. Keines erfordert einen Anbietervertrag, und alle drei lassen sich kostenlos selbst hosten und überprüfen.

Was die einzelnen Tools abdecken

Rustinel ist ein plattformübergreifender Agent für Windows, Linux und macOS. Er liest die Telemetrie, die das jeweilige Betriebssystem bereits bereitstellt – ETW unter Windows, eBPF und Endpoint Security unter Linux und macOS – normalisiert sie und wertet Sigma-Regeln, YARA-Signaturen und IOC-Listen dagegen aus. Warnungen werden als lokale ECS-NDJSON-Dateien geschrieben, die in Elastic, Splunk oder eine bestehende Log-Pipeline eingespeist werden; nichts wird an eine Anbieter-Cloud gesendet. Es wird unter der Apache-2.0-Lizenz veröffentlicht.

Fibratus ist auf Windows beschränkt und basiert auf der ETW-Kernel-Telemetrie. Es kombiniert eine verhaltensbasierte Regel-Engine mit einem YARA-Speicherscanner, der neu erstellte Prozessabbilder untersucht, und unterstützt Python-basierte „Filaments“ für Teams, die auf dem rohen Event-Stream eigene Erkennungen schreiben möchten.

owLSM, aus dem öffentlichen Forschungsteam von Cybereason, verfolgt einen anderen Ansatz: Es führt Sigma-artige Regeln im Linux-Kernel selbst mithilfe von eBPF-LSM-Hooks aus und zielt darauf ab, schädliche Aktivitäten in Echtzeit zu blockieren, statt sie erst nachträglich zu protokollieren. Es handelt sich nicht um ein Laborexperiment – Cybereason zufolge ist es bereits in Kundenumgebungen bei Cybereason und LevelBlue im Einsatz.

Wo diese Tools in einen MSP-Stack passen

Keines der drei Tools ist ein vollwertiger Ersatz für ein kommerzielles EDR. Rustinels eigene Dokumentation benennt die Lücke deutlich: kein Kernel-Selbstschutz und kein Manipulationsschutz, sodass ein privilegierter Angreifer den Agenten einfach beenden kann. Fibratus benötigt Administrator- oder SYSTEM-Rechte, um ETW zu lesen, und sollte eher als Werkzeug für Detection Engineering und Forensik betrachtet werden, nicht als gehärteter Produktionssensor. owLSM ist der Produktionsreife am nächsten, aber seine Präventionsregeln müssen weiterhin pro Umgebung angepasst werden; außerdem lassen sich Sigma-Regeln, die für logbasierte Erkennung geschrieben wurden, nicht automatisch übernehmen – Felder und IDs müssen an das owLSM-Format angepasst werden.

Für einen MSP, der eines der drei Tools prüft, sind die praktischen Fragen dieselben: Passt die Plattformabdeckung zur tatsächlich betriebenen Flotte, überschneidet sich das Regelformat mit dem, was das eigene SOC bereits pflegt, und erfolgt der Einsatz für Detection Engineering und Pilotabdeckung oder für produktives Blockieren. Bis sie in der eigenen Umgebung getestet wurden, sollten alle drei als Ergänzung zu vorhandenen Werkzeugen betrachtet werden, nicht als Austausch.

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