Modelagem de Ameaças de Aplicações de Inteligência Artificial
As aplicações de large language models (LLMs) como o ChatGPT sem dúvida conquistaram as notícias, já que todos, desde profissionais de segurança cibernética até estudantes do ensino médio, estão explorando avidamente o poder desses sistemas. Hoje, modelos como o GPT-4, que alimenta o ChatGPT , mostram a promessa que os LLMs têm de dominar o cenário tecnológico, embora, esperançosamente, não dominem o mundo. À medida que esta tecnologia se torna parte integrante da nossa vida cotidiana, é imperativo que implementemos medidas de segurança robustas face à rápida implementação.
Esse desafio me levou a pensar profundamente sobre modelagem de ameaças e pesquisa de vulnerabilidades para esses tipos de LLMs.
Recentemente escrevi sobre Os Principais Riscos para Aplicações de Inteligência Artificial com base no OWASP Top 10 LLM. Aqui pretendo abordar a modelagem de ameaças de uma aplicação de Inteligência Artificial, para esclarecer alguns pontos, entender e mapear possíveis ameaças, e contribuir para uma maior compreensão dos LLMs num contexto de segurança. Também gostaria que esta postagem funcionasse como ponto de partida para qualquer pessoa interessada em construir ou implantar suas próprias aplicações LLM.
O que é modelagem de ameaças?
Conforme definido pelo OWASP Modelagem de Ameaças é:
Um modelo de ameaça é uma representação estruturada de todas as informações que afetam a segurança de uma aplicação. Em essência, é uma visão da aplicação e do seu ambiente através da lente da segurança.
A modelagem de ameaças analisa as representações de uma aplicação para destacar as preocupações sobre as características de segurança e privacidade.
De um alto nível, quando modelamos ameaças, fazemos quatro perguntas principais:
- Em que estamos trabalhando?
- O que pode dar errado?
- O que você irá fazer sobre isso?
- Fizemos um trabalho bom o suficiente?
Uma modelagem de ameaça permite que você adote a visão de um invasor para ver onde os pontos fracos de uma aplicação podem estar presentes.
Um modelo de ameaça é uma excelente maneira de decompor uma aplicação e identificar pontos de entrada, dependências externas, limites de confiança, etc.
Para entender um pouco mais sobre modelagem de ameaças eu também tenho este conteúdo publicado, que explica mais no detalhe as etapas: Modelagem de Ameaças, o primeiro passo para o Desenvolvimento Seguro de Aplicações.
Decompor a Aplicação
A primeira etapa no processo de modelagem de ameaças está relacionada ao entendimento da aplicação e como ela interage com entidades externas. Começamos a modelagem de ameaças com um diagrama de fluxo de dados (DFD). Isso nos dará uma ideia de como seria uma aplicação hipotética e onde deveriam estar os limites de confiança associados. Para ter uma visão geral, usaremos um DFD. Na figura abaixo, há alguns elementos e seus limites de confiança associados:
- External prompt sources (por exemplo, usuários, conteúdo do site, corpos de e-mail, etc.)
- The LLM model itself (por exemplo, GPT4, LLaMA, Claude, etc.)
- Server-side functions (por exemplo, ferramentas e componentes LangChain)
- Private data sources (por exemplo, documentos internos ou bancos de dados)
O limite de confiança TB01 está entre os terminais externos e o próprio LLM. Numa aplicação tradicional, isto seria considerado as “oportunidades de injeção”, onde um atacante poderia enviar código malicioso para manipular uma aplicação. No entanto, os LLMs são únicos porque não devemos considerar apenas a entrada dos usuários como não confiável, mas também a saída dos LLMs como não confiável. O raciocínio é que os utilizadores e fontes externas poderiam convencer o LLM a modificar os seus resultados de forma controlada pelo utilizador. Isso também força o TB01 a ser um limite de confiança bidirecional. Não apenas o usuário pode modificar a entrada, mas a saída pode ser modificada para atacar os usuários. Por exemplo, retornar uma carga útil XSS ao usuário, mas fora de um bloco de código que teria evitado a execução arbitrária.
Controles adequados ao longo do TB02 mitigariam o impacto de um LLM passar a entrada diretamente para uma função exec(); ou modificar a apresentação de uma carga XSS sendo passada de volta ao usuário. Da mesma forma, os controles adequados ao longo do TB03 reduziriam a capacidade do LLM ou de um usuário externo de obter acesso a armazenamentos de dados confidenciais, uma vez que, por natureza, os próprios LLMs não aderem aos controles de autorização internamente.
Determine e Classifique as Ameaças
Agora que temos nosso DFD detalhado, podemos começar com a parte real da enumeração da ameaça. Esta tende a ser a parte mais demorada do exercício.
Para isso faremos o uso de uma metodologia de categorização de ameaças, chamada STRIDE. Se você não conhece, o STRIDE é uma estrutura padrão em exercícios de modelagem de ameaças. Cada letra do nome corresponde a uma categoria de ameaça específica. O STRIDE é extremamente útil para identificar pontos fortes e fracos de um sistema.
Limite de confiança: TB01
Este limite de confiança reside entre os usuários e entidades externas, como sites ou e-mail, e o próprio LLM. Conforme mencionado na seção DFD, TB01 deve ser considerado um limite de confiança bidirecional. Por esse motivo, listaremos as ameaças nos controles relativos ao tráfego de entidades externas, bem como ao tráfego do próprio LLM de volta aos usuários.
As seguintes ameaças são identificadas:
THREAT01 — Modificar prompt do sistema (injeção imediata): Os usuários podem modificar as restrições de prompt no nível do sistema para fazer o “jailbreak” do LLM e substituir os controles anteriores em vigor.
THREAT02 — Modificar os parâmetros LLM (temperatura, comprimento, modelo, etc.): Os usuários podem modificar os parâmetros da API como entrada para o LLM, como temperatura, número de tokens retornados e modelo em uso.
THREAT03 — Inserir informações confidenciais em um site de terceiros (comportamento do usuário): Os usuários podem, consciente ou inconscientemente, enviar informações privadas, como detalhes da HIPAA ou segredos comerciais, para LLMs.
THREAT04 — LLMs não conseguem filtrar informações confidenciais (área de pesquisa aberta): Os LLMs não são capazes de ocultar informações confidenciais. Qualquer coisa apresentada a um LLM pode ser recuperada por um usuário. Esta é uma área aberta de pesquisa.
Limite de confiança: TB02
Esse limite de confiança fica entre o LLM e as funções ou serviços de back-end. Por exemplo, um LLM pode solicitar que uma função de back-end execute alguma ação com base em um prompt recebido. No caso de TB02, queremos ter certeza de que não estamos passando requisições não filtradas do LLM para as funções de back-end. Assim como devemos colocar controles do lado do cliente e do lado do servidor em aplicações web modernas, também devemos colocar controles do lado do cliente e do lado do servidor em aplicações LLM.
Duas ameaças foram identificadas:
THREAT05 — Saída controlada por entrada de prompt (não filtrada): A saída do LLM pode ser controlada por usuários e entidades externas. A aceitação não filtrada da saída do LLM pode levar à execução não intencional de código.
THREAT06 — A saída do lado do servidor pode ser alimentada diretamente no LLM (requer filtro): A entrada irrestrita em funções do lado do servidor pode resultar na divulgação de informações confidenciais ou na falsificação de requisição do lado do servidor (SSRF). Os controles do lado do servidor atenuariam esse impacto.
Limite de confiança: TB03
Este é o último limite de confiança que veremos, TB03. Esse limite de confiança fica entre o LLM e qualquer armazenamento de dados privado que alguém possa ter. Por exemplo, documentação de referência, sites internos, bancos de dados privados, etc. Aqui, queremos garantir que estamos aplicando os controles de autorização necessários e o princípio do menor privilégio fora do LLM, uma vez que os próprios LLMs não podem fazer isso por conta própria.
Neste contexto conseguimos identificar duas ameaças, sendo que uma se repete:
THREAT05 — Saída controlada por entrada de prompt (não filtrada): A saída do LLM pode ser controlada por usuários e entidades externas. A aceitação não filtrada da saída do LLM pode levar à execução não intencional de código.
THREAT07 — Acesso a informações confidenciais: LLMs não têm conceito de autorização ou confidencialidade. O acesso irrestrito a armazenamentos de dados privados permitiria aos usuários recuperar informações confidenciais.
Determinar Contramedidas e Mitigação
Para completar este exercício, aqui estão algumas recomendações/requisitos de alto nível para mitigar as ameaças identificadas.
REQ01: THREAT01 — Modificar prompt do sistema (injeção imediata)
Não podemos fazer muita coisa diretamente, mas podemos mitigar os efeitos posteriores. Certifique-se de que o LLM não seja treinado em dados não públicos ou confidenciais. Além disso, trate todas as saídas do LLM como não confiáveis e aplique as restrições necessárias aos dados ou ações solicitadas pelo LLM, conforme as estratégias de prevenção e mitigação previstas no LLMTOP10 da OWASP — LLM01: Prompt Injection.
REQ02: THREAT02 — Modificar os parâmetros LLM (temperatura, comprimento, modelo, etc.)
Limite a superfície de ataque da API exposta a fontes de prompt externas (usuários, conteúdo do site, corpos de e-mail, etc.). Como sempre, trate a entrada externa como não confiável e aplique filtragem quando apropriado, conforme as estratégias de prevenção e mitigação previstas no LLMTOP10 da OWASP — LLM02: Insecure Output Handling.
REQ03: THREAT03 — Inserir informações confidenciais em um site de terceiros (comportamento do usuário)
Este é um problema de comportamento do usuário, mas podemos educá-los por meio de declarações apresentadas durante o processo de inscrição e por meio de notificações claras e consistentes sempre que um usuário se conectar ao LLM.
REQ04: THREAT04 — LLMs não conseguem filtrar informações confidenciais (área de pesquisa aberta)
Não treine LLMs em dados confidenciais aos quais todos os usuários não deveriam ter acesso. Além disso, não confie nos LLMs para impor controles de autorização às fontes de dados. Em vez disso, aplique esses controles às próprias fontes de dados, conforme as estratégias de prevenção e mitigação previstas no LLMTOP10 da OWASP — LLM06: Sensitive Information Disclosure.
REQ05: THREAT05 — Saída controlada por entrada de prompt (não filtrada)
Trate todas as saídas do LLM como não confiáveis e aplique as restrições apropriadas antes de usar os resultados como entrada para funções adicionais. Isso mitigará o impacto que um prompt criado com códigos maliciosos poderia ter nas funções e serviços do ambiente interno, conforme as estratégias de prevenção e mitigação previstas no LLMTOP10 da OWASP — LLM02: Insecure Output Handling.
REQ06: THREAT06 — A saída do lado do servidor pode ser alimentada diretamente no LLM (requer filtro)
Execute a filtragem apropriada na saída da função do lado do servidor. Se o LLM armazenar a saída para dados de treinamento futuros, certifique-se de que as informações confidenciais sejam higienizadas antes do novo treinamento. Se o LLM retornar a saída da função (em qualquer formato) para um usuário, certifique-se de que as informações confidenciais sejam removidas antes de retornar tais informações, conforme as estratégias de prevenção e mitigação previstas no LLMTOP10 da OWASP — LLM06: Sensitive Information Disclosure.
REQ07: THREAT07 — Acesso a informações confidenciais
Trate o acesso do LLM como se fosse um usuário típico. Aplique controles de autenticação/autorização antes do acesso aos dados. Os LLMs não têm como proteger informações confidenciais de usuários não autorizados, portanto, os controles devem ser colocados aqui, conforme as estratégias de prevenção e mitigação previstas no LLMTOP10 da OWASP — LLM06: Sensitive Information Disclosure.
Conclusão
No geral, este exercício foi bastante frutífero. Temos 7 ameaças de alto nível para resolver. Novamente, isso é apenas para começarmos, percorrendo o processo de modelagem formal de ameaças de uma aplicação LLM.
Espero que este exercício tenha sido útil e tenha permitido que você se preocupe mais com a segurança quando se trata de construir e implantar aplicações com tecnologia LLM.
REFERÊNCIAS:
