Analiza cyberataków na polską infrastrukturę energetyczną z 29 i 30 grudnia 2025 roku obnaża niewygodną prawdę o stanie cyberbezpieczeństwa w sektorze krytycznym dla funkcjonowania państwa.

‍

To, co w pierwszych komunikatach prezentowano jako "wyrafinowany atak obcych służb", po analizie raportów technicznych CERT Polska okazuje się w znacznej mierze skutkiem rażących zaniedbań w konfiguracji systemów i fikcji procesów kontrolnych. Klaster grup APT powiązanych z rosyjskimi służbami, nie musiał stosować zaawansowanych metod, exploitów zero-day, etc. - wystarczyły domyślne hasła i usługi sieciowe szeroko otwarte na świat.

‍

1. Rażące zaniedbania w instalacjach OZE

‍

Raport z ataków na farmy wiatrowe i fotowoltaiczne ujawnia obraz, który powinien wywołać konsternację w środowisku inżynierskim.

‍

Wszystkie zaatakowane typy urządzeń - sterowniki RTU Hitachi, sterowniki RTU Mikronika, sterowniki zabezpieczeń Hitachi Relion, komputery HMI Mikronika oraz serwery portów Moxa - pracowały na niezmienionych domyślnych poświadczeniach. Atakujący wykorzystali wbudowane konta z hasłami typu "Default" lub standardowymi loginami dostępnymi w dokumentacji technicznej urządzeń. Co więcej, funkcje bezpieczeństwa dostępne w urządzeniach nie zostały włączone.

‍

CERT Polska stwierdza wprost:

‍

"Funkcja secure update, która umożliwiałaby sprawdzenie podpisu wgrywanego firmware, została udostępniona w wersji 13.2.1, jednak wymagała ona włączenia. Na żadnym z urządzeń, które wspierało secure update, ta funkcja nie została włączona."

‍

Szczególnie uderzający jest fakt, że w przypadku sterowników Hitachi Relion raport wskazuje:

‍

"Należy podkreślić, że gdyby urządzenie zostało wdrożone zgodnie z zaleceniami producenta, to domyślne konto FTP zostałoby automatycznie zablokowane."

‍

Taka sytuacja świadczy o braku podstawowej higieny cyfrowej w instalacjach sterujących łączną mocą około 1,5 GW.

‍

2. Luki w procesie odbioru instalacji

‍

Można stawiać pytanie o podział odpowiedzialności między dostawcą lub integratorem systemu a właścicielem instalacji. Czy fakt pozostawienia defaultowych haseł jest winą integratora czy klienta? Kto powinien zadbać o to, by oddane do eksploatacji systemy infrastruktury krytycznej nie zawierały prymitywnych wręcz luk w zabezpieczeniach?

‍

W typowym procesie wdrożenia integrator często używa haseł domyślnych podczas testów i uruchomienia, aby ułatwić współpracę wielu ekipom. Problem pojawia się, gdy w kontrakcie nie ma wymagania "końcowego utwardzenia" systemu przed oddaniem do eksploatacji.

‍

Z drugiej strony, zgodnie z obowiązującą Ustawą o krajowym systemie cyberbezpieczeństwa, to Operator Usługi Kluczowej odpowiada za bezpieczeństwo swoich systemów. Jednak fakt, że właściciele farm OZE – będący formalnie elementem KSC – wykazują brak elementarnej wiedzy o stanie zabezpieczeń własnych urządzeń, jest rażącym naruszeniem ducha Ustawy.

‍

Ustawa wymaga od operatorów posiadania odpowiednich zasobów i kompetencji, jednak w praktyce są one często outsourcowane bez realnego nadzoru merytorycznego. Ufność w to, że działająca instalacja jest bezpieczna, gdyż takie wymaganie sformułowaliśmy w umowie z usługodawcą to niedopuszczalna postawa w sektorach infrastruktury krytycznej.

‍

Brak weryfikacji zmiany haseł domyślnych w sterownikach Hitachi czy Moxa dowodzi, że nadzór nad outsourcerami miał charakter wyłącznie formalny. Autorzy dyrektywy NIS2 zauważyli ten problem i stąd właśnie pojawiła się w niej konieczność posiadania kompetencji w zakresie cyberbezpieczeństwa przez kierownictwo podmiotu kluczowego lub ważnego. Żeby czymś zarządzać, trzeba mieć choć mgliste pojęcie o materii, której dotyczą podejmowane decyzje. Klient nie jest dzieckiem – ma obowiązek wiedzieć, za co płaci i jak sprawdzić, czy usługa została wykonana rzetelnie.

