Jak przygotować się do NIS2 bez luk w dowodach

Jak przygotować się do NIS2: plan audytu, remediacji i dowodów, który łączy wymagania zarządcze z kontrolą środowisk IT, chmury i OT i raportowaniem.

Awaria systemu produkcyjnego, nieautoryzowany dostęp do kont uprzywilejowanych albo wyciek danych od dostawcy nie są już wyłącznie problemem działu IT. Dla organizacji objętej NIS2 stają się zdarzeniami, które mogą wpływać na ciągłość usług, obowiązki raportowe, odpowiedzialność zarządu i relację z regulatorem. Pytanie, jak przygotować się do NIS2, nie powinno więc zaczynać się od zakupu narzędzia ani od aktualizacji jednej polityki. Punktem wyjścia jest ustalenie, czy organizacja potrafi wykazać kontrolę nad realną ekspozycją i czy umie przeprowadzić kontrolowaną remediację, zanim incydent wymusi działania pod presją czasu.

Dyrektywa NIS2 podnosi poprzeczkę nie dlatego, że wymaga większej liczby dokumentów. Wymaga powiązania decyzji zarządczych, procesów bezpieczeństwa, stanu środowiska technicznego i dowodów ich działania. Organizacja musi umieć odpowiedzieć na proste, lecz wymagające pytania: które usługi są krytyczne, od czego zależą, gdzie znajdują się ich słabe punkty, kto podejmuje decyzje podczas incydentu i jak szybko można przedstawić wiarygodne informacje właściwym osobom.

Jak przygotować się do NIS2: zacząć od zakresu i odpowiedzialności

Pierwszym błędem jest założenie, że NIS2 dotyczy wyłącznie zespołu cyberbezpieczeństwa. W praktyce zakres oceny obejmuje procesy biznesowe, usługi cyfrowe, infrastrukturę IT, środowiska chmurowe, dostawców oraz - w sektorze produkcyjnym i infrastrukturalnym - sieci OT/ICS. Trzeba ustalić, które podmioty z grupy, lokalizacje, systemy i usługi wchodzą do zakresu regulacyjnego oraz jaki organ może oczekiwać określonych informacji.

Dyrektywa wyznacza ramy, jednak szczegółowe obowiązki trzeba zawsze odnieść do aktualnych przepisów krajowych, w tym regulacji wdrażających NIS2 do polskiego porządku prawnego, oraz do klasyfikacji organizacji. Nie warto budować programu wyłącznie na prezentacji o dyrektywie lub ogólnej checkliście. Właściwy zakres zależy między innymi od sektora, wielkości podmiotu, roli w łańcuchu usług oraz krytyczności świadczonych funkcji.

Równolegle należy formalnie przypisać odpowiedzialność. Zarząd nie musi zatwierdzać reguł filtrowania ruchu sieciowego, ale powinien zatwierdzić model zarządzania ryzykiem, priorytety inwestycyjne, akceptację ryzyka rezydualnego oraz zasady eskalacji. CISO, CIO, właściciele usług, właściciele ryzyka, compliance i liderzy operacyjni muszą wiedzieć, kto odpowiada za decyzję, wykonanie, weryfikację i dowód. Bez tego incydent kończy się serią spotkań, a nie sprawnym triage według SLA.

Audyt luk powinien badać stan faktyczny, nie deklaracje

Dojrzałość NIS2 warto oceniać w dwóch warstwach. Pierwsza to warstwa zarządczo-procesowa: polityki, role, rejestry ryzyka, ciągłość działania, zarządzanie dostawcami, procedury incydentowe i szkolenia. Druga jest techniczna: inwentaryzacja aktywów, konfiguracje, tożsamość, podatności, logowanie, kopie zapasowe, segmentacja i zdolność wykrywania zdarzeń.

