Plan reagowania na incydent cyberbezpieczeństwa – co powinien zawierać?

Skutki cyberataku mogą w krótkim czasie zakłócić działanie całej organizacji. Niedostępność systemów i danych utrudnia realizację kluczowych procesów, obsługę klientów oraz komunikację, a najważniejsze decyzje trzeba podejmować pod presją czasu.

Wtedy okazuje się, że reakcja na incydent nie jest zadaniem wyłącznie dla zespołu IT. W zależności od skali zdarzenia może wymagać zaangażowania zarządu, zespołów operacyjnych, komunikacji, działu prawnego oraz osób odpowiedzialnych za zgodność i ciągłość działania.

Podmioty objęte ustawą o krajowym systemie cyberbezpieczeństwa, wdrażającą do polskiego prawa wymagania NIS2, muszą uwzględnić także obowiązki regulacyjne. Odnoszą się one m.in. do oceny zdarzenia, terminowego raportowania oraz współpracy z właściwymi organami i zespołami CSIRT.

Sama procedura nie gwarantuje jednak skutecznej reakcji. Musi być możliwa do zastosowania w praktyce i znana osobom odpowiedzialnym za działania techniczne, decyzje biznesowe oraz komunikację.

Co zatem powinien zawierać plan reagowania na incydent cyberbezpieczeństwa i jak przygotować go do wykorzystania w praktyce?

Czym jest incydent cyberbezpieczeństwa?

Incydent cyberbezpieczeństwa to zdarzenie, które narusza dostępność, poufność, integralność lub autentyczność danych albo usług świadczonych za pośrednictwem systemów informacyjnych. Może wpływać zarówno na bezpieczeństwo środowiska IT, jak i na ciągłość procesów biznesowych.

Do takich zdarzeń należą m.in. przejęcie konta użytkownika, wyciek danych, infekcja złośliwym oprogramowaniem, niedostępność systemu czy zakłócenie działania kluczowej usługi. Źródłem incydentu może być również błąd konfiguracyjny, podatność wykorzystywanego rozwiązania albo atak przeprowadzony za pośrednictwem dostawcy.

Nie każdy incydent podlega obowiązkowi zgłoszenia. Podmioty objęte ustawą o krajowym systemie cyberbezpieczeństwa powinny ocenić jego skalę, przyczyny i wpływ na świadczone usługi, aby ustalić, czy spełnia kryteria incydentu poważnego. Od wyniku tej klasyfikacji zależą dalsze działania, w tym obowiązek przekazania zgłoszenia do właściwego CSIRT.

Dlatego reagowanie nie powinno ograniczać się do doraźnego usunięcia problemu technicznego. Potrzebny jest uporządkowany proces, który pozwala ocenić zdarzenie, ograniczyć jego skutki, spełnić obowiązki raportowe i bezpiecznie przywrócić działanie organizacji.

Dlaczego plan reagowania jest dziś tak ważny?

Plan reagowania skraca czas potrzebny na ocenę sytuacji i pozwala uruchomić właściwe działania bez ustalania ról dopiero w trakcie kryzysu. Określa, kto podejmuje decyzje, w jaki sposób należy eskalować zdarzenie oraz jak skoordynować pracę zespołów technicznych i biznesowych.

Ma to szczególne znaczenie, gdy niedostępność systemów wpływa na realizację usług, obsługę klientów lub komunikację. W takiej sytuacji organizacja musi jednocześnie ograniczać skutki ataku, utrzymać kluczowe procesy i przekazywać sprawdzone informacje osobom zaangażowanym w reakcję.

Dla podmiotów objętych ustawą o krajowym systemie cyberbezpieczeństwa plan ma również znaczenie regulacyjne. Nowe zasady przewidują przekazanie wczesnego ostrzeżenia o incydencie poważnym w ciągu 24 godzin, a następnie jego zgłoszenie w ciągu 72 godzin od wykrycia. Podmioty kluczowe i ważne mają czas na wdrożenie obowiązków wynikających z nowych przepisów do 3 kwietnia 2027 roku. Ich realizacja wymaga sprawnej klasyfikacji zdarzenia, zabezpieczenia potrzebnych informacji oraz ustalenia, kto odpowiada za kontakt z właściwym CSIRT.

