Elastic avança na segurança do LLM com campos padronizados e integrações

Introdução

Na semana passada, a pesquisadora de segurança Mika Ayenson escreveu uma publicação destacando possíveis estratégias de detecção e uma solução de protótipo de auditoria de conteúdo LLM por meio de um proxy implementado durante a série de eventos OnWeek da Elastic. Esta postagem destacou a importância da pesquisa referente à segurança da tecnologia LLM implementada em diferentes ambientes e o foco da pesquisa que adotamos no Elastic Security Labs.

Dado o ponto de vista exclusivo da Elastic ao alavancar a tecnologia LLM em nossa plataforma para potencializar recursos como o Security AI Assistant, nosso desejo por regras de detecção, integrações e conteúdo de pesquisa mais formais tem crescido. Esta publicação destaca alguns dos avanços recentes que fizemos em integrações de LLM, nossas ideias sobre detecções alinhadas aos padrões da indústria e mapeamentos de campo do ECS.

Estamos comprometidos com uma estratégia de segurança abrangente que proteja não apenas as interações diretas do LLM baseadas no usuário, mas também o ecossistema mais amplo que as cerca. Essa abordagem envolve camadas de oportunidades de engenharia de detecção de segurança para abordar não apenas as solicitações/respostas do LLM, mas também os sistemas e integrações subjacentes usados pelos modelos.

Essas oportunidades de detecção ajudam coletivamente a proteger o ecossistema LLM e podem ser amplamente agrupadas em cinco categorias:

1. Prontidão e resposta: mecanismos de detecção projetados para identificar e mitigar ameaças com base na crescente variedade de interações de LLM para garantir que todas as comunicações sejam auditadas com segurança.
2. Infraestrutura e plataforma: implementação de detecções para proteger a infraestrutura que hospeda LLMs (incluindo dispositivos AI Pin vestíveis), incluindo a detecção de ameaças contra os dados armazenados, atividades de processamento e comunicação com o servidor.
3. API e integrações: detecção de ameaças ao interagir com APIs do LLM e proteção de integrações com outros aplicativos que ingerem saída do modelo.
4. Processos operacionais e dados: monitoramento de processos operacionais (inclusive em agentes de IA) e fluxos de dados, protegendo os dados durante todo o seu ciclo de vida.
5. Conformidade e ética: Alinhar estratégias de detecção com regulamentações e padrões éticos bem adotados pelo setor.

Protegendo o ecossistema LLM: cinco categorias

Outra consideração importante para essas categorias se expande para quem pode abordar melhor os riscos ou quem é responsável por cada categoria de risco referente aos sistemas LLM.

Semelhante aos modelos existentes de Responsabilidade de Segurança Compartilhada , a Elastic avaliou quatro categorias amplas, que serão expandidas ainda mais à medida que continuamos nossa pesquisa sobre estratégias e integrações de engenharia de detecção. Em termos gerais, esta publicação considera proteções de segurança que envolvem os seguintes proprietários de responsabilidade:

• Criadores de LLM: Organizações que estão construindo, projetando, hospedando e treinando LLMs, como OpenAI, Amazon Web Services ou Google
• Integradores LLM: Organizações e indivíduos que integram tecnologias LLM existentes produzidas por criadores LLM em outros aplicativos
• Mantenedores de LLM: Indivíduos que monitoram LLMs operacionais para desempenho, confiabilidade, segurança e casos de uso de integridade e permanecem diretamente envolvidos na manutenção da base de código, infraestrutura e arquitetura de software
• Usuários de segurança: pessoas que procuram ativamente por vulnerabilidades em sistemas por meio de mecanismos e meios de teste tradicionais. Isso pode expandir-se além dos riscos tradicionais discutidos no LLM Top 10 da OWASP para riscos associados ao software e à infraestrutura que envolvem esses sistemas