Sama obecność polityki nie jest dowodem jej stosowania. Jeżeli dokument przewiduje kwartalny przegląd kont uprzywilejowanych, audyt powinien sprawdzić próbkę rzeczywistych przeglądów, decyzji o odebraniu dostępów i wyjątków. Jeżeli istnieje proces zarządzania podatnościami, trzeba zweryfikować pokrycie skanowaniem, czas od wykrycia do naprawy, wyjątki zaakceptowane przez właściciela ryzyka oraz skuteczność retestów. To różnica między zgodnością deklaratywną a zgodnością możliwą do obrony.

Dobry audyt luk nie tworzy listy kilkuset zaleceń o identycznej wadze. Łączy ustalenia z procesami krytycznymi i scenariuszami zagrożeń. Krytyczna podatność na serwerze obsługującym planowanie produkcji, system płatności lub zdalny dostęp do OT ma inny priorytet niż podobna luka w odizolowanym środowisku testowym. Priorytety powinny uwzględniać ekspozycję, możliwość wykorzystania, wartość usługi, zależności i wykonalność naprawy.

Inwentaryzacja jest warunkiem kontroli

W wielu organizacjach CMDB, narzędzia EDR, systemy skanowania podatności i zasoby chmurowe pokazują różne obrazy środowiska. To nie jest problem administracyjny. Nieznany serwer, niezarządzany tenant, konto serwisowe bez właściciela lub brama zdalnego dostępu poza monitoringiem są bezpośrednią luką w zarządzaniu ryzykiem.

Należy uzgodnić minimalny model ewidencji aktywów: właściciel, funkcja biznesowa, klasyfikacja krytyczności, lokalizacja, system operacyjny lub usługa, zależności, poziom ekspozycji oraz stan monitoringu. W środowiskach OT inwentaryzację trzeba prowadzić ostrożnie. Agresywne skanowanie może zakłócić urządzenia przemysłowe, dlatego często właściwsze są pasywne metody rozpoznania, analiza konfiguracji i uzgodnione okna zmian.

Zbuduj program remediacji, a nie katalog problemów

Po ocenie luk organizacja potrzebuje planu, który da się wykonać bez destabilizowania usług. Najpierw należy wyznaczyć kilka ścieżek remediacji z konkretnymi właścicielami, terminami i kryteriami zamknięcia. Zwykle obejmują one tożsamość i dostęp uprzywilejowany, zarządzanie podatnościami, wykrywanie i obsługę incydentów, odporność kopii zapasowych, segmentację sieci oraz kontrolę dostawców.

Warto rozdzielić działania natychmiastowe od zmian architektonicznych. Natychmiast można ograniczyć publiczną ekspozycję paneli administracyjnych, usunąć nieużywane konta, wprowadzić MFA dla dostępu zdalnego, uzupełnić krytyczne logi i zamknąć podatności z aktywną ścieżką ataku. Segmentacja OT, przebudowa zarządzania tożsamością lub migracja systemu kopii zapasowych będą natomiast projektami wielomiesięcznymi. Ich opóźnienie może być uzasadnione, lecz ryzyko musi mieć właściciela, plan kompensacyjny i datę ponownej oceny.

Mierniki powinny pokazywać zmianę ryzyka, a nie aktywność zespołu. Liczba zamkniętych zgłoszeń jest mniej użyteczna niż odsetek krytycznych aktywów objętych EDR, czas remediacji podatności krytycznych, liczba niezweryfikowanych kont uprzywilejowanych, pokrycie logowaniem kluczowych systemów czy czas od wykrycia incydentu do eskalacji. Zarząd potrzebuje trendu, ekspozycji i decyzji wymagających finansowania, a nie surowego eksportu z narzędzia skanującego.

Incydent trzeba przećwiczyć przed obowiązkiem raportowym

