Tre progetti EDR open source da tenere d'occhio: Rustinel, Fibratus, owLSM

Tre progetti open source di rilevamento degli endpoint stanno circolando tra i difensori questo mese, ognuno dei quali copre un angolo diverso della flotta: Rustinel, Fibratus e owLSM. Nessuno richiede un contratto con un fornitore e tutti e tre sono gratuiti da ospitare autonomamente e da ispezionare.

Cosa copre ciascuno

Rustinel è un agente multipiattaforma per Windows, Linux e macOS. Legge la telemetria che ciascun sistema operativo espone già — ETW su Windows, eBPF ed Endpoint Security su Linux e macOS — la normalizza e la valuta rispetto a regole Sigma, firme YARA ed elenchi di IOC. Gli avvisi vengono scritti come file NDJSON ECS locali che confluiscono in Elastic, Splunk o in qualsiasi pipeline di log esistente; nulla viene inviato al cloud del fornitore. È distribuito sotto licenza Apache 2.0.

Fibratus è solo per Windows e si basa sulla telemetria del kernel ETW. Abbina un motore di regole orientato al comportamento a uno scanner di memoria YARA che ispeziona le immagini dei processi appena creati, e supporta "filamenti" basati su Python per i team che vogliono scrivere i propri rilevamenti sopra il flusso di eventi grezzi.

owLSM, del braccio di ricerca pubblico di Cybereason, adotta un approccio diverso: esegue regole in stile Sigma direttamente nel kernel Linux usando gli hook eBPF LSM, con l'obiettivo di bloccare l'attività dannosa in tempo reale anziché limitarsi a registrarla a posteriori. Non è un esperimento di laboratorio — Cybereason afferma che è già distribuito negli ambienti dei clienti presso Cybereason e LevelBlue.

Dove si inseriscono in uno stack MSP

Nessuno dei tre è un sostituto integrale di un EDR commerciale. La stessa documentazione di Rustinel è esplicita sul divario: nessuna autoprotezione del kernel, nessuna protezione anti-manomissione, quindi un attaccante privilegiato può semplicemente fermarlo. Fibratus richiede diritti di amministratore o SYSTEM per leggere ETW ed è meglio considerarlo uno strumento di ingegneria del rilevamento e di analisi forense piuttosto che un sensore di produzione rinforzato. owLSM è il più vicino all'uso in produzione, ma le sue regole di prevenzione devono ancora essere calibrate per ciascun ambiente, e le regole Sigma scritte per il rilevamento basato sui log non si trasferiscono automaticamente — campi e ID devono essere adattati al formato di owLSM.

Per un MSP che valuta uno qualsiasi dei tre, le domande pratiche sono le stesse: la copertura della piattaforma corrisponde alla flotta che gestisci davvero, il formato delle regole si sovrappone a ciò che il tuo SOC già mantiene, e lo stai distribuendo per l'ingegneria del rilevamento e una copertura pilota oppure per il blocco in produzione. Tratta tutti e tre come un'aggiunta alla strumentazione esistente, non come una sostituzione, finché non li hai testati nel tuo ambiente.

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