AuditBench : les LLM enquêteurs d'attaques sont des machines à faux positifs

De quoi s’agit-il ?

Les éditeurs de sécurité présentent volontiers les LLM comme des analystes SOC infatigables, capables de lire des logs et d’y détecter des intrusions. AuditBench, un papier de benchmark soumis sur arXiv le 9 juin 2026 (arXiv:2606.10281, Anand, Hou, Fields, Kantchelian, Tao, Thomas et Ho), est l’une des premières tentatives systématiques de vérifier si cette promesse résiste au contact de vrais logs d’audit. Les auteurs ont construit un jeu de données étiqueté de logs système Linux et Windows couvrant plus de 50 scénarios d’investigation — malveillants comme bénins — et noté cinq LLM de pointe sur quatre tâches que les équipes de réponse à incident effectuent réellement : le triage d’alertes (classification d’attaques), puis l’identification des mouvements latéraux, des mécanismes de persistance et de l’exfiltration de données.

Comment ça fonctionne

Le benchmark combine deux sources de données. Une partie « laboratoire » contient 25 scénarios exécutés sur machines virtuelles, avec des techniques d’attaque tirées de MITRE ATT&CK et implémentées via le framework Atomic Red Team. Une seconde partie dérive 16 scénarios d’attaque du jeu de données OpTC de la DARPA. Chaque scénario dispose de labels de vérité terrain vérifiés manuellement, ce qui permet au pipeline d’évaluation de calculer taux de vrais positifs, taux de faux positifs et F1 par tâche.

Deux choix de conception intéressent les praticiens. D’abord, les logs sont fournis au modèle sous deux représentations : la sortie brute des collecteurs natifs comme auditd sous Linux, ou une représentation en arêtes pré-traitée, construite à partir d’un graphe de provenance. Ensuite, les modèles évalués se répartissent en grands (GPT-5, Gemini 2.5 Pro) et petits (GPT-5 mini, Gemini 2.5 Flash, Llama 4 Maverick), ce qui permet de tester directement si la taille achète la compétence d’investigation.

Pourquoi c’est important

Le résultat principal est sans appel : les performances sont inégales sur l’ensemble des tâches, avec une forte tendance aux verdicts trop soupçonneux — les modèles classent des activités bénignes comme malveillantes, reproduisant précisément le déluge de faux positifs qui noie déjà les équipes SOC. Un assistant qui amplifie la fatigue d’alerte n’est pas neutre : les faux positifs constituent une surface d’attaque opérationnelle connue, et des travaux récents sur la capacité de supervision montrent que les analystes se dégradent vite sous le volume.

Ensuite, aucun modèle ne domine strictement, et — contrairement aux attentes liées au passage à l’échelle — le meilleur petit modèle égale ou bat fréquemment le meilleur grand modèle. Sur la représentation en arêtes, les petits modèles atteignent un F1 de 1,00 contre 0,77 pour les grands en classification, et 0,80 contre 0,57 en persistance ; les grands ne conservent l’avantage que sur l’exfiltration (0,77 contre 0,56). La représentation des données et la construction du prompt influencent autant les résultats que le choix du modèle.

Enfin, le papier évalue la qualité des explications via un juge d’implication textuelle (NLI) : même lorsque le verdict est correct, le raisonnement avancé par le modèle n’est pas toujours étayé par les logs — un risque réel quand les analystes recopient des narratifs LLM dans leurs rapports d’incident.

Défenses

Pour les équipes qui déploient de l’investigation assistée par LLM, les constats d’AuditBench se traduisent en garde-fous concrets :

• Traitez les verdicts LLM comme des suggestions de triage, jamais comme des conclusions définitives. Gardez un analyste humain comme autorité sur les décisions de clôture, et budgétez le biais de faux positifs.
• Investissez dans la représentation des données avant la taille du modèle. Un pré-traitement en graphe de provenance a davantage changé les résultats qu’un passage à un modèle plus grand — et permet à des modèles moins coûteux de faire le travail.
• Vérifiez les explications, pas seulement les verdicts. Exigez que toute preuve citée par le LLM (noms de processus, lignes de log, horodatages) soit contrôlée mécaniquement contre les logs réels avant d’entrer dans un rapport.
• Benchmarkez sur votre propre télémétrie. Les profils d’erreur varient fortement par tâche ; un modèle fort en persistance peut être faible en exfiltration. Construisez un petit jeu de scénarios étiquetés (Atomic Red Team rend cela peu coûteux) et mesurez avant de faire confiance.
• Durcissez le pipeline de logs lui-même. Un LLM qui lit des logs est aussi une cible d’injection de prompt — des chaînes contrôlées par l’attaquant dans des arguments de processus ou des noms de fichiers arrivent directement dans le contexte du modèle.

État des lieux

Élément	Détail
Papier	arXiv:2606.10281, soumis le 9 juin 2026
Périmètre	4 tâches IR, 50+ scénarios, Linux + Windows
Modèles testés	GPT-5, Gemini 2.5 Pro, GPT-5 mini, Gemini 2.5 Flash, Llama 4 Maverick
Constat clé	Performances inégales, biais de faux positifs ; petits modèles compétitifs
Travaux antérieurs	ExCyTIn-Bench (arXiv:2507.14201) pour les agents d’investigation