42 dni do wykrycia, 24 godziny na zgłoszenie: NIS2 i KSC w środowisku OT

Jaguar Land Rover stracił pięć tygodni produkcji i około 50 milionów funtów tygodniowo, kiedy atak ransomware we wrześniu 2025 roku zatrzymał zakłady w Wielkiej Brytanii, na Słowacji i w Brazylii. Napastnicy nie dotknęli ani jednego urządzenia na hali. Wystarczyło, że zaszyfrowali systemy IT, w których działało planowanie produkcji, zamówienia komponentów i komunikacja z dostawcami. Linie stanęły, bo bez tych danych nie było czego produkować ani z czego. JLR przynajmniej wiedział od razu: produkcja zatrzymała się tego samego dnia. Większość włamań do środowisk przemysłowych ujawnia się znacznie później i właśnie tam obowiązki zgłoszeniowe z NIS2 stają się trudne w sposób, którego treść dyrektywy nie zapowiada.

Większość producentów zgadza się z tą diagnozą i mimo to odkłada pracę, bo wdrożenie NIS2 oznacza inwentaryzację setek urządzeń, przebudowę architektury sieci i osobną rozmowę z każdym dostawcą oraz integratorem. To nie jest niefrasobliwość. To realistyczna ocena nakładu pracy, w której zgodność przegrywa z utrzymaniem produkcji do momentu, aż zderzy się z terminem albo z incydentem.

W skrócie: NIS2, wdrożona w Polsce nowelizacją ustawy o krajowym systemie cyberbezpieczeństwa (KSC), wymaga zarządzania ryzykiem, zgłaszania incydentów, segmentacji, bezpieczeństwa łańcucha dostaw i odpowiedzialności na poziomie zarządu. Zrozumienie wymagań zajmuje popołudnie. Trudność zaczyna się przy pierwszym urządzeniu z listy: sterowniku nadzorującym pasteryzację, na którym pracuje oprogramowanie porzucone przez dostawcę sześć lat temu. Nie da się go zaktualizować bez zgody dostawcy, wsparcia integratora i rewalidacji procesu, a ta walidacja obejmuje parametry decydujące o tym, czy produkt jest bezpieczny do spożycia. Najbliższe okno na taką pracę wypada w listopadzie.

Regulacja nie jest tu trudną częścią

NIS2 opisuje dziesięć środków zarządzania ryzykiem i harmonogram zgłoszeń. Wystarczy przeczytać je raz, żeby zrozumieć intencję, bo to te same zasady, które rozpozna każdy zespół bezpieczeństwa. W Polsce obowiązki egzekwuje się na podstawie znowelizowanej ustawy o KSC, więc pytania z kontroli przyjdą z jej brzmienia, a nie wprost z tekstu dyrektywy. Komplikacją jest środowisko, w którym mają wylądować.

Korporacyjne IT może załatać serwer we wtorek wieczorem, wypchnąć agenta na każdy laptop i wycofać nieobsługiwany sprzęt w cyklu odświeżania. Środowisko produkcyjne nie daje żadnej z tych opcji na żądanie. Dlatego playbook bezpieczeństwa IT przeniesiony wprost do OT zwykle zatrzymuje się w pierwszym tygodniu: skanowanie sieci podnosi alarm na sterowniku, agent EDR blokuje aplikację sterującą, a polityka wymuszonych aktualizacji zderza się z certyfikacją urządzeń. Same wymagania są sensowne. Droga do nich prowadzi przez zmiany w architekturze zakładu, a te należą do programu cyfryzacji produkcji, a nie do osobnego projektu compliance prowadzonego obok produkcji.

Pięć rzeczy, które zamieniają wymaganie w decyzję operacyjną

1. Urządzenia, których nie da się załatać w tym kwartale. Dostawca sterownika wydał poprawkę, ale jej instalacja oznacza zatrzymanie linii, inżyniera OEM na miejscu i pełny test regresyjny logiki sterowania. Na urządzeniach walidowanych dochodzi rekwalifikacja procesu. Sprzęt przemysłowy pracuje trzy do czterech razy dłużej niż sprzęt IT, więc część podatności zostaje z Tobą na lata, niezależnie od tego, co polityka łatania mówi na papierze. 

2. Brak jednego obrazu tego, co jest podłączone. Sterowniki, komputery przemysłowe, przełączniki, panele HMI, stacje inżynierskie, laptopy wykonawców, zdalne łącza serwisowe. Niewiele zakładów potrafi przedstawić jedną wiarygodną listę, bo dane z urządzeń różnych producentów nigdy nie trafiły w jedno miejsce. Dlatego budowa warstwy komunikacji przemysłowej i praca nad bezpieczeństwem OT raz po raz okazują się tym samym projektem. 