‍

Proces przekazania instalacji powinien kończyć się formalną sesją, w której właściciel w obecności integratora wprowadza własne poświadczenia, a integrator potwierdza, że konta techniczne i serwisowe zostały usunięte lub zablokowane. W profesjonalnym procesie inżynierskim "oddanie instalacji" powinno obejmować nie tylko sprawdzenie parametrów elektrycznych, ale również formalne potwierdzenie przekazania uprawnień dostępowych i zamknięcia kont serwisowych. Pozostawienie haseł typu "Default" przy obiekcie o mocy 1,5 GW świadczy o tym, że obie strony - i dostawca, i klient - potraktowały cyberbezpieczeństwo jako formalność, a nie integralny element infrastruktury krytycznej.

‍

‍

‍

3. Atak na elektrociepłownię i 9 miesięcy ślepoty

‍

Jeszcze bardziej niepokojący obraz wyłania się z ataku na elektrociepłownię. Intruz infiltrował infrastrukturę przez dziewięć miesięcy - od marca do grudnia 2025 roku - zanim podjął próbę uruchomienia destrukcyjnego oprogramowania typu wiper. W tym czasie atakujący systematycznie prowadził rekonesans, wykonywał zrzuty ekranu systemów z nazwą "scada", skanował sieć narzędziami systemowymi oraz kradł poświadczenia z kontrolera domeny. Pod koniec lipca 2025 roku dokonał zrzutu całej bazy Active Directory (ntds.dit), co oznacza przejęcie pełnej kontroli nad tożsamością w organizacji.

‍

Kluczowe podatności, które umożliwiły ten atak, to przede wszystkim brak uwierzytelniania dwuskładnikowego (MFA) w dostępie VPN oraz kompromitujący błąd w konfiguracji urządzenia brzegowego Fortigate. Poświadczenia do maszyn wewnętrznych były zapisane na sztywno w formie "zakładek" (bookmarks) w konfiguracji VPN, co pozwalało intruzowi na automatyczne logowanie do systemów wewnętrznych bez znajomości haseł. Raport ujawnia również, że niektórzy użytkownicy posiadali statycznie ustawione poświadczenia użytkownika docelowego, co umożliwiało łączenie się do maszyny przesiadkowej z portalu SSL-VPN bez podawania dodatkowych danych uwierzytelniających.

‍

Funkcja bookmarks w portalach SSL-VPN jest przeznaczona dla wygody użytkowników biurowych, a nie do zarządzania dostępem do serwerów SCADA czy kontrolerów domeny. W poprawnie skonfigurowanym środowisku przejęcie hasła do VPN to dopiero początek – atakujący musi jeszcze znać login i hasło do konkretnej stacji roboczej (Jump Host). W tej elektrociepłowni administratorzy stworzyli intruzowi autostradę.

‍

Atakujący po wejściu na portal VPN widział listę ikon (bookmarks).Kliknięcie w ikonę automatycznie logowało go do systemów wewnętrznych, ponieważ poświadczenia (login i hasło) były zaszyte w konfiguracji urządzenia brzegowego.

‍

To tak, jakby zostawić klucz pod wycieraczką, a na drzwiach umieścić instrukcję, gdzie w domu schowane są pieniądze.

‍

Użycie zakładek z zapisanymi hasłami sprawia, że w logach systemowych logowanie wygląda na w pełni legalne. Systemy monitoringu nie widziały prób zgadywania haseł (Brute Force) ani podejrzanych błędów uwierzytelniania, bo intruz użył „gotowca” podanego mu na tacy przez administratorów.

‍

Fortinet (producent Fortigate) w swoich Best Practices dla SSL-VPN wyraźnie odradza statyczne zapisywanie haseł w zakładkach RDP/VNC, szczególnie w środowiskach o podwyższonym ryzyku. Zignorowanie tych zaleceń przez podmiot będący operatorem usługi kluczowej to dowód na to, że konfiguracja była robiona „na skróty”, byle było wygodnie dla personelu technicznego.

‍

Opisana konfiguracja Fortigate (statyczne hasła w zakładkach) zostałaby skompromitowana przez dowolnego pentestera w pierwszych minutach pracy. To, że ta luka przetrwała dziewięć miesięcy infiltracji, sugeruje, że rzetelnych testów penetracyjnych po prostu nie było.

