Uczenie maszynowe w bezpieczeństwie IT: wykrywanie anomalii i ataków w logach

Po co łączyć uczenie maszynowe z bezpieczeństwem IT?

Skala logów kontra możliwości zespołów bezpieczeństwa

Średniej wielkości organizacja generuje każdego dnia miliony wpisów w logach: z firewalli, serwerów, aplikacji, chmury, VPN, systemów pocztowych. Każdy wpis to potencjalny ślad ataku lub nadużycia, ale większość z nich opisuje zwykłe, rutynowe działanie systemów i użytkowników. Ręczna analiza takiego wolumenu danych jest praktycznie niemożliwa – nawet dobrze zorganizowany SOC zobaczy tylko wąski wycinek tego, co naprawdę się dzieje.

Systemy SIEM ułatwiły zbieranie i korelowanie logów, jednak same w sobie nie rozwiązują problemu „szumu”. Analityk nadal spędza znaczną część czasu na filtrowaniu powiadomień, które finalnie okazują się fałszywymi alarmami. Pytanie brzmi: które zdarzenia faktycznie wymagają reakcji, a które można zignorować bez ryzyka?

Uczenie maszynowe pozwala przenieść część tej pracy na algorytmy. Modele analizują dane logów bezpieczeństwa w sposób zautomatyzowany, wyciągają wzorce normalnego zachowania i sygnalizują odstępstwa, które mogą oznaczać próbę ataku, nadużycie konta lub nienormalną aktywność wewnętrzną. Maszyna nie zastępuje analityka, ale filtruje dla niego strumień zdarzeń tak, aby uwaga człowieka skupiała się tam, gdzie jest faktycznie potrzebna.

Ograniczenia tradycyjnych systemów regułowych

Klasyczne systemy IDS/IPS i SIEM bazują głównie na regułach: sygnaturach znanych ataków, prostych korelacjach (np. kilkukrotne nieudane logowanie z jednego IP w krótkim czasie), zdefiniowanych progach czy listach blokowanych adresów. Mechanizmy te świetnie sprawdzają się w detekcji znanych wzorców, jednak gorzej radzą sobie z:

• atakami typu zero-day, które nie mają jeszcze sygnatur,
• atakami „niskimi i powolnymi”, rozłożonymi w czasie i maskowanymi wśród ruchu normalnego,
• nadużyciami wewnętrznymi, gdzie ruch nie odbiega drastycznie od standardowych schematów,
• nowymi kombinacjami technik (living-off-the-land, wykorzystanie narzędzi administracyjnych w nietypowy sposób).

Reguły mają też istotną wadę operacyjną: trzeba je tworzyć, aktualizować i utrzymywać. Gdy infrastruktura rośnie, a aplikacje zmieniają się dynamicznie, utrzymanie spójnego zestawu reguł staje się coraz trudniejsze. W praktyce wiele organizacji ma setki lub tysiące reguł, z których znaczna część jest przestarzała albo generuje zbyt wiele szumu.

Obietnica uczenia maszynowego: od sygnatur do wzorców zachowania

Uczenie maszynowe nie polega na zastąpieniu każdej reguły „czarną skrzynką”. Jego główna wartość w bezpieczeństwie IT to:

• automatyczne wykrywanie anomalii – identyfikacja zachowania odstającego od wyuczonej bazowej linii, nawet jeśli nie istnieje na nie gotowa reguła,
• priorytetyzacja zgłoszeń – nadawanie wyższego priorytetu zdarzeniom, które model ocenia jako bardziej podejrzane w oparciu o kontekst i historię,
• adaptacja do zmian – modele uwzględniają zmieniające się wzorce pracy (np. więcej pracy zdalnej, nowe aplikacje) bez ręcznego dopisywania setek reguł,
• redukcja fałszywych alarmów – ograniczenie powiadomień o zdarzeniach, które z perspektywy globalnego wzorca nie wyglądają groźnie.

W efekcie analitycy SOC mogą skoncentrować się na głębszej analizie incydentów, „polowaniu na zagrożenia” (threat hunting) i doskonaleniu procesów, zamiast ręcznie przeglądać setki alertów o niskiej wartości.

Co wiemy o normalnym ruchu, a czego nie wiemy o atakach?

W logach znacznie łatwiej opisać i zmodelować to, co normalne, niż to, co złe. Wiemy, jak na co dzień wygląda:

• aktywność typowego pracownika (godziny logowania, aplikacje, lokalizacje),
• zachowanie usług (średnie obciążenie, typowe błędy, rozkład ruchu w czasie),
• schematy ruchu sieciowego między segmentami.

O wiele trudniej jest z katalogiem ataków. Atakujący ciągle zmieniają techniki, mieszają je, korzystają z legalnych narzędzi. Z tego powodu w bezpieczeństwie IT dominują podejścia nienadzorowane i półnadzorowane: najpierw budowana jest bazowa linia „normalności”, a dopiero później na jej tle szukane są anomalie mogące oznaczać ataki. Tam, gdzie dostępne są dobre etykiety incydentów (np. w poczcie spam / nie-spam, złośliwe / niezłośliwe załączniki), stosuje się też klasyczne uczenie nadzorowane.