Dobrze przygotowany i przetestowany plan porządkuje te działania, zmniejsza ryzyko błędnych decyzji i ułatwia organizacji powrót do normalnego funkcjonowania.

Przeczytaj również: Nowa ustawa o Krajowym Systemie Cyberbezpieczeństwa – najważniejsze zmiany i obowiązki

Co powinien zawierać plan reagowania na incydent cyberbezpieczeństwa?

Plan reagowania powinien określać role i odpowiedzialności, sposób klasyfikacji oraz eskalacji zdarzeń, procedury techniczne, zasady komunikacji i raportowania, a także działania związane z odtworzeniem systemów i analizą przyczyn incydentu.

Nie istnieje jeden wzór odpowiedni dla każdej organizacji. Innych scenariuszy będzie wymagać firma produkcyjna, innych instytucja finansowa, a jeszcze innych podmiot korzystający głównie z usług chmurowych.

Zakres planu musi uwzględniać skalę działalności, zidentyfikowane ryzyka, wykorzystywane technologie, zależności od dostawców oraz wymagania regulacyjne.

Niezależnie od specyfiki organizacji w planie warto uwzględnić następujące elementy.

1. Role i odpowiedzialności

W dokumencie należy jednoznacznie wskazać, kto koordynuje reakcję, odpowiada za działania techniczne i podejmuje decyzje biznesowe. Trzeba również określić osoby uprawnione do uruchomienia procedur awaryjnych, wyłączenia części środowiska czy poinformowania klientów, organów państwowych lub mediów.

Przypisanie odpowiedzialności z wyprzedzeniem ogranicza ryzyko opóźnień i sprzecznych decyzji podejmowanych w trakcie kryzysu. Warto wyznaczyć również zastępców na wypadek nieobecności kluczowych osób.

2. Zespół reagowania na incydenty

Zakres kompetencji zespołu dobiera się do możliwych skutków zdarzenia. Poza specjalistami IT i cyberbezpieczeństwa w jego skład mogą wejść przedstawiciele zarządu, działu prawnego, komunikacji, HR, compliance, operacji oraz ciągłości działania.

W planie warto określić, kiedy poszczególne osoby dołączają do zespołu, kto kieruje jego pracą i z jakich kanałów komunikacji korzystają jego członkowie. Ułatwia to dopasowanie kompetencji do charakteru incydentu i jego potencjalnych konsekwencji.

3. Klasyfikacja i ścieżki eskalacji

Plan określa kryteria oceny skali zdarzenia, jego wpływu na usługi i ryzyka dalszego rozprzestrzeniania się zagrożenia. Pomocne są poziomy krytyczności, matryce klasyfikacyjne oraz przykładowe scenariusze wskazujące działania właściwe w danej sytuacji.

Należy także ustalić, kogo i w jakim czasie powiadomić. Dla podmiotów objętych ustawą o KSC prawidłowa klasyfikacja ma bezpośredni wpływ na obowiązek zgłoszenia incydentu poważnego do właściwego CSIRT.

4. Procedury techniczne i operacyjne

Procedury powinny obejmować działania od wykrycia zdarzenia i zabezpieczenia dowodów, przez izolację zagrożonych zasobów oraz analizę skali ataku, aż po usunięcie jego przyczyn i bezpieczne odtworzenie systemów.

W dokumencie warto również wskazać, gdzie przechowywane są logi, kto ma do nich dostęp i jakie dane trzeba zabezpieczyć do dalszej analizy. Poszczególne instrukcje warto dostosować do konkretnych scenariuszy, takich jak ransomware, przejęcie konta, wyciek danych czy niedostępność kluczowej usługi.

5. Komunikacja kryzysowa