NIS2 wzmacnia wymagania dotyczące zgłaszania istotnych incydentów. Ramy dyrektywy przewidują wczesne ostrzeżenie co do zasady w ciągu 24 godzin, zgłoszenie incydentu w ciągu 72 godzin oraz raport końcowy w późniejszym terminie. W praktyce organizacja powinna potwierdzić terminy, kanały i definicje wynikające z przepisów krajowych oraz wytycznych właściwego organu.

Największą trudnością rzadko bywa samo wysłanie zgłoszenia. Problemem jest ustalenie, czy zdarzenie jest istotne, jakiego wpływu biznesowego dotyczy, czy atak nadal trwa i które informacje są potwierdzone. Dlatego procedura nie może być ogólnym opisem reagowania na incydenty. Powinna zawierać ścieżkę decyzyjną, listę ról dostępnych poza godzinami pracy, wzory komunikatów, sposób zabezpieczania dowodów i warunki angażowania działu prawnego, komunikacji oraz zarządu.

Ćwiczenie tabletop z ransomware, kompromitacją dostawcy lub utratą widoczności w sieci OT szybko pokazuje różnicę między procedurą a gotowością. Warto testować nie tylko SOC i IT. W scenariuszu powinni uczestniczyć właściciel usługi, osoba odpowiedzialna za ciągłość działania, compliance oraz przedstawiciel zarządu. Rezultatem powinny być mierzalne korekty: skrócona ścieżka eskalacji, uzupełnione źródło logów, poprawiony kontakt do dostawcy albo doprecyzowane kryterium klasyfikacji zdarzeń.

Dostawcy i chmura są częścią granicy bezpieczeństwa

Organizacja może mieć dojrzały SOC, a jednocześnie utrzymywać krytyczny proces na platformie SaaS bez wymagań dotyczących incydentów, ciągłości działania i dostępu administracyjnego. NIS2 wymaga zarządzania ryzykiem w łańcuchu dostaw, co oznacza konieczność rozróżnienia dostawców krytycznych od zwykłych zakupów operacyjnych.

Dla kluczowych dostawców potrzebne są nie tylko ankiety. Należy zdefiniować wymagania kontraktowe dotyczące powiadamiania o incydentach, prawa do informacji i audytu, lokalizacji oraz ochrony danych, zarządzania podwykonawcami, retencji logów, testów ciągłości i warunków zakończenia współpracy. Zakres będzie inny dla dostawcy poczty, operatora łącza, producenta systemu SCADA i firmy utrzymującej aplikację. Wspólnym mianownikiem jest jednak wiedza, jaki wpływ awaria lub kompromitacja dostawcy ma na usługę krytyczną.

Dowody zgodności projektuje się od początku

Najtrudniejszą częścią przygotowań często nie jest wdrożenie kontroli, lecz zebranie dowodów w sposób powtarzalny. Zrzut ekranu wykonany na potrzeby audytu nie zastąpi rejestru zmian, protokołu z testu odtworzenia kopii, raportu z przeglądu dostępów ani potwierdzenia zamknięcia podatności po retestach.

Warto zbudować prostą matrycę dowodową. Dla każdego wymagania należy wskazać właściciela kontroli, źródło dowodu, częstotliwość jego powstawania, miejsce przechowywania oraz osobę zatwierdzającą. Taka matryca ogranicza pracę ręczną przed audytem i pozwala szybciej wykryć procesy, które istnieją tylko na papierze.

Przygotowanie do NIS2 nie kończy się w dniu zamknięcia audytu. Najlepszym pierwszym krokiem jest krótka ocena zakresu, ekspozycji i zdolności dowodowej, zakończona planem remediacji zatwierdzonym przez właścicieli ryzyka. Dopiero wtedy można zdecydować, czy potrzebne są zmiany procedur, testy techniczne, segmentacja, wsparcie SOC czy przebudowa relacji z dostawcami. Taki program daje zarządowi coś więcej niż deklarację zgodności: widoczny postęp w redukcji ryzyka i gotowość do działania wtedy, gdy usługa krytyczna naprawdę znajdzie się pod presją.