ML IDS with Suricata: training models for cybersecurity

Next-Gen ML IDS: How Suricata Trains Models for Effective Intrusion Detection

Modern Intrusion Detection Systems (IDS) struggle to identify novel and modified cyberattacks due to their reliance on signature-based analysis. The advancement of machine learning (ML) offers a promising solution, but deploying ML IDS in real-world networks presents challenges, particularly concerning the generation of labeled data. This article explores an innovative approach to building ML IDS by leveraging security event data recorded by Suricata to train models and enhance defense efficacy.

The Evolution of Intrusion Detection Systems: From Signatures to Intelligence

The arsenal of information security tools against cyberattacks includes firewalls, network and host-based Intrusion Detection Systems (IDS), Next-Generation Firewalls (NGFW), and Security Information and Event Management (SIEM) systems. Despite their variety, most rely on signature-based analysis, which effectively identifies known threats but proves ineffective against new or modified attacks. This fundamental weakness underscores the urgency of developing ML IDS capable of heuristic or intelligent detection.

The task of building network-level ML IDS is typically approached in two main ways:

Network Traffic Classification: Dividing traffic into “clean” and “attack” (possibly with attack subcategories). This requires a labeled dataset, which is challenging in real-world scenarios due to ethical, infrastructural, and methodological constraints. Creating accurate models of protected resources or collecting attack data without compromising live infrastructure presents a significant hurdle.
Anomaly Detection: Identifying anomalous network connections or packets when only “clean” traffic is known. This approach is less demanding regarding labeled data but may result in a higher rate of false positives.

Existing research often demonstrates high accuracy for ML IDS in laboratory settings, where models are trained and tested in controlled environments. However, when these models are deployed in real-world networks, a significant performance drop is observed. This is because the feature vectors used for training often heavily depend on the physical network structure, hardware configurations, and the specifics of network services where data was collected. Discrepancies in these parameters between test and production environments lead to classification errors and a reduction in overall model accuracy.

Hypothesis and Methodology: Suricata as a Knowledge Source

Recognizing these limitations, the article's authors aimed to determine if an effective ML IDS could be built on an already operational network using data that does not require deliberate attacks on the resource. The core hypothesis is the feasibility of using security events recorded by traditional intrusion detection systems, such as Suricata, for dataset labeling. This approach bypasses the challenges of generating labeled data and can potentially enhance the adaptability of ML IDS to real-world conditions.

To implement this hypothesis, a proprietary tool called session_analyzer was developed. This tool is designed to calculate feature vector values for network traffic for each network connection. It's important to note that session_analyzer is analogous to the popular CICFlowMeter (formerly NTLFlowLyzer) but adapted for specific research tasks. Initially, it focuses on the TCP protocol, but its architecture allows for extending analysis to other protocols.

Principles of Feature Vector Generation in `session_analyzer`

session_analyzer applies strict rules for analyzing network traffic and extracting meaningful features, which are then used for training machine learning models. These principles ensure the consistency and relevance of the generated data.

Protocol Filtering: Only packets from Ethernet II, MPLS, VLAN, IPv4, TCP, UDP, and ICMPv4 protocols are analyzed. All other link, network, and transport layer protocols are ignored.
Network Session Identification (Flow ID): Each session is uniquely identified using a 5-component sequence (5-Tuple): Destination IP - Source IP - Destination Port - Source Port - Proto.
Network Session Definition: A session is defined as a sequence of packets belonging to a single TCP connection, UDP flow, or ICMP flow. A packet's belonging to a session is established by matching the 5-Tuple address information (either direct or reverse direction).
TCP Session Start Criterion: A TCP session is registered only upon the first packet with SYN=1 and ACK=0 flags. This packet also determines the data transfer direction (client-server).
UDP/ICMP Session Start Criterion: Registered upon the appearance of the first packet with a new identifier. Potential for error in direction determination, for example, with the first observed DNS response.
Network Session End Criterion (Timeout): A timeout from the last received packet is provided for all session types. Configurable default values: tcp_session_timeout = 60000 ms, udp_session_timeout = 60000 ms, icmp_session_timeout = 60000 ms.
TCP Session End Criterion (Termination Flags): RST or FIN packets are additionally monitored. Upon receiving an RST, the session is considered closed. Upon FIN, a mechanism for tracking acknowledgments (ACK) from both sides is initiated.
Network Packet Flow (Flow): A strict sequence of packets within a single session, irrespective of direction.
Forward Packet Flow (Fwd): A strict sequence of packets from client to server within a session.
Backward Packet Flow (Bwd): A strict sequence of packets from server to client within a session.
Network Session Duration: Can be calculated in two ways: from the first to the last packet in the session, or from the first to the last packet with payload data (payload > 0). The parameter is_need_calc_duration_by_last_payload controls this.
Network Session Stream (Stream): A set of sessions between a single Source IP and a specified network service (Destination IP | Destination Port | Proto). The stream_id is formed by concatenating these four components. Features with the "Stream" prefix characterize parallel sessions, their creation times, and intervals between them.
"Independent" Sessions in a Flow: Sessions are considered independent if the time between their creation exceeds session_simple_timeout (default 60000000 microseconds).
Time Intervals Between Sessions in a Flow:

* session_time_prev_absent: The interval between the current and previous session. If the current session is the first or the interval exceeds the threshold, the value session_time_prev_absent is set (default 60000000 microseconds).

* session_time_next_absent: The interval between the current and next session. If the current session is the last or the interval exceeds the threshold, the value session_time_next_absent is set (default 60000000 microseconds).

These detailed rules enable session_analyzer to generate a rich set of features that can be used for training ML models. Using Suricata for labeling allows these features to be associated with specific detected threats, creating labeled datasets without the need for real attacks. This paves the way for building more adaptive and accurate ML IDS capable of operating effectively in the dynamic and unique conditions of real-world network infrastructures.

Advantages and Limitations of the Approach

Using Suricata for data labeling offers several key advantages:

Data Realism: Training occurs on actual traffic and real incidents recorded by Suricata, which enhances model relevance.
Resource Efficiency: Eliminates the need for costly testbeds to simulate attacks or conduct attacks on production systems.
Adaptability: The model is trained on data from a specific network, allowing it to better adapt to the unique characteristics of traffic and equipment.

However, there are also limitations. The quality of labeling directly depends on Suricata's effectiveness and the currency of its signatures. If Suricata fails to detect a new attack, that attack will not be labeled in the dataset, and the ML model will not learn to identify it. Furthermore, the feature generation process by session_analyzer itself can be resource-intensive. Nevertheless, this approach represents a significant step forward in addressing the challenge of creating reliable and adaptive ML IDS for real-world production environments.

Key Takeaways

Traditional IDS are vulnerable to new and modified attacks due to their signature-based approach.
ML IDS show promise but require labeled data, which is difficult to obtain in real-world scenarios.
Leveraging Suricata events for dataset labeling enables training ML IDS on real traffic without conducting attacks.
The session_analyzer tool generates detailed feature vectors for network sessions based on 14 principles.
This approach enhances ML IDS adaptability to the unique characteristics of real networks but relies on the quality of Suricata's detections.

— Editorial Team