Obsługa incydentów NIS 2 zgodnie z Artykułem 21(2)(b)
Artykuł 21(2)(b) to obowiązek wewnętrzny: wykryć, powstrzymać, odzyskać, udokumentować, wyciągnąć wnioski. Artykuł 23 to obowiązek zewnętrzny: powiadomić BSI lub swój krajowy CSIRT. Dwa różne obowiązki, często mylone. CIR (UE) 2024/2690 §3 precyzuje ten wewnętrzny.
Wersja skrócona
Obsługa incydentów to punkt (b) na liście dziesięciu obowiązków cyberbezpieczeństwa z Artykułu 21(2). Dotyczy tego, co robisz wewnątrz firmy, gdy coś idzie nie tak: wykryć to, powstrzymać, odzyskać, spisać, co się stało, wyciągnąć wnioski.
CIR (UE) 2024/2690 §3 uzupełnia szczegóły w sześciu podsekcjach: §3.1 pisemna koncepcja obsługi incydentów, §3.2 monitorowanie i logowanie, §3.3 wewnętrzna eskalacja zdarzeń, §3.4 klasyfikacja, §3.5 samo reagowanie (powstrzymanie, eradykacja, odtworzenie), §3.6 przegląd poincydentalny. Jeśli prowadzisz DNS, chmurę, centrum danych, MSP lub jakikolwiek inny sektor z Załącznika CIR, wiąże Cię to bezpośrednio.
Niemcy umieszczają ten sam obowiązek w prawie krajowym poprzez §30(2)(2) BSIG. Sformułowanie brzmi 'Bewältigung von Sicherheitsvorfällen', te same słowa co w dyrektywie. Ta strona omawia dyrektywę, unijne rozporządzenie wykonawcze i niemiecką transpozycję w tej kolejności.
Artykuł 21(2)(b) dyrektywy NIS 2 (2022/2555)
Obsługa incydentów.
Punkt (b) na liście dziesięciu środków cyberbezpieczeństwa. Dwa słowa w tekście dyrektywy. CIR §3 przekuwa te dwa słowa w szczegóły operacyjne. Ważne: jest to wewnętrzny obowiązek obsługi. Zewnętrzny obowiązek powiadomienia CSIRT mieści się w Artykule 23 i jest oddzielną stroną.
CIR (UE) 2024/2690, Załącznik §3
Do celów Artykułu 21(2)(b) dyrektywy (UE) 2022/2555 odnośne podmioty ustanawiają i wdrażają politykę obsługi incydentów, określającą role, zakresy odpowiedzialności i procedury terminowego wykrywania, analizy, powstrzymywania lub reagowania, odtwarzania, a także dokumentowania i zgłaszania incydentów.
Ponieważ jest to rozporządzenie, jest bezpośrednio wiążącym prawem UE. Nie jest potrzebna transpozycja krajowa. Załącznik §3 dzieli obowiązek na sześć podsekcji: koncepcja (§3.1), logowanie (§3.2), eskalacja wewnętrzna (§3.3), klasyfikacja (§3.4), reagowanie (§3.5), przegląd poincydentalny (§3.6).
§30(2)(2) BSIG (Niemcy)
Bewältigung von Sicherheitsvorfällen.
Niemcy kopiują brzmienie dyrektywy słowo w słowo. Treść jest identyczna z Artykułem 21(2)(b). BSI wykorzystuje następnie moduły IT-Grundschutz (w szczególności DER.2 'Vorfall-Bewältigung'), aby pokazać, jak pisemna koncepcja obsługi incydentów wygląda w praktyce.
Pisemna koncepcja obsługi incydentów
Spisz, kto robi co, gdy coś idzie nie tak. Role, zakresy odpowiedzialności, kroki wykrywania, analizy, powstrzymywania, odtwarzania, dokumentowania i wewnętrznego zgłaszania. CIR §3.1.1 wymaga, aby koncepcja istniała przed incydentem, a nie po nim. Organ zarządzający musi ją zatwierdzić.
Monitorowanie i logowanie
Nie da się obsłużyć tego, czego nie widać. CIR §3.2 wymienia dwanaście typów zdarzeń, które musisz logować (próby logowania, zmiany uprawnień, wykrycia złośliwego oprogramowania, anomalie sieciowe i inne). Logi muszą być odporne na manipulacje i przechowywane wystarczająco długo, aby wspierać analizę. To jest warstwa wykrywania.
Fazy reagowania: powstrzymanie, eradykacja, odtworzenie
CIR §3.5 dzieli reagowanie na trzy fazy. Powstrzymanie zatrzymuje rozprzestrzenianie się incydentu. Eradykacja usuwa pierwotną przyczynę. Odtworzenie przywraca systemy do znanego dobrego stanu. Każda faza musi być dokumentowana na bieżąco, aby §3.6 (przegląd poincydentalny) miał z czym pracować.
Obsługa wewnętrzna to nie zgłaszanie zewnętrzne
Artykuł 21(2)(b) to to, co robisz wewnątrz firmy. Artykuł 23 to to, co mówisz regulatorowi (wczesne ostrzeżenie w 24 godziny, powiadomienie o incydencie w 72 godziny, raport końcowy w jeden miesiąc do BSI lub Twojego krajowego CSIRT). Dwa oddzielne obowiązki. Wykonanie zgłaszania nie zwalnia z obsługi, a wykonanie obsługi nie zwalnia ze zgłaszania.
Przegląd poincydentalny wraca do zarządzania ryzykiem
CIR §3.6 zamyka pętlę. Wnioski z każdego incydentu wracają do ram zarządzania ryzykiem z CIR §2. Nowe ryzyka są dodawane, plany postępowania aktualizowane, środki kontroli korygowane. To jest cykl PDCA. Incydent, który obsłużysz, ale z którego nie wyciągniesz wniosków, to pół roboty.
BSI / §30(2)(2) BSIG
BSI wymienia obsługę incydentów w Infopakete jako drugi z dziesięciu środków z Artykułu 21(2). Niemiecka transpozycja używa tego samego sformułowania co dyrektywa. BSI wskazuje moduł IT-Grundschutz DER.2 ('Vorfall-Bewältigung') jako praktyczną drogę. DER.2 przeprowadza Cię przez koncepcję, plan działania (playbook), role i przegląd poincydentalny.
Wytyczne techniczne ENISA dotyczące wdrażania
TIG ENISA bierze CIR §3 i pokazuje, jak dowody wyglądają w praktyce: pisemna koncepcja, plan działania, zapisy symulacji, notatki z przeglądu poincydentalnego. Mapuje też §3 na ustalone środki kontroli w ISO/IEC 27001:2022 (klauzula A.5.24 do A.5.28) i NIST CSF 2.0 (funkcje Respond i Recover), więc istniejąca certyfikacja daje Ci przewagę na starcie.
Krajowe ustawy transponujące
Każde państwo członkowskie ma własną ustawę transponującą (Niderlandy: Cyberbeveiligingswet, Austria: NISG, Belgia: NIS2-Wet). Obowiązek jest taki sam, ponieważ dyrektywa ustanawia jeden ogólnounijny standard. Co się różni: z którym CSIRT rozmawiasz na potrzeby zgłaszania z Artykułu 23 oraz jak każdy krajowy organ formułuje praktyczne wytyczne.
Zgłaszamy do BSI, gdy coś się dzieje, więc jesteśmy zabezpieczeni.
To obejmuje Artykuł 23, a nie Artykuł 21(2)(b). Zgłaszanie do CSIRT to obowiązek zewnętrzny. Artykuł 21(2)(b) to ten wewnętrzny: wykryć, powstrzymać, odzyskać, udokumentować, przejrzeć. Oba muszą istnieć. Audytor poprosi o pokazanie koncepcji obsługi incydentów (CIR §3.1) ponad rejestrem zgłoszeń z Artykułu 23.
Napiszemy plan działania, gdy coś się stanie.
CIR §3.1.1 jest jednoznaczny: koncepcja musi być 'ustanowiona i wdrożona' przed incydentem. Role, zakresy odpowiedzialności, procedury, wszystko na papierze, zatwierdzone przez kierownictwo. Pisanie tego w trakcie incydentu to nie obsługa, to improwizacja. Audytorzy sprawdzają najpierw datowaną, podpisaną koncepcję.
Zespół IT się tym zajmuje, to wystarczy.
CIR §3.1.1 wymaga udokumentowanych ról i zakresów odpowiedzialności. Kto deklaruje incydent. Kto decyduje o powstrzymaniu. Kto rozmawia z działem prawnym. Kto zatwierdza odtworzenie. Organ zarządzający musi zatwierdzić koncepcję. 'Zespół IT się tym zajmuje' to nie struktura, to założenie.
Typowa luka w Mittelstandzie to dokumentacja, a nie zdolność. Wykrywanie się dzieje (ktoś zauważa, IT bada, problem zostaje naprawiony). Dokumentacja nie. Bez datowanego zapisu, kto co zrobił, audytor nie ma jak sprawdzić, że §3 został zachowany. Rozwiązaniem jest najpierw zbudować plan działania, potem symulować dwa razy w roku, a następnie uchwycić wnioski w szablonie przeglądu poincydentalnego.
Dwie symulacje rocznie to liczba, na której ląduje większość praktyków, z którymi rozmawiamy. Jedna tabletop (ludzie wokół stołu, przechodzący plan działania przez scenariusz), jedna techniczna (kontrolowane odtworzenie z kopii zapasowej, ćwiczenie reagowania na phishing, coś, co ćwiczy narzędzia). Chodzi o znalezienie luk, zanim zrobi to audytor lub zanim zrobi to prawdziwy incydent. Proporcjonalność z Artykułu 21(1) pozwala dostosować skalę symulacji do Twojej wielkości i obrazu ryzyka; nie pozwala ich pomijać.
Wbudowaliśmy CIR §3 w platformę jako moduł INC. Rejestrujesz incydent, uchwytujesz klasyfikację zgodnie z §3.4, przechodzisz przez fazy reagowania (powstrzymanie, eradykacja, odtworzenie) ze znacznikami czasu i przeprowadzasz przegląd poincydentalny na końcu. Ślad audytowy rejestruje każdy krok. Bez stosu arkuszy kalkulacyjnych.
Przegląd poincydentalny z §3.6 to część, którą pomija większość zespołów. Uczyniliśmy z niego pole wymagane, zanim incydent będzie można zamknąć: co poszło nie tak, co zadziałało, jakie zmiany wracają do ram ryzyka z CIR §2. Zgłaszanie z Artykułu 23 (24h / 72h / jeden miesiąc) to oddzielny moduł, który korzysta z tego samego rekordu incydentu, więc nie wpisujesz faktów dwa razy.
- Dyrektywa (UE) 2022/2555 (NIS 2), Artykuł 21(2)(b) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Rozporządzenie wykonawcze Komisji (UE) 2024/2690 (CIR), Załącznik §3 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Ustawa BSI (BSIG), §30(2)(2) w brzmieniu nadanym przez ustawę wdrażającą NIS2 i wzmacniającą cyberbezpieczeństwo
- Moduł BSI IT-Grundschutz DER.2 'Vorfall-Bewältigung' — bsi.bund.de/grundschutz
- Wytyczne techniczne ENISA dotyczące wdrażania CIR (UE) 2024/2690, mapowanie §3 na ISO/IEC 27001:2022 i NIST CSF 2.0