Jakie logi nadają się do wykrywania anomalii i ataków?

Kluczowe typy logów w kontekście detekcji

Źródeł logów jest wiele, ale nie wszystkie w równym stopniu nadają się do budowy modeli ML do detekcji ataków. W praktyce najczęściej wykorzystywane są:

• logi systemowe – syslog, Windows Event Log: próby logowania, eskalacja uprawnień, instalacja usług, zmiany w konfiguracji systemu,
• logi sieciowe – firewall, proxy, IDS/IPS: przepływy ruchu, zablokowane połączenia, podejrzane sygnatury w ruchu,
• logi aplikacyjne – serwery HTTP, aplikacje biznesowe, API gateways: błędy, nietypowe ścieżki URL, gwałtowne zmiany w liczbie żądań,
• logi bazodanowe – zapytania SQL, operacje na danych wrażliwych, masowe eksporty,
• logi chmurowe – np. AWS CloudTrail, Azure Activity Logs: tworzenie i modyfikacja zasobów, zmiany IAM, podejrzane działania konsoli administratora,
• logi uwierzytelniania i dostępu – AD, SSO, VPN, systemy IAM: logowania, reset haseł, tokeny, zmiany uprawnień.

Jakość detekcji zależy od tego, czy logi są spójne, kompletne oraz czy zawierają kontekst: informacje o użytkowniku, źródłowym IP, docelowym zasobie, statusie operacji, ewentualnych błędach. Surowe pakiety sieciowe niosą więcej szczegółów, ale są trudniejsze w obróbce. Zdarzenia wysokiego poziomu (np. „logowanie użytkownika X do aplikacji Y z IP Z”) są bardziej kompaktowe i łatwiejsze do modelowania.

Granularność i jakość danych: pakiety kontra zdarzenia

Na jednym końcu spektrum są surowe dane, takie jak pakiety sieciowe lub logi na poziomie protokołu (PCAP, NetFlow). Na drugim – zdarzenia wysokiego poziomu generowane przez systemy aplikacyjne i bezpieczeństwa. Różnice między nimi można uporządkować w prostej tabeli:

Dobór poziomu granularności wpływa na typ modeli i koszt ich utrzymania. Wiele organizacji zaczyna od logów na poziomie zdarzeń (np. logi uwierzytelniania, firewalli i serwerów WWW), bo są one stosunkowo łatwe do przetwarzania, a jednocześnie bogate w informacje przydatne w wykrywaniu anomalii w sieci i systemach.

Najbardziej przydatne źródła logów na start

Nie da się objąć uczeniem maszynowym wszystkich logów od razu. Zwykle sensowne jest rozpoczęcie od tych źródeł, które dobrze opisują dostęp do zasobów i ruch „na obrzeżach” organizacji:

• logi uwierzytelniania (AD, SSO, VPN) – idealne do wykrywania przejęcia kont, nietypowych lokalizacji logowania, prób brute force,
• logi firewalla i VPN – obraz tego, kto i skąd komunikuje się z infrastrukturą, jakie porty i protokoły są używane,
• logi serwerów HTTP / reverse proxy – ataki na aplikacje (SQLi, XSS), skanowania, nietypowe ścieżki i parametry zapytań,
• logi administracyjne z chmury – zmiany w konfiguracji bezpieczeństwa, tworzenie kluczy, modyfikacje uprawnień.

Te źródła są wystarczająco bogate, aby zbudować pierwsze modele wykrywania anomalii i ataków, a jednocześnie nie wymagają jeszcze bardzo skomplikowanej infrastruktury do przetwarzania miliardów wydarzeń dziennie.

Realistyczny przykład: próba brute force w logach VPN

Wyobraźmy sobie analityka SOC, który monitoruje logi serwera VPN. Pojedynczy wpis może wyglądać jak:

2026-05-11 10:15:23, user=j.nowak, src_ip=203.0.113.5, status=FAILED_AUTH, reason=wrong_password

Jeden taki wpis zwykle nie jest alarmujący. Ktoś mógł wpisać błędne hasło. Natomiast seria:

• 50 nieudanych logowań dla różnych użytkowników z tego samego IP w ciągu 10 minut,
• próby logowania do kont, które zwykle nie logują się z Internetu,
• nietypowa pora dnia dla danej organizacji,
• pojawienie się nowego kraju, z którego nigdy wcześniej nie było połączeń VPN,

składa się na obraz prawdopodobnej próby brute force. Uczenie maszynowe pomaga tu w kilku aspektach: zlicza zdarzenia w odpowiednich oknach czasowych, porównuje je z historycznymi wzorcami dla danego użytkownika lub IP, ocenia rzadkość takiego zachowania. Model może podnieść alarm wcześniej i dokładniej określić, czy sytuacja jest nietypowa, bez konieczności ręcznego przeglądania tysięcy wpisów.

