La sécurité de l’IA n’est pas cassée, nous défendons simplement les mauvaises choses

L’industrie de la cybersécurité a une tendance lorsqu’une nouvelle technologie émerge, nous commençons immédiatement à construire des murs autour. Nous l’avons fait avec le cloud, nous l’avons fait avec les conteneurs, et maintenant, nous le faisons avec l’IA, sauf que cette fois, les murs que nous construisons sont à des endroits complètement erronés.

Entrez dans n’importe quelle revue de sécurité d’entreprise aujourd’hui, et vous entendrez les mêmes priorités : sécuriser les modèles d’IA, protéger les données de formation, valider les sorties, et déployer des copilotes alimentés par l’IA. Les fournisseurs se précipitent pour vendre des outils de “sécurité de l’IA” qui se concentrent exclusivement sur les contrôles au niveau du modèle, tels que les garde-fous, les défenses contre les injections de invites, et les plateformes de surveillance de modèle.

Mais les attaquants utilisent vos intégrations d’IA comme autoroutes pour accéder à tout le reste.

La véritable surface d’attaque que personne ne surveille

Un modèle que nous observons constamment dans les environnements d’entreprise raconte une histoire inquiétante de sécurité des équipes qui investissent lourdement dans la sécurisation de leurs environnements de développement d’IA : contrôles d’accès aux modèles, cadres de gouvernance des données, outils de sécurité MLOps. Cela donne une fausse confiance que leur IA est “verrouillée”.

Mais lorsque vous cartographiez la véritable surface d’attaque, vous voyez que les chatbots d’IA détiennent souvent des jetons OAuth pour des dizaines de plateformes SaaS, des clés API avec des autorisations de cloud excessives, et des relations de confiance d’identité qui peuvent créer des chemins directs d’une simple injection de invite à l’infrastructure de production. Les modèles eux-mêmes peuvent être sécurisés, mais les écosystèmes dans lesquels ils vivent sont souvent grands ouverts, et ce n’est pas un cas de figure marginal.

Les entreprises utilisent maintenant en moyenne 130+ applications SaaS, avec des intégrations d’IA qui s’étendent aux fournisseurs d’identité, aux infrastructures cloud, aux bases de données et aux systèmes critiques pour les entreprises. Chaque intégration est un chemin d’attaque potentiel, et chaque connexion API est une limite de confiance que les attaquants sont en train de sonder activement.

Le problème n’est pas que nos outils de sécurité d’IA sont cassés. C’est que nous sécurisons des composants individuels tandis que les attaquants exploitent les connexions entre eux.

Pourquoi la sécurité axée sur le modèle manque l’essentiel

L’approche actuelle de la sécurité de l’IA repose sur une mécompréhension fondamentale de la façon dont les attaques modernes fonctionnent. Nous traitons l’IA comme un actif autonome qui nécessite une protection, similaire à la façon dont nous pourrions sécuriser une base de données ou une application Web. Mais l’IA en production n’existe pas en isolation. C’est un nœud dans un graphique complexe d’identités, d’autorisations, d’API et de flux de données.

Considérez un déploiement d’IA d’entreprise typique. Vous avez un agent d’IA avec accès à votre Google Workspace. Il est connecté à Salesforce via des API. Il est intégré à Slack pour les notifications. Il extrait des données de buckets AWS S3. Il est authentifié via Okta ou Azure AD. Il déclenche des flux de travail dans ServiceNow.

La sécurité d’IA traditionnelle se concentre sur le modèle lui-même : sa posture de sécurité, la validation des invites, la sécurité des sorties. Mais les attaquants se concentrent sur les intégrations : ce qu’ils peuvent atteindre via des comptes de service compromis, où ils peuvent basculer via des manipulations d’API, quelles limites de confiance ils peuvent traverser via des intégrations exploitées.

L’attaque ne commence ni ne se termine avec le modèle d’IA. Le modèle est juste le point d’entrée.

Les chemins d’attaque ne respectent pas les limites de produit

Voici où la plupart des organisations sont bloquées. Elles ont déployé des outils de sécurité qui each fournissent une visibilité sur un seul domaine. Un outil surveille les autorisations cloud. Un autre suit les configurations SaaS. Un troisième gère la gouvernance des identités. Un quatrième gère la gestion des vulnérabilités.

Chaque outil vous montre sa partie du puzzle. Aucun d’entre eux ne vous montre comment les pièces se connectent.

Selon Gartner, les organisations utilisent maintenant en moyenne 45+ outils de sécurité. Pourtant, malgré cet investissement massif, les attaquants réussissent à enchaîner des mauvaises configurations à travers ces domaines parce qu’aucun outil ne peut voir le chemin d’attaque complet.