Essa perspectiva mais ampla mostra uma abordagem unificada para a engenharia de detecção de LLM que começa com a ingestão de dados usando integrações nativas do Elastic; neste exemplo, destacamos o caso de uso do AWS Bedrock Model Invocation.

Integrando logs LLM no Elastic

As integrações elásticas simplificam a ingestão de dados no Elastic de várias fontes, aprimorando nossa solução de segurança. Essas integrações são gerenciadas pelo Fleet no Kibana, permitindo que os usuários implantem e gerenciem dados facilmente dentro do Elastic Agent. Os usuários podem adaptar rapidamente o Elastic a novas fontes de dados selecionando e configurando integrações por meio do Fleet. Para mais detalhes, consulte o blog da Elastic sobre como facilitar a integração dos seus sistemas com a Elastic.

O trabalho inicial da ONWeek realizado pela equipe envolveu uma solução de proxy simples que extraía campos de interações com o Elastic Security AI Assistant. Este protótipo foi implantado junto com o Elastic Stack e consumiu dados de uma solução de fornecedor que não tinha recursos de auditoria de segurança. Embora essa implementação inicial tenha se mostrado conceitualmente interessante, ela levou a equipe a investir tempo na avaliação das integrações Elastic existentes de um de nossos parceiros provedores de nuvem, a Amazon Web Services. Essa metodologia garante acessibilidade simplificada para nossos usuários, oferecendo integrações perfeitas e com apenas um clique para ingestão de dados. Todos os pipelines de ingestão estão em conformidade com os padrões de normalização ECS/OTel, abrangendo conteúdo abrangente, incluindo painéis, em um pacote unificado. Além disso, essa estratégia nos posiciona para aproveitar integrações adicionais existentes, como Azure e GCP, para futuras integrações focadas em LLM.

Seleção de fornecedores e recursos de API

Ao selecionar quais provedores de LLM criar integrações, analisamos os tipos de campos que precisamos ingerir para nossos casos de uso de segurança. Para o conjunto inicial de regras detalhadas aqui, precisávamos de informações como registros de data e hora e contagens de tokens; descobrimos que fornecedores como o Azure OpenAI forneciam filtragem de moderação de conteúdo nos prompts e no conteúdo gerado. LangSmith (parte da ferramenta LangChain) também foi um dos principais concorrentes, pois os dados contêm o tipo de fornecedor usado (por exemplo, OpenAI, Bedrock, etc.) e todos os metadados respectivos. No entanto, isso exigia que o usuário também tivesse o LangSmith configurado. Para esta implementação, decidimos usar logs com suporte próprio de um fornecedor que fornece LLMs.

À medida que nos aprofundamos em possíveis integrações, decidimos escolher o AWS Bedrock, por alguns motivos específicos. Em primeiro lugar, o registro Bedrock tem suporte próprio para Amazon CloudWatch Logs e Amazon S3. Em segundo lugar, o registro é criado especificamente para invocação de modelo, incluindo dados específicos para LLMs (em oposição a outras operações e modelos de aprendizado de máquina), incluindo prompts e respostas, e filtragem de conteúdo/guardrail. Em terceiro lugar, a Elastic já tem um catálogo robusto de integrações com a AWS, então conseguimos criar rapidamente uma nova integração especificamente para logs de invocação do modelo AWS Bedrock. A próxima seção abordará essa nova integração, que você pode usar para capturar seus logs de invocação do modelo Bedrock na pilha Elastic.

Integração do modelo Elastic AWS Bedrock

Overview

A nova integração do Elastic AWS Bedrock para logs de invocação de modelo fornece uma maneira de coletar e analisar dados de serviços da AWS rapidamente, com foco específico no modelo. Essa integração fornece dois métodos principais para coleta de logs: buckets do Amazon S3 e Amazon CloudWatch. Cada método é otimizado para oferecer recursos robustos de recuperação de dados, considerando a relação custo-benefício e a eficiência de desempenho. Usamos esses campos específicos do LLM coletados para fins de engenharia de detecção.