Podstawy uczenia maszynowego w kontekście bezpieczeństwa

Uczenie nadzorowane, nienadzorowane i półnadzorowane

Uczenie maszynowe w bezpieczeństwie IT działa w nieco innym kontekście niż np. w marketingu czy rekomendacjach produktów. Kluczowy jest podział na trzy główne paradygmaty:

• uczenie nadzorowane – model uczy się na danych wejściowych (cechach) oraz etykietach, które mówią, czy dane zdarzenie było atakiem, czy nie. Przykład: klasyfikacja ruchu sieciowego na „złośliwy” i „normalny” tam, gdzie mamy oznaczone próbki,
• uczenie nienadzorowane – model ma tylko dane wejściowe, bez etykiet. Jego celem jest znalezienie struktur, klastrów lub odchyleń. Typowy przykład to wykrywanie anomalii w logach uwierzytelniania, gdzie nie wiemy dokładnie, które zdarzenia są złe,
• uczenie półnadzorowane – model ma mieszankę niewielkiej liczby oznaczonych przykładów i dużej liczby nieoznaczonych. Przykład: kilka potwierdzonych incydentów bezpieczeństwa w logach VPN oraz ogromna ilość nieopisanych zdarzeń, które można wykorzystać do uczenia bazowej linii.

W praktyce bezpieczeństwa IT dominuje uczenie nienadzorowane i półnadzorowane. Z etykietami jest problem: wiele incydentów pozostaje niewykrytych lub nie jest poprawnie oznaczonych w systemach ticketowych, a ataki ewoluują. Tam, gdzie da się zebrać wystarczająco dużo wiarygodnych etykiet (np. malware / clean, phishing / legit), z powodzeniem stosuje się modele nadzorowane.

Anomalia, outlier, rzadkie klasy – o czym właściwie mowa?

W dyskusji o wykrywaniu ataków w logach często przewijają się terminy: anomalia, outlier, zdarzenie rzadkie. Wspólnym mianownikiem jest tu odstępstwo od dominującego wzorca. Różnice są jednak istotne:

• anomalia – zdarzenie lub sekwencja zdarzeń, które znacząco różnią się od normalnego zachowania, często w wielu wymiarach jednocześnie,
• outlier – pojedynczy punkt danych, który leży „daleko” od reszty w przestrzeni cech (np. IP z tysiącami prób logowania, gdy typowa liczba to kilkanaście),
• rzadka klasa – formalny problem klasyfikacji, gdy jedna z klas (np. „atak”) występuje bardzo rzadko w porównaniu z drugą („normalny ruch”).

Imbalans klas i „brudne” etykiety w praktyce SOC

Modele bezpieczeństwa uczą się na danych, które od początku są „skrzywione”. Zdarzenia normalne dominują, a incydenty stanowią ułamek promila wszystkich wpisów w logach. Do tego dochodzą błędy w oznaczaniu zdarzeń – część incydentów nie trafia do systemów ticketowych, inne są zamykane z błędną klasyfikacją („false positive”, choć później okazuje się, że coś jednak się stało).

Co wiemy? Dane pozytywne (ataki) są rzadkie i często niepełne. Czego nie wiemy? Ile ataków w ogóle nie zostało zauważonych. To przekłada się na konkretne problemy dla uczenia maszynowego:

• modele nadzorowane łatwo „uczą się” klasy normalne i ignorują klasę atak,
• jakość etykiet jest nierówna w czasie – zmiana procedur w SOC wpływa na sposób oznaczania incydentów,
• część danych jest fałszywie pozytywna (np. testy penetracyjne, skany wewnętrzne), ale nie jest jasno opisana w logach.

Praktycznym kompromisem jest łączenie różnych technik: uczenia nienadzorowanego do wykrywania nowych wzorców oraz nadzorowanego tam, gdzie incydenty są dobrze opisane (np. malware, phishing na podstawie sandboxów lub systemów antyspamowych). W wielu zespołach SOC powstają też podręczne „zestawy etalonowe” – małe, ale dobrze zweryfikowane zbiory incydentów używane do okresowego testowania modeli.

Ryzyko nadmiernego dopasowania do „dziwnej normalności”

Środowiska IT bywają chaotyczne: testy, migracje, awarie. Dla człowieka oczywiste jest, że wieczorny deployment aplikacji przejściowo podnosi poziom błędów 500 w logach HTTP. Model widzi jedynie nagły skok pewnych cech i po kilku powtórzeniach zaczyna traktować to jako „nową normalność”.

W efekcie istnieje ryzyko, że rzeczywista anomalia, która przypadkiem zbiegnie się w czasie z takim oknem serwisowym, zostanie „wygładzona” i nie oznaczona jako podejrzana. Z drugiej strony, ignorowanie tych okresów powoduje wysyp fałszywych alarmów. Rozwiązaniem jest wprowadzanie do cech dodatkowego kontekstu:

