NIS-2 — reporting incydentów w praktyce. 24h early warning, 72h, 1 miesiąc

Trzy fazy raportowania, jedno okno czasowe, które startuje od wykrycia

Art. 23 dyrektywy 2022/2555 (NIS-2) wymaga, żeby podmioty kluczowe i ważne raportowały znaczące incydenty cyberbezpieczeństwa w trzech fazach — z konkretnymi terminami liczonymi od momentu, w którym podmiot dowiedział się o incydencie. Te terminy nie są negocjowalne, nie przesuwają się przez weekendy i nie zatrzymują się na czas wewnętrznego śledztwa.

Dla polskiego MŚP, które znajduje się w zakresie NIS-2, oznacza to konieczność posiadania operacyjnego playbooka — gotowego do uruchomienia w ciągu kilku godzin od pierwszego sygnału alertu. Ten artykuł rozkłada art. 23 na konkretne kroki, ich kontent, adresatów w polskim systemie krajowym i typowe pułapki, w które wpadają firmy po pierwszych incydentach.

Dyrektywa weszła w życie 16 stycznia 2023 r. z terminem transpozycji do prawa krajowego do 17 października 2024 r. W Polsce implementacja przebiega przez nowelizację ustawy o Krajowym Systemie Cyberbezpieczeństwa (KSC) — na dzień publikacji tego artykułu ustawa była procedowana w sejmie i nie jest jeszcze ostatecznie podpisana, ale obowiązki z dyrektywy są bezpośrednio stosowalne wobec państwa członkowskiego.

Art. 23 — kompletna struktura obowiązku

Art. 23 ust. 1 nakłada na podmioty kluczowe i ważne obowiązek bez zbędnej zwłoki powiadomienia właściwego CSIRT lub organu kompetentnego o każdym znaczącym incydencie.

Ust. 2 dodaje obowiązek powiadomienia odbiorców usług o incydencie, jeśli może on negatywnie wpłynąć na świadczenie tych usług — a także o środkach lub działaniach, jakie odbiorcy mogą podjąć w odpowiedzi.

Ust. 3 definiuje, kiedy incydent jest „znaczący”:

spowodował lub mógł spowodować poważne zakłócenia operacyjne lub straty finansowe dla podmiotu;
wpłynął lub mógł wpłynąć na inne osoby fizyczne lub prawne przez spowodowanie znacznych szkód materialnych lub niematerialnych.

Ust. 4 wprowadza trzy fazy raportowania — wczesne ostrzeżenie w 24 godziny, zgłoszenie incydentu w 72 godziny, raport końcowy w 1 miesiąc.

Faza 1 — wczesne ostrzeżenie w 24 godziny

Art. 23 ust. 4 lit. a wymaga wczesnego ostrzeżenia (early warning) bez zbędnej zwłoki — i w każdym przypadku nie później niż w ciągu 24 godzin od momentu, w którym podmiot dowiedział się o znaczącym incydencie.

Kontent early warning jest celowo minimalny — bo na tym etapie podmiot rzadko ma pełną wiedzę. Należy wskazać:

czy istnieje podejrzenie, że incydent jest skutkiem działania bezprawnego lub złośliwego;
czy incydent może mieć wpływ transgraniczny.

Adresatem w Polsce jest właściwy CSIRT na poziomie krajowym lub sektorowym — w praktyce CSIRT NASK dla większości MŚP poza sektorem finansowym, energetycznym i zdrowia (gdzie funkcjonują dedykowane sektorowe CSIRT).

Co istotne — okno startuje od momentu, w którym podmiot dowiedział się, a nie od momentu wystąpienia incydentu. Detekcja po dwóch tygodniach od faktycznego naruszenia nie wydłuża okna do 14 dni i 24 godzin — okno startuje w momencie potwierdzonej detekcji.

Faza 2 — zgłoszenie incydentu w 72 godziny

Art. 23 ust. 4 lit. b: w ciągu 72 godzin od momentu, w którym podmiot dowiedział się o incydencie — szczegółowe zgłoszenie incydentu (incident notification).

Kontent 72-godzinnego zgłoszenia obejmuje:

aktualizację informacji z early warning;
pierwszą ocenę znaczącego incydentu — w tym jego dotkliwość i wpływ;
wskaźniki kompromitacji (IoC), o ile są dostępne;
aktualnie podjęte i planowane środki zaradcze.

Adresat — ten sam CSIRT, do którego wysłano early warning. Wiele krajowych CSIRT-ów wymaga zgłoszenia przez dedykowany portal (w Polsce — portal CSIRT NASK z formularzem).

Jeśli incydent nie został potwierdzony jako znaczący do tego momentu — np. okazuje się, że pierwsza diagnoza była fałszywym alarmem — należy poinformować CSIRT o tej aktualizacji. Nieformalne wycofanie nie istnieje.

Faza 3 — raport końcowy w 1 miesiąc

Art. 23 ust. 4 lit. c: nie później niż 1 miesiąc po zgłoszeniu incydentu z fazy 2 — raport końcowy (final report).

Kontent raportu końcowego:

