10 kroków do sprawnego SIEM i inżynierii detekcji w cybersecurity

Zdjęcie: SIEM detection engineering

Systemy SIEM i inżynieria detekcji to nie tylko dane i reguły detekcji. Z czasem coraz większe znaczenie ma planowanie i procesy. W 10 punktach dowiesz się jak sprawnie podejść do detekcji w cybersecurity.

1. Po prostu zacznij

Jeśli kiedykolwiek programowałeś/aś, na pewno kojarzysz inżynierię oprogramowania. W projektach możemy kierować się różnymi metodykami. Kiedyś na topie był model kaskadowy (waterfall), czyli najpierw był plan, potem analiza, potem implementacja… a pod koniec okazywało się iż klient zamawiał coś innego. Rozwiązaniem tego problemu było programowanie zwinne (agile), którego populanym przykładem jest Scrum.

Ale czemu w artykule o SIEM i inżynierii detekcji wspominam o metodykach zwinnych? Ponieważ można je na swój sposób wdrożyć w świat cybersecurity. Wiele osób pyta mnie jak mają zacząć, ile serwerów zamówić, jakie dyski, ile węzłów itp. Odpowiedź jest prosta: to zależy.

Wszystko zależy od kontekstu. Najlepiej zacząć jak najszybciej. Postawić prosty klaster i zacząć zbierać logi. Co zyskamy?

1. Pierwszą iterację/sprint
2. Rozpoznamy jakie źródła mamy do dyspozycji
3. Zaczniemy proces parsowania źródeł które nie mają gotowych rozwiązań
4. Dowiemy się jak jak dużo logów do nas trafia (events per second) oraz jak dużo ważą (storage)
5. Dowiemy się jak mało wiedzialiśmy o swoim monitorowanym środowisku
6. Jeśli źródeł będzie za dużo to… dowiemy się jakie logi są dla nas najbardziej istotne.
7. Podstawową wiedzę do zaplanowania kolejnej iteracji i zakupów licencji/sprzętu.

Ja akurat jestem zwolennikiem Elastic Stack (psst! Mam choćby kursik ) i używania darmowej wersji. Masz bardzo dużo rzeczy do ogarnięcia zanim zaczniesz korzystać z funkcjonalności płatnych. Chyba iż od samego początku potrzebujesz EDR’a, wtedy potrzebujesz wersji Platinium.

Psst! Możesz mieć kilka różnych klastrów .

2. Zadbaj o normalizację modelu danych

Normalizacja danych to kluczowa rzecz w kontekście danych w SIEM. Dlaczego? Wyobraź sobie sytuację, w której 4 źródła logów parsowane są przez 4 osoby bez żadnych wytycznych. Oto co dostaniesz:

1. Adam zastosował konwencję src_ip oraz dst_ip
2. Józek preferuje camelCase, czyli srcIp oraz dstIp
3. Oliwia użyła source.ip oraz destination.ip, a choćby użyła specjalnego typu danych IP (pozwala na szukanie po maskach podsieci)
4. Tomek pracował sporo w MySQL, więc IP jest w postaci int(4)

Jak widzisz mamy problem… Trudno jest się w tym odnaleźć, a co dopiero napisać regułę detekcji.

Rozwiązaniem jest nałożenie konwencji nazw pól i ich typów. Uniwersalnym przykładem jest OSSEM, natomiast w świecie Elastic Stack naturalnym wyborem jest Elastic Common Schema (ECS). Warto również wykorzystać specjalne typy takie jak IP, Geopoint,Geoshape, Histogram lub czas w nanosekundach.

3. Zaplanuj retencje danych

Prędzej czy później spotkasz się z sytuacją gdy braknie Cie miejsca na dyskach (lub wręcz odwrotnie, będziesz mieć dużo miejsca w porfelu ). Przy planowaniu rozwiązania typu SIEM warto ustalic docelową retencje danych. Im mniejsza, tym więcej zaoszczędzimy na sprzęcie lub usługach w chmurze. Z drugiej strony, o fakcie włamania możemy dowiedzieć się długo po jego wystąpieniu. Bez logów ciężko będzie o analizę. Są też formalne wymagania wynikające z norm/standardów które nasza organizacja musi spełniać.

