Systemy OT w firmie. Skąd bierze się ryzyko i co pełnomocnik ds. cyberbezpieczeństwa ma powiedzieć zarządowi?

Technologia operacyjna (OT) to sterowniki, systemy SCADA, panele HMI i cała automatyka, która zamiast danych przetwarza fizyczny proces: otwiera zawór, przełącza rozdzielnię, dozuje chlor, prowadzi linię produkcyjną. Ryzyko z OT różni się od ryzyka z IT skutkiem: incydent przerywa dostawę wody, ciepła albo prądu, zatrzymuje produkcję albo zagraża ludziom.

W 2025 r. Polska po raz pierwszy zobaczyła skoordynowany atak niszczący urządzenia w energetyce, a jedna gmina została na sześć godzin bez wody, bo ktoś zalogował się do sterownika pomp.

Poniżej: gdzie OT występuje, co pokazały incydenty z Polski i ze świata, dlaczego automatyka wdrożona przez firmę zewnętrzną jest osobnym ryzykiem i jak jako pełnomocnik ds. cyberbezpieczeństwa przedstawiam to zarządowi, także wtedy, gdy trzeba coś wymienić.

Czym jest OT i gdzie go spotykam?

Na OT składa się kilka warstw. Sterownik PLC to wytrzymały komputer przemysłowy, który wykonuje jedną, konkretną pracę: pilnuje poziomu w zbiorniku, temperatury w kotle, taśmy w sortowni. System SCADA zbiera dane z wielu sterowników i pozwala nadzorować z jednego miejsca całą stację, zakład albo sieć. Panel HMI to ekran, na którym operator widzi proces i zmienia nastawy. W dużych zakładach chemicznych czy elektrowniach rolę SCADA pełni rozproszony system sterowania DCS, a w budynkach system BMS steruje wentylacją, ogrzewaniem, windami i sygnalizacją pożarową.

Ta warstwa jest w większości sektorów z załączników do ustawy z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (ustawa o KSC). Załącznik nr 1 wymienia energię, transport, ochronę zdrowia, zaopatrzenie w wodę pitną i odprowadzanie ścieków, załącznik nr 2 produkcję i dystrybucję chemikaliów i żywności, produkcję wyrobów medycznych, urządzeń elektrycznych, maszyn i pojazdów oraz gospodarowanie odpadami.

W praktyce wygląda to tak:

• energetyka: sterowniki RTU i zabezpieczenia w rozdzielniach, telemechanika farm wiatrowych i fotowoltaicznych, automatyka kotłów i turbin w elektrociepłowniach;
• wod-kan i ciepłownictwo: pompy, dozowanie chemikaliów, przepływomierze, reaktory oczyszczalni, sterowanie kotłami w ciepłowniach;
• produkcja: roboty spawalnicze i lakiernicze w motoryzacji, mieszalniki i kontrola temperatury w farmacji, pasteryzatory i linie rozlewnicze w przemyśle spożywczym;
• budynki: wentylacja i klimatyzacja szpitali, windy, systemy gaszenia w wysokich biurowcach;
• transport: sygnalizacja drogowa i kolejowa, sortownie bagażu, dźwigi portowe, sterowanie siłownią statku.

Ustawa nie używa słowa OT, ale obejmuje je definicją. Art. 2 pkt 14 lit. b ustawy o KSC definiuje system informacyjny także jako urządzenie lub grupę połączonych urządzeń i oprogramowania zaprogramowanych w celu przetwarzania danych, a art. 8 ust. 1 wymaga systemu zarządzania bezpieczeństwem informacji (SZBI) w systemie informacyjnym wykorzystywanym w procesach wpływających na świadczenie usługi. Sterownik pompy jest takim systemem, i to bardziej niż serwer poczty.

Raport roczny CERT Polska za 2025 r. pokazuje, ile incydentów trafia do tych sektorów:

