Where Do LLM-based Systems Break? A System-Level Security Framework for Risk Assessment and Treatment

Cette étude propose un cadre d'évaluation des risques axé sur les objectifs pour les systèmes alimentés par des modèles de langage, combinant la modélisation système et l'analyse des arbres d'attaque-défense pour identifier des points de défaillance critiques et optimiser les stratégies de défense dans des contextes critiques comme la santé.

L'essentiel

Imaginez que vous construisez un médecin robotique ultra-intelligent capable de lire des dossiers médicaux, de répondre aux patients et de conseiller les chirurgiens. C'est ce qu'on appelle un système basé sur un "Grand Modèle de Langage" (LLM).

Le problème, c'est que ce robot est connecté à tout : aux dossiers des patients, aux outils de traduction, aux bases de données, et il parle aux humains. Si quelqu'un trouve une faille, il ne s'agit pas seulement de voler un mot de passe, mais de tromper le robot pour qu'il donne de mauvais conseils médicaux, vole des données privées ou arrête de fonctionner.

Ce papier propose une nouvelle méthode pour cartographier les dangers avant même que le robot ne soit complètement construit. Voici comment cela fonctionne, expliqué simplement :

1. Le Problème : On regarde trop les détails, pas le tout

Jusqu'à présent, les experts en sécurité regardaient le robot comme un objet isolé. Ils se demandaient : "Peut-on pirater le code ?" ou "Peut-on tromper le robot avec une phrase bizarre ?".
Mais dans la réalité, le robot est comme un chef d'orchestre. Si le violoniste (le robot) joue faux, c'est peut-être parce que le chef d'orchestre (le système) a mal lu la partition, ou parce que quelqu'un a volé la partition (les données), ou parce que le public (les utilisateurs) a lancé des tomates.

Les chercheurs disent : "Il faut arrêter de regarder juste la note de musique, il faut regarder tout le concert pour voir comment le chaos peut se propager."

2. La Solution : L'Arbre de l'Attaque et de la Défense (ADTree)

Pour visualiser cela, les auteurs utilisent une sorte de carte au trésor inversée.

• L'objectif du pirate (Le Trésor) : C'est le but final, par exemple : "Faire donner une mauvaise ordonnance" ou "Voler le dossier de Monsieur Dupont".
• Les chemins (Les Sentiers) : Pour atteindre ce trésor, le pirate doit suivre un chemin. Ce chemin a deux étapes :
  1. Les Prérequis (Le "Comment entrer") : Il faut d'abord voler un badge, ou pirater un ordinateur, ou convaincre un employé.
  2. L'Exécution (Le "Coup final") : Une fois à l'intérieur, il envoie le message malveillant ou vole les données.

L'outil permet de dessiner tous ces chemins possibles et de voir où ils se croisent. Souvent, plusieurs chemins différents passent par le même "goulot d'étranglement" (comme une porte mal verrouillée).

3. La Mesure : Le "Score de Facilité" (CVSS)

Comment savoir quel chemin est le plus dangereux ? Les auteurs utilisent un système de notation déjà existant dans le monde de la sécurité informatique, appelé CVSS, qu'ils adaptent pour les robots.

Imaginez que chaque étape du chemin du pirate a un score de difficulté :

• Est-ce que le pirate doit être physiquement présent ? (Difficile)
• Est-ce qu'il a besoin d'un mot de passe d'administrateur ? (Difficile)
• Est-ce qu'il doit attendre que quelqu'un clique sur un lien ? (Moyen)
• Est-ce qu'il peut le faire à distance en 2 secondes ? (Très facile)

En additionnant ces scores le long du chemin, ils obtiennent un score de risque global. Plus le score est bas, plus c'est facile pour le pirate. Plus il est haut, plus c'est difficile.

4. L'Expérience : Le Cas du Médecin Robot

Ils ont testé leur méthode sur un scénario de santé avec trois objectifs de sécurité :

