NIS2: zgłaszanie incydentów – terminy i praktyka, czyli zegar, który tyka zanim ktokolwiek zauważy

Wyobraź sobie, że w piątek o 16:00 ktoś z działu IT dzwoni, że „coś dziwnie działa” na serwerze produkcyjnym. Zanim zdążysz zapytać, czy to ransomware, czy fałszywy alarm, zegar NIS2 już tyka – a Ty jeszcze nie wiesz, czy w ogóle masz incydent poważny, czy tylko awarię. I to jest właśnie moment, w którym większość znanych mi wdrożeń NIS2 rozsypuje się nie na etapie dokumentacji, ale na etapie decyzyjnym.

Zegar zaczyna tykać, zanim ktokolwiek zdąży powiedzieć „incydent”

Dyrektywa NIS2, a konkretnie jej artykuł 23, jest brutalnie konkretna: wczesne ostrzeżenie w ciągu 24 godzin od powzięcia wiedzy o incydencie poważnym, zgłoszenie incydentu w ciągu 72 godzin, raport końcowy w ciągu miesiąca od rozwiązania incydentu. Trzy różne terminy, trzy różne poziomy szczegółowości, jeden wspólny mianownik – wszystkie liczone nie od momentu, w którym ktoś potwierdzi atak, ale od momentu, w którym organizacja „dowiedziała się” o incydencie. To słowo „dowiedziała się” jest zmorą prawników i audytorów, bo nie ma jednej definicji operacyjnej. W praktyce oznacza to, że musisz mieć procedurę, która mówi, kto w firmie jest uprawniony do stwierdzenia „mamy incydent poważny” i kiedy ten moment następuje. Jeśli tego nie ma, 24 godziny mijają na wewnętrznej dyskusji, czy to na pewno incydent, czy tylko „dziwne zachowanie systemu”.

Wartość wczesnego ostrzegania jest głównie informacyjna. Wskazujesz właściwy CSIRT sektorowy, informujesz, czy incydent mógł być wynikiem działania celowego – na przykład cyberataku – i czy dotyczy innych państw członkowskich. Nie musisz jeszcze znać zakresu szkód ani wektora ataku. To ma być szybki sygnał: „coś się dzieje, jeszcze nie wiemy co”. Problem w tym, że wiele organizacji traktuje ten etap jak coś wstydliwego – boimy się wysłać ostrzeżenie, które potem okaże się fałszywym alarmem. A to jest dokładnie odwrotna logika niż intencja dyrektywy: lepiej wysłać wczesne ostrzeżenie i później je skorygować, niż nie wysłać go wcale i narazić się na sankcje za naruszenie obowiązków.

72 godziny to nie czas na diagnozę, to czas na raport z tym, co wiesz

Zgłoszenie incydentu w ciągu 72 godzin jest już bardziej wymagające. Musi zawierać wstępną ocenę dotkliwości i skutków incydentu oraz, jeśli to możliwe, wskaźniki naruszenia integralności systemów. To nie jest raport dochodzeniowy – to raport o tym, co wiesz na tym etapie. I tu pojawia się najczęstszy błąd: organizacje próbują w 72 godziny zmieścić analizę forensyczną, której nikt nie jest w stanie zrobić tak szybko. Efekt jest taki, że raport jest albo spóźniony, albo niedokładny, albo – co gorsza – napisany językiem, który nie mówi nic konkretnego, bo dział IT boi się przyznać, że nie wie, co się stało. Lepszy raport z trzema niewiadomymi niż raport, który udaje pełny obraz.

Raport końcowy w ciągu miesiąca od rozwiązania incydentu to z kolei moment, w którym organizacja musi pokazać, że wyciągnęła wnioski. I tu wracamy do mojego podwórka – audytu. Bo jeśli nie masz udokumentowanego przeglądu poincydentalnego, który wskazuje działania korygujące, to przy najbliższym audycie ISO 27001 albo w ramach nadzoru UKSC nie będziesz miał czym się podeprzeć. Terminy NIS2 są tak skonstruowane, żeby wymusić nie tylko reakcję, ale i refleksję. A refleksja po incydencie jest dokładnie tym, co większość firm odkłada na „kiedyś, jak będzie czas”.

Przykład z praktyki

Zespół bezpieczeństwa w firmie logistycznej obsługującej kilka platform e-commerce zauważył w poniedziałek rano nietypowy ruch wychodzący z jednego z serwerów aplikacyjnych. Monitoring wychwycił to automatycznie, ale nikt nie miał jasnej instrukcji, co zrobić z alertem. Administrator uznał, że to „pewnie backup”, i zamknął zgłoszenie. Dopiero w środę, gdy klient zgłosił problem z logowaniem, okazało się, że doszło do eksfiltracji danych. Od momentu, w którym organizacja realnie dowiedziała się o incydencie – czyli od poniedziałkowego alertu – minęło ponad 48 godzin, zanim ktokolwiek pomyślał o NIS2. Wczesne ostrzeżenie nie zostało wysłane w ogóle, a zgłoszenie incydentu trafiło do CSIRT dopiero po tygodniu, już po interwencji prawnika.

Co poszło nie tak? Nie brakowało procedury – ona istniała, miała nawet ładną tabelkę z terminami. Zabrakło jednego zdania: kto ma prawo i obowiązek zakwalifikować alert jako incydent poważny. W praktyce okazało się, że każdy zakładał, że zrobi to ktoś inny. To klasyczny problem rozmytej odpowiedzialności, który w NIS2 kosztuje znacznie więcej niż w zwykłym IT, bo dochodzą terminy ustawowe i ryzyko sankcji. Gdyby ta sama firma miała jasny próg decyzyjny – na przykład „każdy alert o nietypowym ruchu wychodzącym powyżej X MB jest automatycznie eskalowany do zespołu bezpieczeństwa w ciągu 30 minut” – zegar zacząłby tykać od właściwego momentu, a nie od momentu, w którym ktoś przypadkiem zauważył problem.

Co z tego wynika

Terminy NIS2 nie wyznaczają tempa twojej reakcji technicznej – wyznaczają tempo twojej decyzyjności. Zanim zaczniesz pisać procedury zgłaszania incydentów, ustal jedną rzecz: kto w twojej organizacji ma władzę powiedzenia „to jest incydent poważny” i jakie są twarde przesłanki, które go do tego upoważniają. Bez tego nawet najlepiej napisana procedura będzie tylko dokumentem, który ładnie wygląda w segregatorze i na audycie, ale w momencie prawdziwego zdarzenia nikt nie będzie wiedział, kiedy zaczął się czas.