Sabotaż i błąd ludzki - niedoceniane zagrożenia w środowiskach OT | SEQRED

Luty 2000 roku. Na przedmieściach Sunshine Coast w Australii mieszkańcy zaczynają skarżyć się na smród. Ścieżki rowerowe wzdłuż Eudlo Creek pokrywa cuchnąca maź. Ryby w potoku giną. Na terenie hotelu Hyatt Regency pojawia się surowy ściek. Przez dwa miesiące nikt nie może zidentyfikować przyczyny - awarie pomp ściekowych zdarzają się przecież regularnie.

Dopiero w kwietniu 2000 roku okazuje się, że za 46 incydentami stoi jeden człowiek: Vitek Boden, były pracownik firmy Hunter Watertech, która instalowała system SCADA w oczyszczalni Maroochy Shire Council. Boden, któremu odmówiono zatrudnienia w radzie gminy, jeździł po okolicy samochodem wypełnionym skradzionym sprzętem radiowym i wydawał polecenia pompowniom. W sumie uwolnił 800 000 litrów surowych ścieków do parków, rzek i terenów hotelowych.

Wyrok: dwa lata więzienia. Lekcja: pierwsza udokumentowana cyberataka na infrastrukturę krytyczną była dziełem insidera.

Dlaczego czynnik ludzki dominuje w OT

Środowiska OT różnią się od typowych środowisk IT pod jednym kluczowym względem: operatorzy mają bezpośredni, fizyczny dostęp do procesów, które mogą spowodować realne szkody - wycieki substancji chemicznych, przerwy w dostawach energii, zniszczenie sprzętu wartego miliony. Każdy błąd - czy to celowy sabotaż, czy zwykła pomyłka przy konfiguracji - może mieć konsekwencje, których nie da się cofnąć przyciskiem “undo”.

Raport Verizon DBIR 2025 wskazuje, że czynnik ludzki (human element) odpowiada za 60% naruszeń bezpieczeństwa. W regionie EMEA aż 29% naruszeń pochodzi z wewnątrz organizacji - to sześciokrotnie więcej niż w Ameryce Północnej (5%) i prawie trzydziestokrotnie więcej niż w regionie APAC (1%).

W kontekście OT problem jest jeszcze poważniejszy. Badanie SANS ICS/OT 2025 (330 respondentów) pokazuje, że 21% organizacji doświadczyło incydentu OT w minionym roku, a 40% z nich odnotowało zakłócenia operacyjne. Ponad 20% potrzebowało więcej niż miesiąca na przywrócenie normalnej pracy.

60%

naruszeń z czynnikiem ludzkim (Verizon DBIR 2025)

29%

naruszeń w EMEA od insiderów

81 dni

średni czas wykrycia zagrożenia wewnętrznego (Ponemon 2025)

$17,4M

roczny koszt incydentów insiderskich na organizację

Źródła: Verizon DBIR 2025, Ponemon Cost of Insider Risks 2025

Trzy oblicza zagrożenia wewnętrznego

Zagrożenia od wewnątrz nie ograniczają się do złośliwych sabotażystów. Ponemon Institute w raporcie Cost of Insider Risks 2025 klasyfikuje je w trzech kategoriach:

1. Nieostrożny pracownik (negligent insider)

Najczęściej: operator, który pomija procedurę, używa współdzielonego hasła lub podłącza niezweryfikowane urządzenie USB do stacji inżynierskiej. To nie zła wola - to rutyna, zmęczenie lub brak świadomości.

Przykład - Davis-Besse, 2003: Robak SQL Slammer dostał się do sieci elektrowni jądrowej Davis-Besse w Ohio przez niezabezpieczone połączenie T1 kontraktora, omijając firewall. Przez prawie 5 godzin system wyświetlania parametrów bezpieczeństwa (SPDS) był niedostępny. Operatorzy nie mieli wglądu w krytyczne dane bezpieczeństwa. Przyczyna? Niezałożony patch Microsoftu, dostępny od sześciu miesięcy, i kontraktowe połączenie sieciowe, o którym zespół bezpieczeństwa nie wiedział.

2. Złośliwy insider (malicious insider)

Świadome działanie: sabotaż, kradzież danych, manipulacja procesem. Motywacja: zemsta po zwolnieniu, korzyść finansowa, presja ze strony osób trzecich.

Przykład - Tesla, 2018: Pracownik Martin Tripp zmodyfikował kod Tesla Manufacturing Operating System (MOS), eksportując gigabajty poufnych danych, w tym fotografie i wideo z linii produkcyjnych. Zmiany wprowadzał pod fałszywymi kontami użytkowników.

