ML IDS avec Suricata : entraînement de modèles pour la cybersécurité

IDS ML de Nouvelle Génération : Comment Suricata Entraîne des Modèles pour une Détection d'Intrusion Efficace

Les Systèmes de Détection d'Intrusion (IDS) modernes peinent à identifier les cyberattaques inédites et modifiées en raison de leur dépendance à l'analyse basée sur les signatures. L'avancement de l'apprentissage automatique (ML) offre une solution prometteuse, mais le déploiement d'IDS ML dans les réseaux réels présente des défis, notamment en ce qui concerne la génération de données étiquetées. Cet article explore une approche innovante pour construire des IDS ML en exploitant les données d'événements de sécurité enregistrées par Suricata afin d'entraîner des modèles et d'améliorer l'efficacité de la défense.

L'Évolution des Systèmes de Détection d'Intrusion : Des Signatures à l'Intelligence

L'arsenal des outils de sécurité de l'information contre les cyberattaques comprend les pare-feu, les Systèmes de Détection d'Intrusion (IDS) basés sur le réseau et l'hôte, les Pare-feu de Nouvelle Génération (NGFW) et les systèmes de Gestion des Informations et des Événements de Sécurité (SIEM). Malgré leur diversité, la plupart reposent sur une analyse basée sur les signatures, qui identifie efficacement les menaces connues mais s'avère inefficace contre les attaques nouvelles ou modifiées. Cette faiblesse fondamentale souligne l'urgence de développer des IDS ML capables d'une détection heuristique ou intelligente.

La tâche de construire des IDS ML au niveau du réseau est généralement abordée de deux manières principales :