W tej części należy określić, kto odpowiada za komunikację z pracownikami, klientami, partnerami, mediami i organami państwowymi. Warto wcześniej przygotować zasady zatwierdzania komunikatów oraz ustalić, jakie informacje mogą być przekazywane na poszczególnych etapach reagowania.

Plan musi także uwzględniać alternatywne kanały kontaktu na wypadek niedostępności firmowej poczty, komunikatorów lub telefonii. Pozwoli to zespołowi sprawnie wymieniać informacje, a jednocześnie ograniczyć ryzyko dezinformacji lub nieuprawnionego ujawnienia danych o incydencie.

6. Kontakty awaryjne i współpraca z podmiotami zewnętrznymi

Lista kontaktów awaryjnych powinna obejmować dostawców usług IT i chmurowych, administratorów kluczowych systemów, kancelarię prawną, specjalistów informatyki śledczej, dostawcę SOC oraz właściwy CSIRT. Trzeba regularnie sprawdzać aktualność danych i dostępność wsparcia poza standardowymi godzinami pracy.

W dokumencie należy określić zasady udzielania dostępu zewnętrznym ekspertom, zakres odpowiedzialności dostawców oraz sposób bezpiecznej wymiany danych. Jest to szczególnie istotne w środowiskach wykorzystujących outsourcing lub wielu wzajemnie zależnych usługodawców.

7. Raportowanie i dokumentowanie działań

Ważne jest jasne przypisanie odpowiedzialności za ocenę obowiązku zgłoszenia incydentu, przygotowanie wymaganych informacji i kontakt z właściwym CSIRT. W tym miejscu warto również uwzględnić terminy, zakres poszczególnych zgłoszeń oraz zasady dokumentowania podjętych decyzji.

Rejestrowanie przebiegu incydentu ułatwia przygotowanie raportu końcowego, współpracę z organami państwowymi i późniejszą ocenę skuteczności podjętych działań.

8. Odtworzenie działania i wnioski po incydencie

Plan obejmuje również kryteria bezpiecznego przywracania systemów, kolejność odtwarzania usług oraz sposób potwierdzenia, że zagrożenie zostało usunięte. Samo uruchomienie środowiska nie oznacza jeszcze zakończenia procesu reagowania.

Po incydencie analizuje się jego przyczyny i przebieg, a wnioski wykorzystuje do aktualizacji procedur, zabezpieczeń i scenariuszy reagowania.

Z praktyki Resilia: Problemem często okazuje się nie brak procedury, lecz rozbieżność między jej zapisami a rzeczywistym sposobem działania organizacji. Nieaktualne kontakty, zmiany w składzie zespołu czy nowe zależności od dostawców mogą sprawić, że w czasie incydentu część założeń okaże się nieaktualna.

Jak wygląda reakcja na incydent cyberbezpieczeństwa? Przykładowy scenariusz działania

Przebieg reakcji zależy od rodzaju zdarzenia, wykorzystywanych technologii i przyjętych procedur. Poniższy scenariusz pokazuje, jakie działania może podjąć organizacja po wykryciu potencjalnego ataku phishingowego.

Scenariusz

Pracownik otwiera załącznik otrzymany w wiadomości phishingowej. System EDR wykrywa próbę uruchomienia złośliwego skryptu PowerShell i nawiązania połączenia z zewnętrzną infrastrukturą Command and Control (C2). Alert trafia do zespołu bezpieczeństwa lub SOC.

Etap 1 – weryfikacja alertu

Zespół sprawdza, którego urządzenia i użytkownika dotyczy zdarzenie oraz jakie procesy zostały uruchomione. Analizuje dane z EDR, aktywność konta, połączenia sieciowe i zdarzenia systemowe.

Pierwszym celem jest potwierdzenie, czy doszło do incydentu, oraz wstępna ocena jego skali. Zespół weryfikuje również, czy podobna aktywność wystąpiła na innych urządzeniach lub kontach.

Etap 2 – ograniczenie zagrożenia

