ML IDS se Suricata: trénování modelů pro kyberbezpečnost

ML IDS nové generace: Jak Suricata trénuje modely pro efektivní detekci průniků

Moderní systémy detekce průniků (IDS) se potýkají s problémem identifikace nových a modifikovaných kybernetických útoků kvůli své závislosti na signaturní analýze. Rozvoj strojového učení (ML) nabízí slibné řešení, avšak implementace ML IDS v reálných sítích je spojena s obtížemi, zejména co se týče tvorby označených dat. Tento článek zkoumá inovativní přístup k vytváření ML IDS, který využívá bezpečnostní události zaznamenané systémem Suricata k trénování modelů a zvyšování efektivity ochrany.

Evoluce systémů detekce průniků: od signatur k inteligenci

V arzenálu nástrojů pro ochranu informací před kybernetickými útoky najdeme firewally, systémy detekce průniků (IDS) na úrovni sítě i hostitele, NGFW a SIEM systémy. Navzdory jejich rozmanitosti se většina z nich spoléhá na signaturní analýzu, která efektivně identifikuje známé hrozby, ale je bezmocná proti novým nebo modifikovaným útokům. Tato zásadní slabina podtrhuje naléhavost vývoje ML IDS schopných heuristické nebo inteligentní detekce.

Úkol vytvoření ML IDS na úrovni sítě je formulován dvěma hlavními způsoby:

• Klasifikace síťového provozu: Rozdělení provozu na „čistý“ a „útok“ (případně s podkategoriemi útoků). To vyžaduje označený datový soubor, což je v reálných podmínkách obtížné kvůli etickým, infrastrukturním a metodologickým omezením. Vytvoření přesných modelů chráněných zdrojů nebo sběr dat o útocích bez poškození reálné infrastruktury představuje značný problém.
• Detekce anomálií: Odhalení anomálních síťových spojení nebo paketů, kdy je znám pouze „čistý“ provoz. Tento přístup je méně náročný na označená data, ale může mít vyšší podíl falešných poplachů.

Současné výzkumy často demonstrují vysokou přesnost ML IDS na laboratorních testovacích prostředích, kde jsou modely trénovány a testovány v kontrolovaném prostředí. Při přenosu těchto modelů do reálných sítí však dochází k výraznému snížení výkonu. To je způsobeno tím, že vektory příznaků používané pro trénování často silně závisí na fyzické struktuře sítě, nastavení hardwaru a specifikách síťových služeb, kde byl sběr dat prováděn. Rozdíly v těchto parametrech mezi testovacím a produkčním prostředím vedou k chybám v klasifikaci a snížení celkové přesnosti modelu.

Hypotéza a metodologie: Suricata jako zdroj znalostí

S vědomím těchto omezení si autoři článku stanovili za cíl zjistit, zda je možné vybudovat efektivní ML IDS na již provozované síti, a to s využitím dat, která nevyžadují záměrné útoky na daný zdroj. Hlavní hypotéza spočívá v možnosti použití bezpečnostních událostí zaznamenaných klasickými systémy detekce průniků, jako je Suricata, pro označování datových souborů. Tento přístup umožňuje obejít problémy s tvorbou označených dat a potenciálně zvýšit adaptabilitu ML IDS na reálné podmínky.

Principy tvorby vektorů příznaků v session_analyzer

session_analyzer uplatňuje přísná pravidla pro analýzu síťového provozu a extrakci významných příznaků, které jsou následně použity pro trénování modelů strojového učení. Tyto principy zajišťují konzistenci a relevanci generovaných dat.