Observação: embora essa integração não abranja todos os campos propostos, ela padroniza os campos existentes do AWS Bedrock na categoria gen_ai. Essa abordagem facilita a manutenção de regras de detecção em várias fontes de dados, minimizando a necessidade de regras separadas para cada fornecedor de LLM.

Configurando o método de coleta de dados de integração

Coletando logs de buckets S3

Essa integração permite a coleta eficiente de logs de buckets do S3 usando dois métodos distintos:

• Notificação SQS: Este é o método preferencial para coleta. Envolve a leitura de eventos de notificação do S3 de uma fila do AWS Simple Queue Service (SQS). Este método é menos dispendioso e proporciona melhor desempenho em comparação à pesquisa direta.
• Sondagem direta de bucket S3: esse método sonda diretamente uma lista de objetos S3 dentro de um bucket S3 e é recomendado somente quando as notificações SQS não podem ser configuradas. Essa abordagem exige mais recursos, mas oferece uma alternativa quando o SQS não é viável.

Coletando logs do CloudWatch

Os logs também podem ser coletados diretamente do CloudWatch, onde a integração acessa todos os fluxos de logs dentro de um grupo de logs especificado usando a API AWS filterLogEvents. Este método é uma alternativa ao uso total de buckets do S3.

Instalação de integração

A integração pode ser configurada dentro do Elastic Agent seguindo as etapas normais de instalação do Elastic.

1. Navegue até a integração do AWS Bedrock
2. Configure queue_url para SQS ou bucket_arn para pesquisa direta do S3.

Configurando guarda-corpos de base rochosa

O AWS Bedrock Guardrails permite que as organizações imponham a segurança definindo políticas que limitam conteúdo prejudicial ou indesejável em interações de LLM. Essas proteções podem ser personalizadas para incluir tópicos negados para bloquear assuntos específicos e filtros de conteúdo para moderar a gravidade do conteúdo em prompts e respostas. Além disso, filtros de palavras e informações confidenciais bloqueiam palavrões e mascaram informações de identificação pessoal (PII), garantindo que as interações estejam em conformidade com os padrões éticos e de privacidade. Esse recurso ajuda a controlar o conteúdo gerado e consumido pelos LLMs e, idealmente, reduz o risco associado a prompts maliciosos.

Observação: outros exemplos de proteção incluem os filtros de conteúdo e resposta do Azure OpenAI, que pretendemos capturar em nossos campos padronizados de LLM propostos para registro independente de fornecedor.

Quando o conteúdo de interação do LLM aciona esses filtros, os objetos de resposta são preenchidos com os campos amazon-bedrock-trace e amazon-bedrock-guardrailAction , fornecendo detalhes sobre o resultado do Guardrails, e campos aninhados indicando se a entrada correspondeu ao filtro de conteúdo. Esse enriquecimento de objeto de resposta com resultados de filtro detalhados melhora a qualidade geral dos dados, o que se torna particularmente eficaz quando esses campos aninhados são alinhados com mapeamentos do ECS.

A importância dos mapeamentos ECS

O mapeamento de campo é uma parte crítica do processo de desenvolvimento de integração, principalmente para melhorar nossa capacidade de escrever regras de detecção de amplo escopo e amplamente compatíveis. Ao padronizar como os dados são ingeridos e analisados, as organizações podem detectar, investigar e responder de forma mais eficaz a possíveis ameaças ou anomalias em logs ingeridos no Elastic e, neste caso específico, logs LLM.

Nosso mapeamento inicial começa investigando os campos fornecidos pelo fornecedor e as lacunas existentes, levando ao estabelecimento de um esquema abrangente adaptado às nuances das operações de LLM. Em seguida, reconciliamos os campos para alinhá-los com nossas convenções semânticas do OpenTelemetry. Esses mapeamentos mostrados na tabela abrangem vários aspectos:

• Campos de interação gerais do LLM: incluem informações básicas, mas críticas, como o conteúdo de solicitações e respostas, contagens de tokens, registros de data e hora e identificadores de usuários, que são fundamentais para entender o contexto e o escopo das interações.
• Campos de métricas de qualidade e relevância do texto: campos que medem a legibilidade, a complexidade e as pontuações de similaridade do texto ajudam a avaliar a qualidade e a relevância das saídas do modelo, garantindo que as respostas não sejam apenas precisas, mas também apropriadas para o usuário.
• Campos de métricas de segurança: esta classe de métricas é importante para identificar e quantificar potenciais riscos de segurança, incluindo correspondências de padrões de regex e pontuações relacionadas a tentativas de jailbreak, injeções de prompt e outras preocupações de segurança, como consistência de alucinação e respostas de recusa.
• Campos de aplicação de políticas: esses campos capturam detalhes sobre ações específicas de aplicação de políticas tomadas durante interações, como bloqueio ou modificação de conteúdo, e fornecem insights sobre os níveis de confiança dessas ações, aprimorando as medidas de segurança e conformidade.
• Campos de análise de ameaças: focados em identificar e quantificar ameaças potenciais, esses campos fornecem uma análise detalhada de pontuações de risco, tipos de ameaças detectadas e as medidas tomadas para mitigar essas ameaças.
• Campos de conformidade: esses campos ajudam a garantir que as interações estejam em conformidade com vários padrões regulatórios, detalhando quaisquer violações de conformidade detectadas e as regras específicas que foram acionadas durante a interação.
• Dez principais campos específicos do OWASP: esses campos são mapeados diretamente para os principais 10 riscos do OWASP para aplicativos LLM, ajudando a alinhar as medidas de segurança com os padrões reconhecidos do setor.
• Campos de análise de sentimento e toxicidade: essas análises são essenciais para avaliar o tom e detectar qualquer conteúdo prejudicial na resposta, garantindo que os resultados estejam alinhados com as diretrizes e padrões éticos. Isso inclui pontuações de sentimento, níveis de toxicidade e identificação de conteúdo inapropriado ou sensível.
• Campos de métricas de desempenho: esses campos medem os aspectos de desempenho das interações do LLM, incluindo tempos de resposta e tamanhos de solicitações e respostas, que são essenciais para otimizar o desempenho do sistema e garantir operações eficientes.

Nota: Veja o resumo para uma tabela estendida de campos propostos.

Esses campos são mapeados por nossas integrações LLM e, por fim, usados em nossas detecções. À medida que continuamos a entender o cenário de ameaças, continuaremos a refinar esses campos para garantir que campos adicionais preenchidos por outros fornecedores de LLM sejam padronizados e refletidos conceitualmente no mapeamento.

Implicações e benefícios mais amplos da padronização

Padronizar campos de segurança dentro do ecossistema LLM (por exemplo, interação do usuário e integração de aplicativos) facilita uma abordagem unificada ao domínio de segurança. A Elastic se esforça para liderar o movimento definindo e promovendo um conjunto de campos padrão. Esse esforço não apenas melhora a postura de segurança de organizações individuais, mas também promove um setor mais seguro.

Integração com ferramentas de segurança: ao padronizar as respostas das ferramentas de segurança relacionadas ao LLM, ele enriquece os campos de análise de segurança que podem ser enviados com o conteúdo original do fornecedor do LLM para uma solução de segurança. Se encadeadas operacionalmente no ecossistema do aplicativo LLM, as ferramentas de segurança podem auditar cada solicitação de invocação e resposta. As equipes de segurança podem então aproveitar esses campos para criar mecanismos de detecção complexos que podem identificar sinais sutis de uso indevido ou vulnerabilidades nas interações do LLM.

Consistência entre fornecedores: insistir para que todos os fornecedores de LLM adotem esses campos padrão impulsiona o objetivo único de proteger aplicativos de forma eficaz, mas de uma forma que estabeleça uma linha de base que todos os usuários do setor possam aderir. Os usuários são incentivados a se alinhar a um esquema comum, independentemente da plataforma ou ferramenta.

