ML IDS z Suricata: uczenie modeli dla cyberbezpieczeństwa

ML IDS nowej generacji: Jak Suricata szkoli modele do skutecznego wykrywania intruzji

Współczesne systemy wykrywania intruzji (IDS) mierzą się z wyzwaniem identyfikacji nowych i zmodyfikowanych cyberataków, polegając na analizie sygnatur. Rozwój uczenia maszynowego (ML) oferuje obiecujące rozwiązanie, jednak wdrożenie ML IDS w rzeczywistych sieciach wiąże się z trudnościami, zwłaszcza w zakresie tworzenia etykietowanych danych. Niniejszy artykuł bada innowacyjne podejście do budowy ML IDS, wykorzystując dane o zdarzeniach bezpieczeństwa rejestrowane przez Suricatę do szkolenia modeli i zwiększania skuteczności ochrony.

Ewolucja systemów wykrywania intruzji: od sygnatur do inteligencji

W arsenale środków ochrony informacji przed atakami komputerowymi znajdują się zapory sieciowe (firewalle), systemy wykrywania intruzji (IDS) na poziomie sieci i hosta, systemy NGFW oraz SIEM. Pomimo ich różnorodności, większość z nich opiera się na analizie sygnatur, która skutecznie identyfikuje znane zagrożenia, ale jest bezsilna wobec nowych lub zmodyfikowanych ataków. Ta fundamentalna słabość podkreśla znaczenie rozwoju ML IDS, zdolnych do heurystycznego lub inteligentnego wykrywania.

Zadanie budowy ML IDS na poziomie sieci formułuje się na dwa główne sposoby:

• Klasyfikacja ruchu sieciowego: Podział ruchu na „czysty” i „atak” (ewentualnie z podklasami ataków). Wymaga to etykietowanego zbioru danych (datasetu), co w rzeczywistych warunkach jest trudne ze względu na ograniczenia etyczne, infrastrukturalne i metodologiczne. Tworzenie precyzyjnych modeli chronionych zasobów lub zbieranie danych o atakach bez uszczerbku dla rzeczywistej infrastruktury stanowi poważne wyzwanie.
• Wykrywanie anomalii: Identyfikacja anomalnych połączeń sieciowych lub pakietów, gdy znany jest tylko „czysty” ruch. To podejście jest mniej wymagające pod względem etykietowanych danych, ale może generować wyższy odsetek fałszywych alarmów.

Istniejące badania często wykazują wysoką dokładność ML IDS na stanowiskach laboratoryjnych, gdzie modele są szkolone i testowane w kontrolowanym środowisku. Jednakże, przeniesienie tych modeli do rzeczywistych sieci skutkuje znacznym spadkiem wydajności. Wynika to z faktu, że wektory cech używane do szkolenia często silnie zależą od fizycznej struktury sieci, konfiguracji sprzętu i specyfiki usług sieciowych, w których zbierano dane. Różnice w tych parametrach między środowiskiem testowym a produkcyjnym prowadzą do błędów klasyfikacji i obniżenia ogólnej dokładności modelu.

Hipoteza i metodologia: Suricata jako źródło wiedzy

Mając świadomość tych ograniczeń, autorzy artykułu postawili sobie za cel zbadanie, czy możliwe jest zbudowanie efektywnego ML IDS w już eksploatowanej sieci, wykorzystując dane, które nie wymagają celowych ataków na zasoby. Główna hipoteza zakłada możliwość wykorzystania zdarzeń bezpieczeństwa, rejestrowanych przez klasyczne systemy wykrywania intruzji, takie jak Suricata, do etykietowania zbiorów danych. Takie podejście pozwala ominąć problemy związane z tworzeniem etykietowanych danych i potencjalnie zwiększyć adaptacyjność ML IDS do rzeczywistych warunków.

W celu weryfikacji tej hipotezy opracowano własne narzędzie session_analyzer. Narzędzie to służy do obliczania wartości wektorów cech ruchu sieciowego dla każdego połączenia sieciowego. Warto zaznaczyć, że session_analyzer jest analogiem popularnego narzędzia CICFlowMeter (wcześniej NTLFlowLyzer), ale zostało zaadaptowane do specyficznych zadań badawczych. Początkowo jest ono zorientowane na protokół TCP, jednak jego architektura pozwala na rozszerzenie analizy na inne protokoły.

Zasady tworzenia wektorów cech w session_analyzer

session_analyzer stosuje rygorystyczne zasady analizy ruchu sieciowego i ekstrakcji z niego istotnych cech, które następnie są wykorzystywane do szkolenia modeli uczenia maszynowego. Zasady te zapewniają spójność i trafność generowanych danych.

