Cloudflare annonce un pare-feu pour l’IA

xguru · 2024-03-06T10:32:02+09:00

Cloudflare a annoncé le développement de « Firewall for AI », une nouvelle couche de protection placée devant les grands modèles de langage (Large Language Models, LLM) afin d’identifier les abus Utiliser des LLM comme applications connectées à Internet introduit de nouvelles vulnérabilités qui peuvent être exploitées par des acteurs malveillants En plus des vulnérabilités qui affectent les applications web et API existantes, de nouvelles menaces apparaissent en raison du mode de fonctionnement des LLM Le pare-feu pour l’IA est un pare-feu applicatif web (WAF) avancé, spécialisé pour les applications qui utilisent des LLM, et comprend un ensemble d’outils permettant de détecter les vulnérabilités et d’offrir de la visibilité aux propriétaires des modèles Pourquoi les LLM sont-ils différents des applications traditionnelles ? Si l’on considère les LLM comme des applications connectées à Internet, il existe deux différences majeures par rapport aux applications web traditionnelles Premièrement, la manière dont les utilisateurs interagissent avec le produit est différente. Les applications traditionnelles sont déterministes, tandis que les LLM sont non déterministes et reposent sur le langage naturel Deuxièmement, la manière dont le plan de contrôle de l’application interagit avec les données est différente. Dans les applications traditionnelles, le plan de contrôle (le code) et le plan de données (la base de données) sont bien séparés ; dans les LLM, les données d’entraînement font partie du modèle lui-même, ce qui rend difficile le contrôle du partage de données via les prompts des utilisateurs Vulnérabilités OWASP des LLM La fondation OWASP a publié le top 10 des vulnérabilités des LLM, offrant un cadre utile pour réfléchir à la manière de protéger les modèles de langage Certaines menaces ressemblent au top 10 OWASP des applications web, mais d’autres sont spécifiques aux modèles de langage Déploiement des LLM Les risques liés aux LLM varient selon le modèle de déploiement. Il existe actuellement trois grandes approches de déploiement Internal LLM (interne) : l’entreprise développe un LLM pour assister ses équipes dans leurs tâches quotidiennes. Il est considéré comme un actif de l’entreprise et ne doit pas être accessible à des personnes extérieures. Par exemple, un copilote IA entraîné sur des données commerciales et des interactions client pour générer des recommandations personnalisées, ou un LLM entraîné sur une base de connaissances interne que les ingénieurs peuvent interroger Public LLM (public) : un LLM accessible en dehors de l’entreprise. Ces solutions disposent souvent d’une version gratuite utilisable par tous et sont généralement entraînées sur des connaissances générales ou publiques. Par exemple GPT d’OpenAI ou Claude d’Anthropic Product LLM (produit) : du point de vue de l’entreprise, le LLM peut faire partie d’un produit ou d’un service proposé aux clients. Il s’agit généralement d’une solution personnalisée auto-hébergée, utilisable comme outil interagissant avec les ressources de l’entreprise. Par exemple un chatbot de support client ou l’assistant IA de Cloudflare Dans tous les scénarios, il faut protéger le modèle contre les abus, protéger les données propriétaires stockées dans le modèle et protéger les utilisateurs contre la désinformation ou les contenus inappropriés Pare-feu pour l’IA Le pare-feu pour l’IA de Cloudflare se déploie comme un WAF traditionnel et analyse toutes les requêtes API contenant des prompts de LLM afin de détecter d’éventuels schémas et signatures d’attaque Il peut être placé devant des modèles hébergés sur la plateforme Cloudflare Workers AI ou sur une infrastructure tierce, et peut être utilisé avec Cloudflare AI Gateway Protection contre les attaques en volume L’une des menaces listées par OWASP est le déni de service du modèle (Model Denial of Service) Comme pour les applications traditionnelles, les attaques DoS dégradent la qualité de service ou augmentent les coûts d’exploitation du modèle en consommant excessivement les ressources Ce risque peut être atténué en adoptant des politiques de limitation de débit qui contrôlent le rythme des requêtes sur chaque session Identification des informations sensibles Il existe deux cas d’usage autour des informations sensibles, selon que l’on possède le modèle et les données ou que l’on cherche à empêcher les utilisateurs d’envoyer des données à un LLM public La divulgation d’informations sensibles définie par OWASP se produit lorsqu’un LLM révèle par inadvertance des données confidentielles dans ses réponses, ce qui peut entraîner un accès non autorisé aux données, des atteintes à la vie privée et des violations de sécurité Prévention des abus du modèle Les abus du modèle incluent diverses approches, comme la « prompt injection » ou l’envoi de requêtes destinées à provoquer des hallucinations ou à générer des réponses inexactes, offensantes, inappropriées ou hors sujet La prompt injection est une tentative de manipulation d’un modèle de langage via une entrée spécialement conçue afin de provoquer des réponses non intentionnelles du LLM Comment utiliser le pare-feu pour l’IA Les clients entreprises qui utilisent « Application Security Advanced » peuvent utiliser immédiatement Advanced Rate Limiting et Sensitive Data Detection Les fonctionnalités de validation des prompts du pare-feu pour l’IA sont actuellement en cours de développement et une version bêta devrait être lancée pour les utilisateurs de Workers AI dans les prochains mois

