Krótko: Ćwiczenie tabletop w IT omawia incydent bezpieczeństwa przy stole: moderacja krok po kroku podaje nowe informacje o sytuacji, uczestnicy decydują jak w razie prawdziwej awarii, a na końcu powstaje lista konkretnych usprawnień. Dla serwerów WWW nadaje się scenariusz wzorowany na PHP2Shell, ponieważ dotyka jednocześnie techniki, decyzji w warunkach niepewności, ochrony danych i komunikacji.
Dlaczego plan zaczyna działać dopiero przez ćwiczenie
Wiele firm ma dziś plan awaryjny. To, czy działa, pokazuje się jednak dopiero wtedy, gdy ktoś używa go pod presją czasu. Czy jest w nim właściwy numer telefonu? Czy zarząd wie, że musi zdecydować o wyłączeniu? Czy usługodawca zna dostępy? Takie pytania ćwiczenie przy stole wyjaśnia w kilka godzin.
Tydzień października 2026 pokazał, jak szybko sytuacja może eskalować: zapowiedź php.net 20.10., poprawki 21.10. o godz. 16:00 czasu niemieckiego, poziom ostrzegawczy pomarańczowy BSI (niemiecki Federalny Urząd ds. Bezpieczeństwa w Technice Informatycznej), według doniesień medialnych wyłączenia publicznych stron. Kto wcześniej raz przećwiczył taki przebieg, musiał mniej improwizować. Przebieg w szczegółach opisuje Chronologia PHP2Shell. Jak samodzielnie zbudować plan, wyjaśnia artykuł Jak sporządzić plan awaryjny IT dla serwerów WWW; tutaj chodzi o ćwiczenie.
Ćwiczenie tabletop w IT: role i przygotowanie
Dobre ćwiczenie wymaga niewiele materiałów, ale jasnych ról. Moderacja prowadzi przez scenariusz, wprowadza informacje i pilnuje czasu. Nie dyskutuje, lecz zadaje pytania. Protokolant zapisuje decyzje, otwarte pytania i każde miejsce, w którym ktoś mówi „tego teraz bym nie wiedział”. Opcjonalnie kolejna osoba obserwuje, jak przebiega komunikacja.
Uczestnicy to ludzie, którzy w razie prawdziwej awarii faktycznie działają: zarząd, wewnętrzne IT lub zewnętrzny usługodawca, inspektorzy ochrony danych, komunikacja, w razie potrzeby zakupy lub dział prawny. Ważne, aby byli też zastępcy, ponieważ incydenty nie liczą się z planami urlopowymi.
Do przygotowania należą: aktualny plan awaryjny na papierze, lista kontaktów, przegląd stron i serwerów oraz pomieszczenie bez przerw. Proszę wcześniej ustalić, że chodzi o uczenie się, a nie o oceny. Kto boi się skompromitować, nie powie, czego nie wie.
Gotowy scenariusz: krytyczna luka w PHP w piątek po południu
Poniższy scenariusz jest fikcyjny, ale wzorowany na prawdziwej sytuacji. Proszę dostosować systemy i nazwy do swojego środowiska. Każdy wstrzyk otrzymuje dziesięć do dwudziestu minut dyskusji.
| Krok | Wstrzyk moderacji | Pytanie przewodnie do grupy |
|---|---|---|
| 1 | Prasa branżowa donosi o krytycznej luce w PHP, poprawki są zapowiedziane, ale jeszcze ich nie ma. | Kto dowie się o tym pierwszy i kogo trzeba poinformować? |
| 2 | Poprawki ukazują się po południu. BSI zaleca natychmiastową aktualizację, w przeciwnym razie tymczasowe wyłączenie. | Które z naszych systemów są dotknięte i skąd to wiemy? |
| 3 | Firma hostingowa się nie odzywa. Własny serwer działa na wersji PHP bez oficjalnej aktualizacji. | Łatać, wyłączyć czy czekać i kto o tym decyduje? |
| 4 | Sklep ma w weekend prowadzić promocję. Sprzedaż naciska, by niczego nie wyłączać. | Jak ważymy przychody i ryzyko i jak dokumentujemy decyzję? |
| 5 | Administrator znajduje w poniedziałek nieznany plik PHP w folderze uploadu. | Co robimy najpierw, czego świadomie nie robimy? Kto zabezpiecza dowody? |
| 6 | Nie jest jasne, czy dane klientów wyciekły. | Kto ocenia możliwy obowiązek zgłoszenia i kiedy biegnie termin? |
| 7 | Dziennikarka pyta, dlaczego strona jest offline. | Kto wypowiada się na zewnątrz i co mówimy, dopóki wiemy niewiele? |
Krok 6 dotyka RODO. W ćwiczeniu wystarczy wyjaśnić przebieg: kto włącza inspektorów ochrony danych i kiedy. Ocena prawna pozostaje przy specjalistach; podstawowe zasady dotyczące terminu zawiera art. 33 RODO.
Typowe wnioski i jak je zapisać
Pewne luki pojawiają się niemal przy każdym pierwszym ćwiczeniu. Brakuje pełnej listy, jakie strony działają na jakich serwerach z jaką wersją PHP. Dane kontaktowe firmy hostingowej są nieaktualne albo zapisane tylko w skrzynce pocztowej, która w razie awarii jest nieosiągalna. Nikt nie wie na pewno, czy zarząd może sam zarządzić wyłączenie, czy ktoś musi się zgodzić.
Proszę zapisać każdy wniosek w trzech częściach: co stwierdziliśmy, co zmieniamy i kto to zrobi do kiedy. Wniosek bez osoby odpowiedzialnej, jak pokazuje doświadczenie, zostaje na półce. Punkty proszę uporządkować według skutku: brakujący numer awaryjny jest szybko uzupełniony i pomaga od razu, nowe rozwiązanie monitoringu wymaga planowania.
Do uporządkowanej oceny po ćwiczeniu nadaje się to samo postępowanie, co po prawdziwym incydencie. Jest opisane we wpisie Lessons learned: jak stać się lepszym po incydencie. Listę kontaktów, która w ćwiczeniu zwykle ujawnia słabości, omawia wpis Kontakty awaryjne: kogo i kiedy trzeba poinformować?.
Proszę powtórzyć ćwiczenie po sześciu do dwunastu miesiącach z innym scenariuszem, na przykład zhakowanej strony z przekierowaniem na obce witryny. W ten sposób sprawdzą Państwo, czy działania z pierwszej rundy zostały naprawdę wdrożone.
Jak konkretnie pomaga PHP SOS?
- Dostosowujemy scenariusz do Państwa rzeczywistych stron, serwerów i usługodawców i przygotowujemy wstrzyki.
- Moderujemy ćwiczenie zdalnie lub przez wideokonferencję i powstrzymujemy się od ocen, dopóki grupa nie podejmie decyzji.
- Dostarczamy potem protokół z wnioskami, działaniami, osobami odpowiedzialnymi i terminami.
- Na życzenie ćwiczymy następnie część techniczną, czyli inwentaryzację, poprawkę i poszukiwanie śladów, tak jak wykonuje ją nasze reagowanie na incydenty w razie awarii.
Podsumowanie
Ćwiczenie awaryjne przy stole to najtańszy sposób na znalezienie słabości planu awaryjnego, zanim zrobi to prawdziwy incydent. Na początek wystarczą jedno popołudnie, realistyczny scenariusz i uczciwa ocena. Decydujące jest to, aby z każdego wniosku powstało zadanie z nazwiskiem i datą.
Częste pytania
Czym jest ćwiczenie tabletop?
To ćwiczenie, w którym uczestnicy wspólnie omawiają incydent przy stole, nie pracując na prawdziwych systemach. Moderacja krok po kroku wprowadza nowe informacje, a grupa decyduje i uzasadnia swoje decyzje. W ten sposób uwidaczniają się luki w planie, odpowiedzialnościach i listach kontaktów.
Kto powinien uczestniczyć w ćwiczeniu awaryjnym?
Wszyscy, którzy w razie awarii decydują lub działają: zarząd, IT lub usługodawca, ochrona danych, komunikacja oraz, jeśli jest, osoba odpowiedzialna za sprawy ubezpieczeniowe. Więcej niż osiem do dziesięciu osób sprawia, że runda staje się ociężała.
Jak długo trwa ćwiczenie tabletop?
Na pierwsze przejście wystarczają dwie do trzech godzin wraz z oceną. Ważniejsze niż długość jest to, aby wyniki zostały zapisane, a działania przydzielone z terminem.
Czy scenariusz musi być realistyczny?
Powinien pasować do Państwa środowiska, ale nie musi zgadzać się w każdym szczególe. Scenariusz wzorowany na prawdziwej sytuacji, takiej jak PHP2Shell, jest wiarygodny i kieruje dyskusję na decyzje zamiast na szczegóły techniczne.