Przykład - Tesla, 2020: Rosyjski obywatel Egor Kriuchkov zaproponował pracownikowi fabryki Tesli w Nevadzie milion dolarów za zainstalowanie ransomware w sieci zakładu. Pracownik zgłosił próbę FBI, a Kriuchkov został aresztowany. Ten przypadek pokazuje, że granica między insiderem a atakiem zewnętrznym jest często rozmyta.

3. Skompromitowane konto (compromised insider)

Atakujący przejmuje dane logowania pracownika i działa w jego imieniu. Z perspektywy systemów monitoringu to “normalny” użytkownik wykonujący “normalne” operacje - co czyni wykrycie wyjątkowo trudnym.

Przykład - Oldsmar, 2021: Ktoś zdalnie zalogował się przez TeamViewer do stacji uzdatniania wody na Florydzie i zmienił stężenie wodorotlenku sodu ze 100 do 11 100 ppm. Współdzielone hasła, brak MFA i przestarzały Windows 7 umożliwiły ten incydent. Szerzej piszemy o nim w analizie ataku na Oldsmar.

Wielki blackout 2003 - gdy jeden błąd zatrzymuje kontynent

14 sierpnia 2003 roku, chwilę po godzinie 16:10 czasu wschodniego, 55 milionów ludzi w ośmiu stanach USA i prowincji Ontario w Kanadzie straciło prąd. Blackout trwał do dwóch dni, spowodował straty szacowane na 6 miliardów dolarów i przyczynił się do 11 zgonów.

Przyczyna nie była cyberatakiem w klasycznym sensie - była sekwencją błędów ludzkich i technicznych:

Zaniedbana infrastruktura - linie wysokiego napięcia FirstEnergy dotknęły przerośniętych drzew w pasie transmisyjnym, którego nikt nie przycinał
Błąd oprogramowania - bug typu race condition w systemie zarządzania energią GE XA/21 wyłączył alarmy w centrum sterowania FirstEnergy na ponad godzinę
Brak świadomości sytuacyjnej - operatorzy nie wiedzieli, że sieć jest przeciążona, i nie przerzucili obciążenia w porę
Kaskadowe awarie - bez interwencji lokalna awaria rozlała się na cały północno-wschodni grid

WARNING

Blackout z 2003 roku nie wymagał hakera. Wystarczyło zaniedbanie utrzymania, niesprawdzony alarm i operatorzy, którzy nie mieli pełnego obrazu sytuacji. W OT brak procedur i świadomości może mieć skutki porównywalne z celowym atakiem.

IEC 62443-2-1 - wymagania dotyczące czynnika ludzkiego

Norma IEC 62443-2-1 definiuje wymagania dla systemu zarządzania cyberbezpieczeństwem (CSMS) w środowiskach automatyki przemysłowej. Czynnik ludzki przewija się przez cały dokument, ale kluczowe wymagania koncentrują się w kilku obszarach:

Obszar IEC 62443-2-1	Wymaganie	Cel
Świadomość i szkolenia	Okresowe szkolenia z cyberbezpieczeństwa dla całego personelu OT	Redukcja błędów z niewiedzy
Kontrola dostępu personelu	Przydzielanie uprawnień według zasady minimalnych przywilejów	Ograniczenie zasięgu potencjalnego incydentu
Zarządzanie kontami	Indywidualne konta, zakaz współdzielenia haseł, przeglądy dostępu	Rozliczalność i śledzenie działań
Weryfikacja personelu	Sprawdzanie przeszłości pracowników z dostępem do systemów krytycznych	Prewencja zagrożeń od insiderów
Zarządzanie zmianami	Formalna procedura zatwierdzania zmian w konfiguracji systemów	Zapobieganie nieautoryzowanym modyfikacjom
Reakcja na incydenty	Plan reagowania obejmujący scenariusze zagrożeń wewnętrznych	Szybka identyfikacja i izolacja problemu

Więcej o praktycznym zastosowaniu IEC 62443 w kontekście stref i korytarzy opisujemy w artykule o Defense in Depth w systemach DCS.

TIP

IEC 62443-2-1 wymaga, aby szkolenia z cyberbezpieczeństwa były dostosowane do roli pracownika. Operator DCS potrzebuje innego szkolenia niż administrator sieci OT czy kierownik utrzymania ruchu. Generyczne szkolenia “z IT” nie spełniają tego wymagania.

12 kontroli organizacyjnych - lista do wdrożenia

Na podstawie wymagań IEC 62443-2-1, wytycznych CISA dotyczących zagrożeń wewnętrznych oraz praktyk opisanych przez Ponemon Institute, poniżej przedstawiamy 12 kontroli, które pomagają ograniczyć ryzyko od czynnika ludzkiego w OT:

Ludzie

