detection engineering

Detection engineering to dyscyplina projektowania, testowania i utrzymywania reguł wykrywania zagrożeń tak, jak utrzymuje się kod: z wersjonowaniem, przeglądem, testami i pomiarem skuteczności. Reguła detekcji jest w tym ujęciu produktem, który ma cel, dokumentację i znane ograniczenia, a nie jednorazowym wpisem w konsoli. Pokrycie reguł opisuje się zwykle w odniesieniu do MITRE ATT&CK, ogólnodostępnej bazy wiedzy o taktykach i technikach przeciwników opartej na obserwacjach z rzeczywistych ataków ^[1]. W polskich materiałach szkoleniowych ten sam obszar pojawia się jako tworzenie reguł detekcji i zarządzanie nimi ^[6].

Jak działa

Punktem wyjścia jest hipoteza: jaką technikę przeciwnika reguła ma wychwycić i w jakich danych zostawia ona ślad. Hipoteza pochodzi z threat intelligence, z wyników threat huntingu (polowania na zagrożenia) albo z analizy incydentu. Następnie reguła powstaje w repozytorium, przechodzi test na przykładowych zdarzeniach, trafia do SIEM i jest mierzona w produkcji.

RYS. 1Cykl życia reguły detekcji

Firma Palantir opisała, dlaczego taka dyscyplina jest potrzebna. Przed wprowadzeniem własnego frameworka brakowało rygoru przy tworzeniu alertów, więc do produkcji trafiały reguły bez dokumentacji i przeglądu; część z nich zyskała opinię niskiej jakości, co prowadziło do zmęczenia, apatii wobec alertów albo dodatkowego nakładu pracy ^[3]. Odpowiedzią był framework Alerting and Detection Strategy (ADS), czyli szablon, który każda reguła musi wypełnić przed wdrożeniem ^[3].

Składniki

Palantir przechowuje każdy alert opisany według ADS w trwałym, wersjonowanym i centralnym miejscu, na przykład w repozytorium ^[3]. Podobną rolę pełni Sigma, którą twórcy opisują jako ogólny i otwarty format sygnatur do opisu zdarzeń w logach ^[2]. Sigma ma być dla logów tym, czym Snort dla ruchu sieciowego i YARA dla plików; jej główne repozytorium zawiera ponad 3000 reguł ^[2]. Twórcy podkreślają, że reguły Sigma nie są związane z jednym producentem, a do ich konwersji na zapytania konkretnych systemów służy oficjalne narzędzie Sigma CLI ^[2].

Do testów służą biblioteki symulujące techniki przeciwnika. Atomic Red Team to biblioteka testów przypisanych do technik MITRE ATT&CK, pozwalająca szybko i powtarzalnie sprawdzić środowisko ^[4]. W praktyce takie testy łączą pracę red teamu i obrońców, czyli blue teamu, w ćwiczeniach typu purple team. Po stronie SIEM przydaje się tester reguł: w Wazuhu narzędzie wazuh-logtest pozwala sprawdzić, które dekodery i reguły pasują do podanych próbek logów, i korzysta z tych samych reguł co silnik analizy ^[5].

Wspólne formaty sprzyjają wymianie reguł. Twórcy Sigmy piszą, że głównym celem projektu jest ustrukturyzowana forma, w której badacze i analitycy opisują opracowane metody wykrywania i udostępniają je innym ^[2]. Reguły w repozytorium przechodzą przegląd społeczności zawodowych inżynierów detekcji ^[2]. Palantir, publikując swój framework z przykładami, wyraził nadzieję, że dzielenie się regułami podniesie koszt operacyjny działań atakujących ^[3].

Wiedza o przeciwniku, na której opiera się reguła, pochodzi z ATT&CK. MITRE podaje, że baza ta służy jako podstawa do budowania modeli zagrożeń i metodyk w sektorze prywatnym, administracji i wśród dostawców produktów bezpieczeństwa ^[1]. W programach szkoleń z systemów SIEM tworzenie reguł detekcji występuje obok analizy alertów i symulacji ataku z analizą jego skutków ^[6], co odpowiada pętli: reguła, test, wniosek.

W WordPressie

Dla strony na WordPressie detection engineering zaczyna się od pytania, które zdarzenia w ogóle są rejestrowane. Rdzeń udostępnia na przykład hak wp_login_failed, uruchamiany po nieudanym logowaniu, który przekazuje login lub adres e-mail oraz obiekt błędu ^[7]. Wtyczka albo serwer mogą zapisywać te zdarzenia do logu, który następnie czyta SIEM. Na tej podstawie można zbudować regułę wykrywającą atak siłowy (brute-force) na panel.

Poniższy szkic reguły w formacie Sigma opisuje żądania logowania w logu serwera WWW. Próg liczby prób ustala się osobno, a reguła musi mieć opisane fałszywe alarmy.

title: Wiele prób logowania do WordPressa
logsource:
  category: webserver
detection:
  selection:
    cs-method: POST
    cs-uri-stem: /wp-login.php
  condition: selection
falsepositives:
  - menedżer haseł lub monitoring dostępności logujący się cyklicznie
level: medium

Taka reguła uzupełnia mechanizmy zapobiegawcze, jak limit prób logowania. Blokada zatrzymuje pojedynczy adres, a reguła pokazuje zjawisko w skali wielu stron i adresów.

Znaczenie

Reguła bez pomiaru z czasem traci wartość. Fałszywe alarmy (false positive) prowadzą do zmęczenia alertami (alert fatigue), co opisuje przykład Palantira ^[3]. Brak detekcji dla znanej techniki oznacza z kolei lukę, której nie widać, dopóki ktoś jej nie wykorzysta. Sekcja o martwych polach w ADS zmusza autora do nazwania takich luk przed wdrożeniem ^[3].

Detection engineering jest przez to łącznikiem między wiedzą o taktykach, technikach i procedurach (TTP) przeciwników a codzienną pracą SOC. Od jakości reguł zależy wskaźnik MTTD, a od opisanej sekcji reakcji — to, czy analityk ma gotowy playbook.

Dobre praktyki

• Każdą regułę przypisz do techniki ATT&CK i zapisz cel ^{[1] [3]}.
• Trzymaj reguły w repozytorium z historią zmian i przeglądem ^[3].
• Testuj reguły na próbkach logów przed wdrożeniem ^[5] i na symulacji techniki po wdrożeniu ^[4].
• Dokumentuj znane fałszywe alarmy i martwe pola ^[3].
• Korzystaj z otwartych formatów, by reguła przetrwała zmianę narzędzia ^[2].