Sztuczna inteligencja a cyberbezpieczeństwo w OT: ochrona sieci przemysłowych przed atakami

Jak OT różni się od IT i dlaczego klasyczne podejście do cyberbezpieczeństwa nie wystarcza

Specyfika środowisk OT, ICS i SCADA

Środowiska OT (Operational Technology) funkcjonują według zupełnie innych zasad niż klasyczne IT. W biurze najważniejsze jest, aby dane były poufne i dostępne dla uprawnionych osób. W zakładzie przemysłowym na pierwszym miejscu stoi dostępność procesu i bezpieczeństwo fizyczne ludzi, maszyn i środowiska. To odwraca tradycyjną piramidę CIA (Confidentiality – Integrity – Availability). W OT to raczej A-I-C: produkcja ma działać, a dopiero potem dbamy o resztę.

Systemy OT – PLC, DCS, SCADA, HMI, sieci polowe – powstawały z myślą o niezawodności i deterministycznym działaniu, a nie o cyberbezpieczeństwie. Wiele z nich projektowano w czasach, gdy łączenie linii produkcyjnej z Internetem wydawało się science fiction. Efekt? Protokoły bez autoryzacji, brak szyfrowania, brak natywnej kontroli dostępu. Do tego dochodzi bardzo długi cykl życia: sterowniki, które pracują w szafie 10–20 lat, systemy SCADA oparte na przestarzałych systemach operacyjnych, których nikt nie może łatwo zaktualizować.

Infrastruktura OT to mieszanina różnych technologii:

• PLC (Programmable Logic Controller) – sterowniki wykonujące logikę procesu, często komunikujące się po Modbus, Profinet, Ethernet/IP.
• DCS (Distributed Control System) – rozproszone systemy sterowania w procesach ciągłych (chemia, energetyka, rafinerie).
• SCADA (Supervisory Control and Data Acquisition) – systemy nadzorujące, zbierające dane z wielu urządzeń i umożliwiające sterowanie.
• HMI (Human Machine Interface) – panele operatorskie, stacje inżynierskie, wizualizacja i zmiana parametrów procesu.
• Sieci polowe i przemysłowe – Profibus, CAN, Modbus RTU/TCP, Profinet, EtherCAT i inne – często bez wbudowanych mechanizmów bezpieczeństwa.

Ruch w takich sieciach jest najczęściej bardzo powtarzalny i stabilny: te same ramki, w tym samym cyklu, między tymi samymi urządzeniami. Zmiana w tym schemacie, która w IT byłaby normalnym fluktuującym ruchem użytkowników, w OT szybko staje się sygnałem, że dzieje się coś niepokojącego – albo ktoś, albo „coś” ingeruje w proces.

Dlaczego „nie dotykaj, bo stanie linia” blokuje bezpieczeństwo

W zakładach produkcyjnych istnieje silna, często uzasadniona obawa: „jak coś zmienimy, to stanie linia”. Utrata produkcji na kilka godzin lub dni to realne, namacalne straty finansowe. Zespół automatyki i utrzymania ruchu zwykle jest rozliczany z ciągłości pracy, a nie z braku incydentów cyberbezpieczeństwa. To naturalnie powoduje, że każda propozycja instalacji agenta, aktualizacji systemu czy skanowania aktywnego jest traktowana jak potencjalne źródło problemów.

Ta kultura „nie dotykaj, dopóki działa” skutkuje tym, że:

• łatki bezpieczeństwa nie są instalowane miesiącami lub latami,
• systemy OT często nie mają nawet antywirusa (albo mają jego wersję z 2012 roku z wyłączonymi aktualizacjami),
• kontrola dostępu do stacji inżynierskich odbywa się hasłem „admin/admin” spisanym na karteczce przy monitorze,
• zdalne dostępy dla serwisantów działają non stop, „bo kiedyś może być potrzebny serwis”.

Klasyczne IT reaguje na zagrożenia poprzez częste aktualizacje, wdrażanie nowych narzędzi, skanery podatności, EDR, silną segmentację. W OT takie działania bywają blokowane z obawy przed zakłóceniem procesu. Paradoksalnie, im starsza i bardziej wrażliwa na zmiany infrastruktura, tym częściej jest pozostawiana sama sobie, bez aktualizacji i bez współczesnych mechanizmów ochrony. Sztuczna inteligencja ma szansę trochę przełamać ten impas, bo wiele rozwiązań AI można oprzeć na pasywnym monitoringu, bez ingerencji w urządzenia sterujące.

Ograniczenia klasycznych narzędzi IT w środowisku OT

Standardowe podejście IT – antywirus, EDR, skaner podatności, agresywna inspekcja pakietów – w OT często nie działa albo wręcz szkodzi. Główne powody są dość przyziemne:

• na wielu urządzeniach (PLC, HMI wbudowane, panele operatorskie) nie da się zainstalować agenta,
• aktywne skanowanie portów i usług może zawiesić starsze sterowniki lub spowodować restart modułów komunikacyjnych,
• aktualizacje antywirusów mogą wymagać restartu systemów, co jest niedopuszczalne w czasie pracy linii,
• narzędzia IT zwykle nie rozumieją protokołów przemysłowych ani kontekstu procesu, widzą więc „dziwny” ruch, ale nie potrafią ocenić jego krytyczności.

Skutki awarii w OT są dramatyczne: utrata produkcji, uszkodzenie maszyn i narzędzi, zagrożenie życia pracowników (np. w energetyce, chemii, hutnictwie), ryzyko wycieku niebezpiecznych substancji do środowiska. Przy takich stawkach nikt nie chce eksperymentować. Dlatego potrzebne są mechanizmy, które minimalizują ingerencję w infrastrukturę, a jednocześnie dają realne zwiększenie poziomu bezpieczeństwa. To jeden z powodów, dla których AI oparta na pasywnej analizie ruchu i logów zdobywa popularność w obszarze cyberbezpieczeństwa OT.

Główne wektory ataków na sieci przemysłowe – praktyczny przegląd

Jak wygląda łańcuch ataku („kill chain”) w OT