Urządzenie, które mogło zostać przejęte, zostaje odizolowane od sieci zgodnie z przyjętą procedurą. Konieczne może być także zablokowanie konta użytkownika, unieważnienie aktywnych sesji, zablokowanie szkodliwych adresów oraz zabezpieczenie wiadomości phishingowej.

Jeżeli charakter zdarzenia na to pozwala, urządzenie może pozostać włączone, aby zachować dane zapisane w pamięci operacyjnej. Dalsze postępowanie określa procedura, a decyzję podejmuje zespół reagowania.

Etap 3 – analiza techniczna i ocena skali incydentu

Zespół odtwarza przebieg zdarzenia i ustala, jakie działania wykonał złośliwy skrypt. Sprawdza m.in., czy doszło do pobrania dodatkowego oprogramowania, przejęcia danych uwierzytelniających, komunikacji z infrastrukturą atakującego lub rozprzestrzenienia się zagrożenia na inne systemy.

Równolegle oceniany jest wpływ zdarzenia na dane i świadczone usługi. W przypadku podmiotu objętego ustawą o KSC analiza obejmuje również ustalenie, czy zdarzenie spełnia kryteria incydentu poważnego i wymaga zgłoszenia do właściwego CSIRT.

Etap 4 – eskalacja i działania organizacyjne

Jeżeli incydent może wpłynąć na działalność firmy, informacja trafia do osób odpowiedzialnych za decyzje biznesowe, ciągłość działania, kwestie prawne i komunikację. W zależności od skali zdarzenia organizacja może uruchomić procedury awaryjne, skontaktować się z dostawcami oraz przygotować komunikaty dla pracowników, klientów lub partnerów.

Na tym etapie należy również dokumentować podjęte decyzje i działania. Jeśli incydent podlega obowiązkowi zgłoszenia, wyznaczona osoba przekazuje wymagane informacje do właściwego CSIRT w przewidzianym terminie.

Etap 5 – usunięcie zagrożenia i odtworzenie środowiska

Po ustaleniu przyczyn incydentu zespół usuwa złośliwe oprogramowanie i mechanizmy pozwalające atakującemu utrzymać dostęp. Konieczne może być odtworzenie urządzenia z zaufanego obrazu, zmiana danych uwierzytelniających, usunięcie podatności oraz aktualizacja konfiguracji i reguł detekcji.

Systemy powinny wracać do działania dopiero po potwierdzeniu, że zagrożenie zostało usunięte i nie występuje w innych częściach środowiska.

Etap 6 – analiza poincydentowa

Po zakończeniu działań organizacja analizuje przebieg zdarzenia i ocenia skuteczność reakcji. Sprawdza, co zadziałało prawidłowo, gdzie pojawiły się opóźnienia oraz jakie zabezpieczenia lub procedury wymagają zmiany.

Wnioski powinny przełożyć się na konkretne działania: aktualizację planu reagowania, poprawę konfiguracji, rozszerzenie monitoringu, zmianę zasad współpracy z dostawcami lub dodatkowe szkolenia pracowników. Każde działanie naprawcze powinno mieć przypisaną osobę odpowiedzialną i termin realizacji. Warto również sprawdzić, czy wdrożone zmiany rzeczywiście usunęły przyczyny lub słabości ujawnione podczas incydentu.

Przeczytaj również: System S46 i Wykaz KSC – najważniejsze informacje dla podmiotów objętych ustawą o KSC

Najczęstsze błędy podczas incydentów cyberbezpieczeństwa

O skuteczności reakcji nie decydują wyłącznie wykorzystywane technologie. Równie istotne są dostęp do informacji, podział odpowiedzialności i sposób podejmowania decyzji. Błędy w tych obszarach mogą wydłużyć czas obsługi incydentu oraz utrudnić ocenę jego rzeczywistej skali.

Pochopne usuwanie skutków incydentu

