AI w sieci OT w 16 minut. Co test Booz Allen zmienia w szacowaniu ryzyka podmiotu kluczowego i ważnego?

Modele AI w laboratorium przeszły od brzegu sieci do sterowników i poruszyły ramieniem robota. Co z tego testu wynika dla art. 8 ustawy o KSC, a co nie.

Autor: Paweł Rosół
Data: 20.10.2026
Czytanie: 10 min
Kategoria: Zarządzanie ryzykiem

Stan prawny sprawdzony: 20.10.2026

Spis treści

Co dokładnie sprawdzono w laboratorium?
Czego raport nie mówi?
Czy coś takiego zdarzyło się już poza laboratorium?
Co to zmienia w obowiązkach z art. 8 ustawy o KSC?
Jakie zabezpieczenia wynikają z testu?
Jak to wygląda w mojej pracy pełnomocnika ds. cyberbezpieczeństwa?

Booz Allen Hamilton wpuścił modele AI do laboratorium, które udaje zakład produkcyjny, i sprawdził, czy z ogólnym poleceniem i bez dokumentacji dojdą od sieci biurowej do sterownikówSterownik PLC Programmable Logic Controller: przemysłowy komputer, który według zapisanego programu bezpośrednio steruje pompą, zaworem albo silnikiem.. Doszły w każdym z ośmiu scenariuszy, w jednym w nieco ponad 16 minut. Dla podmiotu kluczowegoPodmiot kluczowy Podmiot z sektorów ustawy o KSC, który ze względu na wielkość albo rodzaj działalności ma najszersze obowiązki, w tym audyt bezpieczeństwa co najmniej raz na trzy lata. lub ważnego z urządzeniami OTTechnologia operacyjna Systemy, które sterują procesami fizycznymi: sterowniki, SCADA, automatyka w wodociągach i energetyce. W tekstach zostaje angielski skrót OT. wniosek jest prosty: założenie, że do ataku na sterownik potrzebny jest napastnik ze znajomością automatyki, przestało być bezpieczne i nie powinno już obniżać prawdopodobieństwa w rejestrze ryzyka. Zabezpieczenia, które z raportu wynikają, ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa (ustawa o KSCUstawa o KSC Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Po nowelizacji z 2026 r. wdraża dyrektywę NIS2 i określa obowiązki podmiotów kluczowych i ważnych.) wymienia w art. 8.

O raporcie napisało 19 października CyberDefence24. Przeczytałem cały raport, stronę Booz Allen, na której go opublikowano, i opis prawdziwego włamania z pomocą AI do wodociągów w Meksyku, który przygotował Dragos. Drogi, którymi napastnicy docierają do sterowników bez żadnej AI, opisałem w tekście o atakach na urządzenia OT, a raport dla zarządu o OT w tekście o systemach OT w firmie. Tu zajmuję się tym, co dokłada AI.

Co dokładnie sprawdzono w laboratorium?

Raport „From Digital to Physical: The AI Threat Is Here” ma datę 6 października 2026 r. Testy odbyły się w laboratorium OT Booz Allen w Chantilly w Wirginii, odizolowanym od świata i zbudowanym na wzór ogólnego zakładu produkcyjnego. Sieć podzielono na strefy według modelu Purdue: biurową, przemysłową strefę DMZStrefa DMZ Wydzielony segment sieci między siecią wewnętrzną a światem zewnętrznym. Stoją w nim usługi, które muszą być dostępne z zewnątrz, a zapora przepuszcza dalej tylko to, co niezbędne., sieć operacyjną zakładu i strefy produkcyjne, z zaporami między nimi. W środku stały sterowniki PLC kilku producentów, panele HMIPanel operatorski HMI Human-Machine Interface: ekran albo aplikacja, przez które operator odczytuje stan procesu i wydaje polecenia sterownikom., stacje inżynierskie i operatorskie, system SCADASystem SCADA Supervisory Control and Data Acquisition: system nadzoru i zbierania danych, przez który dyspozytor widzi rozproszoną instalację, na przykład sieć wodociągową, i nią steruje., przemiennik częstotliwości z silnikiem, ramię robota i czujniki. Autorzy piszą, że mieszanka producentów, wersji firmware i niedoskonała segmentacja miały odtworzyć dług technologiczny typowy dla instalacji, które pracują od lat.

