Résumé technique : Honeyval – Un cadre d'évaluation complet pour les leurres HTTP alimentés par des modèles de langage (LLM)

Énoncé du problème

Les leurres sont des systèmes leurres défensifs conçus pour imiter de vrais composants d'une pile logicielle afin de détecter, surveiller et étudier les attaquants. Bien que les leurres traditionnels à haute interaction offrent des simulations réalistes, ils reposent sur des ressources système réelles, exposant les défenseurs à des risques de sécurité importants. Récemment, les modèles de langage (LLM) sont apparus comme une solution pour simuler des interactions système avec une grande fidélité sans nécessiter l'accès à des ressources d'hôte vulnérables.

Cependant, le développement de leurres alimentés par des LLM manque d'un cadre d'évaluation unifié, évolutif et reproductible. Les méthodes d'évaluation actuelles souffrent de trois limitations principales :

1. Évolutivité : La dépendance aux tests manuels en laboratoire ou aux déploiements réels épars rend le développement itératif difficile.
2. Reproductibilité : Les évaluations manquent souvent de configurations système précises. Lorsque les LLM simulent des systèmes sous-spécifiés, ils génèrent des détails incohérents (par exemple, les états du système de fichiers) d'une exécution à l'autre, rendant les résultats incomparables.
3. Représentativité : Les comparaisons statiques de commandes et de résultats ou les interactions ouvertes ne parviennent pas à capturer des chaînes d'attaque réalistes ni à s'adapter à des objectifs adverses spécifiques.

Les évaluations existantes mesurent généralement la similarité des réponses par rapport à des commandes fixes, procèdent à des tests manuels ou déploient des systèmes en ligne. Ces méthodes ne traitent pas adéquatement la dynamique « chat et souris » où attaquants et défenseurs s'adaptent mutuellement.

Méthodologie : Le cadre Honeyval

Pour combler ces lacunes, les auteurs introduisent Honeyval, un cadre d'évaluation complet spécifiquement conçu pour les leurres HTTP alimentés par des LLM. Le cadre est fondé sur 16 configurations d'applications backend réalistes issues de BaxBench, un benchmark pour la sécurité des applications web générées par LLM.

Composants principaux

1. Environnements : Honeyval utilise 16 applications backend distinctes (par exemple, calculatrices, catalogues de produits, services de connexion) définies par des spécifications OpenAPI standardisées. Chaque application comprend :

   • Une implémentation sécurisée.
   • Une implémentation non sécurisée et exploitable.
   • Une suite de tests fonctionnels.
   • Un objectif d'exploitation défini (par exemple, télécharger un script, supprimer une table de base de données, modifier un mot de passe administrateur ou exfiltrer le stockage du navigateur).

2. Tâches d'évaluation : Le cadre emploie trois tâches distinctes pour assurer la robustesse et la comparabilité :

   • Tâche principale (Leurre vs Attaquant) : Un agent de piratage IA interagit directement avec le leurre alimenté par LLM. Le leurre simule l'API backend, tandis que l'agent tente d'atteindre l'objectif d'exploitation défini. Les métriques suivies incluent la longueur de l'interaction (nombre de requêtes), les coûts d'exécution, la latence et les taux de détection du leurre.
   • Tâche de contrôle de l'agent : L'agent de piratage interagit avec les implémentations réelles sécurisées et non sécurisées des applications backend. Cette tâche mesure la capacité de base de l'agent à exploiter les vulnérabilités et sa capacité à distinguer les systèmes réels des leurres (taux de faux positifs).
   • Tâche de contrôle du leurre : Le leurre est testé contre la suite de tests fonctionnels de l'application backend qu'il simule. Cela garantit que les réponses du LLM ont une haute fidélité fonctionnelle et ne sont pas facilement identifiables par des requêtes bénignes.

3. Agents et modèles :

   • Attaquants : Le cadre teste un agent ReAct personnalisé et des agents de codage de pointe (Claude Code, Gemini CLI).
   • Leurres : L'étude évalue cinq LLM rentables (Gemini 3 Flash, Claude Haiku 4.5, Gemini 2.5 Flash, Qwen 3.5 9B, GPT 5.4 Nano) agissant comme colonne vertébrale de la simulation.
   • Références : Un leurre à faible interaction basé sur des règles (API factice) sert de référence pour la comparaison.

4. Adaptabilité : Le cadre permet de tester des configurations de leurres personnalisées (par exemple, en demandant au LLM de tenter une injection de prompt ou de convaincre l'attaquant que le système est sécurisé) et des configurations d'agents (par exemple, en demandant aux agents de cacher leur intention).

Contributions clés

1. Formulation des exigences : Les auteurs identifient et formalisent quatre exigences clés pour l'évaluation des leurres LLM : Évolutivité, Reproductibilité, Représentativité et Adaptabilité.
2. Cadre Honeyval : Ils introduisent et rendent accessible le premier cadre d'évaluation complet pour les leurres HTTP alimentés par des LLM, comportant 16 environnements backend ancrés et une structure de tâche tripartite (Principale, Contrôle de l'agent, Contrôle du leurre).
3. Évaluation empirique extensive : L'article présente une évaluation à grande échelle de LLM rentables en tant que leurres face à des agents de piratage IA de pointe, analysant les dynamiques d'interaction, les asymétries de coûts et les taux de détection.

