Przeprowadź w tym tygodniu tabletop z reagowania na incydenty

Ćwiczenie tabletop wymaga sali, scenariusza, dwóch godzin i kogoś, kto zapisze, co poszło nie tak. Nie potrzebujesz zewnętrznego dostawcy, budżetu ani gotowego planu reagowania na incydenty. Chodzi o to, żeby sprawdzić, dopóki nic się nie pali, kto faktycznie decyduje o odłączeniu serwera od sieci i gdzie są przechowywane numery telefonów.

Wybierz jeden scenariusz i właściwych ludzi

Wybierz jeden scenariusz. Ransomware na serwerze plików i przejęcie konta skrzynki pocztowej w dziale finansów to dwa najbardziej przydatne scenariusze dla małego zespołu, bo oba wymuszają decyzje dotyczące izolacji, komunikacji i odtwarzania. Nie próbuj objąć obu podczas jednej sesji.

Nie musisz pisać scenariusza od zera. Exercise in a Box od NCSC jest darmowy, zawiera ćwiczenia tabletop dotyczące m.in. ransomware i phishingu oraz materiały do przygotowania, zaplanowania i przeprowadzenia ćwiczenia, a także do wskazania działań po jego zakończeniu. Tabletop Exercise Packages od CISA oferują szablony celów, pytania do dyskusji, formularz opinii i raport After Action Report, w tym scenariusze z ransomware i dla samorządów. Potraktuj je jako szkielet i dopasuj szczegóły do własnych systemów.

Zaproś osoby, które naprawdę uczestniczyłyby w rozmowie w trakcie incydentu:

• osobę administrującą katalogiem i kopiami zapasowymi
• osobę, która może zatwierdzić przestój (menedżera, a nie tylko dział IT)
• kogoś, kto odpowiada za komunikację zewnętrzną, nawet jeśli to office manager
• jednego facilitatora, który nie gra w scenariuszu i nie odpowiada na pytania

Rola facilitatora jest ważna. Jeśli ta sama osoba prowadzi scenariusz i broni własnej konfiguracji, ćwiczenie zamienia się w pokaz.

Dwugodzinny harmonogram

Na początku ustal jedną zasadę: odpowiedzi mają opisywać to, co naprawdę zrobiłbyś z dostępami i narzędziami, które masz dziś, a nie to, co mówi polityka. Jeśli ktoś mówi „sprawdzilibyśmy logi", facilitator pyta: jakie logi, gdzie i kto ma do nich dostęp o 07:40 w poniedziałek.

Injecty w wersji z ransomware

Podawaj scenariusz krok po kroku, a nie wszystko naraz. Sprawdzona kolejność:

1. Użytkownik zgłasza, że dokumenty na dysku współdzielonym zmieniły rozszerzenie, a w każdym folderze leży plik tekstowy z żądaniem okupu.
2. Dwóch kolejnych użytkowników zgłasza to samo. Serwer plików działa wolno.
3. Konsola backupu pokazuje, że ostatnie zadanie się zakończyło, ale serwer kopii zapasowych jest dołączony do domeny.
4. Notatka atakującego grozi opublikowaniem danych za 72 godziny.
5. Poczta nie działa, bo konektor poczty działa na zaatakowanym hoście.

Do każdego kroku przypisz pytanie. Kto może odizolować host i czy potrzebuje na to zgody? Czy kopie zapasowe są osiągalne za pomocą tych samych poświadczeń administratora, które może mieć atakujący? Gdzie jest lista kontaktów, jeśli katalog i poczta są niedostępne? Kto decyduje, czy angażować policję lub organ regulacyjny, i kto kontaktuje się z ubezpieczycielem?

Injecty w wersji z przejęciem konta