Operatorzy podali modelom granice podsieci i ogólne polecenie, bez kodu, dokumentacji technicznej i wskazówek dotyczących OT. Modele miały się zatrzymać i czekać na zgodę człowieka przed każdym exploitem i przed każdym działaniem z fizycznym skutkiem, a przy urządzeniach bezpieczeństwa zachować szczególną ostrożność. Osiem scenariuszy obejmowało kolejne etapy ataku: rozpoznanie sieci i ważnych zasobów, znalezienie podatnościPodatność Słabość produktu lub usługi ICT, którą można wykorzystać do ataku. Znane podatności dostają identyfikatory CVE, a te wykorzystywane w atakach trafiają do katalogu KEV., zbudowanie z nich działającego dostępu, połączenie słabości w drogę do systemów produkcji, manipulację sterownikami różnych producentów, zmianę prędkości oraz zatrzymanie i uruchomienie silnika, przejęcie systemu SCADA ze zmianą ekranów operatora i poruszenie ramieniem robota.

Wszystkie osiem celów osiągnięto. Najmocniej brzmią trzy obserwacje z raportu:

w jednym teście modele przeszły od przełamania brzegu sieci do działań w strefie sterowania w nieco ponad 16 minut, a ramię robota znalazły, przejęły i poruszyły w ciągu kilku minut;
brama SCADA trzymała otwarte, już uwierzytelnione sesje do 14 urządzeń OT w obu strefach produkcyjnych, w tym do każdego znalezionego sterownika, i miała drugą kartę sieciową w podsieci sterowania, więc jedno przejęcie dawało drogę do wszystkich sterowników;
gdy pierwsza próba zmiany ekranów operatora się nie udała, bo modele zmieniły nie tę wersję interfejsu, sprawdziły aktywne sesje, ustaliły wersję używaną w sterowni, przebudowały ładunek i wyświetliły na ekranach operatorów własny obraz na cały ekran.

W tym trzecim teście model sam zauważył, że z takim dostępem może jednocześnie wysyłać polecenia do sterowników i sprawić, że ekrany operatorów będą „kłamać”. Ten sam mechanizm opisałem przy Stuxnecie w tekście o atakach na urządzenia OT.

Brama SCADA z otwartymi sesjami do wszystkich sterowników to jedne drzwi do całego zakładu, a model AI znalazł je bez żadnej dokumentacji.

Czego raport nie mówi?

Zanim ktoś przeniesie te 16 minut do prezentacji dla zarządu, kilka zastrzeżeń. Część robią sami autorzy, część dopisuję ja.

Autorzy piszą, że wyniki są wstępne i nie przewidują skutku w konkretnym zakładzie, bo ten zależy od architektury, urządzeń, zabezpieczeń mechanicznych i od tego, jaki dostęp zdobył napastnik. Przyznają też, że doświadczony zespół ludzi z odpowiednim czasem i wiedzą odtworzyłby wiele pojedynczych działań modeli. Nowa jest szybkość i połączenie rozpoznania, badań, planowania i wykonania w jeden ciąg, a nie nowa klasa ataku na OT.

Raport nie podaje, które modele testowano, w jakich wersjach, ile było powtórzeń ani jakie narzędzia obronne stały w laboratorium. Nie wiadomo, ile trwały pozostałe scenariusze, bo 16 minut dotyczy jednego z nich. Każde wykonanie exploita i każdy ruch maszyny czekał na zgodę operatora, więc to nie jest pomiar w pełni samodzielnego ataku. Booz Allen sprzedaje usługi i produkty bezpieczeństwa, w tym obronę opartą na AI, a strona z raportem nazywa testowane modele „super intelligence”, choć sam raport pisze o „frontier AI”. Wyniki mogą być rzetelne, ale czytam je jako badanie dostawcy, nie niezależną ocenę.

Wiele mówi też to, czego modelom nie udało się zrobić. Jeden sterownik początkowo odrzucił polecenie zatrzymania. Silnik ustawiony na sterowanie lokalne nie dał się uruchomić zdalnie. Zapory, segmentacja i ochrona stacji końcowych spowalniały albo blokowały część działań, choć modele czasem zmieniały metodę i szły inną drogą. Autorzy podsumowują to tak, że obrona warstwowa działa, ale żadne pojedyncze zabezpieczenie nie zatrzymywało modeli konsekwentnie.

