Gdy w marcu 2025 roku amerykański sąd federalny skazał Davisa Lu na cztery lata więzienia za celowe uszkodzenie chronionych systemów komputerowych, wiele firm zajmujących się zarządzaniem ryzykiem i ciągłością działania odczytało ten wyrok jako wyraźny sygnał, że wewnętrzne zagrożenia – zwłaszcza te pochodzące od pracowników uprzywilejowanych – wciąż są jednym z najsłabiej kontrolowanych obszarów odporności organizacyjnej. Sprawa Lu dostarcza materiału analitycznego, nad którym powinna pochylić się każda organizacja.

‍

Czynniki ryzyka dla insider threat

Starszy programista Davis Lu, zatrudniony od 2007 roku w firmie Eaton Corporation, producenta rozwiązań z zakresu zarządzania energią, przez lata należał do osób posiadających dostęp do kluczowych systemów firmy. W 2018 roku, po reorganizacji przedsiębiorstwa, jego rola została ograniczona, a część uprawnień odebrano. Według dokumentów sądowych to właśnie w tym momencie rozpoczął przygotowania do sabotażu – cichego, rozproszonego i trudnego do wykrycia.

W kolejnych miesiącach zaczął wprowadzać do kodu produkcyjnego fragmenty złośliwego oprogramowania, m.in. moduły nazwane „Hakai” i „HunShui”, które miały zakłócać działanie serwerów. Najważniejszym z nich był jednak „kill switch”, zaprojektowany tak, by aktywował się automatycznie po wyłączeniu jego konta w Active Directory. Mechanizm ten badano później m.in. pod nazwą funkcji „IsDLEnabledinAD”.

Gdy 9 września 2019 roku Eaton Corporation rozstała się z Lu i zablokowała jego konto, ukryty kod natychmiast został uruchomiony. W wyniku jego działania tysiące pracowników straciło możliwość logowania się do kluczowych aplikacji, a część profili użytkowników została usunięta. Serwery przeciążone przez niekończące się pętle wątków przestawały odpowiadać. Usuwanie zainfekowanych komponentów i przywracanie środowiska do stanu bezpiecznego zajęło firmie ponad rok.

‍

Skutki dla ciągłości działania

W swoich katalogach zagrożeń firmy na ogół uwzględniają sabotaż zewnętrzny, ale rozmowy o zagrożeniach ze strony własnych pracowników, to często temat tabu. Tymczasem, scenariusz insider threat jest niezwykle niebezpieczny i powinien być zawsze analizowany. Pracownik, szczególnie o wysokich uprawnieniach, posiadający pełne zrozumienie architektury systemów, w pewnych okolicznościach może zaplanować i przeprowadzić niewykrywalny, wieloetapowy sabotaż.

Davis Lu uderzył w trzy aspekty bezpieczeństwa:

• dostępność (availability) – blokada logowania, przeciążenie usług, okresowe unieruchomienie ogólnofirmowych systemów;
• integralność (integrity) – usunięcie profili użytkowników, modyfikacje kodu i konfiguracji systemów;
• zaufanie do systemów (trust/confidence) – konieczność długotrwałego dochodzenia, czyszczenia środowiska i weryfikacji, czy nie istnieją kolejne ukryte moduły.

W praktyce oznaczało to, że choć udało się stosunkowo szybko przywrócić minimalną funkcjonalność, pełne odzyskanie zaufania do systemów trwało miesiącami.

Luki, które umożliwiły atak

Analiza materiałów sądowych pozwala odtworzyć prawdopodobne słabości organizacyjne.

Zbyt szerokie uprawnienia i brak skutecznej separacji obowiązków.

‍
Lu miał możliwość samodzielnego wprowadzania i zatwierdzania zmian w kodzie produkcyjnym, a zmiany te – mimo że dotyczyły systemu używanego przez tysiące pracowników – nie zostały wykryte w standardowych procesach przeglądu i testowania.

Niewystarczający monitoring i analiza anomalii.

‍
Złośliwy kod zawierał konstrukcje (np. niekończące się pętle generujące wątki), które – monitorowane poprawnie – powinny zostać ujawnione jeszcze przed ich produkcyjnym wdrożeniem.

Część złośliwego kodu była przechowywana na serwerze deweloperskim, do którego tylko dostęp miał tylko Lu. Audyty powinny regularnie identyfikować i eliminować nieautoryzowane lub ukryte zasoby systemowe.

Brak zasad zarządzania ryzykiem osobowym i psychospołecznym w firmie.

‍
Pracownik, który zostaje zdegradowany i odbiera mu się część uprawnień, ma prawo odczuwać frustrację z tego powodu i powinien zostać objęty procedurami podwyższonego ryzyka. Zmiana stanowiska i redukcja obowiązków jest trudnym doświadczeniem. Firma powinna zapewnić wsparcie psychologiczne, jasną komunikację (zamiast pozostawienia Lu samemu sobie z poczuciem niesprawiedliwości) lub pomoc w znalezieniu nowej roli, aby zmniejszyć motywację do zemsty.

Choć nie eliminuje to w 100% zagrożeń, dbanie o pozytywną kulturę organizacyjną i otwartą komunikację pomaga w identyfikacji niezadowolonych pracowników, zanim ich frustracja osiągnie poziom prowadzący do sabotażu.

Nieudokumentowane lub niespójne repozytoria kodu.

‍
Fakt, że czyszczenie środowiska zajęło ponad rok, wskazuje na brak wzorcowych, w pełni zaufanych artefaktów do odtworzenia produkcji.

‍Jak oceniać ryzyko takiego incydentu

