Tabletop exercise — jak przećwiczyć reakcję na incydent
Tabletop exercise ujawnia luki w planie reagowania bez wyłączania produkcji. Scenariusz, uczestnicy, injecty, decyzje, dowody i plan naprawczy.
- AUTOR
- Karol Rapacz / Pentester (OSCP, PNPT)
- PUBLIKACJA
- 8 lipca 2026
- CZAS CZYTANIA
- 10 min czytania
- TEMAT
- Reagowanie
Tabletop exercise reagowania na incydent to moderowane ćwiczenie decyzyjne. Zespół otrzymuje realistyczny scenariusz i kolejne porcje informacji, a następnie opisuje, co zrobiłby w prawdziwym zdarzeniu. Nie wyłączamy produkcji i nie uruchamiamy malware; testujemy role, komunikację, dowody oraz decyzje pod presją.
NIST SP 800-84 opisuje projektowanie, prowadzenie i ocenę ćwiczeń dla planów IT. Największa wartość powstaje wtedy, gdy sesja kończy się konkretnymi zmianami, a nie pamiątkowym raportem.
Ustal jeden mierzalny cel
Ćwiczenie „sprawdźmy cyberbezpieczeństwo” jest zbyt szerokie. Wybierz np.:
- decyzję o izolacji krytycznej usługi;
- odtworzenie z backupu po ransomware;
- obsługę wycieku danych i terminów zgłoszeń;
- kompromitację dostawcy SaaS;
- przejęcie konta administratora chmury;
- komunikację zarządu i klientów podczas przerwy.
Cel określa uczestników i injecty. Scenariusz dla SOC różni się od ćwiczenia dla zarządu, prawników i PR.
Przygotuj realistyczną chronologię
Moderator przekazuje injecty: alert EDR, telefon klienta, żądanie okupu, log z chmury, publikację w mediach albo informację o braku backupu. Każdy powinien wymagać decyzji.
Nie twórz zagadki, w której uczestnicy muszą odgadnąć tajny exploit. Testujemy proces przy niepełnych danych: kto ma authority, jakie dowody zbiera, kiedy eskaluje i kto może zatrzymać usługę.
Kogo zaprosić
W zależności od celu potrzebni są:
- właściciel incident response i SOC;
- infrastruktura, chmura, aplikacje oraz identity;
- biznesowy właściciel usługi;
- prawo, compliance, DPO i komunikacja;
- zarząd lub osoba uprawniona do decyzji finansowych;
- dostawca MSP, chmury lub cyberubezpieczyciel.
Obserwator zapisuje decyzje i dowody, ale nie podpowiada rozwiązań.
Przebieg ćwiczenia
- Przedstaw zasady, cel i stan początkowy.
- Podaj pierwszy sygnał bez pełnej diagnozy.
- Pytaj: kto działa, na jakiej podstawie, w jakim czasie?
- Dodawaj konsekwencje oraz sprzeczne informacje.
- Weryfikuj numery kontaktowe, dostęp do logów i procedur.
- Zakończ po osiągnięciu celu, nie po „pokonaniu atakującego”.
- Natychmiast wykonaj hot wash: co zadziałało, co blokowało reakcję?
Co mierzyć
- czas do klasyfikacji i właściciela incydentu;
- czas do decyzji o izolacji;
- dostępność kontaktów i uprawnień;
- możliwość ustalenia zakresu danych;
- jakość śladu decyzyjnego;
- zgodność komunikacji wewnętrznej i zewnętrznej;
- realność RTO/RPO oraz backupów;
- liczbę problemów z przypisanym właścicielem i terminem.
Raport, który prowadzi do poprawy
Każda obserwacja powinna wskazywać dowód, wpływ, właściciela, działanie i termin. Zmień plan reagowania na incydenty, numery alarmowe, role IAM, retencję logów i runbooki. Potem wykonaj mniejsze ćwiczenie weryfikujące poprawki.
Nie oceniaj ludzi za ujawnienie problemu. Celem jest znalezienie luki w bezpiecznych warunkach. Ćwiczenie, w którym wszystko działa idealnie, zwykle było zbyt łatwe albo uczestnicy używali założeń nieobecnych w realnym środowisku.
Dowody, które powinny zostać po ćwiczeniu
Facylitator prowadzi oś czasu injectów, decyzji i brakujących informacji. Obserwatorzy zapisują nie tylko błędy techniczne, lecz także momenty niejasnej odpowiedzialności: kto może odłączyć system, zawiadomić regulatora, uruchomić komunikację kryzysową lub zaakceptować pracę w trybie awaryjnym. Ćwiczenie nie powinno oceniać pojedynczych osób — testuje system decyzyjny organizacji.
Raport końcowy musi zamienić obserwacje w zadania z właścicielem, terminem i kryterium ukończenia. Po 60–90 dniach wykonaj krótki retest najważniejszych luk. Jeżeli scenariusz nigdy nie wymaga odtworzenia danych, kontaktu z dostawcą lub decyzji prawnej, prawdopodobnie jest zbyt wąski.
Przed rozpoczęciem zapisz cele i kryteria sukcesu, np. czas do powołania sztabu, identyfikację właściciela decyzji i dostępność aktualnych kontaktów. Nie ujawniaj całego scenariusza uczestnikom, ale jasno oddziel fikcyjne zdarzenia od realnych alarmów. Zakończ hotwashem jeszcze tego samego dnia, zanim zniknie kontekst decyzji.
Źródła: NIST SP 800-84, NIST SP 800-61 Rev. 3, CISA Tabletop Exercise Packages.