szczegółowy opis incydentu, w tym jego dotkliwość i wpływ;
typ zagrożenia lub przyczyny, które prawdopodobnie wywołały incydent;
zastosowane i wdrażane środki łagodzące;
w stosownych przypadkach — transgraniczny wpływ incydentu.

Jeśli incydent w momencie raportu końcowego nadal trwa, art. 23 ust. 4 lit. d wymaga raportu o postępach (progress report) i raportu końcowego dopiero po pełnym rozwiązaniu — w ciągu jednego miesiąca od tego momentu.

Powiadomienie odbiorców — art. 23 ust. 2

Osobny obowiązek, niezależny od raportowania do CSIRT — powiadomienie odbiorców usług. Wymagany, gdy incydent może mieć negatywny wpływ na świadczenie usług na rzecz tych odbiorców.

Praktyka: dla MŚP-SaaS oznacza to powiadomienie klientów korporacyjnych mailem lub przez status page — z opisem incydentu, jego wpływu na ich usługę, środków, jakie sami mogą podjąć (np. zmiana haseł, rotacja kluczy API).

Granica między „może mieć wpływ” a „nie ma wpływu” jest często niejasna w pierwszych godzinach. Kierunek dyrektywy jest jednoznaczny — w razie wątpliwości informować, a nie milczeć.

Adresaci w polskim systemie krajowym

Krajobraz CSIRT w Polsce składa się z:

CSIRT NASK — krajowy CSIRT dla większości MŚP i administracji niesektorowej;
CSIRT GOV — administracja rządowa;
CSIRT MON — sektor obronny;
CSIRT sektorowe — wskazywane przez właściwe organy sektorowe (KNF dla finansów, Ministerstwo Zdrowia dla ochrony zdrowia, Ministerstwo Klimatu i Środowiska dla energetyki, Ministerstwo Infrastruktury dla transportu).

Dla MŚP w sektorze ICT, e-commerce, B2B SaaS bez powiązań sektorowych — pierwszy adresat to CSIRT NASK. Numery kontaktowe i procedury zgłoszeń warto mieć w playbooku zanim incydent się wydarzy, a nie po.

Operacyjny playbook — pięć kroków

Krok 1: detekcja. Alert z SIEM, EDR, IDS, security log lub raport od pracownika/klienta. Każdy alert otrzymuje wstępną klasyfikację — istotny czy nieistotny — z timestampem zarejestrowanym w ticket systemie.

Krok 2: triage w pierwszej godzinie. Zespół security ocenia, czy mamy do czynienia z incydentem znaczącym w rozumieniu art. 23 ust. 3. Kryteria: ile usług dotyka, ile danych potencjalnie ujawniono, ile użytkowników, jaka kwota strat finansowych, jaki wpływ transgraniczny.

Krok 3: classification i decyzja o reportingu. Po triage — formalna decyzja: zgłaszamy czy nie. Decyzję podejmuje CISO lub osoba odpowiedzialna za bezpieczeństwo. Decyzja jest dokumentowana z uzasadnieniem — bo w razie późniejszej kontroli organu nadzorczego trzeba pokazać, dlaczego coś nie zostało zgłoszone.

Krok 4: notification — wczesne ostrzeżenie w 24h. Wysłanie wczesnego ostrzeżenia do właściwego CSIRT — z minimalnym kontentem. Równolegle uruchomienie procedury wewnętrznego dochodzenia, izolacji systemów, zabezpieczenia logów na potrzeby śledztwa.

Krok 5: post-mortem i final report. Po stabilizacji — pełny post-mortem z root cause analysis, lessons learned, mapą luk w obecnym stacku bezpieczeństwa. Z tego materiału powstaje raport końcowy do CSIRT i wewnętrzna aktualizacja playbooka.

Co zbudować pre-emptive

Wszystko, co da się zbudować przed incydentem, jest tańsze niż próba zbudowania tego w trakcie. Minimum operacyjne dla MŚP:

Zespół incident response z zdefiniowanymi rolami. Kto jest incident commander, kto komunikuje z klientami, kto z CSIRT, kto dokumentuje. Imiona i nazwiska, nie funkcje — bo „CTO” w środę o 2 w nocy może być nieosiągalny.
Playbooki per scenariusz. Ransomware, data breach z exfiltracją, DDoS, supply-chain attack, kompromitacja konta uprzywilejowanego. Każdy z osobną listą pierwszych kroków, kontaktów i szablonów komunikacji.
Kontakty CSIRT pre-loaded. Numer alarmowy CSIRT NASK, sektorowego CSIRT (jeśli dotyczy), kontakt z prawnikiem specjalizującym się w cyber. W papierowej kopii, bo Twoje VPN może być zablokowane przez sam incydent.
Logi z retencją proporcjonalną. Bez logów nie da się napisać raportu końcowego. Minimum sześć miesięcy dla logów aplikacyjnych, dwanaście dla systemów krytycznych, z immutable storage (write-once) dla logów bezpieczeństwa.

QA10 — gdzie to sprawdzamy

W Audytcie AiP weryfikujemy gotowość playbooka klienta pod art. 23 NIS-2 — w tym test stop-watch (czy zespół zdąży z wczesnym ostrzeżeniem w 24h przy realnym scenariuszu) i kompletność stacku logowania pod raport końcowy.