Czy coś takiego zdarzyło się już poza laboratorium?

W części. Dragos opisał 6 maja 2026 r. włamanie do przedsiębiorstwa wodociągowo-kanalizacyjnego obsługującego aglomerację Monterrey w Meksyku, część kampanii przeciw meksykańskim instytucjom publicznym z przełomu 2025 i 2026 r., którą wcześniej ujawniło Gambit Security. Napastnik używał modeli Claude i GPT. Według Dragos Claude, przeszukując sieć biurową przedsiębiorstwa, sam rozpoznał serwer z bramą przemysłową vNode i platformą SCADA jako drogę w stronę OT, uznał go za cel o dużej wartości, przejrzał dokumentację producenta, przygotował listy haseł domyślnych i dopasowanych do ofiary i uruchomił próbę ich masowego odgadywania. Próba się nie udała i Dragos nie znalazł śladów wejścia do sieci OT.

Dragos dodaje zastrzeżenie: w prawdziwych incydentach nie obserwuje dziś autonomicznej AI, która sama przejmuje infrastrukturę, a modele nie dają napastnikom nowych zdolności specyficznych dla OT. Dają im za to widoczność. Napastnik, który był w sieci biurowej po dane i nie znał się na automatyce, dostał od modelu informację, że obok stoi system sterujący wodą i jak można do niego podejść. Raport Booz Allen pokazuje, co mogłoby się stać, gdyby ta próba się powiodła.

AI nie wymyśla nowych ataków na sterowniki, tylko podsuwa stare temu, kto wcześniej nie wiedziałby, że sterowniki w ogóle są w zasięgu.

Co to zmienia w obowiązkach z art. 8 ustawy o KSC?

Art. 8 nie wspomina o AI, ale jego ust. 1 pkt 1 wymaga systematycznego szacowania ryzyka wystąpienia incydentu, a pkt 2 wymaga środków proporcjonalnych do oszacowanego ryzyka, które uwzględniają między innymi najnowszy stan wiedzy, prawdopodobieństwo wystąpienia incydentów i narażenie podmiotu na ryzyka. Art. 8 ust. 1 pkt 3 dokłada zbieranie informacji o cyberzagrożeniach. Art. 21 ust. 1 dyrektywy 2022/2555 (NIS2) wymaga uwzględnienia najnowszego stanu wiedzy tymi samymi słowami.

W praktyce oznacza to trzy poprawki w szacowaniu ryzyka OT.

Pierwsza dotyczy prawdopodobieństwa. Jeśli scenariusz „napastnik przejmuje sterownik” ma w rejestrze niską ocenę z uzasadnieniem, że wymaga wiedzy o konkretnym producencie i protokole, raport i opis Dragos podważają właśnie to uzasadnienie. Nie każdy taki scenariusz trzeba od razu ocenić wysoko, ale ocena oparta na „nikt się na tym nie zna” powinna wrócić do przeglądu.

Druga dotyczy kolejności łatania. Raport zaleca, żeby podatności szeregować według tego, czy system jest osiągalny, jakie drogi do niego prowadzą i co da się z niego zmienić w procesie, a nie według samej oceny CVSS. Dodaje obserwację ważną zwłaszcza dla OT: na poziomie sterowników modele w większości używały zwykłych poleceń protokołów przemysłowych, a nie exploitów. Sterownik bez uwierzytelniania wykona polecenie od każdego, kto do niego dotrze, więc najważniejsze jest to, kto może dotrzeć. Art. 8 ust. 1 pkt 5 lit. d wymaga niezwłocznych działań po dostrzeżeniu podatności lub cyberzagrożeń, a taka lista priorytetów mówi, od czego te działania zacząć.

Trzecia dotyczy czasu reakcji. Jeśli od przełamania brzegu do strefy sterowania mija kwadrans, procedura, w której alert z sieci OT czeka do rana na informatyka, nie zdąży. Monitorowanie w trybie ciągłym z art. 8 ust. 1 pkt 2 lit. g musi więc obejmować sieć OT i mieć kogoś, kto zareaguje w nocy, albo przynajmniej automatyczną reakcję uzgodnioną z technologiem.