Engenharia de detecção aprimorada: com esses campos padrão, a engenharia de detecção se torna mais robusta e a mudança de falsos positivos é reduzida. Engenheiros de segurança podem criar regras eficazes que identifiquem ameaças potenciais em diferentes modelos, interações e ecossistemas. Essa consistência é especialmente importante para organizações que dependem de vários LLMs ou ferramentas de segurança e precisam manter uma plataforma unificada.

Campos específicos do LLM de exemplo: caso de uso do AWS Bedrock

Com base no pipeline de ingestão da integração, nos mapeamentos de campos e nos processadores, os dados do AWS Bedrock são limpos, padronizados e mapeados para campos do Elastic Common Schema (ECS). Os principais campos do Bedrock são então introduzidos no grupo aws.bedrock , que inclui detalhes sobre a invocação do modelo, como solicitações, respostas e contagens de tokens. A integração preenche campos adicionais personalizados para o LLM para fornecer insights mais profundos sobre as interações do modelo, que são posteriormente usadas em nossas detecções.

Exemplos de engenharia de detecção de LLM

Com os campos padronizados e a integração do Elastic AWS Bedrock, podemos começar a elaborar regras de engenharia de detecção que mostram o recurso proposto com complexidade variável. Os exemplos abaixo foram escritos usando ES|QL.

Observação: confira o diretório de busca detection-rules e as regras aws_bedrock para obter mais detalhes sobre essas consultas.

Detecção básica de recusa de conteúdo sensível

Com as políticas e padrões atuais sobre tópicos delicados dentro da organização, é importante ter mecanismos para garantir que os LLMs também cumpram os padrões de conformidade e éticos. As organizações têm a oportunidade de monitorar e capturar casos em que um LLM se recusa diretamente a responder a tópicos delicados.

Detecção de amostra:

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

Descrição da detecção: esta consulta é usada para detectar instâncias em que o modelo se recusa explicitamente a fornecer informações sobre tópicos potencialmente sensíveis ou restritos várias vezes. Combinado com saídas formatadas predefinidas, o uso de frases específicas como "Não posso fornecer nenhuma informação sobre" no conteúdo de saída indica que o modelo foi acionado por um prompt do usuário para discutir algo que ele foi programado para tratar como confidencial ou inapropriado.

Relevância de segurança: monitorar recusas de LLM ajuda a identificar tentativas de sondar o modelo em busca de dados confidenciais ou de explorá-lo de uma maneira que possa levar ao vazamento de informações proprietárias ou restritas. Ao analisar os padrões e a frequência dessas recusas, as equipes de segurança podem investigar se há tentativas direcionadas de violação de políticas de segurança da informação.

Possíveis ataques de negação de serviço ou exaustão de recursos

Devido ao projeto de engenharia dos LLMs ser altamente computacional e intensivo em dados, eles são suscetíveis ao esgotamento de recursos e ataques de negação de serviço (DoS). Padrões de alto uso podem indicar abuso ou atividades maliciosas projetadas para degradar a disponibilidade do LLM. Devido à ambiguidade de correlacionar o tamanho da solicitação de prompt diretamente com a contagem de tokens, é essencial considerar as implicações de contagens altas de tokens em prompts, que nem sempre podem resultar de corpos de solicitação maiores. A contagem de tokens e de caracteres depende do modelo específico, onde cada um pode ser diferente e está relacionado à forma como os embeddings são gerados.

Detecção de amostra:

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

Descrição da detecção: Esta consulta identifica o uso de tokens em alto volume, o que pode ser indicativo de abuso ou tentativa de ataque de negação de serviço (DoS). O monitoramento de contagens de tokens anormalmente altas (entrada ou saída) ajuda a detectar padrões que podem tornar o sistema lento ou sobrecarregar, o que pode levar a interrupções no serviço. Considerando que cada aplicativo pode aproveitar um volume de token diferente, escolhemos um limite simples com base em nossa experiência existente que deve cobrir casos de uso básicos.