3. Okna serwisowe raz na kwartał. Urządzenie z najpoważniejszą podatnością bywa dostępne wyłącznie podczas planowanego postoju. Do tego czasu podatność istnieje, a ktoś musi świadomie zdecydować, że z nią żyjecie. 

4. Rozproszone lokalizacje i zależności od dostawców. Inne zakłady, inni integratorzy, inne architektury i umowy OEM, które wymagają zdalnego dostępu, żeby utrzymać gwarancję. 

5. Trzy zespoły, które się nawzajem potrzebują. Bezpieczeństwo IT i CISO wiedzą, czego wymaga dyrektywa. Bezpieczeństwo OT wie, jak to zrealizować wewnątrz systemu sterowania bez tworzenia ryzyka operacyjnego. Automatycy znają proces. Żaden z tych zespołów nie oszacuje ryzyka sam, a bezpieczeństwo OT dowożone wyłącznie przez IT kończy się środkami, które zakład później obchodzi. 

Kolejna technologia bezpieczeństwa tych problemów nie rozwiąże. Pomoże widoczność i wspólny model ryzyka. Dopóki bezpieczeństwo i utrzymanie ruchu patrzą na dwie różne listy urządzeń, każda decyzja o łataniu, izolacji czy wymianie jest negocjacją bez wspólnych danych.

Wpływ NIS2 na organizacje przemysłowe

1. Zarządzanie ryzykiem operacyjnym
   Cyberbezpieczeństwo staje się elementem, który wpływa na ciągłość produkcji, bezpieczeństwo pracowników i odporność biznesu.
2. Szersza odpowiedzialność
   Zarządzanie ryzykiem obejmuje dostawców i partnerów technologicznych, a ostateczna odpowiedzialność spoczywa na kierownictwie.
3. Proaktywna dojrzałość
   Zgodność pokazuje zdolność organizacji do zarządzania ryzykiem cybernetycznym i utrzymania ciągłości działania w trakcie incydentu.

Zacznij od zrozumienia, co u Ciebie naprawdę pracuje

Inwentaryzacja zasobów OT nie jest czynnością administracyjną. To fundament, na którym opiera się wszystko inne. Użyteczny spis odnotowuje, co jest podłączone, który proces obsługuje, jak krytyczny jest ten proces, jak urządzenie się komunikuje, gdzie stykają się IT i OT, kto może do niego dotrzeć i co się stanie, jeśli przestanie działać. Zebranie tego ręcznie zajmuje tygodnie i dezaktualizuje się, zanim powstanie. Użyteczna baza musi być prowadzona centralnie, wspierana narzędziami automatycznego wykrywania zasobów i polityką, która czyni jej aktualność czyimś obowiązkiem. Żadne narzędzie nie znajdzie wszystkiego, bo różnorodność typów urządzeń, modeli sieci i nieudokumentowanych połączeń jest na to zbyt duża. Narzędzia zamykają większość luki, resztę zamyka proces.

Bez tego lista podatności jest tylko listą. Ta sama luka na stanowisku testowym i na stacji sterującej linią, która wyznacza takt całego zakładu, to dwa różne problemy, a jedno okno serwisowe rozwiąże tylko jeden z nich. Które urządzenia należą do drugiej kategorii, widać w danych produkcyjnych, które już zbierasz: monitorowanie OEE pokazuje, gdzie przestoje kosztują najwięcej.

Co dalej: segmentacja, monitorowanie i realistyczna polityka łatania

1. Segmentacja ogranicza zasięg ruchu napastnika. Według raportu Dragos 2026 81% ocenianych środowisk przemysłowych nie ma jej na wystarczającym poziomie, co ułatwia przejście z sieci korporacyjnej do systemów sterowania. Nie da się jej zaprojektować na podstawie schematu architektury, bo większość zakładów niesie ze sobą nieudokumentowane połączenia narosłe przez lata: laptop spinający dwie strefy, integrację z ERP sięgającą dalej, niż ktokolwiek zakładał, zdalne łącze dodane na czas wizyty serwisowej w 2019 roku i nigdy nieusunięte. Najpierw zmapuj rzeczywisty ruch.

2. Monitorowanie pokazuje, kiedy normalne zachowanie się zmienia, a wagę nadaje temu harmonogram zgłoszeń. Zegar NIS2 rusza nie w momencie włamania, tylko wtedy, gdy dowiadujesz się o incydencie: 24 godziny na wczesne ostrzeżenie, 72 godziny na ocenę skutków, miesiąc na raport końcowy. Zestaw to z 42 dniami niewykrytego dostępu, które ten sam raport podaje jako średni czas obecności ransomware w środowiskach OT, a problem staje się widoczny. Te sześć tygodni niczego w dyrektywie nie narusza. Problem leży w tym, co po nich zostaje: okres, w którym nikt nie patrzył, więc brakuje materiału dowodowego, a zgłoszenie sprowadza się do rekonstrukcji. Jeśli już zbierasz dane z zakładu, jesteś znacznie bliżej, niż myślisz, bo praca nad zgłoszeniem zamienia się w odpytanie tego, co masz, zamiast składania wszystkiego od zera. Jeśli nie zbierasz nic, zaczynasz od zera w dniu, w którym rusza zegar. A 42 dni to średnia, więc wiele przypadków trwa znacznie dłużej. Warto pamiętać, że monitorowanie w OT musi być pasywne, bo inwazyjne skanowanie i agenci na starych systemach sterowania tworzą dokładnie to ryzyko operacyjne, którego chciałeś uniknąć.
   

