Incydent bezpieczeństwa w jednostce samorządu terytorialnego to nie kwestia „czy”, tylko „kiedy”. Ustawa o Krajowym Systemie Cyberbezpieczeństwa nakłada na wójtów, burmistrzów, prezydentów miast i starostów obowiązek posiadania procedur reagowania oraz zgłaszania incydentów do właściwego CSIRT-u. Poniższy przewodnik pokazuje, jak zbudować działający plan reagowania na incydenty (IRP), które terminy trzeba dotrzymać i jak sprawdzić, czy dokumenty rzeczywiście chronią urząd — a nie tylko leżą w segregatorze.

Dlaczego plan reagowania na incydenty jest obowiązkowy w JST

Znowelizowana ustawa o KSC oraz dyrektywa NIS2 kwalifikują JST jako podmioty istotne dla ciągłości usług publicznych. Obowiązki obejmują między innymi wdrożenie Systemu Zarządzania Bezpieczeństwem Informacji, cykliczny audyt, wyznaczenie osób odpowiedzialnych za cyberbezpieczeństwo oraz raportowanie incydentów. Brak procedury reagowania to nie tylko ryzyko techniczne — to bezpośrednia podstawa do zaleceń pokontrolnych NIK, kar administracyjnych i osobistej odpowiedzialności kierownika jednostki.

Realne zagrożenia dla JST to dziś w większości ransomware, phishing ukierunkowany na skarbników i sekretarki, kompromitacja poczty urzędu oraz wycieki danych z systemów dziedzinowych (EZD, systemy ewidencyjne, rejestry mieszkańców). Każdy z tych scenariuszy potrafi w kilka godzin zatrzymać obsługę mieszkańców, wypłatę świadczeń lub obieg dokumentów.

Struktura planu IRP zgodnego z KSC i ISO/IEC 27035

Skuteczny plan reagowania na incydenty w JST opiera się na cyklu życia incydentu opisanym w normie ISO/IEC 27035 i wpisuje się w wymagania KSC. Powinien zawierać sześć twardo zdefiniowanych faz:

1. Przygotowanie

Powołanie zespołu reagowania (koordynator, administrator IT, IOD, radca prawny, rzecznik prasowy), aktualne listy kontaktowe, wzory komunikatów, umowy z podmiotem zewnętrznym świadczącym usługi SOC/CSIRT komercyjnego oraz — co kluczowe — pełne, przetestowane kopie zapasowe.

2. Wykrywanie i klasyfikacja

Źródła sygnałów: system SIEM lub logi z firewalla, zgłoszenia użytkowników przez helpdesk, alerty z antywirusa/EDR, powiadomienia od CSIRT NASK lub CERT Polska. Każde zgłoszenie musi być zarejestrowane w rejestrze incydentów z sygnaturą, datą wykrycia i wstępną klasyfikacją.

3. Powstrzymanie i eradykacja

Odcięcie zainfekowanego segmentu sieci, zablokowanie kont, wymuszona zmiana haseł, wyłączenie usług dziedzinowych do czasu weryfikacji. Kolejność działań musi być spisana w formie checklisty — w trakcie ataku nikt nie ma czasu improwizować.

4. Odtworzenie

Przywrócenie systemów z kopii zapasowych, weryfikacja integralności, kontrolowane włączanie usług dla mieszkańców. Odtworzenie musi być poprzedzone testem odtwarzania wykonywanym co najmniej kwartalnie — inaczej backup istnieje tylko na papierze.

5. Zgłoszenie do CSIRT

Zgodnie z ustawą o KSC incydent poważny należy zgłosić do właściwego CSIRT (dla JST — CSIRT NASK) w terminie 24 godzin od wykrycia jako wczesne ostrzeżenie, uzupełnić w ciągu 72 godzin i przekazać raport końcowy w terminie miesiąca. Zgłoszenia realizuje się przez system S46.

6. Wnioski (lessons learned)

Spotkanie zespołu, spisanie przyczyn źródłowych, aktualizacja procedur, kalendarza szkoleń i konfiguracji technicznych. Bez tego kroku ten sam incydent wróci za trzy miesiące.

Checklista pierwszej godziny — co robić od minuty zero

W trakcie realnego incydentu emocje wygrywają z procedurą, dlatego najważniejszy dokument to jednostronicowa checklista pierwszej godziny. W urzędzie powinna wisieć fizycznie u administratora, u sekretarza i u koordynatora ds. cyberbezpieczeństwa. Minimalny zakres:

• Kto podejmuje decyzje — imię, nazwisko, numery telefonów (podstawowy i zapasowy).
• Kogo powiadomić w ciągu 15 minut — kierownik jednostki, IOD, dostawca IT, kancelaria prawna.
• Które usługi wolno wyłączyć bez zgody kierownika (np. dostęp zewnętrzny do EZD) i które wymagają decyzji na piśmie.
• Jakie dowody zabezpieczyć: zrzuty logów, obraz dysku, kopia poczty — zanim ktoś zacznie „naprawiać”.
• Wzory komunikatów: dla mieszkańców, dla mediów, dla nadzoru.

Symulacje tabletop — jak przetestować plan, zanim zrobi to atakujący

Ćwiczenie „tabletop” to warsztat, w którym zespół reagowania przechodzi przez fikcyjny scenariusz incydentu bez fizycznego uruchamiania systemów. Trwa 2–3 godziny i kosztuje kilka razy mniej niż jeden dzień przestoju urzędu. Rekomendujemy dwie sesje rocznie: jedną z ransomware szyfrującym systemy dziedzinowe, drugą z wyciekiem danych osobowych z rejestru mieszkańców. Po każdej sesji powstaje krótki raport z rekomendacjami.

Dojrzała obsługa incydentów w JST to nie stos dokumentów, lecz sprawdzone reakcje ludzi. Jeśli Twój urząd nie ma jeszcze planu IRP albo od dwóch lat nikt go nie testował, warto zacząć od audytu gotowości — pomożemy zbudować dokumentację i przeprowadzić pierwszą symulację.