Relevância de segurança: esta forma de monitoramento ajuda a detectar possíveis problemas com a disponibilidade e o desempenho do sistema. Ajuda na detecção precoce de ataques DoS ou comportamento abusivo que podem degradar a qualidade do serviço para usuários legítimos. Ao agregar e analisar o uso de tokens por conta, as equipes de segurança podem identificar fontes de tráfego potencialmente malicioso e tomar as medidas adequadas.

Monitoramento de anomalias de latência

Métricas baseadas em latência podem ser um indicador importante de problemas de desempenho subjacentes ou ameaças de segurança que sobrecarregam o sistema. Ao monitorar atrasos no processamento, as organizações podem garantir que os servidores estejam operando com a eficiência esperada.

Detecção de amostra:

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

Descrição da detecção: esta consulta atualizada monitora o tempo que um LLM leva para começar a enviar uma resposta após receber uma solicitação, com foco na latência da resposta inicial. Ele identifica atrasos significativos comparando o início real da resposta com os tempos de resposta típicos, destacando os casos em que esses atrasos podem ser anormalmente longos.

Relevância de segurança: latências anômalas podem ser sintomas de problemas como ataques de rede (por exemplo, DDoS) ou ineficiências do sistema que precisam ser resolvidos. Ao rastrear e analisar métricas de latência, as organizações podem garantir que seus sistemas estejam funcionando de forma eficiente e segura, e podem responder rapidamente a possíveis ameaças que podem se manifestar como atrasos anormais.

Casos de uso de engenharia de detecção avançada de LLM

Esta seção explora possíveis casos de uso que podem ser abordados com uma integração do Elastic Security. Ele pressupõe que esses campos estejam totalmente preenchidos e que os recursos de enriquecimento de auditoria de segurança necessários (por exemplo, Guardrails) tenham sido implementados, seja no AWS Bedrock ou por meio de uma abordagem semelhante fornecida pelo fornecedor do LLM. Em combinação com a fonte de dados disponível e a integração elástica, regras de detecção podem ser criadas com base nessas solicitações e respostas do Guardrail para detectar o uso indevido de LLMs na implantação.

Uploads de modelos maliciosos e escalonamento entre locatários

Uma investigação recente sobre a API Hugging Face Interface revelou um risco significativo em que invasores poderiam carregar um modelo criado maliciosamente para executar código arbitrário. Isso foi conseguido usando um arquivo Python Pickle que, quando desserializado, executou código malicioso incorporado. Essas vulnerabilidades destacam a necessidade de medidas de segurança rigorosas para inspecionar e higienizar todas as entradas em plataformas de IA como serviço (AIAAS), desde o LLM até a infraestrutura que hospeda o modelo e a integração da API do aplicativo. Consulte este artigo para mais detalhes.

Oportunidade potencial de detecção: use campos como gen_ai.request.model.id, gen_ai.request.model.version e prompt gen_ai.completion para detectar interações com modelos anômalos. Monitorar valores ou padrões incomuns nos identificadores do modelo e números de versão, juntamente com a inspeção do conteúdo solicitado (por exemplo, procurar técnicas típicas de serialização do Python Pickle) pode indicar comportamento suspeito. Da mesma forma, uma verificação antes de carregar o modelo usando campos semelhantes pode bloquear o carregamento. O cruzamento de referências de campos adicionais como gen_ai.user.id pode ajudar a identificar operações maliciosas entre locatários que realizam esses tipos de atividades.

URLs não autorizadas e comunicação externa

À medida que os LLMs se tornam mais integrados aos ecossistemas operacionais, sua capacidade de interagir com recursos externos, como e-mail ou webhooks, pode ser explorada por invasores. Para se proteger contra essas interações, é importante implementar regras de detecção que possam identificar atividades suspeitas ou não autorizadas com base nas saídas do modelo e nas integrações subsequentes.