Ten sam raport liczy, ile polskich adresów IP wystawia do internetu protokoły przemysłowe: średnio dziennie 157 z protokołem S7 (sterowniki Siemens), 157 z BACnet (automatyka budynkowa) i 102 z Modbus. Każdy z tych adresów to panel albo sterownik, do którego ktoś może się dostać bez wchodzenia do zakładu.

Co się stało w Polsce?

Dwa zdarzenia z 2025 r. pokazują dwa końce skali: atak na energetykę przypisywany grupom powiązanym z rosyjskim państwem i haktywistów przy panelu małej stacji wodociągowej.

Energetyka, 29 grudnia 2025 r. CERT Polska opisał skoordynowany atak na co najmniej 30 farm wiatrowych i fotowoltaicznych, firmę z sektora produkcji i dużą elektrociepłownię dostarczającą ciepło dla prawie pół miliona odbiorców. W punktach przyłączenia farm napastnicy mieli dostęp do sieci wewnętrznych i niszczyli urządzenia: sterowniki RTU odpowiedzialne za telesterowanie, lokalne panele HMI, zabezpieczenia, serwery portów szeregowych, modemy, routery i przełączniki. Robili to przez uszkodzenie firmware, usuwanie plików systemowych albo własne oprogramowanie niszczące.

Stacje straciły łączność z systemami operatora sieci i możliwość zdalnego sterowania, ale według CERT Polska produkcja energii i dostawy ciepła nie ucierpiały. W elektrociepłowni atak poprzedziła długotrwała infiltracja i kradzież informacji operacyjnych, a oprogramowanie niszczące zablokował EDR. Uzupełnienie raportu z sierpnia 2026 r. dodało drugą, mniejszą elektrociepłownię ogrzewającą 50 tys. mieszkańców: tam napastnicy weszli do sieci OT przez prywatny APN operatora komórkowego, którego błędna konfiguracja pozwalała dowolnym urządzeniom w tej sieci rozmawiać ze sobą. Turbina parowa i stacja przygotowania wody procesowej zostały zatrzymane, a przerwa była krótka i nie dotknęła odbiorców.

CERT Polska wskazał na duże pokrycie z infrastrukturą grupy znanej jako Static Tundra, Berserk Bear albo Dragonfly, a ESET ze średnią pewnością przypisał użyty wiper grupie Sandworm. Obie oceny publikuję obok siebie, bo się nie pokrywają. Ministerstwo Energii podało w komunikacie, że zdarzenia miały wpływ na systemy informatyczne i fizyczne urządzenia przemysłowe.

Stacja uzdatniania wody, 2025 r. Raport roczny CERT Polska opisuje, że po zalogowaniu się do urządzeń stacji hakerzy zmienili ustawienia pomp, co doprowadziło do wyczerpania zasobów w zbiorniku i przerwy w dostawie wody na około sześć godzin dla około 2,5 tys. mieszkańców gminy. Po odzyskaniu dostępu do paneli wartości przywrócono i po napełnieniu zbiorników woda wróciła. Raport nie nazywa gminy, więc ja też jej nie nazywam.

W sierpniu 2026 r. Prokuratura Okręgowa w Białymstoku postawiła dwóm obywatelom Rosji zarzuty w sprawie 17 cyberataków na polskie obiekty, z których siedem dotyczyło stacji uzdatniania wody i oczyszczalni ścieków. Według prokuratury ataki nie spowodowały szkód materialnych.

Ten sam typ ataku, czyli zdalne logowanie do panelu sterowania, zadziałał w styczniu 2026 r. w ciepłowni w Rucianem-Nidzie, gdzie zmieniono nastawy kotła na biomasę, i w kwietniu 2026 r. w szpitalu w Sanoku, gdzie na centralach wentylacyjnych, w tym na oddziale ratunkowym, ustawiono temperaturę i wilgotność na maksimum.