3. Zarządzanie podatnościami oparte na ryzyku zaczyna się od przyjęcia, że nie wszystko da się załatać teraz, i od odmowy traktowania tego jako wymówki. Kiedy poprawka musi poczekać:

• Ogranicz dostęp. Kontroluj, kto i skąd może dotrzeć do urządzenia. 

• Zrekompensuj na poziomie sieci. Ściślejsza izolacja urządzenia wewnątrz sieci OT i hardening na granicy strefy. 

• Monitoruj je. Obserwuj ruch do urządzenia i z urządzenia, żeby zmiana jego zachowania była widoczna. 

• Zaplanuj naprawę. Wpisz działanie naprawcze w postój, który faktycznie istnieje w kalendarzu. 

Organ nadzoru nie szuka pustego raportu z łatania. Szuka udokumentowanej decyzji o ryzyku, której da się bronić.

Jedna stacja robocza, dwie poprawne odpowiedzi

Stacja inżynierska w sieci sterowania linii rozlewniczej pracuje na nieobsługiwanej wersji Windows. Dostawca urządzenia łączy się z nią zdalnie w celach diagnostycznych.

Bezpieczeństwo mówi: zaktualizuj system, zainstaluj ochronę i odetnij połączenie zewnętrzne.

Utrzymanie ruchu mówi: aplikacja sterująca nie jest walidowana na nowszym systemie, wymiana stacji wymaga wsparcia dostawcy i rekwalifikacji procesu, agent może zakłócić pracę oprogramowania sterującego, a odcięcie zdalnego dostępu oznacza czekanie na inżyniera na miejscu przy następnym zatrzymaniu linii.

Obie strony mają rację co do własnego ryzyka i żadna nie zdecyduje sama. Rozstrzyga ustalenie, jak krytyczne i jak wyeksponowane jest urządzenie, odcięcie połączeń, których nie potrzebuje, kontrola i logowanie sesji dostawcy, obserwacja jego ruchu oraz wpisanie wymiany w najbliższe planowane okno serwisowe. Tak wygląda zgodność, która przychodzi jako decyzja o ryzyku operacyjnym, a nie jako równoległe ćwiczenie narzucone zakładowi.

Ktoś nadal musi tę decyzję podjąć. Zgodnie z artykułem 20 odpowiedzialność spoczywa na kierownictwie, a w produkcji oznacza to, że bezpieczeństwo OT nie może już mieszkać w całości po stronie IT albo CISO.

Twój termin zależy od tego, gdzie produkujesz

NIS2 jest dyrektywą, a nie rozporządzeniem, więc daty, które Cię obowiązują, wynikają z krajowej ustawy wdrażającej. W Polsce jest to nowelizacja ustawy o KSC, w Niemczech NIS2UmsuCG, we Francji ustawa wciąż powstaje.

Ponad dwadzieścia krajów już egzekwuje przepisy. Pełny status według krajów, regularnie aktualizowany. Grupa z zakładami w trzech krajach pracuje na trzech różnych harmonogramach, trzech ścieżkach rejestracji i z trzema organami nadzoru, dla tej samej dyrektywy.

Pytanie, które warto zadać

Najsilniejsze programy nie będą tymi z największą liczbą polityk, tylko tymi, które zostawią zakład z lepszą widocznością, jasną odpowiedzialnością za ryzyko i realną zdolnością do ograniczenia zakłóceń oraz powrotu do normalnej pracy. Dojście tam wymaga ludzi, którzy uruchamiali sterowniki, i ludzi, którzy pisali polityki bezpieczeństwa. Tak pracujemy z klientami w TT PSC: inżynierowie, którzy łączyli i integrowali zakłady w całej Europie, obok specjalistów bezpieczeństwa OT, oceniają środowiska, których nie da się zatrzymać.

Użyteczne pytanie nie brzmi więc: co muszę wdrożyć, żeby być zgodnym. Brzmi: co musi się zmienić w mojej operacji, żeby odporność stała się częścią sposobu prowadzenia produkcji. Odpowiedź zaczyna się od uczciwej oceny stanu obecnego, a to nie musi być duży projekt.

Ocena gotowości OT na NIS2