Dlaczego KSC NIS2 fundamentalnie zmienia zasady gry w bezpieczeństwie OT/ICS?

Jako CTO lub CIO, prawdopodobnie jesteś już w trakcie planowania wdrożenia KSC/NIS2 dla swojej infrastruktury korporacyjnej (IT). Rozmowy dotyczą systemów SIEM, EDR i polityk dla łańcucha dostaw. Istnieje jednak obszar, który przez lata był poza radarem działów IT, a który nowe regulacje stawiają w samym centrum uwagi: Technologia Operacyjna (OT). To środowisko, w którym cyberatak nie oznacza już „tylko” utraty danych, ale fizyczne zatrzymanie produkcji, zagrożenie dla bezpieczeństwa ludzi i paraliż kluczowych usług.

Dla firm z sektora przemysłu, energetyki czy transportu, KSC/NIS2 to rewolucja, która wymusza na działach IT i inżynierii podjęcie wspólnej odpowiedzialności za systemy ICS, SCADA i PLC. To wyzwanie jest fundamentalnie inne od wszystkiego, z czym miałeś do czynienia w świecie IT. Wymaga nie tylko innych narzędzi, ale przede wszystkim innego sposobu myślenia, w którym priorytetem jest nieprzerwana ciągłość produkcji.

Czym dokładnie jest bezpieczeństwo OT i dlaczego KSC/NIS2 tak mocno je akcentuje?

Technologia Operacyjna (OT) to zbiór systemów sprzętowych i programowych, które monitorują i kontrolują procesy fizyczne. Mówimy tu o systemach sterowania przemysłowego (ICS), systemach nadzoru i akwizycji danych (SCADA) oraz programowalnych sterownikach logicznych (PLC). Krótko mówiąc, jest to technologia, która „kręci” maszynami w fabryce, zarządza przepływem w rurociągu lub steruje siecią trakcyjną.

KSC/NIS2 tak mocno akcentuje ten obszar, ponieważ dotyczy on podmiotów kluczowych, których zakłócenie działania ma bezpośredni wpływ na gospodarkę i społeczeństwo. Ustawodawca doskonale rozumie, że atak na systemy OT w elektrowni, oczyszczalni ścieków czy u producenta żywności jest znacznie groźniejszy niż atak na stronę internetową.

Dlatego właśnie nowe przepisy obejmują ochronę systemów OT/ICS, co dla wielu organizacji oznacza konieczność zbudowania kompetencji bezpieczeństwa w tym obszarze praktycznie od zera. Bezpieczeństwo OT staje się synonimem zapewnienia ciągłości operacyjnej, która jest jednym z głównych filarów KSC/NIS2.

Dlaczego tradycyjne podejście do bezpieczeństwa IT jest nieskuteczne w sieciach OT?

Jako szef IT możesz pomyśleć: „skoro mam EDR, firewall i procedury, to po prostu rozciągnę je na obszar produkcji”. To katastrofalny błąd. Środowisko OT działa według zupełnie innych reguł niż IT. Próba zastosowania standardów IT 1:1 jest nie tylko nieskuteczna, ale może być wręcz niebezpieczna dla procesu produkcyjnego.

W IT priorytetem jest poufność danych (Confidentiality). W OT absolutnym królem jest dostępność (Availability) i integralność (Integrity). Nie można „na chwilę” wyłączyć sterownika PLC, aby wgrać poprawkę bezpieczeństwa, jeśli sterownik ten zarządza pracą reaktora chemicznego lub pieca hutniczego. Systemy OT są projektowane do pracy ciągłej przez 20 lat, a nie do cotygodniowych aktualizacji.

Co więcej, standardowe narzędzia IT, takie jak skanery podatności, działają w sposób agresywny. Uruchomienie skanu portów w sieci IT co najwyżej na chwilę spowolni serwer. Uruchomienie takiego samego skanu w sieci OT może „zawiesić” stary sterownik PLC i doprowadzić do niekontrolowanego zatrzymania całej linii produkcyjnej.

Jakie są największe zagrożenia wynikające z integracji sieci IT i OT?