Atak na sieć przemysłową rzadko polega na „włamaniu się prosto do sterownika PLC”. Przestępcy zazwyczaj stosują podejście etapowe, podobne do klasycznego kill chain, ale dostosowane do specyfiki OT. Typowy scenariusz można ująć w kilku krokach:

1. Wejście do organizacji – phishing pracownika biurowego, wykorzystanie podatności w serwerze WWW, atak na VPN.
2. Przyczółek w IT – przejęcie jednego lub kilku systemów w sieci IT, instalacja malware, rekonesans.
3. Poszukiwanie dojścia do OT – skanowanie segmentów sieci, szukanie przejść między IT a OT (serwery raportowe, system MES, zdalny dostęp serwisantów).
4. Przeskok do strefy przemysłowej – wykorzystanie kont serwisowych, słabych haseł, źle skonfigurowanych firewalli lub bezpośrednich tuneli.
5. Rozpoznanie środowiska OT – identyfikacja PLC, serwerów SCADA, stacji inżynierskich, zmapowanie topologii i protokołów.
6. Przygotowanie ataku właściwego – modyfikacja logiki sterowników, planowanie sabotażu procesu, instalacja ransomware w kluczowych systemach.
7. Egzekucja i ukrywanie śladów – uruchomienie złośliwej logiki, szyfrowanie danych, maskowanie zmian w parametrach, ewentualne wymazanie logów.

Na każdym z tych etapów można atak wykryć i zatrzymać – o ile istnieją odpowiednie mechanizmy obserwacji i korelacji zdarzeń. To właśnie obszar, w którym AI jest w stanie wnieść dużo wartości: od wychwycenia nietypowego ruchu w segmentach przejściowych IT/OT, po identyfikację nietypowych komend w ruchu PLC–SCADA.

Rzeczywiste scenariusze ataków na produkcję

Ataki na infrastrukturę OT rzadko wyglądają jak hollywoodzkie „wybuchy na kliknięcie Enter”. Bardziej przypominają serię drobnych przesunięć, które w końcu prowadzą do zatrzymania produkcji lub uszkodzenia partii wyrobów. Przykładowe scenariusze:

• Ransomware na serwerze historycznym (Historian) – złośliwe oprogramowanie szyfruje dane i zatrzymuje serwer, który zbiera i udostępnia dane procesowe. Same sterowniki działają, linia fizycznie pracuje, ale nie ma raportowania jakości, bilansu energii, rozliczeń produkcji. Efekt: kierownictwo decyduje się wstrzymać wysyłkę, bo nie ma pewności co do jakości lub zgodności z normami.
• Cicha manipulacja parametrami – atakujący uzyskuje dostęp do stacji inżynierskiej, zmienia minimalnie nastawy: temperaturę, czas ekspozycji, prędkość linii. Zmiany są na tyle subtelne, że nie wywołują alarmów, ale po kilku tygodniach pojawia się fala reklamacji, wzrost odrzutów jakościowych, przyspieszone zużycie maszyn. Trudno jednoznacznie powiązać problemy z atakiem – a szkoda już się dzieje.
• Sabotaż jakości – w branżach regulowanych (farmacja, spożywka, automotive) zmiana pojedynczego parametru może spowodować, że cała partia produktu przestaje spełniać normy, choć wizualnie wszystko wygląda dobrze. To wymarzone pole dla cichego ataku, który nie „wybucha”, tylko generuje straty i ryzyka prawne.
• Szpiegostwo przemysłowe – atakujący niekoniecznie chce niszczyć. Często celem jest kradzież receptur, algorytmów sterowania, know-how ustawień linii. Wystarczy przechwytywanie ruchu, konfiguracji sterowników, zrzuty ekranów SCADA.

W takich scenariuszach klasyczna, sygnaturowa detekcja malware może nie wykryć nic, bo:

• kod złośliwy jest szyty na miarę (brak sygnatur),
• zmiany są wprowadzane przez legalne narzędzia inżynierskie,
• atak odbywa się „na żywym organizmie” – używane są normalne protokoły, tylko w nienormalny sposób.

Dlaczego prosta detekcja sygnaturowa nie wystarcza

Sygnatury mają sens wtedy, gdy zagrożenie jest znane i powtarzalne. W OT wiele ataków jest:

• ukierunkowanych na konkretny zakład lub technologię,
• modyfikowanych w czasie, aby ominąć proste reguły,
• opartych na nadużyciu legalnych funkcji (np. komendy „write multiple registers” w Modbus).

Antywirus czy IDS z bazą sygnatur może nie mieć najmniejszego pojęcia, że ktoś właśnie przesyła do PLC nietypowy zestaw komend, który zmieni logikę procesu, bo z sieciowej perspektywy „to tylko kolejny pakiet Modbus”. Sztuczna inteligencja, ucząc się normalnych wzorców pracy, jest w stanie wychwycić, że:

• z tej stacji inżynierskiej zwykle nie idą komendy w środku nocy,
• na tym segmencie sieci nigdy nie było ruchu między HMI a konkretnym PLC,
• wzorzec odczytów i zapisów rejestrów znacząco odbiega od profilu historycznego.

Dlatego w ochronie sieci przemysłowych nie da się polegać wyłącznie na sygnaturach. Potrzebne są mechanizmy, które analizują zachowanie – i tu sztuczna inteligencja zaczyna błyszczeć (w granicach rozsądku, to jeszcze nie magia).

Gdzie w tym wszystkim jest miejsce dla sztucznej inteligencji

Od sygnatur do detekcji zachowania w sieciach OT

Sztuczna inteligencja w cyberbezpieczeństwie OT oznacza przejście od prostego „czy ten pakiet pasuje do znanego wzorca ataku” do pytania: „czy to zachowanie jest typowe dla tej konkretnej linii, tej zmiany, tego dnia tygodnia?”. Modele AI uczą się:

• jak zwykle wygląda ruch między PLC a SCADA,
• jakie komendy są wysyłane, w jakich zakresach, z jaką częstotliwością,
• kto i kiedy loguje się na stacje inżynierskie,
• które urządzenia w jakich godzinach wymieniają dane.

