Threat modeling d'une application IA : STRIDE adapté aux LLM

Le threat modeling est la pratique qui transforme une intuition de risque en liste exploitable de menaces, mitigations et priorités. Pour une application LLM en 2026, STRIDE classique (Microsoft, 1999) ne suffit pas, il a été conçu pour des applications déterministes sans le modèle de menace particulier des LLM (prompt injection, model extraction, DoW, blind trust). Cet article documente une adaptation de STRIDE pour LLM : méthodologie 5 phases (scope → DFD → trust boundaries → STRIDE-PMCB analyse → DREAD priorisation), 4 catégories ajoutées à STRIDE classique (P/M/C/B), mapping avec MITRE ATLAS et OWASP LLM Top 10, exemples concrets sur 2 cas (chatbot SAV et agent IA avec tools), priorisation DREAD adaptée. Cible : architectes sécurité / AppSec / AI engineers structurant la sécurité d'une app IA, RSSI demandant un threat model formel pour conformité (EU AI Act annex III, NIST AI RMF).

Pour la matrice d'attaques de référence : MITRE ATLAS : matrice d'attaques sur systèmes IA. Pour le référentiel vulnérabilités : audit IA générative avec OWASP LLM Top 10.

Pourquoi STRIDE classique ne suffit pas pour les LLM

Rappel STRIDE

STRIDE (1999, Microsoft) couvre 6 classes :

Méthodologie : pour chaque élément du DFD (process, data store, data flow), pour chaque classe STRIDE → identifier menaces.

Les 3 spécificités LLM non couvertes

1. Le modèle est un actif attaquable

STRIDE pense en termes de processus déterministes. Un LLM est un processus stochastique manipulable par son input. Prompt injection n'est pas du Tampering classique (l'input est légitime, c'est l'interprétation qui est détournée).

2. Frontière input/instruction floue

Dans une app classique : input utilisateur ≠ code applicatif. Trust boundary nette. Dans un LLM : input utilisateur + contenu RAG + image OCR-isée se concatènent et sont interprétés comme instructions. Boundary brouillée, STRIDE ne modélise pas cette confusion.

3. Coût asymétrique direct ($ DoW)

DoS classique = saturation infra (CPU, mémoire, bande passante). DoW LLM = coût $ direct facturé. C'est une classe distincte : un attaquant qui inflige 9000 € de coût n'a pas saturé une ressource technique, il a brûlé un budget.

→ Besoin d'extension.

Approches d'extension 2024-2026

Cet article propose STRIDE-PMCB, extension pragmatique adoptable immédiatement.

STRIDE-PMCB : 4 catégories ajoutées

(P) Prompt Injection / Manipulation

Définition : input adversarial qui détourne les instructions du modèle.

Sous-classes :

• Direct : utilisateur tape l'attaque
• Indirect : payload arrive via RAG, image, email, web
• Multi-turn : escalade progressive (Crescendo)

Mapping :

• ATLAS : AML.T0051 LLM Prompt Injection
• OWASP : LLM01 Prompt Injection

Cibles DFD : tout process LLM, tout data flow vers le LLM.

(M) Model Extraction / Theft

Définition : exfiltration des capacités, du training data, ou des paramètres du modèle.

Sous-classes :

• Membership inference (Shokri et al. 2017) : détecter si une donnée était dans training set
• Model extraction : reconstruire un modèle équivalent par interrogation massive
• Weights theft : exfiltration directe des poids (RCE, supply chain)

Mapping :

• ATLAS : AML.T0024 ML Model Extraction, AML.T0044 Membership Inference
• OWASP : LLM10 Unbounded Consumption (lié)

Cibles DFD : modèle, API endpoint, weights storage.

(C) Cost / Resource Exhaustion

Définition : épuisement budget $ ou ressources spécifique LLM, distinct du DoS classique.

Sous-classes :

• DoW direct (volume requêtes coûteuses)
• Recursive tool calling (amplification interne)
• Context window abuse (prompts max-size systématiques)

Mapping :

• ATLAS : AML.T0034 Cost Harvesting
• OWASP : LLM10 Unbounded Consumption

Cibles DFD : LLM provider API, agent process, tool calls.

(B) Blind Trust (over-reliance)

Définition : confiance excessive aux outputs LLM dans le pipeline applicatif. Couvre les classes "fiabilité" qui se transforment en sécurité.

Sous-classes :

• Hallucinations exploitables (Air Canada, Mata v. Avianca)
• Slopsquatting (recommandation packages inexistants)
• Code completion qui inclut backdoor
• Output exécuté/rendu sans validation (XSS, SQLi via output)

Mapping :

• ATLAS : AML.T0048 LLM Output Manipulation
• OWASP : LLM05 Improper Output Handling, LLM09 Misinformation

Cibles DFD : output du LLM, processes consommant l'output (front, autres systems).