• oznaczenie okien planowanych prac (change windows),
• flagi typu „tryb awaryjny”, „degradacja usług”,
• korelacja z danymi z systemów zarządzania zmianą lub ITSM.

Takie metadane pomagają modelom poprawnie rozróżnić, czy nagła zmiana jest efektem planowanego działania, czy potencjalnego ataku ukrytego pod przykrywką chaosu operacyjnego.

Wyzwania danych w logach: od surowego tekstu do struktury

Niespójne formaty i zmiany wersji

Logi bezpieczeństwa rzadko są w pełni znormalizowane. Nawet w ramach jednego produktu zmieniają się wersje, a z nimi format wpisów. Pojawiają się nowe pola, inne znikają, zmieniają się kody błędów, kolejność elementów. Dla człowieka to uciążliwość, dla modelu – poważne zaburzenie danych.

Typowe problemy przy parsowaniu logów do postaci strukturalnej:

• ten sam typ zdarzenia opisany różnymi polami w zależności od wersji agenta lub systemu,
• specjalne znaki w polach tekstowych (np. w nazwach użytkowników, ścieżkach URL), które psują prosty parser regex,
• różne strefy czasowe i formaty dat w jednym strumieniu danych.

Dlatego w dojrzałych środowiskach powstaje warstwa pośrednia: schemat zdarzeń bezpieczeństwa (np. w stylu ECS, CIM lub własny), do którego mapowane są wszystkie źródła logów. Ten krok bywa bardziej pracochłonny niż samo budowanie modelu, ale bez niego porządne uczenie maszynowe na logach jest trudne.

Problemy jakościowe: duplikaty, brakujące pola, szum

Łączenie logów z wielu systemów szybko ujawnia klasyczne problemy jakościowe:

• duplikaty – to samo zdarzenie raportowane wielokrotnie (np. przez agenta lokalnego i centralny system),
• brakujące pola – brak src_ip w części zdarzeń z powodu błędu konfiguracji lub aktualizacji,
• szum – ogromna liczba wpisów o małej wartości dla bezpieczeństwa (np. rutynowe heartbeat, health checki).

Modele uczone na takich danych mają tendencję do:

• fałszywego zawyżania częstotliwości niektórych wzorców (przez duplikaty),
• błędnego wnioskowania o anomaliach w polach, które okresowo znikają,
• ignorowania rzadkich, ale ważnych typów zdarzeń, jeśli giną w potoku heartbeatów.

Stąd duży nacisk na wstępne odszumianie: odfiltrowanie zdarzeń technicznych, identyfikowanie i scalanie duplikatów (np. po hashu treści + czasie), a także monitorowanie kompletności pól w czasie. Statystyki braków same w sobie bywają sygnałem – nagły spadek liczby logów z krytycznego systemu może być objawem awarii albo celowej manipulacji.

Normalizacja i wzbogacanie kontekstem

Surowe logi często zawierają jedynie minimalną informację: nazwę użytkownika, adres IP, kod operacji. W izolacji taki wpis ma ograniczoną wartość. Dopiero powiązanie go z dodatkowymi źródłami nadaje sens:

• katalog użytkowników (AD, IAM) – rola, dział, status konta,
• baza zasobów (CMDB, inventory) – typ urządzenia, lokalizacja, krytyczność systemu,
• geolokalizacja IP – kraj, miasto, ASN, typ łącza (np. hosting, VPN komercyjny).

W praktyce oznacza to, że każdemu zdarzeniu logowemu dodawane są nowe, wyliczone pola: user_department, asset_criticality, src_ip_risk_score. To właśnie te pola często stają się głównymi cechami wejściowymi dla modeli. Zamiast pracować bezpośrednio na surowym IP, model widzi informację w stylu „adres z popularnej sieci VPN, wysoka zmienność adresów, kraj nowy dla tego użytkownika”.

Jak projektować cechy (feature engineering) z logów bezpieczeństwa?

Cechy bazowe: kto, co, skąd, dokąd, kiedy

Pierwsza warstwa cech wynika bezpośrednio z pól logów – to twardy szkielet reprezentacji zdarzeń. W większości przypadków da się z nich wyprowadzić:

• tożsamość – użytkownik, konto serwisowe, rola, grupa,
• źródło – adres IP, urządzenie, kraj, ASN,
• cel – zasób, aplikacja, port, ścieżka URL, typ operacji (read/write/admin),
• czas – dokładna godzina, dzień tygodnia, relacja do typowego grafiku pracy.

Najprostsze cechy to bezpośrednie wykorzystanie tych pól (np. one-hot encoding typów zdarzeń, zhashowane identyfikatory użytkowników). Już na tym etapie widać, że samo dobranie reprezentacji – np. czy porty trzymać jako liczby, czy zgrupować je w kategorie (well-known, ephemeral, niestandardowe) – ma znaczenie dla jakości modelu.

Cechy agregowane w oknach czasowych