Zamiast jednej uniwersalnej reguły dla wszystkich zakładów, powstaje profil konkretnych linii i segmentów sieci. To kluczowe, bo każda fabryka ma swoje „dziwactwa” – niestandardowe konfiguracje, sezonowe zmiany produkcji, praktyki operatorów. AI nie musi tego rozumieć jak człowiek, wystarczy, że jest w stanie zmierzyć odchylenia od typowego wzorca i policzyć, jak bardzo są one podejrzane.

AI jako dodatkowy „operator bezpieczeństwa” dla OT

W realnym zakładzie mało kto ma czas, żeby ślęczeć nad logami z systemów, analizą ruchu na Profinet czy zestawieniem zdarzeń z HMI. Zespół automatyki gasi pożary, utrzymanie ruchu naprawia maszyny, IT zajmuje się serwerami i użytkownikami. Bez dodatkowego wsparcia analitycznego wiele subtelnych incydentów po prostu przemknie niezauważonych.

Sztuczna inteligencja pełni tu rolę dodatkowego operatora bezpieczeństwa, który:

• czyta logi i ruch sieciowy bez przerwy, 24/7,
• porównuje je z wyuczonym modelem normalnego zachowania,
• wypluwa tylko te alerty, które rzeczywiście mocno odbiegają od normy lub wiążą się z konkretnymi ryzykami,
• podpowiada priorytety: co sprawdzić w pierwszej kolejności i dlaczego.

AI w roli „radaru” między IT a OT

Najbardziej newralgiczny obszar w wielu zakładach to nie sam sterownik PLC, ale strefa przejściowa między IT a OT: serwery raportowe, system MES, jump-serwery, bramy zdalnego dostępu. Tam kończą się klasyczne polityki IT, a jeszcze nie zaczynają twarde zasady automatyki. Idealne miejsce na cichy tunel lub rekonesans atakującego.

Modele AI wyspecjalizowane w OT potrafią zbudować mapę typowych połączeń w tych „szarych strefach” i później monitorować, co się z nią dzieje. Dla człowieka pojedyncze, niepozorne sesje RDP czy kilka nowych reguł NAT na firewallu mogą wyglądać jak codzienna administracja. System z uczeniem maszynowym zauważy, że:

• nowy serwer pośredniczący nagle staje się „gwiazdą” ruchu do wielu segmentów OT,
• konto techniczne, które logowało się raz w tygodniu, zaczyna działać codziennie o trzeciej w nocy,
• pomiędzy konkretnymi podsieciami pojawia się komunikacja, której wcześniej nie było, choć na firewallu nic oficjalnie nie zmieniano.

W praktyce przekłada się to na wczesne wykrycie prób przeskoku z IT do OT, zanim ktokolwiek zacznie grzebać w logice sterowników. System nie tylko podnosi alarm, ale też pokazuje „ścieżkę dojścia”: od pierwszego nietypowego logowania, przez konfigurację tunelu, po zmiany w ruchu SCADA.

Synergia człowiek + AI zamiast „automatycznego pilota”

Mimo chwytliwych haseł marketingowych, sztuczna inteligencja w OT nie jest magicznym guzikiem „zabezpiecz wszystko”. W roli samodzielnego decydenta zrobiłaby więcej szkody niż pożytku – automatyczne blokowanie ruchu w sieci sterującej na podstawie samego algorytmu to proszenie się o przestój.

Znacznie lepiej działa podejście, w którym AI:

• wyszukuje anomalie i łączy je w scenariusze,
• podpowiada hipotezy („to wygląda jak nadużycie konta serwisowego z nowej lokalizacji”),
• przygotowuje gotowe „ścieżki analizy” dla inżyniera bezpieczeństwa,
• sugeruje nieinwazyjne działania: podniesienie logowania, ograniczenie dostępu, dodatkową weryfikację użytkownika.

Ostateczna decyzja – odciąć dostęp, zatrzymać linię, zablokować konkretne komendy – pozostaje po stronie człowieka. Tyle że ten człowiek nie startuje z pustą kartką, tylko z konkretnymi danymi, sensownie posegregowanymi przez model. To jak różnica między przeglądaniem surowych logów a dostaniem „streszczenia” z najważniejszymi tropami.

Kluczowe zastosowania AI w cyberbezpieczeństwie OT – od teorii do konkretnych funkcji

Budowa „cyfrowego bliźniaka” zachowania sieci OT

Pierwsze, co robią systemy AI w sieciach przemysłowych, to pasywna obserwacja. Przez tygodnie lub miesiące zbierają:

• kto z kim rozmawia (adresy IP, porty, protokoły),
• jak wygląda typowy ruch dla danej zmiany produkcyjnej,
• jak często wykonuje się operacje zapisu do sterowników,
• jakie urządzenia „widzą się” wzajemnie na poziomie warstwy 2/3.

Na tej podstawie powstaje coś w rodzaju cyfrowego bliźniaka sieci – modelu, który opisuje, jak infrastruktura zachowuje się, gdy wszystko jest w porządku. Taki bliźniak nie musi odzwierciedlać pełnej logiki procesu technologicznego. Wystarczy, że precyzyjnie opisuje ruch, częstotliwości, zależności i sezonowość.

Dzięki temu każda nagła zmiana – nowy typ ruchu, inny schemat komunikacji, nietypowe „rozmowy” między segmentami – jest jak czerwone światło na planszy. Nie oznacza automatycznie ataku, ale sygnalizuje sytuację, którą ktoś technicznie kompetentny powinien obejrzeć z bliska.

Anomalia na poziomie pakietu i procesu

AI w OT potrafi działać na kilku warstwach jednocześnie. Na poziomie czysto sieciowym wyłapuje odchylenia w:

• objętości ruchu (nagłe skoki odczytów/zapisów),
• czasie (komendy wykonywane poza zwykłym harmonogramem),
• strukturze (nietypowe sekwencje ramek lub funkcji w protokołach przemysłowych).

