reagowanie na incydenty

Reagowanie na incydenty (incident response) to zorganizowany proces obsługi incydentu bezpieczeństwa: od wykrycia i analizy, przez opanowanie i usunięcie zagrożenia, po przywrócenie działania i wyciągnięcie wniosków. NIST definiuje incydent bezpieczeństwa komputerowego jako naruszenie albo bezpośrednią groźbę naruszenia polityk bezpieczeństwa, zasad dopuszczalnego użytkowania lub standardowych praktyk bezpieczeństwa ^[1]. Polska ustawa o krajowym systemie cyberbezpieczeństwa używa terminu „obsługa incydentu” i określa go jako czynności umożliwiające wykrywanie, rejestrowanie, analizowanie, klasyfikowanie, priorytetyzację, podejmowanie działań naprawczych i ograniczenie skutków incydentu ^[3].

Etapy

Szeroko stosowany model opisał NIST w publikacji SP 800-61, w wersji wydanej w sierpniu 2012 roku ^[2]. Wyróżnia ona przygotowanie, wykrywanie i analizę, opanowanie, usunięcie zagrożenia i przywrócenie działania oraz działania po incydencie ^[1]. Etapy tworzą cykl, bo w trakcie opanowania praca często wraca do wykrywania i analizy, na przykład by sprawdzić, czy złośliwe oprogramowanie nie zainfekowało kolejnych hostów ^[1].

RYS. 1Cykl reagowania na incydent według NIST SP 800-61

W kwietniu 2025 roku NIST zastąpił ten dokument wersją SP 800-61 Rev. 3, która osadza reagowanie na incydenty w funkcjach NIST Cybersecurity Framework 2.0 i traktuje je jako część zarządzania ryzykiem, a nie odrębną czynność ^[2]. Opisane wyżej etapy pozostają użytecznym językiem opisu pracy zespołu.

Opanowanie i dowody

NIST podkreśla, że opanowanie jest ważne, zanim incydent przeciąży zasoby lub zwiększy szkody ^[1]. Kluczowe są decyzje: wyłączyć system, odłączyć go od sieci, zablokować funkcję ^[1]. Takie decyzje są znacznie łatwiejsze, gdy strategie opanowania ustalono wcześniej ^[1]. Pomaga w tym segmentacja sieci, która pozwala odciąć jedną strefę bez zatrzymywania całej organizacji.

Równolegle zbiera się dowody. Służą przede wszystkim rozwiązaniu incydentu, ale mogą być potrzebne w postępowaniu prawnym ^[1]. NIST zaleca dokumentowanie, jak zabezpieczono każdy dowód, w tym przejęte systemy, oraz formularze chain of custody przy każdym przekazaniu dowodu między osobami ^[1]. Tą stroną zajmuje się informatyka śledcza. Pośpieszne „sprzątanie” przed zabezpieczeniem danych utrudnia potem ustalenie, jak doszło do włamania.

W WordPressie

Dokumentacja WordPress.org opisuje reakcję na włamanie w krokach, które odpowiadają etapom NIST ^[5].

1. Dokumentacja. Pierwszym działaniem ma być zapis: co wskazuje na włamanie, kiedy to zauważono, jakie zmiany wprowadzano ostatnio, np. nowe wtyczki lub zmiany motywu ^[5]. Dokumentacja nazywa to podstawą raportu z incydentu ^[5].
2. Wskaźniki. Jako oznaki włamania wymienia m.in. wpis na czarną listę wyszukiwarki, wyłączenie strony przez hosting, ostrzeżenia antywirusów odwiedzających i nieautoryzowane działania, np. zakładanie nowych użytkowników ^[5].
3. Skanowanie. Strona ma być sprawdzona skanerami złośliwego oprogramowania (malware scanner) działającymi jako wtyczki i zdalnie, a komputer administratora pełnym skanem antywirusowym, bo infekcja często zaczyna się lokalnie od trojana przechwytującego dostęp do FTP i /wp-admin ^[5].
4. Opanowanie. Wymuszenie zmiany haseł wszystkich użytkowników i wylogowanie aktywnych sesji przez zmianę kluczy bezpieczeństwa i soli w wp-config.php ^[5]. Zmiana obejmuje też FTP lub SFTP, panel hostingu i MySQL ^[5].
5. Kopia przed czyszczeniem. Nawet zainfekowane środowisko warto zapisać przed czyszczeniem, by mieć punkt odniesienia ^[5].
6. Usunięcie i aktualizacja. Podmiana katalogów /wp-admin i /wp-includes, przegląd wp-content i pliku .htaccess, a po oczyszczeniu aktualizacja i ponowna zmiana haseł ^[5].
7. Analiza. Ustalenie wektora ataku, by nie mógł zostać użyty ponownie ^[5].

Na hostingu współdzielonym dokumentacja zaleca kontakt z dostawcą, bo włamanie mogło objąć więcej niż jedną stronę ^[5].

Zespoły i obowiązki

Reagowaniem zajmują się zespoły CSIRT. CERT Polska, działający w NASK od 1996 roku, był pierwszym takim zespołem w Polsce i obecnie pełni rolę CSIRT NASK w krajowym systemie cyberbezpieczeństwa ^[4]. W organizacjach pracę operacyjną wykonuje zwykle SOC (Security Operations Center), wspierany przez SIEM (Security Information and Event Management) i EDR (Endpoint Detection and Response).

Ustawa o KSC odróżnia obsługę incydentu od zarządzania incydentem. To drugie obejmuje obsługę, wyszukiwanie powiązań między incydentami, usuwanie przyczyn ich wystąpienia i opracowywanie wniosków ^[3]. Podmioty objęte ustawą mają też obowiązek zgłaszania incydentów w określonych terminach.

Wnioski i typowe błędy

NIST nazywa naukę po incydencie jedną z najważniejszych, a zarazem najczęściej pomijanych części reagowania ^[1]. Zaleca spotkanie wszystkich zaangażowanych w ciągu kilku dni od zakończenia incydentu, z pytaniami m.in. o to, co dokładnie się stało i kiedy ^[1]. Dziś nazywa się to także post-incident review.

Częstym błędem jest brak reakcji na sygnały, które już są. W opublikowanym w sierpniu 2026 roku raporcie CISA opisała ćwiczenie zespołu red team: SOC jednej z organizacji otrzymał alerty EDR (Endpoint Detection and Response) o średnim i niskim priorytecie związane z działaniami atakujących, ale na nie nie zareagował ^[6]. Tysiące fałszywych alarmów z normalnej pracy firmy, wiele o wyższym priorytecie, zasłoniły właściwe sygnały ^[6]. W drugiej organizacji podobne alerty zostały obsłużone, a stacje robocze odizolowano w ciągu 2 do 20 minut ^[6]. CISA zaleca ograniczenie szumu alertów, tak by odróżniać zwykłe czynności administracyjne od możliwych działań napastnika ^[6]. Zjawisko opisuje hasło zmęczenie alertami.