W obu przypadkach obsługa szybko przywróciła nastawy i odbiorcy nic nie odczuli. W Sanoku panel chroniło sześciocyfrowe hasło, więc o skutku zdecydowała przytomność ludzi przy procesie.

Co się stało za granicą?

Ukraina, 23 grudnia 2015 r. To pierwszy potwierdzony blackout wywołany cyberatakiem. Według analizy SANS i E-ISAC napastnicy weszli do trzech spółek dystrybucyjnych przez phishing z dokumentami Office, ukradli poświadczenia, dostali się przez VPN do sieci sterowania i z paneli HMI w systemie SCADA własnoręcznie otworzyli wyłączniki. Co najmniej 27 stacji zostało odłączonych, prąd straciło około 225 tys. odbiorców, a przerwa trwała kilka godzin. Napastnicy mieli dostęp do sieci ponad sześć miesięcy wcześniej, unieruchomili konwertery szeregowe złośliwym firmware, wyczyścili stacje robocze programem KillDisk i zablokowali call center falą telefonów. Rząd USA przypisał atak rosyjskim aktorom państwowym.

Colonial Pipeline, maj 2021 r. Ransomware DarkSide trafił do sieci IT operatora rurociągu, który dostarcza prawie połowę paliwa na wschodnie wybrzeże USA. Prezes spółki zeznał przed Kongresem, że o 5:55 rano 7 maja 2021 r. zaczęto zatrzymywać rurociąg, a o 6:10 wszystkie 5500 mil było wyłączone; celem było odizolowanie ataku, żeby nie przeszedł do sieci OT, jeśli jeszcze tego nie zrobił. CISA i FBI potwierdziły, że nie było oznak bezpośredniego zajęcia sieci OT. Rurociąg wracał do pracy od wieczora 12 maja. Punktem wejścia był, według zeznania prezesa, nieużywany, pozostawiony profil VPN; spółka zapłaciła około 75 bitcoinów okupu, z czego Departament Sprawiedliwości odzyskał 63,7 bitcoina.

Colonial pokazuje, że zatrzymanie OT nie wymaga włamania do OT: wystarczy, że zarząd nie wie, czy atak z IT już tam dotarł, i musi wybrać między ryzykiem a przestojem.

Dlaczego OT wdrożone przez firmę zewnętrzną to osobne ryzyko?

W większości podmiotów, które znam, automatykę zaprojektował, dostarczył i uruchomił integrator, a serwisuje producent albo jego partner. Własna kadra umie prowadzić proces, ale nie zna konfiguracji sieci, haseł serwisowych ani tego, jakie zdalne dostępy zostały włączone na czas rozruchu i nigdy nie wyłączone. Ten układ jest wygodny dla obu stron, a ryzyko z niego zostaje w całości po stronie podmiotu.

Incydenty opisane wyżej mają w tle dokładnie ten układ. W polskiej energetyce napastnicy nadpisywali firmware sterowników przez domyślne dane logowania do interfejsu webowego i wchodzili przez bramy VPN bez uwierzytelniania wieloskładnikowego; w drugiej elektrociepłowni drogą był błędnie skonfigurowany prywatny APN. W Colonial Pipeline furtką był stary profil VPN, o którym nikt nie pamiętał. W ataku TRITON z 2017 r., opisanym przez FireEye, napastnicy sięgnęli do sterowników bezpieczeństwa Triconex w zakładzie infrastruktury krytycznej ze stacji inżynierskiej, a kluczyk sterownika stał w pozycji PROGRAM, choć powinien w niej być tylko na czas zaplanowanego programowania; część sterowników przeszła w stan bezpieczny i zatrzymała proces. Każdy z tych elementów ktoś kiedyś ustawił i nikt na miejscu nie miał obowiązku o nim pamiętać.

Z zewnętrznego wdrożenia bierze się kilka powtarzalnych braków:

• zdalny dostęp serwisowy (VPN, TeamViewer, modem komórkowy) na stałe, ze wspólnym hasłem, bez logu sesji i bez osoby po stronie podmiotu, która go włącza i wyłącza;
• domyślne albo serwisowe hasła w sterownikach, przełącznikach i panelach, bo zmiana wymagałaby wizyty i podmiot nie chce jej płacić;
• dokumentacja sieci, kopie programów sterowników i plany konfiguracji leżą u integratora, nie w podmiocie;
• nikt nie wie, czy podpisana umowa serwisowa obejmuje aktualizacje bezpieczeństwa i w jakim terminie, ani czy producent w ogóle jeszcze wspiera dane urządzenie;
• integrator zmienia nastawy albo firmware bez zgłoszenia, więc podmiot nie odróżnia pracy serwisu od włamania.

Ustawa o KSC nazywa ten obszar wprost. Art. 8 ust. 1 pkt 2 lit. b wymaga bezpieczeństwa w procesie nabywania, rozwoju, utrzymania i eksploatacji systemu informacyjnego, lit. e bezpieczeństwa i ciągłości łańcucha dostaw z uwzględnieniem związków między bezpośrednim dostawcą sprzętu lub oprogramowania a podmiotem, a art. 8 ust. 2 każe przy tym uwzględnić podatności związane z dostawcą i ogólną jakość jego produktów. Do tego dochodzą zarządzanie aktywami (lit. m) i polityki kontroli dostępu (lit. n), których bez wiedzy o tym, co integrator zostawił, nie da się prowadzić.

Odpowiedzialność nie przechodzi na integratora. Art. 8c ust. 3 ustawy o KSC stanowi, że kierownik podmiotu odpowiada także wtedy, gdy obowiązki powierzył innej osobie. Umowa serwisowa może przewidzieć kary, ale wykaz, kontrola i decyzja o karze z ustawy dotyczą podmiotu.

Jak pełnomocnik ds. cyberbezpieczeństwa znajduje te zagrożenia?

Moja praca w podmiocie z OT zaczyna się od inwentaryzacji, bo bez niej reszta jest zgadywaniem. Spisuję każdy sterownik, panel, przełącznik, modem i stację inżynierską z producentem, modelem, wersją firmware, datą zakończenia wsparcia i osobą, która ma do niego dostęp. Zwykle robię to z automatykiem i z integratorem przy jednym stole, bo każdy z nich zna inną część listy.

Potem sprawdzam, co widać z zewnątrz: publiczne adresy IP podmiotu, numery kart SIM w modemach, konta VPN i profile, których nikt nie używa. W typowym zakładzie znajduję kilka usług, które zostały po rozruchu. CERT Polska w ramach #BezpiecznyPrzemysł wysyła powiadomienia o wystawionych urządzeniach OT, więc pytam też, czy podmiot takie powiadomienia dostał i kto je przeczytał.

Trzeci krok to zdalne dostępy i styk sieci. Dla każdego dostępu serwisowego ustalam, kto go włącza, na jak długo, czy jest imienny, czy ma uwierzytelnianie wieloskładnikowe i gdzie zostaje log. Sprawdzam, czy między siecią biurową a OT stoi zapora z regułami, które ktoś rozumie, i czy prywatny APN jest skonfigurowany tak, że terminale nie widzą się nawzajem. Zdarzenia ze sterowników i przełączników powinny trafiać do centralnego repozytorium, o którym mówi art. 8 ust. 1 pkt 2 lit. g (monitorowanie w trybie ciągłym); w większości podmiotów na tym etapie nie trafiają nigdzie.

Czwarty krok jest procesowy, i to on najbardziej interesuje zarząd. Dla każdego węzła odpowiadam z obsługą na trzy pytania: co się stanie, gdy ktoś zmieni nastawy, jak szybko ktoś to zauważy i czy załoga umie prowadzić proces ręcznie, dopóki nie odzyskamy sterowania. Odpowiedzi idą do szacowania ryzyka z art. 8 ust. 1 pkt 1 i do planu ciągłości działania z lit. f, który potem ćwiczymy, odłączając sterownik naprawdę.

