Comprendre ANM
Médiation Neuronale Adversarielle : une défense réseau pensée pour les attaques qui ciblent aussi le machine learning.
Par Ward³
Synthèse exécutive
Le Network Detection and Response (NDR), popularisé par des acteurs comme Vectra, Darktrace et ExtraHop, repose souvent sur une hypothèse simple : un modèle ML bien entraîné sur le trafic d'entreprise saura repérer les attaques avancées. Cette hypothèse était raisonnable en 2017. En 2026, elle est devenue trop fragile pour les environnements à fort enjeu.
Dix ans de recherche en machine learning adversariel ont montré la même chose dans beaucoup de domaines : un modèle utilisé seul peut être trompé par un attaquant motivé. Évasion par gradient, attaques de transfert, extraction de modèle, empoisonnement de labels : ces techniques ne sont plus réservées aux laboratoires. Elles sont disponibles dans des frameworks open source comme ART, CleverHans ou Foolbox.
Pour une banque, un opérateur télécom, un industriel critique ou une organisation de défense, la bonne question n'est plus seulement « notre NDR peut-il être contourné ? ». Elle devient : « si un modèle se trompe, qu'est-ce qui détecte l'incohérence ? »
La Médiation Neuronale Adversarielle (ANM) part de cette question. Au lieu de confier la décision à un seul modèle, ANM fait arbitrer plusieurs juges IA réellement différents : signaux différents, architectures différentes, biais inductifs différents. Leur désaccord est mesuré explicitement et traité comme un signal de sécurité. Tromper un juge ne suffit plus ; il faut tromper plusieurs façons de lire le réseau en même temps.
Partie 1 — Le modèle de menace a changé
Les IDS classiques, comme Snort ou Suricata, reposaient sur des signatures. L'attaquant cherchait à modifier son payload jusqu'à ne plus correspondre à une règle. Les défenseurs répondaient par de nouvelles signatures et des heuristiques.
Le NDR a déplacé le problème vers la détection statistique et le ML. L'attaquant ne cherche plus seulement à éviter une signature ; il cherche à faire prendre une mauvaise décision à un modèle appris. Ce changement compte, parce qu'un modèle ML est moins inspectable, souvent différentiable, et donc exposé à des attaques par optimisation.
Dès 2014, Goodfellow et al. montraient que de très petites perturbations pouvaient faire changer la prédiction d'un classifieur d'images avec un taux de succès très élevé. Les années suivantes ont confirmé le risque sur le malware, la voix, le visage et, pour ce qui nous intéresse ici, la détection d'intrusion réseau.
L'attaquant n'a plus besoin de comprendre toute votre logique de détection. S'il peut entraîner ou obtenir un modèle suffisamment proche, souvent à partir de datasets publics, il peut produire des exemples adversariels qui se transfèrent.
Partie 2 — Pourquoi le NDR mono-modèle échoue
Derrière les différences de packaging, beaucoup de produits NDR suivent le même pipeline : capture de flux (NetFlow / IPFIX / packet broker), extraction de features (5-tuple, tailles de paquets, temps inter-arrivée, protocoles), passage dans un modèle ML, scoring, puis alerte si le seuil est dépassé.
Le modèle devient alors le point de défaillance principal. Si l'attaquant imite assez bien les statistiques du trafic légitime, injecte des features sous le seuil d'erreur de reconstruction, ou choisit une fenêtre de ré-entraînement favorable, l'alerte peut simplement ne jamais partir.
Avec une architecture NDR à autoencodeur typique, nous avons reproduit trois scénarios d'évasion par gradient à ε=0,02, soit une perturbation d'environ 2 % de chaque vecteur de features. Les taux de détection passent de 86–99 % à 12–41 %. L'attaque ne change pas vraiment ; ce sont les features vues par le NDR qui changent.
Partie 3 — Pourquoi les ensembles homogènes ne suffisent pas
La réaction naturelle d'une équipe ML est de proposer un ensemble. C'est utile, parce que cela augmente le coût de l'attaque, mais cela ne règle pas le problème si les modèles se ressemblent trop. Ils partagent encore :
- les mêmes features d'entrée,
- les mêmes données d'entraînement,
- souvent la même famille d'architecture avec des graines aléatoires différentes.
Quand ces éléments sont communs, les perturbations adversarielles se transfèrent souvent d'un modèle à l'autre. Des taux de transfert au-dessus de 60 % sont courants.
La défense devient plus intéressante quand les juges ne se ressemblent pas : chacun doit avoir une vraie raison différente de trouver un flux suspect.
Partie 4 — Ce que nous appelons ANM
La Médiation Neuronale Adversarielle (ANM) désigne une défense réseau où la décision ne vient pas d'un seul modèle ML, mais d'un arbitrage entre plusieurs juges architecturalement distincts. La divergence entre juges n'est pas un détail statistique : elle devient un signal de sécurité.
La définition est volontairement stricte. Trois autoencodeurs presque identiques ne font pas de l'ANM. Un SIEM qui corrèle les alertes de trois produits différents non plus. Et un pipeline entraîné de manière adversarielle, mais qui expose un seul modèle à l'inférence, reste un pipeline mono-modèle.
Partie 5 — Les cinq critères
Pour parler sérieusement d'ANM, les cinq critères ci-dessous doivent être présents ensemble.
- 01Au moins trois juges, architecturalement distincts
Pas trois graines aléatoires, ni trois tailles de fenêtres glissantes. Il faut trois façons différentes de lire le trafic : par exemple un modèle séquentiel sur le timing des paquets, un modèle graphique sur la topologie des flux, et un moteur déterministe de règles. L'objectif est simple : éviter que la même perturbation trompe tout le monde pour la même raison.
- 02Détection explicite de divergence
Le système doit calculer en temps réel le désaccord entre les juges (KL, max-min spread, Jensen-Shannon) et le traiter comme un signal de sécurité, pas comme un simple score de confiance. Une attaque adversarielle réussie contre un juge laisse souvent des sorties anormales chez les autres. C'est précisément ce désaccord qu'il faut exploiter.
- 03Entraînement adversariel des juges ML
Les juges ML doivent être entraînés avec des procédures de robustesse adversarielle, pas seulement sur données propres. La procédure et le modèle de menace doivent être documentés. Un juge non entraîné reste facile à tromper seul ; un juge robuste augmente le coût de l'attaque.
- 04Intégrité et watermarking des modèles
Les modèles déployés doivent être signés et vérifiés au chargement, avec une chaîne qui va de l'artefact de build au déploiement. La substitution et l'empoisonnement de modèle sont des attaques réelles. Sans provenance, la médiation perd sa valeur.
- 05Piste de décision auditable
Chaque décision de détection — scores par juge, divergence, action appliquée — doit être conservée dans un journal inviolable. C'est indispensable pour le forensics, le ré-entraînement et les audits. Une robustesse qu'on ne peut pas rejouer reste difficile à défendre devant un régulateur, un assureur ou un conseil d'administration.
Partie 6 — Ward³ comme implémentation
Ward³ implémente ces cinq critères avec des choix techniques concrets.
Le système s'appuie sur trois juges : un juge séquentiel, qui observe les fenêtres de paquets par flux ; un juge relationnel, qui analyse la topologie src→dst dans une fenêtre glissante ; et un juge de règles, fondé sur des invariants experts.
Les deux premiers juges ne lisent pas le trafic de la même manière. Une perturbation qui rend une séquence plausible ne rend pas forcément la topologie du graphe plausible. Le juge de règles ajoute un troisième axe non différentiable, ce qui le met hors de portée directe des attaques par gradient.
Le médiateur calcule les scores par juge, les divergences par paires et l'écart maximum. Il ne produit un consensus que si la divergence reste sous le seuil. En cas de désaccord, il fail-close et publie XAI_DIVERGENCE_HIGH. L'attaque est alors visible non pas parce qu'un juge a raison seul, mais parce que les juges ne racontent plus la même histoire.
Les deux juges ML sont entraînés avec des procédures d'attaque par gradient. Le modèle de menace, les hyperparamètres et la procédure d'entraînement sont documentés et reproductibles.
Chaque artefact d'inférence est signé au build et vérifié au chargement. Le registre de modèles reste append-only et conserve la provenance : hash du dataset d'entraînement, ID du run, commit du code, et lien vers la model card.
Chaque décision est persistée dans un ledger chaîné par hash et signé avec des primitives post-quantiques. Le ledger peut être rejoué pour reconstruire une décision passée et expliquer le raisonnement du médiateur à un auditeur.
Partie 7 — Trois juges, trois latences, trois surfaces
Ward³ applique la même logique au runtime : toutes les décisions n'ont pas besoin de la même profondeur d'analyse ni de la même latence.
Tier 1 — Edge (μs). Le juge de règles en Rust, le cache de threat intelligence, les empreintes TLS, le préprocessing eBPF et l'enforcement local traitent les cas évidents au plus près du trafic. Une part importante du trafic peut être résolue ici, en microsecondes, sans appeler les modèles ML.
Tier 2 — Tenant (ms). Les juges séquentiel et relationnel tournent ici, aux côtés des juges endpoint processus et fichier. Le médiateur calcule consensus et divergence, puis produit le verdict et le signal d'enforcement.
Tier 3 — Plateforme (dizaines de ms, async). La plateforme enrichit les décisions avec la corrélation cross-host et cross-tenant : endpoint, baselines long-horizon, reconstruction de kill-chain, threat intel fédéré. Ce travail ne bloque pas le hot path ; il complète les verdicts émis au Tier 2.
Ward³ couvre les flux réseau et les signaux endpoint (processus, fichier, mouvement latéral, credential, tamper) sous un même médiateur et un même ledger d'audit. C'est une trajectoire NDR vers XDR sans abandonner les garanties ANM.
Partie 8 — Caractéristiques de performance
Les résultats ci-dessous viennent de trafic exclu de l'entraînement et de réseaux hors-distribution : formats de logs, familles d'attaque et botnets IoT jamais vus pendant l'entraînement. La robustesse adversarielle est mesurée sous évasion par gradient.
L'architecture à trois juges apporte +30 à +60 points de détection sous conditions adversarielles. La contrepartie est une latence d'inférence environ 2× supérieure à un modèle unique, qui reste sous 10 ms p99 par flux sur matériel standard.
| Métrique | Baseline mono-juge | Médiation Ward³ 3-juges |
|---|---|---|
| F1 (clean) | 0,66 | 0,97 |
| AUC-ROC (clean) | 0,89 | 0,998 |
| Détection sous évasion par gradient ε=0,02 | 23,7 % | 94,1 % |
| Détection sous attaque de transfert | 31,4 % | 89,6 % |
| AUC-ROC (hors-distribution) | 0,71 | 0,87 |
Partie 9 — Comparaison aux catégories adjacentes
Ward³ vise à réunir EDR, NDR et XDR dans une plateforme de niveau ANM. Les surfaces que ces catégories traitent souvent séparément — endpoint, réseau, corrélation multi-tenant — convergent sous un médiateur commun, avec un ledger d'audit et une gouvernance partagés.
La différence ne tient pas seulement à la couverture fonctionnelle. Elle tient aux garanties : juges architecturalement distincts, divergence utilisée comme signal de sécurité, entraînement adversariel documenté, vérification d'intégrité des modèles du build au runtime, et ledger inviolable pour chaque décision.
Partie 10 — Considérations d'adoption
L'adoption peut se faire par paliers. Une équipe peut commencer par une surface, souvent le réseau, valider les garanties ANM sur un scénario red-team adversariel, puis étendre progressivement aux autres surfaces à mesure que les contrats historiques arrivent à renouvellement. Ward³ se déploie comme capteur et enforcer natif Kubernetes, ou en mode standalone Linux, avec métriques Prometheus, dashboards Grafana, tracing OpenTelemetry et attestation Sigstore.
La gouvernance est explicite. Le War Mode à 4 yeux encadre les blocages à haut impact. Le quorum basé sur le secret sharing de Shamir protège le matériel cryptographique. Les primitives post-quantiques alignées NIST couvrent le ledger d'audit et les signatures de quorum.
Le multi-tenant MSSP est prévu dès le départ. Les seuils par famille, les poids des juges et les opt-ins de paliers se règlent par tenant. La charge compute suit les fonctionnalités activées, pas le simple nombre de juges déclarés.
Conclusion
Le NDR mono-modèle ne suffit plus pour les environnements où le ML devient lui-même une cible. Le problème n'est pas un simple réglage de seuil, et il ne disparaît pas en ajoutant un autre autoencodeur du même type.
ANM propose une réponse concrète : plusieurs juges architecturalement distincts, la divergence comme signal de sécurité, de l'entraînement adversariel, une chaîne d'intégrité des modèles et des décisions auditables. Ward³ montre comment assembler ces garanties dans une implémentation cohérente.
Si vous êtes responsable de la défense réseau d'une organisation à fort enjeu, la question importante n'est plus seulement de savoir si un attaquant viendra tester votre ML. C'est de savoir ce qui le détecte quand un modèle se trompe.