Warto w tym momencie wspomnieć o temperaturze danych. Dane gorące to te najczęściej używane przez analityków i reguły detekcji (np. do 1-2 tygodni). Dane ciepłe są sporadycznie używane, głównie przez analityków (np. do miesiąca). Dane zimne są rzadko używane i znajdują się na wolniejszych (tańszych) serwerach. W Elastic Stack stosuje się właśnie architekturę Hot Warm Cold.

A co gdy musimy dane trzymać rok, ale nie stać na na tak dużego SIEM’a? Możemy je wrzucać skompresowane na NFS/AWS S3/Azure Blob Storage/Cloud Storage. Trzeba tylko przewidzieć jak je wyciągać i przetwarzać.

4. Monitoruj strumienie danych

Masz SIEM’a, źródła danych, reguły detekcji i… nagle odkrywasz, iż najważniejsze źródło przestało logować miesiąc temu. Musimy pamiętać, iż każdy nowy element naszej architektury to nasza odpowiedzialność. Postawiłeś/aś klaster Kafki? Super! Pamiętaj o odpowiednim monitoringu.

W ramach SPEED SIEM Use Case Framework można zauwazyć specjalną kategorię reguł o nazwie Self-Monitoring. Dlaczego jest tak istotna?

Bez danych nie ma reguł detekcji. Po prostu nie działają, bo nie mają na czym działać.

5. Zaplanuj flow tworzenia reguł detekcji

Z czasem zauważysz, iż pomysłów i potrzeb na reguły jest sporo. Trzeba ten proces uporzadkować. Możesz zasugerować się artykułem napisanym przez Alex’a i wdrożyć go u siebie. Warto zastosować choćby najprostszy issue tracker i spróbować organizować swoją pracę. Poniżej kategorie które mogą się przydać:

1. Backlog – tam trafiają wszystkie nowe pomysły i potrzeby
2. Doing/Development – w trakcie implementacji
3. Documentation – o tym będzie niżej
4. Waiting – w dużych organizacjach nierzadko polegamy na pracy innych zespołów.
5. Testing – musimy wygrzać regułę przed wrzuceniem na produkcję
6. Done –

6. Zidentyfikuj assety

Według wikipedii, triaż to procedura medyczna umożliwiająca służbom medycznym segregację rannych w zależności od stopnia obrażeń oraz rokowania. Stosuje się go nie tylko w medycynie, ale również w Incident Response.

Wdrażanie SIEM’a to proces. Tworzenie reguł detekcji to również proces. W pierwszej kolejności musimy zabezpieczyć najważniejsze elementy systemu np. kontroler domeny, serwer poczty, główny serwer bazy danych naszej aplikacji. Musimy kawałek po kawałku poznawać elementy naszego systemu, ich właścicieli, zainstalowane systemy bezpieczeństwa i logi jakie z nich zbieramy.

Zebrane informacje będą przydatne przy szacowaniu pokrycia przez logi i reguły detekcji. Możemy do tego wykorzystać projekt Detect Tactics, Techniques & Combat Threats (DeTT&CT). W ten sposób oszacujemy czy zbieramy wystarczająco logów i zdarzeń z danego systemu.

7. Dokumentuj

W Inżynierii Danych można spotkać się z Silosami Danych. Są to odizolowane, oddzielne i często niepowiązane ze sobą dane w różnych systemach. Takim silosem może być plik Excel u Twojego kolegi z pracy. Ciężko nim zarządzać oraz ciężko do niego dotrzeć. Wpływa to negatywnie na eksploracje danych.

Takim “białkowym” silosem danych może być… po prostu Twój kolega. Pracuje w firmie od lat. Pytasz go o adres IP, a on odpowiada szczegółowo co to jest i kto tym zarządza. Fajnie mieć takiego kolegę. Niestety taki dostęp do informacji nie skaluje się i posiada niski bus factor .

Jak rozwiązać ten problem? Jeszcze nie wiem! Polecam korzystanie z wiki i trzymanie dokumentacji w plikach markdown. Niestety już wiem, iż ten sposób od pewnego momentu również słabo się skaluje. Aktualnie pracuję nad generowaniem dokumentacji z plików YAML o konkretnym schemacie. Zobaczymy co z tego wyjdzie.

