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.

Dyrektywa NIS2. Cyberbezpieczeństwo systemów automatyki przemysłowej

Skala cyberataków na przemysł rośnie w szybkim tempie – według DHS w 2010 r. było ich 41, a w 2016 r. już 290. W latach 2023-2024 odnotowano ok. 1,4 tys. incydentów w infrastrukturze krytycznej, a więc takiej, która ma fundamentalne znaczenie dla bezpieczeństwa, gospodarki i porządku publicznego. Do kategorii tej zalicza się więc na przykład systemy generowania, przechowywania i transportu energii oraz infrastrukturę wodno-kanalizacyjną, transport i produkcję.

Ponad połowa ze wspominanych incydentów dotyczyła właśnie tych obszarów. Tylko w I kwartale 2024 r. liczba ataków na firmy produkcyjne wzrosła o 28% w porównaniu z poprzednim kwartałem, osiągając rekordowy poziom. Prognozy mówią o kosztach sięgających bilionów dolarów w ciągu kilku lat, a 77% przedsiębiorstw wciąż nie ma spójnego planu reagowania. W tej sytuacji zapewnienie cyberbezpieczeństwa w automatyce przemysłowej staje się kluczową koniecznością.

Szczególne wyzwania dotyczące bezpieczeństwa w obszarze infrastruktury krytycznej wynikają z faktu, że stale przyspiesza transformacja technologiczna szczególnie w wymiarze cyfrowym. Dodatkowo na przedsiębiorstwa nakładane są nowe ogólnoeuropejskie, a czasem globalne regulacje dotyczące ochrony klimatu i ograniczania emisji CO2. Rośnie nacisk na odnawialne źródła energii, a to oznacza, że instaluje się coraz więcej nowej, niezbędnej infrastruktury. Jednocześnie zmniejsza się zapotrzebowanie na energię z paliw kopalnych.

Ta zmiana technologiczna może być źródłem nowych podatności. Firmy zapewniające infrastrukturę krytyczną muszą więc szybko wdrażać nowoczesne zabezpieczenia i inwestować w zautomatyzowane systemy ochrony. Przykładem są wielowarstwowe rozwiązania PACSystems™ firmy Emerson, rekomendowane przez DHS, które zapewniają kompleksową ochronę przed zagrożeniami.

Strategia zarządzania bezpieczeństwem

Emerson opiera strategię bezpieczeństwa na analizie ryzyka, aby łączyć korzyści z otwartej komunikacji, wyższej produktywności systemów i skutecznej ochrony technologii operacyjnych (OT). Krytyczne obszary są stale monitorowane, a wraz ze zmianą technologii i charakteru zagrożeń działania są elastycznie modyfikowane. Takie podejście umożliwia szybkie reagowanie na nowe ryzyka oraz ochronę przed wewnętrznymi i zewnętrznymi zagrożeniami sieciowymi. Strategia obejmuje dwa kluczowe etapy: proces produkcji urządzeń oraz ich późniejszą eksploatację u klientów końcowych, co pozwala zwiększać bezpieczeństwo dostarczanych rozwiązań. Jakie zatem aspekty kontroluje Emerson, aby podnieść bezpieczeństwo dostarczanych produktów i rozwiązań?

Technologia produkcji Emerson PACSystems zgodna z IEC 62443

Firma jako kluczowy dostawca technologii automatyzacji posiada certyfikat IEC 62443 dla całego cyklu życia swoich produktów – od projektowania i rozwoju, przez produkcję i wdrożenie, po eksploatację i konserwację. Norma ta określa wymagania ochrony systemów automatyki przed zagrożeniami w środowiskach przemysłowych. Certyfikacja obejmuje m.in. współpracę z zaufanymi dostawcami, zabezpieczenie łańcucha dostaw oraz wdrażanie mechanizmów zwiększających bezpieczeństwo systemów.

Emerson współpracuje wyłącznie ze sprawdzonymi dostawcami spełniającymi najwyższe normy branżowe. Partnerami firmy są m.in. Intel, NPX, ARM, Qualcomm, Microchip Technology i Texas Instruments. Wykorzystanie komponentów od światowych liderów, objętych rygorystycznymi regulacjami bezpieczeństwa, zapewnia solidne fundamenty do tworzenia niezawodnych systemów.

