Wykrywanie i analiza: identyfikowanie rzeczywistych incydentów

Faza wykrywania i analizy rozpoczyna się w momencie zidentyfikowania potencjalnego incydentu bezpieczeństwa i kończy, gdy zakres oraz wpływ incydentu są już na tyle dobrze poznane, że można rozpocząć izolowanie zagrożenia. Głównym wyzwaniem na tym etapie jest odróżnienie prawdziwych trafień od fałszywych trafień — alertu wygenerowanego przez złośliwą aktywność od alertu wywołanego normalnym, choć nietypowym zachowaniem. Skuteczne wykrywanie wymaga prawidłowo skonfigurowanych narzędzi, przeszkolonych analityków oraz udokumentowanych wzorców normalnej aktywności.

Incydenty są wykrywane za pośrednictwem wielu kanałów: alertów SIEM generowanych przez reguły korelacji, detekcji EDR wynikających z analizy behawioralnej na punktach końcowych, zgłoszeń użytkowników (najczęstszego źródła początkowego wykrycia phishingu), powiadomień od podmiotów zewnętrznych (organów ścigania, dostawców threat intelligence, usług powiadamiania o naruszeniach), automatycznego skanowania (skanerów podatności lub anomalii wykrywanych przez CSPM) oraz threat hunting (proaktywnego dochodzenia). Każde źródło ma inny poziom wiarygodności i dostarcza innego rodzaju dowodów.

Skuteczne wykrywanie wymaga gromadzenia logów z różnych źródeł. Najważniejsze typy logów to: logi uwierzytelniania (Windows Security Event Log, /var/log/auth.log) dotyczące nieudanych i pomyślnych logowań, logi sieciowe (firewall, VPC Flow Logs, proxy) dotyczące nietypowych połączeń, logi DNS dotyczące zapytań do znanych złośliwych domen, logi punktów końcowych (EDR, Sysmon) dotyczące tworzenia procesów i aktywności plików oraz logi audytowe chmury (CloudTrail, Azure Monitor) dotyczące wywołań API. SIEM agreguje i koreluje te różnorodne źródła.

Analitycy SOC przeprowadzają codziennie triage setek lub tysięcy alertów, z których większość to fałszywe trafienia — prawidłowa aktywność, która uruchomiła regułę detekcji. Fałszywe trafienie marnuje czas analityka i powoduje zmęczenie alertami, przez które rzeczywiste zagrożenia mogą zostać zlekceważone. Prawdziwe trafienie oznacza rzeczywistą złośliwą aktywność. Fałszywie ujemny wynik to najgroźniejszy przypadek — złośliwa aktywność, która w ogóle nie wygenerowała alertu. Dostosowywanie reguł detekcji w celu ograniczenia fałszywych trafień bez zwiększania liczby wyników fałszywie ujemnych jest jedną z podstawowych umiejętności w SOC.

Reguły korelacji SIEM łączą wiele pojedynczych zdarzeń w logach, aby identyfikować wzorce wskazujące na ataki. Przykład: jedno nieudane logowanie jest normalne, ale 100 nieudanych logowań z tego samego adresu IP w ciągu 60 sekund wskazuje na brute force. Inny przykład: uwierzytelnienie użytkownika w Stanach Zjednoczonych o 9:00, a następnie w Chinach o 11:00 jest niemożliwą podróżą — najprawdopodobniej oznacza przejęcie konta. Skuteczne reguły korelacji równoważą czułość (wykrywanie rzeczywistych ataków) ze swoistością (niezalewanie analityków szumem).

Podczas analizy osoby reagujące gromadzą Indicators of Compromise (IoCs) charakteryzujące atak: podejrzane adresy IP, złośliwe nazwy domen, skróty plików złośliwego oprogramowania, klucze rejestru zmodyfikowane przez atakującego, nietypowe nazwy procesów lub relacje nadrzędny-podrzędny oraz anomalne połączenia sieciowe. IoC służą do: określania zakresu (czy ten IoC występuje na innych systemach?), wzbogacania threat intelligence, blokowania dalszego dostępu atakującego oraz opracowywania reguł SIEM wykrywających podobną aktywność w przyszłości.

