IA e Cibersegurança: Novas vulnerabilidades que os CISO precisam de endereçar

Com a rápida implementação da Inteligência Artificial (IA) e dos Modelos de Linguagem de Grande Escala (LLM – Large Language Models) em praticamente todos os setores empresariais e casos de uso, é natural que os CISOs (Chief Information Security Officers) estejam preocupados. Com qualquer nova tecnologia surgem também novas ameaças e tal como as empresas estão a desenvolver, testar e evoluir as suas capacidades de IA, pode ter a certeza de que os cibercriminosos estão a fazer o mesmo.

Embora saibamos que a IA, por natureza, introduz riscos, os vetores de ameaça exatos ainda não estão bem estabelecidos, e muitos são apenas teóricos – sabemos que são possíveis, mesmo que ainda não os tenhamos visto na prática. Como a utilização empresarial da IA ainda é tão recente, a investigação de ameaças e as práticas de mitigação estão numa fase inicial. No entanto, todos os dias, as organizações lançam sistemas vulneráveis, prontos para serem explorados. Basta que alguém repare.

Dada esta incerteza, os CISOs precisam de estar cientes das potenciais ameaças e impactos organizacionais, priorizando a criação de resiliência antes que a utilização da IA ultrapasse a sua tolerância ao risco — ou pior, convide a um ataque.

Como é que a IA generativa afetou a segurança?

Com a IA, a confiança desaparece.

Uma das diferenças fundamentais da IA em relação a outras tecnologias, no que diz respeito à segurança, é que é, por natureza, não fiável. Por exemplo, digamos que criou uma aplicação web. Como a desenvolveu, sabe como funciona e controla-a – logo, pode confiar nela.

Por outro lado, a IA interage e opera em vários conjuntos de dados, aplicações e utilizadores, tanto confiáveis como não confiáveis. Pode ser manipulada para causar estragos, mesmo quando construída com os componentes mais confiáveis.

As organizações estão apenas agora a reconhecer os riscos, e temos observado um padrão de vulnerabilidades recorrentes. Aqui estão algumas delas:

Incorporação de prompts: Na maioria dos casos de IA, os prompts dos utilizadores tornam-se parte do modelo – um facto desconhecido para muitos utilizadores ocasionais. A menos que sejam especificamente excluídos (como no caso do Microsoft Copilot), os prompts são utilizados para treinar o LLM, e os utilizadores devem assumi-lo, a não ser que haja garantias em contrário. Ou seja, se os utilizadores carregarem dados confidenciais para análise, esses dados tornam-se irrevogavelmente parte do conjunto de dados e é praticamente impossível extraí-los. Isto está diretamente relacionado com o conceito de “IA paralela”, onde os colaboradores utilizam LLMs de terceiros sem o conhecimento ou autorização das equipas de TI. Esta prática já levou a sérias fugas de dados, pelo que se deve agir com cautela, mesmo com modelos que afirmam excluir prompts. Formar os utilizadores sobre este facto importante é uma orientação essencial.
Variações de injeção de prompts: À medida que os casos de uso da IA crescem, as variações de compromissos também crescem. Um exemplo é o que a OWASP chama de “injeção de prompts indireta“, quando um atacante assume o controlo da conversa entre a IA e o utilizador. A injeção de prompts entre utilizadores também está a tornar-se mais comum. Nesta variante, em vez de pedir diretamente à IA que faça algo malicioso, os cibercriminosos instruem a IA para realizar ações maliciosas na conta de outro utilizador – como eliminá-la, por exemplo. Esta é uma vulnerabilidade grave causada pela falha em isolar devidamente os dados submetidos por potenciais atacantes dos dados fornecidos por utilizadores confiáveis.
Envenenamento de dados: Os LLMs operam repetindo padrões, mas não conseguem discernir padrões bons de padrões maus. Os atacantes podem contaminar conjuntos de dados para que, com o código ou frase certos, controlem o modelo e direcionem-no para realizar ações maliciosas – e a sua empresa pode nunca saber. Foi o que aconteceu com o chatbot Tay da Microsoft, contaminado por prompts e obrigando a empresa a encerrá-lo rapidamente.
Extração ou inversão de modelos: Neste tipo de ataque, um cibercriminoso pode induzir o modelo a extrair os seus dados, duplicar a funcionalidade ou clonar o próprio modelo. Isto significa que, se treinar o modelo com qualquer dado sensível, os atacantes podem roubar esses dados, mesmo que não tenham acesso direto a eles. Por isso, os modelos treinados com dados confidenciais nunca devem ser expostos a terceiros. Embora este ataque ainda seja teórico, poderia facilmente ser explorado sem a devida segmentação.
Contaminação de dados: Numa situação semelhante, os atacantes podem tirar proveito dos modelos que interagem com dados em tempo real de fontes não confiáveis e intencionalmente contaminar esses dados. Isto introduz uma vasta gama de vulnerabilidades, sendo os resultados incorretos a menor delas. Por exemplo, um LLM que analisa críticas de produtos na Amazon pode ser poluído com críticas falsificadas, resultando em análises e saídas distorcidas. Em alguns casos, agentes LLM expostos a dados maliciosos podem, por sua vez, tornar-se agentes desses dados. Os CISOs devem estar atentos aos dados a que os seus LLMs estão expostos para prevenir isto.
Excesso de agência: Uma das vulnerabilidades mais graves ocorre quando um modelo é autorizado a aceder a funções privilegiadas que um utilizador comum não deveria ter. Isto permite que os utilizadores manipulem o modelo para escalar os seus privilégios e aceder a funções restritas.

Novas ameaças, mesmos fundamentos de segurança

Uma vez que a IA é, em grande parte, de código aberto e amplamente disponível para que qualquer pessoa possa aprender, devemos antecipar mais estes ataques à medida que a sua adoção aumenta exponencialmente. Infelizmente, não são necessários atores estatais sofisticados ou pessoas com vasto conhecimento em cadeias técnicas de exploração profunda.

A boa notícia é que defender-se contra ataques a modelos de IA requer, essencialmente, as mesmas bases de segurança que os CISO têm utilizado durante anos, com algumas nuances novas. Embora já existam alguns frameworks para orientar os programadores – a ISO 42001 padroniza como as organizações devem implementar sistemas de IA, e a Europa acaba de introduzir o AI Act – estes não são suficientemente abrangentes nem aplicáveis de forma holística.

Para as empresas que ainda estão a tentar entender o caminho a seguir, aqui estão algumas práticas recomendadas a considerar:

Dê formação – Eduque os colaboradores sobre os riscos da utilização da IA, mesmo de forma casual, no local de trabalho. Infelizmente, nunca se pode confiar plenamente, e os utilizadores devem abordar cada interação com esse pressuposto.
Priorize a segurança desde a conceção – Os programadores devem pensar cuidadosamente sobre quem e ao quê o modelo vai estar exposto, e como isso pode influenciar o seu comportamento. A segurança deve fazer parte do processo desde o início, e não ser uma reflexão tardia. Não assuma que o modelo se comportará sempre da forma que espera.
Realize modelação de ameaças – Tal como faria com qualquer nova introdução no seu ambiente tecnológico, realize uma análise de ameaças sobre as ferramentas de IA. Identifique a que o modelo tem acesso, a que está exposto e como se espera que interaja com outros componentes ou aplicações. Compreenda os riscos, os fluxos de dados e o panorama de ameaças, e depois implemente fronteiras de confiança.
Considere o acesso multidirecional – Como existem tantos pontos de contacto, a maioria das organizações não percebe a extensão completa do risco. Embora o Utilizador A possa não ter intenções maliciosas, o Utilizador B pode manipular a conta do Utilizador A para controlar o modelo (ameaça horizontal), ou alguém pode manipular o modelo para escalar funcionalidades ou privilégios (ameaça vertical). Onde dois modelos se cruzam – por exemplo, um modelo baseado em texto que interage com um modelo de geração de imagens – abre-se um risco multimodal quando os canais são deixados sem restrições, permitindo a fuga de dados entre si até chegar ao utilizador final.
Implemente segmentação de dados e código – Sempre que expõe um modelo de ML a dados não confiáveis, o modelo torna-se agente desses dados. A solução: segmente os modelos dos dados, utilizando uma abordagem de “gatekeeper” que impeça o modelo de aceder simultaneamente a dados não confiáveis e a funções confiáveis.

Mesmo que os alicerces sejam os mesmos, o cronograma acelerou para muitos CISO. A rápida adoção exige soluções urgentes antes que as coisas saiam completamente do controlo.

David Brauchler é Diretor Técnico, NCC Group NA