Większość ataków nie polega na pojedynczym, izolowanym zdarzeniu, lecz na wzorcu rozciągniętym w czasie. Dlatego kluczowe są cechy zbudowane jako agregaty:

• liczba nieudanych logowań dla użytkownika w ostatnich 5/15/60 minutach,
• liczba różnych krajów, z których logował się użytkownik w ciągu doby,
• łączna liczba żądań HTTP z jednego IP w danym przedziale,
• liczba modyfikacji reguł firewalla w ciągu godziny na jednym urządzeniu.

Takie cechy wymagają systemu streamingu lub hurtowni zdarzeń, która potrafi wykonywać obliczenia w oknach czasowych (tumbling, sliding windows). Z punktu widzenia modelu istotne jest, że pojedynczy wpis w logu zostaje zamieniony na wektor liczb opisujących lokalny „kontekst czasowy”. To właśnie te agregaty często mocno odróżniają zachowania typowe od masowych skanowań czy automatów brute force.

Cechy historyczne i profilowanie zachowań

Kolejna warstwa to cechy oparte na profilu użytkownika, urządzenia lub aplikacji – nie tylko na tym, co wydarzyło się w ostatnich minutach, ale jak typowo wygląda zachowanie w dłuższej perspektywie. Przykładowe cechy:

• średnia liczba logowań dziennie dla użytkownika w ostatnim miesiącu,
• typowy zakres godzin aktywności (np. 8–18 czasu lokalnego),
• typowe kraje/miasta, z których łączy się użytkownik,
• typowy wolumen zapytań do danej aplikacji z konkretnego serwera.

W praktyce buduje się proste modele statystyczne „normy” per byt: użytkownik, konto serwisowe, IP, host. Odchylenie od tej normy (np. logowanie o 3 w nocy z innego kontynentu) staje się cechą wejściową dla głównego modelu anomalii, a niekoniecznie od razu alarmem samym w sobie.

Cechy sekwencyjne: kolejność zdarzeń ma znaczenie

Logi są naturalnie sekwencją. Sama informacja, że konto wykonało 10 operacji administracyjnych, niewiele mówi, jeśli nie wiemy w jakiej kolejności i w jakim odstępie czasu. Przykład z praktyki:

• sekcja normalna: logowanie → podwyższenie uprawnień → zmiana konfiguracji → wylogowanie,
• sekcja podejrzana: logowanie → masowe odczyty danych → zmiana reguł logowania → wyłączenie audytu.

Modele sekwencyjne (LSTM, GRU, Transformers) potrzebują jednak odpowiedniej reprezentacji wejścia. Z logów buduje się więc:

• tokeny zdarzeń (np. LOGIN_SUCCESS, PRIV_ESC, RULE_CHANGE),
• cechy czasu między kolejnymi zdarzeniami,
• oznaczenia sesji (grupowanie zdarzeń w spójne transakcje lub sesje użytkownika).

Tak przygotowane sekwencje można następnie porównywać z typowymi „ścieżkami” zachowań i szukać odchyleń, które nie są widoczne na poziomie pojedynczych wpisów.

Reprezentacja pól tekstowych i półstrukturalnych

W logach bezpieczeństwa sporo istotnych informacji kryje się w polach tekstowych: komunikaty błędów, ścieżki URL, nazwy procesów, argumenty linii komend, treści zapytań SQL. Proste podejścia, takie jak tokenizacja po spacji, dają ograniczony efekt. Stosuje się więc kilka praktycznych technik:

• parsowanie specyficzne dla domeny – np. wydzielenie nazwy polecenia, ścieżek plików, domen z ciągu komend,
• hashowanie tokenów (feature hashing) – zamiana rzadkich słów na stałowymiarowy wektor liczbowy,
• embeddings – wektory osadzeń słów lub całych fraz, uczone na dużych korpusach logów.

Coraz częściej wykorzystuje się też modele językowe specjalizowane do logów (np. trenowane na danych z systemów Linux/Windows, serwerów HTTP), aby reprezentacja tekstu uwzględniała relacje między typowymi elementami (nazwy plików, opcji, parametrów). Dla wykrywania ataków aplikacyjnych przydają się także cechy specyficzne: obecność znaków typowych dla SQLi lub XSS, długość parametru, liczba różnych parametrów w jednym żądaniu.

Feature engineering pod ograniczenia operacyjne

Nie każda teoretycznie dobra cecha nadaje się do systemu działającego w czasie rzeczywistym. Część agregatów wymaga długich okien, duża liczba skomplikowanych cech zwiększa opóźnienia przetwarzania, a obliczanie embeddingów tekstowych „w locie” bywa kosztowne. W praktyce trzeba balansować:

• które cechy można policzyć w streamingu, a które tylko w batchu,
• które agregaty są krytyczne dla jakości modelu, a które można uprościć,
• jak ograniczyć liczbę cech przy zachowaniu sensownej skuteczności (selekcja cech, PCA itp.).

