Threat hunting to proaktywne, prowadzone przez człowieka poszukiwanie oznak obecności zagrożenia w środowisku IT, zanim wygeneruje ono alert w systemie automatycznej detekcji — w odróżnieniu od klasycznej pracy zespołu SOC, który reaguje na alerty już wygenerowane przez narzędzia. Zakłada, że część zaawansowanych ataków celowo unika wyzwalania automatycznych reguł detekcji, więc jedynym sposobem ich znalezienia jest aktywne, hipotezowe przeszukiwanie danych.
Na skróty
Czego dowiesz się z artykułu:
- Czym threat hunting różni się od reagowania na alerty w klasycznym SOC
- Tabela porównawcza obu podejść pod kątem inicjatywy, danych wejściowych i celu
- Plan pierwszego cyklu threat huntingu krok po kroku
- Jakie źródła danych są potrzebne, zanim zespół zacznie polować na zagrożenia
- Jak framework MITRE ATT&CK pomaga formułować hipotezy do przeszukania
Dla kogo ten artykuł:
- Zespoły SOC rozważające rozszerzenie działań o threat hunting
- Menedżerowie bezpieczeństwa oceniający dojrzałość zespołu przed inwestycją w tę funkcję
- Analitycy bezpieczeństwa planujący pierwszy cykl proaktywnego poszukiwania zagrożeń
Czas czytania: 6 minut
Czym threat hunting różni się od reagowania na alerty w klasycznym SOC
Klasyczny Security Operations Center (SOC) działa reaktywnie: system detekcji (SIEM, EDR) generuje alert na podstawie zdefiniowanej reguły lub anomalii, a analityk bada ten konkretny alert. To podejście działa dobrze dla znanych wzorców ataku, ale ma lukę: zagrożenie, które nie wyzwala żadnej reguły — bo jest nowe, dobrze zamaskowane lub wykorzystuje legalne narzędzia systemowe w nietypowy sposób — pozostaje niewykryte, dopóki nie wyrządzi szkody widocznej innymi środkami.
Threat hunting odwraca ten kierunek pracy: analityk zaczyna od hipotezy („czy w naszym środowisku mogła wystąpić technika X, opisana w MITRE ATT&CK”) i aktywnie przeszukuje dane, żeby ją potwierdzić lub odrzucić — niezależnie od tego, czy jakikolwiek alert się wygenerował. SANS Institute, w swoich cyklicznych badaniach nad praktyką threat huntingu w organizacjach, konsekwentnie wskazuje dojrzałość źródeł danych i jakość logów jako czynnik decydujący o skuteczności programu threat huntingu silniej niż samo doświadczenie analityka.
Threat hunting vs reagowanie na alerty SOC — porównanie
| Kryterium | Klasyczny SOC (reaktywny) | Threat hunting (proaktywny) |
|---|---|---|
| Punkt startowy | Alert wygenerowany przez system detekcji | Hipoteza sformułowana przez analityka |
| Inicjatywa | Narzędzie inicjuje badanie | Człowiek inicjuje badanie |
| Zakres wykrywanych zagrożeń | Znane wzorce objęte regułami detekcji | Także zagrożenia niewyzwalające żadnej reguły |
| Wymagane dane | Alerty i logi powiązane z konkretnym zdarzeniem | Szeroki, historyczny dostęp do logów z wielu źródeł |
| Rezultat | Zamknięcie lub eskalacja konkretnego alertu | Potwierdzona lub odrzucona hipoteza, czasem nowa reguła detekcji |
Threat hunting nie zastępuje klasycznego SOC — uzupełnia go tam, gdzie automatyczna detekcja z definicji nie sięga.
Plan pierwszego cyklu threat huntingu krok po kroku
- Sformułuj konkretną, testowalną hipotezę — nie „szukajmy czegoś podejrzanego”, tylko konkretne pytanie, np. „czy w naszym środowisku występują ślady bocznego ruchu (lateral movement) przez protokół RDP w nietypowych godzinach”.
- Wykorzystaj MITRE ATT&CK jako źródło hipotez — framework katalogujący realnie obserwowane techniki ataku pozwala systematycznie przechodzić przez kolejne taktyki, zamiast zgadywać, czego szukać.
- Zweryfikuj, czy masz dane potrzebne do zbadania hipotezy — brak odpowiednich logów (np. logów uwierzytelniania czy ruchu sieciowego) unieważnia hipotezę, zanim badanie się zacznie; to najczęstszy powód nieudanych pierwszych cykli.
- Przeszukaj dane pod kątem hipotezy, dokumentując proces — zapisuj, czego szukałeś i dlaczego, niezależnie od wyniku; nieudokumentowane polowanie, które nic nie znalazło, traci wartość dla przyszłych cykli.
- Potwierdź lub odrzuć hipotezę na podstawie zebranych dowodów — brak dowodu potwierdzającego zagrożenie to wartościowy wynik, nie porażka; oznacza, że dana technika ataku prawdopodobnie nie występuje w środowisku.
- Przekształć potwierdzone ustalenia w nową regułę detekcji — jeśli hipoteza się potwierdziła, zamień ręczne poszukiwanie w automatyczną regułę, żeby przyszłe wystąpienia tej samej techniki generowały alert bez konieczności ponownego ręcznego polowania.
Jakie źródła danych są potrzebne, zanim zespół zacznie polować na zagrożenia
Threat hunting bez odpowiednich danych źródłowych jest ćwiczeniem teoretycznym. Minimalny zestaw obejmuje logi uwierzytelniania (kto, kiedy, skąd loguje się do systemów), logi ruchu sieciowego (jakie połączenia są nawiązywane między hostami), logi punktów końcowych z narzędzia EDR (jakie procesy uruchamiają się na stacjach roboczych i serwerach) oraz wystarczająco długi okres retencji tych danych — hipoteza dotycząca zdarzenia sprzed trzech miesięcy jest bezużyteczna, jeśli logi są przechowywane tylko przez 30 dni. SANS Institute w swoich badaniach wskazuje niewystarczającą retencję i fragmentaryczne pokrycie logowania jako jedną z głównych barier, które organizacje napotykają przy próbie uruchomienia programu threat huntingu — problem częściej dotyczy dostępności danych niż samych umiejętności analityków.
Przeczytaj również
- Architektura Zero Trust: bezpieczeństwo bez zaufanej sieci — jak proaktywne podejście do bezpieczeństwa wpisuje się w szerszą architekturę Zero Trust
- SOC — budowa zespołu Security Operations Center — jak threat hunting wpisuje się w strukturę i dojrzałość zespołu SOC
Rozwiń kompetencje
Temat tego artykułu jest powiązany ze szkoleniem Threat Hunting Fundamentals — proaktywne wykrywanie zagrożeń. Sprawdź program i zapisz się, aby rozwinąć kompetencje pod okiem ekspertów EITT.
Najczęściej zadawane pytania
Czym threat hunting różni się od pracy analityka SOC?
Analityk SOC reaguje na alerty już wygenerowane przez system detekcji. Threat hunter aktywnie formułuje hipotezę o możliwym zagrożeniu i przeszukuje dane, żeby ją potwierdzić lub odrzucić, niezależnie od tego, czy jakikolwiek alert się pojawił — obejmuje to zagrożenia, które z definicji nie wyzwalają żadnej reguły detekcji.
Czy brak potwierdzonego zagrożenia oznacza nieudany cykl threat huntingu?
Nie — odrzucona hipoteza to wartościowy wynik, pokazujący, że dana technika ataku prawdopodobnie nie występuje w środowisku. Realną porażką jest cykl bez sformułowanej, testowalnej hipotezy albo bez odpowiednich danych źródłowych do jej zbadania.
Jak framework MITRE ATT&CK pomaga w threat huntingu?
Katalogując realnie obserwowane techniki ataku w ustandaryzowany sposób, pozwala systematycznie przechodzić przez kolejne taktyki i techniki jako źródło hipotez do przeszukania, zamiast zgadywać, czego szukać w danych.
Jaka jest najczęstsza bariera przy uruchamianiu programu threat huntingu?
Niewystarczająca retencja logów i fragmentaryczne pokrycie logowania — bez wystarczająco długiego okresu przechowywania logów uwierzytelniania, ruchu sieciowego i danych z EDR, wiele hipotez threat huntingu nie da się w ogóle zbadać, niezależnie od umiejętności analityków.