Z punktu widzenia analizy ryzyka przypadek Lu idealnie spełnia definicję zagrożenia typu high impact, low likelihood. Prawdopodobieństwo jest zwykle oceniane jako umiarkowane lub niskie, ale konsekwencje – zarówno finansowe, jak i operacyjne – mogą być katastrofalne.

Warto zwrócić uwagę na trzy wymiary oceny:

Prawdopodobieństwo

‍
Wzrasta w sytuacjach reorganizacji, zwolnień, konfliktów pracowniczych.
Najbardziej narażone są stanowiska uprzywilejowane: developerzy z dostępem do serwerów produkcyjnych, administratorzy systemów, konsultanci z czasowym dostępem do środowisk krytycznych.

Wpływ

‍
Incydent Lu pokazuje, że nawet częściowe zakłócenie działania kluczowego systemu może prowadzić do ogólnofirmowych przestojów. Wpływ obejmuje bezpośrednie straty finansowe (w tym przypadku setki tysięcy dolarów), a także w utratę reputacji firmy.

Ryzyko rezydualne

‍
Nawet po wdrożeniu kontroli takich jak przegląd kodu czy monitoring anomalii, pewne ryzyko sabotażu wewnętrznego zawsze pozostaje. Kluczowe jest, aby było ono świadomie zarządzane i objęte planami ciągłości działania.

‍

‍

Jakie rozwiązania warto wdrożyć

Przypadek Lu wyznacza bardzo konkretne kierunki działań.

Po pierwsze, należy projektować systemy tak, jakby ich developer mógł próbować je sabotować. Oznacza to zakaz bezpośredniego dostępu do produkcji, egzekwowanie zasad minimalnych uprawnień (least privilege) oraz obowiązkową separację uprawnień i zapobieganie konfliktom interesu, szczególnie w przypadku wprowadzania zmian w kodzie produkcyjnym.

W momencie, gdy wdrożenie przebiega poprzez zautomatyzowany pipeline, a każdy artefakt jest podpisany kryptograficznie, szansa na niezauważone manipulacje znacząco maleje.

Po drugie, organizacje muszą traktować zagrożenie typu „insider threat” jako osobną kategorię ryzyka dla bezpieczeństwa informacji i ciągłości działania. To oznacza formalne powiązanie procesów HR i bezpieczeństwa, szczególnie w momentach newralgicznych, takich jak degradacja czy zwolnienie pracownika uprzywilejowanego. Wycofanie uprawnień powinno być operacją planowaną i monitorowaną end-to-end.

‍

Po trzecie, monitoring i reakcja muszą uwzględniać wzorce charakterystyczne dla sabotażu. Powtarzające się wyjątki, nietypowe warunki logiczne w kodzie, nietypowe zachowanie użytkownika – to sygnały, które powinny być automatycznie analizowane.

Po czwarte, plan ciągłości działania musi obejmować scenariusz odbudowy środowiska po sabotażu kodu. Tu, podobnie jak w przypadku ransomware, kluczowa jest możliwość szybkiego odtworzenia środowiska „od zera”, z pełną pewnością, że komponenty pochodzą wyłącznie ze zaufanego repozytorium.

Lesson learned

‍

Choć sprawa Davisa Lu jest przykładem o dużej skali, nie jest odosobniona. Każda duża organizacja dysponuje niewielką grupą personelu posiadającego poziom dostępu umożliwiający sabotaż o podobnej destrukcyjnej sile. Ryzyko to może zmaterializować się w wyniku pojedynczej, niezweryfikowanej zmiany, luki w procedurach kontroli lub nieuwagi w okresach reorganizacji.

‍

Z perspektywy zarządzania ryzykiem, scenariusze o niskiej częstotliwości, lecz katastrofalnym wpływie powinny być traktowane priorytetowo w stosunku do incydentów częstszych, lecz łatwiejszych do zarządzania. Przypadek Lu ilustruje, że odpowiednio przygotowany insider jest w stanie jednym działaniem sparaliżować globalne systemy przedsiębiorstwa, a ich pełne przywrócenie i oczyszczenie może wymagać kilkunastu miesięcy.

‍

Dostęp uprzywilejowany jako ryzyko strategiczne

‍

Każda organizacja zatrudnia personel, którego rola lub dostęp techniczny pozwala na natychmiastowe wstrzymanie jej działalności operacyjnej za pomocą pojedynczej interwencji (np. fragmentu kodu lub konfiguracji). Pracownicy ci muszą być objęci odrębnym i rygorystycznym reżimem bezpieczeństwa. Ich uprawnienia powinny podlegać kontroli równie ścisłej jak procedury zarządzania finansami czy dostęp do systemów regulowanych.

‍

Ataki insiderskie oparte na nadanych uprawnieniach i wiedzy

‍

Sabotaż wewnętrzny wykorzystuje zrozumienie architektury systemów i nadmierne zaufanie w organizacji. Z tego względu, nawet rozbudowane systemy ochrony perymetrycznej nie zastąpią skutecznych procesów zarządzania uprawnieniami (IAM) oraz rygorystycznej kontroli zmian.

‍

Reorganizacje, konflikty i degradacje jako okresy podwyższonego ryzyka

‍

Incydenty z udziałem insiderów rzadko mają charakter przypadkowy – są często poprzedzone istotnymi zmianami w relacji pracownika z firmą. Moment zmiany roli, ograniczenia uprawnień lub zaistnienia konfliktu powinien automatycznie uruchamiać procedury oceny ryzyka oraz wzmożony monitoring działań pracownika w kluczowych systemach.

‍