Elastic améliore la sécurité du LLM avec des champs et des intégrations standardisés

Introduction

La semaine dernière, le chercheur en sécurité Mika Ayenson a rédigé une publication mettant en évidence des stratégies de détection potentielles et un prototype de solution d'audit de contenu LLM via un proxy mis en œuvre lors de la série d'événements OnWeek d'Elastic. Ce billet soulignait l'importance de la recherche relative à la sécurité de la technologie LLM mise en œuvre dans différents environnements, et l'axe de recherche que nous avons adopté à Elastic Security Labs.

Étant donné le point de vue unique d'Elastic qui exploite la technologie LLM dans notre plateforme pour alimenter des capacités telles que l' assistant Security AI, notre désir de disposer de règles de détection plus formelles, d'intégrations et de contenu de recherche s'est accru. Cette publication met en lumière certaines des avancées récentes que nous avons réalisées dans les intégrations LLM, nos réflexions sur les détections alignées sur les normes de l'industrie et les mappages de champs ECS.

Nous nous sommes engagés à mettre en place une stratégie de sécurité globale qui protège non seulement les interactions directes entre les utilisateurs du programme LLM, mais aussi l'écosystème plus large qui les entoure. Cette approche implique des couches d'opportunités d'ingénierie de détection de la sécurité pour traiter non seulement les demandes/réponses LLM mais aussi les systèmes sous-jacents et les intégrations utilisées par les modèles.

Ces possibilités de détection contribuent collectivement à sécuriser l'écosystème du LLM et peuvent être regroupées en cinq catégories :