Do tego dochodzi kontekst procesu. Jeżeli model ma dostęp do danych z Historiana lub z systemu SCADA, może korelować zachowanie sieci z tym, co faktycznie dzieje się na instalacji. Przykład:

• pojawia się nowa seria komend zapisu do rejestrów w PLC,
• parametry procesu (ciśnienie, temperatura) nie zmieniają się w sposób, który uzasadnia takie komendy,
• system ocenia, że te zapisy są „odklejone” od normalnego obrazu produkcji.

W takiej sytuacji AI może oznaczyć zdarzenie jako potencjalną manipulację, a nie zwykłą operację serwisową. Szczególnie, jeśli równolegle wykryto logowanie z nietypowego adresu lub niezgodny z grafikiem czas pracy konta.

Wczesne ostrzeganie przed ransomware w OT

Choć ransomware kojarzy się głównie z szyfrowaniem serwerów Windows, jego skutki w OT są wyjątkowo dotkliwe. Zwykle zaczyna się w IT, ale bardzo szybko „wylewa” się na systemy pośrednie, stacje HMI, serwery aplikacyjne. Dla produkcji to często oznacza chaos, nawet jeśli PLC nadal działają.

Modele AI mogą wyłapać wczesne sygnały kampanii ransomware, zanim pierwsza maszyna w strefie OT zostanie zaszyfrowana:

• nietypowe skanowanie zasobów sieciowych (SMB, RDP),
• nagłe, masowe próby logowania na wiele stacji z jednego hosta,
• dziwne wzorce ruchu do zewnętrznych adresów (komunikacja z C2),
• zmiany w zachowaniu serwerów backupu i Historiana.

Zamiast suchego komunikatu „wykryto malware X” system może wygenerować scenariusz: „host A skanuje segment z HMI, host B wysyła podejrzane żądania do domeny C, jednocześnie na serwerze Historian rośnie liczba operacji na plikach wykonywanych przez nowe konto”. To już wygląda nie jak drobny incydent, tylko preludium do poważnego problemu.

Ochrona kont uprzywilejowanych i zdalnego serwisu

Konta serwisowe i dostęp zdalny to ulubiony cel atakujących. Z punktu widzenia bezpieczeństwa OT są jednocześnie koniecznym złem i gospodarzem wielu ryzyk. AI potrafi zbudować profil typowego zachowania takich kont:

• z jakich adresów IP zwykle się logują,
• w jakich godzinach,
• jakie systemy odwiedzają,
• jakie komendy potem wykonują.

Jeżeli nagle:

• to samo konto loguje się z innego kraju,
• zaczyna wykonywać operacje poza swoimi „zwykłymi” systemami,
• pojawiają się próby eskalacji uprawnień lub zmiany konfiguracji,

system może „przykręcić kurek” – od wymuszenia dodatkowego uwierzytelnienia po automatyczne ograniczenie zakresu działań do odczytu. Nie musi od razu zamykać dostępu, ale potrafi szybko zawęzić pole manewru atakującego w oparciu o fakty, a nie tylko statyczne reguły.

Priorytetyzacja alertów – mniej szumu, więcej konkretu

Jednym z największych problemów SOC-ów i zespołów OT/IT jest lawina alertów. Wszystko jest „ważne”, więc w praktyce ważne nie jest nic. Uczenie maszynowe pozwala zapanować nad tym hałasem, bo nie patrzy tylko na pojedyncze zdarzenie, ale na jego kontekst i historię.

Model może ocenić:

• krytyczność urządzenia, którego dotyczy zdarzenie (PLC sterujący kluczowym procesem kontra ekran wizualizacji w biurze),
• dotychczasową „historię zdrowia” tego systemu (czy to odizolowany incydent, czy element większego obrazu),
• korelację z innymi anomaliami (czy w tym samym czasie dzieje się coś podejrzanego w sąsiednich segmentach).

Na tej podstawie powstaje priorytet: kilka zdarzeń dostaje wysoki poziom krytyczności i jest wyświetlanych na górze listy, reszta może poczekać na przegląd okresowy. W praktyce oznacza to, że inżynier nie musi już polować ręcznie na „prawdę” w gąszczu logów, tylko dostaje listę najprawdopodobniej istotnych problemów.

Jak działają modele AI w OT – wytłumaczone „po ludzku”

Uczenie nadzorowane, nienadzorowane i „pomiędzy”

AI w OT korzysta z kilku podejść, które z pozoru brzmią akademicko, ale dają się wytłumaczyć dość prosto.

Uczenie nadzorowane polega na karmieniu modelu przykładami „dobrych” i „złych” zachowań. Dla OT będzie to np. zbiór znanych ataków na protokoły przemysłowe, incydentów z historii zakładu, prób nieautoryzowanych modyfikacji sterowników. Model uczy się rozpoznawać podobne wzorce. Problem? Wiele realnych ataków jest nowych i unikalnych, więc trudno o pełny zestaw „etykietowanych” danych.

Uczenie nienadzorowane to podejście, w którym system dostaje surowe dane i sam szuka w nich struktur: grup zachowań, wzorców, odchyleń. W OT świetnie sprawdza się do budowy profilu normalności – model nie musi wiedzieć, jak wygląda atak, wystarczy, że wie, co jest typowe. Gdy coś odstaje, podnosi rękę.

W praktyce wiele rozwiązań stosuje podejście hybrydowe: nienadzorowane modele wykrywają anomalie, a nadzorowane pomagają ocenić, czy dana anomalia bardziej przypomina znany atak, czy raczej nieszkodliwą zmianę (np. planowy upgrade systemu). To coś jak duet: jeden model „jest podejrzliwy wobec wszystkiego”, drugi pełni rolę bardziej doświadczonego kolegi, który uspokaja, gdy sytuacja jest już znana.

Modele sekwencyjne – patrzenie na czas, a nie tylko na pojedynczy pakiet

