Cyber Defense Benchmark : les LLM de pointe échouent au threat hunting

De quoi s’agit-il ?

Un argument récurrent dans l’outillage de sécurité est celui de l’analyste SOC autonome : pointez un agent LLM vers vos logs et laissez-le chasser. Un nouveau benchmark teste cette promesse de front — et le résultat est sans appel.

Le 21 avril 2026 (dernière révision le 23 avril 2026), Alankrit Chona, Igor Kozlov et Ambuj Kumar ont publié Cyber Defense Benchmark: Agentic Threat Hunting Evaluation for LLMs in SecOps (arXiv:2604.19533). Le papier mesure la capacité des agents LLM à accomplir la tâche centrale du SOC, le threat hunting : à partir d’une base de logs Windows bruts, sans question guidée ni indice, retrouver les horodatages exacts des événements malveillants.

C’est nettement plus dur que les QCM de sécurité préparés sur lesquels les LLM brillent déjà. Il n’y a pas de question à laquelle répondre — seulement une botte de foin et la consigne d’y trouver les aiguilles. Sur cinq modèles de pointe, tous ont échoué lourdement.

Comment ça marche

Le benchmark enveloppe 106 procédures d’attaque réelles issues du corpus open source OTRF Security-Datasets — couvrant 86 sous-techniques MITRE ATT&CK réparties sur 12 tactiques — dans un environnement d’apprentissage par renforcement.

Chaque épisode se déroule ainsi, selon le papier :

1. Un simulateur de campagne déterministe rejoue une vraie attaque,
   en décalant les horodatages et en masquant les noms d'entités pour
   que l'agent ne puisse pas mémoriser l'enregistrement public.
2. L'agent reçoit une base SQLite en mémoire de
   75 000 à 135 000 enregistrements (bruit de fond surtout bénin).
3. L'agent soumet itérativement des requêtes SQL pour enquêter,
   puis signale explicitement les horodatages qu'il juge malveillants.
4. Les signalements sont notés façon CTF contre une vérité terrain
   dérivée de règles de détection Sigma.

Utiliser des règles Sigma — un format de détection agnostique du SIEM, mappé sur ATT&CK — comme vérité terrain signifie que l’agent est noté face à ce qu’un ingénieur détection compétent signalerait réellement, et non face à une clé synthétique.

Les modèles testés étaient Claude Opus 4.6, GPT-5, Gemini 3.1 Pro, Kimi K2.5 et Gemini 3 Flash, sur 26 campagnes couvrant 105 des 106 procédures.

Pourquoi c’est important

Les chiffres sont brutaux. Le meilleur modèle, Claude Opus 4.6, a soumis des signalements corrects pour seulement 3,8 % des événements malveillants en moyenne. Aucun run, quel que soit le modèle, n’a jamais trouvé tous les signalements d’un épisode.

Les auteurs définissent un seuil de déploiement raisonnable : ≥ 50 % de rappel sur chaque tactique ATT&CK — le minimum avant de laisser un agent chasser sans supervision. Aucun modèle ne le franchit. Le leader l’a atteint sur 5 tactiques sur 13 ; les quatre autres modèles sur zéro.

L’écart qui compte est celui entre ce résultat et les benchmarks soignés que citent les éditeurs. Les LLM paraissent solides sur des QCM de sécurité riches en indices. Plongez les mêmes modèles dans une chasse ouverte et factuelle au sein de logs bruyants, et la performance s’effondre. La compétence mesurée ici — pivoter patiemment et itérativement à travers un grand corpus pour assembler des signaux faibles en une découverte confirmée — est exactement ce que fait un analyste SOC, et exactement ce que les benchmarks préparés ne capturent pas.

Pour quiconque évalue un produit de « threat hunting par IA », c’est une raison concrète d’exiger une évaluation sur des tâches ouvertes, pas sur des QCM de classement.

Défenses

Il s’agit d’un constat de maturité défensive ; la « défense » consiste donc à déployer les LLM dans un SOC sans leur accorder une confiance excessive.

1. Ne lancez pas de chasse autonome sans supervision. Au vu de ces résultats, un agent LLM laissé seul pour trouver des événements malveillants en manquera la grande majorité. Gardez un analyste humain dans la boucle pour toute chasse qui conditionne une réponse.
2. Utilisez les LLM là où ils sont réellement forts. Résumer une alerte, rédiger une requête, expliquer une règle Sigma, trier un événement déjà détecté — des tâches étroites et bornées — n’ont rien à voir avec la découverte ouverte. Cadrez l’outil sur ces usages.
3. Évaluez sur vos propres tâches ouvertes. La précision annoncée par un éditeur sur des QCM ne dit presque rien de la chasse. Rejouez de vraies données d’attaque (le corpus OTRF est public) et mesurez le rappel par tactique ATT&CK avant de faire confiance à un agent.
4. Traitez le rappel, pas la précision, comme métrique de sûreté. Un chasseur qui manque 96 % des événements est dangereux même si tout ce qu’il signale est correct. Mesurez ce qu’il a échoué à trouver.
5. Posez une détection déterministe en dessous. Les règles Sigma et la détection à signatures ont capté ces événements par construction. Les agents LLM devraient se poser au-dessus d’une ingénierie de détection fiable, pas la remplacer.

Ces points renforcent la mise en garde plus large de la saison : benchmarker des agents de sécurité est difficile et un chiffre unique masque le point de fonctionnement auquel vous opérerez réellement.

Statut

Élément	Référence	Date	Notes
Cyber Defense Benchmark	arXiv:2604.19533	2026-04-21 (v1) → 2026-04-23 (v3)	106 procédures, 86 sous-techniques ATT&CK, 12 tactiques
Meilleur résultat	Claude Opus 4.6	2026	3,8 % des événements signalés ; passe 5/13 tactiques
Autres modèles	GPT-5, Gemini 3.1 Pro, Kimi K2.5, Gemini 3 Flash	2026	Franchissent le seuil sur zéro tactique
Vérité terrain	OTRF Security-Datasets + règles Sigma	en cours	Corpus public ; résultats reproductibles

À retenir : les LLM ne sont pas inutiles dans un SOC — mais le threat hunting ouvert n’est pas encore une tâche que l’on peut déléguer. Mesurez-le avant de lui faire confiance.