Cloudflare annonce ce 4 mars le développement de Firewall for AI (Pare-feu pour l'IA), une couche de protection qui peut être déployée devant les grands modèles de langage (LLM) afin d'identifier les abus avant qu'ils n'atteignent les modèles.Alors que les modèles d'IA, et en particulier les LLM, sont en plein essor, les clients de Cloudflare ont fait part de leur inquiétude quant aux meilleures stratégies pour sécuriser leurs propres LLM. L'utilisation de LLM dans le cadre d'applications connectées à l'internet introduit de nouvelles vulnérabilités qui peuvent être exploitées par des acteurs malveillants.
Certaines des vulnérabilités affectant les applications web et API traditionnelles s'appliquent également au monde des LLM, y compris les injections ou l'exfiltration de données. Cependant, il existe un nouvel ensemble de menaces qui sont maintenant pertinentes en raison de la façon dont les LLM fonctionnent. Par exemple, des chercheurs ont récemment découvert une vulnérabilité dans une plateforme de collaboration en IA qui leur permet de détourner des modèles et d'effectuer des actions non autorisées.
Firewall for AI est un Web Application Firewall (WAF) avancé spécialement conçu pour les applications utilisant des LLM. Il comprendra un ensemble d'outils qui peuvent être déployés devant les applications pour détecter les vulnérabilités et fournir une visibilité aux propriétaires de modèles. Le kit d'outils comprendra des produits qui font déjà partie du WAF, tels que la limitation du débit et la détection des données sensibles, ainsi qu'une nouvelle couche de protection qui est actuellement en cours de développement. Cette nouvelle validation analyse l'invite soumise par l'utilisateur final afin d'identifier les tentatives d'exploitation du modèle pour extraire des données et d'autres tentatives d'abus. Tirant parti de la taille du réseau Cloudflare, Firewall for AI fonctionne au plus près de l'utilisateur, permettant ainsi d'identifier rapidement les attaques et de protéger à la fois l'utilisateur final et les modèles contre les abus et les attaques.
Avant de se pencher sur le fonctionnement de Firewall for AI et sur l'ensemble de ses fonctionnalités, examinons d'abord ce qui rend les LLM uniques et les surfaces d'attaque qu'ils introduisent. Le Top 10 de l'OWASP pour les LLM sera utilisé comme référence.
Pourquoi les LLM sont-ils différents des applications traditionnelles ?
Lorsque l'on considère les LLM comme des applications connectées à Internet, il existe deux différences principales par rapport aux applications web plus traditionnelles.
Premièrement, la manière dont les utilisateurs interagissent avec le produit. Les applications traditionnelles sont déterministes par nature. Pensez à une application bancaire - elle est définie par un ensemble d'opérations (vérifier mon solde, effectuer un virement, etc.). La sécurité des opérations commerciales (et des données) peut être obtenue en contrôlant l'ensemble des opérations acceptées par ces points de terminaison : "GET /balance" ou "POST /transfer".
Les opérations avec les LLM sont non déterministes par conception. Pour commencer, les interactions avec les LLM sont basées sur le langage naturel, ce qui rend l'identification des requêtes problématiques plus difficile que la correspondance des signatures d'attaques. En outre, à moins qu'une réponse ne soit mise en cache, les LLM fournissent généralement une réponse différente à chaque fois, même si la même demande d'entrée est répétée. Il est donc beaucoup plus difficile de limiter la façon dont l'utilisateur interagit avec l'application. Cela représente également une menace pour l'utilisateur, qui risque d'être exposé à des informations erronées qui affaiblissent sa confiance dans le modèle.
Deuxièmement, la façon dont le plan de contrôle de l'application interagit avec les données constitue une grande différence. Dans les applications traditionnelles, le plan de contrôle (code) est bien séparé du plan de données (base de données). Les opérations définies sont le seul moyen d'interagir avec les données sous-jacentes (par exemple, montrez-moi l'historique de mes transactions de paiement). Cela permet aux praticiens de la sécurité de se concentrer sur l'ajout de contrôles et de garde-fous au plan de contrôle et de protéger ainsi indirectement la base de données.
Les LLM sont différents en ce sens que les données d'apprentissage deviennent partie intégrante du modèle lui-même par le biais du processus d'apprentissage, ce qui rend extrêmement difficile le contrôle de la manière dont ces données sont partagées à la suite d'une demande de l'utilisateur. Certaines solutions architecturales sont à l'étude, comme la séparation des LLM en différents niveaux et la séparation des données. Cependant, aucune solution miracle n'a encore été trouvée.
Du point de vue de la sécurité, ces différences permettent aux attaquants de concevoir de nouveaux vecteurs d'attaque qui peuvent cibler les LLM et passer sous le radar des outils de sécurité existants conçus pour les applications web traditionnelles.
Vulnérabilités LLM de l'OWASP
La fondation OWASP a publié une liste des 10 principales classes de vulnérabilités pour les LLM, fournissant un cadre utile pour réfléchir à la manière de sécuriser les modèles de langage. Certaines menaces rappellent le top 10 de l'OWASP pour les applications web, tandis que d'autres sont spécifiques aux modèles de langage.
Comme pour les applications web, certaines de ces vulnérabilités peuvent être traitées au mieux lors de la conception, du développement et de la formation de l'application LLM. Par exemple, l'empoisonnement des données d'apprentissage peut être réalisé en introduisant des vulnérabilités dans l'ensemble des données d'apprentissage utilisées pour former de nouveaux modèles. Les informations empoisonnées sont ensuite présentées à l'utilisateur lorsque le modèle est opérationnel. Les vulnérabilités de la chaîne d'approvisionnement et la conception de plugins non sécurisés sont des vulnérabilités introduites dans les composants ajoutés au modèle, comme les progiciels tiers. Enfin, la gestion des autorisations et des permissions est cruciale lorsqu'il s'agit de traiter les cas d'Excessive Agency, où des modèles non contraints peuvent effectuer des actions non autorisées au sein d'une application ou d'une infrastructure plus large.
Inversement, l'injection d'invites, le déni de service du modèle et la divulgation d'informations sensibles peuvent être atténués par l'adoption d'une solution de sécurité proxy telle que Cloudflare Firewall for AI. Dans les sections suivantes, plus de détails seront donnés sur ces vulnérabilités et sur la façon dont Cloudflare est positionné de manière optimale pour les atténuer.
Déploiements de LLM
Les risques liés aux modèles linguistiques dépendent également du modèle de déploiement. Actuellement, trois approches principales de déploiement sont observées : les LLM internes, publics et de produits. Dans ces trois scénarios, vous devez protéger les modèles contre les abus, protéger les données propriétaires stockées dans le modèle et protéger l'utilisateur final contre les informations erronées ou l'exposition à un contenu inapproprié.
LLM internes : Les entreprises développent des LLM pour aider leurs employés dans leurs tâches quotidiennes. Ils sont considérés comme des actifs de l'entreprise et ne doivent pas être accessibles aux non-employés. Il peut s'agir, par exemple, d'un copilote IA formé aux données de vente et aux interactions avec les clients, utilisé pour générer des propositions personnalisées, ou d'un LLM formé à une base de connaissances interne qui peut être interrogée par les ingénieurs.
LLM publics : Il s'agit de LLM accessibles en dehors des frontières d'une entreprise. Ces solutions ont souvent des versions gratuites que tout le monde peut utiliser et elles sont souvent formées sur des connaissances générales ou publiques. Parmi les exemples, citons GPT d'OpenAI ou Claude d'Anthropic.
LLM de produit : du point de vue de l'entreprise, les LLM peuvent faire partie d'un produit ou d'un service offert à ses clients. Il s'agit généralement de solutions personnalisées auto-hébergées qui peuvent être mises à disposition en tant qu'outil d'interaction avec les ressources de l'entreprise. Parmi les exemples, citons les chatbots de support client ou l'assistant AI de Cloudflare.
Du point de vue du risque, la différence entre les LLM de produit et les LLM publics consiste à déterminer qui subit l'impact des attaques réussies. Les LLM publics sont considérés comme une menace pour les données car les données qui aboutissent dans le modèle peuvent être consultées par pratiquement n'importe qui. C'est l'une des raisons pour lesquelles de nombreuses entreprises conseillent à leurs employés de ne pas utiliser d'informations confidentielles dans les invites de services accessibles au public. Les LLM de produit peuvent être considérés comme une menace pour les entreprises et leur propriété intellectuelle si les modèles ont eu accès à des informations exclusives pendant la formation (par conception ou par accident).
Firewall for AI
Cloudflare Firewall for AI sera déployé comme un WAF traditionnel, où chaque requête API avec une invite LLM est analysée pour rechercher des motifs et des signatures d'attaques possibles.
Firewall for AI peut être déployé devant des modèles hébergés sur la plateforme Cloudflare Workers AI ou des modèles hébergés sur toute autre infrastructure tierce. Il peut également être utilisé avec Cloudflare AI Gateway, et les clients pourront contrôler et configurer Firewall for AI en utilisant le plan de contrôle WAF.
Prévenir les attaques volumétriques
L'une des menaces répertoriées par l'OWASP est le déni de service des modèles. Comme pour les applications traditionnelles, une attaque par déni de service est menée en consommant une quantité exceptionnellement élevée de ressources, ce qui entraîne une réduction de la qualité du service ou une augmentation potentielle des coûts d'exploitation du modèle. Étant donné la quantité de ressources dont les LLM ont besoin pour fonctionner et l'imprévisibilité des entrées des utilisateurs, ce type d'attaque peut être préjudiciable.
Ce risque peut être atténué en adoptant des politiques de limitation de taux qui contrôlent le taux de requêtes provenant de sessions individuelles, limitant ainsi la fenêtre contextuelle. En faisant passer votre modèle par Cloudflare dès aujourd'hui, vous bénéficiez d'une protection contre les attaques DDoS. Vous pouvez également utiliser la limitation de taux et la limitation de taux avancée pour gérer le taux de requêtes autorisées à atteindre votre modèle en définissant un taux maximum de requêtes effectuées par une adresse IP ou une clé API individuelle au cours d'une session.
Identifier les informations sensibles avec la détection des données sensibles
Il existe deux cas d'utilisation des données sensibles, selon que vous êtes propriétaire du modèle et des données ou que vous souhaitez empêcher les utilisateurs d'envoyer des données dans des LLM publics.
Selon la définition de l'OWASP, la divulgation d'informations sensibles se produit lorsque les LLM révèlent par inadvertance des données confidentielles dans les réponses, ce qui entraîne un accès non autorisé aux données, des violations de la vie privée et des failles de sécurité. Une façon d'éviter cela est d'ajouter des validations strictes de l'invite. Une autre approche consiste à identifier le moment où les informations personnelles identifiables (PII) quittent le modèle. C'est le cas, par exemple, lorsqu'un modèle a été formé à l'aide d'une base de connaissances de l'entreprise qui peut contenir des informations sensibles, telles que des PII (comme le numéro de sécurité sociale), des codes propriétaires ou des algorithmes.
Les clients qui utilisent des modèles LLM derrière Cloudflare WAF peuvent utiliser l'ensemble de règles gérées SDD (Sensitive Data Detection) WAF pour identifier certaines PII renvoyées par le modèle dans la réponse. Les clients peuvent consulter les correspondances SDD sur les événements de sécurité du WAF. Aujourd'hui, SDD est proposé sous la forme d'un ensemble de règles gérées conçues pour rechercher des informations financières (telles que les numéros de carte de crédit) ainsi que des secrets (clés API). Dans le cadre de la feuille de route, Cloudflare prévoit de permettre à ses clients de créer leurs propres empreintes digitales personnalisées.
L'autre cas d'utilisation vise à empêcher les utilisateurs de partager des PII ou d'autres informations sensibles avec des fournisseurs LLM externes, tels que OpenAI ou Anthropic. Pour se protéger contre ce scénario, Cloudflare prévoit d'étendre le SDD afin d'analyser l'invite et d'intégrer sa sortie à AI Gateway où, en plus de l'historique de l'invite, certaines données sensibles seront détectées si elles ont été incluses dans la requête. Cloudflare commencera par utiliser les règles SDD existantes, et prévoit d'autoriser les clients à rédiger leurs propres signatures personnalisées. Dans le même ordre d'idées, l'obscurcissement est une autre fonction dont les clients évoquent souvent l'importance. Une fois disponible, le SDD étendu permettra aux clients d'obscurcir certaines données sensibles dans une invite avant qu'elles n'atteignent le modèle. Le SDD sur la phase de requête est en cours de développement.
Prévenir les abus de modèles
L'abus de modèle est une catégorie plus large d'abus. Elle comprend des approches telles que l'"injection d'invite" ou la soumission de requêtes qui génèrent des hallucinations ou conduisent à des réponses inexactes, offensantes, inappropriées ou simplement hors sujet.
L'injection d'invites est une tentative de manipulation d'un modèle linguistique par le biais d'entrées spécialement conçues, provoquant des réponses involontaires de la part du LLM. Les résultats d'une injection peuvent varier, allant de l'extraction d'informations sensibles à l'influence sur la prise de décision en imitant les interactions normales avec le modèle. Un exemple classique d'injection d'invite est la manipulation d'un CV pour influencer les résultats des outils de sélection de CV.
Un cas d'utilisation courant évoqué par les clients de AI Gateway est qu'ils souhaitent éviter que leur application ne génère un langage toxique, offensant ou problématique. Les risques de ne pas contrôler le résultat du modèle comprennent l'atteinte à la réputation et le préjudice causé à l'utilisateur final en fournissant une réponse non fiable.
Ces types d'abus peuvent être gérés en ajoutant une couche de protection supplémentaire devant le modèle. Cette couche peut être entraînée à bloquer les tentatives d'injection ou à bloquer les invites qui tombent dans des catégories inappropriées.
Validation de l'invite et de la réponse
Firewall for AI lancera une série de détections conçues pour identifier les tentatives d'injection d'invites et d'autres abus, en s'assurant par exemple que le sujet reste dans les limites définies par le propriétaire du modèle. Comme d'autres fonctions WAF existantes, Firewall for AI recherchera automatiquement les invites intégrées dans les requêtes HTTP ou permettra aux clients de créer des règles basées sur l'endroit du corps JSON de la requête où l'invite peut être trouvée.
Une fois activé, le pare-feu analysera chaque invite et fournira un score basé sur la probabilité qu'elle soit malveillante. Il marque également l'invite en fonction de catégories prédéfinies. La note va de 1 à 99, ce qui indique la probabilité d'une injection d'invite, la note 1 étant la plus probable.
Les clients pourront créer des règles WAF pour bloquer ou traiter les requêtes ayant un score particulier dans l'une ou l'autre de ces dimensions, ou dans les deux. Vous pourrez combiner ce score avec d'autres signaux existants (comme le score de bot ou le score d'attaque) pour déterminer si la demande doit atteindre le modèle ou être bloquée. Par exemple, il peut être combiné avec un score de bot pour identifier si la demande est malveillante et générée par une source automatisée.
Outre le score, le système attribuera à chaque invite des balises qui pourront être utilisées lors de la création de règles visant à empêcher les invites appartenant à l'une de ces catégories d'atteindre leur modèle. Par exemple, les clients pourront créer des règles pour bloquer des sujets spécifiques. Cela inclut les invites utilisant des mots classés comme offensants ou liés à la religion, au contenu sexuel ou à la politique, par exemple.
Comment utiliser Firewall for AI ? Qui peut en bénéficier ?
Les entreprises clientes de l'offre Application Security Advanced peuvent immédiatement commencer à utiliser Advanced Rate Limiting et Sensitive Data Detection (sur la phase de réponse). Ces deux produits se trouvent dans la section WAF du tableau de bord de Cloudflare. La fonction de validation rapide de Firewall for AI est actuellement en cours de développement et une version bêta sera mise à la disposition de tous les utilisateurs de Workers AI dans les mois à venir.
Conclusion
Cloudflare est l'un des premiers fournisseurs de sécurité à lancer un ensemble d'outils pour sécuriser les applications d'IA. Grâce à Firewall for AI, les clients peuvent contrôler les invites et les demandes qui parviennent à leurs modèles de langage, réduisant ainsi le risque d'abus et d'exfiltration de données.
Source : "Cloudflare announces Firewall for AI" (Cloudflare)
Et vous ?
Quel est votre avis sur le sujet ? Que pensez-vous de cette initiative de Cloudflare, trouvez-vous qu'elle est crédible ou pertinente ? Selon vous, quelles mesures de sécurité supplémentaires peuvent être mises en place pour protéger les LLM contre les abus, tout en assurant la confidentialité des données et la fiabilité des réponses fournies par les modèles ?Voir aussi :
Les systèmes d'IA font face à des menaces croissantes : le NIST a identifié les différents types de cyberattaques qui manipulent le comportement des systèmes d'IA Cloudflare veut remplacer les CAPTCHA par Turnstile qui se passe des images de passages piétons, des cases à cocher et de Google, Turnstile serait plus respectueux de la vie privée que les CAPTCHA Cloudflare affirme avoir réussi à atténuer une attaque DDoS de 26 millions de requêtes par seconde, l'assaut aurait été lancé par un botnet d'environ 5 000 appareils