Procesy przemysłowe są z natury sekwencyjne: coś dzieje się po kolei, według określonego rytmu. To samo dotyczy komunikacji sieciowej w OT. Modele AI, które biorą pod uwagę kolejność zdarzeń (np. sieci rekurencyjne, LSTM, nowocześniejsze architektury sekwencyjne), potrafią patrzeć na ruch nie jak na pojedyncze pakiety, ale jak na „opowieść w czasie”.

Z ich perspektywy podejrzanie wygląda nie tyle sama ramka Modbus, co np. sekwencja:

1. logowanie do stacji inżynierskiej poza grafikiem,
2. próby odczytu konfiguracji z kilku PLC, które zwykle nie są razem modyfikowane,
3. seria zapisów rejestrów w krótkim odstępie czasu,
4. restart wybranych sterowników.

Dopiero połączenie tych kroków układa się w spójny wzorzec potencjalnego sabotażu lub przygotowania do niego. Proste reguły typu „więcej niż X pakietów na minutę” tego nie złapią, bo patrzą zbyt punktowo.

Modele grafowe – sieć jako sieć, a nie lista adresów IP

Coraz częściej w rozwiązaniach dla OT używa się modeli grafowych. Dla nich cała infrastruktura wygląda jak graf: węzły (urządzenia) i krawędzie (połączenia). Taki model uczy się, jak powinien wyglądać „normalny graf” zakładu:

• które PLC zwykle komunikują się z którymi HMI,
• jakie ścieżki danych prowadzą z czujników do systemów raportowych,
• jakie segmenty są logicznie i fizycznie odizolowane.

Jeśli nagle pojawia się nowa krawędź (np. bezpośrednie połączenie między serwerem w IT a sterownikiem w strefie krytycznej) albo któryś węzeł zmienia swoją „rolę” (urządzenie peryferyjne zaczyna robić za pośrednika dla wielu innych), model natychmiast to zauważa.

Zaletą takiego podejścia jest to, że nie trzeba ręcznie utrzymywać gigantycznych diagramów sieci w dokumentacji. Model grafowy aktualizuje „obraz” sieci z ruchu, a każde większe odstępstwo od utartego wzorca jest traktowane jak potencjalna anomalia.

Dlaczego AI w OT musi być „oszczędna” w zasobach

Środowisko OT nie wybacza ciężkich agentów, agresywnych skanów czy ciągłego obciążania urządzeń dodatkowymi procesami. Dlatego większość rozwiązań AI działa:

• pasywnie – podsłuchując ruch na portach SPAN, tapach sieciowych, mirrorach,
• centralnie – modele są liczone na dedykowanych appliance’ach lub w chmurze (przy zadbaniu o prywatność i opóźnienia),
• z ograniczonym dostępem do samych sterowników (bez instalowania niczego na PLC czy HMI).

Skąd biorą się dane do uczenia modeli w OT

Najlepszy model bez porządnych danych jest jak sterownik bez sygnałów z czujników – teoretycznie coś umie, ale w praktyce niewiele zrobi. W OT źródła danych są rozproszone i często „zabetonowane” w starszych technologiach, dlatego cały proces zaczyna się od rozsądnego podejścia do ich zbierania.

Typowe źródła to m.in.:

• ruch sieciowy z portów SPAN/TAP (warstwa L2–L4 + payload protokołów przemysłowych),
• logi z serwerów Historian, systemów SCADA, serwerów aplikacyjnych i domenowych,
• logi z zapór, IDS/IPS, bramek zdalnego dostępu,
• dane z systemów zarządzania konfiguracją (zmiany w projektach PLC, wersje firmware, backupy),
• informacje z CMDB lub prostych inwentaryzacji (kto, gdzie, jaki sterownik i z czym połączony).

Najpierw trzeba te dane ujednolicić – różne formaty logów, różne strefy czasowe, różny poziom szczegółowości. Dopiero po „odszumieniu” da się z nich budować sensowne cechy, czyli to, na czym faktycznie uczą się modele. Tu kończy się magia, a zaczyna rzemiosło: mapowanie pól, korekta czasów, usuwanie duplikatów, anonimizacja wrażliwych danych.

W praktyce bardzo często zaczyna się od pilota w jednym segmencie: np. tylko linia pakowania lub tylko strefa DMZ między IT a OT. Dzięki temu można przetestować, czy źródła danych faktycznie działają, zanim ktoś spróbuje podłączyć „cały zakład naraz” i sparaliżuje sieć mirrorami.

Dlaczego „trenowanie w chmurze” i „działanie lokalne” to rozsądny kompromis

Modele AI zwykle wymagają solidnej mocy obliczeniowej na etapie trenowania, ale w trakcie działania (inference) mogą być dużo lżejsze. To otwiera drzwi do architektury, w której:

• ciężkie treningi odbywają się w chmurze lub w centralnym data center,
• a gotowe, „odchudzone” modele są wdrażane na appliance’ach w OT.

Dzięki temu da się połączyć dwie, z pozoru sprzeczne rzeczy:

• korzystanie z mocy obliczeniowej i elastyczności chmury,
• zachowanie lokalności danych krytycznych (ruch procesowy, szczegóły konfiguracji PLC) i odporności na przerwy w łączności.

Niektóre rozwiązania stosują podejście federacyjne: każdy zakład ma swój lokalny model, który uczy się na „swoich” danych, a do centralnego środowiska trafiają tylko zanonimizowane parametry aktualizujące model globalny. Dzięki temu nie wywozi się pełnych logów z sieci przemysłowej, a mimo to cała organizacja korzysta z doświadczeń z wielu lokalizacji.

Explainable AI – dlaczego inżynier chce „zobaczyć, co tam w środku siedzi”

W klasycznym IT komunikat „model uznał to za podejrzane z prawdopodobieństwem 93%” częściej przechodzi bez dyskusji. W OT bywa inaczej – inżynier produkcji, który ma zatrzymać linię, chce mieć coś więcej niż procenty z czarnej skrzynki.

Dlatego coraz większy nacisk kładzie się na wyjaśnialność modeli (XAI). Chodzi o to, aby system pokazał nie tylko co wykrył, ale też dlaczego. W praktyce wygląda to jak:

• wskazanie najważniejszych cech, które wpłynęły na decyzję (np. „nietypowa liczba zapisów rejestrów + komunikacja z nowym adresem IP + czas poza harmonogramem”),
• porównanie z „normalnymi” zachowaniami na wykresie lub prostym timeline,
• klasyfikacja typu: „podobne do znanego ataku X / podobne do zmiany serwisowej Y / nowy typ anomalii”.

Dzięki takim podpowiedziom inżynier może w kilka minut zorientować się, czy to raczej fałszywy alarm, czy realne zagrożenie. Dodatkowo każda ręczna decyzja (potwierdzenie incydentu lub oznaczenie go jako nieszkodliwego) może być użyta jako feedback do dalszego ulepszania modelu.

Feedback loop – jak inżynierowie „wychowują” model

AI w OT nie jest systemem typu „kup, włącz i zapomnij”. W dobrze wdrożonym rozwiązaniu model żyje razem z zakładem, a inżynierowie i analitycy SOC pełnią rolę nauczycieli.

W codziennej pracy wygląda to tak:

1. Model zgłasza anomalię z określonym priorytetem.
2. Operator analizuje kontekst, sprawdza w dzienniku zmian, pyta odpowiednie osoby.
3. Oznacza zdarzenie jako: „prawdziwy incydent”, „akceptowalna zmiana”, „fałszywy alarm”.
4. Ta informacja wraca do systemu jako etykieta do dalszego uczenia.

Po kilkudziesięciu, kilkuset takich iteracjach model zaczyna lepiej „czuć” specyfikę danego zakładu. Mniej hałasuje o planowe testy awaryjne, a szybciej reaguje na subtelne odstępstwa od ustalonego rytmu pracy. W pewnym sensie przejmuje trochę „instynktu” doświadczonych inżynierów – oczywiście w granicach tego, co da się zapisać w liczbach.

Scenariusz z życia: nowa linia produkcyjna a modele AI

Dobrym przykładem jest uruchomienie nowej linii w istniejącym zakładzie. Z perspektywy AI oznacza to nagłe pojawienie się nowej wyspy anomalii: inne urządzenia, inny ruch, inne czasy cykli. Gdyby model pozostał niezmieniony, przez kilka tygodni zasypywałby zespół alertami typu „wszystko jest dziwne”.

Dlatego sensowny proces wdrożenia obejmuje:

• okres „obserwacji” – model uczy się nowych wzorców bez generowania pełnej skali alertów,
• oznaczenie fazy rozruchu jako specjalnego stanu (więcej zmian jest wtedy normalnych),
• stopniowe „dokręcanie śruby” czułości, gdy proces się stabilizuje.

W jednym z zakładów automotive zrobiono to w prosty sposób: przed startem linii zdefiniowano okno dwóch miesięcy, w którym wszystkie anomalia z nowego segmentu były automatycznie tagowane jako „okres rozruchowy”. Analitycy mieli je na osobnej liście i oceniali ręcznie, a dopiero po zakończeniu rozruchu model dostał sygnał, że to jest teraz nowa normalność. Dzięki temu uniknięto nerwowego „wyłączania AI, bo przeszkadza w produkcji”.

Wyzwania integracji AI w istniejącej infrastrukturze OT

Technologia to jedno, zderzenie z rzeczywistością drugie. W istniejących zakładach wdrożenie AI bywa utrudnione przez kilka typowych przeszkód:

• stare urządzenia, które nie wspierają nowoczesnych protokołów ani dodatkowego monitoringu,
• brak aktualnej dokumentacji sieci – nikt nie ma pewności, które porty można mirrorować bez ryzyka,
• ograniczone okna serwisowe – na instalację tapów czy konfigurację SPAN-a jest czas „w sobotę między 2:00 a 4:00, ale tylko jeśli nie ma awarii”,
• podział odpowiedzialności między zespoły IT, OT, utrzymania ruchu i zewnętrznych integratorów.

Rozsądna droga to podejście etapowe:

1. Wybór jednego lub dwóch segmentów jako poligon doświadczalny.
2. Uruchomienie monitoringu pasywnego bez żadnych automatycznych reakcji.
3. Kalibracja modeli, wspólna analiza alertów z udziałem OT i SOC.
4. Dopiero potem stopniowe włączanie akcji półautomatycznych (np. ograniczanie dostępu, dodatkowe uwierzytelnienie).

Takie podejście zmniejsza ryzyko, że AI stanie się kozłem ofiarnym za każdy nieoczekiwany przestój – zwłaszcza gdy ktoś przypadkiem podłączy mirrora do portu, który obsługuje krytyczne urządzenie.

Rola dostawców i integratorów w „uzbrajaniu” AI

W wielu zakładach kluczową rolę odgrywają integratorzy systemów oraz dostawcy linii technologicznych. To oni często najlepiej znają logikę procesu i zależności między komponentami. Bez ich udziału modele AI widzą tylko „ruch i adresy IP”, ale nie rozumieją, że to akurat ta pompa nie może się zatrzymać, a ten bufor dopuszcza większe wahania.

Dobra praktyka to włączenie integratorów w:

• tworzenie mapy krytyczności urządzeń (co jest „mission critical”, a co „nice to have”),
• opis typowych scenariuszy serwisowych i testowych (żeby nie pomylić ich z atakiem),
• definiowanie bezpiecznych reakcji automatycznych (co wolno zablokować, a czego nie tykamy bez człowieka).

W efekcie model nie tylko rozpoznaje anomalie, ale potrafi powiązać je z kontekstem procesu. Zamiast ogólnego „anomalny ruch do PLC” można dostać komunikat: „nietypowa sekwencja zapisów w sterowniku linii suszenia, możliwy wpływ na jakość produktu”. Taki opis zdecydowanie łatwiej sprzedać kierownikowi produkcji niż sam wykres pakietów.

Poziomy automatyzacji reakcji – od „tylko podpowiadam” do „sam odcinam”

