Alors que l’IA rend la modélisation des menaces plus complexe, les RSSI ont besoin d’un moyen plus rapide et plus pratique d’identifier les nouveaux risques sans perdre de vue les bases de la sécurité.
Il y a quelques semaines, lors d’une journée bien remplie, Adam Shostack, expert en modélisation des menaces, a ouvert un e-mail provenant d’un client. Quelqu’un dans cette organisation avait codé une application et l’avait mise en œuvre avec les données des clients. Désormais, le client voulait savoir quels risques présentait l’outil. Et ce qu’il devrait faire à leur sujet.
Ils avaient besoin de réponses rapidement, alors Shostack s’est donné 15 minutes pour analyser le système.
Bientôt, il eut « une liste de menaces significatives », y compris les hallucinations et les préjugés, des problèmes que STRIDE, un cadre de modèle de menace pour la sécurité des applications largement utilisé, n’aurait pas montré.
« J’ai découvert des choses intéressantes qui n’étaient pas évidentes pour moi lorsque j’ai commencé », explique Shostack.
Pendant ces 15 minutes, il a utilisé PHANTOM-B, un framework de modélisation des menaces qu’il a développé. Cela commence par la question standard « Qu’est-ce qui peut mal se passer ? » mais l’applique spécifiquement aux composants LLM d’un système.
Chaque lettre du nom représente une menace spécifique : injection rapide, hallucination, anthropomorphisation, non-explicabilité, problèmes de formation, confiance excessive (y compris la qualité des données ou « poison »), ingénierie de sécurité manquante et biais.
Le nouveau cadre est destiné à compléter STRIDE et non à le remplacer. Alors que STRIDE s’applique à l’ensemble de l’application, PHANTOM-B peut être utilisé pour les composants qui interagissent avec les LLM.
Le cadre est conçu pour produire rapidement des résultats utiles, rendant la modélisation des menaces moins intimidante et moins coûteuse. Et, par conséquent, il est plus probable que cela se produise.
« Je suis un grand fan de : rendons ce travail peu coûteux », déclare Shostack, qui a présenté PHANTOM-B au Black Hat USA 2026.
Shostack ajoute que les RSSI et leurs organisations sont pris entre deux défis : la pression pour sécuriser rapidement l’IA et la difficulté d’y appliquer les outils de sécurité existants.
« Les entreprises ont besoin d’un point d’entrée, ce qui peut être intégré dans une réunion d’une heure ou une conversation de 10 minutes avec un dirigeant », explique-t-il.
Le besoin d’utiliser des outils comme PHANTOM-B devient de plus en plus urgent, car les entreprises s’appuient de plus en plus sur l’IA. « La modélisation des menaces est plus importante que jamais, car l’IA introduit de véritables nouvelles architectures d’applications et de nouveaux risques », déclare Jeff Williams, fondateur d’OWASP et fondateur et CTO de Contrast Security.
Pourquoi la modélisation traditionnelle des menaces est insuffisante
La modélisation des menaces a toujours été un combat. Les organisations de toutes tailles ont du mal à le faire de manière cohérente, car cela prend du temps et ne peut souvent pas suivre le nombre d’applications créées et mises à jour. En conséquence, de nombreuses entreprises le réservent à leurs systèmes les plus critiques, laissant une grande partie de leurs logiciels sans le même examen.
« L’IA n’a pas brisé la modélisation des menaces. Elle a révélé des faiblesses déjà présentes », explique Williams. La réalité inconfortable, affirme-t-il, est que la modélisation des menaces n’a jamais été suffisamment standardisée ou automatisée pour pouvoir évoluer.
Le plus difficile n’est pas de nommer les menaces mais de déterminer quelles applications fonctionnent. « Traditionnellement, nous avons tenté cela avec des enquêtes, des questionnaires, des entretiens, des diagrammes Visio obsolètes et des feuilles de calcul », explique Williams. « Le modèle obtenu est souvent incomplet avant même le début de l’exercice, et il devient obsolète dès que l’application change. »
L’IA générative et agentique amplifie ces faiblesses, car leur comportement n’est pas facile à prédire. Les logiciels conventionnels suivent des règles que les ingénieurs peuvent tracer depuis l’entrée jusqu’à la sortie. Les systèmes d’IA interprètent les instructions en langage naturel et génèrent des réponses probabilistes, de sorte qu’une même requête peut produire des résultats différents. Et lorsque les agents peuvent accéder aux données ou appeler des outils, ces résultats peuvent déclencher des actions ailleurs.
« La modélisation traditionnelle des menaces a été appliquée à des systèmes généralement déterministes. Les systèmes modernes d’IA générative et agentique ne sont pas déterministes, il est donc nécessaire de modifier la façon dont nous percevons leurs profils de risque », explique Brian Glas, vice-président des services de conseil chez CODIFIC et l’un des chefs de projet du Top 10 de l’OWASP.
Cette distinction apparaît également dans les conseils de modélisation des menaces IA de Microsoft, qui notent que la frontière entre les données et les commandes peut s’estomper, créant de nouvelles surfaces d’attaque et permettant aux pannes de se propager aux outils, à la mémoire et aux agents.
Dans le même temps, des cycles de développement plus rapides laissent aux équipes moins de temps pour réfléchir à la manière dont les systèmes doivent être conçus et sécurisés. Et la complexité rend également plus difficile l’examen isolé des menaces. Une faiblesse dans un document, par exemple, pourrait modifier la réponse d’un modèle et amener un agent ou un outil à entreprendre une action dangereuse dans un autre système. L’OWASP prévient que ces risques peuvent se propager à l’ensemble du pipeline de production augmentée par récupération.
« Un enchaînement de menaces ou de faiblesses aboutit à l’exploitation de l’application », explique Glas.
La réponse à ces questions est de faire de la modélisation des menaces une pratique continue, une recommandation formulée dans le cadre de gestion des risques liés à l’intelligence artificielle du NIST.
Mais malgré un nombre croissant de conseils – notamment le PHANTOM-B de Shostack, les recommandations de modélisation des menaces de l’IA de Microsoft, le profil Generative AI du NIST et le Top 10 des applications LLM de l’OWASP – il n’existe toujours pas de manuel définitif pour les systèmes d’IA de modélisation des menaces.
« La modélisation des menaces n’est pas une pratique mature », déclare Glas. « Je crois que nous essayons toujours de comprendre cela. »
Améliorer la modélisation des menaces à l’ère de l’IA
Un exercice de modélisation des menaces de 15 ou 30 minutes semble trompeusement gérable. Mais quelle quantité de travail de sécurité utile les équipes peuvent-elles réellement accomplir en si peu de temps ?
Shostack dit qu’une courte session n’est pas censée être exhaustive. Il doit toutefois identifier suffisamment de risques significatifs pour guider la prochaine décision : le risque est-il acceptable, le système doit-il changer ou un examen plus approfondi est-il nécessaire ?
« L’une des choses que nous avons apprises du monde agile est que lorsque vous réduisez la période de travail, vous itérez plus et plus rapidement », dit-il. Si la première session manque la cible, l’équipe peut effacer le tableau blanc et réessayer sans perdre des jours ou des semaines de travail. « Vous rendez les expériences bon marché, et lorsque l’expérience est bon marché, vous pouvez la répéter à plusieurs reprises. »
Le résultat devrait être un ensemble d’histoires concrètes sur la façon dont le système pourrait échouer. Ces scénarios peuvent aider les RSSI à comprendre les risques qu’ils acceptent et aider les équipes techniques à choisir les contrôles appropriés, ce qui peut impliquer de limiter l’accès aux données, de restreindre les autorisations des outils, d’ajouter des points d’approbation humaine ou même de reconsidérer la nécessité d’un LLM.
PHANTOM-B vise à combler les lacunes laissées par d’autres frameworks. Il aborde des concepts pertinents mais parfois exotiques tels que l’anthropomorphisation, en se demandant si les utilisateurs ou les développeurs traitent le modèle comme s’il comprenait l’intention, raisonnait comme une personne, ou suivait de manière fiable une instruction telle que « Ne faites pas X ». Cette confiance mal placée peut façonner la manière dont un système est conçu et le degré d’autorité dont il bénéficie.
L’inexplicabilité soulève un autre problème. Si un LLM examine des curriculum vitae, évalue des images médicales ou prend des décisions commerciales, une organisation devra peut-être justifier ses résultats. Mais demander au modèle de s’expliquer peut produire une réponse plausible plutôt qu’un enregistrement précis de la manière dont il a atteint le résultat initial. Les LLM étant probabilistes, la réexécution de la même requête peut ne pas reproduire le même résultat, ce qui rend l’investigation et le débogage plus difficiles.
L’invite « ingénierie de sécurité manquante » rappelle que l’ajout d’un LLM n’élimine pas les risques logiciels conventionnels. Selon le livre blanc de Shostack, cela peut les amplifier, en particulier lorsque les organisations se précipitent pour déployer des logiciels codés en ambiance que personne ne comprend vraiment.
Cet outil, associé aux travaux de l’OWASP, du NIST, du CISA et d’autres, peut aider les équipes à comprendre le paysage des risques émergents. « La modélisation des menaces est un processus créatif », explique Williams.
Erreurs à éviter lors de la modélisation des systèmes d’IA des menaces
Les outils basés sur LLM sont peut-être relativement nouveaux, mais ce sont toujours des applications. Ils utilisent des bibliothèques tierces, traitent des entrées non fiables, gèrent des données sensibles, exposent des API et dépendent de contrôles d’identité et d’autorisation.
Se concentrer fortement sur les nouvelles menaces de l’IA tout en ignorant les bases peut exposer les organisations à des vulnérabilités évitables. « La plus grande erreur est d’oublier que tous les risques existants existent toujours », déclare Williams.
Il conseille aux RSSI de ne pas passer directement à l’injection rapide ou à la manipulation de modèles tout en ignorant les principes fondamentaux. « C’est à l’envers », dit Williams. « La sécurité traditionnelle des applications doit être la base. Les nouveaux risques liés à l’IA sont une couche supplémentaire par-dessus, et non un remplacement. »
Glas est d’accord. « Les détails ont changé, mais pas les fondamentaux du risque », dit-il. « Ne jetez pas les leçons de sécurité apprises au cours des 25 dernières années pour rechercher la vélocité. »
Glas souligne également un autre problème courant : le manque de contexte. Les équipes peuvent ne pas comprendre pleinement comment un LLM s’intègre dans une application plus large, y compris ses contrôles d’accès, ses limites de confiance, ses entrées et ses flux de données. Sans cette vision, des risques importants peuvent facilement passer entre les mailles du filet.
Essayer de cataloguer toutes les attaques imaginables n’est pas non plus la solution. « Vous ne pouvez pas tous les suivre », explique Glas. « Le nombre d’attaques possibles est presque illimité. » Il recommande plutôt de commencer par les actifs qui nécessitent une protection et les contrôles préventifs et de détection déjà en place. À partir de là, les équipes peuvent modéliser différents types d’attaques pour découvrir les contrôles faibles ou manquants et déterminer ce qui est nécessaire pour réduire les risques à un niveau acceptable.
