Jak przeprowadzić migrację systemu automatyki – 7 kroków, 4 pułapki

Stare, nieaktualizowane PLC pracujące w systemach automatyki przedsiębiorstw sklasyfikowanych jako krytyczne to bardzo często otwarte okno podatności, przez które cyberprzestępcy włamują się do systemów OT. Niestety w dalszym ciągu wielu inżynierów nie zdaje sobie z tego sprawy. Ci którzy już są tego świadomi stają przed wyzwaniem: jak przeprowadzić migrację aby system spełniał wymogi aktualnych standardów w systemach automatyki?

Kiedy modernizacja staje się zagrożeniem?

W lutym 2021 roku operator zakładu uzdatniania wody w Oldsmar na Florydzie podczas wykonywania swoich obowiązków obserwuje na ekranie, jak kursor myszki zaczyna się poruszać sam. Ktoś nieznany przejął zdalny dostęp do systemu sterowania opartego na oprogramowaniu inżynierskim i w ciągu kilku sekund zmienił poziom wodorotlenku sodu – substancji używanej do regulacji pH wody pitnej – ze 111 ppm do 11 100 ppm. Stężenie 111 razy przekraczające normę! Operatorowi udało się błyskawicznie cofnąć zmianę, zanim cokolwiek dotarło do sieci wodociągowej. Śledztwo wykazało, że zakład korzystał ze starego oprogramowania TeamViewer, a sieć OT nie była odseparowana od sieci biurowej. Działo się to w trakcie planowanej modernizacji systemu sterowania.

Ten incydent nie wydarzył się w kraju słabo rozwiniętym. Doszło do niego w małym, amerykańskim zakładzie komunalnym – z budżetem i strukturą IT podobną do setek zakładów produkcyjnych w Polsce. Z tego powodu powinien stać się bardzo istotny dla inżynierów automatyki i kierowników utrzymania ruchu, którzy stoją przed decyzją o migracji sterowników PLC, gdyż ten proces również może nieść ze sobą ryzyko, jeśli nie przeprowadza się go zgodnie z procedurami.

Dlaczego migracja PLC to moment szczególnego ryzyka cyberbezpieczeństwa?

Migracja systemu automatyki przemysłowej – w szczególności wymiana sterowników PLC – jest jednym z najbardziej ryzykownych z punktu widzenia cyberbezpieczeństwa OT momentów w cyklu życia instalacji. Paradoks polega na tym, że ryzyko wzrasta właśnie wtedy, gdy przedsiębiorstwo próbuje unowocześnić istniejącą infrastrukturę. Podczas typowej migracji PLC nakładają się na siebie cztery istotne czynniki ryzyka:

• Równoległe działanie starego i nowego systemu – przez tygodnie, a niekiedy miesiące, stary sterownik (często z podatnościami) i nowy PLC funkcjonują w tej samej sieci przemysłowej, często bez właściwej segmentacji.
  
• Rozszerzone uprawnienia dostępowe – zewnętrzni integratorzy, dostawcy OEM i serwisanci wykonujący usługę migracji uzyskują tymczasowy, ale szeroki dostęp do sieci OT. Ich laptopy i narzędzia inżynierskie rzadko podlegają tym samym rygorom bezpieczeństwa co sprzęt zakładowy co generuje spore ryzyko.
  
• Tymczasowe mosty sieciowe – aby umożliwić testowanie i uruchamianie nowego sterownika, tworzone są tymczasowe połączenia między sieciami i segmentami sieci, które w normalnych warunkach byłyby odizolowane. Te połączenia bywają pozostawiane aktywne długo po zakończeniu migracji. Po prostu się o nich zapomina.
  
• Oprogramowanie inżynierskie jako wektor ataku – rozbudowane narzędzia inżynierskie są interfejsami do wszystkich sterowników danego producenta. Jeśli laptop z takim oprogramowaniem zostanie zhakowany, atakujący może zmodyfikować logikę drabinkową lub parametry procesu w wielu urządzeniach do których laptop ma dostęp, praktycznie bez pozostawienia śladu po modyfikacji.