Nie każde wdrożenie AI w OT musi od razu kończyć się automatycznym blokowaniem dostępu do sterowników. Zazwyczaj przechodzi się przez kilka poziomów zaufania:

1. Monitorowanie bierne – system tylko zbiera dane i zgłasza anomalia. Idealny etap na poznanie możliwości i kalibrację.
2. Rekomendacje – AI podpowiada możliwe działania („zablokuj połączenie X”, „wymuś MFA dla konta Y”), ale decyzję podejmuje człowiek.
3. Półautomatyzacja – część reakcji jest wykonywana automatycznie, ale tylko w niskokrytycznych obszarach lub według ściśle zdefiniowanych scenariuszy.
4. Automatyzacja selektywna – pełna automatyka tylko tam, gdzie skutki uboczne są akceptowalne (np. w strefie DMZ, przy kontach technicznych, w ruchu między IT a OT).

Kluczowe jest, aby nie zaczynać od końca. Automatyczne akcje bez wcześniejszego „oswojenia” modeli i ludzi kończą się zwykle szybkim wyłączeniem systemu bezpieczeństwa, bo „blokuje produkcję”. Dużo lepiej zbudować najpierw zaufanie – pokazać, że AI ma sensowne przemyślenia – a dopiero potem oddawać jej fragmenty sterowania reakcją.

Zarządzanie ryzykiem błędów modeli – fałszywe alarmy i „przeoczone strzały”

Każdy model AI popełnia dwa rodzaje błędów:

• fałszywie pozytywne (false positives) – zgłasza problem, którego nie ma,
• fałszywie negatywne (false negatives) – nie widzi problemu, który faktycznie występuje.

W OT każdy z nich boli inaczej. Pierwszy prowadzi do „zmęczenia alertami” i ignorowania komunikatów, drugi – do realnych incydentów. Dlatego konfiguracja progów czułości to nie jednorazowe kliknięcie, ale ciągły proces, w którym bierze udział SOC, OT i często także biznes (produkacja, utrzymanie ruchu).

Praktyczne podejście to:

• zdefiniowanie obszarów, gdzie tolerujemy więcej fałszywych alarmów (np. strefy pośrednie między IT a OT),
• i obszarów, gdzie liczy się przede wszystkim brak „przeoczonych strzałów” (np. segmenty krytycznych PLC),
• oddzielne strojenie modeli dla różnych klas urządzeń (inna „wrażliwość” dla Historiana, inna dla systemów BMS, inna dla sterowników ruchu).

Dzięki temu AI nie jest ustawiona na jeden, globalny poziom czułości, tylko zachowuje się jak kilka wyspecjalizowanych czujników, dostosowanych do roli i ważności danego fragmentu infrastruktury.

Kompetencje ludzi – kogo naprawdę potrzeba do pracy z AI w OT

Same modele nie wystarczą, jeśli brakuje ludzi, którzy potrafią z nich sensownie korzystać. Nie chodzi jednak o armie naukowców danych w kaskach, ale o połączenie trzech kompetencji:

• znajomości procesów przemysłowych i systemów OT,
• rozumienia podstaw cyberbezpieczeństwa (sieci, protokoły, typy ataków),
• oswojenia z narzędziami analitycznymi i logiką działania modeli (co to jest anomalia, jak interpretować „confidence score”).

W wielu organizacjach najlepiej sprawdzają się małe, mieszane zespoły: inżynier OT + analityk SOC + ktoś od narzędzi AI. Po kilku miesiącach wspólnej pracy inżynierowie zaczynają swobodnie czytać raporty modeli, a analitycy SOC przestają bać się słów typu „Modbus” czy „Profibus”. A to już solidny krok do tego, by AI faktycznie pomagała, zamiast być kolejnym, „magicznie brzmiącym” pudełkiem w serwerowni.

Najczęściej zadawane pytania (FAQ)

1. Czym różni się cyberbezpieczeństwo OT od klasycznego bezpieczeństwa IT?

W IT główny nacisk kładzie się na poufność i integralność danych, a dostępność systemów zwykle da się „odkopać” z backupu. W OT priorytet jest odwrotny: najważniejsze jest, żeby proces działał bez przerwy i żeby nikomu nie stała się krzywda. Dlatego w środowiskach przemysłowych liczy się ciągłość produkcji, bezpieczeństwo ludzi, maszyn i środowiska.

Systemy OT (PLC, DCS, SCADA, HMI) były projektowane z myślą o niezawodności i deterministycznym działaniu, a nie o cyberzagrożeniach. Nie mają natywnych mechanizmów typu szyfrowanie, autoryzacja użytkowników czy segmentacja, a wiele z nich pracuje na przestarzałych systemach operacyjnych. To sprawia, że metody i narzędzia znane z IT nie zawsze da się wprost przenieść do hal produkcyjnych.

2. Dlaczego klasyczne narzędzia IT (antywirus, skanery, EDR) często nie sprawdzają się w OT?

W wielu urządzeniach przemysłowych po prostu nie ma gdzie „wcisnąć” agenta bezpieczeństwa – sterowniki PLC czy niektóre panele HMI mają ograniczone zasoby i zamknięte środowisko. Do tego aktywne skanowanie sieci, które w IT jest normalne, w OT potrafi zawiesić starszy sterownik albo zrestartować moduł komunikacyjny. Efekt? „Bezpiecznik” uruchomiony zbyt agresywnie może sam zatrzymać linię.

Drugi problem to brak zrozumienia protokołów i kontekstu procesu. Typowy system IT widzi ruch Modbus czy Profinet jako egzotykę i nie potrafi ocenić, czy dana komenda to zwykły odczyt, czy próba zmiany logiki sterownika. Dlatego w OT stosuje się narzędzia wyspecjalizowane w analizie ruchu przemysłowego, często oparte na pasywnym monitoringu.

3. Jak sztuczna inteligencja może pomóc w ochronie sieci przemysłowych OT?