Ocena ryzyka oparta na tym, że „nikt się na tym nie zna”, powinna wrócić do przeglądu.

Jakie zabezpieczenia wynikają z testu?

Zalecenia raportu pokrywają się z tym, co od września wymienia rekomendacja Pełnomocnika Rządu nr 2026-67-8 dla wodociągów i kanalizacji, i z przepisami art. 8. Wybrałem te, które w laboratorium miały największe znaczenie.

Zinwentaryzuj ukryte mosty między strefami: hosty z dwiema kartami sieciowymi, wspólne usługi, serwery z otwartymi sesjami do sterowników i aplikacje, które omijają segmentację. Modele w teście znajdowały je szybko i używały ich do przejścia dalej. Odpowiada to zarządzaniu aktywami (art. 8 ust. 1 pkt 2 lit. m) i polityce kontroli dostępu (lit. n), a rekomendacja nr 2026-67-8 wymaga dedykowanych sieci OT i stref DMZ z aktywnymi regułami na zaporze.
Traktuj zapory, przełączniki, serwery przesiadkowe i interfejsy administracyjne jak urządzenia OT o wysokiej wartości: łataj albo izoluj, ogranicz usługi zarządzania, przeglądaj reguły i pilnuj zmian konfiguracji. Według raportu podatne urządzenia sieciowe i dziurawe reguły ułatwiały modelom przejście przez granice stref. Rekomendacja nr 2026-67-8 zaleca cykliczny przegląd reguł na zaporach i koncentratorach VPN.
Usuń hasła domyślne i powtarzane, wprowadź indywidualne konta uprzywilejowane i uwierzytelnianie wieloskładnikowe tam, gdzie to możliwe. Tam, gdzie modele trafiały na hasła domyślne albo powtórzone, raport opisuje ominięcie zabezpieczeń jako trywialne; modele same szukały haseł domyślnych producentów i zapamiętywały złamane hasła na później. Rekomendacja nr 2026-67-8 wymienia zmianę domyślnych poświadczeń, wyłączenie kont wbudowanych i konta indywidualne.
Wzmocnij konfigurację systemów SCADA, HMI, MES, historianów i oprogramowania inżynierskiego, bo łączą szeroki wgląd z uwierzytelnionym dostępem do sterowników. To bezpieczeństwo w procesie utrzymania i eksploatacji systemu informacyjnego, w tym jego testowanie (art. 8 ust. 1 pkt 2 lit. b).
Monitoruj zmiany w zachowaniu procesu, nie tylko sygnatury ataków: zmiany trybu pracy sterownika, wymuszenia wyjść, zapisy programu i konfiguracji, import projektów SCADA, nowe połączenia między strefami i nietypowe użycie zaufanych interfejsów. Raport zauważa, że modele były głośne na etapie rozpoznania, a cichły, gdy przechodziły na natywne protokoły OT. Rekomendacja nr 2026-67-8 wymaga logowania zdarzeń administracyjnych i zmian konfiguracji oraz monitorowania zdarzeń z sieci OT.
Trzymaj sprawdzone kopie logiki sterowników, konfiguracji, receptur, projektów HMI i konfiguracji urządzeń sieciowych, zachowaj znane dobre stany sterowników i ćwicz odtwarzanie. To plany ciągłości działania i odtworzenia (art. 8 ust. 1 pkt 2 lit. f) i ochrona przed nieuprawnioną modyfikacją (pkt 5 lit. c).
Nie wyłączaj zabezpieczeń lokalnych dla wygody. Przełącznik sterowania lokalnego przy silniku i sterownik, który początkowo odrzucił polecenie zatrzymania, zablokowały konkretne działania modeli już po tym, jak modele dotarły do sieci OT. To moje zalecenie, wyprowadzone z tych dwóch obserwacji: przy szacowaniu ryzyka sprawdzam, które urządzenia da się przestawić zdalnie tylko dlatego, że komuś było tak wygodniej przy uruchomieniu.

