post-incident review

Post-incident review to podsumowanie przeprowadzane po zamknięciu incydentu. Jego celem jest ustalenie, co się stało, dlaczego obrona zawiodła i co trzeba zmienić, a nie wskazanie winnych. NIST opisuje ten etap jako spotkanie „lessons learned”, które pozwala zamknąć incydent przez przegląd tego, co się wydarzyło, jak interweniowano i jak skuteczna była interwencja ^[1]. W tym samym dokumencie NIST nazywa uczenie się i doskonalenie jedną z najważniejszych, a zarazem najczęściej pomijanych części reagowania na incydenty ^[1].

Jak działa

W klasycznym cyklu reagowania post-incident review zamyka pętlę: wnioski wracają do przygotowania i zmieniają procedury przed następnym zdarzeniem. Schemat poniżej pokazuje to miejsce w cyklu.

RYS. 1Miejsce przeglądu w cyklu reagowania

NIST SP 800-61 Rev. 2 zaleca, by spotkanie odbyło się w ciągu kilku dni od zakończenia incydentu ^[1]. Po poważnym incydencie powinni w nim uczestniczyć wszyscy zaangażowani; po mniejszych przegląd można robić okresowo, a jedno spotkanie może objąć kilka incydentów ^[1]. Dokument podaje pytania, na które spotkanie ma odpowiedzieć ^[1]:

• co dokładnie się stało i o której godzinie;
• czy zespół i kierownictwo działali sprawnie, czy procedury były przestrzegane i czy wystarczały;
• jakich informacji zabrakło wcześniej i które działania mogły utrudnić przywrócenie;
• co zrobić inaczej następnym razem i jakie działania naprawcze zapobiegną podobnym incydentom;
• jakie sygnały i wskaźniki kompromitacji (IoC) obserwować, by wykryć podobne zdarzenie.

Wynikiem jest raport z incydentu. NIST podkreśla wagę formalnej chronologii zdarzeń ze znacznikami czasu, na przykład z logów, oraz szacunku strat ^[1]. Ustalenia i zadania trzeba zapisać i przekazać osobom, które nie brały udziału w spotkaniu ^[1].

Zasada bez winnych

Google w podręczniku Site Reliability Engineering definiuje postmortem jako pisemny zapis incydentu, jego skutków, działań podjętych w celu ograniczenia lub usunięcia problemu, przyczyn źródłowych i działań zapobiegających powtórce ^[3]. Przegląd ma skupiać się na przyczynach, które przyczyniły się do incydentu, bez obwiniania osób ani zespołów ^[3]. Założenie brzmi: każdy uczestnik miał dobre intencje i działał właściwie w świetle informacji, które miał ^[3]. Gdy ludzie boją się kary, przestają zgłaszać problemy, a przegląd traci materiał.

Google wymienia typowe powody zwołania przeglądu, między innymi utratę danych, konieczność interwencji dyżurnego, przekroczenie ustalonego czasu rozwiązania i sytuację, w której monitoring nie wykrył problemu ^[3]. Ostatni przypadek jest w bezpieczeństwie szczególnie ważny, bo pokazuje lukę w wykrywaniu, a nie tylko w reakcji.

Przegląd a ćwiczenie

Podobny mechanizm stosuje się po ćwiczeniach. NIST SP 800-84 opisuje debriefing prowadzony zaraz po ćwiczeniu typu tabletop, nazywany „hotwash”: uczestnicy mówią, co wyszło dobrze, gdzie potrzebne jest szkolenie i które części planu trzeba zmienić ^[4]. Wnioski trafiają do raportu po ćwiczeniu (after action report), a koordynator planu przydziela zadania aktualizacji ^[4]. Różnica polega na źródle danych: ćwiczenie sprawdza plan na scenariuszu, post-incident review na prawdziwym zdarzeniu.

W WordPressie

Dokumentacja WordPress.org zaleca, by po włamaniu najpierw udokumentować objawy, godzinę ich zauważenia ze strefą czasową i ostatnie zmiany na stronie, na przykład nową wtyczkę albo zmianę w motywie ^[5]. Taki zapis nazywa podstawą raportu z incydentu ^[5]. Ta sama strona opisuje etap analizy powłamaniowej jako ustalenie, jak napastnik dostał się do środka, aby nie mógł ponownie użyć tej drogi ^[5]. Odpowiada to dziedzinie, jaką jest informatyka śledcza.

CERT Polska zaleca, by przed czyszczeniem zabezpieczyć logi serwera HTTP i logi systemowe, zanim nadpisze je rotacja ^[6]. W logach warto szukać wektora ataku i czasu infekcji, zmienionych plików, webshelli oraz śladów w systemie, na przykład nowych kont i zadań cron ^[6]. Jeżeli wektor i czas są jasne, stronę można odtworzyć z czystej kopii zapasowej (backup) sprzed incydentu; jeżeli nie, CERT Polska zaleca odbudowę od zera ^[6].

Na stronie WordPress przegląd zwykle kończy się listą konkretnych zmian:

• aktualizacja lub usunięcie wtyczki, przez którą weszło włamanie, zob. podatność we wtyczce;
• zmiana wszystkich haseł i kluczy w wp-config.php, co wylogowuje aktywne sesje ^[5];
• włączenie uwierzytelniania dwuskładnikowego i zapory aplikacyjnej ^[6];
• kopie przechowywane poza serwerem, którego dotyczył incydent ^[6].

Samo czyszczenie przejętej strony nie jest przeglądem. Czyszczenie usuwa skutki, przegląd ustala, dlaczego do nich doszło.

Dobre praktyki

• Termin w kalendarzu od razu po zamknięciu incydentu; NIST wskazuje kilka dni ^[1].
• Moderator z umiejętnością prowadzenia dyskusji i agenda zebrana od uczestników przed spotkaniem ^[1].
• Oś czasu oparta na logach, a nie na pamięci; wymaga to przemyślanej retencji logów.
• Każde zadanie naprawcze z właścicielem i terminem; Google przegląda zadania pod kątem kompletności i priorytetu ^[3].
• Zbieranie danych do porównań w czasie, takich jak MTTD i MTTR ^[1].
• Aktualizacja procedur po każdym przeglądzie; NIST zauważa, że analiza często ujawnia brakujący krok w procedurze ^[1].

Historia i przykłady

Etap działań po incydencie był częścią cyklu w NIST SP 800-61 Rev. 2 z 2012 roku ^[2]. W kwietniu 2025 roku NIST zastąpił ten dokument wersją Rev. 3, która wpisuje reagowanie na incydenty w zarządzanie ryzykiem według CSF 2.0 ^[2]. Nowa wersja stawia sobie za cel między innymi poprawę skuteczności wykrywania, reagowania i odtwarzania ^[2], a więc ciągłe doskonalenie, któremu służy przegląd.