Résultats et analyse

Longueur de l'interaction et engagement

Les leurres alimentés par des LLM surpassent nettement les références basées sur des règles dans l'engagement des attaquants.

• Métrique : Longueur moyenne de l'interaction (requêtes par interaction).
• Résultat : Les leurres alimentés par des LLM ont maintenu des interactions pendant une moyenne de 82,6 requêtes, contre 30,6 requêtes pour les leurres basés sur des règles. Cela indique que les LLM peuvent maintenir l'illusion d'un système réel beaucoup plus longtemps, fournissant aux défenseurs davantage de données sur les tactiques des attaquants.

Détection

• Métrique : Taux de vrais positifs (TPR) de détection du leurre par les agents par rapport au taux de faux positifs (FPR) sur les applications réelles.
• Résultat : Alors que les leurres basés sur des règles étaient identifiés à des taux écrasants, les leurres alimentés par des LLM étaient nettement plus difficiles à détecter. Dans la plupart des cas, les taux de détection étaient bien inférieurs à 40 %. Notamment, même des modèles plus petits comme Qwen 3.5 9B ont bien performé. Cependant, les agents utilisant Gemini CLI ont montré des taux de détection élevés mais aussi des FPR élevés sur les applications réelles, suggérant un jugement peu fiable dans cette configuration spécifique.

Asymétrie des coûts

• Métrique : Avantage relatif des coûts d'exécution (Coût de l'agent / Coût du leurre).
• Résultat : Malgré l'utilisation d'une architecture naïve où le leurre traite chaque requête individuellement, les leurres alimentés par des LLM ont généralement maintenu un avantage de coût sur les agents attaquants. Cela suggère que même dans une configuration non optimisée, le défenseur peut soutenir l'interaction à un coût inférieur à celui que l'attaquant peut soutenir pour l'attaque.

Compromis entre latence et fidélité

• Latence : Une limitation clé identifiée est la latence de réponse. Même les modèles les plus rapides (Gemini 3 Flash) ont pris environ 3,3 secondes par réponse.
• Fidélité : Les modèles ont atteint une haute fidélité fonctionnelle (scores Pass@1 >70 % sur les suites de tests), mais cela s'est fait au prix d'une génération élevée de tokens (moyenne de 200 à 500+ tokens par réponse), ce qui augmente les coûts et la latence.
• Corrélation avec la détection : Bien que la latence ne soit pas strictement corrélée aux taux de détection sur tous les modèles, les agents ont souvent cité la latence de réponse et les dépassements de temps comme preuves pour classer une application comme un leurre.

Impact des instructions personnalisées

L'étude a exploré la modification des invites des leurres pour atteindre des objectifs contre-offensifs :

• Invite « Convaincre » : Demander au leurre d'affirmer que l'application est sécurisée a augmenté la longueur de l'interaction (moyenne de 102,6 requêtes) mais a également augmenté le taux de détection (TPR 0,45).
• Invite « PI prudente » (Injection de prompt) : Demander au leurre de tenter une injection de prompt a considérablement augmenté les taux de détection (TPR 0,49) et réduit la longueur de l'interaction, car les agents ont souvent détecté les tentatives d'injection. Cette configuration a également dégradé la fidélité fonctionnelle sur les suites de tests bénignes.

Importance et affirmations

L'article affirme que Honeyval fournit une base nécessaire, évolutive et reproductible pour le développement de leurres alimentés par des LLM. Les auteurs affirment que :

1. Les LLM sont des défenseurs prometteurs : Les leurres alimentés par des LLM offrent une alternative viable aux systèmes à haute interaction, fournissant des simulations de haute fidélité avec un risque de sécurité minimal et des coûts opérationnels inférieurs par rapport au coût de l'attaque.
2. L'évaluation est cruciale : Les compromis uniques observés (par exemple, des interactions plus longues contre un risque de détection plus élevé lors de l'utilisation d'invites contre-offensives) soulignent la nécessité des tâches de contrôle fournies par Honeyval pour surveiller les effets secondaires des changements de configuration.
3. Perspectives futures : Le travail suggère que, bien que les architectures naïves actuelles soient efficaces, les améliorations futures en matière de gestion du contexte (mise en cache, mémoire) et de matériel d'inférence pourraient encore améliorer les performances. Le cadre est conçu pour soutenir l'évolution des attaquants et des défenseurs automatisés.

Les auteurs concluent que, bien que les leurres alimentés par des LLM montrent une promesse claire, leur déploiement nécessite une configuration et une surveillance attentives, ce que Honeyval facilite. Le cadre est rendu accessible pour faire progresser les efforts de la communauté dans ce domaine.