Raport proponuje też ocenę obrony opartej na agentach AI przy granicach OT, z zachowaniem decyzji człowieka przy wszystkim, co dotyczy bezpieczeństwa. Do tego podchodzę ostrożnie. Agent z uprawnieniami do blokowania ruchu w sieci OT sam staje się systemem, który może zatrzymać proces, więc wchodzi do szacowania ryzyka jak każde inne urządzenie z dostępem uprzywilejowanym.

Jak to wygląda w mojej pracy pełnomocnika ds. cyberbezpieczeństwa?

Po takim raporcie nie przepisuję polityk. Biorę rejestr ryzyka OT i szukam scenariuszy, których niską ocenę uzasadniono trudnością ataku albo nieznajomością urządzeń przez napastnika. Każdy taki wpis wraca do przeglądu z pytaniem, co by się stało, gdyby napastnik z sieci biurowej miał obok siebie kogoś, kto zna każdy protokół i każde hasło domyślne. Wynik przeglądu z kosztami idzie do kierownika podmiotu, bo decyzje o SZBI i budżecie należą do niego z mocy art. 8d, a art. 8c ust. 3 nie pozwala ich przenieść na mnie ani na integratora.

Potem razem z automatykiem rysujemy drogę od zwykłej stacji roboczej w biurze do najważniejszego sterownika i liczymy, ile przeszkód stoi po drodze i które z nich ktoś monitoruje. Szukam przy tym tego, co w laboratorium znalazły modele: serwera SCADA albo historiana z nogą w obu sieciach i otwartymi sesjami do sterowników.

Ostatnią rzeczą jest pomiar. Test Booz Allen mierzył czas od wejścia do strefy sterowania. U siebie warto zmierzyć drugą stronę: po ilu minutach od nietypowego zapisu do sterownika ktoś w podmiocie o tym wie. Jeśli odpowiedź brzmi „rano”, zarząd dostaje konkretną liczbę do porównania z kwadransem z laboratorium.

Pojęcia w tym tekście (19)

Sterownik PLC: Programmable Logic Controller: przemysłowy komputer, który według zapisanego programu bezpośrednio steruje pompą, zaworem albo silnikiem.
Podmiot kluczowy: Podmiot z sektorów ustawy o KSC, który ze względu na wielkość albo rodzaj działalności ma najszersze obowiązki, w tym audyt bezpieczeństwa co najmniej raz na trzy lata.
Technologia operacyjna: Systemy, które sterują procesami fizycznymi: sterowniki, SCADA, automatyka w wodociągach i energetyce. W tekstach zostaje angielski skrót OT.
Ustawa o KSC: Ustawa z dnia 5 lipca 2018 r. o krajowym systemie cyberbezpieczeństwa. Po nowelizacji z 2026 r. wdraża dyrektywę NIS2 i określa obowiązki podmiotów kluczowych i ważnych.
Strefa DMZ: Wydzielony segment sieci między siecią wewnętrzną a światem zewnętrznym. Stoją w nim usługi, które muszą być dostępne z zewnątrz, a zapora przepuszcza dalej tylko to, co niezbędne.
Panel operatorski HMI: Human-Machine Interface: ekran albo aplikacja, przez które operator odczytuje stan procesu i wydaje polecenia sterownikom.
System SCADA: Supervisory Control and Data Acquisition: system nadzoru i zbierania danych, przez który dyspozytor widzi rozproszoną instalację, na przykład sieć wodociągową, i nią steruje.
Podatność: Słabość produktu lub usługi ICT, którą można wykorzystać do ataku. Znane podatności dostają identyfikatory CVE, a te wykorzystywane w atakach trafiają do katalogu KEV.
Zapora sieciowa: Urządzenie albo program, które przepuszczają lub blokują ruch sieciowy według reguł. Oddzielają na przykład sieć biurową od sieci sterowników.
Incydent: Zdarzenie, które szkodzi albo może zaszkodzić bezpieczeństwu systemów informacyjnych. Zgłaszać trzeba nie każdy incydent, tylko incydent poważny.
Szacowanie ryzyka: Proces, w którym podmiot ustala, co może zagrozić jego systemom, jak bardzo jest to prawdopodobne i jakie byłyby skutki. W praktyce mówi się też „analiza ryzyka”.
Dyrektywa NIS2: Dyrektywa Parlamentu Europejskiego i Rady (UE) 2022/2555 z dnia 14 grudnia 2022 r. o cyberbezpieczeństwie w Unii. W Polsce wdraża ją ustawa o KSC po nowelizacji z 2026 r.
CVSS: Common Vulnerability Scoring System: skala od 0 do 10 opisująca techniczną powagę podatności. Wynik nie mówi, czy podatność jest już wykorzystywana w atakach.
Rekomendacja Pełnomocnika: Dokument Pełnomocnika Rządu do Spraw Cyberbezpieczeństwa o środkach ochrony albo o stosowaniu konkretnego produktu lub usługi ICT. Publikowany w BIP; rekomendacje o środkach ochrony są dobrowolne.
Wirtualna sieć prywatna: Virtual Private Network: szyfrowany tunel, którym pracownik albo oddział łączy się z siecią firmy przez internet. Brama VPN wystawiona do internetu to częsty cel ataków.
Uwierzytelnianie wieloskładnikowe: Logowanie, które wymaga więcej niż jednego składnika, na przykład hasła i kodu z aplikacji. Ustawa o KSC wymienia je wśród środków bezpieczeństwa.
Ciągłość działania: Zdolność podmiotu do świadczenia usługi mimo awarii albo ataku. Ustawa wymaga planów ciągłości działania, które są dokumentowane, testowane i utrzymywane.
Kierownik podmiotu: Osoba albo organ kierujący podmiotem kluczowym lub ważnym, na przykład zarząd spółki. Odpowiada za cyberbezpieczeństwo podmiotu także wtedy, gdy zadania powierzył innej osobie.
System zarządzania bezpieczeństwem informacji: Uporządkowany sposób, w jaki podmiot kluczowy lub ważny zarządza bezpieczeństwem systemu używanego do świadczenia usługi, od szacowania ryzyka po obsługę incydentów.

