Trzy warte uwagi projekty open-source EDR: Rustinel, Fibratus, owLSM

Trzy projekty open-source wykrywania na endpointach krążą wśród obrońców w tym miesiącu, każdy obejmujący inny obszar floty: Rustinel, Fibratus i owLSM. Żaden nie wymaga kontraktu z dostawcą, a wszystkie trzy są bezpłatne do samoobsługi i inspekcji.

Co obejmuje każdy z nich

Rustinel to wieloplatformowy agent dla systemów Windows, Linux i macOS. Odczytuje telemetrię, którą każdy system operacyjny już udostępnia -- ETW w Windows, eBPF i Endpoint Security w Linux i macOS -- normalizuje ją i ocenia reguły Sigma, sygnatury YARA oraz listy IOC. Alerty zapisywane są jako lokalne pliki ECS NDJSON, które zasilają Elastic, Splunk lub dowolny istniejący potok logów; nic nie jest wysyłane do chmury dostawcy. Rozpowszechniany jest na licencji Apache 2.0.

Fibratus działa wyłącznie w systemie Windows i opiera się na telemetrii jądra ETW. Łączy silnik reguł oparty na zachowaniu ze skanerem pamięci YARA, który sprawdza świeżo utworzone obrazy procesów, oraz obsługuje „filamenty” oparte na Pythonie dla zespołów chcących tworzyć własne detekcje na podstawie surowego strumienia zdarzeń.

owLSM, pochodzący z publicznego działu badawczego firmy Cybereason, stosuje inne podejście: uruchamia reguły w stylu Sigma wewnątrz jądra Linux za pomocą hooków eBPF LSM, dążąc do blokowania złośliwej aktywności w czasie rzeczywistym, a nie tylko jej rejestrowania po fakcie. Nie jest to eksperyment laboratoryjny -- Cybereason podaje, że rozwiązanie jest już wdrożone w środowiskach klientów Cybereason i LevelBlue.

Jak te narzędzia wpisują się w stos MSP

Żadne z trzech rozwiązań nie jest pełnym zamiennikiem komercyjnego EDR. Dokumentacja Rustinel jasno wskazuje lukę: brak ochrony jądra przed samą sobą, brak zabezpieczeń przed manipulacją, więc uprzywilejowany atakujący może po prostu je zatrzymać. Fibratus wymaga uprawnień administratora lub SYSTEM do odczytu ETW i najlepiej traktować je jako narzędzie do inżynierii detekcji oraz analizy kryminalistycznej, a nie jako utwardzony sensor produkcyjny. owLSM jest najbardziej zaawansowany pod kątem użycia produkcyjnego, ale jego reguły zapobiegawcze nadal wymagają dostrojenia do każdego środowiska, a reguły Sigma napisane do detekcji opartej na logach nie przenoszą się automatycznie -- pola i identyfikatory trzeba dostosować do formatu owLSM.

Dla MSP oceniającego którekolwiek z tych trzech rozwiązań praktyczne pytania pozostają takie same: czy pokrycie platform odpowiada rzeczywistej flocie, czy format reguł pokrywa się z tym, co SOC już utrzymuje, oraz czy wdraża się je do inżynierii detekcji i pokrycia pilotażowego, czy do blokowania produkcyjnego. Traktuj wszystkie trzy jako dodatek do istniejących narzędzi, a nie zamiennik, dopóki nie przetestujesz ich we własnym środowisku.

Źródła: Rustinel (GitHub), Fibratus, owLSM (GitHub).