Firma produkcyjna zatrudniająca 180 osób otrzymuje od kluczowego kontrahenta ankietę bezpieczeństwa. Pytania dotyczą zarządzania ryzykiem, rejestru incydentów, ciągłości działania, bezpieczeństwa dostawców i monitorowania infrastruktury. Zarząd wie, że temat NIS2 nie może zostać sprowadzony do zakupu kolejnego narzędzia. Potrzebny jest uporządkowany program obejmujący ludzi, procesy, dokumentację i ochronę techniczną. Taki przykład wdrożenia NIS2 pokazuje, jak przejść od rozproszonych działań IT do mierzalnej gotowości operacyjnej.
Poniższy scenariusz jest modelowy, ale opiera się na realiach polskich średnich przedsiębiorstw. Nie każda organizacja podlega tym samym obowiązkom, a kwalifikację należy ocenić względem sektora, wielkości podmiotu, roli w łańcuchu dostaw oraz przepisów krajowych. Sama niepewność co do zakresu nie jest jednak uzasadnieniem dla bezczynności. Wymagania klientów, ubezpieczycieli i partnerów coraz częściej odzwierciedlają standard NIS2 niezależnie od formalnego statusu firmy.
Punkt wyjścia: bezpieczeństwo istnieje, ale nie jest zarządzane
W analizowanej firmie działa firewall UTM, kopie zapasowe są wykonywane codziennie, a zespół IT stosuje ochronę antywirusową na stacjach roboczych. Problem pojawia się wtedy, gdy trzeba odpowiedzieć na proste pytania zarządcze: kto zatwierdza ryzyko? Które systemy są krytyczne? Jak szybko firma wykryje przejęte konto Microsoft 365? Kto podejmie decyzję o odłączeniu serwera od sieci? Czy dostawca systemu produkcyjnego ma obowiązek zgłosić podatność?
Na większość pytań odpowiedź brzmi: „to zależy” albo „wie to administrator”. To nie jest model wystarczający dla organizacji, która ma wykazać nadzór nad cyberbezpieczeństwem. Wdrożenie rozpoczyna się więc od diagnozy, a nie od zamówienia licencji.
Audyt otwarcia obejmuje inwentaryzację aktywów, przegląd architektury sieci, kont uprzywilejowanych, kopii zapasowych, umów z dostawcami oraz obecnej dokumentacji. Zespół ustala również, jakie procesy biznesowe nie mogą zostać zatrzymane dłużej niż kilka godzin. Dla firmy produkcyjnej są to zwykle planowanie produkcji, dostęp do ERP, łączność z magazynem, poczta, systemy jakości i środowiska OT.
Ocena ryzyka, która daje zarządowi decyzje
W praktyce rejestr ryzyka nie powinien być arkuszem zawierającym kilkaset ogólnych zagrożeń. Ma prowadzić do decyzji o właścicielu ryzyka, terminie działania, priorytecie i akceptowalnym poziomie ekspozycji.
W tym przypadku najwyższe ryzyka dotyczą braku wieloskładnikowego uwierzytelniania dla dostępu zdalnego, niewystarczającej segmentacji między siecią biurową a systemami produkcyjnymi, braku centralnego monitoringu zdarzeń oraz niezweryfikowanych kopii zapasowych. Osobną kategorię stanowi ryzyko dostawców, ponieważ zewnętrzny serwisant może łączyć się z infrastrukturą zakładu.
Zarząd zatwierdza plan postępowania z ryzykiem i wyznacza jego właścicieli. Dyrektor operacyjny odpowiada za ciągłość procesów produkcyjnych, IT za zabezpieczenia techniczne, dział zakupów za wymagania wobec dostawców, a osoba odpowiedzialna za zgodność koordynuje dokumentację oraz dowody realizacji działań. Taki podział eliminuje częsty błąd: przekazanie całej odpowiedzialności za NIS2 jednemu administratorowi.
Przykład wdrożenia NIS2: plan na 90 dni
Projekt podzielono na trzy etapy. Pierwsze 30 dni służy porządkowaniu zakresu, ryzyka i odpowiedzialności. Kolejne 30 dni przeznaczono na priorytetowe zabezpieczenia techniczne oraz dokumentację. Ostatni etap obejmuje ćwiczenie incydentu, weryfikację dowodów i plan rozwoju na następne kwartały.
Najpierw firma ustanawia formalny model zarządzania bezpieczeństwem. Powstaje polityka cyberbezpieczeństwa, procedura zarządzania incydentami, zasady kontroli dostępu, polityka kopii zapasowych, procedura oceny dostawców oraz plan ciągłości działania. Dokumenty nie są tworzone wyłącznie na potrzeby audytu. Każdy z nich zawiera właściciela, częstotliwość przeglądu, konkretne role i sposób potwierdzania wykonania obowiązków.
Przykładowo procedura incydentowa wskazuje, że pracownik zgłasza podejrzaną wiadomość do wyznaczonego kanału, zespół IT wykonuje wstępną ocenę, a SOC prowadzi triage alertów i zbiera materiał techniczny. Kierownictwo otrzymuje informację o wpływie na działalność, decyzjach oraz działaniach ograniczających skutki. W przypadku zdarzeń spełniających warunki ustawowe organizacja uruchamia ścieżkę raportowania do właściwego organu. Terminy raportowe wymagają przygotowania wcześniej, ponieważ podczas aktywnego incydentu nie ma czasu na ustalanie, kto ma zatwierdzić komunikat.
Priorytet: widoczność, dostęp i odtwarzanie
Po stronie technicznej firma nie próbuje jednocześnie przebudować całego środowiska. W pierwszej kolejności wdraża kontrole, które realnie redukują prawdopodobieństwo oraz skutki ataku.
Włączone zostaje MFA dla poczty, VPN, kont administracyjnych i dostępu do aplikacji chmurowych. Dostępy uprzywilejowane są ograniczane do imiennych kont, a uprawnienia przeglądane co kwartał. Sieć biurowa, serwery i systemy produkcyjne otrzymują oddzielne strefy, z kontrolowanym ruchem między nimi. Nie zawsze pełna segmentacja OT jest możliwa od razu – starsze urządzenia i wymagania producentów mogą ograniczać zmiany. Wtedy stosuje się rozwiązania kompensacyjne, takie jak kontrolowane stanowiska pośredniczące, ograniczenie zdalnego dostępu i szczegółowe rejestrowanie połączeń.
Równolegle firma wdraża EDR na stacjach i serwerach oraz przekazuje kluczowe logi do monitorowania przez SOC 24/7. Źródłami zdarzeń są m.in. usługi tożsamości, poczta, endpointy, firewall i VPN. Sama agregacja logów nie zapewnia ochrony. Kluczowe jest ustalenie scenariuszy detekcji, priorytetów alertów, zasad eskalacji oraz osób dostępnych poza godzinami pracy.
Kopie zapasowe zostają objęte zasadą rozdzielenia środowisk i okresowych testów odtworzeniowych. Zarząd chce otrzymać odpowiedź nie tylko na pytanie, czy backup powstał, lecz także czy można odtworzyć ERP w założonym czasie. Test odtworzenia ujawnia, że kopia bazy danych jest poprawna, ale brakuje aktualnej instrukcji konfiguracji aplikacji. To właśnie ten detal trafia do planu naprawczego.
Dostawcy i pracownicy jako element kontroli
W przedsiębiorstwie średniej wielkości wiele krytycznych usług obsługują partnerzy zewnętrzni: dostawca ERP, firma serwisująca maszyny, operator chmury, księgowość czy telekomunikacja. Dlatego dział zakupów otrzymuje prosty formularz oceny dostawcy. Sprawdza on zakres dostępu, lokalizację danych, zasady zgłaszania incydentów, stosowane zabezpieczenia oraz możliwość zakończenia współpracy bez utraty danych.
Nowe i odnawiane umowy zawierają minimalne wymagania bezpieczeństwa. Nie chodzi o przeniesienie pełnej odpowiedzialności na dostawcę, lecz o ustalenie praktycznych zasad współdziałania. Dostawca z dostępem zdalnym powinien korzystać z imiennych kont, MFA, ograniczonych okien serwisowych i rejestrowanych sesji.
Równie istotne jest szkolenie pracowników. W tym przypadku nie kończy się ono prezentacją raz w roku. Firma prowadzi krótkie szkolenia dla wszystkich użytkowników, osobne warsztaty dla kadry kierowniczej oraz symulacje phishingu. Zarząd ćwiczy decyzje biznesowe, IT analizuje sygnały techniczne, a pracownicy uczą się szybko zgłaszać podejrzane zdarzenia bez obawy przed oceną.
Test, który sprawdza przygotowanie
W 75. dniu realizowany jest scenariusz ataku ransomware. SOC wykrywa nietypowe logowanie, a następnie próbę masowego szyfrowania plików na serwerze działowym. Zespół izoluje urządzenie, resetuje zagrożone poświadczenia, ocenia zakres wpływu i uruchamia komunikację kryzysową.
Ćwiczenie ujawnia dwa problemy: lista kontaktowa do dostawcy ERP jest nieaktualna, a dział produkcji nie zna alternatywnej procedury pracy przy niedostępności systemu. Te ustalenia są cenniejsze niż deklaracja, że procedura istnieje. Po ćwiczeniu firma aktualizuje plan ciągłości działania, kontaktów awaryjnych i kryteriów eskalacji.
Gotowość do NIS2 warto mierzyć konkretnie: pokryciem MFA, czasem wykrycia i reakcji na alert, odsetkiem aktualnych aktywów, skutecznością odtworzeń backupu, terminowością przeglądów dostawców oraz realizacją szkoleń. Mierniki nie zastąpią oceny eksperckiej, ale pozwalają zarządowi zobaczyć, czy bezpieczeństwo jest utrzymywane, a nie tylko jednorazowo wdrożone.
Dla wielu organizacji największym ryzykiem nie jest brak pojedynczego narzędzia, lecz brak ciągłości między audytem, działaniem technicznym i nadzorem zarządczym. Właśnie dlatego wsparcie partnera łączącego wdrożenie SZBI, ochronę XDR oraz monitoring SOC może skrócić drogę do realnej gotowości. Dobrze zaprojektowany program NIS2 ma działać także po zakończeniu projektu – wtedy, gdy pojawi się pierwszy alert, awaria dostawcy lub pytanie od audytora.