Méthodologie 5 phases

Phase 1, Scope

Définir précisément :

• Système à modéliser : nom, version, owners
• Frontières : ce qui est in-scope / out-of-scope (rare-t-on aussi le LLM provider lui-même ? le réseau corporate ?)
• Cas d'usage primaires : chatbot SAV ? agent IA avec tools ? RAG enterprise ?
• Acteurs : utilisateurs, admins, dev, attaquants potentiels (interne / externe / supply chain)
• Données sensibles : PII, secrets, IP, données clients

Phase 2, Data Flow Diagram (DFD)

Élaborer DFD niveau 1 (vue d'ensemble) puis niveau 2 (zoom sur composants critiques).

Légende standard :

□  External entity (user, attaquant, third-party)
○  Process (service, endpoint, function)
═  Data store (DB, vector DB, file storage)
→  Data flow (request, message, file)
┄┄┄ Trust boundary (zone de confiance)

Exemple niveau 1, Chatbot SAV avec RAG :

                          ┄┄┄┄┄┄┄┄┄ Internet/Edge ┄┄┄┄┄┄┄
   □ User                                                  
        │                                                  
        ▼                                                  
   ○ Frontend (React)                                      
        │                                                  
        ▼                                                  
   ┄┄┄┄┄┄┄┄┄┄┄┄┄ Frontend/Backend ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
        │                                                  
        ▼                                                  
   ○ API Gateway ──► ○ Auth service ──► ═ User DB         
        │                                                  
        ▼                                                  
   ○ Chat App                                              
        ├─► ○ Guardrail (input)                            
        ├─► ═ RAG Vector Store                             
        ├─► ○ Conversation Memory                          
        └─► ┄┄┄┄┄ External LLM Boundary ┄┄┄┄┄┄              
             │                                              
             ▼                                              
        ○ LLM Provider (OpenAI / Anthropic) □ External    
             │                                              
        ┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄
             ▼                                              
        ○ Guardrail (output)                                
             │                                              
             ▼                                              
        ═ Logs / Observability                              

Phase 3, Trust boundaries

Identifier explicitement les zones de confiance :

Règle : tout data flow qui traverse une trust boundary mérite un examen STRIDE-PMCB systématique.

Phase 4, Analyse STRIDE-PMCB par élément

Pour chaque élément du DFD, parcourir les 10 catégories (STRIDE + PMCB) et lister menaces.

Exemple ciblé sur LLM Provider :

10 menaces identifiées rien que sur un seul élément. Le DFD complet d'une app moyenne génère 50-200 menaces brutes, d'où l'importance de la phase 5 (priorisation).

Phase 5, Priorisation DREAD

Pour chaque menace : score DREAD adapté.

def dread_score(threat: dict) -> dict:
    # Chaque dimension scorée 1-10
    d = threat["damage"]          # impact $ + reputation + breach
    r = threat["reproducibility"] # facilité reproduction (HackAPrompt baisse cette barre)
    e = threat["exploitability"]  # compétences/ressources requises
    a = threat["affected_users"]  # nombre/type users impactés
    di = threat["discoverability"]
    
    score = (d + r + e + a + di) / 5
    
    if score >= 7:
        priority = "critical"
    elif score >= 5:
        priority = "high"
    elif score >= 3:
        priority = "medium"
    else:
        priority = "low"
    
    return {"score": round(score, 1), "priority": priority}

Output : threat list rangée par score. Garder top 10-30 pour mitigation roadmap.

Exemple complet, chatbot SAV avec RAG

Phase 1, Scope

• Système : ChatBot SAV ZerodaySupport v2.1
• In-scope : front, API, app middleware, RAG store, OpenAI provider
• Out-of-scope : OpenAI infrastructure interne, LAN corporate
• Cas d'usage : réponses commandes/retours/livraison
• Acteurs : clients, admins SAV, attaquants externes, employés malveillants
• Données : PII clients, infos commandes, codes promo internes (ne devraient pas être dans RAG mais c'est à vérifier)

Phase 2-3, DFD + boundaries

Cf section précédente.

Phase 4, Top 10 menaces identifiées

Phase 5, Priorisation

#1 Direct prompt injection, DREAD 7.4, CRITICAL
#2 Indirect injection RAG, DREAD 7.0, CRITICAL
#3 DoW context abuse, DREAD 6.8, HIGH
#5 XSS output, DREAD 6.6, HIGH
#9 Cross-tenant RAG, DREAD 6.4, HIGH
#7 Cross-user memory, DREAD 5.8, HIGH
#10 Credential stuffing → DoW, DREAD 5.6, HIGH
#6 API key compromise, DREAD 5.2, HIGH
#8 PII en clair logs, DREAD 4.8, MEDIUM
#4 Model extraction, DREAD 4.0, MEDIUM

→ Roadmap mitigation : adresser top 7 critical/high en 3 sprints, medium en planning trimestre suivant.

Exemple complémentaire, agent IA avec tools

Pour un agent IA (Copilot-like, custom LangChain) avec accès à outils sensibles (mail, drive, code commit) :

Trust boundaries spécifiques

┄┄┄┄┄ Agent boundary ┄┄┄┄┄
   ↑
   ├── User prompts (untrusted)
   ├── Tool results (untrusted, peuvent être manipulés)
   ├── Memory inter-session (untrusted si shared)
   ├── RAG documents (untrusted)
   └── External web fetched (untrusted)
   ↓
   ► Tool : send_email (high impact, external)
   ► Tool : commit_code (high impact, repo)
   ► Tool : delete_file (high impact, irreversible)
   ► Tool : search_docs (low impact, read)

Menaces additionnelles spécifiques

→ Threat model agent 2× plus dense qu'un chatbot simple. À refaire spécifiquement quand on passe d'app statique à agent.

Mapping STRIDE-PMCB ↔ ATLAS ↔ OWASP

Tableau de correspondance pour aligner les référentiels :

Threat library : tenir une base avec ces correspondances + status mitigation. Format Notion ou tableau Excel, devient l'asset le plus précieux de l'équipe sécurité IA.

Cadence et déclencheurs

Cinq déclencheurs pour refaire le threat model

Format workshop

• Participants : 1 architecte sécurité, 1-2 AI engineers, 1 AppSec, 1 product owner.
• Durée : 2-4h initial, 1-2h refresh.
• Output : DFD à jour + threat library updated + mitigation roadmap.
• Outils : Microsoft Threat Modeling Tool (Windows), OWASP Threat Dragon (multi-platform), draw.io, IriusRisk.

Outils logiciels

Microsoft Threat Modeling Tool

• Gratuit, Windows uniquement
• DFD éditeur avec stencils STRIDE
• Auto-génération de menaces basée sur règles
• Export Word / Excel

OWASP Threat Dragon

• Open-source, multi-platform
• Web ou desktop
• DFD éditeur
• Threat library customisable
• Plus simple que Microsoft Threat Modeling Tool

IriusRisk

• Commercial
• Threat library extensive incluant LLM
• Workflow gestion mitigations
• Intégration Jira / Azure DevOps

Pour LLM spécifiquement (2026)

• Pas encore d'outil dédié mature
• Approche pragmatique : OWASP Threat Dragon + threat library custom STRIDE-PMCB en Notion/Confluence
• Veille : projets émergents 2025-2026 (MAESTRO tooling, AI Threat Modeling Toolkit)

Erreurs récurrentes

Erreur 1, Threat model fait une fois puis oublié

À 18 mois, c'est de la fiction. Cadence annuelle minimum + déclencheurs.

Erreur 2, DFD trop détaillé d'emblée

100 éléments → ingérable. Commencer niveau 1 (vue d'ensemble) puis zoom progressif.

Erreur 3, STRIDE classique only

Manque les 4 catégories LLM. Adopter STRIDE-PMCB systématiquement.

Erreur 4, Pas de priorisation

Liste de 200 menaces sans score → backlog mort. DREAD ou matrice 2D obligatoire.

Erreur 5, Mapping ATLAS/OWASP absent

Threat parle un langage seulement → silos. Mapping triple obligatoire pour collab cross-équipes.

Erreur 6, Pas de propriétaire de la threat library

Document orphelin. Owner explicite (architecte sécurité IA) qui maintient.

Erreur 7, Output non actionable

Threat list sans roadmap mitigation. Top 10 → tickets Jira → sprints.

Ce que ça change pour votre dispositif

Un threat model LLM mature 2026 :

• STRIDE-PMCB systématiquement (10 catégories pour chaque élément DFD)
• DFD + trust boundaries documentés et maintenus
• Priorisation DREAD ou matrice 2D
• Mapping ATLAS + OWASP pour collab cross-équipes
• Cadence + déclencheurs définis
• Threat library vivante avec owner
• Output actionable : roadmap mitigation top 10 en backlog

C'est le pivot méthodologique qui transforme une démarche sécurité IA opportuniste en démarche structurée. Sans threat model formel, on patch des incidents au fil de l'eau. Avec, on conçoit défensivement.

ROI : 1-2 jours-homme initiaux, 2-4h/trimestre en routine. Bénéfice : alignement équipes, conformité (EU AI Act + NIST AI RMF demandent threat assessment), réduction incidents non anticipés de l'ordre de 30-50% sur 12 mois.

Pour aller plus loin : la suite naturelle est l'architecture sécurisée pour déployer un LLM on-premise, où le threat model identifié se traduit en choix d'infra concrets : VPC isolé, KMS, observabilité, hardware sécurisé. À découvrir dans le prochain article du cluster.