Tres proyectos EDR de código abierto que vale la pena conocer: Rustinel, Fibratus, owLSM

Tres proyectos de código abierto para detección de endpoints están circulando entre los equipos de defensa este mes, cada uno cubre un rincón distinto de la flota: Rustinel, Fibratus y owLSM. Ninguno exige un contrato con un proveedor y los tres se pueden alojar e inspeccionar de forma gratuita.

Qué cubre cada uno

Rustinel es un agente multiplataforma para Windows, Linux y macOS. Lee la telemetría que ya expone cada sistema operativo —ETW en Windows, y eBPF y Endpoint Security en Linux y macOS—, la normaliza y evalúa contra ella reglas Sigma, firmas YARA y listas de IOC. Las alertas se escriben como archivos ECS NDJSON locales que alimentan Elastic, Splunk o cualquier canal de registros existente; no se envía nada a la nube de un proveedor. Se distribuye bajo la licencia Apache 2.0.

Fibratus es solo para Windows y está construido sobre la telemetría del kernel de ETW. Combina un motor de reglas orientado al comportamiento con un escáner de memoria YARA que inspecciona las imágenes de los procesos recién creados, y admite «filamentos» basados en Python para equipos que quieran escribir sus propias detecciones sobre el flujo de eventos sin tratar.

owLSM, del brazo de investigación pública de Cybereason, adopta un enfoque distinto: ejecuta reglas de estilo Sigma dentro del propio kernel de Linux mediante hooks eBPF LSM, con el objetivo de bloquear la actividad maliciosa en tiempo real en lugar de limitarse a registrarla después. No es un experimento de laboratorio: Cybereason afirma que ya está desplegado en entornos de clientes de Cybereason y LevelBlue.

Dónde encajan en la pila de un MSP

Ninguno de los tres es un sustituto integral de un EDR comercial. La propia documentación de Rustinel es explícita sobre la limitación: no hay autoprotección del kernel ni protección antimanipulación, por lo que un atacante con privilegios puede simplemente detenerlo. Fibratus necesita derechos de administrador o de SYSTEM para leer ETW y conviene tratarlo como una herramienta de ingeniería de detección y análisis forense, no como un sensor de producción reforzado. owLSM es el que está más avanzado para el uso en producción, pero sus reglas de prevención todavía deben ajustarse a cada entorno, y las reglas Sigma escritas para la detección basada en registros no se portan automáticamente: los campos y los identificadores deben adaptarse al formato de owLSM.

Para un MSP que evalúe cualquiera de los tres, las preguntas prácticas son las mismas: ¿la cobertura de plataformas coincide con la flota que realmente utiliza?, ¿el formato de las reglas se solapa con lo que su SOC ya mantiene? y ¿va a desplegarlo para ingeniería de detección y cobertura piloto o para bloqueo en producción? Trate los tres como un complemento de las herramientas existentes, no como un recambio, hasta que los haya probado en su propio entorno.

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