1. Rapidité et réaction: Mécanismes de détection conçus pour identifier et atténuer les menaces sur la base de la variété croissante des interactions LLM afin de garantir que toutes les communications sont vérifiées en toute sécurité.
2. Infrastructure et plateforme: Mise en œuvre de détections pour protéger l'infrastructure hébergeant les LLM (y compris les dispositifs d'IA Pin portables), y compris la détection des menaces contre les données stockées, les activités de traitement et la communication avec les serveurs.
3. API et intégrations: Détection des menaces lors de l'interaction avec les API LLM et protection des intégrations avec d'autres applications qui ingèrent les résultats du modèle.
4. Processus opérationnels et données: Surveillance des processus opérationnels (y compris dans les agents d'IA) et des flux de données tout en protégeant les données tout au long de leur cycle de vie.
5. Conformité et éthique: Alignement des stratégies de détection sur les réglementations sectorielles et les normes éthiques en vigueur.

Sécuriser l'écosystème du LLM : cinq catégories

Une autre considération importante pour ces catégories est de savoir qui est le mieux à même de traiter les risques ou qui est responsable de chaque catégorie de risque concernant les systèmes de gestion du cycle de vie.

À l'instar des modèles existants de responsabilité partagée en matière de sécurité, Elastic a évalué quatre grandes catégories, qui seront éventuellement développées au fur et à mesure que nous poursuivons nos recherches sur les stratégies d'ingénierie de détection et les intégrations. D'une manière générale, cette publication considère les mesures de protection de la sécurité qui impliquent les détenteurs de responsabilité suivants :

• Créateurs de LLM: Organisations qui construisent, conçoivent, hébergent et forment des LLM, telles que OpenAI, Amazon Web Services ou Google.
• Intégrateurs LLM: Organisations et personnes qui intègrent les technologies LLM existantes produites par les créateurs LLM dans d'autres applications.
• Les mainteneurs de LLM: Les personnes qui contrôlent les LLM opérationnels en termes de performance, de fiabilité, de sécurité et d'intégrité et qui restent directement impliquées dans la maintenance de la base de code, de l'infrastructure et de l'architecture logicielle.
• Utilisateurs de la sécurité: Les personnes qui recherchent activement des vulnérabilités dans les systèmes par le biais de mécanismes et de moyens de test traditionnels. Cela peut aller au-delà des risques traditionnels évoqués dans le Top 10 LLM de l'OWASP et englober les risques associés aux logiciels et à l'infrastructure entourant ces systèmes.

Cette perspective plus large met en évidence une approche unifiée de l'ingénierie de détection LLM qui commence par l'ingestion de données à l'aide d'intégrations Elastic natives ; dans cet exemple, nous mettons en évidence le cas d'utilisation AWS Bedrock Model Invocation.

Intégration des logs LLM dans Elastic

Les intégrations Elastic simplifient l'ingestion de données dans Elastic à partir de diverses sources, ce qui améliore en fin de compte notre solution de sécurité. Ces intégrations sont gérées par Fleet dans Kibana, ce qui permet aux utilisateurs de déployer et de gérer facilement les données au sein d'Elastic Agent. Les utilisateurs peuvent rapidement adapter Elastic à de nouvelles sources de données en sélectionnant et en configurant des intégrations via Fleet. Pour plus de détails, consultez le blog d 'Elastic sur la facilitation de l'intégration de vos systèmes avec Elastic.

Le travail initial de l'équipe ONWeek a consisté en une simple solution de proxy qui a extrait des champs des interactions avec l'assistant IA d'Elastic Security. Ce prototype a été déployé parallèlement à la pile Elastic et a consommé des données provenant d'une solution fournisseur qui ne disposait pas de capacités d'audit de sécurité. Si cette première mise en œuvre s'est avérée intéressante sur le plan conceptuel, elle a incité l'équipe à consacrer du temps à l'évaluation des intégrations Elastic existantes chez l'un de nos partenaires fournisseurs de services en nuage, Amazon Web Services. Cette méthodologie garantit une accessibilité simplifiée pour nos utilisateurs, en offrant des intégrations transparentes et en un seul clic pour l'ingestion de données. Tous les pipelines d'acquisition sont conformes aux normes de normalisation ECS/OTel, englobant un contenu complet, y compris des tableaux de bord, dans un paquet unifié. En outre, cette stratégie nous permet de tirer parti d'autres intégrations existantes, telles qu'Azure et GCP, pour de futures intégrations axées sur le LLM.

Sélection des fournisseurs et capacités API

Lorsque nous avons choisi les fournisseurs de LLM pour lesquels nous allions créer des intégrations, nous avons examiné les types de champs que nous devions ingérer pour nos cas d'utilisation de la sécurité. Pour le premier ensemble de règles présenté ici, nous avions besoin d'informations telles que l'horodatage et le nombre de jetons ; nous avons constaté que des fournisseurs tels qu'Azure OpenAI offraient un filtrage de modération du contenu sur les messages-guides et le contenu généré. LangSmith (qui fait partie de l'outil LangChain) était également en tête de liste, car les données contiennent le type de fournisseur utilisé (par exemple, OpenAI, Bedrock, etc.) et toutes les métadonnées correspondantes. Cependant, cela nécessite que l'utilisateur ait également installé LangSmith. Pour cette mise en œuvre, nous avons décidé d'utiliser des journaux pris en charge par une première partie, provenant d'un fournisseur qui propose des LLM.

Au fur et à mesure que nous approfondissions les intégrations potentielles, nous avons décidé d'opter pour AWS Bedrock, pour quelques raisons spécifiques. Tout d'abord, Bedrock Logging a un support de première partie pour Amazon CloudWatch Logs et Amazon S3. Deuxièmement, la journalisation est conçue spécifiquement pour l'invocation de modèles, y compris les données spécifiques aux LLM (par opposition à d'autres opérations et modèles d'apprentissage automatique), y compris les invites et les réponses, et le filtrage des garde-fous/contenus. Troisièmement, Elastic dispose déjà d'un solide catalogue d' intégrations avec AWS, nous avons donc pu créer rapidement une nouvelle intégration pour les journaux d'invocation du modèle AWS Bedrock en particulier. La section suivante se penchera sur cette nouvelle intégration, que vous pouvez utiliser pour capturer les journaux d'invocation de votre modèle Bedrock dans la pile Elastic.

Intégration du modèle Elastic AWS Bedrock

Overview

La nouvelle intégration Elastic AWS Bedrock pour les journaux d'invocation de modèles permet de collecter et d'analyser rapidement les données des services AWS, en se concentrant spécifiquement sur le modèle. Cette intégration offre deux méthodes principales pour la collecte des journaux : Amazon S3 buckets et Amazon CloudWatch. Chaque méthode est optimisée pour offrir des capacités de recherche de données robustes tout en tenant compte de la rentabilité et de l'efficacité des performances. Nous utilisons ces champs spécifiques au LLM à des fins d'ingénierie de détection.

Note : Bien que cette intégration ne couvre pas tous les champs proposés, elle standardise les champs AWS Bedrock existants dans la catégorie gen_ai. Cette approche facilite la mise à jour des règles de détection dans les différentes sources de données, réduisant ainsi la nécessité de règles distinctes pour chaque fournisseur de LLM.

Configuration de la méthode de collecte des données d'intégration

Collecte de journaux à partir de buckets S3

Cette intégration permet une collecte efficace des logs à partir des buckets S3 à l'aide de deux méthodes distinctes :

• Notification SQS: C'est la méthode préférée pour la collecte. Il s'agit de lire les événements de notification S3 à partir d'une file d'attente AWS Simple Queue Service (SQS). Cette méthode est moins coûteuse et offre de meilleures performances que le sondage direct.
• Interrogation directe d'un seau S3: Cette méthode interroge directement une liste d'objets S3 à l'intérieur d'un seau S3 et n'est recommandée que lorsque les notifications SQS ne peuvent pas être configurées. Cette approche est plus gourmande en ressources, mais elle constitue une alternative lorsque la SQS n'est pas réalisable.

Collecte de journaux à partir de CloudWatch

Les journaux peuvent également être collectés directement à partir de CloudWatch, où l'intégration permet d'accéder à tous les flux de journaux au sein d'un groupe de journaux spécifié à l'aide de l'API AWS filterLogEvents. Cette méthode est une alternative à l'utilisation des buckets S3.

Installation d'intégration

L'intégration peut être mise en place dans l'agent Elastic en suivant les étapes normales d'installation d' Elastic.

1. Naviguez vers l'intégration AWS Bedrock
2. Configurez le site queue_url pour SQS ou bucket_arn pour l'interrogation directe de S3.

Configuration des garde-corps en roche-mère

Les garde-fous AWS Bedrock permettent aux organisations d'appliquer la sécurité en définissant des politiques qui limitent le contenu nuisible ou indésirable dans les interactions LLM. Ces garde-fous peuvent être personnalisés pour inclure des sujets interdits afin de bloquer des sujets spécifiques et des filtres de contenu pour modérer la gravité du contenu des messages-guides et des réponses. En outre, les filtres de mots et d'informations sensibles bloquent les blasphèmes et masquent les informations personnelles identifiables (IPI), garantissant ainsi que les interactions respectent les normes éthiques et de confidentialité. Cette fonction permet de contrôler le contenu généré et consommé par les LLM et, idéalement, de réduire le risque associé aux messages malveillants.

Note : d'autres exemples de garde-fous incluent les filtres de contenu et de réponse d'Azure OpenAI, que nous visons à capturer dans nos champs normalisés LLM proposés pour l'enregistrement indépendant du fournisseur.

Lorsque le contenu de l'interaction LLM déclenche ces filtres, les objets de réponse sont remplis avec les champs amazon-bedrock-trace et amazon-bedrock-guardrailAction, fournissant des détails sur le résultat de Guardrails, et des champs imbriqués indiquant si l'entrée correspond au filtre de contenu. Cet enrichissement de l'objet de la réponse avec des résultats de filtrage détaillés améliore la qualité globale des données, ce qui est particulièrement efficace lorsque ces champs imbriqués sont alignés sur les mappages ECS.

L'importance des correspondances ECS

La cartographie des champs est un élément essentiel du processus de développement de l'intégration, principalement pour améliorer notre capacité à rédiger des règles de détection à large portée et largement compatibles. En normalisant la manière dont les données sont ingérées et analysées, les organisations peuvent plus efficacement détecter, enquêter et répondre aux menaces potentielles ou aux anomalies dans les logs ingérés dans Elastic, et dans ce cas spécifique, les logs LLM.

Notre cartographie initiale commence par l'étude des champs fournis par le vendeur et des lacunes existantes, ce qui conduit à l'établissement d'un schéma complet adapté aux nuances des opérations de LLM. Nous avons ensuite rapproché les champs pour les aligner sur nos conventions sémantiques OpenTelemetry. Les correspondances présentées dans le tableau couvrent différents aspects :

• Champs d'interaction LLM généraux: Il s'agit d'informations de base mais essentielles telles que le contenu des demandes et des réponses, le nombre de jetons, l'horodatage et les identifiants des utilisateurs, qui sont indispensables pour comprendre le contexte et la portée des interactions.
• Champs de mesure de la qualité et de la pertinence du texte: Les champs mesurant la lisibilité du texte, la complexité et les scores de similarité permettent d'évaluer la qualité et la pertinence des résultats du modèle, en veillant à ce que les réponses soient non seulement exactes, mais aussi adaptées à l'utilisateur.
• Champs de métriques de sécurité: Cette catégorie de mesures est importante pour identifier et quantifier les risques potentiels en matière de sécurité, y compris les correspondances de motifs regex et les scores liés aux tentatives de jailbreak, aux injections d'invite et à d'autres problèmes de sécurité tels que la cohérence des hallucinations et les réponses de refus.
• Champs d'application de la politique: Ces champs contiennent des informations sur les mesures spécifiques d'application des politiques prises au cours des interactions, telles que le blocage ou la modification de contenu, et fournissent des indications sur le niveau de confiance de ces mesures, ce qui renforce les mesures de sécurité et de conformité.
• Champs d'analyse des menaces: Axés sur l'identification et la quantification des menaces potentielles, ces champs fournissent une analyse détaillée des scores de risque, des types de menaces détectées et des mesures prises pour atténuer ces menaces.
• Champs de conformité: Ces champs permettent de s'assurer que les interactions sont conformes à diverses normes réglementaires, en détaillant les violations de conformité détectées et les règles spécifiques qui ont été déclenchées au cours de l'interaction.
• Champs spécifiques du Top 10 de l'OWASP: Ces champs correspondent directement aux risques OWASP Top 10 pour les applications LLM, ce qui permet d'aligner les mesures de sécurité sur les normes industrielles reconnues.
• Champs d'analyse des sentiments et de la toxicité: Ces analyses sont essentielles pour évaluer le ton et détecter tout contenu préjudiciable dans la réponse, en veillant à ce que les résultats soient conformes aux lignes directrices et aux normes éthiques. Il s'agit notamment des scores de sentiment, des niveaux de toxicité et de l'identification des contenus inappropriés ou sensibles.
• Champs de mesure de performance: Ces champs mesurent les aspects de performance des interactions LLM, y compris les temps de réponse et la taille des requêtes et des réponses, qui sont essentiels pour optimiser la performance du système et garantir des opérations efficaces.

Note : Voir le gist pour un tableau complet des champs proposés.

Ces champs sont cartographiés par nos intégrations LLM et finalement utilisés dans nos détections. Au fur et à mesure de notre compréhension du paysage des menaces, nous continuerons à affiner ces champs afin de garantir que les champs supplémentaires remplis par d'autres fournisseurs de LLM soient normalisés et reflétés de manière conceptuelle dans la cartographie.

Implications et avantages plus larges de la normalisation

La normalisation des domaines de sécurité au sein de l'écosystème LLM (par exemple, l'interaction avec l'utilisateur et l'intégration des applications) facilite une approche unifiée du domaine de la sécurité. Elastic s'efforce de mener la charge en définissant et en promouvant un ensemble de champs standard. Cet effort permet non seulement d'améliorer le niveau de sécurité des organisations individuelles, mais aussi de promouvoir un secteur plus sûr.

Intégration avec les outils de sécurité: En normalisant les réponses des outils de sécurité liés au LLM, il enrichit les champs d'analyse de sécurité qui peuvent être expédiés avec le contenu original du fournisseur LLM à une solution de sécurité. S'ils sont enchaînés de manière opérationnelle dans l'écosystème de l'application LLM, les outils de sécurité peuvent auditer chaque demande d'invocation et chaque réponse. Les équipes de sécurité peuvent alors exploiter ces champs pour construire des mécanismes de détection complexes capables d'identifier des signes subtils d'abus ou de vulnérabilités dans les interactions LLM.

Cohérence entre les fournisseurs: Insister pour que tous les fournisseurs de LLM adoptent ces champs standard permet d'atteindre un objectif unique : protéger efficacement les applications, mais d'une manière qui établit une base de référence à laquelle tous les utilisateurs de l'industrie peuvent adhérer. Les utilisateurs sont encouragés à s'aligner sur un schéma commun, quelle que soit la plateforme ou l'outil.

Amélioration de l'ingénierie de détection: Grâce à ces champs standard, l'ingénierie de détection devient plus robuste et le nombre de faux positifs diminue. Les ingénieurs en sécurité peuvent créer des règles efficaces qui identifient les menaces potentielles dans différents modèles, interactions et écosystèmes. Cette cohérence est particulièrement importante pour les organisations qui utilisent plusieurs LLM ou outils de sécurité et qui doivent maintenir une plateforme unifiée.

Exemples de champs spécifiques au LLM : Cas d'utilisation AWS Bedrock

En fonction du pipeline d'ingestion, des mappages de champs et des processeurs de l'intégration, les données AWS Bedrock sont nettoyées, normalisées et mappées aux champs Elastic Common Schema(ECS). Les champs principaux de Bedrock sont ensuite introduits dans le groupe aws.bedrock qui comprend des détails sur l'invocation du modèle comme les demandes, les réponses et le nombre de jetons. L'intégration remplit des champs supplémentaires adaptés au LLM afin de fournir des informations plus approfondies sur les interactions du modèle, qui sont ensuite utilisées dans nos détections.

Exemples d'ingénierie de détection LLM

Grâce aux champs normalisés et à l'intégration d'Elastic AWS Bedrock, nous pouvons commencer à élaborer des règles d'ingénierie de détection qui présentent la capacité proposée avec une complexité variable. Les exemples ci-dessous sont écrits en utilisant ES|QL.

Remarque : consultez le répertoire de chasse detection-rules et les règles aws_bedrock pour plus de détails sur ces requêtes.

Détection de base du refus de contenu sensible

Avec les politiques et les normes actuelles sur les sujets sensibles au sein de l'organisation, il est important d'avoir des mécanismes en place pour s'assurer que les LLM adhèrent également aux normes de conformité et d'éthique. Les organisations ont la possibilité de surveiller et de saisir les cas où un MLD refuse directement de répondre à des sujets sensibles.

Détection de l'échantillon:

from logs-aws_bedrock.invocation-*
 | WHERE @timestamp > NOW() - 1 DAY
   AND (
     gen_ai.completion LIKE "*I cannot provide any information about*"
     AND gen_ai.response.finish_reasons LIKE "*end_turn*"
   )
 | STATS user_request_count = count() BY gen_ai.user.id
 | WHERE user_request_count >= 3

Description de la détection: Cette requête est utilisée pour détecter les cas où le modèle refuse explicitement de fournir des informations sur des sujets potentiellement sensibles ou restreints à plusieurs reprises. Associée à des sorties formatées prédéfinies, l'utilisation d'expressions spécifiques telles que "Je ne peux fournir aucune information sur" dans le contenu de la sortie indique que le modèle a été déclenché par une invite de l'utilisateur à discuter d'un sujet qu'il est programmé pour traiter comme confidentiel ou inapproprié.

Pertinence en matière de sécurité: La surveillance des refus de LLM permet d'identifier les tentatives de sonder le modèle à la recherche de données sensibles ou de l'exploiter d'une manière qui pourrait entraîner la fuite d'informations exclusives ou restreintes. En analysant les schémas et la fréquence de ces refus, les équipes de sécurité peuvent déterminer s'il existe des tentatives ciblées de violation des politiques de sécurité de l'information.

Possibilité d'attaques par déni de service ou par épuisement des ressources

En raison de leur conception technique, les LLM sont très gourmands en calculs et en données et sont susceptibles d'épuiser leurs ressources et de subir des attaques par déni de service (DoS). Des schémas d'utilisation élevés peuvent indiquer des abus ou des activités malveillantes visant à dégrader la disponibilité du LLM. En raison de l'ambiguïté de la corrélation directe entre la taille de la demande d'invite et le nombre de jetons, il est essentiel d'examiner les implications d'un nombre élevé de jetons dans les invites, qui ne résultent pas toujours d'un corps de demande plus important. Le nombre de tokens et le nombre de caractères dépendent du modèle spécifique, où chacun peut être différent et est lié à la façon dont les embeddings sont générés.

Détection de l'échantillon:

from logs-aws_bedrock.invocation-*
 | WHERE @timestamp > NOW() - 1 DAY
   AND (
     gen_ai.usage.prompt_tokens > 8000 OR
     gen_ai.usage.completion_tokens > 8000 OR
     gen_ai.performance.request_size > 8000
   )
 | STATS max_prompt_tokens = max(gen_ai.usage.prompt_tokens),
         max_request_tokens = max(gen_ai.performance.request_size),
         max_completion_tokens = max(gen_ai.usage.completion_tokens),
         request_count = count() BY cloud.account.id
 | WHERE request_count > 1
 | SORT max_prompt_tokens, max_request_tokens, max_completion_tokens DESC

Description de la détection: Cette requête identifie l'utilisation d'un grand nombre de jetons, ce qui pourrait indiquer un abus ou une tentative d'attaque par déni de service (DoS). La surveillance d'un nombre anormalement élevé de jetons (en entrée ou en sortie) permet de détecter des schémas susceptibles de ralentir ou de saturer le système, ce qui pourrait entraîner des interruptions de service. Étant donné que chaque application peut utiliser un volume de jetons différent, nous avons choisi un seuil simple basé sur notre expérience existante qui devrait couvrir les cas d'utilisation de base.

Pertinence en matière de sécurité: Cette forme de surveillance permet de détecter les problèmes potentiels liés à la disponibilité et aux performances du système. Il permet de détecter rapidement les attaques DoS ou les comportements abusifs susceptibles de dégrader la qualité du service pour les utilisateurs légitimes. En regroupant et en analysant l'utilisation des jetons par compte, les équipes de sécurité peuvent identifier les sources de trafic potentiellement malveillant et prendre les mesures appropriées.

Surveillance des anomalies de latence

Les mesures basées sur la latence peuvent être un indicateur clé des problèmes de performance sous-jacents ou des menaces de sécurité qui surchargent le système. En surveillant les délais de traitement, les organisations peuvent s'assurer que les serveurs fonctionnent aussi efficacement que prévu.

Détection de l'échantillon:

from logs-aws_bedrock.invocation-*
 | WHERE @timestamp > NOW() - 1 DAY
 | EVAL response_delay_seconds = gen_ai.performance.start_response_time / 1000
 | WHERE response_delay_seconds > 5
 | STATS max_response_delay = max(response_delay_seconds),
         request_count = count() BY gen_ai.user.id
 | WHERE request_count > 3
 | SORT max_response_delay DESC

Description de la détection: Cette requête mise à jour surveille le temps nécessaire à un LLM pour commencer à envoyer une réponse après avoir reçu une requête, en se concentrant sur la latence de la réponse initiale. Il identifie les retards importants en comparant le début effectif de la réponse aux temps de réponse habituels, en mettant en évidence les cas où ces délais peuvent être anormalement longs.

Pertinence en matière de sécurité: Les latences anormales peuvent être symptomatiques de problèmes tels que des attaques de réseau (par exemple, DDoS) ou des inefficacités du système qui doivent être résolues. En suivant et en analysant les mesures de latence, les entreprises peuvent s'assurer que leurs systèmes fonctionnent de manière efficace et sécurisée, et peuvent réagir rapidement aux menaces potentielles qui pourraient se manifester sous la forme de retards anormaux.

Cas d'utilisation de l'ingénierie de détection avancée du LLM

Cette section explore les cas d'utilisation potentiels qui pourraient être traités avec une intégration d'Elastic Security. Il suppose que ces champs sont entièrement remplis et que les fonctions d'enrichissement de l'audit de sécurité nécessaires (par exemple, Guardrails) ont été mises en œuvre, soit dans AWS Bedrock, soit par le biais d'une approche similaire fournie par le fournisseur LLM. En combinaison avec la source de données disponible et l'intégration Elastic, des règles de détection peuvent être élaborées à partir de ces demandes et réponses Guardrail afin de détecter une mauvaise utilisation des LLM en cours de déploiement.

Téléchargements de modèles malveillants et escalade entre locataires

Une enquête récente sur l'API Hugging Face Interface a révélé un risque important où les attaquants pourraient télécharger un modèle malicieusement conçu pour exécuter un code arbitraire. Pour ce faire, il a utilisé un fichier Pickle Python qui, lorsqu'il est désérialisé, exécute un code malveillant intégré. Ces vulnérabilités soulignent la nécessité de mettre en place des mesures de sécurité rigoureuses afin d'inspecter et d'assainir toutes les entrées dans les plateformes d'IA en tant que service (AIAAS), du LLM à l'infrastructure qui héberge le modèle, en passant par l'intégration de l'API de l'application. Reportez-vous à cet article pour plus de détails.

Opportunité de détection potentielle: Utilisez des champs tels que gen_ai.request.model.id, gen_ai.request.model.version, et gen_ai.completion pour détecter les interactions avec des modèles anormaux. La surveillance de valeurs ou de schémas inhabituels dans les identificateurs de modèle et les numéros de version, ainsi que l'inspection du contenu demandé (par exemple, la recherche de techniques de sérialisation Python Pickle typiques) peuvent indiquer un comportement suspect. De même, une vérification avant le téléchargement du modèle à l'aide de champs similaires peut bloquer le téléchargement. Le recoupement de champs supplémentaires tels que gen_ai.user.id peut aider à identifier les opérations malveillantes entre locataires effectuant ce type d'activités.

URL non autorisés et communication externe

Au fur et à mesure que les LLM s'intègrent dans les écosystèmes opérationnels, leur capacité à interagir avec des capacités externes telles que le courrier électronique ou les webhooks peut être exploitée par des attaquants. Pour se protéger contre ces interactions, il est important de mettre en œuvre des règles de détection qui peuvent identifier des activités suspectes ou non autorisées sur la base des résultats du modèle et des intégrations ultérieures.

Opportunité de détection potentielle: Utilisez des champs tels que gen_ai.completion, et gen_ai.security.regex_pattern_count pour trier les URL externes et les webhooks malveillants. Ces modèles de regex doivent être prédéfinis sur la base de modèles suspects bien connus.

Priorité hiérarchique à l'enseignement

Les LLM sont de plus en plus utilisés dans des environnements où ils reçoivent des instructions de diverses sources (par exemple, les instructions personnalisées de ChatGPT), qui n'ont pas toujours des intentions bénignes. Ce processus de construction d'un modèle peut entraîner une série de failles de sécurité potentielles, si le modèle traite toutes les instructions avec la même importance et qu'elles ne sont pas vérifiées. Référence ici.

Opportunité de détection potentielle: Surveillez les champs tels que gen_ai.model.instructions et gen_ai.completion pour identifier les divergences entre les instructions données et les réponses des modèles, ce qui peut indiquer que les modèles traitent toutes les instructions avec la même importance. En outre, analysez le site gen_ai.similarity_score, afin de déterminer dans quelle mesure la réponse est similaire à la demande initiale.

Détections étendues comprenant des types de règles Elastic supplémentaires

Cette section présente des techniques d'ingénierie de détection supplémentaires utilisant certains types de règles d'Elastic, Threshold, Indicator Match et New Terms, afin de fournir une posture de sécurité plus nuancée et plus robuste.

• Règles de seuil: Identifiez une fréquence élevée de demandes refusées sur une courte période, regroupées par gen_ai.user.id, qui pourrait indiquer des tentatives d'abus. (par exemple LLM04 de l'OWASP)
• Règles de correspondance des indicateurs: Faites correspondre les indicateurs fournis par les services d'information sur les menaces malveillantes connues, tels que l'identifiant de l'utilisateur LLM, avec les sites gen_ai.user.id qui contiennent les attributs de l'utilisateur. (par exemple arn:aws:iam::12345678912:user/thethreatactor)
• Règles relatives aux nouveaux termes: Détectez les termes nouveaux ou inhabituels dans les invites des utilisateurs qui pourraient indiquer une activité habituelle en dehors de l'usage normal pour le rôle de l'utilisateur, ce qui pourrait indiquer de nouveaux comportements malveillants.