‍

‍

Na szczęście nowe prawo, wdrażające unijną dyrektywę NIS2, kładzie nacisk na systematyczne testowanie środków zarządzania ryzykiem. Choć poprzednia wersja ustawy skupiała się na audytach zgodności dokumentacji, obecne przepisy wymagają praktycznego sprawdzania skuteczności wdrożonych zabezpieczeń. Martwi jedynie przyzwolenie na długi czas wdrożenia i bezkarność w pierwszych dwóch latach obowiązywania nowej ustawy.

‍

4. Skala planowanej katastrofy

‍

Analiza pełnego zakresu planowanego sabotażu, zgodnie z klasyfikacją MITRE ATT&CK ICS, ujawnia skalę potencjalnej katastrofy, którą udało się powstrzymać w ostatniej chwili. Atakujący przygotowali wielowarstwowy scenariusz destrukcji obejmujący:

‍

• Wgranie uszkodzonego firmware do sterowników RTU, co uniemożliwiłoby ich uruchomienie (T0857 System Firmware, T0892 Module Firmware)
• Modyfikację konfiguracji macierzy RAID na serwerach, niszcząc strukturę danych (T1561.002 Disk Structure Wipe)
• Zmianę adresacji IP zaatakowanych urządzeń, co sparaliżowałoby możliwość zdalnego przywrócenia kontroli (T1490 Inhibit System Recovery)
• Fizyczne wyłączanie urządzeń automatyki przemysłowej po przeprowadzeniu sabotażu (T0816 Device Restart/Shutdown)

‍

Gdyby plan się powiódł, byłaby to wielodniowa, a może wielotygodniowa utrata kontroli nad obiektem, wymagająca fizycznej wymiany sprzętu i odbudowy konfiguracji od podstaw. Fakt, że EDR zdołał zablokować atak na etapie dystrybucji wipera przez GPO, zanim doszło do wyczyszczenia firmware’u urządzeń, okazał się szczęściem w nieszczęściu.

‍

5. Ironia losu - atakujący wykorzystują AI, obrońcy ignorują podstawy

‍

Dodatkowym, ironicznym elementem ataków z grudnia 2025 roku jest wykorzystanie przez napastników dużych modeli językowych (LLM) do tworzenia narzędzi destrukcyjnych. W incydencie związanym z przedsiębiorstwem z sektora produkcyjnego atak został przeprowadzony przy użyciu wipera napisanego w PowerShell, nazwanego przez CERT Polska "LazyWiper". Analiza kodu ujawnia ciekawe szczegóły dotyczące metod pracy współczesnych grup APT.

‍

Skrypt nadpisuje pliki pseudolosowymi ciągami 32 bajtów, umieszczanymi co 16 bajtów, co teoretycznie ma nadpisać 2/3 zawartości pliku, uniemożliwiając jego użycie lub odtworzenie. Kluczowa funkcja WriteRandomBytes, odpowiedzialna za niszczenie danych, wyróżnia się na tle reszty kodu. Ma inny układ, odmienny styl pisania oraz całkowicie różną konwencję formatowania. Co więcej, zawiera bezsensowne komentarze, których - jak słusznie zauważa CERT Polska - prawdopodobnie nie umieściłby żaden ludzki programista piszący kod produkcyjny.

‍

Najbardziej wymowny jest fakt, że algorytm optymalizacyjny – służący nadpisywaniu 2/3 pliku zamiast całości, co miało przyspieszyć proces destrukcji - ze względu na sposób realizacji operacji plikowych w praktyce działa znacznie wolniej niż proste, sekwencyjne nadpisanie całego pliku. To klasyczny przykład "halucynacji" modelu LLM. Na pozór logiczne rozwiązanie przy głębszej analizie okazuje się nieoptymalnym kompromisem wynikającym z braku prawdziwego zrozumienia działania systemu operacyjnego.

‍

Ta obserwacja stawia całą sytuację w nowym, gorzkim świetle.

‍

‍

Co więcej, fakt użycia AI-generowanego kodu może świadczyć o dwóch rzeczach. Po pierwsze, pokazuje, jak bardzo obniżyła się bariera wejścia w tworzenie zaawansowanych narzędzi cybernetycznych. Nawet atakujący o ograniczonych umiejętnościach programistycznych mogą teraz zlecić LLM napisanie funkcji niszczącej dane.