(blog.cloudflare.com)

7 points par xguru 2024-03-06 | 1 commentaires | Partager sur WhatsApp

Cloudflare a annoncé le développement de « Firewall for AI », une nouvelle couche de protection placée devant les grands modèles de langage (Large Language Models, LLM) afin d’identifier les abus
Utiliser des LLM comme applications connectées à Internet introduit de nouvelles vulnérabilités qui peuvent être exploitées par des acteurs malveillants
En plus des vulnérabilités qui affectent les applications web et API existantes, de nouvelles menaces apparaissent en raison du mode de fonctionnement des LLM
Le pare-feu pour l’IA est un pare-feu applicatif web (WAF) avancé, spécialisé pour les applications qui utilisent des LLM, et comprend un ensemble d’outils permettant de détecter les vulnérabilités et d’offrir de la visibilité aux propriétaires des modèles

Pourquoi les LLM sont-ils différents des applications traditionnelles ?

Si l’on considère les LLM comme des applications connectées à Internet, il existe deux différences majeures par rapport aux applications web traditionnelles
Premièrement, la manière dont les utilisateurs interagissent avec le produit est différente. Les applications traditionnelles sont déterministes, tandis que les LLM sont non déterministes et reposent sur le langage naturel
Deuxièmement, la manière dont le plan de contrôle de l’application interagit avec les données est différente. Dans les applications traditionnelles, le plan de contrôle (le code) et le plan de données (la base de données) sont bien séparés ; dans les LLM, les données d’entraînement font partie du modèle lui-même, ce qui rend difficile le contrôle du partage de données via les prompts des utilisateurs

Vulnérabilités OWASP des LLM

La fondation OWASP a publié le top 10 des vulnérabilités des LLM, offrant un cadre utile pour réfléchir à la manière de protéger les modèles de langage
Certaines menaces ressemblent au top 10 OWASP des applications web, mais d’autres sont spécifiques aux modèles de langage

Déploiement des LLM

Les risques liés aux LLM varient selon le modèle de déploiement. Il existe actuellement trois grandes approches de déploiement
- Internal LLM (interne) : l’entreprise développe un LLM pour assister ses équipes dans leurs tâches quotidiennes. Il est considéré comme un actif de l’entreprise et ne doit pas être accessible à des personnes extérieures. Par exemple, un copilote IA entraîné sur des données commerciales et des interactions client pour générer des recommandations personnalisées, ou un LLM entraîné sur une base de connaissances interne que les ingénieurs peuvent interroger
- Public LLM (public) : un LLM accessible en dehors de l’entreprise. Ces solutions disposent souvent d’une version gratuite utilisable par tous et sont généralement entraînées sur des connaissances générales ou publiques. Par exemple GPT d’OpenAI ou Claude d’Anthropic
- Product LLM (produit) : du point de vue de l’entreprise, le LLM peut faire partie d’un produit ou d’un service proposé aux clients. Il s’agit généralement d’une solution personnalisée auto-hébergée, utilisable comme outil interagissant avec les ressources de l’entreprise. Par exemple un chatbot de support client ou l’assistant IA de Cloudflare
Dans tous les scénarios, il faut protéger le modèle contre les abus, protéger les données propriétaires stockées dans le modèle et protéger les utilisateurs contre la désinformation ou les contenus inappropriés

Pare-feu pour l’IA

Le pare-feu pour l’IA de Cloudflare se déploie comme un WAF traditionnel et analyse toutes les requêtes API contenant des prompts de LLM afin de détecter d’éventuels schémas et signatures d’attaque
Il peut être placé devant des modèles hébergés sur la plateforme Cloudflare Workers AI ou sur une infrastructure tierce, et peut être utilisé avec Cloudflare AI Gateway

Protection contre les attaques en volume

L’une des menaces listées par OWASP est le déni de service du modèle (Model Denial of Service)
Comme pour les applications traditionnelles, les attaques DoS dégradent la qualité de service ou augmentent les coûts d’exploitation du modèle en consommant excessivement les ressources
Ce risque peut être atténué en adoptant des politiques de limitation de débit qui contrôlent le rythme des requêtes sur chaque session

Identification des informations sensibles

