Tre EDR-projekt med öppen källkod värda en titt: Rustinel, Fibratus, owLSM

Tre projekt för ändpunktsdetektering med öppen källkod cirkulerar bland försvarare den här månaden och täcker var sin del av klientflottan: Rustinel, Fibratus och owLSM. Inget kräver något leverantörsavtal, och alla tre är gratis att självhosta och inspektera.

Vad var och ett täcker

Rustinel är en plattformsoberoende agent för Windows, Linux och macOS. Den läser den telemetri som varje operativsystem redan exponerar – ETW på Windows, eBPF och Endpoint Security på Linux och macOS – normaliserar den och utvärderar Sigma-regler, YARA-signaturer och IOC-listor mot den. Larm skrivs som lokala ECS NDJSON-filer som matas in i Elastic, Splunk eller en befintlig loggpipeline; inget skickas till något leverantörsmoln. Den distribueras under Apache 2.0-licensen.

Fibratus är endast för Windows och bygger på ETW-kärntelemetri. Det kombinerar en beteendedriven regelmotor med en YARA-minnesskanner som inspekterar nyskapade processavbilder, och det har stöd för Python-baserade "filaments" för team som vill skriva sina egna detekteringar ovanpå den råa händelseströmmen.

owLSM, från Cybereasons offentliga forskningsarm, tar ett annat grepp: det kör Sigma-liknande regler inuti själva Linuxkärnan med hjälp av eBPF LSM-hookar, i syfte att blockera skadlig aktivitet i realtid snarare än att bara logga den i efterhand. Det är inte ett labbexperiment – Cybereason uppger att det redan används i kundmiljöer hos Cybereason och LevelBlue.

Var dessa passar i en MSP-stack

Inget av de tre är en fullvärdig ersättning för en kommersiell EDR. Rustinels egen dokumentation är tydlig om luckan: inget självskydd i kärnan, inget manipuleringsskydd, så en privilegierad angripare kan helt enkelt stoppa det. Fibratus kräver administratörs- eller SYSTEM-behörighet för att läsa ETW och behandlas bäst som ett verktyg för detekteringsutveckling och forensik snarare än som en härdad produktionssensor. owLSM har kommit längst mot produktionsanvändning, men dess skyddsregler måste fortfarande anpassas per miljö, och Sigma-regler som skrivits för loggbaserad detektering överförs inte automatiskt – fält och ID:n måste anpassas till owLSM:s format.

För en MSP som utvärderar något av de tre är de praktiska frågorna desamma: matchar plattformstäckningen den klientflotta du faktiskt kör, överlappar regelformatet med det din SOC redan underhåller, och distribuerar du det för detekteringsutveckling och pilottäckning eller för blockering i produktion. Behandla alla tre som ett komplement till befintliga verktyg, inte som en ersättning, tills du har kört dem mot din egen miljö.

Källor: Rustinel (GitHub), Fibratus, owLSM (GitHub).