Analiza zakresu odpowiada na pytania: Jakie systemy zostały zaatakowane? Do jakich danych uzyskano dostęp lub jakie dane wyeksfiltrowano? Jak i kiedy atakujący dostał się do środka? Osoby reagujące wykorzystują analizę logów do odtworzenia osi czasu ataku, identyfikacji początkowego wektora dostępu, sporządzenia listy wszystkich systemów, których dotknął atakujący (ruch boczny), oraz ustalenia, czy doszło do eksfiltracji danych (nagłe wzrosty transferu wychodzącego, katalogi buforowania danych). Ocena zakresu wyznacza decyzje dotyczące izolowania zagrożenia — nie można odizolować tego, czego wcześniej nie zmapowano.

Platformy EDR (Endpoint Detection and Response) są podstawowym narzędziem technicznym do analizy incydentów na poziomie punktów końcowych. Telemetria EDR dostarcza informacji o: drzewach wykonywania procesów (co uruchomiło dany proces), aktywności systemu plików, połączeniach sieciowych poszczególnych procesów, modyfikacjach rejestru oraz wykrywaniu wstrzykiwania do pamięci. Podczas incydentu EDR pozwala analitykom jednocześnie wyszukiwać IoC na wszystkich punktach końcowych (hunt w całym przedsiębiorstwie), odizolować przejęty punkt końcowy od sieci oraz pobierać artefakty kryminalistyczne bez fizycznego dostępu do systemu.

Dowody sieciowe są często najbardziej wiarygodnym źródłem podczas analizy incydentu. NetFlow i VPC Flow Logs pokazują połączenia między systemami bez ujawniania treści przesyłanych danych — są przydatne do mapowania ruchu bocznego. Pełne przechwytywanie pakietów (PCAP) pokazuje pełną treść komunikacji, w tym dane uwierzytelniające, wyeksfiltrowane dane i polecenia C2 (jeśli ruch nie jest szyfrowany). Logi zapytań DNS ujawniają komunikację malware z domenami C2. Osoby reagujące szukają: dużych transferów danych wychodzących, połączeń z nietypowymi portami, wzorców beaconingu (regularnych połączeń co N sekund) oraz oznak skanowania wewnętrznego.

Odtworzenie osi czasu ataku jest niezbędne do zrozumienia czasu przebywania atakującego w środowisku (jak długo był obecny przed wykryciem), zidentyfikowania początkowego wektora dostępu (aby usunąć podatność) oraz zachowania dowodów w porządku chronologicznym na potrzeby postępowania prawnego. Osie czasu tworzy się przez korelowanie znaczników czasu z wielu źródeł logów. Kluczowa jest synchronizacja czasu (z użyciem NTP) — logi z nieprawidłowymi zegarami systemowymi tworzą luki i sprzeczności na osiach czasu, podważając wnioski z analizy kryminalistycznej.

Nie każdy alert wymaga pełnej aktywacji CSIRT. Analitycy korzystają z udokumentowanych kryteriów, aby określić wyzwalacze eskalacji: wykrycie potwierdzonego wycieku danych powoduje obowiązek wysłania powiadomień wymaganych przepisami oraz eskalację do kadry kierowniczej. Wykrycie złośliwego oprogramowania, które rozprzestrzeniło się poza jeden system, wymaga pełnego zaangażowania CSIRT. Pojedyncza wiadomość phishingowa (bez kliknięcia) pozostaje na poziomie analityka pierwszej linii. Dobrze zdefiniowane progi eskalacji zapobiegają zarówno nadmiernej reakcji (marnowaniu zasobów na drobne zdarzenia), jak i niewystarczającej reakcji (sytuacji, w której poważne naruszenia się nasilają, ponieważ są traktowane jak mało istotne alerty).

W tej lekcji nauczyli się Państwo, że: wykrywanie opiera się na różnorodnych źródłach logów agregowanych przez SIEM, który za pomocą reguł korelacji identyfikuje wielozdarzeniowe wzorce ataków, IoC zebrane podczas analizy służą do określenia zakresu incydentu we wszystkich systemach oraz opracowania reguł blokowania, a fałszywie ujemne wyniki są najgroźniejszym skutkiem, ponieważ pozwalają atakującym działać bez wykrycia. Następnie omówimy powstrzymywanie, likwidację zagrożenia i odzyskiwanie.