Dobrze przygotowana dokumentacja na pewno ułatwi i przyśpieszy proces wdrażania nowych osób do zespołu. Zidentyfikowane assety z punktu 6 warto wrzucić do dokumentacji.

8. Zautomatyzuj detekcję IoC

Czytasz raport o nowym zagrożeniu w sieci, tworzysz regułę, wrzucasz IoC z raportu. Czytasz kolejny raport, tworzysz kolejną regułę, wrzucasz kolejne IoC… Po jakimś czasie juz Ci się to nudzi, a stare reguły można wywalić bo adwersaż juz dawno zmienił adresy IP i domeny (Piramyd of Pain).

Detekcja na podstawie IoC jest pierwszym typem reguły do zautomatyzowania. Życiem IoC można zarządzać MISP’ie. Elastic Stack, a dokładnie Filebeat, ma moduł do pobierania danych z MISP’a i innych źródeł IoC. Kilka generycznych reguł powinno załatwic sprawę.

9. Określ metryki

W przypadku programowania w miarę łatwo określić cel i mierzyć progress. Mamy zestaw funkcjonalności, definiujemy zadania. Z każdym kolejnym sprintem aplikacja wygląda coraz lepiej, a klient jest coraz bardziej zadowolony (przynajmniej w teorii ).

W inżynierii detekcji sprawa jest trochę bardziej skomplikowana. Trzeba określić miejsce w którym jesteśmy i miejsce w którym chcemy się znaleźć. Możemy mierzyć postęp w kategoriach takich jak dojrzałość (zespołu, procesów) oraz pokrycie (źródła danych, reguły).

Detection Engineering Maturity Matrix

Kyle Bailey określił macierz dojrzałosci inżynierii detekcji. Tutaj znajdziesz jego artykuł, a tutaj projekt na GitHib. Utworzyłem też wersję w Google Sheets.

Macierz porusza kategorie takie jak ludzie, procesy, technologia i detekcja. Nie ma sensu pisać o tym więcej, lepiej przejrzeć macierz .

MITRE

MITRE to organizacja non-profit zajmująca się problemami związanymi z cyberbezpieczeństwem. Znana jest z publicznie dostępnych produktów takich jak:

1. MITRE ATT&CK – Baza wiedzy o taktykach i technikach adwersarzy. Jest to podstawa do opracowania konkretnych modeli zagrożeń i metodologii. Pod kątem technik, jest bardziej szegółowa niż Cyber Kill Chain. Jest podstawą innych narzędzi, np. wspomnianego już DeTT&CT.
2. MITRE ATT&CK Navigator – narzędzie do opisywania i eksplorowania macierzy ATT&CK. Można w nim utworzyć wizualizację pokrycia źródeł logów, reguł detekcji i działań ofensywnych.
3. MITRE D3FEND – Model grafowy zorientowany na środkach przeciwdziałającym zagrożeniom. Każdy środek ma powiązanie z technikami w ATT&CK
4. MITRE Engage – Platforma mająca na celu skuteczne zaangażowanie adwersarza, czyli wpuszczenie go w maliny i wyciągnięcie wniosków .

Każda organizacja będzie miała inny model zagrożeń, a więc inne KPI. Mierzenie pokrycia wykorzystując powyższe narzędzia pozwala określić swoje słabe i mocne strony oraz podejmować decyzje.

10. Nie zawracaj sobie głowy ML

Machine Learning, Deep Learning, Blockchain, Big Data, NFT… to wszystko są fajne i seksowne słowa, którymi sprzedawcy nęcą osoby decyzyjne w firmach. Nie mówię, iż nie są to fajne zagadnienia, bo są.

Zmierzam do tego, iż Machine Learning to wisienka na torcie. Nie ma sensu po nią sięgać bez przerobionych punktów 1-9. Nieraz zgłaszała się do mnie firma która chciała robić ML nie wiedząc do końca co tak naprawdę chce osiągnąć. Nie idź tą drogą. Prostego IF’a łatwiej i szybciej wdrożyć, wytłumaczyć i używać . Nie jestem odosobniony w tym stwierdzeniu. W Cloud Security Podcast słyszałem o tym nie raz.

Podsumowanie

Ten artykuł to próba uporządkowania doświadczeń i zdobytej wiedzy. jeżeli masz jakiś komentarz lub propozycję, chetnie ją poznam.