Jak działa segmentacja sieci OT w praktyce

Jak działa segmentacja sieci OT: ogranicza ruch, zatrzymuje propagację incydentów i wspiera ciągłość produkcji oraz wymagania NIS2 i audyty zgodności.

Awaria pojedynczej stacji inżynierskiej nie powinna dawać atakującemu drogi do sterownika PLC, serwera HMI ani systemu zarządzania produkcją. W wielu zakładach właśnie tak wygląda jednak rzeczywistość: środowiska IT i OT komunikują się szerzej, niż wymaga tego proces, a reguły dostępu są budowane historycznie, pod presją uruchomienia linii lub zdalnego wsparcia dostawcy. Jak działa segmentacja sieci OT w takim środowisku? Nie polega na mechanicznym podziale adresacji IP. Jest kontrolą przepływów, która ogranicza zasięg incydentu bez zakłócania procesu technologicznego.

Dla zarządu efektem ma być mierzalne zmniejszenie ryzyka przestoju, naruszenia bezpieczeństwa fizycznego lub utraty możliwości realizacji usługi. Dla zespołów OT oznacza to precyzyjnie określone ścieżki komunikacji, kontrolowaną administrację i możliwość wykazania, kto oraz z jakiego systemu uzyskuje dostęp do aktywów krytycznych. Dobrze zaprojektowana segmentacja dostarcza też dowodów przydatnych w audytach NIS2, KSC czy ISO 27001, ale jej pierwszym celem pozostaje ciągłość operacyjna.

Dlaczego płaska sieć OT zwiększa skutki incydentu

W płaskiej sieci urządzenia należące do różnych stref procesu mogą komunikować się praktycznie bez ograniczeń. Stacja operatora, serwer historyczny, panel HMI, sterownik, system kontroli jakości i komputer serwisowy są wtedy osiągalne w ramach tego samego segmentu lub przez nadmiernie otwarte reguły routingu. Problem nie zawsze jest widoczny podczas normalnej pracy. Ujawnia się dopiero wtedy, gdy malware, przejęte konto lub błędnie skonfigurowany laptop serwisowy zacznie skanować i wykorzystywać kolejne zasoby.

W IT konsekwencją może być wyciek danych albo niedostępność aplikacji. W OT stawką jest zatrzymanie linii, utrata widoczności procesu, błędne parametry sterowania, uszkodzenie produktu lub zagrożenie dla ludzi. Dlatego ocena ryzyka nie może kończyć się na pytaniu, czy dany port jest otwarty. Trzeba ustalić, jaki proces biznesowy obsługuje aktywo, jaki jest dopuszczalny czas niedostępności i czy jego komunikacja jest niezbędna do bezpiecznej eksploatacji.

Segmentacja redukuje tzw. ruch boczny. Jeżeli incydent wystąpi w jednej strefie, atakujący nie powinien automatycznie przejść do pozostałych elementów środowiska. To ograniczenie nie eliminuje potrzeby ochrony endpointów, monitoringu SOC czy zarządzania podatnościami. Zmniejsza jednak promień rażenia zdarzenia i daje zespołom czas na triage oraz kontrolowaną remediację.

Jak działa segmentacja sieci OT: strefy i kontrolowane przepływy

Punktem wyjścia jest model stref i kanałów komunikacji. Strefa grupuje aktywa o podobnej funkcji, krytyczności i wymaganiach bezpieczeństwa. Kanał określa natomiast, jaka komunikacja może przechodzić między strefami, z jakiego źródła, do jakiego celu, w jakim protokole oraz w jakim kierunku.

Typowa architektura rozdziela co najmniej sieć korporacyjną IT, strefę pośrednią IT/OT, strefy nadzoru produkcji oraz sieci bezpośredniego sterowania. W zależności od zakładu osobno wydziela się również systemy bezpieczeństwa funkcjonalnego, laboratoria, sieci dostawców, urządzenia mobilne i infrastrukturę zdalnego dostępu. Granice te są egzekwowane przez firewalle przemysłowe, listy kontroli dostępu, przełączniki, mechanizmy uwierzytelniania i rozwiązania dostępu uprzywilejowanego.

Najczęściej kluczową rolę pełni przemysłowa strefa DMZ między IT a OT. Nie jest to tylko kolejny VLAN. To kontrolowany bufor, w którym umieszcza się usługi wymagające wymiany danych, na przykład serwery pośredniczące, repozytoria aktualizacji, mechanizmy transferu plików lub komponenty raportowe. Zamiast bezpośredniego połączenia systemu ERP ze sterowaniem produkcji tworzy się przepływ pośredni, ograniczony do konkretnej usługi i uzasadnionego kierunku komunikacji.

Dobra polityka nie brzmi „zezwól z IT do OT”. Powinna być jednoznaczna: wskazywać konkretny system źródłowy, serwer docelowy, port, protokół, kierunek i właściciela biznesowego przepływu. Jeżeli dostawca musi zdalnie diagnozować urządzenie, dostęp powinien przechodzić przez kontrolowany punkt wejścia, być ograniczony czasowo, rejestrowany i zatwierdzany. Stała reguła „any-to-any” dla wygody serwisu tworzy ekspozycję, której nie da się obronić ani operacyjnie, ani audytowo.

Segmentacja nie może zatrzymać procesu

Środowisko OT różni się od klasycznej sieci biurowej. Część urządzeń pracuje przez wiele lat, korzysta z protokołów bez silnego uwierzytelniania, wymaga komunikacji rozgłoszeniowej albo jest wspierana wyłącznie w określonej konfiguracji producenta. Zmiana reguły może wpłynąć na synchronizację, alarmowanie lub wymianę receptur. Dlatego zasada „domyślnie blokuj” jest właściwym celem, ale jej wdrożenie musi odbywać się etapowo i po weryfikacji zachowania procesu.