‍

Po drugie, paradoksalnie, wskazuje na pewną desperację lub ograniczenia czasowe po stronie napastników - skoro poświęcili czas na infiltrację trwającą dziewięć miesięcy, ale ostatecznie narzędzie destrukcyjne zawiera kod AI o słabej jakości, może to sugerować, że końcowa faza ataku była realizowana pod presją czasu lub przez operatorów o mniejszych kompetencjach niż zespół prowadzący rekonesans.

‍

Niezależnie od motywacji, kontrast pozostaje uderzający - doświadczona i niebezpieczna grupa uzbrojona w LLM wchodzi przez konto zabezpieczone hasłem "admin".

‍

6. Znane techniki, nieobecny monitoring

‍

‍

• Default Credentials (T0812) - każde profesjonalne narzędzie do audytu bezpieczeństwa OT potrafi wykryć niezmienione hasła fabryczne.
• OS Credential Dumping (T1003) - zrzuty LSASS i NTDS to jedne z najbardziej oczywistych sygnałów włamania, monitorowane przez każdy system EDR.
• Screen Capture automatyki (T0852) - masowe wykonywanie zrzutów ekranu systemów SCADA przez narzędzie nircmd to anomalia, która powinna wzbudzić natychmiastowy alert.
• GPO Modification (T1484.001) - modyfikacja krytycznej polityki "Default Domain Policy" powinna być monitorowana i wymagać dodatkowej autoryzacji.

‍

Co więcej, atakujący korzystali z legalnych serwisów do komunikacji i eksfiltracji - pobierali narzędzia z Dropbox (T1105 Ingress Tool Transfer), a wyniki działania skryptów przesyłali na kanał Slack przez webhook (T1567.004 Exfiltration Over Webhook). Napastnicy używali tych samych narzędzi, których używają legalni administratorzy IT. Właśnie dlatego wykrycie wymagało nie tyle zaawansowanych narzędzi, co podstawowej higieny monitoringu i zrozumienia, co jest normalnym zachowaniem w danej sieci.

‍

Urządzenie Fortigate stało się dla atakujących bazą operacyjną (T1133 External Remote Services jako mechanizm utrzymywania długotrwałej obecności w infrastrukturze). Zainstalowali na nim skrypty automatycznie kradnące poświadczenia administratorów i modyfikujące konfigurację (T1053 Scheduled Task/Job). To oznacza, że nawet gdyby obrońcy wykryli włamanie i "wyrzucili" intruza z sieci wewnętrznej, mógł on wrócić przez VPN, który był całkowicie pod jego kontrolą.

‍

7. Higiena monitoringu

‍

Skuteczny monitoring wymaga oprócz wiedzy o wystąpieniu anomalii także zrozumienia jej znaczenia. To kluczowe rozróżnienie, które ujawnia prawdziwą naturę problemu. Zaawansowane systemy EDR i SIEM potrafią wykryć techniczną anomalię, np. nietypowe wywołanie API, podejrzany hash procesu, niezwykłą sekwencję zdarzeń systemowych, ale nie potrafią samodzielnie rozstrzygnąć, czy dana aktywność jest zagrożeniem, czy rutynową pracą administratora. To wymaga wiedzy kontekstowej o specyfice pracy danej organizacji.

‍

Wzorzec zachowania użytkowników, czyli co jest "normalne" w tej konkretnej sieci?

‍

W profesjonalnie zarządzanej infrastrukturze kluczowe jest zdefiniowanie i udokumentowanie normalnego zachowania użytkowników. W przypadku elektrociepłowni powinno to obejmować odpowiedzi na pytania:

‍

• Kto i kiedy ma prawo logować się do kontrolera domeny? Jeśli w organizacji są dwaj administratorzy systemu pracujący w godzinach 8-16, to logowanie o 3 w nocy lub logowanie trzeciej, nieznanej tożsamości jest anomalią behawioralną, nawet jeśli technicznie używa poprawnych poświadczeń.
• Skąd pochodzą typowe połączenia RDP do maszyn przesiadkowych? Jeśli administratorzy łączą się zawsze z wewnętrznej sieci biurowej, to połączenie z węzła TOR lub zagranicznego adresu IP jest natychmiastowym sygnałem alarmowym.
• Jakie narzędzia są standardowo używane w środowisku? Jeśli w organizacji nie używa się narzędzia nircmd do automatycznych zrzutów ekranu, to jego pojawienie się na dziesiątkach maszyn w krótkim czasie to wyraźna oznaka, że dzieje się coś złego.
• Jaki jest profil dostępu do systemów SCADA? Jeśli inżynier automatyki łączy się do systemów HMI raz na kwartał podczas planowanych przeglądów, to codzienne przeglądanie zasobów SMB z nazwą "scada" z poziomu serwera domenowego jest absolutnie nietypowe.