Bezpieczna wymiana danych

Kontrolery PACSystems zapewniają najwyższy poziom bezpieczeństwa komunikacji w sieciach przemysłowych dzięki protokołowi OPC-UA, który oferuje szyfrowanie, uwierzytelnianie oraz ochronę przed podszywaniem się pod urządzenia. Hasła i certyfikaty uniemożliwiają przechwycenie danych czy ingerencję w proces sterowania, nawet przy fizycznym dostępie do sprzętu. OPC-UA jest standardem we wszystkich urządzeniach PACSystems i pozwala na bezpieczną integrację sprzętu różnych producentów, co ma kluczowe znaczenie w złożonych, wieloplatformowych systemach automatyki.

Mechanizm Secure Boot zintegrowany w kontrolerach PACSystems

Emerson wyposaża każdy ze swoich kontrolerów w mechanizm zwany Secure Boot, który weryfikuje podpisy cyfrowe i źródło bootloadera, kernela oraz sterowników. Chroni to przed uruchomieniem nieautoryzowanego lub złośliwego kodu, blokując start urządzenia w razie wykrycia zmian. Rozwiązanie zabezpiecza m.in. przed atakami typu supply chain czy Evil Maid, uniemożliwiając instalację złośliwego firmware’u nawet przy fizycznym dostępie do sprzętu. Secure Boot stanowi pierwszą linię obrony kluczowych systemów automatyki przed atakami na najniższym poziomie systemu.

Secure Load – bezpieczeństwo przy ładowaniu kodu do urządzenia

Secure Load w kontrolerach PACSystems weryfikuje podpis cyfrowy każdego wgrywanego programu, dopuszczając jedynie zaufane aplikacje. Chroni to przed sabotażem, także ze strony personelu i spełnia wymagania norm VDE-AR-N 4110/4120 oraz IEC 62443, tworząc rejestr wszystkich prób ładowania kodu. Nawet przy fizycznym dostępie do urządzenia nie można uruchomić nieautoryzowanego oprogramowania.

Zintegrowany moduł Trusted Platform Module

Wybrane kontrolery PACSystems wyposażono w moduł Trusted Platform Module (TPM) – sprzętowy „sejf” do bezpiecznego przechowywania kluczy szyfrujących, haseł i certyfikatów. TPM odpowiada za uwierzytelnianie urządzeń, ochronę dostępu do systemu operacyjnego oraz wykrywanie nieautoryzowanych zmian w systemie. Wspiera mechanizmy Secure Boot i Secure Load, zwiększając odporność systemu na złośliwe oprogramowanie, w tym rootkity, które mogą przejąć kontrolę nad urządzeniem i ukryć swoją obecność. TPM stanowi kluczową warstwę ochrony przed zaawansowanymi cyberatakami, takimi jak Stuxnet, który w 2010 roku spowodował fizyczne uszkodzenie wirówek w irańskim programie nuklearnym.

Certyfikacja Achilles dla kontrolerów Emerson PACSystems

Kontrolery Emerson PACSystems posiadają certyfikat Achilles, potwierdzający odporność ich interfejsów komunikacyjnych na zagrożenia sieciowe. Certyfikacja, opracowana przez Wurldtech i szeroko stosowana w przemyśle, obejmuje testy protokołów, odporność na przeciążenia oraz różne scenariusze cyberataków. Poziomy certyfikacji:

• Level 1 sprawdza podstawowe protokoły (Ethernet, IP, TCP/UDP),
• Level 2 obejmuje zaawansowane testy, m.in. odporność na ataki typu DoS i złożone wzorce ruchu.

Certyfikat świadczy o niezawodności i bezpieczeństwie urządzeń, co jest kluczowe w infrastrukturze krytycznej; wszystkie kontrolery PACSystems, w tym CPE100, CPE200, CPL400 i RX3i, są poddawane tym testom.

Enchanced Security w PAC Machine Edition