Najczęściej zadawane pytania

Czy ustawa o KSC wymaga, żeby szacowanie ryzyka uwzględniało ataki prowadzone z pomocą AI?

Art. 8 ustawy o KSC nie wymienia sztucznej inteligencji, ale jego ust. 1 pkt 2 wymaga środków technicznych i organizacyjnych uwzględniających najnowszy stan wiedzy i prawdopodobieństwo wystąpienia incydentów, a art. 8 ust. 1 pkt 3 wymaga zbierania informacji o cyberzagrożeniach. Jeśli publiczne badania i opisy incydentów pokazują, że narzędzia AI obniżają próg wiedzy potrzebnej do ataku na OT, szacowanie ryzyka prowadzone systematycznie (art. 8 ust. 1 pkt 1) powinno to uwzględnić. Art. 21 ust. 1 dyrektywy 2022/2555 (NIS2) mówi o najnowszym stanie wiedzy tak samo.

Kto w podmiocie decyduje, czy po takim raporcie zmienić zabezpieczenia OT?

Kierownik podmiotu kluczowego lub podmiotu ważnego. Art. 8d ustawy o KSC powierza mu decyzje w zakresie przygotowania, wdrażania, stosowania, przeglądu i nadzoru SZBI oraz planowanie środków finansowych, a art. 8c ust. 3 stanowi, że odpowiada także wtedy, gdy obowiązki powierzył innej osobie.

Źródła

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

Co dokładnie sprawdzono w laboratorium?

Czego raport nie mówi?

Czy coś takiego zdarzyło się już poza laboratorium?

Co to zmienia w obowiązkach z art. 8 ustawy o KSC?

Jakie zabezpieczenia wynikają z testu?

Jak to wygląda w mojej pracy pełnomocnika ds. cyberbezpieczeństwa?

Najczęściej zadawane pytania

Źródła

Powiązane artykuły

Ataki na urządzenia OT. Jak napastnicy przestawiają proces i jak ograniczyć to ryzyko według ustawy o KSC i NIS2?

Rekomendacja Pełnomocnika nr 2026-67a-9 punkt po punkcie. Jak sprawdzić własny podmiot według katalogu ministerstwa?

Łańcuch dostaw w ustawie o KSC: czego wymagać od dostawców i co wpisać do umowy?