Na koniec czytam umowy z integratorem i producentem: zakres serwisu, czas reakcji, obowiązek zgłaszania zmian, prawo podmiotu do kopii programów i dokumentacji, zasady zdalnego dostępu. To, czego w umowie nie ma, wpisuję do raportu jako ryzyko, a nie jako pretensję.

Co trafia do zarządu i co może kosztować?

Raport dla kierownika podmiotu piszę według skutku, nie według technologii. Na górze stoją węzły, których zatrzymanie przerywa usługę albo zagraża ludziom, z opisem, jak łatwo dziś do nich dojść i ile godzin podmiot wytrzyma bez sterowania. Przy każdym jest decyzja do podjęcia, bo art. 8d ustawy o KSC przypisuje kierownikowi właśnie decyzje o SZBI, planowanie środków finansowych i przydział zadań.

Część decyzji jest tania: wyłączyć dostępy po rozruchu, zmienić hasła, chować panele za VPN z uwierzytelnianiem wieloskładnikowym, dopisać do umowy serwisowej zasady zdalnego dostępu. Część jest droga i tę część muszę nazwać wprost.

Bywa, że jedynym uczciwym wnioskiem z analizy jest to, że sterownika albo systemu SCADA nie da się bezpiecznie zostawić, bo producent skończył wsparcie i nie ma dla niego poprawek.

Art. 8 ust. 1 pkt 5 lit. b ustawy o KSC wymaga regularnych aktualizacji oprogramowania stosownie do zaleceń producenta, z analizą wpływu na świadczoną usługę. Dla urządzenia bez wsparcia zaleceń nie ma, więc podmiot ma do wyboru wymianę, odizolowanie z przyjęciem ryzyka na piśmie albo udawanie, że problemu nie ma. Rekomendacja Pełnomocnika Rządu do Spraw Cyberbezpieczeństwa z 18 września 2026 r. dla sektora wod-kan wymienia procedury wycofania urządzeń po zakończeniu wsparcia producenta jako element SZBI; jej stosowanie jest dobrowolne (art. 67a ust. 5), ale opisuje to, co i tak wynika z art. 8.

Wymiana oznacza planowany przestój, nowy projekt automatyki, często nowego dostawcę, przeszkolenie obsługi i zmianę procedur, a w podmiocie publicznym dodatkowo zamówienie publiczne. Zdarza się, że wymiana jednego sterownika pociąga za sobą wymianę systemu SCADA, bo nowy model nie rozmawia ze starym oprogramowaniem. Nie umiem zrobić tego tanio. Umiem za to sprawić, że zarząd dowie się o tym rok wcześniej, a nie w dniu incydentu, dlatego daty końca wsparcia wpisuję do rejestru ryzyka z terminem decyzji.

Gdy wymiana nie jest możliwa od razu, zapisuję środki zastępcze i ich granice: urządzenie odcięte od wszystkiego poza stacją operatorską, dostęp serwisowy tylko na miejscu, log każdej zmiany nastaw, obsługa przećwiczona w prowadzeniu ręcznym. Kierownik podpisuje przyjęcie ryzyka z datą ponownego przeglądu, bo art. 8c ust. 3 nie pozwala mu tej decyzji oddać mnie ani integratorowi.

Audytu z art. 15 nie zrobię sam, bo ust. 2a wyklucza osobę, która realizuje w podmiocie zadania z art. 8. Przygotowuję więc to, co audytor będzie chciał zobaczyć: inwentarz, listę dostępów, dowody ćwiczeń i rejestr ryzyka, w którym przy urządzeniach bez wsparcia stoi „do wymiany” z datą decyzji zarządu albo podpisane przyjęcie ryzyka z datą kolejnego przeglądu.

Stan prawny sprawdzony: 25.09.2026. Wpis jest informacją ogólną, nie poradą prawną (zasady publikacji).