Przejdź do treści
INDEKS ANALIZ BREACHROAD / NOTA TECHNICZNA
Reagowanie

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.

MATERIAŁ PUBLICZNY
AUTOR
/ Pentester (OSCP, PNPT)
PUBLIKACJA
8 lipca 2026
CZAS CZYTANIA
10 min czytania
TEMAT
Reagowanie
Tabletop exercise — jak przećwiczyć reakcję na incydent

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

  1. Przedstaw zasady, cel i stan początkowy.
  2. Podaj pierwszy sygnał bez pełnej diagnozy.
  3. Pytaj: kto działa, na jakiej podstawie, w jakim czasie?
  4. Dodawaj konsekwencje oraz sprzeczne informacje.
  5. Weryfikuj numery kontaktowe, dostęp do logów i procedur.
  6. Zakończ po osiągnięciu celu, nie po „pokonaniu atakującego”.
  7. 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.

UDOSTĘPNIJ / KOPIUJ