Il existe deux cas d’usage autour des informations sensibles, selon que l’on possède le modèle et les données ou que l’on cherche à empêcher les utilisateurs d’envoyer des données à un LLM public
La divulgation d’informations sensibles définie par OWASP se produit lorsqu’un LLM révèle par inadvertance des données confidentielles dans ses réponses, ce qui peut entraîner un accès non autorisé aux données, des atteintes à la vie privée et des violations de sécurité

Prévention des abus du modèle

Les abus du modèle incluent diverses approches, comme la « prompt injection » ou l’envoi de requêtes destinées à provoquer des hallucinations ou à générer des réponses inexactes, offensantes, inappropriées ou hors sujet
La prompt injection est une tentative de manipulation d’un modèle de langage via une entrée spécialement conçue afin de provoquer des réponses non intentionnelles du LLM

Comment utiliser le pare-feu pour l’IA

Les clients entreprises qui utilisent « Application Security Advanced » peuvent utiliser immédiatement Advanced Rate Limiting et Sensitive Data Detection
Les fonctionnalités de validation des prompts du pare-feu pour l’IA sont actuellement en cours de développement et une version bêta devrait être lancée pour les utilisateurs de Workers AI dans les prochains mois

1 commentaires

xguru 2024-03-06

Avis sur Hacker News

On affirme que l’injection de prompt et le jailbreaking sont différents, mais j’ai l’impression que ce débat est déjà perdu. D’après l’article de Cloudflare, l’abus de modèle désigne une catégorie plus large d’abus incluant des approches comme l’injection de prompt. L’injection de prompt se produit lorsqu’un développeur concatène un prompt défini par le développeur avec une entrée utilisateur non fiable. Sans concaténation entre entrée fiable et entrée non fiable, ce n’est pas une injection de prompt. Cette distinction est importante, et un modèle entraîné sur des attaques générales de jailbreaking aura probablement du mal à la détecter.
Le WAF (Web Application Firewall) était une solution de contournement pour des services web que les équipes de sécurité ne pouvaient ni contrôler ni comprendre. Il est tombé en désuétude à cause de problèmes de performances et de la difficulté à le régler pour bloquer efficacement le trafic malveillant. Une approche fondée sur le WAF implique l’aveu d’une ignorance et l’emplacement d’une faiblesse, et le passage vers les modèles n’est pas encore validé ; cela va aussi à l’encontre d’idées comme l’autoprotection applicative réactive.
Je veux une protection pour empêcher que mon site soit scrapé à des fins d’entraînement de l’IA. J’ai déjà l’impression que c’est une bataille perdue, mais j’ai découvert que les personnes attachées à la vie privée pensent la même chose.
Comme pour la plupart des produits de Cloudflare, celui-ci devient plus utile à mesure que davantage de clients l’utilisent et demande moins d’effort manuel par client. La valeur de Cloudflare ne réside pas dans la configuration et les garanties, mais dans la visibilité — presque en temps réel — sur les attaques que tout le monde voit, ainsi que dans son packaging.
Ce produit semble être une très bonne idée. Quand c’est aussi simple que d’ajouter et d’activer un pare-feu, il est plus facile d’attirer l’intérêt et l’adoption que pour d’autres produits de garde-fous. Je me demande jusqu’à quel point un pare-feu LLM générique peut être utile, et selon le modèle et le cas d’usage, combien de personnalisation est nécessaire et possible. Mais cela semble pouvoir se résoudre assez facilement.
À la lecture de ce post, j’ai l’impression que Cloudflare se jette dans la censure et les guerres culturelles. Les utilisateurs payants de Cloudflare paieront l’entreprise pour imposer leurs biais politiques, et les utilisateurs d’IA accuseront Cloudflare d’adhérer à la censure. Cloudflare risque de se retrouver entraîné inutilement dans des batailles politiques.
Ils utilisent de l’IA pour filtrer les requêtes ? Si c’est le cas, ce sera une combinaison divine !
[se penche vers le micro] L’ingrédient secret, ce sont les expressions régulières.
Je réfléchis depuis un moment à faire quelque chose dans le même esprit pour des identifiants de paiement intelligents, dans des situations où un LLM prend des décisions d’achat ou de non-achat, afin d’empêcher les usages abusifs des LLM. L’idée serait de ne fournir un jeton à usage unique (ou quelque chose du genre) que lorsque les identifiants de paiement sont demandés par une chaîne légitime. Si quelqu’un réfléchit à ce domaine, j’aimerais en discuter.
Pendant longtemps, j’ai pensé qu’ils continueraient à courir après le prochain grand coup marketing. Tant mieux, cela laisse plus de place à la concurrence sur les marchés CDN/DNS/WAF pour les entreprises qui se soucient encore de ce genre de choses.