Opisywany powyżej incydent z Oldsmar pokazał, że wystarczy jeden niezabezpieczony pulpit zdalny i jeden moment nieuwagi, żeby operator stracił kontrolę nad procesem. A migracja systemu to czas, gdy takich momentów jest najwięcej.

Drugi przykład z ostatnich lat doskonale pokazuje, jak atak wchodzący przez sieć IT może sparaliżować środowisko OT. W 2019 roku ransomware LockerGoga uderzył w Norsk Hydro – globalnego producenta aluminium. Złośliwe oprogramowanie rozprzestrzeniło się z sieci biurowej do systemów operacyjnych, zmuszając część zakładów do przejścia na sterowanie ręczne. Szacowane straty przekroczyły 70 milionów dolarów. Kluczowy wniosek: integracja sieci IT i OT – tak pożądana z punktu widzenia efektywności – staje się kosztowną pułapką, gdy brakuje odpowiedniej segmentacji i kontroli dostępu.

Jakie są kluczowe normy i regulacje?

Cyberbezpieczeństwo systemów automatyki przemysłowej tworzy ramy prawne i techniczne, których naruszenie może pociągać za sobą realne konsekwencje. Dotyczy to szczególnie przedsiębiorstw klasyfikowanych jako infrastruktura krytyczna, ale nie tylko. Widać, że nawet podmioty formalnie nieobjęte nowymi regulacjami coraz częściej analizują swoje systemy i podejmują działania, aby dostosować się do obowiązujących standardów oraz zwiększać poziom zgodności i bezpieczeństwa.

IEC 62443 – standard dedykowany systemom OT

To najczęściej wymieniana norma dla środowisk przemysłowych OT w kontekście cyberbezpieczeństwa. W kontekście migracji PLC szczególnie istotne są dwa wymagania i dwa poziomy certyfikacji w ramach serii IEC 62443-4:

• IEC 62443-4-1 dotyczy procesu wytwarzania oprogramowania i systemów (Secure Development Lifecycle),
• IEC 62443-4-2 określa wymagania dla konkretnych komponentów systemów automatyki przemysłowej (IACS) i definiuje poziomy bezpieczeństwa (Security Level, SL 1–4), które opisują zdolność danego komponentu do ochrony przed określonymi klasami zagrożeń.

Część producentów sterowników PAC, jak Emerson, posiada certyfikację IEC 62443-4-1, potwierdzającą, że proces projektowania i wytwarzania ich platform – w tym na przykład PACSystems – spełnia wymogi bezpiecznego cyklu wytwórczego. To istotna informacja przy doborze dostawcy, ponieważ certyfikat ten oznacza, że bezpieczeństwo jest elementem wbudowanym, a nie dokładnym do gotowego produktu.

NIS2 – dyrektywa unijna

Od października 2024 roku dyrektywa NIS2 obowiązuje w polskim prawie. W ślad za nie podąża Ustawa o Krajowym Systemie Cyberbezpieczeństwa. Obejmuje ona operatorów infrastruktury krytycznej oraz ważnych usługodawców w kluczowych sektorach – energetyce, produkcji, wodociągach, transporcie. Nakłada obowiązek wdrożenia środków zarządzania ryzykiem cyberbezpieczeństwa, raportowania incydentów i regularnych audytów.

Migracja PLC w takim zakładzie musi być prowadzona zgodnie z udokumentowaną procedurą zarządzania ryzykiem. W 2026 roku trwają audyty działających systemów i przygotowywane są projekty wdrożeniowe, gdyż przedsiębiorstwa mają czas do 3 kwietnia 2027 na pełne wdrożenie wymagań i realne dostosowanie systemów, procedur i bezpieczeństwa. Na 2028 zaplanowane są pierwsze obowiązkowe audyty cyberbezpieczeństwa.

ISO/IEC 27001 w kontekście OT