Possível oportunidade de detecção: use campos como gen_ai.completion e gen_ai.security.regex_pattern_count para selecionar URLs externos maliciosos e webhooks. Esses padrões de regex precisam ser predefinidos com base em padrões suspeitos bem conhecidos.

Priorização de instruções hierárquicas

Os LLMs são cada vez mais usados em ambientes onde recebem instruções de várias fontes (por exemplo, instruções personalizadas do ChatGPT), que nem sempre têm intenções benignas. Esse fluxo de trabalho de criação de seu próprio modelo pode levar a uma série de potenciais vulnerabilidades de segurança se o modelo tratar todas as instruções com a mesma importância e elas não forem verificadas. Referência aqui.

Oportunidade potencial de detecção: monitore campos como gen_ai.model.instructions e gen_ai.completion para identificar discrepâncias entre as instruções fornecidas e as respostas dos modelos, o que pode indicar casos em que os modelos tratam todas as instruções com a mesma importância. Além disso, analise o gen_ai.similarity_score para discernir o quão semelhante a resposta é à solicitação original.

Detecções estendidas com tipos de regras elásticas adicionais

Esta seção apresenta técnicas adicionais de engenharia de detecção usando alguns dos tipos de regras do Elastic, Limite, Correspondência de Indicador e Novos Termos para fornecer uma postura de segurança mais diferenciada e robusta.

• Regras de limite: identifique a alta frequência de solicitações negadas em um curto período de tempo, agrupadas por gen_ai.user.id , que podem ser indicativas de tentativas de abuso. (por exemplo LLM04 da OWASP)
• Regras de correspondência de indicadores: corresponda a indicadores fornecidos por informações sobre ameaças maliciosas conhecidas, como o ID do usuário do LLM, como gen_ai.user.id , que contém esses atributos do usuário. (por exemplo arn:aws:iam::12345678912:user/thethreatactor)
• Novas regras de termos: detecte termos novos ou incomuns em prompts de usuário que possam indicar atividades usuais fora do uso normal da função do usuário, potencialmente indicando novos comportamentos maliciosos.

Resumo

A Elastic é pioneira na padronização de campos baseados em LLM em todo o cenário de IA generativa para permitir detecções de segurança em todo o ecossistema. Esta iniciativa não apenas se alinha com nossos aprimoramentos contínuos em estratégias de integração e segurança de LLM, mas também dá suporte à nossa ampla estrutura de segurança que protege tanto as interações diretas do usuário quanto as arquiteturas de sistema subjacentes. Ao promover uma linguagem uniforme entre fornecedores de LLM para recursos aprimorados de detecção e resposta, pretendemos proteger todo o ecossistema, tornando-o mais seguro e confiável. A Elastic convida todas as partes interessadas do setor, criadores, mantenedores, integradores e usuários, a adotar essas práticas padronizadas, fortalecendo assim as medidas de segurança coletiva e promovendo proteções em todo o setor.

À medida que continuamos adicionando e aprimorando nossas integrações, começando com o AWS Bedrock, estamos elaborando estratégias para alinhar outras integrações baseadas em LLM aos novos padrões que definimos, abrindo caminho para uma experiência unificada em todo o ecossistema Elastic. A sobreposição perfeita com os recursos existentes do Elasticsearch permite que os usuários aproveitem pesquisas e análises sofisticadas diretamente nos dados do LLM, direcionando os fluxos de trabalho existentes de volta às ferramentas com as quais os usuários se sentem mais confortáveis.

Confira a Avaliação de Segurança do LLM, que se aprofunda nesses tópicos.

O lançamento e o tempo de amadurecimento de todos os recursos ou funcionalidades descritos neste artigo permanecem a exclusivo critério da Elastic. Os recursos ou funcionalidades não disponíveis no momento poderão não ser entregues ou não chegarem no prazo previsto.