Três projetos EDR open-source que merecem atenção: Rustinel, Fibratus, owLSM

Três projetos open-source de deteção de endpoints estão a circular entre os defensores este mês, cada um a cobrir um canto diferente da frota: Rustinel, Fibratus e owLSM. Nenhum exige contrato com um fornecedor e os três são gratuitos para autoalojar e inspecionar.

O que cada um cobre

Rustinel é um agente multiplataforma para Windows, Linux e macOS. Lê a telemetria que cada sistema operativo já expõe — ETW no Windows, eBPF e Endpoint Security no Linux e macOS —, normaliza-a e avalia regras Sigma, assinaturas YARA e listas de IOC contra ela. Os alertas são escritos como ficheiros locais ECS NDJSON que alimentam o Elastic, o Splunk ou qualquer pipeline de registos existente; nada é enviado para a nuvem de um fornecedor. É distribuído sob a licença Apache 2.0.

Fibratus é exclusivo para Windows e baseado em telemetria de kernel ETW. Combina um motor de regras orientado ao comportamento com um scanner de memória YARA que inspeciona imagens de processos recém-criados e suporta "filaments" em Python para equipas que queiram escrever as suas próprias deteções sobre o fluxo de eventos em bruto.

owLSM, do braço de investigação pública da Cybereason, adota uma abordagem diferente: executa regras de estilo Sigma dentro do próprio kernel Linux, usando hooks eBPF LSM, com o objetivo de bloquear atividade maliciosa em tempo real, em vez de apenas a registar depois do facto. Não é uma experiência de laboratório — a Cybereason afirma que já está implementado em ambientes de clientes na Cybereason e na LevelBlue.

Onde estes projetos se encaixam numa stack de MSP

Nenhum dos três é um substituto integral de um EDR comercial. A própria documentação do Rustinel é explícita quanto à lacuna: sem autoproteção do kernel, sem anti-adulteração, pelo que um atacante privilegiado pode simplesmente pará-lo. O Fibratus necessita de direitos de administrador ou SYSTEM para ler o ETW e é melhor tratado como uma ferramenta de engenharia de deteção e forense, e não como um sensor de produção endurecido. O owLSM é o que está mais avançado rumo à utilização em produção, mas as suas regras de prevenção ainda precisam de ser afinadas por ambiente, e as regras Sigma escritas para deteção baseada em registos não são portadas automaticamente — os campos e IDs têm de ser adaptados ao formato do owLSM.

Para um MSP que avalie qualquer um dos três, as questões práticas são as mesmas: a cobertura de plataformas corresponde à frota que realmente executa, o formato das regras sobrepõe-se ao que o seu SOC já mantém, e está a implementá-lo para engenharia de deteção e cobertura piloto ou para bloqueio em produção. Trate os três como um complemento às ferramentas existentes, não como uma substituição, até os ter executado no seu próprio ambiente.

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