Choć ISO 27001 jest normą zorientowaną na bezpieczeństwo informacji (IT), jej wymagania dotyczące zarządzania ryzykiem, kontroli dostępu i ciągłości działania coraz częściej obejmują także środowiska OT – szczególnie tam, gdzie granica między IT a OT zaciera się mocno z uwagi na prowadzone projekty cyfryzacji mające na celu podnoszenie efektywności. Migracja PLC powinna być prowadzona w ramach udokumentowanego systemu zarządzania bezpieczeństwem.

7 praktycznych kroków do bezpiecznej migracji PLC

Zrobienie ich pozwala ograniczyć ryzyko przestojów, błędów konfiguracyjnych oraz problemów z cyberbezpieczeństwem podczas modernizacji systemów automatyki. Co więc wykonywać i w jakiej kolejności?

Krok 1 – Inwentaryzacja i ocena ryzyka przed startem projektu

Przed wymianą jakiegokolwiek sterownika PLC należy stworzyć pełny spis wszystkich urządzeń OT pracujących na sieci: modele PLC, wersje firmware, używane protokoły (Modbus, PROFINET, EtherNet/IP, OPC-UA), fizyczne porty komunikacyjne. Konieczne jest zidentyfikowanie znanych podatności (CVE) dla każdego modelu. To punkt wyjścia do oceny ryzyka – bez niej projekt migracji jest prowadzony w ciemno.

Krok 2 – Segmentacja sieci OT – DMZ między biurem a produkcją

Zanim zostanie podłączony pierwszy nowy sterownik PLC, koniecznie trzeba zadbać o właściwą segmentację sieci. Strefa DMZ (Demilitarized Zone) między siecią korporacyjną a siecią produkcyjną to absolutne minimum. Stary i nowy PLC w tym samym projekcie migracji powinny znajdować się w kontrolowanym środowisku sieciowym, nie w jednej płaskiej sieci z dostępem do Internetu i do zdalnych dostępów.

Krok 3 – Zarządzanie dostępem uprzywilejowanym (PAM) dla integratorów

Każdy zewnętrzny integrator, serwisant OEM i inżynier projektowy który świadczy usługi wdrożeniowe podczas procesu migracji powinien mieć dostęp wyłącznie do tych zasobów, które są niezbędne do wykonania jego zadania – i tylko w określonym oknie czasowym. Wdrożenie rozwiązania PAM (Privileged Access Management) pozwala rejestrować i nagrywać sesje zdalnego dostępu, co jest kluczowe zarówno podczas incydentu, jak i w trakcie audytu.

Krok 4 – Testowanie programu PLC

Nowy program sterownika – zanim zostanie wgrany na produkcyjny PLC – powinien przejść pełny cykl testów. Minimum to testy „na biurku”, a najlepiej, aby były prowadzone w środowisku emulowanym lub na specjalnym stanowisku testowym w środowisku sandbox. Oczywiście nie wszyscy mają dostęp do takich zasobów, jednak im więcej testów przeprowadzimy, tym mniejsze ryzyko podczas wdrożenia. Weryfikacja powinna obejmować nie tylko poprawność logiki technologicznej, ale również konfigurację bezpieczeństwa: czy wyłączono nieużywane porty i usługi, zmieniono domyślne hasła oraz poprawnie skonfigurowano listy kontroli dostępu.

Krok 5 – Hardening sterownika przed podłączeniem do sieci produkcyjnej

Każdy nowy PLC powinien przejść procedurę hardeningu: aktualizacja firmware do najnowszej stabilnej wersji, wyłączenie nieużywanych protokołów i portów fizycznych (USB, RS-232), zmiana fabrycznych haseł dostępu, konfiguracja mechanizmów uwierzytelniania. Warto przy wyborze nowej platformy PLC/PAC zwrócić uwagę na wbudowane mechanizmy bezpieczeństwa sprzętowego. Niektórzy producenci, jak Emerson w platformach PACSystems, wbudowują w architekturę sterownika funkcje takie jak Secure Boot (weryfikacja integralności firmware przy każdym starcie) oraz skonfigurowany fabrycznie firewall na poziomie kontrolera – co znacząco redukuje powierzchnię ataku jeszcze przed pierwszym uruchomieniem w środowisku produkcyjnym.