Zacznij od zgłoszenia użytkownika z działu finansów, który widzi powtarzające się prośby o MFA, których nie wywołał. Następnie dodaj logowanie z nieznanego kraju, potem odkrycie reguły skrzynki przekazującej pocztę na zewnętrzny adres, a na końcu fakturę ze zmienionymi danymi bankowymi wysłaną do klienta. Zapytaj, jak unieważnić sesje i tokeny, a nie tylko zresetować hasło. Zapytaj, jak daleko wstecz sięgają logi logowań i kto sprawdza skrzynkę pod kątem reguł i delegowanych uprawnień. Jeśli chcesz szybko sprawdzić, czy dane logowania pracowników pojawiły się już w publicznych wyciekach, nasza sprawdzarka wycieków haseł to rozsądny krok przed ćwiczeniem.

Zapisuj luki, póki są świeże

Protokolant prowadzi prosty rejestr. Nie porządkuj go w trakcie sesji. Pojedynczy wpis wygląda tak:

Inject 3 | Backups reachable with domain admin | Gap: backup server domain-joined,
no offline copy confirmed | Owner: infra lead | Fix by: 30 days | Severity: high

Każda luka potrzebuje właściciela i terminu, w przeciwnym razie jest tylko życzeniem. Układaj je według tego, co uniemożliwiłoby wam pracę, a nie według tego, jak bardzo były niezręczne. Typowe ustalenia są przyziemne: nikt nie znał danych logowania do rejestratora domen, numer dyżurny był nieaktualny, a osoba uprawniona do wyłączenia produkcji była na urlopie i nie miała zastępcy.

Poproś uczestników o pisemną opinię, zanim wyjdą. Pakiet CISA zawiera szablon formularza opinii i After Action Report, więc nie musisz projektować żadnego z nich.

Zamień rejestr w runbook

W ciągu tygodnia przekształć rejestr w krótki runbook. Wystarczą jedna lub dwie strony na scenariusz. Runbook, którego nikt nie czyta w trakcie incydentu, jest gorszy niż brak runbooka.

Uwzględnij:

• Pierwsza godzina: ponumerowane działania, każde z przypisaną rolą, a nie imieniem i nazwiskiem.
• Uprawnienia decyzyjne: kto może izolować systemy, kto może zatwierdzić opłacenie zewnętrznej pomocy, kto rozmawia z klientami.
• Kontakty: wydrukowane lub przechowywane offline, obejmujące pracowników, dostawców, dostawcę internetu, ubezpieczyciela i zewnętrznych specjalistów reagowania.
• Postępowanie z dowodami: czego nie wolno czyścić ani restartować, zanim ktoś zabezpieczy obrazy i logi.
• Kolejność odtwarzania: które systemy wracają najpierw i co dowodzi, że są czyste.

Szerszą strukturę znajdziesz w Computer Security Incident Handling Guide od NIST, SP 800-61 Rev. 2, który jest powszechnie przywoływany, ale NIST wycofał go 3 kwietnia 2025 i zastąpił wersją Rev. 3, więc jako punkt odniesienia używaj aktualnej wersji. Jeśli chcesz uzyskać zewnętrzną ocenę runbooka lub pomoc w poprowadzeniu sesji, sprawdź nasze usługi: reagowanie na incydenty i doradztwo.

Następnie zaplanuj powtórkę. Przeprowadź drugi scenariusz za trzy do sześciu miesięcy i ponownie przetestuj poprawki z pierwszego rejestru luk.

Od czego zacząć

1. Zarezerwuj dwie godziny w tym tygodniu i zablokuj kalendarze czterech lub pięciu osób, które uczestniczyłyby w rozmowie w trakcie incydentu.
2. Pobierz scenariusz z ransomware lub phishingiem z Exercise in a Box albo z pakietu CISA i dostosuj go do swoich rzeczywistych systemów.
3. Wskaż facilitatora, który nie będzie grał w scenariuszu, oraz protokolanta, który poprowadzi rejestr luk.
4. Przeprowadź sesję przy otwartych prawdziwych narzędziach: konsoli backupu, katalogu, logach logowań i liście kontaktów.
5. Przypisz właściciela i termin do każdej luki, zanim sala się opróżni.
6. Napisz jednostronicowy runbook w ciągu siedmiu dni i zapisz jego kopię w miejscu, które działa także wtedy, gdy twoja sieć nie działa.