Résumé

Elastic est un pionnier de la normalisation des champs basés sur le LLM dans le paysage de l'IA générative afin de permettre des détections de sécurité dans l'ensemble de l'écosystème. Cette initiative s'inscrit non seulement dans le cadre de nos améliorations continues des stratégies d'intégration et de sécurité du LLM, mais elle soutient également notre vaste cadre de sécurité qui protège à la fois les interactions directes avec les utilisateurs et les architectures sous-jacentes du système. En promouvant un langage uniforme parmi les fournisseurs de LLM pour améliorer les capacités de détection et de réponse, nous visons à protéger l'ensemble de l'écosystème, en le rendant plus sûr et plus fiable. Elastic invite tous les acteurs du secteur, créateurs, mainteneurs, intégrateurs et utilisateurs, à adopter ces pratiques normalisées, renforçant ainsi les mesures de sécurité collective et faisant progresser les protections à l'échelle du secteur.

Alors que nous continuons à ajouter et à améliorer nos intégrations, en commençant par AWS Bedrock, nous élaborons une stratégie pour aligner d'autres intégrations basées sur LLM sur les nouvelles normes que nous avons établies, ouvrant ainsi la voie à une expérience unifiée dans tout l'écosystème Elastic. Le chevauchement transparent avec les capacités Elasticsearch existantes permet aux utilisateurs d'exploiter des recherches et des analyses sophistiquées directement sur les données LLM, en ramenant les flux de travail existants vers les outils avec lesquels les utilisateurs sont le plus à l'aise.

Consultez l'évaluation de la sécurité du LLM, qui approfondit ces sujets.

La publication et la date de publication de toute fonctionnalité ou fonction décrite dans le présent article restent à la seule discrétion d'Elastic. Toute fonctionnalité ou fonction qui n'est actuellement pas disponible peut ne pas être livrée à temps ou ne pas être livrée du tout.