Enhanced Security w PAC Machine Edition (PME 9.5+) zabezpiecza środowisko programistyczne i komunikację z kontrolerami PACSystems. Funkcje tego systemu obejmują kontrolę dostępu opartą na rolach (RBAC), uwierzytelnianie użytkowników, weryfikację podpisów cyfrowych firmware i programów, autoryzację przy pobieraniu/wgrywaniu kodu, szyfrowanie komunikacji (TLS) oraz audyt zmian (Change Management). Rozwiązanie to chroni przed nieautoryzowanymi modyfikacjami, sabotażem wewnętrznym i przejęciem komunikacji w sieci OT, spełniając normy IEC 62443, NERC CIP i ISA/IEC 61511.

Rejestrowanie zdarzeń bezpieczeństwa w kontrolerach PACSystems

Kontrolery PACSystems rejestrują zdarzenia operacyjne w dwóch 64-wpisowych tabelach błędów, zawierających czas i datę zdarzenia. Tabele można odczytać lokalnie lub zdalnie, a dane eksportować do pliku XML, tekstowego lub przesłać do zewnętrznego systemu SIEM w celu audytu.

Większość zdarzeń dotyczy problemów funkcjonalnych, np. awarii sprzętu, ale rejestrowane są też kluczowe zdarzenia bezpieczeństwa:

• Błąd uwierzytelnienia – nieudana próba logowania przez Service Request zapisuje błąd „Błąd dostępu do hosta” i ustawia zmienną systemową #BAD_PWD.
• Błąd kontroli dostępu – próba wykonania funkcji bez odpowiednich uprawnień zapisuje błąd „Wykryto naruszenie listy kontroli dostępu”.

Dzięki temu kontroler umożliwia monitoring i audyt zdarzeń związanych z bezpieczeństwem systemu.

Redundantna architektura kontrolerów PACSystems HSR

W systemach krytycznych istotna jest nadmiarowa architektura, która zapewnia ciągłość produkcji przy awarii lub aktualizacji kontrolera. Kontrolery Emerson PACSystems obsługują gorącą rezerwę, automatycznie przełączając się na jednostkę zapasową bez przerywania pracy, informując jedynie personel o zdarzeniu.

Redundancja obejmuje jednostki centralne, zasilacze, moduły komunikacyjne, synchronizacji danych i sygnałowe. Przełączenie aktywnego kontrolera na rezerwowy odbywa się w ciągu milisekund, w trakcie jednego cyklu programowego, bez obciążania jednostek centralnych dodatkowymi procedurami.

Konfiguracja i programowanie układu nie różnią się od pracy pojedynczego kontrolera dzięki wbudowanym mechanizmom synchronizacji w PAC Machine Edition. Komunikacja z I/O i urządzeniami wykonawczymi jest bezpieczna i niezawodna. Obsługa Profinet MRP S2 RING pozwala utrzymać komunikację w całym systemie nawet przy awarii segmentu sieci lub wprowadzeniu urządzenia w tryb serwisowy.

Wytyczne dotyczące konfiguracji kontrolerów pod kątem bezpieczeństwa

Emerson kładzie duży nacisk na wdrażanie wytycznych i dobrych praktyk, które pozwalają maksymalnie podnieść poziom bezpieczeństwa systemów PACSystems. Dokument Controller Secure Deployment Guide, regularnie aktualizowany, zbiera wszystkie kluczowe zasady i procedury związane z bezpieczeństwem kontrolerów.

Dostawca wspiera także edukację użytkowników, udostępniając informacje o wykrytych podatnościach oraz wskazówki, jak zabezpieczyć system przed potencjalnymi atakami.

Podsumowując

Sama liczba opisanych powyżej mechanizmów i technologii ochronnych pokazuje, że współcześnie walka z cyberzagrożeniami, zwłaszcza w przypadku ochrony infrastruktury krytycznej, wymaga całego arsenału komplementarnych rozwiązań. Fakt, że zagrożeń tych przybywa sprawia, że coraz więcej przedsiębiorstw, tych rozwiązań będzie potrzebować. Ponieważ rodzaje zagrożeń stale ulegają modyfikacjom i wciąż pojawiają się nowe, aby skutecznie zabezpieczać się przed obecnymi i przyszłymi, warto postawić na sprawdzonych partnerów technologicznych – takich jak Emerson –, którzy kwestię cyberbezpieczeństwa traktują kompleksowo. Tylko tak można ochronić cenne zasoby firmy, utrzymać ciągłość działalności, zapobiec stratom finansowym i wizerunkowym.