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 un schéma pour 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 vers tout le reste.

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

Un schéma que nous observons constamment dans les environnements d’entreprise raconte une histoire inquiétante de équipes de sécurité 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 d’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 bordure.

Les entreprises utilisent maintenant en moyenne 130+ applications SaaS, avec des intégrations d’IA s’étendant 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 d’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é de l’IA sont cassés. C’est que nous sécurisons des composants individuels alors que les attaquants exploitent les connexions entre eux.

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

L’approche actuelle de la sécurité de l’IA fonctionne sur une méconception 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, de permissions, 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 d’AWS S3. Il est authentifié via Okta ou Azure AD. Il déclenche des flux de travail dans ServiceNow.

La sécurité de l’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 pivoter via des manipulations d’API, quelles limites de confiance ils peuvent franchir 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

C’est là que la plupart des organisations sont bloquées. Elles ont déployé des outils de sécurité qui fournissent chacun une visibilité dans un seul domaine. Un outil surveille les autorisations de cloud. Un autre suit les configurations de 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 sont en train de relier 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 seau 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 ? 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 de l’exposition

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égrés à 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 d’une 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 changent 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.

Ceci est encore plus prononcé avec les systèmes d’IA car ils changent constamment. De nouvelles intégrations sont ajoutées chaque semaine. Les autorisations évoluent. Les connexions d’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é informée des chemins d’attaque

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

Tout d’abord, vous avez besoin d’une visibilité unifiée à travers 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é de cloud, de gouvernance des identités, de gestion de SaaS et de scan de 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 pour 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 se fier à des scores de gravité théoriques.

Troisièmement, priorisez en fonction du contexte. Un seau S3 mal configuré n’est pas critique simplement parce qu’il est public. C’est critique si c’est public et qu’il 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 à la réparation préventive. Lorsque votre équipe de sécurité d’opérations 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 pas ignorer

Alors que l’IA est intégrée à chaque couche de la pile d’entreprise, la surface d’attaque s’étend plus vite que les équipes de sécurité ne peuvent raisonner manuellement à son sujet. 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 votre environnement entier.

Les entreprises qui sécuriseront avec succès l’IA ne seront pas celles qui ont le plus d’outils de sécurité de l’IA. Ce seront celles qui comprennent que la sécurité de l’IA est inséparable de la gestion de l’exposition à travers leur surface d’attaque entière.

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, à travers leur environnement entier, elles ne sécurisent pas l’IA. Elles espèrent simplement que les murs qu’elles ont construits sont aux bons endroits.