‍

Konkretne przykłady z raportu, które stanowiły wyraźne “czerwone flagi”

‍

Przyjrzyjmy się aktywności opisanej w raporcie przez pryzmat tego, co powinno wzbudzić alarm w organizacji znającej swój wzorzec zachowania.

‍

Przykład 1: Masowe zrzuty ekranu

‍

Raport stwierdza: "Wykorzystywał w tym celu narzędzie konsolowe nircmd, za pomocą którego wykonywał zrzuty ekranów poszczególnych urządzeń."

Pytanie podstawowe: Czy w Państwa elektrociepłowni administratorzy rutynowo wykonują zrzuty ekranu sterowników przemysłowych za pomocą narzędzia wiersza poleceń?

Odpowiedź: Oczywiście, że nie. Dokumentacja problemów technicznych odbywa się poprzez systemy ticketingowe, a zrzuty ekranu robi się manualnie, narzędziami GUI, i od razu wkleja do zgłoszenia. Masowe, zautomatyzowane screenshoty poprzez PsExec na dziesiątkach maszyn to działanie charakterystyczne wyłącznie dla rekonesansu.

‍

Przykład 2: Godziny aktywności

‍

Raport wskazuje: "Działania te były rozłożone w czasie, w zdecydowanej większości prowadzono je w godzinach pracy biurowej."

Tu pojawia się subtelność. Atakujący próbowali wtopić się w normalny rytm organizacji, działając w godzinach 9-17. To taktyka kamuflażu. Ale pojawiają się pytania:

• Czy administrator codziennie przez miesiąc skanuje sieć poleceniem netstat -r i robi zrzuty ARP cache?
• Czy administrator po wykonaniu takiego skanu zapisuje wyniki do pliku outlog.txt w katalogu C:\Windows\TEMP\ zamiast do ustalonej lokalizacji z logami?

Organizacja, która wie, jak pracują jej ludzie, natychmiast zauważy, że to nie jest typowy wzorzec dla rozwiązywania problemów.

‍

Przykład 3: Exfiltracja przez Slack webhook

‍

Raport ujawnia: "Przesyłanie wyników wykonania skryptów na kanał Slack"

Pytanie: Czy Państwa dział IT używa Slacka jako platformy komunikacyjnej?

• Jeśli tak - czy mają Państwo udokumentowane, które skrypty automatyzacyjne mają uprawnienia do wysyłania danych przez webhooks i do jakich konkretnie kanałów?
• Jeśli nie - dlaczego w logach sieciowych pojawia się ruch wychodzący do API Slacka?

W obu przypadkach powinien zapalić się alarm. W pierwszym – nieautoryzowany webhook. W drugim – ruch do usługi, której organizacja oficjalnie nie używa.

‍

Problem braku kompetencji

‍

Najczęstszą odpowiedzią na pytanie "dlaczego tego nie wykryliście?" jest: "alerty były, ale nie mieliśmy mocy przerobowych ich analizy" albo "uznaliśmy to za fałszywe pozytywy". To ujawnia problem polegający na tym, że organizacja posiada narzędzia, ale brak jej kompetencji lub ludzi (lub jednego i drugiego) do ich skutecznego wykorzystania.

‍

System SIEM może wygenerować alert: "Wykryto wykonanie nircmd.exe na 15 maszynach w ciągu 2 godzin", ale jeśli analityk SOC:

‍

• nie wie, że nircmd nie jest standardowym narzędziem w tej organizacji,
• nie ma listy zatwierdzonych narzędzi administracyjnych,
• nie rozumie różnicy między siecią IT a siecią OT i nie wie, że maszyny z nazwą “scada” są szczególnie chronione,
• zamyka ticket jako "fałszywy pozytyw", bo "przecież PsExec to legalne narzędzie Microsoft",

‍

...to najlepsze narzędzia są bezużyteczne.

‍

Różnica między wiedzą, a zrozumieniem

‍