Rozbudowane cechy sekwencyjne i tekstowe często trafiają do modeli działających asynchronicznie (np. analizy nocne), natomiast modele online opierają się na mniejszym, dobrze dobranym zestawie cech numerycznych i kategorycznych.

Przegląd typów modeli stosowanych do wykrywania anomalii i ataków w logach

Modele statystyczne i proste reguły progowe

Zanim pojawią się bardziej zaawansowane techniki, w wielu organizacjach działają klasyczne metody statystyczne. Proste liczniki i progi nadal są podstawą:

• reguły typu „więcej niż N nieudanych logowań w X minut”,
• detekcja odchyleń od średniej i odchylenia standardowego (np. 3-sigma),
• poziomy bazowe (baselines) per użytkownik lub urządzenie.

Klasyczne uczenie nadzorowane

Gdy dostępne są dobrze opisane incydenty, w grę wchodzą klasyczne modele nadzorowane. Z perspektywy bezpieczeństwa kluczowe jest nie tyle maksymalizowanie ogólnej dokładności, ile sensowne zarządzanie fałszywymi alarmami i przeoczeniami. W praktyce stosuje się:

• drzewa decyzyjne i lasy losowe – dobrze radzą sobie z mieszanką cech kategorycznych i numerycznych, pozwalają też tłumaczyć decyzje (które cechy przeważyły),
• gradient boosting (XGBoost, LightGBM) – często osiąga najlepsze wyniki przy rozsądnych kosztach obliczeń,
• modele liniowe (logistic regression) – przy odpowiednim doborze cech bywają wystarczające, a są szybkie i stabilne.

Problemem jest zwykle rozkład klas: „normalne” zdarzenia liczone są w milionach, oznaczonych ataków – w dziesiątkach czy setkach. Stosuje się więc techniki radzenia sobie z niezbalansowanymi danymi:

• ważenie klas (większa kara za pomylenie ataku z normalnym ruchem),
• dobór metryk (precision, recall, F1, ROC/PR), zamiast samej dokładności,
• selektywny oversampling lub generowanie syntetycznych przykładów (np. SMOTE).

Pytanie kontrolne: co wiemy? – że taki model dobrze rozpoznaje znane scenariusze ataków, przy których mieliśmy dane treningowe. Czego nie wiemy? – jak zachowa się wobec nowej techniki, której w danych historycznych po prostu nie było. To miejsce, gdzie potrzebne są metody nienadzorowane i hybrydowe.

Uczenie nienadzorowane i semi-nadzorowane do anomalii

Większość logów nie ma etykiet. Incydenty są nieliczne, a ich opis – niekompletny. Z tego powodu dużą rolę odgrywają modele nienadzorowane, których zadaniem jest raczej wskazywanie „odstających” wzorców niż bezpośrednie przypisywanie łatki „atak”. Wykorzystywane są m.in.:

• klastrowanie (k-means, DBSCAN, HDBSCAN) – grupowanie podobnych zachowań i szukanie małych, nietypowych klastrów,
• metody oparte na gęstości (Local Outlier Factor, Isolation Forest) – każde zdarzenie lub sesja dostaje wynik „odstającości”,
• modele one-class (One-Class SVM, autoenkodery) – uczone wyłącznie na danych uznanych za normalne, uczą się „obszaru normalności”.

W trybie semi-nadzorowanym etykietuje się niewielki, krytyczny wycinek danych (np. potwierdzone incydenty), a resztę traktuje jako niepewną. Modele potrafią wtedy dociągać granice decyzyjne tak, aby zachować wysoki poziom ostrożności przy małej liczbie znanych przykładów zagrożeń.

Modele sekwencyjne do analizy ciągów zdarzeń

Gdy w centrum jest sekwencja działań – np. kolejne komendy na serwerze, kroki w aplikacji, przejścia między systemami – stosuje się modele sekwencyjne. W praktyce używane są:

• HMM i profile Markowa – starsze, ale nadal przydatne do prostych łańcuchów zdarzeń,
• sieci rekurencyjne (LSTM, GRU) – uczą się typowych ciągów operacji i wykrywają odstępstwa,
• Transformers – lepiej skalują się do dłuższych sekwencji, zwłaszcza gdy istotne są odległe zależności.

Często celem jest predykcja następnego zdarzenia albo rekonstrukcja całej sekwencji. Jeśli model ma problem z odtworzeniem konkretnej sesji (wysoki błąd rekonstrukcji), zostaje ona oznaczona jako anomalia. To dobrze sprawdza się np. w logach poleceń administracyjnych – typowe sekwencje są powtarzalne, a nietypowe „skoki” wyróżniają się w modelu.

Autoenkodery i modele rekonstrukcyjne

Autoenkodery to sieci neuronowe uczone do odtwarzania własnego wejścia. Wykorzystuje się je tam, gdzie mamy dużo danych uznawanych za normalne, a mało przykładów anomalii. Schemat jest prosty:

1. trenowanie na dużym zbiorze logów z okresu bez znanych incydentów,
2. kompresja logów do wektora (warstwa ukryta) i rekonstrukcja,
3. podczas działania – mierzenie błędu rekonstrukcji dla nowych zdarzeń lub sekwencji.

Wysoki błąd rekonstrukcji oznacza, że dany wzorzec odbiega od tego, czego model „nauczył się” jako typowe. Takie podejście bywa stosowane w systemach IDS/IPS opartych na zachowaniu, a także w monitoringu logów aplikacyjnych, gdzie struktura żądań HTTP jest względnie przewidywalna.

Modele oparte na grafach i powiązaniach

Ataki rzadko odbywają się w izolacji. Typowo obejmują wiele kont, hostów, aplikacji. Logi można więc traktować jako źródło krawędzi w grafie zdarzeń:

• węzłami są użytkownicy, urządzenia, adresy IP, aplikacje,
• krawędziami – logowania, połączenia sieciowe, wywołania API.

Na takim grafie można:

• analizować ścieżki ataku (pivotowanie między hostami, lateral movement),
• wykrywać nietypowe połączenia (użytkownik łączący się z serwerem, z którym nigdy nie miał relacji),
• stosować graph neural networks do wykrywania anomalii strukturalnych.

To podejście rośnie na znaczeniu w dużych środowiskach korporacyjnych i w infrastrukturze chmurowej, gdzie powiązań jest zbyt wiele, by człowiek był w stanie je ręcznie prześledzić.

Modele hybrydowe: reguły + ML + kontekst

W większości realnych wdrożeń nie ma jednego „modelu idealnego”. Stosuje się układ warstwowy:

• reguły i progi do prostych, dobrze znanych scenariuszy (np. lockout po serii nieudanych logowań),
• modele anomalii do wychwytywania nieznanych wzorców w tle,
• modele nadzorowane do klasyfikacji typów incydentów, tam gdzie jest wystarczająco dużo etykiet.

Dodatkowo wprowadza się warstwę łączenia sygnałów (tzw. fusion): wynik z kilku niezależnych modeli, wzbogacony o kontekst biznesowy (krytyczność systemu, pora dnia, rola użytkownika), daje końcowy score ryzyka. Pozwala to uniknąć sytuacji, w której pojedynczy słaby sygnał generuje nieproporcjonalnie duży alarm.

Dobór modeli do przypadków użycia

Wybór modelu zależy nie tylko od danych, ale i od charakteru zagrożeń oraz wymagań operacyjnych. Kilka częstych scenariuszy:

• brute force, skanowania, proste nadużycia – liczniki, progi, ewentualnie lekkie modele nadzorowane,
• wyciek danych i nadużycia kont uprzywilejowanych – modele sekwencyjne i profilowanie użytkowników,
• ataki aplikacyjne (SQLi, XSS) – kombinacja cech tekstowych, embeddings oraz klasyfikatorów nadzorowanych,
• ruch boczny w sieci – modele grafowe i analiza anomalii w połączeniach między hostami.

Dobrym sprawdzianem jest pytanie: czy bardziej boimy się przegapić rzadki atak, czy zatopić SOC w alertach? Odpowiedź powinna prowadzić do świadomego ustawienia progu czułości i doboru metryk, a w konsekwencji – do konkretnego typu modelu.

Trenowanie i walidacja w realiach logów

Logi mają charakter strumieniowy i zmienny. Klasyczne podejście „dzielimy dane na train/validation/test” trzeba dostosować:

• podział czasowy – model trenuje się na starszym okresie, a testuje na nowszym, aby uniknąć przecieku informacji z przyszłości,
• walidacja na incydentach znanych – nawet jeśli jest ich mało, służą jako kotwica do oceny,
• symulacje „co by było, gdyby” – odtwarzanie znanych ataków na historycznych logach z włączonym nowym modelem.

Wiele zespołów buduje też osobne zbiory walidacyjne z okresów zmian w infrastrukturze (migracje, nowe systemy). Chodzi o sprawdzenie, czy model nie wariuje przy skokowej zmianie wzorców logowania, która nie ma nic wspólnego z atakiem.

Koncept drift i starzenie się modeli

Środowisko IT zmienia się niemal ciągle: nowe aplikacje, zmiana trybu pracy (np. masowy home office), inne wzorce ruchu sieciowego. To prowadzi do concept drift – powolnej zmiany rozkładu danych i znaczenia cech. Objawy:

• stopniowy wzrost liczby fałszywych alarmów bez widocznej przyczyny,
• spadek skuteczności detekcji znanych typów incydentów,
• pojawianie się nowych, stabilnych „anomalii”, które w praktyce stają się normą.

Radzenie sobie z drift wymaga:

• monitorowania metryk modeli w czasie (nie tylko ROC, ale też liczba alertów per typ),
• regularnego retrainingu z kontrolą zmian (A/B testy modeli),
• w niektórych przypadkach – modeli uczących się ciągle (online learning) z mechanizmami zabezpieczającymi przed „nauczaniem się ataku”.

