Les systèmes de détection des intrusions passent d’une dépendance presque totale aux signatures connues à une architecture hybride combinant correspondance traditionnelle, apprentissage automatique et investigation agentique. Une analyse publiée sur le blog de Stack Overflow estime que SnortML constitue une couche de détection de bas niveau au sein de Snort 3, tandis que l’intelligence artificielle agentique relie les événements dans le temps et entre les sources, puis détermine l’étape suivante de l’investigation.
Le problème des signatures traditionnelles ne tient pas à leur manque de précision, mais au fait qu’elles sont précises pour ce qu’elles ont été conçues à détecter. Une règle dédiée à une vulnérabilité donnée, telle que CVE-2024-12345, peut détecter l’exploitation connue avec un taux de faux positifs très faible, mais ne pas réagir à une charge utile modifiée qui emprunte le même chemin de code vulnérable. Entre l’apparition d’un nouvel exploit dans la nature, son analyse, l’écriture d’une règle, son test et sa distribution, des jours ou des semaines peuvent s’écouler, ce qui constitue une lacune dangereuse lorsque la vulnérabilité est effectivement exploitée.
Comment SnortML fonctionne-t-il au sein de Snort 3 ?
Cisco Talos a présenté le moteur SnortML en mars 2024 comme un moteur de détection par apprentissage automatique fonctionnant nativement dans Snort 3. Le moteur ne dépend pas d’un service cloud externe, car l’inférence est réalisée localement, dans le même chemin de traitement que celui utilisé pour évaluer les règles, et produit un résultat en moins d’une milliseconde.
L’implémentation se compose du module snort_ml_engine, qui charge au démarrage les modèles TensorFlow préentraînés, et de l’inspecteur snort_ml, qui reçoit les données des inspecteurs de services existants de Snort 3 via une interface de publication-abonnement. Lorsque l’inspecteur HTTP termine l’analyse de la requête, il envoie la chaîne de requête et le contenu POST au bus d’événements, puis SnortML les classe et renvoie une valeur probabiliste indiquant la probabilité qu’ils contiennent une tentative d’exploitation.
Le modèle repose sur un réseau LSTM précédé d’une couche d’incorporation qui transforme les valeurs brutes des octets en représentations vectorielles, ce qui permet de capturer les relations et le contexte entre les octets, avant que le LSTM ne traite leur ordre et leur séquence. Une couche dense finale réduit le résultat à une seule valeur probabiliste. LibML, fourni avec SnortML, utilise la bibliothèque XNNPACK pour accélérer les opérations matricielles. Selon l’article, une classification prend environ 350 microsecondes sur un processeur AMD cadencé à 4,7 gigahertz.
À partir de Secure Firewall 10.0.0, SnortML sélectionne automatiquement un modèle adapté aux longueurs de 256, 512 ou 1024 octets. Les requêtes dépassant 1024 octets sont tronquées à cette limite avant la classification. La première version détectait les injections SQL, puis la couverture s’est étendue jusqu’à la fin de 2025 pour inclure les XSS et les injections de commandes. Les mises à jour des modèles sont distribuées via le même système Lightweight Security Package que celui utilisé pour distribuer le contenu des règles.
La force et les limites de l’approche hybride
SnortML fonctionne en parallèle de la correspondance des signatures, et non à sa place. Le modèle peut détecter de nouvelles variantes d’attaques appartenant à des catégories connues, tandis que les signatures traditionnelles fournissent une ligne de détection à faible bruit pour les modèles confirmés. Lorsque les deux mécanismes déclenchent une alerte sur la même charge utile, celle-ci peut être considérée comme un signal plus fort qu’une alerte issue du seul apprentissage automatique, chaque mécanisme conservant toutefois des caractéristiques d’erreur différentes.
Mais SnortML analyse un seul paramètre HTTP, comme une chaîne de requête URI ou un contenu POST, et ne sait pas ce qui s’est produit avant ou après la requête, ni ce que l’adresse source a fait au cours des minutes précédentes. Ainsi, une séquence de reconnaissance, puis d’énumération et enfin d’exploitation personnalisée peut passer sans qu’aucune étape isolée ne dépasse le seuil de détection. En outre, le modèle actuel ne voit pas les tunnels DNS, les attaques de la couche TLS, l’exploitation de SMB ou les comportements anormaux dans les protocoles autres que HTTP, car les modèles disponibles sont liés au chemin de données de l’inspecteur HTTP.
Le temps de traitement d’environ 350 microsecondes ajoute également un coût réel, bien que limité et prévisible grâce à XNNPACK. Il ne faut donc pas évaluer les performances du modèle indépendamment de la taille de l’ensemble de règles, de la complexité des protocoles et du budget de traitement de l’équipement de protection.
Qu’ajoute l’intelligence artificielle agentique ?
L’analyse distingue un modèle d’apprentissage automatique qui évalue uniquement ce qui se trouve devant lui, un playbook SOAR qui suit des étapes fixes et un agent qui conserve l’état d’une investigation en plusieurs phases et décide de ce qui doit être examiné ensuite en fonction des résultats précédents. Selon le scénario présenté, l’agent peut interroger le SIEM sur des événements associés, vérifier l’empreinte d’un fichier via une plateforme de renseignement sur les menaces, récupérer l’activité d’un utilisateur auprès du fournisseur d’identité, puis rassembler le contexte avant de recommander une réponse ou de la transmettre à un analyste humain.
L’article mentionne le lancement par IBM de la plateforme ATOM, ou Autonomous Threat Operations Machine, en avril 2025, ainsi que le lancement par Trend Micro d’Agentic SIEM en août 2025. Ces systèmes sont présentés comme des plateformes de coordination et d’investigation multi-agents, et non comme de simples interfaces conversationnelles dotées d’informations de sécurité. L’analyse relie leur essor à la pression causée par la pénurie de personnel : elle mentionne une pénurie mondiale d’environ quatre millions de postes vacants dans la cybersécurité, ainsi qu’une enquête menée en 2025 selon laquelle 82 % des analystes des centres d’opérations de sécurité craignent de manquer de véritables menaces en raison du volume d’alertes.
Dans cette architecture, Snort 3 et SnortML deviennent des capteurs proches du réseau, fournissant à la couche d’inférence supérieure ce qui a effectivement été observé. Mais l’augmentation du niveau d’automatisation rend la précision du capteur plus importante : une fausse alerte ne consomme pas seulement le temps de l’analyste, elle mobilise aussi les ressources des agents et peut déclencher des mesures de confinement dans des environnements mal configurés. La valeur probabiliste de SnortML permet également de construire un score de confiance composite : une alerte combinant une signature traditionnelle et un score ML de 0,97 doit être traitée différemment d’une alerte déclenchée uniquement par le ML avec un score de 0,61.
Architecture d’intégration et problème de la boucle de rétroaction
L’article propose une architecture qui commence par une couche de capture des paquets via DAQ, en utilisant AFPacket RSS ou DPDK selon les exigences de débit, puis une couche de détection qui exécute en parallèle le moteur MPSE Hyperscan et SnortML. Les deux couches envoient à un bus de télémétrie unifié des événements au format JSON comprenant les alertes, les scores de probabilité et les données des flux.
Les tâches sont ensuite réparties entre des agents spécialisés : un agent chargé du triage, de la déduplication et de l’évaluation de la gravité, des agents chargés de l’enrichissement et du renseignement sur les menaces, un agent d’investigation qui relie les journaux du SIEM, du fournisseur d’identité et des points de terminaison, ainsi qu’un agent de contexte qui compare l’activité aux modèles historiques et aux campagnes connues. Le scénario insiste sur la nécessité de renvoyer les résultats des investigations confirmées aux moteurs de modèles et de règles, plutôt que d’arrêter le flux au stade de la réponse.
Les charges utiles dont il a été établi qu’elles constituaient des attaques, mais qui ont obtenu un score faible ou n’ont correspondu à aucune signature, peuvent être transformées en données d’entraînement ou en entrées pour la formulation de nouvelles règles. Ce processus nécessite toutefois une validation humaine et des mécanismes de détection de l’empoisonnement des données d’entraînement : un attaquant pourrait tenter de manipuler les résultats de l’investigation automatisée afin d’introduire des échantillons corrompus dans le processus de réentraînement.
Limites du déploiement et recommandations pratiques
L’analyse relève d’autres lacunes, notamment la limitation de la couverture actuelle de SnortML aux paramètres HTTP, l’immaturité des protocoles de coordination des agents et la faible explicabilité des alertes du modèle. Les sorties actuelles affichent le score de probabilité et la charge utile à l’origine de l’alerte, mais n’indiquent pas quels octets ou quelles zones de l’entrée ont influencé le résultat. En outre, la robustesse du modèle face à l’obfuscation, à l’encodage, à la manipulation des espaces et à l’injection de commentaires SQL n’a pas été décrite publiquement dans des évaluations publiées, selon l’article.
En pratique, l’article recommande de commencer par exécuter SnortML sur un port de surveillance et en mode alerte uniquement, et non directement sur le chemin avec blocage. Il convient de mesurer les faux positifs sur le trafic des applications connues pendant au moins deux semaines couvrant les cycles de travail habituels, puis d’ajuster les seuils avant d’activer le déploiement sélectif inline. Le score ML doit également être traité comme un facteur dans le calcul d’un niveau de confiance composite, et non comme un substitut à la signature traditionnelle ou comme un déclencheur de blocage à lui seul.
Les mesures de confinement à fort impact, telles que le blocage d’adresses IP, l’isolement des appareils ou la réinitialisation des identifiants, doivent rester soumises à une validation humaine. La conclusion principale de l’analyse est que l’automatisation peut prendre en charge le triage, l’enrichissement, la corrélation et l’agrégation intensive du contexte, tandis que la décision finale de réponse est plus sûre lorsqu’elle est examinée par un humain à partir du contexte recueilli par l’agent.