System EDR w elektrociepłowni wiedział, że ktoś wyciągnął dane z procesu LSASS (kradzież haseł), użył narzędzia Rubeus (ataki na Kerberos) i że ktoś skopiował całą bazę ntds.dit (wszystkie hasła w domenie).

‍

Najwyraźniej jednak system nie rozumiał, że to oznacza przejęcie pełnej kontroli nad organizacją. Dopiero gdy wiper próbował się uruchomić, sygnatura znana w bazach zagrożeń wywołała automatyczną blokadę.

‍

Gdyby w zespole był analityk, który rozumie, że kradzież ntds.dit to nie jest "podejrzane zdarzenie do obserwacji", ale incydent poważny wymagający izolacji sieci - atak zostałby powstrzymany w maju, a nie w grudniu.

‍

Co oznacza higiena monitoringu?

‍

To zestaw podstawowych, lecz żmudnych praktyk, które są czasochłonne i wymagają stałej konserwacji. Jeśli oczekujemy, że monitoring będzie wykonywany “w tzw. międzyczasie” przez pracowników pełniących inne obowiązki, narażamy się na podobną sytuację jak zaatakowana elektrociepłownia - mamy narzędzia, ale jeśli nikt nie będzie ich używał, lub będzie używał ich sporadycznie z braku czasu, może to spowodować poważne problemy.

‍

• Inwentaryzacja wszystkich programów używanych przez IT/OT w organizacji.
• Określenie ról, czyli zdefiniowanie kto, kiedy i z jakich lokalizacji ma prawo wykonywać konkretne zadania?
• Baseline ruchu sieciowego, czyli odpowiedź na pytanie, które systemy komunikują się ze sobą i jaka komunikacja jest anomalią?
• Zdefiniowanie ścieżki eskalacji zdarzeń, czyli jasnego podziału, które alerty może zamknąć junior SOC, a które wymagają eskalacji do CISO.
• Regularne przeglądy - np. co tydzień, co miesiąc przeglądanie zamkniętych alertów pod kątem weryfikacji "czy czegoś nie przegapiliśmy?".

‍

To absolutne podstawy, które w zaatakowanych obiektach najwyraźniej nie zostały skutecznie wdrożone.

‍

Raport CERT Polska pokazuje, że atakujący wcale nie musieli być geniuszami zła. Wystarczyło tylko upewnić się, że po drugiej stronie nie ma nikogo, kto rozumie własną sieć na tyle dobrze, by zauważyć, że coś jest nie tak. I to jest najgorszy możliwy wniosek dla podmiotów kluczowych - zaawansowane narzędzia stoją bezczynnie, podczas gdy intruz przez 9 miesięcy robi dokładnie to, co powinno wzbudzić natychmiastową reakcję u każdego kompetentnego administratora.

‍

8. Pytania o skuteczność i egzekucję audytów KSC

‍

Wystąpienie tak podstawowych podatności, jak brak silnych metod uwierzytelniania czy nieaktywne funkcje secure update, stawia pod znakiem zapytania proces audytowy w zaatakowanych podmiotach.

‍

Należy zweryfikować, czy audytorzy zidentyfikowali te braki i w jaki sposób zostały one sklasyfikowane w raportach. Jeśli luki te zostały wskazane jako ryzyka krytyczne, odpowiedzialność przesuwa się na poziom kierownictwa, który nie nadał priorytetu działaniom naprawczym lub świadomie je odroczył z przyczyn operacyjnych czy finansowych. W takim przypadku mamy do czynienia z "akceptacją ryzyka" przez zarząd, co przy obiektach infrastruktury krytycznej powinno wiązać się z osobistą odpowiedzialnością członków zarządu.

‍

Jeśli natomiast audyt nie wykazał tych podatności, sugeruje to poważny problem z zastosowaną metodyką. Audyt mógł skupić się zbyt mocno na weryfikacji dokumentacji (tzw. paper-compliance), pomijając techniczną weryfikację odporności systemów. W takim modelu audytor sprawdza np. istnienie "polityki haseł", ale nie prosi pracowników o fizyczne zalogowanie się do sterownika Hitachi czy Moxa, by sprawdzić faktyczny stan konfiguracji.

‍

‍

9. Jak rozliczać audytorów nie narażając ich na ataki?

‍

Upublicznienie tożsamości firm audytorskich obsługujących infrastrukturę krytyczną niesie ze sobą ryzyko ich infiltracji przez obce służby, niemniej obecny brak jakiejkolwiek transparentności prowadzi do degradacji jakości usług.