Historycznie sieci OT były bezpieczne, ponieważ były fizycznie odizolowane („air-gapped”). Nie miały połączenia z internetem ani z siecią biurową. Ten świat już nie istnieje. W pogoni za efektywnością, analizą danych i Przemysłem 4.0, firmy masowo łączyły swoje sieci IT (biurowe) z sieciami OT (produkcyjnymi).

To właśnie ta integracja stworzyła „autostradę” dla cyberzagrożeń. Dziś najczęstszy scenariusz ataku to taki, w którym atakujący dostaje się do sieci IT (np. poprzez phishing), a następnie, wykorzystując brak odpowiedniej separacji, przemieszcza się lateralnie do sieci OT.

Rezultat? Atak ransomware, który w sieci IT jest „tylko” problemem biznesowym (zaszyfrowane pliki), w sieci OT staje się kryzysem operacyjnym. Zaszyfrowanie stacji HMI lub serwera SCADA oznacza natychmiastowe zatrzymanie produkcji, straty finansowe liczone w milionach na godzinę i ryzyko fizycznych uszkodzeń maszyn.

Na czym polega audyt bezpieczeństwa OT zgodny z KSC/NIS2?

Pierwszym krokiem do zabezpieczenia OT jest zrozumienie, co tak naprawdę posiadamy i jakie jest ryzyko. Audyt bezpieczeństwa OT, który jest wymagany przez KSC/NIS2, jest jednak zupełnie inny niż audyt IT. Partnerzy tacy jak nFlo wykonują dedykowane oceny zgodności NIS2 dla OT/ICS oraz audyty zgodności z kluczową normą branżową – IEC 62443.

Taki audyt nie polega na aktywnym skanowaniu. Kluczowa jest pasywna ocena podatności. Specjalistyczne sondy „nasłuchują” ruchu w sieci OT, identyfikując urządzenia (PLC, HMI), protokoły (np. Modbus, Profinet) oraz znane podatności, a wszystko to bez wysyłania ani jednego pakietu, który mógłby zakłócić produkcję.

Audyt obejmuje również analizę konfiguracji stacji operatorskich, serwerów SCADA oraz samych sterowników. Kluczowe jest też sprawdzenie procedur – czy istnieje polityka bezpieczeństwa OT, jak zarządzany jest zdalny dostęp serwisantów, jak wygląda proces aktualizacji (jeśli w ogóle jest możliwy).

Czym jest model Purdue i dlaczego jest kluczowy dla segmentacji sieci OT?

Jeśli jest jedna techniczna koncepcja, którą jako CTO/CIO musisz wdrożyć w OT, to jest nią segmentacja sieci oparta na modelu Purdue. To absolutny fundament bezpieczeństwa OT, który bezpośrednio adresuje ryzyko przeskoczenia ataku z IT do OT.

Model Purdue to logiczna architektura, która dzieli infrastrukturę na hierarchiczne poziomy – od czujników i maszyn na „dole” (Poziom 0/1), przez systemy sterowania (Poziom 2), zarządzania produkcją (Poziom 3), aż po sieć korporacyjną IT (Poziom 4/5). Cała filozofia polega na tym, by stworzyć strefy bezpieczeństwa i rygorystycznie kontrolować komunikację między nimi.

W praktyce oznacza to „zaprojektowanie architektury bezpieczeństwa OT”, w której sieć IT nie może komunikować się bezpośrednio ze sterownikami PLC. Ruch musi przejść przez strefę zdemilitaryzowaną (DMZ), gdzie jest filtrowany przez specjalistyczne zapory sieciowe (Industrial Firewalls). Wdrożenie tego modelu to najważniejszy krok w kierunku budowy odporności.

Jak przeprowadzić strategiczną ocenę ryzyka dla procesów produkcyjnych?

KSC/NIS2 opiera się na podejściu bazującym na ryzyku. W świecie OT, ryzyko to nie jest mierzone wartością danych na serwerze, ale kosztem zatrzymania procesu produkcyjnego. Dlatego jako CTO/CIO musisz zainicjować strategiczną ocenę ryzyka dla procesów produkcyjnych.

Oznacza to, że zamiast pytać „jakie jest ryzyko dla tego serwera?”, musisz zapytać: „Jaka jest strata finansowa i operacyjna, jeśli ta linia produkcyjna stanie na 4 godziny? A na 24 godziny?”. To zupełnie zmienia priorytety.