• Classification du Trafic Réseau : Diviser le trafic en “propre” et “attaque” (éventuellement avec des sous-catégories d'attaque). Cela nécessite un ensemble de données étiquetées, ce qui est difficile dans des scénarios réels en raison de contraintes éthiques, infrastructurelles et méthodologiques. La création de modèles précis de ressources protégées ou la collecte de données d'attaque sans compromettre l'infrastructure en direct représente un obstacle significatif.
• Détection d'Anomalies : Identifier les connexions ou paquets réseau anormaux lorsque seul le trafic “propre” est connu. Cette approche est moins exigeante en termes de données étiquetées mais peut entraîner un taux plus élevé de faux positifs.

Les recherches existantes démontrent souvent une grande précision pour les IDS ML dans des environnements de laboratoire, où les modèles sont entraînés et testés dans des conditions contrôlées. Cependant, lorsque ces modèles sont déployés dans des réseaux réels, une baisse significative des performances est observée. Cela est dû au fait que les vecteurs de caractéristiques utilisés pour l'entraînement dépendent souvent fortement de la structure physique du réseau, des configurations matérielles et des spécificités des services réseau où les données ont été collectées. Les écarts dans ces paramètres entre les environnements de test et de production entraînent des erreurs de classification et une réduction de la précision globale du modèle.

Hypothèse et Méthodologie : Suricata comme Source de Connaissances

Reconnaissant ces limitations, les auteurs de l'article ont cherché à déterminer si un IDS ML efficace pouvait être construit sur un réseau déjà opérationnel en utilisant des données qui ne nécessitent pas d'attaques délibérées sur la ressource. L'hypothèse centrale est la faisabilité d'utiliser les événements de sécurité enregistrés par les systèmes de détection d'intrusion traditionnels, tels que Suricata, pour l'étiquetage des ensembles de données. Cette approche contourne les défis de la génération de données étiquetées et peut potentiellement améliorer l'adaptabilité des IDS ML aux conditions réelles.

Pour mettre en œuvre cette hypothèse, un outil propriétaire appelé session_analyzer a été développé. Cet outil est conçu pour calculer les valeurs des vecteurs de caractéristiques pour le trafic réseau pour chaque connexion réseau. Il est important de noter que session_analyzer est analogue au populaire CICFlowMeter (anciennement NTLFlowLyzer) mais adapté à des tâches de recherche spécifiques. Initialement, il se concentre sur le protocole TCP, mais son architecture permet d'étendre l'analyse à d'autres protocoles.

Principes de Génération des Vecteurs de Caractéristiques dans session_analyzer

session_analyzer applique des règles strictes pour analyser le trafic réseau et extraire des caractéristiques significatives, qui sont ensuite utilisées pour entraîner les modèles d'apprentissage automatique. Ces principes garantissent la cohérence et la pertinence des données générées.

• Filtrage des Protocoles : Seuls les paquets des protocoles Ethernet II, MPLS, VLAN, IPv4, TCP, UDP et ICMPv4 sont analysés. Tous les autres protocoles de couche liaison, réseau et transport sont ignorés.
• Identification de la Session Réseau (ID de Flux) : Chaque session est identifiée de manière unique à l'aide d'une séquence à 5 composants (5-Tuple) : IP de Destination - IP Source - Port de Destination - Port Source - Proto.
• Définition de la Session Réseau : Une session est définie comme une séquence de paquets appartenant à une seule connexion TCP, un flux UDP ou un flux ICMP. L'appartenance d'un paquet à une session est établie en faisant correspondre les informations d'adresse 5-Tuple (direction directe ou inverse).
• Critère de Démarrage de Session TCP : Une session TCP est enregistrée uniquement lors du premier paquet avec les flags SYN=1 et ACK=0. Ce paquet détermine également la direction du transfert de données (client-serveur).
• Critère de Démarrage de Session UDP/ICMP : Enregistré lors de l'apparition du premier paquet avec un nouvel identifiant. Potentiel d'erreur dans la détermination de la direction, par exemple, avec la première réponse DNS observée.
• Critère de Fin de Session Réseau (Délai d'Attente) : Un délai d'attente à partir du dernier paquet reçu est fourni pour tous les types de session. Valeurs par défaut configurables : tcp_session_timeout = 60000 ms, udp_session_timeout = 60000 ms, icmp_session_timeout = 60000 ms.
• Critère de Fin de Session TCP (Flags de Terminaison) : Les paquets RST ou FIN sont également surveillés. Dès la réception d'un RST, la session est considérée comme fermée. Dès un FIN, un mécanisme de suivi des accusés de réception (ACK) des deux côtés est initié.
• Flux de Paquets Réseau (Flow) : Une séquence stricte de paquets au sein d'une seule session, quelle que soit la direction.
• Flux de Paquets Avant (Fwd) : Une séquence stricte de paquets du client vers le serveur au sein d'une session.
• Flux de Paquets Arrière (Bwd) : Une séquence stricte de paquets du serveur vers le client au sein d'une session.
• Durée de la Session Réseau : Peut être calculée de deux manières : du premier au dernier paquet de la session, ou du premier au dernier paquet avec des données de charge utile (payload > 0). Le paramètre is_need_calc_duration_by_last_payload contrôle cela.
• Flux de Session Réseau (Stream) : Un ensemble de sessions entre une seule IP Source et un service réseau spécifié (IP de Destination | Port de Destination | Proto). L'stream_id est formé en concaténant ces quatre composants. Les caractéristiques avec le préfixe "Stream" caractérisent les sessions parallèles, leurs heures de création et les intervalles entre elles.
• Sessions "Indépendantes" dans un Flux : Les sessions sont considérées comme indépendantes si le temps entre leur création dépasse session_simple_timeout (par défaut 60000000 microsecondes).
• Intervalles de Temps Entre les Sessions dans un Flux :

* session_time_prev_absent : L'intervalle entre la session actuelle et la précédente. Si la session actuelle est la première ou si l'intervalle dépasse le seuil, la valeur session_time_prev_absent est définie (par défaut 60000000 microsecondes).

* session_time_next_absent : L'intervalle entre la session actuelle et la suivante. Si la session actuelle est la dernière ou si l'intervalle dépasse le seuil, la valeur session_time_next_absent est définie (par défaut 60000000 microsecondes).

Ces règles détaillées permettent à session_analyzer de générer un riche ensemble de caractéristiques qui peuvent être utilisées pour entraîner des modèles ML. L'utilisation de Suricata pour l'étiquetage permet d'associer ces caractéristiques à des menaces spécifiques détectées, créant ainsi des ensembles de données étiquetées sans nécessiter d'attaques réelles. Cela ouvre la voie à la construction d'IDS ML plus adaptatifs et précis, capables de fonctionner efficacement dans les conditions dynamiques et uniques des infrastructures réseau réelles.

Avantages et Limites de l'Approche

L'utilisation de Suricata pour l'étiquetage des données offre plusieurs avantages clés :

• Réalisme des Données : L'entraînement se fait sur le trafic réel et les incidents réels enregistrés par Suricata, ce qui améliore la pertinence du modèle.
• Efficacité des Ressources : Élimine le besoin de bancs d'essai coûteux pour simuler des attaques ou mener des attaques sur des systèmes de production.
• Adaptabilité : Le modèle est entraîné sur des données provenant d'un réseau spécifique, ce qui lui permet de mieux s'adapter aux caractéristiques uniques du trafic et de l'équipement.

Cependant, il existe également des limites. La qualité de l'étiquetage dépend directement de l'efficacité de Suricata et de l'actualité de ses signatures. Si Suricata ne parvient pas à détecter une nouvelle attaque, cette attaque ne sera pas étiquetée dans l'ensemble de données, et le modèle ML n'apprendra pas à l'identifier. De plus, le processus de génération de caractéristiques par session_analyzer lui-même peut être gourmand en ressources. Néanmoins, cette approche représente un pas significatif dans la résolution du défi de la création d'IDS ML fiables et adaptatifs pour les environnements de production réels.

Points Clés à Retenir

• Les IDS traditionnels sont vulnérables aux attaques nouvelles et modifiées en raison de leur approche basée sur les signatures.
• Les IDS ML sont prometteurs mais nécessitent des données étiquetées, difficiles à obtenir dans des scénarios réels.
• L'exploitation des événements Suricata pour l'étiquetage des ensembles de données permet d'entraîner des IDS ML sur le trafic réel sans mener d'attaques.
• L'outil session_analyzer génère des vecteurs de caractéristiques détaillés pour les sessions réseau basés sur 14 principes.
• Cette approche améliore l'adaptabilité des IDS ML aux caractéristiques uniques des réseaux réels mais dépend de la qualité des détections de Suricata.

— Editorial Team