• Filtrace protokolů: Analyzovány jsou pouze pakety protokolů Ethernet II, MPLS, VLAN, IPv4, TCP, UDP, ICMPv4. Všechny ostatní protokoly linkové, síťové a transportní vrstvy jsou ignorovány.
• Identifikace síťové relace (Flow ID): Každá relace je jednoznačně identifikována pomocí 5-komponentní sekvence (5-Tuple): Cílová IP - Zdrojová IP - Cílový Port - Zdrojový Port - Protokol.
• Definice síťové relace: Relace je definována jako posloupnost paketů patřících k jednomu TCP spojení, UDP toku nebo ICMP toku. Příslušnost paketu k relaci je stanovena shodou adresních informací 5-Tuple (přímý nebo zpětný směr).
• Kritérium začátku TCP relace: TCP relace je registrována pouze při prvním paketu s příznaky SYN=1 a ACK=0. Tento paket také určuje směr přenosu dat (klient-server).
• Kritérium začátku UDP/ICMP relace: Registruje se při objevení prvního paketu s novým identifikátorem. Možnost chyby v určení směru, například při první zaznamenané DNS odpovědi.
• Kritérium ukončení síťové relace (timeout): Pro všechny typy relací je stanoven timeout od posledního přijatého paketu. Nastavitelné výchozí hodnoty: tcp_session_timeout = 60000 ms, udp_session_timeout = 60000 ms, icmp_session_timeout = 60000 ms.
• Kritérium ukončení TCP relace (příznaky ukončení): Dále jsou sledovány pakety RST nebo FIN. Po obdržení RST je relace považována za ukončenou. Při FIN je spuštěn mechanismus sledování potvrzení (ACK) z obou stran.
• Tok síťových paketů (Flow): Přísná posloupnost paketů v rámci jedné relace bez ohledu na směr.
• Tok paketů ve směru Forward (Fwd): Přísná posloupnost paketů od klienta k serveru v rámci relace.
• Tok paketů ve směru Backward (Bwd): Přísná posloupnost paketů od serveru ke klientovi v rámci relace.
• Délka síťové relace: Může být vypočítána dvěma způsoby: od prvního do posledního paketu v relaci, nebo od prvního do posledního paketu s užitečnými daty (payload > 0). Parametr is_need_calc_duration_by_last_payload toto řídí.
• Tok síťových relací (Stream): Množina relací mezi jednou zdrojovou IP adresou a danou síťovou službou (Cílová IP | Cílový Port | Protokol). Identifikátor stream_id je tvořen konkatenací těchto čtyř komponent. Příznaky s předponou "Stream" charakterizují paralelní relace, jejich čas vzniku a intervaly mezi nimi.
• "Nezávislé" relace v toku: Relace jsou považovány za nezávislé, pokud čas mezi jejich vytvořením přesahuje session_simple_timeout (výchozí hodnota 60000000 mikrosekund).
• Časové intervaly mezi relacemi v toku:

* session_time_prev_absent: Interval mezi aktuální a předchozí relací. Pokud je aktuální relace první nebo interval přesahuje práh, nastaví se hodnota session_time_prev_absent (výchozí hodnota 60000000 mikrosekund).

* session_time_next_absent: Interval mezi aktuální a následující relací. Pokud je aktuální relace poslední nebo interval přesahuje práh, nastaví se hodnota session_time_next_absent (výchozí hodnota 60000000 mikrosekund).

Tato detailní pravidla umožňují session_analyzer generovat bohatou sadu příznaků, které mohou být použity pro trénování ML modelů. Použití Suricaty pro označování dat umožňuje tyto příznaky propojit s konkrétními detekovanými hrozbami, čímž se vytvářejí označené datové soubory bez nutnosti provádění skutečných útoků. To otevírá cestu k vytváření adaptivnějších a přesnějších ML IDS, schopných efektivně fungovat v dynamických a unikátních podmínkách reálných síťových infrastruktur.

Výhody a omezení přístupu

Použití Suricaty pro označování dat nabízí několik klíčových výhod:

• Realistická data: Trénink probíhá na reálném provozu a skutečných incidentech zaznamenaných Suricatou, což zvyšuje relevanci modelu.
• Úspora zdrojů: Není nutné vytvářet drahé testovací prostředí pro simulaci útoků nebo provádět útoky na produkční systémy.
• Adaptabilita: Model se učí na datech konkrétní sítě, což mu umožňuje lépe se přizpůsobit unikátním charakteristikám provozu a vybavení.

Existují však i omezení. Kvalita označení přímo závisí na efektivitě Suricaty a aktuálnosti jejích signatur. Pokud Suricata novou hrozbu neodhalí, nebude takový útok v datovém souboru označen a ML model se jej nenaučí detekovat. Kromě toho může být samotný proces generování příznaků v session_analyzer náročný na zdroje. Přesto tento přístup představuje významný krok vpřed v řešení problému vytváření spolehlivých a adaptabilních ML IDS pro reálná produkční prostředí.

Co je důležité

• Tradiční IDS jsou zranitelné vůči novým a modifikovaným útokům kvůli signaturnímu přístupu.
• ML IDS jsou slibné, ale vyžadují označená data, která je v reálných podmínkách obtížné získat.
• Využití událostí Suricaty pro označování datových souborů umožňuje trénovat ML IDS na reálném provozu bez provádění útoků.
• Nástroj session_analyzer generuje detailní vektory příznaků síťových relací na základě 14 principů.
• Tento přístup zvyšuje adaptabilitu ML IDS na unikátní vlastnosti reálných sítí, ale závisí na kvalitě detekcí Suricaty.

— Editorial Team