Logowanie i monitorowanie w NIS 2 na podstawie Artykułu 21(2)(b)
Logowanie to warstwa widoczności obsługi incydentów. Artykuł 21(2)(b) jest miejscem, w którym żyje obowiązek, CIR §3.2 wymienia dwanaście typów zdarzeń i zasady operacyjne, a Niemcy umieszczają tę samą regułę w §30(2)(2) BSIG.
Krótka wersja
Logowanie i monitorowanie nie są odrębnym obowiązkiem w ramach NIS 2. Mieszczą się one wewnątrz środka obsługi incydentów z Artykułu 21(2)(b). Logika jest prosta: jeśli nie widzisz, co dzieje się w Twojej sieci, nie wykryjesz incydentu bezpieczeństwa i nie zdołasz go opanować.
CIR (EU) 2024/2690 §3.2 uzupełnia szczegóły. Wymienia dwanaście typów zdarzeń, które musisz logować, ustala zasady dotyczące alarmów i wykwalifikowanej reakcji, ustala określony okres retencji oraz wymaga systemów zsynchronizowanych czasowo i redundantnego monitorowania. To minimum dla sektorów wymienionych w Załączniku CIR.
Niemcy umieszczają tę samą regułę w §30(2)(2) BSIG. Praktyczną podstawą jest IT-Grundschutz OPS.1.1.5 'Protokollierung' oraz DER.1 'Detektion'. Ta strona omawia dyrektywę, uzupełniające rozporządzenie UE oraz niemiecką transpozycję w tej kolejności.
Artykuł 21(2)(b) Dyrektywy NIS 2 (2022/2555)
Obsługa incydentów.
To punkt (b) na liście dziesięciu środków cyberbezpieczeństwa, które każdy podmiot kluczowy i ważny musi wdrożyć. CIR §3 następnie go operacjonalizuje. Logowanie i monitorowanie mieszczą się wewnątrz §3.2.
CIR (EU) 2024/2690, Załącznik §3.2.1
Odpowiednie podmioty ustanawiają procedury i stosują narzędzia do monitorowania i logowania działań w swoich sieciach i systemach informatycznych, tak aby zdarzenia, które można uznać za incydenty bezpieczeństwa, mogły zostać wykryte i poddane działaniom w celu ograniczenia ich skutków.
Ponieważ jest to rozporządzenie (a nie dyrektywa), stanowi bezpośrednio wiążące prawo UE. §3.2 dzieli się następnie na siedem podpunktów obejmujących typy zdarzeń do logowania, alarmowanie, retencję, synchronizację czasu i redundancję. Transpozycja krajowa nie jest potrzebna.
§30(2)(2) BSIG (Niemcy)
Obsługa incydentów.
Niemcy kopiują tekst UE słowo w słowo. Praktyczne 'jak' przychodzi przez IT-Grundschutz: OPS.1.1.5 'Protokollierung' dla projektu logowania oraz DER.1 'Detektion' dla strony alarmowania i reagowania.
Loguj dwanaście typów zdarzeń
Zbuduj listę względem swojej inwentaryzacji aktywów. Tam, gdzie to właściwe, rejestruj: przychodzący i wychodzący ruch sieciowy, zmiany użytkowników i uprawnień, dostęp do systemów i aplikacji, zdarzenia uwierzytelniania, całą aktywność uprzywilejowaną i administracyjną, dostęp do krytycznych plików konfiguracyjnych lub kopii zapasowych, logi narzędzi bezpieczeństwa (AV, IDS, zapora), wykorzystanie zasobów systemowych, dostęp fizyczny, użycie sprzętu sieciowego, aktywację lub wstrzymanie samych logów oraz zdarzenia środowiskowe.
Przegląd, alarm, wykwalifikowana reakcja
Zbieranie logów nie wystarczy. Sprawdzaj je w regularnym rytmie pod kątem nietypowych lub niepożądanych trendów. Tam, gdzie to właściwe, ustaw progi. Gdy próg zostanie przekroczony, uruchom automatyczny alarm. I upewnij się, że ktoś wykwalifikowany faktycznie reaguje na czas. Przechowywanie bez przeglądu nie jest logowaniem w rozumieniu §3.2.
Chroń, przechowuj, synchronizuj czas, zapewnij redundancję
Same logi są dowodem. Przechowuj je przez określony okres retencji, chroń przed nieuprawnionym dostępem i zmianami, synchronizuj czas wszystkich systemów, aby zdarzenia można było skorelować, i prowadź system monitorowania w sposób redundantny. Monitorowanie systemu monitorowania jest samo w sobie niezależne od systemów, które monitoruje.
Logi to aktywa, a nie produkt uboczny
§3.2.5 traktuje logi jak dane krytyczne. Określony okres retencji, ochrona przed manipulacją, ochrona przed nieuprawnionym dostępem. Jeśli napastnik może usunąć logi pokazujące, co zrobił, obowiązek logowania nie jest spełniony. Dlatego też §3.2.3(k) wyraźnie wymienia 'aktywację, dezaktywację lub wstrzymanie' logów jako zdarzenie, które musisz logować.
Przegląd logów to obowiązek, a nie miły dodatek
§3.2.4 wymaga regularnych kontroli pod kątem nietypowych trendów, progów tam, gdzie to właściwe, automatycznych alarmów przy przekroczeniu progu oraz terminowej wykwalifikowanej reakcji. SIEM, na który nikt nie patrzy, tego nie spełnia. Audytor zapyta, kto przeglądał które alarmy, kiedy i co z nimi zrobił.
BSI / IT-Grundschutz OPS.1.1.5 + DER.1
BSI wskazuje IT-Grundschutz jako praktyczną drogę. OPS.1.1.5 'Protokollierung' jest miejscem, gdzie żyje projekt logowania (co logować, retencja, ochrona). DER.1 'Detektion' obejmuje stronę alarmowania i reagowania (rytm przeglądu, reguły SIEM, wykwalifikowana obsługa). Te dwa razem odwzorowują się na CIR §3.2.
ENISA Technical Implementation Guidance
TIG ENISA podaje konkretne przykłady dowodów dla §3.2: szablony polityki logowania, przykładowe progi alarmów, domyślne wartości retencji oraz mapowanie na ISO/IEC 27001:2022 Załącznik A (A.8.15 Logowanie, A.8.16 Działania monitorujące). Jeśli już prowadzisz ISO 27001, ponownie wykorzystujesz większość zabezpieczeń.
Krajowe ustawy transponujące
Każde państwo członkowskie ma własną transpozycję (Holandia: Cyberbeveiligingswet, Austria: NISG, Belgia: NIS2-Wet). Obowiązek z §3.2 jest taki sam, ponieważ CIR jest bezpośrednio stosowany. Co się różni: z którym organem krajowym rozmawiasz oraz jak lokalnie prowadzone są kanały zgłaszania i rytmy audytów.
Przechowujemy wszystkie logi na zawsze, więc jesteśmy zabezpieczeni.
§3.2.5 wymaga określonego okresu retencji, a nie nieskończonego. Przechowywanie wszystkiego na zawsze to problem ochrony danych (Art. 5(1)(e) GDPR ograniczenie przechowywania) i problem kosztowy. Ustal okno retencji dla każdego typu logu, zapisz je, uzasadnij względem swojego obrazu ryzyka i się go trzymaj.
SIEM to ma, więc jest w porządku.
Blisko, ale nie do końca. §3.2.4 nie wymaga tylko przechowywania. Wymaga regularnego przeglądu, progów tam, gdzie to właściwe, automatycznych alarmów przy przekroczeniu oraz wykwalifikowanej osoby, która faktycznie reaguje. SIEM, który działa bez reguł lub z regułami, których nikt nie dostraja, nie spełnia §3.2.4.
Logujemy aktywność użytkowników, ale nie aktywność administratorów.
§3.2.3(e) jest jednoznaczny: cały uprzywilejowany dostęp do systemów i aplikacji oraz działania kont administracyjnych. Administratorzy to użytkownicy o największym wpływie w Twojej sieci. Nielogowanie ich to luka, którą audytor znajdzie pierwszą.
Co widzimy w praktyce: większość firm Mittelstandu ma logi zapory i logi Active Directory. Rzadko mają systematycznie pokryte dwanaście typów zdarzeń z §3.2.3. Dostęp uprzywilejowany, zmiany w plikach konfiguracyjnych oraz dostęp fizyczny to trzy zwykłe luki.
Najtańsza naprawa: zbuduj listę z §3.2.3 względem swojej inwentaryzacji aktywów (RSK 2.2), kieruj wszystko do jednego miejsca (centralne repozytorium logów lub mały SIEM), ustaw progi na zdarzeniach o wysokiej wartości i przeglądaj co tydzień. Nie potrzebujesz zarządzanego SOC pierwszego dnia. Potrzebujesz kogoś, kto patrzy na alarmy i wie, co robić.
Moduł INC obejmuje strategię logowania z §3.2: które typy zdarzeń logujesz, względem których aktywów, z jakim oknem retencji. Piszesz to raz, podpisujesz, i staje się Twoją gotową do audytu polityką logowania.
Moduł EFF obejmuje stronę przeglądu z §3.2.4: progi alarmów, rytm przeglądu, dowody wykwalifikowanej reakcji. Podpisy i ścieżka audytu pokazują audytorowi, że ktoś patrzył na alarmy i działał na ich podstawie. Bez stosu arkuszy kalkulacyjnych. Bez drugiego narzędzia.
- Dyrektywa (EU) 2022/2555 (NIS 2), Artykuł 21(2)(b) — eur-lex.europa.eu/eli/dir/2022/2555/oj
- Rozporządzenie wykonawcze Komisji (EU) 2024/2690 (CIR), Załącznik §3.2 — eur-lex.europa.eu/eli/reg_impl/2024/2690/oj
- Ustawa o BSI (BSIG), §30(2)(2) w brzmieniu zmienionym Ustawą o wdrożeniu NIS2 i wzmocnieniu cyberbezpieczeństwa
- IT-Grundschutz Kompendium, OPS.1.1.5 'Protokollierung' oraz DER.1 'Detektion' — bsi.bund.de/grundschutz
- ENISA Technical Implementation Guidance dla CIR (EU) 2024/2690 (stan na maj 2026)