Krótko: Lessons learned po incydencie IT oznacza: po technicznym zakończeniu wszyscy zaangażowani zasiadają razem, odtwarzają przebieg, bez szukania winnych nazywają to, co poszło dobrze i co nie, i wyprowadzają z tego działania z osobami odpowiedzialnymi i terminami. Dotyczy to także prawie-incydentów, takich jak łagodnie przebiegły tydzień PHP2Shell. Decydujący jest nie protokół, lecz późniejsza kontrola, czy działania zostały wdrożone.
Dlaczego tydzień po incydencie jest tak ważny
Gdy serwer znów działa, a poprawki są zainstalowane, pokusa szybkiego powrotu do codzienności jest duża. Właśnie wtedy ginie najcenniejsza wiedza: kto co i kiedy zauważył? Gdzie brakowało informacji? Która decyzja trwała zbyt długo? Za kilka tygodni nikt już tego dokładnie nie będzie wiedział.
Tydzień października 2026 jest tu dobrym przykładem. Wiele firm załatało serwery PHP, napisało do firm hostingowych, prewencyjnie wyłączyło strony lub zabezpieczyło logi. Nawet jeśli nie stwierdzono włamania, jest w tym dużo materiału do nauki. Jak długo trwało, zanim ustalono, które systemy są dotknięte? Kto musiał zatwierdzić wyłączenie i czy ta osoba była osiągalna?
Techniczne kroki po samym ataku omawia lista kontrolna po włamaniu. Ten wpis zaczyna się później: czego się z tego uczymy?
Lessons learned po incydencie IT: podstawowe zasady omówienia
Omówienie nie jest trybunałem. Kto obawia się, że błędy mają osobiste konsekwencje, opowiada tylko połowę historii. Dlatego obowiązuje zasada: szukamy przyczyn w procesach, narzędziach i informacjach, a nie winnych. Ludzie działali z wiedzą, którą mieli w danej chwili.
Proszę zaprosić wszystkich zaangażowanych, także osoby zewnętrzne, takie jak firma hostingowa, agencja czy usługodawca, o ile to możliwe. Proszę zaplanować dwie godziny. Proszę wcześniej poprosić o materiały: zgłoszenia, historie czatów, e-maile, notatki, wyciągi z logów. Z nich powstaje oś czasu, kręgosłup spotkania. Jak ją rzetelnie zbudować, opisuje artykuł Jak sporządzić oś czasu incydentu.
Moderacji nie powinna przejmować osoba, która prowadziła incydent operacyjnie. Oceniałaby wtedy własne decyzje. Neutralna jest na przykład osoba z innego działu lub zewnętrzny partner.
Przebieg w sześciu krokach
- Przedstawić oś czasu: Co wydarzyło się kiedy, od pierwszego zgłoszenia do zakończenia? Luki w osi czasu oznaczyć, nie zgadywać.
- Co poszło dobrze? Proszę zacząć świadomie od pozytywów. To pokazuje, co ma zostać zachowane, i rozluźnia grupę.
- Gdzie zawodziło? Każde opóźnienie, każda brakująca informacja, każda niepewność jest zbierana, najpierw bez dyskusji o rozwiązaniach.
- Wyjaśnić przyczyny: W najważniejszych punktach proszę pytać wielokrotnie o „dlaczego”. „Poprawka przyszła późno” to ustalenie, „nikt nie wiedział, że na starym serwerze nadal działa PHP” to przyczyna.
- Ustalić działania: Do każdej przyczyny konkretne działanie, osoba odpowiedzialna i termin.
- Uzgodnić kontrolę końcową: Termin za cztery do ośmiu tygodni, w którym sprawdza się, co zostało wdrożone.
Typowe pytania i działania po sytuacji związanej z PHP
Poniższa tabela pokazuje pytania, które po sytuacji takiej jak PHP2Shell pojawiają się często, oraz możliwe odpowiedzi w formie działań. Nie każde pasuje do każdej firmy; ma wyostrzyć spojrzenie.
| Pytanie na omówieniu | Typowe ustalenie | Możliwe działanie |
|---|---|---|
| Jak dowiedzieliśmy się o luce? | Przypadkiem z wiadomości | Celowo zasubskrybować komunikaty bezpieczeństwa php.net i BSI |
| Czy wiedzieliśmy, które systemy są dotknięte? | Lista niekompletna, zapomniany stary system | Inwentarz wszystkich stron i serwerów z wersją PHP |
| Kto mógł zdecydować o wyłączeniu? | Niejasne, decyzja opóźniona | Zapisać uprawnienie do decyzji w planie awaryjnym |
| Czy firma hostingowa potwierdziła poprawkę? | Tylko ustnie lub wcale | Zażądać pisemnego potwierdzenia, uzupełnić umowę |
| Czy zrestartowano wszystkie procesy PHP? | Nie sprawdzono | Włączyć restart i kontrolę jako stały krok |
| Czy logi od 20.10. były dostępne? | Częściowo już nadpisane | Wydłużyć czas przechowywania, zabezpieczać logi centralnie |
| Jak przebiegała komunikacja wewnętrzna i zewnętrzna? | Pracownicy dowiedzieli się z prasy | Przygotować wewnętrzną informację wstępną |
Proszę też zapisać to, czego świadomie nie zmieniamy. Czasem ustalenie jest znane, ale działanie byłoby niewspółmierne. Udokumentowana decyzja jest lepsza niż ciche zapomnienie.
Proszę rozdzielać w protokole potwierdzone fakty, prawdopodobne założenia i otwarte pytania. Zwłaszcza po PHP2Shell, dla którego nie ma opublikowanych, potwierdzonych wskaźników kompromitacji (indicators of compromise), to rozdzielenie jest ważne.
Od protokołu do zmiany
Najczęstsza porażka lessons learned jest banalna: protokół zostaje rozesłany, a potem nic się nie dzieje. Pomagają trzy nawyki. Po pierwsze, każde działanie należy do systemu, w którym i tak się pracuje, czyli systemu zgłoszeń lub listy zadań, a nie do osobnego dokumentu. Po drugie, kontrola końcowa dostaje stały termin w kalendarzu zarządu. Po trzecie, wyniki wpływają do planu awaryjnego, listy kontaktów i ćwiczeń.
Kto chce sprawdzić wnioski bez czekania na następny prawdziwy incydent, może je przećwiczyć w ćwiczeniu awaryjnym przy stole. A tam, gdzie omówienie pokazuje, że aktualizacje zbyt zależały od przypadku, warto przebudować to na zarządzanie poprawkami jako proces.
Dla ochrony danych, ubezpieczenia i ewentualnie organów raport końcowy jest ponadto ważnym dokumentem. Ocena prawna, na przykład czy zgłoszenie według art. 33 RODO było konieczne, należy jednak do inspektora ochrony danych lub adwokata, a nie do technicznego omówienia.
Jak konkretnie pomaga PHP SOS?
- Sporządzamy z logów, zgłoszeń i notatek oś czasu incydentu i oznaczamy luki.
- Moderujemy omówienie jako neutralna strona i dbamy o to, aby szukać przyczyn, a nie winnych.
- Tłumaczymy ustalenia techniczne na działania z oszacowaniem nakładu i priorytetem.
- Towarzyszymy kontroli końcowej i na życzenie sami wdrażamy działania techniczne, tak jak przewiduje to nasze reagowanie na incydenty.
Podsumowanie
Incydent jest wystarczająco drogi. Kto go nie analizuje, płaci przy następnym razie jeszcze raz. Uczciwe omówienie bez szukania winnych, rzetelna oś czasu i działania z nazwiskiem i terminem zamieniają trudny tydzień w trwały zysk w bezpieczeństwie.
Częste pytania
Kiedy powinno odbyć się spotkanie lessons learned?
Gdy incydent jest technicznie zakończony, ale pamięć jest jeszcze świeża. W praktyce sprawdza się termin około jednego do dwóch tygodni po zakończeniu. Wcześniej często brakuje dystansu, później szczegóły się zacierają.
Czy omówienie trzeba robić także po prawie-incydencie?
Warto. Sytuacja taka jak PHP2Shell, w której na końcu nic się nie stało, mimo to pokazuje, gdzie procesy zawodziły. Te wnioski są szczególnie cenne, ponieważ powstały bez szkody.
Kto prowadzi omówienie?
Najlepiej ktoś, kto nie prowadził incydentu operacyjnie. Dzięki temu moderacja pozostaje neutralna i nikt nie musi bronić własnych decyzji. Może to być także zewnętrzny usługodawca.
Co dzieje się z wynikami?
Każdy wniosek staje się działaniem z osobą odpowiedzialną i terminem. Plan awaryjny, lista kontaktów i dokumentacja są dostosowywane. Po kilku tygodniach ktoś sprawdza, co faktycznie zostało wdrożone.