Cel analizy incydentu sieciowego z punktu widzenia praktyka
Osoba, która siada do analizy incydentu sieciowego, zwykle chce jednego: szybko zrozumieć, co się stało, na jaką skalę i co trzeba zrobić, żeby sytuację opanować. Drugie dno to uporządkowanie własnych działań, żeby w stresie nie improwizować i nie tracić cennych minut na chaotyczne klikanie po logach.
Proces obsługi incydentu, analiza logów sieciowych i korelacja zdarzeń mają sens tylko wtedy, gdy tworzą spójną ścieżkę: od pierwszego alertu, przez triage incydentu, po końcowy raport i wnioski po incydencie. Dobrze ułożona analiza ogranicza straty, skraca przestoje i pozwala później realnie poprawić bezpieczeństwo, zamiast jedynie „gasić pożar”.
Frazy pomocnicze: proces obsługi incydentu, analiza logów sieciowych, korelacja zdarzeń, triage incydentu, analiza ruchu sieciowego, artefakty z incydentu, priorytetyzacja zdarzeń, dzienniki systemowe i aplikacyjne, komunikacja w trakcie incydentu, dokumentowanie incydentu, współpraca z SOC, wnioski po incydencie
Czym jest incydent sieciowy i kiedy zaczyna się analiza
Bez prostych definicji łatwo wpaść w skrajności: albo wszystko traktować jako krytyczny atak, albo ignorować realne zagrożenia. Na poziomie operacyjnym wystarczą praktyczne rozróżnienia, które pomagają podjąć decyzje w ciągu minut, a nie godzin.
Zdarzenie (event) to pojedynczy fakt zaobserwowany przez system: logowanie użytkownika, próba połączenia z portem, odrzucenie pakietu przez firewall, alert z IDS. Zdarzeń są miliony dziennie. Samo zdarzenie nie oznacza jeszcze problemu bezpieczeństwa.
Incydent sieciowy to zdarzenie lub seria zdarzeń, które naruszają, lub z dużym prawdopodobieństwem mogą naruszyć, poufność, integralność albo dostępność zasobów. W praktyce to moment, gdy trzeba zareagować: odciąć dostęp, zmienić regułę, sprawdzić hosty, zaangażować dodatkowe osoby.
Fałszywy alarm to alert, który wygląda podejrzanie, ale po weryfikacji okazuje się zgodny z politykami i oczekiwaniami. Nie musi oznaczać błędnej konfiguracji – czasem to po prostu cena za czułe reguły detekcji.
Analiza incydentu sieciowego zaczyna się wtedy, gdy coś przechodzi z kategorii zwykłego zdarzenia do podejrzenia incydentu. Pierwszy log, który przykuwa uwagę, często jest tylko końcówką dłuższego łańcucha. Cała praca polega na odtworzeniu reszty.
Źródła pierwszego sygnału o incydencie
Pierwszy sygnał rzadko bywa eleganckim, opisanym alarmem. Częściej to luźna obserwacja, zgłoszenie użytkownika lub „dziwny” wykres. W praktyce punkt startowy może pochodzić z kilku miejsc:
IDS/IPS – systemy wykrywania lub zapobiegania włamaniom, które sygnalizują anomalie w ruchu lub wzorce znanych ataków (np. próby exploitów, skanowanie portów).
EDR/antywirus – narzędzia na hostach, wykrywające złośliwe procesy, podejrzane połączenia wychodzące, nietypowe zachowanie aplikacji.
Monitoring dostępności – nagłe spadki wydajności, wzrost opóźnień, niedostępność usług mogą być skutkiem ataku (np. DDoS, wyciek danych, ransomware).
Zgłoszenie użytkownika – informacja o dziwnym zachowaniu systemu, oknach logowania, których wcześniej nie było, poczcie z prośbą o ponowne logowanie.
Logi z urządzeń sieciowych – nietypowe ilości ruchu na określonym porcie, gwałtowne wzrosty sesji, wiele błędnych logowań.
Kluczowe jest to, aby każdy taki sygnał miał jasno określoną ścieżkę: kto go odbiera, kto decyduje o dalszych krokach i gdzie rozpoczyna się triage incydentu.
Granica między zwykłym błędem a incydentem bezpieczeństwa
Awaria zasilania, błąd aplikacji po update czy źle skonfigurowany load balancer potrafią wyglądać podobnie jak atak. Różnica jest w tym, czy obserwowane objawy mają źródło w intencjonalnym działaniu z zewnątrz (lub wewnątrz), czy są skutkiem zwykłego błędu.
Granica jest płynna, ale pomocne są podstawowe pytania:
Czy występują próby dostępu lub ruch z nietypowych adresów IP, krajów, sieci?
Czy widać wzorce podobne do znanych technik ataków (brute force, skan portów, SQL Injection, LFI/RFI)?
Czy zakres problemu pokrywa się z jednym systemem po zmianie konfiguracji, czy dotyka wielu niezależnych usług?
Czy ktoś zmieniał coś w infrastrukturze tuż przed pierwszymi objawami?
Jeśli nie ma jasnej odpowiedzi, warto założyć ostrożnie, że to incydent bezpieczeństwa i uruchomić minimalny proces obsługi incydentu, nawet jeśli później okaże się to fałszywym alarmem. Koszt nadmiarowej czujności jest zwykle mniejszy niż koszt przeoczonego ataku.
Dlaczego szybkie nazwanie typu incydentu ma znaczenie
Nadanie roboczej etykiety w stylu „podejrzenie skanowania portów”, „podejrzenie malware na stacji X”, „możliwa exfiltracja danych z serwera Y” porządkuje pracę i komunikację. Zespół SOC i administratorzy wiedzą, czego szukać i czego się spodziewać, a nie błądzą w nieokreślonym „coś jest nie tak”.
Wczesna klasyfikacja wpływa na:
priorytetyzację zdarzeń – inne tempo reakcji przy podejrzeniu exfiltracji danych osobowych, a inne przy pojedynczych próbach logowania z obcych IP;
zaangażowanie ludzi – nie każdy incydent wymaga natychmiastowego włączenia wszystkich zespołów;
wybór narzędzi – przy podejrzeniu malware szybciej sięga się po EDR i analizę hosta, przy skanowaniu portów ważniejszy jest firewall i IDS.
Nazwa można później zmieniać i doprecyzować, gdy pojawią się nowe dane. Pierwsza etykieta to punkt orientacyjny, nie wyrok.
Przygotowanie do analizy zanim wydarzy się incydent
Fundamenty: centralizacja logów, czas i podstawowy monitoring
Bez logów nie da się prowadzić sensownej analizy incydentu sieciowego. Bez wspólnego czasu logi z różnych systemów nie dadzą się ze sobą skorelować. Bez monitoringu nie ma pierwszego sygnału. To są absolutne fundamenty.
Centralizacja logów można zrealizować na różne sposoby: prosty syslog, ELK/Opensearch, komercyjny SIEM. Ważne jest, aby co najmniej kluczowe systemy wysyłały dzienniki do jednego miejsca:
firewalle i urządzenia brzegowe,
serwery krytycznych aplikacji,
kontrolery domeny (AD) i systemy tożsamości,
systemy VPN / zdalnego dostępu,
istotne serwisy webowe i API.
Synchronizacja czasu (NTP) to często pomijany detal. Kilkuminutowe rozjazdy pomiędzy serwerami, firewallami i stacjami roboczymi potrafią zamienić oś czasu zdarzeń w chaos. W praktyce jeden lub kilka serwerów NTP wewnątrz organizacji, zsynchronizowanych z zaufanym źródłem, załatwia sprawę.
Podstawowy monitoring to nie tylko „czy serwer żyje”. Przydatne są proste metryki: ruch na interfejsach, obciążenie CPU, liczba aktywnych sesji, ilość błędów aplikacji. Bez tego trudno odróżnić zwykły pik ruchu od anomalii potencjalnie związanej z atakiem.
Zakres i retencja logów: co musi być logowane
Nie chodzi o to, żeby logować wszystko, tylko to, co da się później wykorzystać do rekonstrukcji incydentu sieciowego. Minimalny zestaw z punktu widzenia bezpieczeństwa zwykle obejmuje:
logi firewalli – ruch do/z stref zaufanych, odrzucenia, reguły dopuszczające, zmiany konfiguracji;
logi systemów uwierzytelniania – udane i nieudane logowania, zmiany haseł, resetowanie uwierzytelnienia, blokady kont;
logi aplikacyjne – błędy, nietypowe zapytania, próby nieautoryzowanego dostępu, zmiany konfiguracji;
logi z IDS/IPS i EDR – alerty, podjęte akcje (blokowanie, izolowanie hosta), szczegóły detekcji.
Retencja logów powinna odzwierciedlać realne scenariusze. Incydent wykryty dzisiaj mógł mieć początek kilka tygodni temu (powolna eksfiltracja, długotrwała obecność atakującego w sieci). Trzymanie logów przez 7 dni to proszenie się o zaskoczenie. Rozsądnym minimum dla kluczowych logów bywa 3–6 miesięcy, jeśli tylko zasoby na to pozwalają.
Prosty plan reagowania: role, kontakty, eskalacja
W czasie incydentu sieciowego nikt nie ma ochoty ustalać, kto jest odpowiedzialny za firewall, a kto ma klucze do serwerowni. Dlatego potrzebny jest prosty, zrozumiały dla wszystkich plan reagowania – bez dziesiątek stron teorii.
W praktyce wystarczy kilka dokumentów roboczych:
lista kontaktów – imię, nazwisko, rola, telefon służbowy, alternatywny kanał kontaktu (np. komunikator, prywatny numer do użycia w wyjątkowych sytuacjach);
ścieżka eskalacji – kto decyduje o: odłączeniu systemów od sieci, powiadomieniu zarządu, poinformowaniu klientów, kontakcie z zewnętrznym SOC;
definicje poziomów incydentu – zdarzenie, incydent niski/średni/wysoki, kryzys; na każdy poziom przypisane minimalne działania;
checklista „on-call” – co zrobić w pierwszych 30 minutach od otrzymania alertu, zanim dołączy reszta zespołu.
Plan reagowania nie musi być idealny, ale musi być aktualny i znany. Dokument, który leży na dysku jako PDF sprzed 3 lat, gdy połowa zespołu już nie pracuje w organizacji, nie ma żadnej wartości.
Dostępy i narzędzia do analizy incydentu
Osoba analizująca incydent sieciowy potrzebuje realnego dostępu do danych i narzędzi. Brak uprawnień do odczytu logów z firewalli czy brak konta w SIEM w środku nocy to przepis na stracone godziny. Proces obsługi incydentu powinien mieć zabezpieczoną stronę operacyjną.
W praktyce oznacza to, że:
przynajmniej część zespołu ma rozsądny poziom dostępu „tylko do odczytu” do logów krytycznych systemów,
istnieją konta techniczne na wypadek awarii integracji z domeną,
narzędzia do analizy (np. Wireshark, tcpdump, narzędzia forensiczne) są dostępne na kontrolowanych stacjach lub serwerach,
istnieje tryb awaryjny dostępu do urządzeń sieciowych (out-of-band, hasła w sejfie, system haseł jednorazowych dla adminów).
Bez tego cały proces analizy pozostaje teoretyczny, a pierwsze godziny incydentu są marnowane na organizację dostępu zamiast na szukanie przyczyny.
Przykład: incydent niemożliwy do zbadania z powodu braku logów
Realistyczny scenariusz: dział sprzedaży zgłasza, że kilku klientów otrzymało od firmy nietypowe wiadomości z prośbą o przesłanie danych płatniczych. W logach pocztowych widać tylko, że wiadomości rzeczywiście wyszły z serwera. Nie ma logów z systemów uwierzytelniania, bo „zajmowały za dużo miejsca”. Logi webowe z panelu pocztowego rotują się co 24 godziny i akurat zostały nadpisane.
W efekcie:
nie da się ustalić, czy ktoś zalogował się na konto przez panel webowy, czy użył protokołu SMTP/IMAP,
brak informacji, z jakich IP logowano się na skrzynkę,
nie wiadomo, czy doszło do przejęcia hasła, czy podatności aplikacji.
Analiza incydentu kończy się na poziomie hipotez i ogólnych zaleceń, bez twardego wniosku, co poszło źle. Sytuację można było odwrócić, mając minimalną retencję kluczowych logów przez kilkanaście–kilkadziesiąt dni.
Pierwszy sygnał: triage i potwierdzenie incydentu
Odbiór alertu i szybka weryfikacja
Każdy incydent sieciowy zaczyna się od czyjegoś „spojrzenia na coś”. Ktoś w SOC widzi alert w SIEM, administrator monitoruje wykres, użytkownik zgłasza problem z logowaniem. Pierwszym krokiem jest doprecyzowanie, czy to w ogóle dotyczy bezpieczeństwa.
Przy odbiorze alertu warto zadać kilka szybkich pytań:
Czy podobny alert pojawiał się wcześniej i jak był klasyfikowany?
Minimalny zestaw pytań w triage technicznym
Po stwierdzeniu, że sygnał może dotyczyć bezpieczeństwa, dobrze jest przejść przez stały zestaw pytań. Chodzi o szybkie zorientowanie się w skali i potencjalnym wpływie, bez wchodzenia w głęboką analizę.
Zakres – ile systemów/użytkowników/IP jest objętych zdarzeniem? Jeden host, podsieć, cała lokalizacja?
Czas – kiedy pojawił się pierwszy ślad w logach? Czy to pojedynczy pik, czy zjawisko ciągłe?
Wpływ – czy coś przestało działać, czy są symptomy utraty danych, spadku wydajności, anomalii aplikacyjnych?
Wejście/wyjście – czy zdarzenie dotyczy ruchu przychodzącego z Internetu, wychodzącego na zewnątrz, czy tylko wewnątrz sieci?
Powtarzalność – czy podobne zdarzenie widać na innych hostach / w innych lokalizacjach?
Odpowiedzi często pozwalają szybko odsiać oczywiste fałszywe alarmy (np. planowe skanowanie podatności) od sygnałów, które wymagają dalszej pracy.
Decyzja: eskalować czy utrzymać na pierwszej linii
Po wstępnym triage trzeba zdecydować, czy incydent przechodzi do szerszego zespołu, czy pozostaje w obsłudze pojedynczej osoby/dyżurnego. Kryteria dobrze mieć wcześniej spisane, ale praktyka jest dość stała.
Eskalację zwykle uzasadniają:
podejrzenie kompromitacji kont uprzywilejowanych lub systemów krytycznych (AD, systemy finansowe, systemy produkcyjne),
wyraźne symptomy exfiltracji danych (duże transfery na nietypowe adresy, szyfrowane tunele z hostów użytkowników),
rozprzestrzenianie się problemu (kolejne hosty z podobnymi alertami),
brak możliwości szybkiego ustalenia przyczyny przy rosnącej liczbie sygnałów.
Jeżeli nic z powyższego nie zachodzi, a zdarzenie jest dobrze rozpoznane (np. skan znanego bota, pojedyncza próba logowania z egzotycznego kraju), można je obsłużyć w trybie „routine”, z dokumentacją i prostymi działaniami (blokada IP, korekta reguły).
Dokumentowanie od pierwszych minut
Już na etapie triage warto notować podstawowe informacje. Nie chodzi o formalny raport, lecz prosty dziennik działań, który później przyda się przy budowie osi czasu.
Przykładowy minimalny zapis obejmuje:
czas otrzymania alertu i źródło (SIEM, zgłoszenie użytkownika, monitoring aplikacji),
kto prowadzi triage,
krótką roboczą nazwę incydentu,
pierwsze decyzje (eskalować / nie eskalować, odłączyć host / tylko obserwować),
wszystkie zmiany w konfiguracji zrobione w odpowiedzi na incydent (nowe reguły, blokady).
Prosty plik tekstowy, notatka w systemie ticketowym albo w narzędziu typu wiki wystarczy, o ile jest spójnie uzupełniany.
Zabezpieczenie środowiska i dowodów na wczesnym etapie
Równowaga między ciągłością działania a bezpieczeństwem
Po potwierdzeniu incydentu sieciowego naturalnym odruchem jest „odłączamy wszystko”. W praktyce często nie ma na to zgody biznesu. Dlatego decyzje izolacyjne trzeba brać pod kątem wpływu na działanie firmy.
Dobrym kompromisem bywa:
izolacja pojedynczych hostów użytkowników od Internetu przy pozostawieniu dostępu do krytycznych systemów wewnętrznych,
czasowe zablokowanie konkretnych kierunków ruchu (np. podejrzany kraj / ASN), zamiast pełnego odcięcia serwera,
przełączenie usług na serwery zapasowe, aby uwolnić kompromitowany host do analizy offline.
Im lepiej znana jest topologia i zależności biznesowe, tym łatwiej podjąć decyzję o selektywnej izolacji zamiast „wielkiego wyłącznika”.
Szybkie działania ochronne, które nie niszczą śladów
Na początku dochodzenia trzeba unikać kroków, które skasują cenne dane forensyczne. Skanowanie „naprawcze” z antywirusa na żywym systemie często nadpisze artefakty, które później byłyby kluczowe.
Bezpieczniejsze są działania typu:
blokady na poziomie sieci (ACL, reguły firewall, blokada adresów URL/hostów w proxy),
odłączenie interfejsu sieciowego kompromitowanego hosta bez wyłączania zasilania,
zablokowanie kont użytkowników lub wymuszenie zmiany haseł z zachowaniem logów uwierzytelnienia.
Czynności w stylu „przeinstalujmy serwer” powinny pojawiać się dopiero po zabezpieczeniu materiału dowodowego lub świadomej decyzji, że analiza forensyczna nie jest potrzebna.
Zabezpieczanie logów i zrzutów systemowych
Kluczowy etap to „zamrożenie” stanu logów i systemu tak, aby późniejsze rotacje lub sprzątanie nie zniszczyły danych. Trzeba działać szybko, ale metodycznie.
Przydatne praktyki:
natychmiastowe zwiększenie retencji w SIEM / systemie logów dla objętych zdarzeniem źródeł,
eksport logów z urządzeń brzegowych i krytycznych serwerów do odseparowanej przestrzeni (np. zaszyfrowany udział tylko do odczytu),
jeśli to uzasadnione – wykonanie zrzutu pamięci RAM hosta oraz obrazu dysku (bit-by-bit), z zachowaniem łańcucha dowodowego.
W mniejszych środowiskach zamiast pełnych obrazów dysków można ograniczyć się do archiwizacji katalogów logów systemowych i aplikacyjnych, ale trzeba to robić spójnie (zapis daty, narzędzia, osoby wykonującej kopię).
Łańcuch dowodowy i prosta ewidencja
Jeśli incydent może mieć skutki prawne (naruszenie danych osobowych, potencjalne postępowanie karne), ważne jest, aby materiał dowodowy był wiarygodny. To nie wymaga skomplikowanych systemów, lecz podstawowej dyscypliny.
Minimalnie dobrze jest zapisywać:
co zostało zabezpieczone (rodzaj danych, ścieżka, system),
kto i kiedy wykonał kopię/zrzut,
gdzie dane są przechowywane i kto ma do nich dostęp,
czy na danych były wykonywane jakiekolwiek modyfikacje (np. anonimizacja raportów dla biznesu).
Prosta tabela w arkuszu lub system ticketowy z kilkoma polami może spełniać rolę ewidencji dowodów.
Źródło: Pexels | Autor: Tima Miroshnichenko
Mapa zdarzenia: budowanie osi czasu z logów
Ustalenie punktu startowego i końcowego
Oś czasu nie może być „od zawsze”. Trzeba zdefiniować okno, w którym zdarzenie na pewno miało miejsce. Zwykle punktem odniesienia jest pierwszy zauważony objaw (alert, skarga użytkownika) i czas ostatniego potwierdzonego objawu.
Dobrą techniką jest cofanie się od pierwszego znanego zdarzenia krok po kroku:
znaleźć wcześniejsze logi powiązane z tym samym IP, użytkownikiem, hostem,
ustalić, kiedy po raz pierwszy dane IP/użytkownik pojawili się w systemie,
sprawdzić, czy były dłuższe okresy ciszy, przerwane nagłym wzrostem aktywności.
Okno czasowe można potem zawężać lub rozszerzać w miarę pojawiania się nowych śladów.
Normalizacja czasu i źródeł logów
Żeby korelować logi z wielu systemów, trzeba mieć pewność co do czasu. Nawet przy NTP zdarzają się odchyłki, inne strefy czasowe lub logi bez informacji o strefie.
Przydatne kroki:
sprawdzenie stref czasowych na kluczowych systemach (UTC vs lokalna),
odnotowanie stałych przesunięć (np. firewall –2 minuty względem SIEM) i uwzględnianie ich przy analizie,
konwersja czasów do jednego formatu (np. UTC) w roboczych notatkach i raportach.
Jeśli SIEM robi to automatycznie, problem jest mniejszy, ale na poziomie pracy analitycznej dobrze mieć jedno „źródło prawdy” czasu.
Grupowanie zdarzeń według obiektów
Oś czasu zwykle buduje się wokół jednego z trzech punktów: użytkownika, hosta lub usługi. Pozwala to lepiej zobaczyć sekwencję działań.
Prosty sposób pracy:
najpierw zebrać wszystkie zdarzenia dla kompromitowanego hosta (logi systemowe, ruch na firewallu, zdarzenia EDR),
potem dodać działania użytkownika przypisanego do tego hosta (logowania, zmiany haseł, dostęp do aplikacji),
na końcu dorzucić logi usług, z których korzystał (VPN, serwery aplikacyjne, bazy danych).
W efekcie powstaje ciąg kroków, który można czytać jak historię: wejście, ruch w bok, wykonanie celu (np. kradzież danych) i próby ukrycia śladów.
Narzędzia do wizualizacji osi czasu
Nie trzeba od razu specjalistycznych platform. W wielu przypadkach wystarczy SIEM i arkusz kalkulacyjny. Chodzi o przedstawienie zdarzeń w kolejności, z krótkim opisem.
Praktyczne podejście to:
eksport wyników zapytań z SIEM do CSV,
oczyszczenie kolumn do minimum (czas, źródło, host/użytkownik, opis),
ręczne dodanie kluczowych działań administracyjnych (np. zmiana reguły firewall, reset hasła) jako osobnych wierszy,
oznaczenie kolorami typów czynności (wejście, eskalacja, ruch boczny, exfiltracja, reakcja obronna).
Przy bardziej złożonych zdarzeniach można użyć dedykowanych narzędzi timeline (np. forensycznych), ale logika pozostaje identyczna.
Dogłębna analiza ruchu sieciowego i artefaktów
Kiedy sięgać po pełne zrzuty ruchu
Przechowywanie pełnych zrzutów ruchu (PCAP) dla całej sieci jest drogie. Zwykle dostępne są tylko w wybranych segmentach lub krótkich oknach czasowych. Dlatego ich użycie trzeba planować.
Warto po nie sięgnąć, gdy:
chodzi o analizę nieznanego malware lub nietypowego protokołu,
IDS generuje ogólne alerty, ale bez szczegółów treści (np. tylko informacja o podejrzanej sygnaturze),
trzeba ocenić faktyczną zawartość transferu (czy poszły dane wrażliwe, czy tylko „szum”).
Jeżeli zrzutów nie ma, alternatywą jest analiza metadanych (NetFlow/IPFIX, logi proxy, logi aplikacji) – mniej dokładna, ale nadal użyteczna.
Analiza metadanych ruchu: kto, dokąd, jak długo
NetFlow i podobne dane dają obraz ruchu bez treści pakietów. W większości incydentów to wystarcza do zrozumienia schematu ataku.
Przydatne pytania przy pracy z metadanymi:
czy widać nietypowo długie lub częste sesje z jednego hosta do rzadko używanych portów?
czy ruch wychodzący z hosta użytkownika przypomina typowy ruch (HTTP/HTTPS, DNS), czy nagle pojawiają się egzotyczne porty i protokoły?
czy ilość danych wysyłanych na zewnątrz gwałtownie rośnie w określonych godzinach (np. nocą, weekend)?
Nawet prosty wykres wolumenu ruchu i liczby sesji per IP często pokazuje, które hosty grają główną rolę w incydencie.
Rozpoznawanie narzędzi i technik w ruchu sieciowym
W logach i zrzutach ruchu da się często rozpoznać konkretne narzędzia atakujących: skanery, frameworki C2, tunelowanie przez znane aplikacje.
W praktyce analitycy szukają:
charakterystycznych wzorców zapytań (np. specyficzne nagłówki HTTP, ścieżki URL używane przez popularne narzędzia C2),
regularnych, krótkich połączeń keep-alive do tego samego hosta (beacony),
nietypowych kombinacji port/protokół (HTTP na porcie 8081 z dziwnymi hostami, DNS używany do przesyłania dużych ilości danych w polach TXT).
Tu przydają się zarówno sygnatury z IDS, jak i wiedza własna zespołu, budowana na wcześniejszych incydentach i ręcznej analizie.
Artefakty na hostach a obraz w sieci
Ruch sieciowy i logi systemowe wzajemnie się uzupełniają. Pełniejszy obraz incydentu powstaje dopiero, gdy połączy się te dwa światy.
Typowy schemat pracy wygląda tak:
identyfikacja podejrzanego hosta po logach z firewalli/IDS,
sprawdzenie na hoście procesów generujących ruch (EDR, narzędzia systemowe),
mapowanie proces → plik na dysku → wpisy w logach systemowych (instalacja, uruchomienie, błędy),
powrót do logów sieciowych, aby sprawdzić, z kim ten proces się łączył.
Korelacja i hipotezy: czego faktycznie szukamy
Od surowych logów do pytań badawczych
Po pierwszym przeglądzie logów i ruchu sieciowego przychodzi moment, kiedy same dane nie wystarczają. Trzeba sformułować kilka konkretnych pytań, na które analiza ma odpowiedzieć.
Typowe pytania startowe:
jak atakujący wszedł do środka (pierwszy punkt wejścia),
jakie uprawnienia uzyskał i jak je zwiększał,
czy był ruch boczny na inne hosty,
czy doszło do kradzieży lub modyfikacji danych,
czy atak nadal trwa lub może zostać łatwo powtórzony.
Bez takich pytań łatwo utknąć w bezproduktywnym grzebaniu w logach.
Budowanie hipotez roboczych
Hipoteza to proste zdanie opisujące możliwy przebieg zdarzeń, które da się zweryfikować w danych. Nie musi być od razu trafna.
Przykłady hipotez:
„Atakujący dostał się przez konto VPN pracownika X, używając skradzionych haseł” – do sprawdzenia w logach VPN i uwierzytelnienia,
„Ruch boczny odbywał się z hosta A na serwery baz danych wyłącznie po RDP” – do sprawdzenia w NetFlow i logach systemowych,
„Eksfiltracja danych odbyła się przez tunel w HTTPS do domeny Y” – do sprawdzenia w proxy/NGFW.
Każda hipoteza powinna mieć wskazane źródła danych i kryteria potwierdzenia lub odrzucenia.
Korelacja między różnymi klasami logów
Kiedy hipotezy są wypisane, zaczyna się korelowanie zdarzeń z różnych systemów. Chodzi o złożenie kilku części układanki w jedno spójne zdarzenie.
Typowe pary korelacyjne:
logi uwierzytelnienia ↔ logi VPN / aplikacji (kto się logował i do czego),
logi EDR ↔ NetFlow (jaki proces generował podejrzany ruch),
Działania z pierwszej grupy zwykle wykonuje się jeszcze w trakcie analizy, żeby nie dopuścić do kolejnych incydentów tego samego typu.
Dokumentowanie wniosków na bieżąco
Analiza incydentu trwa często kilka dni lub tygodni. Bez prostych notatek wnioski z pierwszych dni łatwo się rozmywają.
Praktyczny, lekki model dokumentowania to:
krótka sekcja „co już wiemy” aktualizowana co dzień lub po ważnym odkryciu,
lista hipotez z oznaczeniem: potwierdzona / odrzucona / w toku,
prosta tabela „akcja → powód → oczekiwany efekt” dla działań naprawczych.
Taka dokumentacja jest przydatna zarówno do wewnętrznej komunikacji w zespole, jak i do późniejszego formalnego raportu technicznego.
Co warto zapamiętać
Analiza incydentu sieciowego ma dwa główne cele: szybkie zrozumienie skali i wpływu zdarzenia oraz uporządkowanie działań tak, aby w stresie nie tracić czasu na chaotyczne przeglądanie logów.
Kluczowe jest praktyczne rozróżnienie pomiędzy zwykłym zdarzeniem, incydentem sieciowym a fałszywym alarmem – inaczej albo wszystko będzie traktowane jak krytyczny atak, albo realne zagrożenia zostaną zignorowane.
Analiza incydentu zaczyna się w momencie przejścia z „zwykłego zdarzenia” do „podejrzenia incydentu”; pierwszy log jest zwykle tylko widoczną końcówką dłuższego łańcucha, który trzeba odtworzyć z logów i artefaktów.
Pierwszy sygnał o incydencie może przyjść z wielu źródeł (IDS/IPS, EDR, monitoring dostępności, zgłoszenie użytkownika, logi urządzeń sieciowych), dlatego musi istnieć jasna ścieżka: kto odbiera alert, kto robi triage i gdzie trafiają informacje.
Granica między awarią a atakiem jest płynna, więc przy braku pewności lepiej założyć incydent bezpieczeństwa i uruchomić minimalny proces obsługi niż przeoczyć realny atak.
Szybkie nadanie roboczej etykiety incydentowi (np. „podejrzenie skanowania portów”, „możliwe malware na stacji X”) porządkuje komunikację, ułatwia priorytetyzację zdarzeń i pozwala dobrać właściwe narzędzia do analizy.
Skuteczna analiza jest możliwa tylko wtedy, gdy wcześniej przygotowano fundamenty: centralizację logów, spójny czas w systemach oraz podstawowy monitoring ruchu i dostępności.
Bibliografia
NIST Special Publication 800-61 Revision 2: Computer Security Incident Handling Guide. National Institute of Standards and Technology (2012) – Proces obsługi incydentów, etapy, role i dobre praktyki
NIST Special Publication 800-92: Guide to Computer Security Log Management. National Institute of Standards and Technology (2006) – Zarządzanie logami, centralizacja, korelacja i wykorzystanie w analizie
ISO/IEC 27035-1: Information security incident management – Part 1: Principles of incident management. International Organization for Standardization (2023) – Norma dot. definicji incydentu, cyklu życia i organizacji procesu
ENISA Threat Landscape. European Union Agency for Cybersecurity – Przegląd typowych ataków sieciowych, trendów i scenariuszy incydentów
SANS Incident Handler's Handbook. SANS Institute – Praktyczny przewodnik po triage, analizie logów i obsłudze incydentów
MITRE ATT&CK Framework. MITRE Corporation – Klasyfikacja technik ataków, pomoc w etykietowaniu i korelacji zdarzeń
RFC 3164: The BSD Syslog Protocol. Internet Engineering Task Force (2001) – Podstawy protokołu syslog używanego do centralizacji logów