Wyłączenie urządzenia, usunięcie plików lub przeinstalowanie systemu przed zabezpieczeniem materiału do analizy może doprowadzić do utraty ważnych informacji. Dotyczy to m.in. danych z pamięci operacyjnej, historii procesów i śladów aktywności atakującego. Kolejność działań powinna wynikać z procedury i decyzji zespołu reagowania, ponieważ sposób zabezpieczenia urządzenia zależy od rodzaju zdarzenia.

Brak danych potrzebnych do analizy

Zbyt krótka retencja logów, rozproszenie danych albo brak centralnego monitoringu utrudniają odtworzenie przebiegu ataku. Problem jest szczególnie widoczny, gdy incydent zostaje wykryty długo po pierwszej aktywności atakującego. Bez odpowiednich danych trudno ustalić punkt wejścia, zasięg kompromitacji i systemy wymagające zabezpieczenia.

Niejasny podział odpowiedzialności

W trakcie incydentu nie powinno się dopiero ustalać, kto koordynuje działania, podejmuje decyzje biznesowe lub odpowiada za komunikację. Brak wyznaczonych osób i zastępców prowadzi do opóźnień, powielania zadań oraz przekazywania sprzecznych informacji.

Nieaktualne kontakty i nieustalone zasady współpracy

Numer telefonu do niepracującej już osoby lub brak kontaktu do całodobowego wsparcia dostawcy może zatrzymać reakcję w kluczowym momencie. Listy kontaktów awaryjnych, zasady udzielania dostępu zewnętrznym ekspertom i ścieżki eskalacji powinny być regularnie weryfikowane.

Zbyt późna klasyfikacja i eskalacja zdarzenia

Odkładanie oceny wpływu incydentu może opóźnić uruchomienie procedur awaryjnych oraz realizację obowiązków raportowych. Klasyfikacja powinna rozpocząć się już na wczesnym etapie i być aktualizowana wraz z pojawianiem się nowych informacji.

Procedury, których nie sprawdzono w praktyce

Samo opracowanie dokumentacji nie potwierdza gotowości organizacji. Ćwiczenia typu tabletop, symulacje ransomware oraz testy niedostępności usług pozwalają sprawdzić, czy role są zrozumiałe, kanały komunikacji działają, a zespół potrafi podejmować decyzje na podstawie niepełnych informacji. Wnioski z ćwiczeń powinny prowadzić do aktualizacji planu i usunięcia wykrytych luk.

Podsumowanie

Skuteczna reakcja na cyberatak wymaga koordynacji działań technicznych, decyzji biznesowych, komunikacji i obowiązków regulacyjnych. Plan reagowania porządkuje ten proces: wskazuje odpowiedzialne osoby, zasady eskalacji, sposób ograniczania skutków zdarzenia oraz działania potrzebne do bezpiecznego odtworzenia systemów.

Dokument powinien być dostosowany do rzeczywistych procesów i zagrożeń organizacji, regularnie aktualizowany oraz sprawdzany podczas ćwiczeń. Ma to szczególne znaczenie dla podmiotów objętych ustawą o krajowym systemie cyberbezpieczeństwa, które muszą odpowiednio klasyfikować i terminowo zgłaszać incydenty poważne.

Dobrze przygotowany plan skraca czas reakcji, ogranicza ryzyko błędnych decyzji i pomaga sprawniej przywrócić normalne funkcjonowanie organizacji.

Potrzebujesz wsparcia w przygotowaniu organizacji na incydenty?

Projektujemy i wdrażamy procesy zarządzania incydentami, opracowujemy plany reagowania oraz weryfikujemy ich skuteczność podczas ćwiczeń i symulacji. Pomagamy także podmiotom objętym ustawą o KSC przejść od analizy wymagań do wdrożenia konkretnych rozwiązań organizacyjnych i technicznych zgodnych z NIS2 i krajowymi przepisami.

Wyślij formularz kontaktowy na dole strony, aby omówić zakres wsparcia dopasowany do potrzeb Twojej organizacji.

Wdrożenie NIS2 i KSC

Sprawdź usługę VCISO