Taka ocena, przeprowadzana wspólnie z działem produkcji i inżynierii, pozwala zidentyfikować najbardziej krytyczne zasoby OT. Może się okazać, że najważniejszy jest nie nowy serwer SCADA, ale stary, niepatchowany sterownik PLC, którego nikt nie ruszał od 15 lat, a który kontroluje kluczową maszynę. To tam musi pójść pierwszy budżet na mitygację ryzyka.

Jak testować bezpieczeństwo w środowiskach OT bez zatrzymywania produkcji?

To jedno z najczęstszych pytań i największych obaw dyrektorów technicznych. Chcemy sprawdzić bezpieczeństwo, ale nie możemy ryzykować przestoju. Odpowiedź leży w specjalistycznych, pasywnych i bezpiecznych metodach testowania.

Jak wspomniano, podstawą jest pasywna ocena podatności – czyli monitorowanie ruchu sieciowego w celu znalezienia słabych punktów, bez aktywnej ingerencji. Drugim elementem jest przegląd konfiguracji sterowników PLC, HMI i systemów SCADA. Analizuje się je pod kątem dobrych praktyk bezpieczeństwa (np. czy domyślne hasła zostały zmienione).

Dopiero w trzeciej kolejności wykonuje się bezpieczne testy penetracyjne systemów OT/ICS. Nigdy nie robi się ich „na żywo” na produkcji. Przeprowadza się je w ścisłej współpracy z inżynierami, często w kontrolowanym środowisku testowym (laboratorium) lub podczas planowanego okna serwisowego.

Jak przygotować plan reagowania na incydenty (IR) specyficzny dla OT?

Posiadanie planu reagowania na incydenty jest twardym wymogiem KSC/NIS2. Jednak plan IR dla IT jest bezużyteczny w środowisku OT. W IT pierwszą reakcją na atak ransomware jest „odciąć serwer od sieci”. Zastosowanie tej samej logiki w OT i nagłe odcięcie sterownika PLC może doprowadzić do fizycznego uszkodzenia maszyn lub zagrożenia dla ludzi.

Plan reagowania na incydenty w OT musi być opracowany od zera. Musi definiować, kto podejmuje decyzje o bezpiecznym i kontrolowanym zatrzymaniu procesu produkcyjnego. Musi uwzględniać inżynierów procesu i operatorów maszyn, a nie tylko specjalistów IT.

Dlatego kluczowe jest nie tylko opracowanie tych planów, ale także ich regularne testowanie poprzez ćwiczenia tabletop. Symulacja „ataku ransomware na linię produkcyjną” pozwala przećwiczyć komunikację i proces decyzyjny między IT, OT i zarządem w bezpiecznych warunkach.

Różnice w Reagowaniu na Incydenty: IT vs. OT

Zrozumienie fundamentalnych różnic w priorytetach jest kluczowe dla skutecznego planu IR zgodnego z KSC/NIS2.

Dlaczego do wdrożenia bezpieczeństwa OT potrzebny jest wyspecjalizowany partner?

Jako CTO/CIO wiesz, że Twój wewnętrzny zespół IT jest ekspertem w systemach korporacyjnych. Dział Utrzymania Ruchu i inżynierowie to eksperci od procesów produkcyjnych. Problem polega na tym, że żadna z tych grup nie jest ekspertem od bezpieczeństwa OT. To wysoce niszowa dziedzina, wymagająca jednoczesnego rozumienia cyberbezpieczeństwa na poziomie IT oraz specyfiki protokołów przemysłowych i ryzyka fizycznego.

Próba wdrożenia KSC/NIS2 w obszarze OT siłami wewnętrznymi jest niezwykle ryzykowna. Można przypadkowo zatrzymać produkcję lub wdrożyć rozwiązania, które nie będą skuteczne. Dlatego potrzebny jest partner, który łączy te dwa światy.

Partner taki jak nFlo posiada dedykowany filar usług „CyberSec – OT”. To zespół, który rozumie normę IEC 62443, potrafi projektować architekturę w oparciu o model Purdue i wie, jak przeprowadzić pasywny audyt sterowników PLC. Zaangażowanie takiego integratora to jedyny sposób, aby zagwarantować, że bezpieczeństwo będzie wspierać ciągłość produkcji, a nie ją zakłócać.