Procedura reakcji na incydent dla firmy 50–200 osób powinna jasno określać, kto podejmuje decyzje, jak zabezpiecza się dowody, kiedy izoluje systemy oraz kto odpowiada za zgłoszenia do CSIRT i UODO. W średniej organizacji nie ma miejsca na improwizację: jedna pochopna decyzja może zatrzeć ślady ataku, zatrzymać kluczowy proces albo uruchomić odpowiedzialność regulacyjną.
Ograniczyć skutki cyberataku, zachować materiał dowodowy, utrzymać ciągłość działania i przeprowadzić organizację od pierwszego alarmu do bezpiecznego odtworzenia usług oraz sprawozdania końcowego.
Model zespołu Zarząd + IT + IOD + ekspert zewnętrzny
Dokument nie zastępuje planu dopasowanego do infrastruktury konkretnej firmy. Jest praktycznym szkieletem dla zarządu, osoby odpowiedzialnej za bezpieczeństwo, działu IT, IOD i zewnętrznego dostawcy technologii. Przed incydentem należy przypisać nazwiska do ról, ustalić kanał komunikacji awaryjnej i przetestować procedurę podczas ćwiczenia.
Najpierw bezpieczeństwo ludzi i ciągłość procesów krytycznych
Zabezpieczenie dowodów jest ważne, ale nie ma pierwszeństwa przed życiem, zdrowiem ani bezpieczeństwem instalacji. W środowiskach produkcyjnych, medycznych i OT izolację lub wyłączenie systemu należy uzgodnić z osobą odpowiedzialną za dany proces.
Od czego zacząć reakcję na incydent?
Zanim zespół rozpocznie naprawę, musi ograniczyć ryzyko utraty danych potrzebnych do ustalenia przyczyn i zakresu zdarzenia. Pierwsze działania powinny być zapisywane w dzienniku incydentu wraz z dokładnym czasem, osobą wykonującą czynność i jej rezultatem.
- Nie restartuj pochopnie zainfekowanych serwerów i stacji. Restart lub odłączenie zasilania może usunąć dane ulotne, aktywne połączenia i informacje z pamięci RAM.
- Jeżeli jest to bezpieczne operacyjnie, odizoluj urządzenie od sieci zamiast wyłączać jego zasilanie. Odłącz przewód sieciowy, wyłącz Wi-Fi lub zastosuj izolację przez EDR.
- Ustal i zapisz moment wykrycia incydentu poważnego. Od niego mogą biec terminy 24 i 72 godzin wynikające z ustawy o KSC.
Pierwsze 15 minut
Alarm, koordynator, dziennik działań i pierwsza izolacja.
Skala, dowody, zagrożone konta, systemy krytyczne i kopie zapasowe.
Wczesne ostrzeżenie o incydencie poważnym do właściwego CSIRT.
Zgłoszenie incydentu poważnego oraz odrębna analiza obowiązku wobec UODO.
Sprawozdanie końcowe albo sprawozdanie z postępu, jeśli obsługa nadal trwa.
Identyfikacja, ocena skali i zabezpieczenie dowodów
Potwierdź incydent
Celem nie jest natychmiastowe nazwanie sprawcy, lecz ustalenie, czy zdarzenie rzeczywiście zagraża poufności, integralności lub dostępności systemów i usług. Zespół powinien odróżnić incydent od błędu użytkownika, awarii sprzętu lub pojedynczego alertu bez skutków.
- Zabezpiecz logi z zapór sieciowych, Active Directory, EDR lub antywirusa, poczty, VPN, aplikacji chmurowych i systemów krytycznych.
- Jeżeli jest to możliwe i zespół posiada odpowiednie kompetencje, wykonaj zrzut pamięci RAM oraz kopię danych potrzebnych do analizy śledczej.
- Określ typ zagrożenia: ransomware, phishing i przejęcie konta, wyciek danych, DDoS, złośliwe oprogramowanie, nadużycie uprawnień albo podatność aplikacji.
- Ustal, które systemy, lokalizacje, konta, dane i procesy zostały dotknięte oraz czy atak nadal trwa.
- Sprawdź wpływ na sprzedaż, produkcję, obsługę klienta, płatności, logistykę i inne usługi krytyczne.
Informacje, które muszą trafić do dziennika incydentu
Kto wykrył zdarzenie, o której godzinie i na podstawie jakiego alertu lub objawu.
Urządzenia, konta, adresy IP, domeny, systemy, dane i wskaźniki kompromitacji.
Niedostępne usługi, przerwane procesy, możliwe straty i dotknięci odbiorcy.
Kto zatwierdził izolację, reset danych dostępowych, komunikat lub zgłoszenie.
Powstrzymanie zagrożenia i izolacja systemów
Zatrzymaj rozprzestrzenianie
Powstrzymanie powinno ograniczyć straty bez niszczenia dowodów i bez niekontrolowanego zatrzymania całej firmy. Zakres działań zależy od rodzaju ataku i krytyczności systemów.
- Odłącz zainfekowane urządzenia od LAN i Internetu albo zastosuj izolację sieciową przez system EDR.
- Zablokuj na zaporze ruch do i z potwierdzonych złośliwych adresów IP, domen i innych wskaźników kompromitacji.
- Zablokuj przejęte konta, unieważnij aktywne sesje i tokeny, zmień hasła kont zagrożonych oraz rotuj klucze i sekrety, jeżeli mogły zostać ujawnione.
- Globalny reset haseł wykonuj dopiero wtedy, gdy uzasadnia go skala incydentu i zespół może przeprowadzić go w kontrolowany sposób.
- Odizoluj repozytoria kopii zapasowych, ogranicz do nich dostęp i sprawdź, czy kopie nie zostały zmodyfikowane lub zaszyfrowane.
- Zablokuj wykorzystywaną podatność lub usługę, jeżeli można to zrobić bez zwiększenia ryzyka dla ludzi i procesów krytycznych.
Nie komunikuj się o incydencie przez przejęty kanał
Jeżeli istnieje podejrzenie kompromitacji poczty, komunikatora lub domeny, zespół powinien korzystać z wcześniej uzgodnionego kanału awaryjnego, na przykład numerów telefonów i prywatnej przestrzeni komunikacyjnej przeznaczonej wyłącznie do obsługi kryzysu.
Komunikacja i raportowanie: KSC, CSIRT oraz UODO
Prowadź dwa równoległe tory oceny
Incydent poważny w rozumieniu ustawy o KSC i naruszenie ochrony danych osobowych to nie to samo. Mogą wystąpić razem, ale każde zdarzenie wymaga osobnej kwalifikacji, ma odrębnego adresata i własny moment rozpoczęcia biegu terminu.
| Termin | Działanie | Odbiorca i kanał | Odpowiedzialność wewnętrzna |
|---|---|---|---|
| Niezwłocznie | Uruchomienie zespołu, dziennika incydentu, oceny technicznej i wpływu biznesowego. | Zarząd, IT, pełnomocnik ds. SZBI, IOD i dostawca zewnętrzny. | Koordynator incydentu |
| Do 24 godzin | Wczesne ostrzeżenie po wykryciu incydentu poważnego. Na tym etapie nie trzeba znać wszystkich przyczyn i skutków. | Właściwy CSIRT sektorowy, co do zasady przez System S46. | Osoba wyznaczona do kontaktu z CSIRT i reprezentant podmiotu |
| Do 72 godzin | Zgłoszenie incydentu poważnego z uzupełnioną oceną charakteru, skali, wpływu i podjętych działań. | Właściwy CSIRT sektorowy przez System S46. | Koordynator techniczny i osoba odpowiedzialna za część prawną |
| Do 72 godzin od stwierdzenia naruszenia | Odrębne zgłoszenie naruszenia ochrony danych, jeżeli może ono powodować ryzyko dla praw lub wolności osób. | Prezes UODO. W określonych przypadkach również osoby, których dane dotyczą. | IOD lub osoba odpowiedzialna za ochronę danych |
| W trakcie | Aktualizacje dla CSIRT, zarządu, pracowników, klientów i kontrahentów stosownie do sytuacji. | Adresat zależny od wpływu incydentu i wymogów prawa. | Koordynator komunikacji zatwierdzony przez zarząd |
| Do miesiąca | Sprawozdanie końcowe. Gdy obsługa nadal trwa: sprawozdanie z postępu, a następnie raport końcowy po zakończeniu działań. | Właściwy CSIRT sektorowy przez System S46. | Właściciel procedury wraz z IT i zarządem |
Szczegółowe omówienie kwalifikacji i raportowania znajdziesz w materiale Zgłoszenie incydentu NIS2 – dwa terminy na reakcję. Jeżeli firma nie ma jeszcze aktywnej przestrzeni w Systemie S46, potrzebna jest również wcześniejsza rejestracja podmiotu i osób uprawnionych do działania.
Usunięcie przyczyny, odtwarzanie i wzmożony monitoring
Wracaj do pracy etapami
Odtworzenie usługi przed zamknięciem pierwotnego wektora ataku może doprowadzić do ponownej infekcji. Decyzja o uruchomieniu systemu powinna uwzględniać zarówno wynik analizy technicznej, jak i ryzyko biznesowe.
- Znajdź pierwotny wektor ataku, na przykład złośliwy załącznik, przejęte konto, niezałatany VPN, błędną konfigurację albo podatną aplikację.
- Usuń mechanizmy utrzymania dostępu przez napastnika, załataj podatności i zweryfikuj konfigurację zabezpieczeń.
- Przeprowadź głębokie skanowanie i kontrolę integralności systemów, które mogły mieć kontakt z zaatakowanym środowiskiem.
- Przywracaj dane i usługi wyłącznie ze sprawdzonych kopii wykonanych przed kompromitacją.
- Uruchamiaj usługi według ich krytyczności, po formalnej akceptacji właściciela biznesowego.
- Utrzymuj podwyższony monitoring przez co najmniej 48 godzin lub dłużej, jeżeli uzasadnia to ryzyko, charakter zagrożenia albo krytyczność systemu.
Warunki zgody na odtworzenie systemu
Sprawozdanie końcowe i aktualizacja procedur
Zamknij incydent dowodowo i organizacyjnie
Sprawozdanie końcowe powinno umożliwić odtworzenie przebiegu zdarzenia, ocenę skuteczności reakcji i wykazanie, że zarząd podjął adekwatne działania. Nie może ograniczać się do informacji, że „system został przywrócony”.
- Opisz wpływ incydentu na usługi, procesy, klientów, pracowników, dane i wyniki finansowe.
- Wskaż przyczynę zdarzenia, wektor ataku i podatności wykorzystane przez napastnika.
- Przedstaw chronologię decyzji, działania ograniczające skutki i sposób odtworzenia środowiska.
- Dołącz potwierdzone wskaźniki kompromitacji, wyniki analizy i listę wdrożonych środków zaradczych.
- Oszacuj koszty przestoju, obsługi technicznej, prawnej, komunikacji i utraconych przychodów.
Wprowadź wnioski do codziennego działania
Każdy incydent powinien prowadzić do mierzalnej zmiany. Zarząd zatwierdza plan naprawczy, właścicieli zadań, budżet i terminy realizacji.
- Zaktualizuj polityki bezpieczeństwa, procedurę reagowania i plan ciągłości działania.
- Skoryguj reguły zapór, EDR, SIEM, filtrowania poczty i zarządzania uprawnieniami.
- Zmień zakres monitorowania i retencję logów, jeżeli dane potrzebne do analizy nie były dostępne.
- Zaplanuj szkolenie dla pracowników, administratorów i zarządu oparte na rzeczywistym scenariuszu.
- Sprawdź umowy z dostawcami IT: czas reakcji, obowiązek współpracy, dostęp do logów, odpowiedzialność i zachowanie dowodów.
- Przeprowadź ponowny test procedury po wdrożeniu działań naprawczych.
Kryzysowa książka kontaktowa firmy
Podczas cyberataku zespół nie powinien szukać numerów telefonów w niedostępnej poczcie lub katalogu domenowym. Tabela musi zostać wypełniona przed incydentem, przechowywana w kontrolowanej wersji offline i aktualizowana po każdej zmianie personalnej lub dostawcy.
| Rola w incydencie | Imię i nazwisko | Kontakt (e-mail / telefon) |
|---|---|---|
| Wyznaczony członek zarządu | [Uzupełnij] | [Uzupełnij] |
| Bezpośredni przełożony | [Uzupełnij] | [Uzupełnij] |
| Pełnomocnik ds. SZBI | [Uzupełnij] | [Uzupełnij] |
| Inspektor Ochrony Danych (IOD) | [Uzupełnij] | [Uzupełnij] |
| Zewnętrzny dostawca IT / SOC | [Uzupełnij] | [Uzupełnij] |
Warto dodać także dane ubezpieczyciela cyber, kancelarii, firmy informatyki śledczej, operatora telekomunikacyjnego i kluczowych dostawców chmurowych.
Dokumenty do wykorzystania w organizacji
Pobierz dwie uzupełniające instrukcje i udostępnij je odpowiednim grupom. Procedura dla działu IT porządkuje działania techniczne, a instrukcja dla użytkowników pokazuje pracownikom, jak zachować się po zauważeniu podejrzanego zdarzenia.
FAQ: procedura obsługi incydentu
Czy każda firma 50–200 osób musi zgłaszać incydenty przez System S46?
Nie. Obowiązek raportowania incydentu poważnego w tym trybie dotyczy podmiotów objętych właściwymi przepisami KSC. Wielkość zatrudnienia jest jednym z elementów oceny, ale znaczenie mają również sektor, rodzaj usług, skala działalności i szczególne przesłanki ustawowe.
Kto powinien kierować reakcją na incydent?
Firma powinna wyznaczyć jednego koordynatora posiadającego dostęp do zarządu i możliwość uruchomienia zasobów IT, prawnych oraz komunikacyjnych. Koordynator nie musi sam wykonywać wszystkich działań, ale odpowiada za spójność decyzji, dokumentację i terminy.
Czy po wykryciu ransomware należy natychmiast wyłączyć serwer?
Nie istnieje jedna odpowiedź dla każdego środowiska. Zwykle najpierw izoluje się urządzenie od sieci, zachowując zasilanie i dane ulotne, jeśli jest to bezpieczne. Jeżeli dalsza praca urządzenia zwiększa szkody albo zagraża ludziom lub procesowi przemysłowemu, priorytetem jest ograniczenie zagrożenia.
Czy termin 72 godzin do CSIRT i UODO jest tym samym terminem?
Nie. Zgłoszenie incydentu poważnego do CSIRT i zgłoszenie naruszenia ochrony danych do UODO mają inne podstawy prawne, kryteria i moment rozpoczęcia biegu terminu. Oba tory należy ocenić niezależnie.
Jak często testować procedurę reagowania?
Co najmniej raz w roku oraz po istotnej zmianie systemów, dostawców, struktury firmy albo przepisów. Dodatkowy test powinien odbyć się po poważnym incydencie i wdrożeniu planu naprawczego.
Czy procedura może ograniczyć się do instrukcji działu IT?
Nie. Incydent wpływa na decyzje zarządu, ciągłość procesów, obowiązki regulacyjne, ochronę danych, komunikację i umowy. Procedura musi łączyć działania techniczne, biznesowe, prawne i dowodowe.
Sprawdź, czy procedura zadziała przed prawdziwym atakiem
Podczas bezpłatnej konsultacji możesz omówić strukturę firmy, zakres KSC/NIS2, obecny sposób obsługi incydentów i gotowość zespołu do działania w terminach 24 oraz 72 godzin. Następnym krokiem może być audyt procedury, ćwiczenie scenariuszowe lub przygotowanie dokumentacji dopasowanej do organizacji.