Inżynieria detekcji – fundament skutecznego działania systemów SIEM

O inżynierii detekcji słów kilka

W dzisiejszych czasach organizacje muszą stawić czoła coraz większej liczbie zagrożeń cybernetycznych, co wymaga efektywnej identyfikacji i szybkiego działania. Dlatego kluczową rolę w ochronie organizacji odgrywają systemy SIEM (Security Information and Event Management), które zbierają i analizują logi z różnych źródeł, pomagając identyfikować podejrzane aktywności. Jednak nawet najlepsze narzędzie nie zrobi nic samo – jego skuteczność zależy od dobrze napisanych reguł detekcji.

Wiele narzędzi SIEM dostępnych na rynku oferuje zestaw gotowych reguł bezpieczeństwa, które pomagają wykrywać popularne zagrożenia. Sprawdzają się one w standardowych scenariuszach, ale nie zawsze uwzględniają specyfikę danej organizacji – jej unikalne systemy, aplikacje czy procesy. W takich przypadkach konieczne jest tworzenie własnych reguł detekcji, dopasowanych do indywidualnych potrzeb i zagrożeń charakterystycznych dla danej infrastruktury.

Identyfikacja logów, zebranie informacji

Pierwszym krokiem w tworzeniu skutecznych reguł detekcji jest dokładne zrozumienie logów generowanych przez systemy i aplikacje. Każde zdarzenie zapisane w logach może zawierać istotne informacje o potencjalnych zagrożeniach, ale aby je wychwycić, trzeba wiedzieć, jakie dane są dostępne, skąd pochodzą i jak je interpretować. Kluczowe jest więc zidentyfikowanie źródeł logów, określenie ich struktury oraz zebranie informacji, które pozwolą na efektywne budowanie reguł wykrywających niepożądane aktywności.

Z pomocą zdecydowanie przychodzi sama dokumentacja producenta, która często zawiera szczegółowe informacje na temat struktury logów, ich znaczenia oraz sposobu interpretacji poszczególnych pól. Może to obejmować przykłady zdarzeń, opisy kodów błędów, a także wskazówki dotyczące korelacji między różnymi wpisami.

Oprócz analizy dokumentacji, niezwykle cennym źródłem informacji jest rozmowa z osobami, które na co dzień pracują z danymi systemami. Administratorzy, deweloperzy i operatorzy systemów najlepiej wiedzą, jakie zdarzenia są normalne, a które mogą wskazywać na potencjalne zagrożenia. Przeprowadzenie wywiadu pozwala także wychwycić specyficzne dla organizacji niuanse, takie jak nietypowe zachowania systemu, charakterystyczne błędy czy procesy, które mogą prowadzić do generowania fałszywych alarmów.

Budowanie reguł bezpieczeństwa

Doskonałym punktem wyjścia w procesie tworzenia reguł detekcji są uznane ramy i źródła wiedzy, takie jak:

• MITRE ATT&CK – globalna baza danych, która szczegółowo opisuje techniki i taktyki wykorzystywane przez cyberprzestępców na różnych etapach ataku. Dzięki tej platformie możliwe jest mapowanie zdarzeń w systemie do konkretnych technik ataku, co umożliwia tworzenie skuteczniejszych reguł detekcji.
• Cyber Kill Chain – model, który przedstawia etapy, przez które przechodzi atak cybernetyczny, począwszy od wstępnej infiltracji, a kończąc na realizacji celu. Pozwala on zidentyfikować punkty, w których można skutecznie wdrożyć detekcję i interwencję, minimalizując ryzyko poważnych szkód.

Budowanie reguły bezpieczeństwa wymaga osiągnięcia równowagi pomiędzy specyficznymi przypadkami a zbyt ogólnym zakresem detekcji.

Przykładem może być reguła, która koncentruje się wyłącznie na monitorowaniu komend wykonywanych z konta root. Tego rodzaju podejście może nie zauważyć ataku przeprowadzanego z konta z podwyższonymi uprawnieniami, które nie jest kontem root, ale może być wykorzystywane do złośliwych działań.

Ważny jest również balans w ilości reguł ze względu na priorytet, pewność ataku oraz wpływ na organizację. Monitorując jedynie najpoważniejsze zagrożenia możemy nie dostrzec ataku który zaczyna się od potencjalnie niegroźnego zachowania.

W przypadku tworzeniu reguł dobrze jest sobie zadawać konkretne pytania. Pytaniem, które nie umożliwi jednoznacznej odpowiedzi jest pytanie „Czy użytkownik powinien zmieniać dane konfiguracyjne w systemie?”. Na to pytanie mogą wpływać różne czynniki, takie jak uprawnienia administratora, potrzeba natychmiastowych zmian w przypadku awarii, czy planowane aktualizacje.

Lepszym pytaniem będzie: „Czy użytkownik próbował zmienić dane konfiguracyjne w systemie produkcyjnym po godzinach pracy, bez odpowiednich uprawnień, korzystając z konta, które nigdy wcześniej nie było używane do takich operacji?”. Na podstawie tego drugiego pytania powinniśmy zdefiniować potencjalną regułę.

Przykładem reguł które znajdują się na samym szczycie jeśli chodzi o priorytet, pewność oraz wpływ są działania, które od razu wskazują na atak bądź kompromitację systemów:

• uruchomienie narzędzi takich jak Mimikatz, wykorzystywanego do zbierania haseł i eskalacji uprawnień,
• zainstalowanie oprogramowania koparki kryptowalut.

Nie oznacza to, że reguły o niskim priorytecie oraz wpływie na organizacje nie są potrzebne. Są zdarzenia, w przypadku których nie musimy od razu rzucać naszych zadań i jak najszybciej potwierdzać działań, wdrażając procedurę reakcji na incydent. Przykładem może być np. wiele nieudanych logowań do konta użytkownika, wiedząc że stare hasło użytkownika wyciekło, a sam użytkownik ma włączone uwierzytelnianie dwuskładnikowe.

Monitorowanie luk w detekcji oraz stałe dostosowywanie reguł.

Monitorowanie luk w detekcji i ciągłe dostosowywanie reguł to kluczowe elementy skutecznego systemu bezpieczeństwa. Z biegiem czasu zagrożenia oraz środowisko IT zmieniają się, co może powodować, że niektóre reguły stają się mniej skuteczne. Regularna analiza wyników detekcji pomaga zidentyfikować obszary, w których system może przeoczyć istotne zdarzenia. Ważne jest, aby na bieżąco dostosowywać reguły do nowych zagrożeń, wprowadzanych zmian w infrastrukturze IT oraz informacji zwrotnych od zespołu. Tylko w ten sposób możemy utrzymać wysoką skuteczność wykrywania i minimalizować ryzyko przeoczenia incydentów.