Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Incydent dotyczący systemu pomp i zabezpieczeń przeciwpowodziowych w rejonie placu św. Marka w Wenecji pokazuje, jak poważne mogą być skutki cyberataku wymierzonego w środowiska OT i ICS. W przeciwieństwie do klasycznych naruszeń IT, kompromitacja systemów sterujących procesami fizycznymi może prowadzić nie tylko do utraty danych, ale również do zakłócenia działania infrastruktury krytycznej, strat materialnych oraz zagrożenia dla bezpieczeństwa publicznego.
To właśnie zatarcie granicy między cyberprzestrzenią a światem fizycznym staje się dziś jednym z najważniejszych wyzwań bezpieczeństwa. Systemy odpowiedzialne za ochronę przed zalaniem, dostawy energii, transport czy gospodarkę wodną coraz częściej są połączone z nowoczesnymi platformami zarządzania i monitoringu, co zwiększa ich funkcjonalność, ale jednocześnie rozszerza powierzchnię ataku.
W skrócie
- Atakujący mieli uzyskać dostęp administracyjny do elementów systemu przeciwpowodziowego obsługującego okolice San Marco.
- W sieci opublikowano materiały sugerujące obecność w środowisku operacyjnym, w tym zrzuty ekranów interfejsów sterowania i dane o stanie urządzeń.
- Napastnicy deklarowali możliwość manipulowania działaniem systemu oraz oferowali sprzedaż dostępu.
- Według dostępnych informacji kluczowe elementy chroniące bazylikę św. Marka nie zostały naruszone.
- Incydent uwypukla ryzyko fizycznych skutków cyberataków na infrastrukturę OT.
Kontekst / historia
Infrastruktura przeciwpowodziowa Wenecji ma znaczenie nie tylko operacyjne, ale również strategiczne i symboliczne. Ochrona historycznego centrum miasta przed zalaniem jest zadaniem o wysokiej randze publicznej, dlatego każda informacja o możliwym naruszeniu systemów sterowania budzi szczególne zainteresowanie opinii publicznej, administracji i środowiska bezpieczeństwa.
Według ujawnionych informacji incydent miał rozpocząć się pod koniec marca 2026 roku, a na początku kwietnia zaczęły pojawiać się publiczne materiały wskazujące na dostęp do interfejsów operacyjnych. Sam charakter publikowanych treści sugerował próbę wywarcia presji informacyjnej i zbudowania przekazu o zdolności ingerencji w działanie infrastruktury krytycznej.
Zdarzenie wpisuje się w szerszy trend wzrostu zagrożeń wobec środowisk przemysłowych. W ostatnich latach systemy OT przestały funkcjonować jako ściśle odizolowane wyspy technologiczne. Coraz częściej są integrowane z sieciami IT, zdalnym utrzymaniem, usługami dostawców zewnętrznych oraz narzędziami analitycznymi. Ta konwergencja poprawia efektywność działania, ale zwiększa ryzyko błędów konfiguracyjnych, niekontrolowanej ekspozycji i nadużyć uprzywilejowanego dostępu.
Analiza techniczna
Z technicznego punktu widzenia najbardziej niepokojący jest deklarowany poziom dostępu. Jeśli napastnicy rzeczywiście uzyskali uprawnienia administracyjne do interfejsów zarządzających elementami systemu hydraulicznego, oznacza to potencjalną możliwość wpływu na logikę działania, parametry sterowania, stany zaworów, pracę pomp albo wizualizację danych operatorskich. W środowiskach SCADA i HMI nawet częściowa kontrola nad warstwą operatorską może prowadzić do błędnych decyzji personelu i zakłócenia procesu.
Udostępnione materiały miały obejmować zrzuty paneli kontrolnych, układy systemu oraz informacje o stanie urządzeń. Taki zestaw danych sugeruje, że naruszenie mogło dotyczyć nie tylko warstwy sieciowej, ale również aplikacyjnych interfejsów wykorzystywanych do bieżącej obsługi procesu. W praktyce możliwe scenariusze obejmują przejęcie zdalnego dostępu, wykorzystanie słabych mechanizmów uwierzytelniania, kompromitację kont uprzywilejowanych, błędną segmentację pomiędzy IT i OT albo ekspozycję usług administracyjnych do internetu.
Warto podkreślić, że w systemach przemysłowych duże zagrożenie stanowi nie tylko pełne wyłączenie urządzeń, ale także subtelna manipulacja danymi. Zmiana wskazań HMI, modyfikacja alarmów, ukrywanie rzeczywistych stanów zaworów lub fałszowanie telemetrii mogą doprowadzić do błędnych działań operatorów bez natychmiastowego wzbudzenia alarmu. To jeden z powodów, dla których środowiska ICS wymagają innego podejścia do detekcji i reagowania niż klasyczne środowiska biurowe.
Incydent dobrze ilustruje również współczesną specyfikę zagrożeń OT. Atakujący nie zawsze muszą korzystać z zaawansowanych exploitów lub nieznanych podatności. Często wystarczają publicznie dostępne interfejsy, domyślne hasła, brak wieloskładnikowego uwierzytelniania, nieaktualne stacje inżynierskie, błędnie skonfigurowane połączenia serwisowe lub zbyt szerokie uprawnienia nadane zewnętrznym dostawcom.
Konsekwencje / ryzyko
Najpoważniejszym ryzykiem w podobnych incydentach jest przejście od kompromitacji cyfrowej do skutku fizycznego. W przypadku systemu przeciwpowodziowego potencjalne skutki mogłyby obejmować niedostępność mechanizmów ochronnych, błędne działanie urządzeń wykonawczych, opóźnienia reakcji operatorów albo utratę widoczności stanu procesu. Nawet krótkotrwałe zakłócenie w newralgicznym momencie może prowadzić do szkód infrastrukturalnych, strat finansowych i zagrożenia dla ludności.
Drugą kategorią ryzyka jest utrata integralności operacyjnej. W środowiskach OT niebezpieczne jest nie tylko zatrzymanie procesu, lecz także jego cicha deformacja. Atak polegający na manipulacji alarmami lub danymi procesowymi może utrudnić wykrycie naruszenia i wydłużyć czas reakcji, co w praktyce zwiększa skalę potencjalnych konsekwencji.
Trzecim problemem jest możliwość dalszego obrotu uzyskanym dostępem. Oferta sprzedaży dostępu do systemu, nawet jeśli miała wymiar propagandowy, pokazuje jak szybko incydent może przejść z fazy demonstracji do etapu wtórnej monetyzacji. W takim modelu pierwszy aktor staje się brokerem dostępu, a realne wykorzystanie kompromitacji może nastąpić później przez inny podmiot, w tym grupę nastawioną na sabotaż, szantaż lub wymuszenie.
Rekomendacje
Operatorzy infrastruktury krytycznej powinni traktować ten przypadek jako wyraźne ostrzeżenie i wdrażać podejście defense-in-depth dostosowane do realiów środowisk OT. Podstawowym krokiem pozostaje ścisła segmentacja sieci między domenami IT i OT oraz eliminacja bezpośredniej ekspozycji interfejsów sterowania do internetu.
- Wdrożenie silnej segmentacji sieci i kontroli ruchu pomiędzy strefami IT, OT oraz sieciami dostawców.
- Ograniczenie zdalnego dostępu wyłącznie do kontrolowanych punktów pośrednich z MFA, rejestrowaniem sesji i zasadą najmniejszych uprawnień.
- Pełna inwentaryzacja zasobów OT, w tym stacji inżynierskich, serwerów SCADA, paneli HMI, sterowników i połączeń serwisowych.
- Monitorowanie ruchu w segmentach przemysłowych oraz wykrywanie anomalii w komunikacji do urządzeń sterujących.
- Kontrola kont uprzywilejowanych i wykrywanie nietypowych logowań, zmian konfiguracji oraz nowych połączeń zdalnych.
- Przygotowanie scenariuszy reagowania na incydenty OT z udziałem SOC, administratorów, inżynierów automatyki, dostawców i kierownictwa operacyjnego.
- Wdrażanie zasad secure-by-design przy nowych inwestycjach infrastrukturalnych.
W odróżnieniu od klasycznych środowisk IT, izolacja systemu po wykryciu incydentu nie zawsze jest najbezpieczniejszą lub natychmiast możliwą decyzją. Dlatego plany reagowania muszą uwzględniać ciągłość procesu, bezpieczeństwo fizyczne oraz zależności pomiędzy systemami sterowania a urządzeniami wykonawczymi. Skuteczne przygotowanie wymaga nie tylko technologii, ale także regularnych ćwiczeń, testów procedur i ścisłej współpracy zespołów technicznych z kadrą odpowiedzialną za eksploatację infrastruktury.
Podsumowanie
Incydent związany z systemem przeciwpowodziowym Wenecji pokazuje, że infrastruktura OT i ICS staje się jednym z głównych celów działań hakerskich o charakterze demonstracyjnym, politycznym i destabilizującym. Niezależnie od pełnego zakresu rzeczywistej kompromitacji, już sama możliwość uzyskania dostępu do systemów sterowania odpowiedzialnych za bezpieczeństwo fizyczne stanowi poważny sygnał ostrzegawczy.
Dla operatorów infrastruktury krytycznej wniosek jest jednoznaczny: cyberbezpieczeństwo nie może być dodatkiem do eksploatacji systemu, lecz jego podstawowym elementem architektonicznym i operacyjnym. Każdy incydent dotyczący środowisk OT należy analizować nie tylko w kategoriach technicznych, ale również przez pryzmat skutków fizycznych, ciągłości działania i bezpieczeństwa publicznego.
Źródła
- Security Affairs — Hackers claim control over Venice San Marco anti-flood pumps — https://securityaffairs.com/190679/hacktivism/hackers-claim-control-over-venice-san-marco-anti-flood-pumps.html
- CISA — Cybersecurity Advisory and Alerts for Operational Technology — https://www.cisa.gov/
- NIST — Guide to Industrial Control Systems (ICS) Security — https://csrc.nist.gov/
- NSA Cybersecurity — Operational Technology Security Guidance — https://www.nsa.gov/Cybersecurity/
- MITRE ATT&CK for ICS — Knowledge Base for Adversary Tactics in ICS — https://attack.mitre.org/