Monitoring NHI – jak wykryć, iż pod maszynę podszywa się człowiek?

Wraz z rosnącą rolą automatyzacji w organizacjach przybywa tożsamości maszynowych (Non-Human Identities, NHI) – kont serwisowych, tokenów API itp. Jednocześnie wzrasta ryzyko, iż ktoś (pracownik lub atakujący) wykorzysta te konta w sposób niezgodny z przeznaczeniem. Nie wszystkie systemy IAM lub PAM wykrywają takie nadużycia, dlatego najważniejszy jest dodatkowy monitoring behawioralny, który zapewnić mogą systemy klasy UEBA (User and Entity Behavior Analytics), uczące się wzorców aktywności kont i maszyn, a następnie wykrywające nietypowe zachowania.

Na podstawie historycznych danych UEBA tworzy „punkt odniesienia” typowego zachowania, a w czasie rzeczywistym porównuje go z bieżącą aktywnością. Wykryte odchylenia – np. gwałtowny, nietypowo duży transfer danych – wyzwalają alert. Analitycy bezpieczeństwa rekomendują właśnie podejście oparte na wychwytywaniu takich odstępstw (outliers) zamiast manualnego sprawdzania każdego loga. Dzięki temu UEBA ułatwia wykrywanie nieautoryzowanego użycia NHI, zanim incydent rozwinie się w pełnoprawne naruszenie.

Jak działa UEBA?

UEBA działa zwykle w następujących krokach:

• Poznawanie normalnego zachowania: System zbiera logi (autoryzacji, ruchu sieciowego, operacji na plikach itp.) i przy pomocy algorytmów ML (Machine Learning) wyznacza wzorce typowej aktywności kont i maszyn.
• Monitorowanie i detekcja anomalii: W czasie rzeczywistym UEBA porównuje bieżące zdarzenia z modelem zachowań. Wykryte odstępstwa (anomalie) są natychmiast oznaczane jako podejrzane. Na przykład system może zauważyć, iż usługa lub konto nieoczekiwanie inicjuje bardzo duży transfer danych, co automatycznie generuje alert.
• Alertowanie i eskalacja: Po wykryciu anomalii UEBA wysyła szczegółowy alert do zespołu SOC (Security Operations Center). Alert zawiera informacje o rodzaju odchylenia i kontekście działania, co pozwala analitykom gwałtownie zweryfikować incydent i podjąć działania (np. odciąć serwis, zresetować klucze).

Dzięki ciągłemu uczeniu się i korekcji modelu UEBA redukuje szum i klasyfikuje jako podejrzane wyłącznie znaczące odchylenia. Eksperci podkreślają, iż koncentracja na takich „outlierach” jest znacznie efektywniejsza niż manualne przeglądanie wszystkich zdarzeń.

Jak odróżnić BAU od incydentu?

Oddzielenie normalnej aktywności (BAU – Business As Usual) od podejrzanych zachowań to nie lada wyzwanie. najważniejsze jest poznanie typowych wzorców – np. jakie zadania wykonywane są rutynowo przez konta maszynowe (np. codzienne backupy, automatyczne skrypty wsparcia itp.). Specjaliści zalecają, by wszystkie takie „zasadniczo dozwolone” użycia NHI zostały zrozumiane i zgłoszone jako dozwolone. W przeciwnym razie choćby istotne anomalie mogą zostać pominięte.

• Uczenie się normalnego tła: Organizacja musi zidentyfikować rutynowe zachowania BAU (np. logowania skryptów o stałych porach, zaufane lokalizacje czy stały wolumen transferów) i uwzględnić je w modelu UEBA. Dzięki temu narzędzie uzna je za normalne i nie będzie fałszywie alarmować. Dopiero znaczące odchylenia (np. działania uruchomione poza zwykłymi godzinami czy z nietypowej lokalizacji) zostaną oznaczone jako anomalie. System UEBA automatycznie sygnalizuje takie odstępstwa i wysyła alert do zespołu bezpieczeństwa.
• Analiza sygnałów ostrzegawczych: Niektóre wskaźniki pomagają zidentyfikować potencjalne podszycie się pod tożsamość konta serwisowego. Na przykład seria logowań z bardzo odległych lokalizacji w krótkim czasie (impossible travel) lub próby wejścia o nietypowej porze dnia (lub nocy) są znakiem ostrzegawczym. UEBA rejestruje takie przypadki i wskazuje je do dodatkowej analizy.
• Odróżnianie fałszywych alarmów: UEBA może czasem oznaczać standardowe zachowanie jako podejrzane – zdarzają się alerty fałszywie dodatnie. Dlatego najważniejsze jest manualne sprawdzenie alertów przez analityków SOC, którzy odfiltrują te wynikające z normalnej działalności. Zastosowanie dodatkowych źródeł danych (np. korelacja z systemami CMDB, analizą procesów biznesowych) pomaga ocenić, czy wykryta anomalia to naprawdę incydent, czy tylko rutynowa operacja.

Jak ograniczyć fałszywe alarmy?

Fałszywe alarmy w monitoringu NHI zwykle wynikają z braku opisanej normalności – to klasyczny problem „BAU vs incydent” – a NIST podkreśla, iż zbudowanie baseline to cel regularnej analizy logów.

Trzy kroki, które realnie odciążają SOC:

1. Opisz BAU dla top‑N krytycznych NHI – okna czasowe, wolumen, źródła wywołań, zasoby docelowe i dozwolone operacje.
2. Wyjątki traktuj jak zmianę – akceptacja odchylenia powinna mieć ownera, datę ważności i powód biznesowy, inaczej baseline się rozjedzie.
3. Priorytetyzuj i filtruj z kontekstem – NIST opisuje filtrowanie do „rozsądnej liczby” wpisów oraz różne poziomy priorytetu, żeby ręczna analiza była wykonalna.

Podsumowując, skuteczny monitoring NHI łączy uczenie maszynowe z kontekstem biznesowym. Implementując UEBA i dostosowując go do realiów swojej firmy, organizacja może wykryć próby „podróży w ciele” (maskowania się) ludzi jako maszyn, zanim nadużycie przerodzi się w poważny incydent.