Un attaquant n’a pas besoin de trouver une vulnérabilité critique dans votre modèle d’IA. Il lui suffit de trouver une chaîne. Peut-être qu’il s’agit d’un rôle IAM mal configuré attaché à votre service d’IA, qui a des autorisations pour un bucket S3, qui contient des informations d’identification pour une application SaaS qui a un accès administrateur à votre environnement de production.

Chaque mauvaise configuration individuelle peut obtenir un score “moyen” ou “faible” dans vos outils de sécurité. Mais enchaînées ensemble ? C’est une exposition critique. Et c’est complètement invisible si vous regardez chaque domaine de sécurité en isolation.

L’impératif de gestion des expositions

C’est pourquoi la conversation doit passer de la “sécurité de l’IA” à la gestion continue de l’exposition aux menaces pour les environnements intégrant l’IA.

Il ne suffit pas de demander si nos modèles d’IA sont sécurisés. Les équipes de sécurité doivent comprendre ce qu’un attaquant peut réellement atteindre s’il compromet un compte de service d’IA. Ils ont besoin de visibilité sur la façon dont les mauvaises configurations à travers les systèmes cloud, SaaS et d’identité pourraient être enchaînées. Ils ont besoin de savoir comment les intégrations d’IA modifient leur surface d’attaque en temps réel. Et ils doivent prioriser les risques en fonction de l’exploitabilité réelle, et non juste des scores de gravité.

La plupart des programmes de sécurité donnent toujours la priorité aux risques en isolation, en utilisant des scores CVSS et des listes de contrôle de conformité qui ignorent complètement si une vulnérabilité est réellement exploitable dans votre environnement spécifique.

Cette faille est encore plus prononcée avec les systèmes d’IA parce qu’ils changent constamment. De nouvelles intégrations sont ajoutées chaque semaine. Les autorisations évoluent. Les connexions API changent. Votre surface d’attaque du mois dernier n’est pas votre surface d’attaque d’aujourd’hui, mais votre évaluation de sécurité est probablement toujours la même.

Ce à quoi ressemble réellement la sécurité consciente du chemin d’attaque

Sécuriser l’IA en production nécessite une approche fondamentalement différente, et cela se résume à quatre changements clés dans la pensée.

Premièrement, vous avez besoin d’une visibilité unifiée sur les domaines de sécurité. Arrêtez de demander à chaque outil de sécurité de fonctionner dans son propre silo. Vos outils de sécurité cloud, de gouvernance des identités, de gestion SaaS et de balayage des vulnérabilités détiennent tous des pièces du puzzle du chemin d’attaque. Ils doivent partager des données en temps réel afin que vous puissiez voir comment les mauvaises configurations s’enchaînent.

Deuxièmement, adoptez la simulation continue du chemin d’attaque. N’attendez pas les tests de pénétration ou les exercices de l’équipe rouge pour découvrir les chemins exploitables. Testez en continu comment un attaquant pourrait se déplacer dans votre environnement, en se concentrant sur l’exploitabilité réelle plutôt que de vous fier à des scores de gravité théoriques.

Troisièmement, priorisez en fonction du contexte. Un bucket S3 mal configuré n’est critique que s’il est public et contient des informations d’identification et que ces informations d’identification ont un accès privilégié, et qu’elles sont accessibles à partir d’un actif exposé à Internet. Le contexte compte plus que n’importe quel score individuel.

Quatrièmement, passez à une remediation préventive. Lorsque votre équipe SOC est en train d’enquêter sur une alerte, vous avez déjà perdu un temps de réponse précieux. La défense moderne nécessite la capacité de fermer les chemins exploitables avant qu’ils ne soient utilisés, et non après un incident.

L’avertissement que nous ne pouvons ignorer

Alors que l’IA s’intègre dans toutes les couches de la pile d’entreprise, la surface d’attaque s’élargit plus vite que les équipes de sécurité ne peuvent la raisonner manuellement. Nous ajoutons des intégrations d’IA à 10 fois le rythme auquel nous les sécurisons.

Si vous sécurisez l’IA en isolation, en protégeant le modèle tout en ignorant l’écosystème dans lequel il opère, vous êtes déjà en retard. Les attaquants ne pensent pas en termes d’outils, ils pensent en termes de chemins. Ils n’exploitent pas des vulnérabilités individuelles. Ils enchaînent des mauvaises configurations à travers tout votre environnement.

Les entreprises qui sécuriseront avec succès l’IA ne seront pas celles qui ont le plus d’outils de sécurité d’IA. Ce seront celles qui comprennent que la sécurité de l’IA est inséparable de la gestion des expositions sur toute leur surface d’attaque.

La sécurité du modèle est un minimum. Ce qui compte, c’est de comprendre ce qu’un attaquant peut atteindre lorsqu’il compromet une intégration d’IA. Jusqu’à ce que les équipes de sécurité puissent répondre à cela en continu, en temps réel, sur tout leur environnement, elles ne sécurisent pas l’IA. Elles espèrent simplement que les murs qu’elles ont construits sont aux bons endroits.