AI w OT najczęściej działa w trybie „obserwatora z boku” – analizuje pasywnie ruch sieciowy i logi, nie dotykając samych sterowników czy systemów SCADA. Modele uczą się, jak wygląda normalna praca procesu: jakie urządzenia ze sobą rozmawiają, jak często, jakimi komendami. Każde odstępstwo od tego wzorca może zostać automatycznie wychwycone i oznaczone jako anomalia.

Taki system potrafi zauważyć np. nagłe pojawienie się nowego hosta w sieci OT, nietypowe polecenia wysyłane do PLC czy zmianę częstotliwości komunikacji między serwerem SCADA a sterownikami. Co ważne, odbywa się to bez instalowania agentów na urządzeniach i bez aktywnego skanowania, więc ryzyko „ubicia” linii jest dużo mniejsze.

4. Jakie są główne wektory ataków na sieci przemysłowe OT?

Atakujący rzadko startują od bezpośredniego ataku na PLC. Częściej wchodzą przez „drzwi frontowe” IT: phishing pracownika biurowego, podatny serwer WWW, słabo zabezpieczony VPN. Potem, mając już przyczółek w sieci IT, szukają przejścia do strefy OT – przez systemy MES, serwery raportowe, zdalny dostęp serwisantów czy błędnie skonfigurowane firewalle.

Po przedostaniu się do sieci przemysłowej następuje rozpoznanie (identyfikacja PLC, SCADA, HMI) i dopiero wtedy przygotowanie właściwego ataku: modyfikacja logiki, stopniowa zmiana parametrów procesu, ransomware na kluczowych serwerach. AI może pomóc na każdym etapie kill chain – od wychwycenia nietypowego ruchu między IT i OT, po identyfikację „dziwnych” komend w ruchu sterującym.

5. Jakie skutki może mieć udany atak na infrastrukturę OT w zakładzie produkcyjnym?

Skutki w OT wykraczają daleko poza „utracone pliki”. Mówimy o zatrzymaniu produkcji, uszkodzeniu maszyn i narzędzi, dużych stratach finansowych i potencjalnym zagrożeniu życia ludzi. W branżach takich jak energetyka, chemia czy hutnictwo dochodzi jeszcze ryzyko awarii technologicznej i szkód środowiskowych.

Przykład z praktyki: ransomware szyfruje serwer Historian, który zbiera dane procesowe. Fizycznie linia nadal pracuje, ale nie ma wiarygodnych danych o jakości, zużyciu energii czy spełnieniu norm. Kierownictwo często decyduje się wstrzymać wysyłkę produktów, bo nikt nie chce brać odpowiedzialności za partię wyprodukowaną „w ciemno”.

6. Co to znaczy, że ruch w sieciach OT jest „powtarzalny” i jak można to wykorzystać do detekcji ataków?

W sieciach przemysłowych komunikacja jest bardzo schematyczna: te same urządzenia wymieniają te same ramki, w określonych cyklach czasowych. Nie ma tu nagłych skoków ruchu, losowych połączeń z Internetem czy tysiąca różnych aplikacji jak w biurze. Ta przewidywalność to świetny materiał dla algorytmów AI, które mogą dokładnie nauczyć się „normalnego dnia na produkcji”.

Gdy nagle pojawia się nowy typ pakietów, niestandardowa częstotliwość zapytań do PLC albo komunikacja między urządzeniami, które wcześniej ze sobą nie rozmawiały, system potrafi to szybko wychwycić. Z punktu widzenia automatyka to dodatkowa para oczu, która bez przerwy patrzy w sieć i zgłasza, że „coś tu nie wygląda jak zwykle”.

7. Jak zacząć podnosić cyberbezpieczeństwo OT bez zatrzymywania produkcji?

Dobry start to działania, które nie ingerują w sam proces: inwentaryzacja urządzeń OT, segmentacja sieci (logiczna lub fizyczna), uporządkowanie zdalnych dostępów serwisowych i wprowadzenie choć podstawowej kontroli haseł. Wiele z tych rzeczy da się zrobić etapami, np. podczas planowanych postojów, zamiast „wielkiej rewolucji” w jeden weekend.

Kolejny krok to wdrożenie pasywnego monitoringu sieci OT, najlepiej z wykorzystaniem analizy behawioralnej lub AI. Taki system obserwuje, ale nie wpływa na sterowniki czy SCADA. Równolegle warto zmienić sposób rozliczania zespołów – nie tylko za „ciągłość pracy”, ale też za zmniejszanie ryzyka cyber. W przeciwnym razie kultura „nie dotykaj, bo stanie linia” zawsze wygra z najlepszą nawet strategią bezpieczeństwa.

Co warto zapamiętać

• Priorytety w OT są odwrócone względem IT: najważniejsza jest ciągłość procesu i bezpieczeństwo fizyczne (A‑I‑C), a nie poufność danych, więc klasyczne podejście IT do cyberbezpieczeństwa nie przystaje do realiów hali produkcyjnej.
• Większość systemów OT (PLC, DCS, SCADA, HMI, sieci polowe) została zaprojektowana bez myślenia o cyberzagrożeniach – brakuje autoryzacji, szyfrowania i nowoczesnej kontroli dostępu, a urządzenia działają 10–20 lat na przestarzałych platformach.
• Ruch w sieciach przemysłowych jest bardzo powtarzalny i przewidywalny, więc każda nietypowa komunikacja może być szybkim sygnałem ingerencji w proces – to wada z punktu widzenia elastyczności, ale ogromna zaleta, jeśli chodzi o wykrywanie anomalii.
• Kultura „nie dotykaj, bo stanie linia” blokuje wdrażanie zabezpieczeń: łatki są odkładane na lata, antywirus (jeśli w ogóle jest) nieaktualny, hasła trywialne, a zdalne dostępy dla serwisantów zostają włączone na stałe „na wszelki wypadek”.
• Klasyczne narzędzia IT (antywirus, EDR, agresywne skanery podatności) potrafią w OT bardziej zaszkodzić niż pomóc – nie zainstalują się na PLC, potrafią zawiesić starsze sterowniki aktywnym skanem i nie rozumieją protokołów przemysłowych ani kontekstu procesu.