Krok 6 – Plan reagowania na incydenty specyficzne dla fazy migracji

Migracja to czas podwyższonego ryzyka – plan reagowania na potencjalne ryzyka powinien zostać zaktualizowany przed startem projektu, nie po pierwszym incydencie. Koniczne jest zabezpieczenie niezbędnych zasobów oraz określenie procedur dla scenariuszy specyficznych dla fazy przejściowej: co zrobić, gdy zostanie wykryty nieautoryzowany dostęp do sieci OT, gdy oprogramowanie inżynierskie zachowa się w nieoczekiwany sposób, lub gdy zdalny dostęp integratora zostanie przejęty.

Krok 7 – Audyt po migracji: weryfikacja, dokumentacja, test penetracyjny OT

Po uruchomieniu nowego systemu konieczne jest przeprowadzenia audytu konfiguracji bezpieczeństwa wszystkich nowych sterowników PLC. Kontroluje się czy wszystkie tymczasowe dostępy i połączenia sieciowe zostały zamknięte, zaktualizuje dokumentację powdrożeniową oraz rozważa wykonanie testu penetracyjnego środowiska OT. Najlepsze praktyki pokazują, że projekty migracyjne prowadzone z wbudowanym procesem audytu końcowego generują znacznie mniej incydentów w pierwszych 12 miesiącach eksploatacji.

4 pułapki, które kosztują najwięcej

To zazwyczaj te przypadki, które na pierwszy rzut oka wydają się mało istotne lub są pomijane pod presją czasu. W praktyce to właśnie one najczęściej prowadzą do błędów wdrożeniowych, przestojów lub problemów z bezpieczeństwem, które generują największe koszty. Na co zwracać szczególna uwagę?

Pułapka 1: Odkładanie aktualizacji firmware na „po migracji”

To jeden z najczęstszych błędów. Stary sterownik PLC z niezałatanymi podatnościami zostaje w sieci miesiącami – bo jest jeszcze potrzebny do porównań, albo nie było czasu na aktualizację. Tymczasem znane podatności CVE dla starych modeli PLC są publicznie dostępne podobnie jak listy exploitów. Jak sobie z tym poradzić?

Przed startem projektu warto zdefiniować maksymalny dopuszczalny czas, przez jaki stary sterownik PLC może pozostawać w sieci OT – zapisuje się to w harmonogramie jako twardy deadline. Jeśli aktualizacja firmware jest niemożliwa (brak wsparcia producenta), stary PLC powinien zostać fizycznie odseparowany od reszty sieci lub przeniesiony do izolowanej podsieci z ograniczonym dostępem i monitoringiem ruchu.

Pułapka 2: Zbyt szerokie uprawnienia dla zewnętrznych integratorów

Laptop serwisowy bez EDR (Endpoint Detection and Response), bez aktualnego antywirusa, podłączony bezpośrednio do switcha na hali produkcyjnej to scenariusz, który powtarza się w dziesiątkach zakładów przy każdej migracji. Integrator dostaje dostęp do całej sieci OT, bo tak jest prościej, a weryfikacja jego sprzętu wydaje się zbędną biurokracją. Wystarczy, że jego maszyna była wcześniej podłączona do zainfekowanej sieci, żeby infekcja przeniosła się na sterowniki w naszym zakładzie. Jak sobie z tym poradzić?

Koniecznie wprowadza się obowiązkową procedurę onboardingu dla każdego zewnętrznego dostawcy: weryfikacja aktualności systemu operacyjnego i oprogramowania antywirusowego przed wejściem do sieci OT, podpisanie polityki bezpieczeństwa i stosowanie zasady minimalnych uprawnień (tylko te zasoby i tylko w tym czasie, kiedy są potrzebne). Warto rozważyć też udostępnianie zdalnego dostępu wyłącznie przez specjalny, monitorowany jump server z nagrywaniem sesji.