‍

‍

Należy rozważyć wprowadzenie rejestru audytów dla Operatorów Usług Kluczowych – np. w systemie S46, gdzie widniałaby nazwa firmy audytorskiej oraz zakres przeprowadzonej weryfikacji. Transparentność byłaby najsilniejszym motywatorem do rzetelności - żadna renomowana firma nie mogłaby sobie pozwolić na powiązanie swojej marki z raportem, który pominął tak prymitywne podatności jak te w sterownikach Hitachi czy Moxa, lub z audytem elektrociepłowni, w której VPN pracował bez MFA z zapisanymi na sztywno hasłami. W zasadzie, kierownictwo tych podmiotów mogłoby z powodzeniem dochodzić zwrotu pieniędzy za tak przeprowadzony audyt.

‍

Obecny system nadzoru nad audytorami jest dziurawy. Wiele podmiotów operujących w polskiej infrastrukturze krytycznej legitymuje się akredytacjami wydanymi poza Polskim Centrum Akredytacji (PCA), co sprawia, że proces składania skarg staje się fikcją. Skargi na brak rzetelności audytora często utykają w zagranicznych jednostkach akredytujących, dla których kontrola polskiej jednostki certyfikującej to dodatkowy koszt i logistyczne wyzwanie.

‍

‍

Co więcej, jeśli dana jednostka akredytująca systematycznie certyfikuje nierzetelnych audytorów, państwo powinno mieć prawo do czasowego zawieszenia uznawania akredytacji tej jednostki na swoim terytorium w zakresie audytów bezpieczeństwa. Być może jest to postulat, który powinien trafić bezpośrednio pod obrady Komisji Europejskiej w ramach monitorowania wdrożenia i egzekucji wymagań dyrektywy NIS2, aby ukrócić proceder turystyki akredytacyjnej i uzyskać jednolity, wysoki poziom usług audytorskich w zakresie cyberbezpieczeństwa.

‍

10. Legislacyjna niemoc i okno możliwości dla atakujących

‍

Paradoksalnie, incydenty z grudnia 2025 roku nastąpiły w momencie przełomowym dla polskiego prawa. W styczniu 2026 roku przez parlament przeszła nowelizacja ustawy o Krajowym Systemie Cyberbezpieczeństwa, wprowadzająca drastyczne zmiany w systemie kar. Nowe przepisy pozwalają na nakładanie kar na podmioty kluczowe sięgających nawet 100 mln zł lub 2% całkowitego rocznego obrotu. Wprowadzono także osobistą odpowiedzialność kierowników - organ właściwy do spraw cyberbezpieczeństwa zyskał uprawnienie do nakładania kar pieniężnych bezpośrednio na kierownika operatora usługi kluczowej, jeśli ten nie dochował należytej staranności.

‍

Problem polega jednak na mechanizmie vacatio legis - nowa ustawa daje rok na wdrożenie wymagań, a kary będą stosowane dopiero po dwóch latach. Jeśli na dziś wdrażanie zabezpieczeń w krytycznym sektorze wygląda tak, jak w zaatakowanych farmach OZE i elektrociepłowni, to nie budzi wielkich nadziei na szybkie zmiany.

‍

Atakujący, jak pokazuje grupa Sandworm, nie zasypują gruszek w popiele i nie będą czekać na zakończenie polskich okresów przejściowych. Sektory kluczowe funkcjonują obecnie w stanie zawieszenia, gdzie nie wyciąga się konsekwencji z wielokrotnych zaniedbań, a nowe wymagania jeszcze nie obowiązują. To dogodne okoliczności dla działań rozmaitych “złych aktorów”.

‍

11. Postulat jawności i odpowiedzialności

‍

Sytuacja wymaga systemowych zmian wykraczających poza pojedyncze postępowania prokuratorskie. Należy również uporządkować "szarą strefę" odpowiedzialności między dostawcami a operatorami infrastruktury krytycznej. Przerzucanie się odpowiedzialnością między klientem a dostawcą musi zostać zastąpione przez standard "Secure by Default", którego spełnienie jest warunkiem koniecznym do podpisania protokołu końcowego. Rzetelny proces przekazania instalacji powinien obejmować nie tylko sprawdzenie parametrów technicznych, ale również formalne potwierdzenie przekazania uprawnień dostępowych i zamknięcia kont serwisowych.

‍

‍