W praktyce część organizacji utrzymuje równolegle „stary” i „nowy” model, porównując ich zachowanie na tej samej próbce danych z ostatnich tygodni, zanim nastąpi pełne przełączenie.

Integracja modeli z SOC i narzędziami bezpieczeństwa

Nawet najlepszy model staje się problemem, jeśli generuje tysiące surowych alertów bez sensownej prezentacji. Kluczowe jest wpięcie go w istniejący ekosystem:

• SIEM – model może publikować wyniki jako dodatkowe pola (np. ml_risk_score, anomaly_type), które następnie są używane w regułach korelacyjnych,
• SOAR – część reakcji (blokada IP, wymuszenie resetu hasła) bywa automatyzowana przy wysokich wartościach score’u,
• dashbordy dla analityków – wizualizacja trendów, ranking najbardziej anomalicznych kont/hostów.

Ważne jest także wzbogacanie alertów o kontekst, który ułatwia pracę analitykowi: krótkie wyjaśnienie, które cechy najmocniej wpłynęły na wynik, odwołanie do historycznego profilu użytkownika, link do podobnych incydentów z przeszłości. Bez tego model bywa postrzegany jako „czarna skrzynka”, której trudno zaufać.

Explainable AI (XAI) w bezpieczeństwie

Modele złożone – zwłaszcza deep learning – mają opinię mało interpretowalnych. W bezpieczeństwie to szczególnie niewygodne, bo analityk musi często uzasadnić swoje działania. Stosowane są więc techniki XAI:

• ważność cech (feature importance) dla drzew i modeli boostingowych,
• LIME, SHAP – lokalne wyjaśnienia, które pokazują, jak dana cecha podniosła lub obniżyła score,
• reguły wyjaśniające – automatycznie generowane opisy typu „nietypowy kraj logowania + wysoka liczba nieudanych logowań w krótkim czasie”.

Tego typu wyjaśnienia nie są jedynie „miłym dodatkiem”. Często decydują, czy SOC realnie korzysta z modeli, czy odkłada je na bok jako zbyt nieprzejrzyste.

Redukcja fałszywych alarmów

Jednym z głównych zarzutów wobec systemów anomalii jest nadprodukcja alertów. Źródła problemu są różne: zbyt agresywne progi, brak kontekstu biznesowego, drift danych. Kilka praktycznych metod redukcji szumu:

• agregacja alertów – grupowanie podobnych zgłoszeń (np. ta sama kombinacja użytkownik–IP–aplikacja) w jeden incydent,
• połączenie z danymi o zmianach – np. informacja, że w tym dniu nastąpił rollout nowej wersji aplikacji,
• feedback od analityków – oznaczanie „fałszywych pozytywów” i wykorzystanie tych etykiet do korekty progów lub retrainingu.

Nie chodzi o całkowitą eliminację fałszywych alarmów, lecz o doprowadzenie do poziomu, w którym zespół jest w stanie je obsłużyć bez wypalenia.

Feedback loop: jak uczenie maszynowe korzysta z pracy SOC

SOC nie jest tylko odbiorcą wyników modelu. To źródło niezwykle cennych danych zwrotnych. Dwa mechanizmy są tu kluczowe:

• etykietowanie incydentów – każde potwierdzenie lub odrzucenie alertu może trafić z powrotem do hurtowni jako etykieta dla kolejnych iteracji modelu,

Najważniejsze wnioski

• Skala logów znacząco przerasta możliwości analityków SOC – miliony wpisów dziennie powodują, że bez automatyzacji większość zdarzeń pozostaje w praktyce nieprzeanalizowana.
• Tradycyjne systemy regułowe (IDS/IPS, SIEM) dobrze wykrywają znane wzorce ataków, ale mają problemy z atakami zero-day, „niskimi i powolnymi” kampaniami oraz nadużyciami wewnętrznymi maskowanymi jako normalny ruch.
• Uczenie maszynowe przenosi nacisk z sygnatur na wzorce zachowania: modele budują obraz „normalności” i wychwytują odstępstwa, co pozwala wykrywać także nowe, nietypowe scenariusze ataków.
• Algorytmy ML pomagają filtrować szum alertów, priorytetyzować zgłoszenia i redukować fałszywe alarmy, dzięki czemu analitycy mogą skupić się na realnych incydentach i proaktywnym „threat huntingu”.
• W bezpieczeństwie IT dominują podejścia nienadzorowane i półnadzorowane, bo stosunkowo łatwo zdefiniować zachowanie normalne, natomiast katalog możliwych ataków jest niepełny i dynamicznie się zmienia.
• Największą wartość dla detekcji anomalii mają spójne, kontekstowe logi systemowe, sieciowe, aplikacyjne, bazodanowe, chmurowe oraz uwierzytelniania, które opisują kto, z jakiego źródła, do jakiego zasobu i z jakim skutkiem wykonuje operacje.