Pułapka 3: Brak izolacji sieci w fazie przejściowej

Stary i nowy PLC w jednej płaskiej sieci, połączonej z siecią biurową przez jeden router bez firewalla – często spotykana praktyka i potencjał na poważny incydent. W normalnych warunkach nikt by tak nie skonfigurował instalacji. Ale podczas migracji, pod presją czasu i kosztów, tymczasowe mosty sieciowe stają się permanentną architekturą. Incydent Norsk Hydro pokazał, co się dzieje, gdy sieć IT i OT są nadmiernie zintegrowane bez właściwej segmentacji. Jak sobie z tym poradzić?

Jeszcze przed podłączeniem nowego sterownika trzeba sporządzić schemat docelowej architektury sieciowej z wyraźnie zaznaczonymi strefami i punktami styku IT/OT. Każde tymczasowe połączenie sieciowe na czas migracji powinno mieć zdefiniowaną datę wyłączenia i być objęte monitoringiem ruchu – nieautoryzowana komunikacja między strefami powinna generować alert, aby nie pozostała niezauważona.

Pułapka 4: Pominięcie testów bezpieczeństwa oprogramowania inżynierskiego

Oprogramowanie narzędziowe to narzędzia o ogromnych uprawnieniach inżynierskich z możliwością modyfikacji każdego urządzenia danego dostawcy. Podłączenie laptopa z takim oprogramowaniem do sieci OT rzadko poprzedza jakikolwiek skan bezpieczeństwa. Zhakowanie narzędzia inżynierskiego może umożliwić nieautoryzowaną modyfikację logiki drabinkowej lub parametrów procesu bez pozostawienia śladów w standardowych logach systemowych. Jak sobie z tym poradzić?

Warto wprowadzić zasadę specjalnych stacji roboczych przeznaczonych do pracy z oprogramowaniem inżynierskim – najlepiej niepodłączonych do ogólnej sieci korporacyjnej. Przed każdym podłączeniem laptopa inżynierskiego do sieci OT warto wykonać skan pod kątem złośliwego oprogramowania praz weryfikację integralności pliku projektu PLC – nieoczekiwana zmiana sumy kontrolnej programu sterownika to sygnał alarmowy wymagający natychmiastowej analizy.

Migracja sterownika PLC – projekt bezpieczeństwa operacyjnego

Wymiana sterownika PLC jest często traktowana jako projekt inżynierski: dobierz nowy model, przepisz program, uruchom, zamknij projekt. Tymczasem każda migracja systemu automatyki przemysłowej to jednocześnie projekt cyberbezpieczeństwa – z oknem podatności, które może trwać tygodnie lub miesiące, i konsekwencjami, które wychodzą daleko poza budżet projektu. Regulacje IEC 62443, NIS2, ISO 27001, wchodzące CRA przestały być teorią, stają się praktyką. Audytorzy pytają o udokumentowane procedury zarządzania ryzykiem przy zmianach w infrastrukturze OT, a ubezpieczyciele cyber coraz częściej uzależniają warunki polisy od wykazania, że organizacja stosuje kontrole bezpieczeństwa w środowiskach przemysłowych.

Ostatecznie migracja sterownika PLC powinna być traktowana nie jako jednorazowa operacja techniczna, ale jako element szerszego procesu zarządzania ryzykiem w środowisku OT. To właśnie w tym momencie organizacja decyduje nie tylko o modernizacji infrastruktury, ale również o poziomie odporności na zagrożenia cybernetyczne na kolejne lata. Dlatego kluczowe jest, aby każdy projekt migracyjny był planowany i realizowany w oparciu o standardy bezpieczeństwa, udokumentowane procedury oraz świadomy wybór technologii, które już na poziomie architektury wspierają wymagania współczesnych regulacji.