Najpierw obserwuje się rzeczywisty ruch, identyfikuje zależności i porównuje je z dokumentacją. Dopiero potem projektuje się reguły, testuje je na ograniczonym zakresie i wdraża z procedurą wycofania. W systemach o wysokiej krytyczności konieczne są okna zmian, udział technologów oraz jasno przypisane kryteria akceptacji. Segmentacja wykonana bez wiedzy o procesie może przynieść więcej ryzyka niż brak segmentacji.

Od inwentaryzacji do egzekwowania polityk

Projekt należy rozpocząć od wiarygodnego obrazu aktywów i komunikacji. Lista urządzeń z CMDB lub arkusza inwentaryzacyjnego bywa niepełna, szczególnie w zakładach rozwijanych przez lata. Potrzebna jest pasywna identyfikacja komponentów OT, ich wersji, funkcji, połączeń i właścicieli. Aktywne skanowanie należy stosować ostrożnie, po ocenie wpływu i uzgodnieniu z osobami odpowiedzialnymi za produkcję.

Następnie zespół klasyfikuje aktywa według krytyczności procesu. Inne wymagania będzie miał serwer raportowy, inne stacja programistyczna PLC, a jeszcze inne system bezpieczeństwa funkcjonalnego. Właśnie w tym miejscu techniczne ustalenia trzeba przełożyć na język ryzyka: które połączenia mogą spowodować przestój, które stanowią drogę z IT do sterowania i gdzie brak kontroli dostępu utrudni odtworzenie przebiegu incydentu.

W praktyce program prac obejmuje cztery równoległe strumienie:

• inwentaryzację aktywów, protokołów i rzeczywistych przepływów;
• projekt stref, kanałów oraz docelowych reguł komunikacji;
• pilotaż i wdrożenie zmian z testami funkcjonalnymi oraz planem wycofania;
• monitoring, przeglądy reguł i zarządzanie wyjątkami po uruchomieniu.

Każdy wyjątek powinien mieć właściciela, uzasadnienie, termin ważności i decyzję akceptującą ryzyko. Bez tego z czasem wraca problem nadmiernie otwartych przejść, tylko w bardziej skomplikowanej architekturze. Przegląd polityk powinien być powiązany ze zmianami w procesie, modernizacją linii, nowym integratorem lub wdrożeniem zdalnego dostępu.

Co mierzyć po wdrożeniu segmentacji OT

Sam diagram architektury nie jest dowodem skuteczności. Organizacja powinna umieć wykazać, ile aktywów objęto inwentaryzacją, które krytyczne przepływy mają zatwierdzonych właścicieli oraz jaki odsetek reguł posiada aktualne uzasadnienie. Warto mierzyć liczbę połączeń IT-OT zredukowanych lub przeniesionych do strefy DMZ, liczbę nieautoryzowanych prób komunikacji wykrytych przez monitoring oraz czas zamknięcia wyjątków wysokiego ryzyka.

Dla SOC segmentacja poprawia jakość detekcji. Alert o komunikacji między strefami ma większą wartość, gdy ruch jest rzadki, zdefiniowany i przypisany do procesu. Zespół nie analizuje wtedy ogromu normalnego ruchu w płaskiej sieci, lecz odchylenie od kontrolowanej polityki. Triage według SLA można oprzeć na krytyczności strefy, typie protokołu i potencjalnym wpływie na produkcję.

Dla audytora znaczenie mają nie tylko konfiguracje firewalli, lecz także dowody procesu: zatwierdzona architektura, rejestr przepływów, wyniki testów, procedury zmian, logi dostępu zdalnego i ślady okresowych przeglądów. Dla zarządu kluczowy jest natomiast związek tych dowodów z redukcją ryzyka operacyjnego oraz zdolnością organizacji do utrzymania działania podczas incydentu.

Najczęstsze błędy i właściwa kolejność działań

Błędem jest zakup urządzeń bezpieczeństwa przed poznaniem ruchu i zależności technologicznych. Firewall nie naprawi niejasnej odpowiedzialności za systemy, nieudokumentowanych połączeń dostawców ani braku procesu zmian. Równie ryzykowne jest traktowanie VLAN-ów jako pełnej segmentacji. Separacja logiczna bez kontroli routingu, restrykcyjnych reguł i monitorowania nie zatrzymuje ruchu tam, gdzie powinna.

Drugim problemem jest projektowanie wyłącznie pod zgodność. Wymóg regulacyjny może inicjować program, ale nie odpowie za funkcjonowanie linii podczas zmiany konfiguracji. Właściwa kolejność to rozpoznanie aktywów i procesu, model ryzyka, projekt architektury, kontrolowany pilotaż, a następnie stałe utrzymanie polityk. W projektach realizowanych przez SprintTech ta kolejność pozwala powiązać ustalenia techniczne z planem remediacji, dowodami zgodności i priorytetami zaakceptowanymi przez właścicieli ryzyka.

Najlepszym pierwszym krokiem nie jest deklaracja pełnej przebudowy sieci. Jest nim wspólny warsztat IT, OT i właścicieli procesu, zakończony listą krytycznych aktywów oraz kilku przepływów, które wymagają natychmiastowej kontroli. Od tej listy można zbudować realny plan segmentacji, który chroni produkcję nie na diagramie, lecz w codziennej pracy zakładu.