1. G1 : Manipuler un traitement médical (Le robot dit "prenez ce poison" au lieu de "prenez ce médicament").
2. G2 : Voler des données (Le robot révèle le dossier secret d'un patient).
3. G3 : Couper le courant (Le robot refuse de répondre, bloquant les urgences).

Ce qu'ils ont découvert :

• Beaucoup de chemins d'attaque différents finissent par passer par les mêmes faiblesses (comme un système de session mal protégé ou une API mal sécurisée).
• En renforçant un seul point fort (par exemple, exiger une double authentification), on bloque plusieurs chemins d'attaque à la fois. C'est comme renforcer la porte principale d'une maison : cela protège contre le cambrioleur par la fenêtre, celui par la cheminée et celui par la porte d'entrée.

5. Le Budget : Combien ça coûte pour se protéger ?

Le papier ne dit pas juste "il faut se protéger". Il compare les solutions selon leur coût (en temps, en argent, en complexité).

• Option A (Pas cher) : Changer une configuration logicielle.
• Option B (Cher) : Changer toute l'architecture du réseau et installer de nouveaux matériels.

Ils montrent que parfois, une solution simple et peu coûteuse (comme ajouter une vérification humaine pour les décisions critiques) est plus efficace qu'une solution complexe et coûteuse.

En Résumé

Ce papier est comme un guide de construction pour des bâtiments anti-pirates.
Au lieu de dire "Attention, il y a des voleurs", il dit : "Voici exactement comment un voleur pourrait entrer, par quelle porte, et combien de temps cela lui prendra. Si vous renforcez cette fenêtre spécifique, vous bloquez 80% des tentatives de vol pour un coût minime."

C'est une méthode pour passer de la peur vague ("Les IA sont dangereuses") à l'action précise ("Voici ce que nous devons réparer demain matin").

Résumé technique

Voici un résumé technique détaillé de l'article « Where Do LLM-based Systems Break? A System-Level Security Framework for Risk Assessment and Treatment », rédigé en français.

1. Problématique

Les Grands Modèles de Langage (LLM) sont de plus en plus intégrés dans des workflows critiques pour la sécurité, notamment dans le secteur de la santé (assistants médicaux, résumés de dossiers électroniques, aide à la décision clinique). Cependant, les analyses de sécurité existantes souffrent de plusieurs lacunes majeures :

• Fragmentation : Elles se concentrent souvent sur des menaces isolées (ex. : injections de prompts, jailbreaks) sans les relier au contexte système global.
• Absence de vision systémique : Elles ne modélisent pas comment les menaces conventionnelles (cyber), les menaces adversariales (ML) et les menaces conversationnelles interagissent pour former des chemins d'attaque complets.
• Manque de priorisation : Les méthodes actuelles peinent à quantifier la faisabilité des chemins d'attaque multi-étapes et à comparer l'efficacité des défenses sous contraintes budgétaires.

L'objectif de ce travail est de combler ce vide en proposant un cadre d'évaluation des risques axé sur les chemins d'attaque (attack-path-centric) pour les systèmes orchestrés par des LLM, permettant une analyse structurée et comparable.

2. Méthodologie

Les auteurs proposent un flux de travail de risque en trois étapes, appliqué à un cas d'usage de santé (assistant médical LLM orchestrant des outils externes et des données EHR) :

A. Modélisation Système et Arbres d'Attaque-Défense (ADT)

• Approche : Au lieu de lister des menaces isolées, les auteurs construisent des Arbres d'Attaque-Défense (ADT) orientés vers des objectifs de sécurité spécifiques.
• Décomposition : Chaque chemin d'attaque est décomposé en trois couches sémantiques :
  1. Préconditions (P) : Ce que l'attaquant doit accomplir pour gagner un pied-à-terre (ex. : compromission de session, vol de clés API).
  2. Exécution (V) : L'action d'attaque active une fois les préconditions remplies (ex. : injection de prompt, manipulation de tâche).
  3. Impact : La réalisation de l'objectif de sécurité (ex. : fuite de données, interruption de service).
• Logique : Utilisation de connecteurs logiques (OR, AND, SAND) pour modéliser les dépendances séquentielles et les alternatives. Les défenses sont modélisées comme des nœuds augmentant la difficulté d'atteindre un objectif (en modifiant les métriques de CVSS).

B. Quantification via CVSS (Common Vulnerability Scoring System)

• Adaptation : Le framework utilise les vecteurs d'exploitabilité du CVSS v3.1 pour évaluer la faisabilité des nœuds feuilles (préconditions et exécution).
• Agrégation :
  • Les nœuds OR prennent le score maximum (l'attaquant choisit le chemin le plus facile).
  • Les nœuds AND prennent le score minimum (toutes les conditions doivent être remplies).
  • Traitement SAND (Séquentiel) : Une méthode spécifique est proposée pour propager la complexité d'attaque (AC) des préconditions vers l'étape d'exécution, évitant ainsi le double comptage des facteurs.
• Calcul du Score Final : L'exploitabilité est calculée le long du chemin, tandis que l'impact (Confidentialité, Intégrité, Disponibilité) est appliqué uniquement au nœud racine (l'objectif). Cela permet de séparer clairement « la difficulté de l'attaque » de « la gravité du résultat ».

C. Traitement des Risques et Comparaison des Défenses

• Scénarios Canoniques : Les auteurs évaluent quatre stratégies de durcissement :
  1. Durcissement des préconditions uniquement.
  2. Durcissement de toutes les préconditions.
  3. Durcissement de l'exécution uniquement (guardrails).
  4. Combinaison des deux.
• Modèle de Coût : Chaque contrôle de sécurité est assigné à un niveau de coût ordinal (1 à 4) basé sur l'effort d'ingénierie, l'empreinte infrastructurelle, la charge opérationnelle et l'impact sur l'expérience utilisateur (UX).
• Optimisation : Le framework permet de comparer les réductions d'exploitabilité ($\Delta E$) par rapport au coût, identifiant ainsi les goulots d'étranglement où les défenses sont les plus efficaces.

3. Contributions Clés

1. Modélisation orientée objectif : Une méthode unifiant les menaces conventionnelles, adversariales et conversationnelles dans un seul modèle système pour les LLM.
2. Scoring d'exploitabilité pour chemins multi-étapes : Une méthode novatrice pour mapper les vecteurs CVSS sur des arbres d'attaque, permettant de calculer un score de risque composé pour des attaques complexes.
3. Comparaison de portefeuilles de défense : Un flux de travail pratique pour évaluer les compromis coût/bénéfice des mesures de sécurité, applicable même en phase précoce du cycle de développement (SDLC) avec des connaissances partielles du système.

4. Résultats

L'application du framework au cas de santé a permis d'identifier trois objectifs de sécurité critiques :

• G1 (Intervention dans les procédures médicales) : Risque d'altération des diagnostics ou des traitements.
• G2 (Fuite de données EHR) : Risque de violation de confidentialité des patients.
• G3 (Perturbation de l'accès) : Risque de déni de service (DoS) ou de dégradation de la disponibilité.

Constats principaux :

• Concentration des risques : De nombreux chemins d'attaque convergent vers un nombre restreint de points de blocage (choke points) partagés, tels que l'authentification, la logique d'orchestration et les connecteurs d'outils.
• Scores CVSS : Les scores de base initiaux se concentrent souvent autour de 7,5 (Critique), reflétant la nature accessible et complexe des systèmes LLM. Cependant, la décomposition en sous-arbres révèle des vulnérabilités structurelles différentes (ex. : compromission de session vs. empoisonnement de cache).
• Efficacité des défenses : Le durcissement des préconditions (ex. : MFA, isolation de session) a souvent un impact plus significatif sur la réduction de l'exploitabilité globale que le durcissement de l'exécution seul, car il bloque l'accès au chemin d'attaque dès le départ. L'ajout de contrôles humains (HITL) pour les actions critiques offre une sécurité opérationnelle supplémentaire mais avec un coût élevé.

5. Signification et Impact

Ce travail est significatif car il opérationnalise la gestion des risques pour les systèmes LLM en les connectant aux pratiques éprouvées de gestion des vulnérabilités (CVSS).

• Langage commun : Il fournit un langage et un cadre communs pour les équipes de sécurité, de développement logiciel et de ML, qui ont souvent des visions fragmentées des risques.
• Pragmatisme : En se basant sur des données de vulnérabilités existantes (CVE) et en les adaptant aux LLM, il rend l'analyse de risque réalisable même avant le déploiement complet.
• Généricité : Bien que testé sur la santé, le framework est agnostique au domaine et peut être appliqué à d'autres infrastructures critiques utilisant des LLM.

En résumé, l'article démontre que la sécurité des systèmes LLM ne peut pas être traitée uniquement au niveau du modèle, mais doit être analysée au niveau du système complet, en identifiant les chemins d'attaque critiques et en priorisant les défenses basées sur leur capacité à briser ces chemins à un coût acceptable.