• Filtrowanie protokołów: Analizie podlegają wyłącznie pakiety protokołów Ethernet II, MPLS, VLAN, IPv4, TCP, UDP, ICMPv4. Wszystkie pozostałe protokoły warstwy łącza danych, sieciowej i transportowej są ignorowane.
• Identyfikacja sesji sieciowej (Flow ID): Każda sesja jest unikalnie identyfikowana za pomocą 5-elementowej sekwencji (5-Tuple): Destination IP - Source IP - Destination Port - Source Port - Proto.
• Definicja sesji sieciowej: Sesja jest definiowana jako sekwencja pakietów należących do jednego połączenia TCP, strumienia UDP lub strumienia ICMP. Przynależność pakietu do sesji jest ustalana na podstawie zgodności informacji adresowej 5-Tuple (kierunek prosty lub odwrotny).
• Kryterium rozpoczęcia sesji TCP: Sesja TCP jest rejestrowana tylko przy pierwszym pakiecie z flagami SYN=1 i ACK=0. Pakiet ten określa również kierunek transmisji danych (klient-serwer).
• Kryterium rozpoczęcia sesji UDP/ICMP: Rejestrowane jest przy pojawieniu się pierwszego pakietu z nowym identyfikatorem. Istnieje możliwość błędu w określeniu kierunku, np. przy pierwszej zaobserwowanej odpowiedzi DNS.
• Kryterium zakończenia sesji sieciowej (timeout): Dla wszystkich typów sesji przewidziano limit czasu (timeout) od ostatniego odebranego pakietu. Domyślne wartości konfigurowalne: tcp_session_timeout = 60000 ms, udp_session_timeout = 60000 ms, icmp_session_timeout = 60000 ms.
• Kryterium zakończenia sesji TCP (flagi rozłączenia): Dodatkowo monitorowane są pakiety RST lub FIN. Po otrzymaniu RST sesja jest uznawana za zamkniętą. W przypadku FIN uruchamiany jest mechanizm śledzenia potwierdzeń (ACK) z obu stron.
• Strumień pakietów sieciowych (Flow): Ścisła sekwencja pakietów w ramach jednej sesji, bez uwzględnienia kierunku.
• Strumień pakietów w kierunku Forward (Fwd): Ścisła sekwencja pakietów od klienta do serwera w ramach sesji.
• Strumień pakietów w kierunku Backward (Bwd): Ścisła sekwencja pakietów od serwera do klienta w ramach sesji.
• Czas trwania sesji sieciowej: Może być obliczany na dwa sposoby: od pierwszego do ostatniego pakietu w sesji, lub od pierwszego do ostatniego pakietu z użytecznymi danymi (payload > 0). Parametr is_need_calc_duration_by_last_payload kontroluje ten proces.
• Strumień sesji sieciowych (Stream): Zbiór sesji między jednym Source IP a określoną usługą sieciową (Destination IP | Destination Port | Proto). Identyfikator stream_id jest tworzony przez konkatenację tych czterech komponentów. Cechy z prefiksem "Stream" charakteryzują sesje równoległe, ich czas powstania i interwały między nimi.
• "Niezależne" sesje w strumieniu: Sesje są uznawane za niezależne, jeśli czas między ich utworzeniem przekracza session_simple_timeout (domyślnie 60000000 mikrosekund).
• Interwały czasowe między sesjami w strumieniu:

* session_time_prev_absent: Interwał między bieżącą a poprzednią sesją. Jeśli bieżąca sesja jest pierwsza lub interwał przekracza próg, ustawiana jest wartość session_time_prev_absent (domyślnie 60000000 mikrosekund).

* session_time_next_absent: Interwał między bieżącą a następną sesją. Jeśli bieżąca sesja jest ostatnia lub interwał przekracza próg, ustawiana jest wartość session_time_next_absent (domyślnie 60000000 mikrosekund).

Te szczegółowe zasady pozwalają session_analyzer generować bogaty zestaw cech, które mogą być wykorzystane do szkolenia modeli ML. Użycie Suricaty do etykietowania umożliwia powiązanie tych cech z konkretnymi wykrytymi zagrożeniami, tworząc etykietowane zbiory danych bez konieczności przeprowadzania rzeczywistych ataków. Otwiera to drogę do tworzenia bardziej adaptacyjnych i precyzyjnych ML IDS, zdolnych do efektywnej pracy w dynamicznych i unikalnych warunkach rzeczywistych infrastruktur sieciowych.

Zalety i ograniczenia podejścia

Wykorzystanie Suricaty do etykietowania danych oferuje kilka kluczowych zalet:

• Realizm danych: Szkolenie odbywa się na rzeczywistym ruchu i prawdziwych incydentach zarejestrowanych przez Suricatę, co zwiększa trafność modelu.
• Oszczędność zasobów: Eliminuje potrzebę tworzenia kosztownych środowisk testowych do symulacji ataków lub przeprowadzania ataków na systemy produkcyjne.
• Adaptacyjność: Model uczy się na danych z konkretnej sieci, co pozwala mu lepiej dostosować się do unikalnych charakterystyk ruchu i sprzętu.

Istnieją jednak również ograniczenia. Jakość etykietowania zależy bezpośrednio od skuteczności Suricaty i aktualności jej sygnatur. Jeśli Suricata nie wykryje nowego ataku, taki atak nie zostanie oznaczony w zbiorze danych, a model ML nie nauczy się go identyfikować. Ponadto, sam proces generowania cech przez session_analyzer może być zasobożerny. Niemniej jednak, to podejście stanowi znaczący krok naprzód w rozwiązywaniu problemu tworzenia niezawodnych i adaptacyjnych ML IDS dla rzeczywistych środowisk produkcyjnych.

Kluczowe wnioski

• Tradycyjne IDS są podatne na nowe i zmodyfikowane ataki ze względu na podejście sygnaturowe.
• ML IDS są obiecujące, ale wymagają etykietowanych danych, które trudno uzyskać w rzeczywistych warunkach.
• Wykorzystanie zdarzeń Suricaty do etykietowania zbiorów danych pozwala szkolić ML IDS na rzeczywistym ruchu bez przeprowadzania ataków.
• Narzędzie session_analyzer generuje szczegółowe wektory cech sesji sieciowych w oparciu o 14 zasad.
• Podejście to zwiększa adaptacyjność ML IDS do unikalnych cech rzeczywistych sieci, ale zależy od jakości wykryć Suricaty.

— Editorial Team