Suricata a montré comment entraîner des systèmes de détection d’attaques basés sur le ML sur du trafic réel

Suricata a montré comment entraîner les systèmes de détection d'attaques ML sur le trafic réel

L'IDS basé sur les signatures Suricata peut être non seulement un outil de détection, mais aussi une source d'étiquetage pour un modèle ML de détection d'attaques. Les auteurs de l'étude ont testé cette idée sur le trafic corporatif réel et ont trouvé un scénario viable, bien que non universel, pour entraîner un ML IDS sans mener d'attaques artificielles sur la ressource protégée.

Comment l'expérience a été configurée

L'expérience a été déployée sur le banc d'essai de l'entreprise Ideco. Un serveur recevait le trafic corporatif réel et le transmettait via un NGFW avec un Suricata IDS modifié et des signatures actuelles. Un deuxième serveur analysait le même flux de trafic avec son propre utilitaire session_analyzer, qui collectait les caractéristiques pour chaque session réseau.

Les auteurs n'ont délibérément pas construit une infrastructure de laboratoire avec des attaques synthétiques : l'objectif était de comprendre si un modèle pouvait être entraîné directement sur un réseau déjà opérationnel et sur des événements de sécurité réels. La collecte a duré deux semaines—du 26 juin au 10 juillet 2025. Après filtrage, il restait 55.

548.971 connexions réseau. Sur les 118 caractéristiques initiales, ils ont sélectionné les informations d'adresse et 10 des caractéristiques de session les plus informatives, puis les ont comparées avec les détections de Suricata et ont attribué des étiquettes Benign ou Attack.

Le résultat était un ensemble de données binaire où le rôle du « professeur » pour le modèle était joué non par des personnes ou un étiquetage manuel, mais par un IDS basé sur les signatures déjà configuré.

Où le schéma s'effondre

Le problème principal s'est avéré ne pas être dans la sélection d'algorithme, mais dans la qualité de l'étiquetage. Le temps de l'événement dans Suricata ne correspond pas au moment du début de la connexion réseau : une détection peut se rapporter à un paquet qui arrive des secondes après le début de la session, et pour les attaques lentes, l'écart dépassait 20 secondes. De plus, le même trafic pouvait être observé avant et après la passerelle, ce qui signifie qu'une attaque correspondait à deux connexions avec des informations d'adresse différentes. Si ces cas ne sont pas pris en compte, le bruit entre dans l'ensemble de données et le modèle commence à apprendre à partir d'exemples contradictoires.

• tous les SID de Suricata ne conviennent pas à l'étiquetage, en particulier les règles liées uniquement à IP, SNI ou des URL spécifiques;
• pour certaines attaques, y compris divers types d'analyse de ports, l'ensemble actuel de caractéristiques est simplement insuffisant;
• l'échantillon d'entraînement doit couvrir au moins une semaine de trafic réel, y compris les jours ouvrables et les week-ends;
• le modèle doit être réentraîné lorsque de nouveaux types d'attaques apparaissent, les signatures changent, l'infrastructure réseau change ou le profil de travail des employés change.

D'où est venu le constat clé sur les vecteurs « mauvais » : si deux connexions ont des caractéristiques identiques ou presque identiques mais des étiquettes différentes, la qualité de la classification chute considérablement. Même le renforcement de gradient puissant comme CatBoost n'aide pas dans ce cas. Certains événements de Suricata aident le modèle, tandis que d'autres ne font que ajouter de faux positifs. Certaines signatures ont finalement plus de sens à exclure de l'étiquetage et à renvoyer les connexions correspondantes à la classe Benign, sinon le ML IDS hérite des erreurs de la couche de signature sous-jacente.

Ce que les résultats ont montré

Malgré toutes les limitations, l'hypothèse a été généralement confirmée : un ML IDS au niveau du réseau peut être construit sur un réseau déjà opérationnel, en utilisant les événements de Suricata comme source d'étiquettes. C'est pratique car les règles de signature bien réglées filtrent à l'avance une part importante des alertes bruyantes auxquelles les opérateurs ne répondraient de toute façon pas. Dans ce mode, Suricata devient non seulement un système de détection mais aussi un filtre de qualité pour l'ensemble d'entraînement.

Le meilleur résultat pratique de l'étude était un score F1 de 0,98 avec un étiquetage correct de l'ensemble de données. Mais les auteurs notent honnêtement les limites de l'approche. Premièrement, ils ont résolu un problème de classification binaire, mais pour un NGFW réel, cela est insuffisant : l'entreprise doit comprendre quelle classe exacte d'attaque a été détectée et comment y répondre.

Deuxièmement, l'expérience a été menée sur un réseau corporatif d'utilisateur, et non sur un service spécifique protégé comme un serveur web, donc transférer les conclusions à d'autres réseaux nécessite une vérification séparée.

Ce que cela signifie

L'étude montre un chemin prédéfini de la protection basée sur les signatures à un modèle ML sans polygone d'essai coûteux et étiquetage manuel de millions de sessions. Mais cela nous rappelle aussi le point principal : en cybersécurité, la qualité du ML commence non pas par le choix de l'algorithme, mais par la façon dont vous connectez soigneusement les alertes réelles, les caractéristiques du réseau et le contexte de l'infrastructure.