Weryfikacja przeszłości - sprawdzanie kandydatów przed przyznaniem dostępu do systemów krytycznych
Szkolenia dopasowane do roli - operator, inżynier, kontraktor - każdy potrzebuje innego programu
Kultura zgłaszania incydentów - pracownik, który zgłosił błąd, nie może być karany (Verizon DBIR 2025 pokazuje, że wskaźnik zgłaszania wzrasta 4-krotnie po odpowiednim szkoleniu)
Procedura offboardingu - natychmiastowe odebranie dostępu odchodzącym pracownikom (przypadek Bodena z Maroochy Shire pokazuje, co się dzieje, gdy tego zabraknie)

Procesy

Zasada czterech oczu - krytyczne zmiany w konfiguracji OT wymagają zatwierdzenia dwóch osób
Zarządzanie dostawcami - kontrola zdalnego dostępu kontraktorów, logi połączeń, ograniczenia czasowe (Davis-Besse: niekontrolowane połączenie T1 kontraktora obeszło firewall)
Przeglądy uprawnień - kwartalna weryfikacja, kto ma dostęp do czego; usuwanie nieaktualnych kont
Plan reagowania na insider threat - osobny playbook dla incydentów z udziałem pracowników, obejmujący aspekty prawne i HR

Technologia

Indywidualne konta - koniec ze współdzielonymi hasłami na stacjach HMI (Oldsmar: jeden login TeamViewer dla całego zespołu)
Monitoring aktywności uprzywilejowanej - nagrywanie sesji na stacjach inżynierskich i konsolach operatorskich
Segmentacja i kontrola dostępu zdalnego - ograniczenie lateral movement nawet po przejściu perymetru. Więcej o tym w naszym przewodniku po zdalnym dostępie ICS
Alerty behawioralne - wykrywanie anomalii w zachowaniu użytkowników: logowania o nietypowych porach, dostęp do systemów spoza zakresu obowiązków, masowe pobieranie danych

Koszty ignorowania problemu

Ponemon Institute w raporcie z 2025 roku szacuje, że średni roczny koszt incydentów insiderskich to 17,4 miliona dolarów na organizację - wzrost z 16,2 miliona w 2023 roku. Średni koszt pojedynczego incydentu wynosi 676 517 dolarów, a w przypadku złośliwego insidera - 715 366 dolarów.

Co istotne, firmy wydają średnio 211 021 dolarów na powstrzymanie incydentu, ale tylko 37 756 dolarów na monitoring. Ta dysproporcja - 5,6-krotna różnica - pokazuje, że większość organizacji reaguje zamiast zapobiegać.

Czas też ma cenę: incydenty insiderskie powstrzymane w ciągu 31 dni kosztują średnio 10,6 miliona dolarów. Te, które ciągną się powyżej 91 dni - 18,7 miliona.

Skala problemu - dane SANS 2025

Raport SANS State of ICS/OT Security 2025 potwierdza, że czynnik ludzki pozostaje kluczowym wektorem:

21,5% organizacji OT zgłosiło incydent cyberbezpieczeństwa w ostatnim roku
50% tych incydentów zainicjowano przez nieautoryzowany dostęp zewnętrzny (często z wykorzystaniem skompromitowanych kont pracowników)
Zaledwie 14% respondentów czuje się w pełni przygotowanych na nowe zagrożenia
Organizacje angażujące techników liniowych w ćwiczenia są 1,7x bardziej skłonne raportować wysoką gotowość

Te dane potwierdzają, że inwestycja w ludzi - szkolenia, ćwiczenia, kulturę zgłaszania - przynosi mierzalny efekt.

Co robić - podejście praktyczne

Zagrożenia wewnętrzne w OT nie wymagają wdrażania rewolucyjnych rozwiązań. Wymagają systematyczności w trzech obszarach, które organizacje często zaniedbują:

Świadomość - ludzie muszą wiedzieć, co może pójść nie tak i jak wyglądają sygnały ostrzegawcze. Nie chodzi o straszenie - chodzi o budowanie kompetencji.
Procesy - procedury muszą istnieć, być aktualne i być stosowane. Procedura offboardingu, której nikt nie realizuje, nie chroni przed kolejnym Bodenem.
Technologia - monitoring, segmentacja, kontrola dostępu - to narzędzia, które pomagają wykrywać i ograniczać skutki incydentów. Ale same w sobie nie wystarczą, jeśli ludzie je omijają.

SEQRED pomaga organizacjom w budowaniu programów bezpieczeństwa OT obejmujących wszystkie trzy wymiary - od audytów IEC 62443 po testy kontroli organizacyjnych w ramach red teamingu.

Sabotaż i błąd ludzki - niedoceniane zagrożenia w środowiskach OT