Dlaczego fabryka staje się celem ataków – i co to zmienia dla produkcji
OT i IoT jako „brama” do produkcji: od PLC po czujniki za 200 zł
Sieci OT i IoT w fabryce to dziś nie tylko sterowniki PLC i panele HMI. To rozbudowana układanka: sterowanie, diagnostyka, monitoring, raportowanie, a coraz częściej także zdalne utrzymanie i integracja z chmurą. Każdy element, który „gada po sieci”, jest potencjalnym punktem wejścia – od szafy sterowniczej za miliony, po tani czujnik temperatury zamówiony w promocji.
Z perspektywy atakującego to złoty target. Jeśli przejmie kontrolę nad częścią sieci OT, ma wpływ na realne procesy: może zakłócić produkcję, jakościowo „podtruć” partię wyrobów, rozkalibrować linię, a nawet doprowadzić do zagrożenia dla ludzi. Nie musi od razu wyłączać całej fabryki – często wystarczy sparaliżować jedną krytyczną linię, by firma stanęła operacyjnie.
Do tego dochodzi IoT: bramki zbierające dane z czujników, kamery IP, liczniki energii, systemy klimatyzacji, tablice andon, telemetria. Wiele z tych urządzeń powstało z myślą „żeby działało”, a nie „żeby było bezpieczne”. Fabryka, która wprowadziła kilkaset tanich sensorów bez realnej kontroli, tworzy sieć tylnego wejścia, o której nikt nie ma pełnego obrazu.
OT kontra klasyczne IT: inne priorytety, inne problemy
W IT priorytetem jest zwykle poufność i integralność danych, a dopiero potem dostępność. W OT kolejność jest odwrotna: produkcja ma działać. Sterownik PLC, który zatrzyma linię, bo „instaluje aktualizacje bezpieczeństwa”, to koszmar każdego kierownika utrzymania ruchu. Dlatego cyberbezpieczeństwo w fabryce musi uwzględniać:
długi cykl życia maszyn – sterowniki i panele działają po 10–20 lat, często z archaicznymi systemami i bez wsparcia producenta,
niechęć do zmian – każda modyfikacja sieci czy konfiguracji to potencjalny przestój, ryzyko błędów i reklamacji,
specyficzne protokoły przemysłowe – wiele z nich nie zna pojęcia szyfrowania czy uwierzytelniania,
ścisłą zależność od fizycznego procesu – cyberatak może szybko przełożyć się na szkody materialne.
Tradycyjne podejście „załatamy wszystko, wdrożymy endpoint security i SIEM” nie zadziała 1:1. Potrzebne są metody, które szanują ciągłość produkcji i charakter maszyn: segmentacja zamiast agresywnego patchowania, monitoring sieci zamiast instalowania agentów na każdym panelu HMI, stopniowe zmiany w oknach serwisowych zamiast weekendowego „big bangu”.
Do tego dochodzą mniej „wysokopoziomowe” incydenty: skrypty skanujące Internet w poszukiwaniu otwartych portów, źle zabezpieczone VPN-y, panele HMI widoczne z zewnątrz. Wystarczy jeden nieświadomy klik w załącznik na komputerze inżyniera, by dostać się do sieci, która ma trasę do sterowników.
Jak wygląda „mały” incydent, który robi duże szkody
Dobry przykład to sytuacja, gdy atakujący lub zwykłe malware nie wyłącza całej fabryki, ale blokuje jeden etap. Przykładowy scenariusz z praktyki: infekcja laptopa serwisowego, z którego inżynier łączy się do szafy sterowniczej przez VPN. Złośliwe oprogramowanie nie atakuje od razu PLC, tylko powoli zmienia konfigurację jednego modułu odpowiedzialnego za etykietowanie.
Linia pakuje normalnie, ale co kilkaset sztuk pojawia się produkt bez kompletnej etykiety. System kontroli jakości widzi skok w brakach, dział jakości zaczyna wycofywać partie, a produkcja spowalnia. Nikt nie szuka od razu cyberataku – wszyscy podejrzewają awarię czujnika lub mechaniczne uszkodzenie. Szkody liczy się w dziennych wynagrodzeniach i kosztach reklamacji, a nie w liczbie zainfekowanych serwerów.
Dlaczego argument „20 lat spokoju” przestał cokolwiek znaczyć
Wiele zakładów żyje przekonaniem: „Przecież od 20 lat mamy te same maszyny i nigdy nic się nie stało”. Tyle że przez te 20 lat:
podłączono więcej systemów do Internetu, chmury, integratorów,
IoT rozlało się po hali – od czujników drgań, po inteligentne kamery,
napastnicy przenieśli swoje zainteresowania z banków i sklepów na przemysł, bo marża jest wyższa, a obrona słabsza,
do sieci trafiły dziesiątki „tymczasowych” rozwiązań, które zostały „na zawsze”.
Argument „nic się nam nie stało” w praktyce oznacza raczej „mieliśmy szczęście” lub „nie zauważyliśmy problemu”. Pytanie nie brzmi już „czy coś się wydarzy”, tylko „czy jesteśmy w stanie ograniczyć skutki i utrzymać produkcję, kiedy się wydarzy”.
Podstawy: co w ogóle znajduje się w Twojej sieci OT i IoT
Jakie urządzenia faktycznie pracują w sieci produkcyjnej
Pierwszy krok do cyberbezpieczeństwa w fabryce to odpowiedź na pozornie banalne pytanie: co jest podłączone do sieci. W praktyce lista jest dłuższa, niż większość osób zakłada. Typowe elementy:
Sterowniki PLC – serce automatyki; różne generacje, od świeżych po „dinozaury” bez wsparcia,
panele HMI – wizualizacja i lokalne sterowanie, często z Windows CE lub wysłużonym Windowsem,
systemy SCADA – serwery, stacje operatorskie, często wpięte jednocześnie do sieci OT i biurowej,
serwery historian – zapis historii produkcji, parametrów procesów, trendów,
czujniki i urządzenia IoT – sensory temperatury, wilgotności, liczniki, czujniki wibracji,
bramki IoT – zbierają dane i wysyłają je do chmury lub systemu MES,
kamery IP – monitoring linii, wizyjna kontrola jakości, bezpieczeństwo fizyczne,
panele operatorskie i terminale – często z przeglądarką, RDP lub klientem SCADA,
laptopy serwisowe – najbardziej niedocenione „wejście” do sieci OT, zwykle z adminem lokalnym bez hasła,
drukarki etykiet, wagowe, urządzenia peryferyjne – z własnym firmware, niekoniecznie aktualnym.
Do tego dochodzą urządzenia, o których nikt już nie pamięta: stary PC w szafie służący kiedyś do konfiguracji, modem GSM do powiadomień SMS, router Wi-Fi do „tymczasowego” dostępu na linii. Z punktu widzenia atakującego każdy z tych elementów może być trampoliną do bardziej krytycznych części sieci.
Kluczowe protokoły: Modbus, PROFINET, OPC UA i cała reszta
W sieciach OT królują protokoły przemysłowe. Ich celem historycznie była niezawodność i prostota, a nie bezpieczeństwo. Przykładowo:
Modbus/TCP – bardzo prosty, czytelny nawet dla początkującego analityka; zwykle bez szyfrowania i uwierzytelniania,
PROFINET – standard w wielu liniach produkcyjnych, również bez natywnego, szeroko stosowanego szyfrowania,
OPC UA – nowszy, z mechanizmami bezpieczeństwa (szyfrowanie, certyfikaty), ale często wdrażany w trybie „żeby działało”, bez pełnej konfiguracji bezpieczeństwa,
protokoły producentów – dedykowane, mało udokumentowane, często równie „nagie” jak Modbus.
To oznacza, że ktoś, kto uzyska dostęp do sieci OT, może w wielu przypadkach:
podsłuchiwać komunikację między PLC a SCADA,
wstrzykiwać własne komendy,
manipulować wartościami odczytów i zapisów bez wykrycia przez urządzenia końcowe.
Zapomniane elementy, które najczęściej otwierają drzwi
W każdym zakładzie są „trupy w szafie”, które z perspektywy cyberbezpieczeństwa są tykającą bombą:
panele HMI z Windows XP lub starym Windows Embedded, dawno poza wsparciem,
modemy GSM – kiedyś używane do wysyłania SMS-ów, dziś nikt nie pamięta, czy są jeszcze aktywne,
tunel VPN od integratora, założony „na chwilę” do uruchomienia linii i nigdy poprawnie zamknięty,
domowy router Wi-Fi „na szybko”, z defaultowymi hasłami i otwartym dostępem do całej sieci produkcyjnej,
stare serwery SCADA z Windows 7, spięte jednocześnie z siecią biurową i OT.
Te elementy zwykle nie figurują w oficjalnej dokumentacji lub są opisane ogólnikowo. Podczas inwentaryzacji warto rozmawiać z inżynierami i technikami, którzy „od zawsze” pracują z daną linią – często wiedzą o takich rozwiązaniach więcej niż administratorzy IT.
Prosta inwentaryzacja sieci bez drogiego systemu
Profesjonalne narzędzia do inventory i monitoringu OT są świetne, ale nie każdy zakład może od nich zacząć. Na start da się wiele zrobić prostymi środkami:
Dlatego tak ważne jest, by ruch tych protokołów był dobrze segmentowany i monitorowany. Szyfrowanie „po całości” bywa trudne w starszych systemach, ale można chronić kanały komunikacji na poziomie sieci (VPN, tunele), o czym szerzej pisze choćby serwis Informatyka, Nowe technologie, AI.
konfiguracja mirror port na kluczowym switchu i podłączenie prostego analizatora (np. laptop z Wiresharkiem),
skanowanie segmentów adresowych narzędziami typu nmap, ale ostrożnie – najlepiej w oknie serwisowym lub na testowej podsieci,
zestawienie informacji od integratorów, serwisu i dokumentacji projektowej w jedno, aktualizowane zestawienie.
Taka baza nie musi być od razu idealna. Chodzi o widoczność: który IP należy do jakiego urządzenia, do jakiej linii, kto odpowiada za utrzymanie, jaki jest system operacyjny i wersja firmware. Nawet prosty arkusz z tymi danymi jest ogromnym krokiem naprzód.
Jak opisywać sieć, żeby inżynierowie nie uciekli
Diagramy dla OT nie mogą wyglądać jak slajdy z konferencji IT. Inżynier utrzymania ruchu potrzebuje zobaczyć:
podział na linie produkcyjne i ich elementy: PLC, HMI, napędy, czujniki,
fizyczne położenie szaf, segmentów, switchy,
powiązanie z procesem technologicznym: który fragment sieci steruje którym etapem,
logiczne połączenia między liniami, SCADA, MES i siecią biurową.
schemat „sieciowy” – VLAN-y, firewalle, routery, połączenia zewnętrzne.
Dopiero razem dają pełny obraz. Dzięki temu łatwiej rozmawiać o zmianach w architekturze, bo każdy widzi, jak firewall czy nowy VLAN wpłyną na realną linię i pracę operatorów.
Źródło: Pexels | Autor: Tima Miroshnichenko
Ocena ryzyka w środowisku OT: na chłodno, bez paniki i bajek
Ryzyko w IT a ryzyko w OT – inne skutki, inne priorytety
W klasycznym IT ryzyko często sprowadza się do utraty danych, wycieku informacji, przestojów usług. W OT skutki sięgają znacznie dalej:
zagrożenie bezpieczeństwa ludzi – błędnie sterowane maszyny, nieprawidłowe blokady,
uszkodzenie sprzętu – zły sposób zatrzymania linii może fizycznie zniszczyć napędy czy elementy mechaniczne,
długie przestoje – awaria jednego sterownika może zatrzymać produkcję na dni,
problemy jakościowe – trudniejsze do wykrycia, za to kosztowniejsze w dłuższej perspektywie.
Dlatego ocena ryzyka w OT musi silniej uwzględniać bezpieczeństwo ludzi i ciągłość produkcji. Utrata poufności danych bywa tu „dodatkowym problemem”, a nie najważniejszym skutkiem.
Prosty model: zasób – zagrożenie – podatność – skutek
Jak rozmawiać o ryzyku, żeby nie wyłączyć fabryki „na wszelki wypadek”
Klasyczna reakcja na cyberzagrożenia to dwa skrajne podejścia: „nic się nie stanie, jedziemy dalej” albo „wszystko odciąć, najlepiej wyciągnąć wtyczkę z gniazdka”. W środowisku OT oba są równie szkodliwe. Potrzebne jest podejście pośrednie: świadome ryzyko.
Dobrze sprawdza się proste pytanie zadawane przy każdym scenariuszu:
czy naprawdę musimy zatrzymywać produkcję, żeby to zminimalizować,
jeśli tak – czy da się to zrobić stopniowo albo w oknie serwisowym,
jeśli nie – jakie dodatkowe zabezpieczenia organizacyjne możemy wprowadzić (procedury, nadzór, alarmy).
Przykład: zamiast natychmiast wymieniać wszystkie panele HMI z Windows XP, można:
odizolować je sieciowo (osobny VLAN, ograniczone reguły na firewallu),
zablokować dostęp z biura i zdalny RDP,
uzgodnić plan wymiany w harmonogramie postoju remontowego.
Ryzyko nie znika, ale jest świadomie zarządzane i wpisane w realne możliwości zakładu, a nie w idealny model z podręcznika.
Jak oceniać prawdopodobieństwo, gdy „nikt nas nie atakuje”
Wielu dyrektorów produkcji powie: „jesteśmy za mali, żeby ktoś się nami interesował”. Problem w tym, że współczesne ataki przemysłowe często są masowe, a nie „na zamówienie”. Z perspektywy grupy ransomware każdy zakład to kolejna szansa na okup.
Przy ocenie prawdopodobieństwa nie ma sensu zgadywać, czy dana grupa wybierze akurat ten zakład. Lepsza jest skala:
wysokie – urządzenia wystawione do Internetu, stare VPN bez MFA, modemy GSM bez kontroli,
średnie – dostęp z biura do OT bez silnej kontroli, słabe hasła, brak segmentacji,
niskie – dobrze segmentowana sieć, kontrolowany dostęp zdalny, aktualne systemy krytyczne.
Punktem wyjścia nie jest więc „czy ktoś będzie chciał”, tylko „jak łatwo jest się do nas dostać, jeśli ktoś spróbuje”.
Typowe błędy w analizie ryzyka OT
Kilka pułapek, które regularnie wyskakują w audytach:
koncentracja tylko na IT – piękny audyt serwerowni, zero informacji o szafach na hali,
przepisy zamiast praktyki – dokumenty pełne referencji do norm, ale bez realnych wniosków, co zmienić przy linii,
ignorowanie ludzi – skupienie na firewallach, przy założeniu, że operatorzy zawsze zrobią „tak jak w procedurze”,
brak priorytetów – lista 200 rekomendacji bez wskazania, które 5 trzeba zrobić w tym roku.
Analiza ryzyka, która nie kończy się krótką, zrozumiałą listą działań dla OT, IT i utrzymania ruchu, zwykle ląduje w szufladzie. I tam spokojnie sobie leży aż do pierwszego incydentu.
Jak „przetłumaczyć” wyniki ryzyka na język zarządu i produkcji
Nawet najlepsza analiza nie zadziała, jeśli nikt poza cyberbezpieczeństwem jej nie rozumie. Zamiast mówić: „ryzyko wysokie, CVSS 9.3”, lepiej użyć prostszego języka:
„Incydent w tym obszarze może zatrzymać linię X na co najmniej kilka godzin”.
„Błąd w tym sterowniku może spowodować niekontrolowane zatrzymanie maszyny – ryzyko dla bezpieczeństwa ludzi”.
„Dane jakościowe z tego systemu są podatne na podmianę – może to skutkować reklamacjami i stratą partii produkcyjnej”.
Jeśli przy każdej rekomendacji pojawi się informacja: koszt orientacyjny i wpływ na ciągłość produkcji (brak / krótki postój / dłuższy remont), decyzje inwestycyjne podejmuje się dużo łatwiej, a bezpieczeństwo przestaje być „kosztem bez zwrotu”.
Projektowanie architektury: segmentacja i strefy bezpieczeństwa zamiast jednej wielkiej „pajęczyny”
Dlaczego „jedna płaska sieć” to przepis na katastrofę
W wielu fabrykach topologia wygląda tak: wszystko w jednej lub dwóch podsieciach, switche spięte „tak, żeby działało”, czasem jeden router na wyjściu do świata. To wygodne do uruchomienia, za to fatalne w kontekście incydentu.
Jeśli malware albo atakujący dostanie się do takiej sieci, ma:
swobodę skanowania wszystkich adresów,
łatwy dostęp do PLC, HMI i serwerów SCADA,
szansę na rozprzestrzenienie się w całej fabryce w ciągu minut, a nie dni.
Segmentacja jest jak przegrody przeciwpożarowe: nie zapobiegną każdemu zapaleniu się kabli, ale ograniczą rozmiar pożaru.
Strefy i poziomy: jak uporządkować sieć OT
Sprawdza się podejście, w którym sieć dzieli się na strefy (ang. zones) i kanały komunikacji (ang. conduits). Przykładowy podział:
Poziom 0/1 – urządzenia polowe, napędy, czujniki (często nie mają IP, ale są za PLC),
Poziom 2 – sterowniki PLC, panele HMI, lokalne panele operatorskie,
Poziom 3 – SCADA, serwery produkcyjne, serwer historian,
Poziom 3.5 – strefa DMZ dla produkcji, serwery pośredniczące, bramki danych do biura i chmury,
Poziom 4 – sieć biurowa, systemy ERP, poczta, laptopy użytkowników.
Między tymi poziomami stosuje się kontrolę ruchu – od prostych ACL na routerach po wyspecjalizowane firewalle przemysłowe. Kluczem jest zasada: każde połączenie między strefami musi być świadome i udokumentowane.
DMZ produkcyjne: bufor między biurem a halą
Największym bólem głowy jest zwykle łączenie SCADA/MES z systemami biznesowymi. Bezpośrednie „przebicie” z ERP do PLC to proszenie się o kłopoty. Rozwiązaniem jest DMZ produkcyjne (czasem nazywane strefą 3.5).
W DMZ umieszcza się:
serwery pośredniczące (replikacja danych z historian do raportowania),
Zarówno sieć biurowa, jak i OT łączą się wtedy tylko z DMZ, a nie bezpośrednio między sobą. Odpowiednie reguły firewalla pozwalają kontrolować, kto i kiedy ma dostęp, a ewentualna infekcja po jednej stronie nie przenosi się od razu na drugą.
Segmentacja na poziomie linii produkcyjnych
W praktyce opłaca się dzielić sieć nie tylko „pionowo” (poziomy 0–4), ale też „poziomo” – według linii, stref, a nawet kluczowych maszyn. Typowy, zdroworozsądkowy podział:
oddzielny VLAN lub podsieć dla każdej większej linii produkcyjnej,
sieć serwisowa/inżynierska oddzielona od sieci urządzeń,
osobny segment dla systemów wizyjnych i kamer (z ograniczeniem dostępu do nagrań),
wydzielona sieć dla IoT, bramek sensorów i infrastruktury pomocniczej.
Dzięki temu infekcja w jednym segmencie nie „kładzie” całego zakładu. W skrajnym przypadku możesz odłączyć problematyczną podsieć, utrzymując działanie reszty produkcji.
Małe kroki: jak segmentować sieć bez wielkiego remontu
Wielu inżynierów słysząc „projekt segmentacji” widzi oczami wyobraźni tygodnie przestojów. Często jednak da się to zrobić operacyjnie, etapami:
Inwentaryzacja logiczna – które IP należą do której linii, jakie są zależności.
Wprowadzenie VLAN-ów na istniejących przełącznikach, bez zmiany fizycznego okablowania.
Stopniowe przenoszenie urządzeń (zmiana adresów IP, konfiguracja gateway) w czasie postoju konserwacyjnego.
Dodanie pierwszego firewalla między OT a biurem lub między linią a SCADA.
Taki plan nie wymaga wymiany całej infrastruktury na raz. Czasem wystarczy dokupić kilka przełączników zarządzalnych i jeden sensowny firewall, żeby zrobić jakościowy skok do przodu.
Monitoring ruchu: widzieć, co się dzieje między strefami
Segmentacja bez monitoringu to jak ściany bez okien. W sieci OT przydaje się:
mirror port na kluczowych switchach i przechwytywanie ruchu protokołów przemysłowych,
systemy IDS/IPS dopasowane do OT (rozumieją Modbus, PROFINET, itp.),
proste alerty na nietypowe zjawiska: nagły wzrost ruchu, nowe urządzenia w sieci, zmiana konfiguracji PLC.
Nie trzeba od razu budować SOC-u 24/7. Na początek wystarczy, że ktoś z OT/IT raz w tygodniu spojrzy w raport i zada pytanie: „a skąd wziął się ten nowy adres IP, kto konfigurował ten PLC w niedzielę o 23?”.
Źródło: Pexels | Autor: Tima Miroshnichenko
Zabezpieczenie dostępu: konta, hasła, zdalny serwis i USB z nieznanego źródła
Kontrola kont użytkowników w OT – bez „admin/admin” na każdym kroku
Wiele systemów przemysłowych powstało w czasach, gdy hasło „1234” uchodziło za całkiem sprytne. Potem w tych samych środowiskach pojawiły się laptopy, RDP i VPN-y – ale nawyki zostały.
Z praktycznego punktu widzenia:
systemy SCADA i serwery powinny mieć logowanie imienne, nie jedno konto „operator” dla wszystkich,
uprawnienia administratora powinny być nadawane tylko wybranym osobom, na odrębnych kontach,
konto „integrator” lub „serwis” musi mieć właściciela po stronie zakładu – kogoś, kto wie, kiedy i po co jest używane.
Jeśli słyszysz na hali: „wszyscy znają to hasło, jakby co”, to masz gotowy temat do poprawy.
Polityka haseł dopasowana do realiów hali produkcyjnej
Zbyt restrykcyjna polityka haseł kończy się tym, że operator zapisuje je na taśmie izolacyjnej przy monitorze. Dlatego lepiej szukać kompromisu:
dla operatorów na HMI – krótsze, ale unikalne hasła, zmieniane rzadziej, z podziałem na role (operator / brygadzista / utrzymanie),
dla dostępów zdalnych, VPN, adminów – silne hasła, najlepiej z MFA (aplikacja, token),
dla urządzeń (kamery, bramki IoT, routery) – obowiązkowa zmiana hasła domyślnego i zapis w centralnym, zabezpieczonym repozytorium.
Nie trzeba wymuszać zmiany hasła co 30 dni wszędzie. Dużo ważniejsze jest, żeby:
hasła nie były współdzielone między osobami i systemami,
po odejściu pracownika jego dostęp można było realnie wyłączyć,
hasła do krytycznych systemów nie krążyły po hali w formie „SMS do wszystkich zainteresowanych”.
Dostęp zdalny: jak nie zrobić „tunelu szwajcarskiego sera”
Zdalny serwis to błogosławieństwo (mniej wizyt integratora na miejscu) i przekleństwo (otwarta brama do sieci OT). Typowy obrazek: stały VPN od integratora do sieci produkcyjnej, jedno hasło, zero logów.
brak stałych tuneli – połączenie zestawiane tylko na czas prac, po zatwierdzeniu przez odpowiedzialną osobę,
VPN z MFA – integrator loguje się imiennie, nie jednym wspólnym kontem „service”,
dostęp tylko do wydzielonej strefy (np. DMZ lub konkretnej podsieci), a nie do całej sieci OT,
nagrywanie sesji RDP/SSH do krytycznych systemów – na wypadek analizy „co dokładnie zostało zmienione”.
Dobrą praktyką jest też obecność osoby z zakładu podczas zdalnych prac – choćby zdalnie, na telefonie. Nie po to, żeby patrzeć integratorowi na ręce, ale by wiedzieć, co i gdzie zostało dotknięte.
Laptopy serwisowe – koń trojański na kółkach
Laptop inżyniera utrzymania ruchu lub integratora często widział więcej sieci niż niejeden router. Był w pięciu fabrykach, na stacji uzdatniania wody i jeszcze na domowym Wi-Fi do Netflixa.
Jak ujarzmić komputery serwisowe i inżynierskie
Z perspektywy OT to, co dzieje się na laptopie serwisowym poza fabryką, jest równie ważne jak to, co dzieje się na hali. Kilka prostych zasad mocno ogranicza ryzyko:
dwa profile albo dwa laptopy – jeden do „świata zewnętrznego” (Internet, poczta), drugi wyłącznie do pracy z urządzeniami przemysłowymi,
uprawnienia lokalnego admina tylko tam, gdzie konieczne – instalacja nowych narzędzi powinna być kontrolowana, nie na zasadzie „ściągnąłem z forum, działa, to dobrze”,
aktualizacje i antywirus – zorganizowane centralnie, z serwera w DMZ lub z wydzielonej sieci, a nie „każdy update’uje się jak uważa”.
W praktyce sprawdza się model, w którym laptopy serwisowe:
łączą się z Internetem tylko przez VPN i tylko z zaufanych lokalizacji,
mają zablokowaną automatyczną instalację niepodpisanych sterowników i aplikacji,
są okresowo skanowane przed dopuszczeniem do sieci OT (np. na „stacji kontrolnej” w DMZ).
Jeśli integrator twierdzi, że „tak się nie da pracować”, to dobrym pytaniem jest: czy wolisz jedną godzinę więcej przygotowań, czy kilkudniowy przestój produkcji po przywiezieniu ransomware w walizce z laptopem.
USB, pendrive’y i inne „niewinne” nośniki
Port USB w szafie sterowniczej to jedna z prostszych dróg wejścia do sieci OT. Nie chodzi tylko o „złośliwe pendrive’y z konferencji”, ale zwykłe dyski, przez które przenosi się projekty, receptury czy raporty.
Da się ograniczyć ryzyko bez kompletnego zakazu wszystkiego:
jasna zasada: żaden nośnik nie trafia bezpośrednio z Internetu do PLC lub HMI, zawsze przechodzi przez „strefę buforową” (komputer w DMZ lub dedykowane stanowisko skanujące),
wydzielenie „pendrive’ów służbowych” – podpisanych, ewidencjonowanych, używanych tylko do OT,
blokada portów USB tam, gdzie nie są potrzebne – wiele HMI i komputerów może działać bez możliwości podpięcia czegokolwiek z zewnątrz.
W zakładach o wyższym poziomie dojrzałości działają też:
stacje skanujące nośniki z aktualnymi sygnaturami AV i sandboxem,
polityki GPO/konfiguracje, które pozwalają na montowanie tylko wybranych typów urządzeń USB (np. klawiatura, mysz, ale już nie pamięć masowa),
procedury dla serwisantów zewnętrznych – nośniki dostarczone przez integratora przechodzą taką samą ścieżkę skanowania jak wszystkie inne.
Najgorzej działa podejście „nie wolno używać USB, ale jak trzeba, to jakoś to obejdziemy”. Lepiej wprost opisać wyjątki i dać ludziom bezpieczną ścieżkę niż liczyć, że zakaz rozwiąże temat.
Zarządzanie uprawnieniami: kto, do czego i na jak długo
Konta i hasła to dopiero początek. Kluczowe pytanie brzmi: kto ma do czego dostęp i czy faktycznie jest mu to potrzebne na stałe. W OT szczególnie widać, kiedy uprawnienia narastały „warstwami geologicznymi” przez lata.
Kilka prostych kroków porządkuje sytuację:
podział ról – operator, brygadzista, utrzymanie ruchu, automatyk, integrator zewnętrzny; każda rola ma jasno zdefiniowany zakres możliwości w SCADA/HMI i systemach inżynierskich,
dostępy czasowe – uprawnienia podwyższone (np. do zmiany receptur czy logiki PLC) nadawane na określony czas i automatycznie wygaszane,
regularny przegląd kont – przynajmniej raz do roku, a najlepiej przy każdej zmianie organizacyjnej; konta po byłych pracownikach i wykonawcach nie powinny „straszyć” w systemach latami.
W wielu zakładach skutecznym półśrodkiem jest prosty rejestr: kto ma konta administracyjne do jakich systemów. To nie jest jeszcze pełne IAM, ale już pozwala podczas incydentu szybko stwierdzić, kto w ogóle mógł coś zmienić.
Logowanie i ślady aktywności: bez tego nie ma bezpieczeństwa
Bez logów każda analiza incydentu sprowadza się do „ktoś coś kiedyś”. W OT nie trzeba od razu wdrażać zaawansowanego SIEM-u, żeby mieć podstawowe ślady aktywności.
Minimalny zestaw obejmuje:
logi logowania i wylogowania użytkowników w SCADA i na serwerach,
rejestr zmian parametrów krytycznych (np. receptury, limity bezpieczeństwa, tryby pracy),
logi dostępu zdalnego (VPN, RDP, rozwiązania serwisowe producentów),
zapisy zmian w konfiguracji PLC (kto i kiedy wgrywał nowy program lub zmieniał parametry).
Kluczowe jest to, aby:
logi były centralnie zbierane (przynajmniej z kluczowych systemów) i miały sensowny czas przechowywania,
dostęp do nich był ograniczony, ale nie tylko dla jednego „człowieka od wszystkiego”,
ktoś faktycznie od czasu do czasu w nie zaglądał, nie tylko po incydencie.
Raz na kwartał można przeprowadzić krótkie ćwiczenie: wybrać losowy dzień i spróbować odtworzyć, kto miał wtedy dostęp do SCADA i jakie zmiany były wykonane. Jeśli bez telefonu do trzech osób i ręcznego szukania w notatnikach się nie da – system logowania wymaga dopracowania.
Bezpieczeństwo procesów: procedury, które działają również w nocy i w weekend
Proste procedury dla zmian w systemach OT
Duża część problemów w OT nie wynika z „hakera z drugiego końca świata”, tylko z chaotycznych zmian: szybkich poprawek na linii, testów „na żywym organizmie” czy instalacji nowych urządzeń na ostatnią chwilę.
Procedura zarządzania zmianą nie musi mieć 20 stron. W większości zakładów wystarczy, że każda istotna modyfikacja:
ma konkretnego właściciela po stronie zakładu,
jest opisana (co, gdzie, po co, przez kogo),
ma określony plan powrotu (cofnięcie do poprzedniej wersji, jeśli coś pójdzie źle),
jest dokonana w oknie serwisowym, a nie w środku krytycznej serii produkcyjnej.
Dobrym nawykiem jest też testowanie zmian w środowisku testowym lub na zapasowym sterowniku. Nawet jeśli „wszyscy wiedzą, że to nie jest idealna kopia”, to i tak pozwoli to wyłapać część błędów zanim trafią na produkcję.
Procedury na czas incydentu: kto dowodzi i co wolno wyłączyć
W momencie, gdy coś podejrzanego dzieje się w sieci OT, nie ma czasu na ustalanie struktury dowodzenia. To powinno być jasne z góry:
kto podejmuje decyzję o odłączeniu określonego segmentu sieci lub systemu,
jak wygląda komunikacja między OT, IT a produkcją (kto, do kogo, jakim kanałem),
co jest priorytetem: bezpieczeństwo ludzi, bezpieczeństwo instalacji, dopiero potem ciągłość produkcji.
Prosta karta „co robić, gdy” powieszona w dyspozytorni czy pokoju utrzymania ruchu potrafi skrócić czas reakcji o kilkanaście minut. W warunkach realnego incydentu te minuty często decydują, czy problem dotknie jednej linii, czy całego zakładu.
Przynajmniej raz w roku warto „przećwiczyć” scenariusz: symulowany atak ransomware w biurze, nietypowy ruch do stacji inżynierskiej, awaria serwera SCADA. Bez wielkich inscenizacji – wystarczy przejść krok po kroku, co kto robi i czy w ogóle ma narzędzia, żeby to zrobić.
Komunikacja między OT a IT: mniej konfliktów, więcej wspólnej roboty
OT i IT często działają jak dwa różne światy. Informatycy chcą patchy i standardów, automatycy – stabilności i niezmienności. Tymczasem sieć jest jedna i podatności też są jedne.
Żeby to pogodzić, przydaje się kilka praktyk:
wspólne ustalenie priorytetów – jakie systemy są krytyczne, gdzie tolerowany jest dłuższy przestój w imię bezpieczeństwa, a gdzie absolutnie nie,
kalendarz działań – z góry zaplanowane okna serwisowe na aktualizacje, testy i modernizacje,
wspólny język – zamiast „trzeba zainstalować łatę CVE-xxxx”, lepiej mówić „ryzyko zatrzymania linii X, jeśli ktoś dostanie się do serwera Y”.
Dobrym ruchem jest też wskazanie „tłumaczy” – osób, które rozumieją zarówno świat IT, jak i OT. To one pomagają przełożyć wymagania bezpieczeństwa na realia produkcji i odwrotnie, bez klasycznego „nie da się” po żadnej ze stron.
Źródło: Pexels | Autor: Tima Miroshnichenko
Aktualizacje, łatki i starzejące się systemy: jak łatać bez wyłączania fabryki
Planowanie aktualizacji w środowisku 24/7
W OT patchowanie „po prostu w środę o 22” rzadko działa. Linia często pracuje w ruchu ciągłym, okna serwisowe są krótkie, a każdy restart systemu może wymagać dodatkowych procedur.
Dlatego dobrze działa podejście etapowe:
Klasyfikacja systemów – które są krytyczne dla bezpieczeństwa ludzi i instalacji, które dla ciągłości produkcji, a które są „pomocnicze”.
Matryca aktualizacji – nie wszystko musi mieć najnowszy patch w dniu wydania; dla krytycznych systemów można przyjąć dłuższy cykl, ale z dodatkowymi zabezpieczeniami (segmentacja, monitoring).
Testy wstępne – jeśli to możliwe, aktualizacje testuje się na bliźniaczej maszynie, wirtualce lub zapasowym serwerze.
Dokumentacja zmian – po każdej aktualizacji zapis, co zostało zmienione, z jakim efektem, czy pojawiły się problemy.
Dla wielu systemów bardziej realne jest podejście „aktualizacje 2–4 razy w roku w skoordynowanych oknach” niż „ciągłe łatki co tydzień”. Chodzi o przewidywalność i możliwość przygotowania się z obu stron – IT i produkcji.
Gdy nie da się zaktualizować: komputery i systemy, których nie można ruszyć
W niemal każdej fabryce znajdzie się komputer z Windows XP, aplikacją producenta sprzed dekady i sterownikiem, którego nikt już nie rozwija. Z punktu widzenia bezpieczeństwa to koszmar, ale z punktu widzenia produkcji – kluczowy element procesu.
Jeśli danego systemu nie można zaktualizować, warto „obudować” go dodatkowymi zabezpieczeniami:
izolacja sieciowa – wydzielona podsieć, minimalny zestaw dozwolonych połączeń (tylko to, co absolutnie konieczne),
aplikacyjne firewalle lub filtry ruchu, które przepuszczają tylko określone protokoły i adresy,
whitelisting aplikacji – blokowanie uruchamiania czegokolwiek poza znanym zestawem programów,
backup obrazu systemu i aplikacji – tak, aby w razie awarii dało się szybko odtworzyć stan „fabryczny”.
Czasem dobrym rozwiązaniem pośrednim jest wirtualizacja: przeniesienie starego systemu na maszynę wirtualną uruchomioną na nowszym, lepiej zarządzanym serwerze, przy zachowaniu zgodności z urządzeniami OT.
Aktualizacje urządzeń OT i IoT: firmware też ma podatności
Coraz więcej elementów linii produkcyjnej to tak naprawdę komputery z własnym systemem operacyjnym: kamery, czytniki kodów, bramki IoT, napędy z interfejsem webowym. One też wymagają aktualizacji.
Podstawą jest rejestr: które urządzenia, jakiej wersji firmware, od jakiego producenta. Bez tego trudno nawet ocenić, czy dana podatność dotyczy zakładu, czy nie. Po zebraniu takiej listy można:
priorytetyzować aktualizacje (np. najpierw urządzenia narażone na dostęp z innych segmentów lub spoza zakładu),
umówić się z dostawcami, jak i kiedy będą wgrywać nowe wersje,
wprowadzić zasadę, że nowe urządzenia nie trafiają na produkcję bez aktualnego firmware i zmienionych haseł domyślnych.
Przed każdą większą akcją aktualizacyjną warto wykonać kopię konfiguracji (backup parametrów) i zaplanować krótki test działania po aktualizacji – choćby prosty sprawdzian: czy urządzenie widzi to, co powinno, i reaguje tak jak wcześniej.
Bezpieczeństwo dla IoT w fabryce: czujniki, bramki i chmura
Inwentaryzacja i „oswojenie” urządzeń IoT
Rozmaite czujniki bezprzewodowe, bramki LTE, moduły do zdalnego monitoringu – wszystko to często pojawia się w fabryce tylnymi drzwiami, w ramach projektów pilotażowych albo „szybkich usprawnień”.
Pierwszy krok to proste pytanie: co właściwie jest podłączone. W praktyce oznacza to:
Najczęściej zadawane pytania (FAQ)
Jak zabezpieczyć sieć OT i IoT w fabryce bez zatrzymywania produkcji?
Podstawą jest podejście „najpierw widoczność, potem zmiany”. Zamiast od razu aktualizować wszystkie sterowniki PLC, lepiej zacząć od inwentaryzacji urządzeń i pasywnego monitoringu ruchu sieciowego. Dzięki temu można wychwycić nietypowe połączenia, nie ingerując w pracę linii.
Kolejny krok to segmentacja sieci: wydzielenie stref (np. linia A, linia B, IoT, biuro) i ograniczenie komunikacji między nimi za pomocą firewalli przemysłowych lub VLAN-ów. Konfiguracje wprowadza się małymi porcjami, w oknach serwisowych, zaczynając od najmniej krytycznych obszarów. Z czasem można dodawać kolejne zabezpieczenia, takie jak kontrola dostępu do VPN, logowanie działań inżynierów czy systemy wykrywania anomalii w sieci OT.
Od czego zacząć cyberbezpieczeństwo w fabryce, która „nigdy nie miała incydentu”?
Pierwszy krok jest mało spektakularny, ale kluczowy: zrobić realny spis tego, co jest wpięte do sieci produkcyjnej. Chodzi nie tylko o PLC i SCADA, ale też stare PC w szafach, modemy GSM, kamery IP, bramki IoT, laptopy serwisowe. Zwykle wychodzi na jaw kilka „zapomnianych” urządzeń, które są idealnym wejściem dla atakującego.
Następnie warto określić, które elementy są krytyczne dla produkcji i od nich zacząć podstawowe zabezpieczenia: zmiana domyślnych haseł, odcięcie dostępu z Internetu, porządek na VPN, ograniczenie zdalnych połączeń tylko do zaufanych stanowisk. Dopiero później ma sens planowanie większych projektów typu segmentacja czy wdrożenie dedykowanego monitoringu OT.
Jakie są najczęstsze wektory ataku na sieci OT i IoT w zakładach produkcyjnych?
Najczęściej atak nie zaczyna się od PLC, tylko od „zwykłego” IT: zainfekowany e‑mail na komputerze inżyniera, słaby VPN, pozostawione otwarte porty do panelu HMI czy SCADA widoczne z Internetu. Z takiego punktu napastnik szuka dalej trasy do sieci OT, gdzie ruch bywa słabo kontrolowany.
Drugim klasykiem jest laptop serwisowy: używany wszędzie, często z lokalnym kontem admina bez hasła, podpinany do różnych sieci, a na końcu wpinany do szafy sterowniczej. Do tego dochodzą urządzenia IoT z domyślnymi hasłami, stare systemy (np. Windows XP na HMI) oraz „tymczasowe” routery Wi‑Fi, które zostają na lata. Każdy z tych elementów może być wygodnym mostem do sieci produkcyjnej.
Jakie zagrożenia niesie podłączanie tanich czujników i IoT do linii produkcyjnej?
Tanie sensory i bramki IoT często projektowane są z myślą „żeby działało”, nie „żeby było bezpieczne”. Mają domyślne loginy, stare firmware, brak szyfrowania komunikacji. Kiedy takich urządzeń jest kilkadziesiąt czy kilkaset, tworzą sieć bocznych drzwi, o której nikt nie ma pełnej dokumentacji.
Ryzyko nie kończy się na potencjalnym dostępie do samych danych pomiarowych. Z poziomu podatnego czujnika można przeskoczyć dalej w sieć, np. do bramki IoT, a stamtąd do systemu nadrzędnego. Dlatego dobrze jest wydzielać osobną podsieć dla IoT, aktualizować firmware tam, gdzie to możliwe, zmieniać domyślne hasła i ograniczać dostęp z Internetu tylko do sprawdzonych kanałów (np. VPN z MFA).
Czym różni się bezpieczeństwo OT od klasycznego bezpieczeństwa IT w firmie?
W IT na pierwszym miejscu zwykle stawia się poufność i integralność danych, a dostępność jest „dopiero” trzecia. W OT kolejność jest odwrotna: linia ma działać, najlepiej 24/7. Aktualizacja, która zatrzyma sterownik PLC lub SCADA w środku zmiany, jest po prostu nieakceptowalna, nawet jeśli zwiększa poziom bezpieczeństwa.
Do tego dochodzi długi cykl życia maszyn (10–20 lat), archaiczne systemy operacyjne, protokoły bez szyfrowania i silna zależność od procesu fizycznego. Dlatego w OT częściej stosuje się: segmentację sieci zamiast masowego patchowania, pasywny monitoring zamiast agentów na każdym HMI, wdrożenia „po kawałku” w oknach serwisowych zamiast wielkiego przełączenia w jeden weekend.
Jakie realne skutki może mieć „mały” cyberincydent w fabryce?
„Mały” incydent zwykle nie wygląda jak hollywoodzki blackout całej fabryki. Częściej jest to subtelna zmiana w jednym etapie procesu. Przykład z praktyki: malware na laptopie serwisowym, które stopniowo zmienia konfigurację modułu odpowiedzialnego za etykietowanie. Linia pakuje, ale co jakiś czas wychodzi produkt z niepełną etykietą.
Efekt? Skok braków, dodatkowe kontrole, spowolnienie produkcji, możliwe reklamacje i wycofania partii. Na poziomie technicznym infrastruktura IT „żyje”, serwery się nie wyłączają, liczba zainfekowanych hostów może być niewielka. Natomiast na poziomie biznesu szkody są liczone w przestojach, nadgodzinach i utraconym zaufaniu klientów.
Jak sprawdzić, co dokładnie jest podłączone do sieci produkcyjnej (OT/IoT)?
Najprostsza, choć żmudna metoda to fizyczny przegląd szaf sterowniczych, linii i pomieszczeń technicznych połączony z przeglądem konfiguracji przełączników i routerów. W wielu zakładach już taki „spacer z notatnikiem” ujawnia stare PC, konwertery, modemy GSM czy access pointy, o których nikt od lat nie wspominał.
Druga ścieżka to użycie pasywnych narzędzi do skanowania i monitoringu sieci OT, które rozpoznają urządzenia, adresy IP, protokoły (Modbus, PROFINET, OPC UA itd.) bez wysyłania agresywnych pakietów. Ważne, by nie robić typowego skanowania jak w IT (agresywne port‑scany), bo niektóre sterowniki reagują na to jak na atak i mogą się zawiesić.
