W poprzednim poście przyglądaliśmy tworzeniu i funkcjonalności reguł YARA, które są nieocenioną pomocą dla analityków w wykrywaniu i klasyfikacji plików. Niektórzy mogliby jednak powiedzieć, iż dzisiaj to za mało. W końcu coraz popularniejsze są ataki typu living off the land, gdzie atakujący nie korzystają z dodatkowego oprogramowania, a wystarczają im narzędzia już obecne w systemie. Jak więc tworzyć detekcje i katalogować wskaźniki aktywności o ile chcemy skupić się na zachowaniach, a nie plikach? Tutaj właśnie z pomocą przyjdą nam reguły Sigma, które niejako są dla logów zdarzeń systemowych czym reguły YARA dla plików. Z ich pomocą będziemy mogli opisywać zdarzenia, dzielić się detekcjami i wprowadzać nasze pomysły na wykrywanie złośliwej aktywności w życie przez przekładania reguł Sigma na składnię systemów takich jak Splunk czy Elastic.
Reguły korzystają z formatu YAML i ich struktura będzie bardziej złożona niż ta wykorzystywana w YARA, nie tracąc czasu przyjrzymy się jak działa Sigma. Szkielet reguły zgodnie z oficjalną specyfikacją wygląda następująco:
Jak widzimy jest tego całkiem sporo, co wynika z mnogości potencjalnych źródeł logów, a więc konieczności uwzględnienia pól które umożliwią szczegółowe określenie czego i gdzie szukamy. Zapoznajmy się teraz po kolei z poszczególnymi dostępnymi funkcjami i tym jak możemy je wykorzystać.
Pierwsza część służy określeniu nazwy reguły i dodaniu informacji pomagającymi zrozumieć kontekst i działanie detekcji. Jest to sekcja analogiczna to części „meta” z reguł YARA. Oprócz nazwy pola nie są obowiązkowe jednak zdecydowanie warto je dodać aby ułatwić korzystanie z naszego dzieła. Przybliżając po krótce pola w tej części:
- Title – obowiązkowa nazwa naszej reguły.
- id – możemy tutaj umieścić unikalny identyfikator UUID który pozwoli na jednoznaczną identyfikację detekcji.
- related – w tej podsekcji możemy wskazać odwołania do innych reguł np.: poprzednich wersji obecnej reguły.
- status – umieszczamy tutaj informacje odnośnie statusu, jak np.: czy reguła jest w fazie testów czy już gotowa do produkcji.
- description – opis funkcjonalności i zastosowania naszego dzieła.
- autor – informacja o autorze i danych kontaktowych.
- references – i w końcu możemy umieścić źródła z których korzystaliśmy tworząc regułę.
Kolejna sekcja będzie już stanowić ścisły trzon detekcji. W logsource określimy typ logów do jakiego powinna zostać zastosowana nasza reguła. Mamy tutaj do dyspozycji trzy główne pola:
- category – typ urządzenia z którego logów korzystamy jak firewall czy antywirus.
- product – jak wskazuje nazwa, określamy tutaj już konkretny product taki jak Windows lub Apache.
- service – i w końcu możemy oznaczyć kategorie logów z danego produktu, np.: w przypadku systemu Windows możemy zawęzić logi do zdarzeń z dziennika Security.
Dodatkowo aby zawęzić źródła danych możemy użyć pola Definition. Nie jest ono automatycznie przekształcane na instrukcje dla np.: Splunka, jednak może ułatwić analitykom odpowiednią konfigurację źródeł danych.
Dalej umieszczamy sekcje Detection w której określimy to co chcemy odnaleźć w logach i kiedy nasza reguła powinna wywołać alert. Tutaj kluczową rolę odgrywać będą dwie zmienne:
- selection – w której umieścimy definicje tego co chcemy znaleźć jak np.: nazwy i ścieżki plików, komendy w terminalu.
- condition – podobnie jak w YARA, warunki do spełnienia żeby reguła zareagowała, np.: jeden z dwóch warunków określonych polami selection.
Selection to właśnie część w której mamy największe pole do popisu i to tutaj będziemy definiować zmienne, identyfikatory wydarzeń i inne wartości które mogą pomóc w wykrywaniu złośliwej aktywności. Oprócz zwykłego „tekstowego” wyszukiwania możemy korzystać z list i słowników, jak i modyfikatorów wyszukiwania treści. Spójrzmy na przykłady z samej dokumentacji Sigmy:
Tutaj widzimy najprostszy przykład, kiedy wskazujemy ciągi tekstowe do wykrycia, w takim formacie jest między nimi operator OR, a więc wystarczy wykrycie jedno do wywołania detekcji.
Teraz z kolei korzystamy ze słownika, aby wywołać detekcję musi wystąpić log Security z identyfikatorem zdarzania 517 albo 1102.
W przypadku nazw plików czy konkretnych zdarzeń, taka składnia może być dla nas wystarczająca. o ile jednak chcemy wyszukiwać poleceń w terminalu bądź plików w konkretnych ścieżkach bardzo będą przydatne modyfikatory, które uwzględnia Sigma. Dodajemy je po symbolu „|” i tym samym zmieniamy zakres wyszukiwania. Przykładowo, o ile chcemy wyszukiwać ciąg znaków który występuje gdziekolwiek w poleceniu wykonanym w terminalu skorzystamy z modyfikatora „contains”, który otacza podane przez nas dane symbolami „*” czyli po i przed może wystąpić dowolny ciąg znaków. W praktyce wygląda to tak:
Wybraliśmy więc tutaj kategorię logów – tworzenie procesów, jak i produkt – system Windows. Nasz ciąg danych do wyszukania to tutaj „oursecretstring”, którego reguła będzie szukać w linii poleceń – zgodnie z modyfikatorem nie ważne gdzie wystąpi. W końcu jako warunek wskazaliśmy po prostu selection czyli tutaj wystąpienie w konkretnym logu naszego wskazanego tekstu. o ile chodzi o inne modyfikatory to warto też wskazać:
- all – zmienia warunek w listach z OR na AND, co oznacza, iż muszą być znalezione wyszystkie podane wartości.
- startwith / endswith – podobne do contains określenie miejsca występowania wskazanych danych. Możemy więc ignorować to jest po (startwith) lub przed (endswith) wskazaną wartością.
- base64 – kodowanie wartości w base64.
Pole condition działa w Sigma podobnie jak miało to miejsce w regułach YARA. Możemy więc zarówno wskazywać kryteria wprost, jak np.: „selection_1 AND selection_2” jak i korzystać z wyrażeń „all of them”, „2 of them”, „any of selection_*” i podobnych.
Na koniec spójrzmy jeszcze na dwa nieobowiązkowe ale warte uwagi pola.
W „falsepositives” możemy wskazać użytkownikom naszych reguł na co zwracać uwagę aby odsiewać podobną ale nieszkodliwą aktywność. Szczególnie w przypadku prób wykrycia stosowania technik living off the land, pomoc w odróżnianiu działań administracyjnych od złośliwej aktywności.
W końcu „level” pozwala nam określić priorytet alertu wynikającego ze znalezienia określonych w regule indykatorów. Sigma zakłada tutaj pięć poziomów:
- informational – dla reguł stosowanych raczej do oznaczania zdarzeń niż wyszukiwania zagrożeń.
- low – zdarzenia mogące świadczyć o złośliwej aktywności w określonym kontekście jak duża liczba takich zdarzeń.
- medium – znaczące wydarzenia, które powinny być regularnie sprawdzane przez analityków.
- high – zdarzenia świadczące o złośliwej aktywności, które powinny wywołać alert i zostać niezwłocznie sprawdzone.
- critical – szczególnie niebezpieczne zachowania, które powinny wywołać natychmiastową reakcję.
Łącząc falsepositives i level możemy zdecydowanie ułatwić pracę analityków. choćby najlepsza detekcja jest bowiem trudna do zastosowania o ile musimy regularnie konfrontować się fałszywie pozytywnymi alertami i trudno ocenić jest znaczenie znaleziska. Tworząc detekcję myślmy nie tylko o technicznych szczegółach, ale też implementacji reguł w warunkach pracy zespołu SOC i reagowania na incydenty.
Zbierzmy więc wszystkie te informacje i spróbujmy stworzyć już konkretną regułę, która będzie wykrywała tworzenie procesów o nazwach wykorzystywanych przez interesujące nas grupy aktywności wraz z hasłem podawanym jako argument (o których wiemy od niezastąpionego zespołu threat intelligence ).
Jeżeli chcemy teraz przekształcić naszą regułę Sigma do formatu zapytania w systemie obsługi logów z którego korzystamy jak np.: Splunk możemy skorzystać z narzędzia sigmac bądź konwertera online. Spójrzmy na rezultat skorzystania z tego ostatniego:
W ten oto sposób poznaliśmy podstawy tworzenia reguł Sigma i możemy ruszać na poszukiwania interesujących nas zdarzeń w logach które mamy do dyspozycji.
