Quand je commence un threat modeling sur une app IA, la première question est : on prend quel référentiel ? STRIDE est connu de toutes les équipes sécu mais conçu pour les apps "classiques". ATLAS est conçu pour l'IA mais n'a pas la structure top-down de STRIDE. Voilà comment je les combine.
Ce que fait chacun, en pratique
STRIDE
Cadre de Microsoft, 6 catégories de menaces :
- Spoofing — usurpation d'identité.
- Tampering — altération.
- Repudiation — répudiation d'action.
- Information disclosure — divulgation.
- Denial of service — déni de service.
- Elevation of privilege — élévation de privilèges.
On l'applique en posant : pour chaque composant et flux de données, quelles menaces STRIDE sont applicables ? C'est top-down, exhaustif, mais générique.
MITRE ATLAS
Catalogue de tactiques et techniques d'attaque sur les systèmes IA. Plus operationnel : il liste des techniques précises (Poison Training Data, Backdoor ML Model, LLM Prompt Injection, Extract ML Model) avec descriptions, exemples réels, mitigations.
On l'applique en posant : quelles techniques ATLAS sont applicables à mon architecture ?
Pourquoi STRIDE seul ne marche pas en IA
STRIDE pose des questions comme "y a-t-il un risque d'altération sur ce flux ?". Sur une app classique, ça suffit. Sur une app IA, des menaces critiques passent au travers :
- Prompt injection — c'est du Tampering, mais STRIDE ne dit pas qu'il faut tester ça en runtime.
- Data poisoning — Tampering aussi, mais STRIDE ne dit pas que la mitigation est provenance dataset + hash + tests.
- Model extraction — Information disclosure, mais STRIDE ne mentionne pas rate limiting + watermarking.
STRIDE est un cadre, ATLAS est un catalogue de menaces concrètes. Les deux se complètent.
Comment je structure une session threat modeling IA
Étape 1 — Diagramme du système (1-2h)
Diagramme de flux de données (DFD) qui inclut :
- Composants : utilisateur, frontend, backend, LLM provider, RAG / vector DB, feature store, modèles ML, tools / MCP servers, mémoire long-terme.
- Flux de données : requête utilisateur, contexte RAG, appel LLM, output, tool calls, écritures DB.
- Limites de confiance (trust boundaries) entre composants.
Tracer ce diagramme prend 1-2h avec l'équipe. C'est la base de tout.
Étape 2 — Pass STRIDE sur chaque composant (2-3h)
Pour chaque composant, je passe les 6 menaces. Exemple sur "backend agent" :
- S : qui peut s'authentifier comme agent ? (token leak ?)
- T : altération du system prompt ? Altération de la mémoire ? Altération de la config modèle ?
- R : audit log permet de prouver qui a déclenché quelle action ?
- I : fuite du contexte d'un utilisateur vers un autre ? Fuite du system prompt ?
- D : prompts qui font boucler ? Rate limiting ?
- E : prompt injection qui élève les privilèges ? Tool abuse ?
Étape 3 — Pass ATLAS sur les composants IA (1-2h)
Pour les composants spécifiquement IA (LLM, RAG, modèle ML, agents) :
- Quelles techniques ATLAS sont applicables ?
- Pour chacune, quel impact métier ?
- Quel contrôle est en place / manque ?
Étape 4 — Synthèse et priorisation (1h)
Pour chaque menace identifiée (STRIDE ou ATLAS) :
- Probabilité (Faible/Moyenne/Forte).
- Impact métier (Faible/Moyen/Critique).
- Contrôles existants.
- Recommandation (Accepter / Mitiger / Transférer / Éviter).
Le résultat fait 10-30 menaces priorisées, avec une roadmap remédiation.
Le mapping STRIDE ↔ ATLAS
Pour la défendabilité, je documente le mapping :
| STRIDE | Techniques ATLAS associées | |---|---| | Tampering | Poison Training Data, Backdoor ML Model, LLM Prompt Injection | | Information disclosure | Extract ML Model, ML Artifact Theft, LLM Sensitive Information Disclosure | | Denial of service | Spamming ML System, LLM Resource Exhaustion | | Elevation of privilege | LLM Plugin Compromise, System Misuse for External Effect | | Spoofing | Model Theft (variante : impersonation via clone) | | Repudiation | Erode ML Model Integrity (sans audit) |
Ce mapping rend la traçabilité explicite et facilite le reporting.
Les pièges classiques
Faire STRIDE sans diagramme à jour
Sans DFD précis, on rate des limites de confiance. Mettre 2h à faire le diagramme avant tout exercice.
Faire ATLAS comme une checklist sans contexte
Pas toutes les techniques sont applicables. Filtrer par architecture avant d'analyser, sinon vous passez 4h sur des menaces non pertinentes.
Confondre threat modeling et red teaming
Threat modeling = analyse statique des menaces possibles. Red teaming = tentatives réelles d'exploitation. Le premier produit la roadmap, le second valide qu'elle marche. Voir AI red teaming programme.
Ne pas remettre à jour quand le système évolue
Un threat model fait il y a 18 mois ne reflète plus rien si l'architecture a bougé. Re-passer au minimum à chaque évolution majeure (nouveau modèle, nouveau RAG, nouveau tool).
Mon avis en 1 ligne
STRIDE pour la structure, ATLAS pour le détail menaces IA, et un mapping documenté entre les deux. Compter 1 journée pour un threat modeling complet d'une app IA de complexité moyenne, refait à chaque release majeure. C'est le livrable qui rend la sécurité IA défendable face à un comex et à un auditeur. Voir threat model agents IA 7 surfaces pour le cas spécifique des agents autonomes.