Entre em contato

A segurança da IA ​​não está quebrada, nós é que estamos defendendo as coisas erradas.

Líderes de pensamento

A segurança da IA ​​não está quebrada, nós é que estamos defendendo as coisas erradas.

mm

O setor de cibersegurança tem um padrão: quando surge uma nova tecnologia, imediatamente começamos a construir barreiras ao seu redor. Fizemos isso com a nuvem, fizemos isso com os contêineres e agora estamos fazendo isso com a IA, só que desta vez, as barreiras que estamos construindo estão nos lugares completamente errados.

Entre em qualquer reunião de revisão de segurança empresarial hoje em dia e você ouvirá as mesmas prioridades: proteger modelos de IA, proteção de dados de treinamentoValidação de resultados e implementação de copilotos com inteligência artificial. Os fornecedores estão correndo para vender ferramentas de "segurança de IA" que se concentram exclusivamente em controles em nível de modelo, como mecanismos de proteção, defesas contra injeção imediata e plataformas de monitoramento de modelos.

Mas os atacantes estão usando suas integrações de IA como vias de acesso a todo o resto.

A verdadeira superfície de ataque que ninguém está observando.

Um padrão que observamos consistentemente em ambientes corporativos revela uma história preocupante: equipes de segurança investem pesadamente na proteção de seus ambientes de desenvolvimento de IA: controles de acesso a modelos, estruturas de governança de dados, ferramentas de segurança MLOps. Isso gera uma falsa sensação de segurança de que sua IA está "protegida".

Mas, ao mapear a superfície de ataque real, percebe-se que os chatbots de IA frequentemente possuem tokens OAuth para dezenas de plataformas SaaS, chaves de API com permissões excessivas na nuvem e relações de confiança de identidade que podem criar caminhos diretos, desde uma simples injeção de código até a infraestrutura de produção. Os modelos em si podem ser seguros, mas os ecossistemas em que operam costumam ser extremamente vulneráveis, e este não é um caso isolado.

Atualmente, as empresas utilizam, em média, mais de 130 aplicativos SaaS, com integrações de IA que abrangem provedores de identidade, infraestrutura em nuvem, bancos de dados e sistemas críticos para os negócios. Cada integração representa um caminho potencial para ataques, e cada conexão de API é um limite de confiança que os invasores estão ativamente testando.

O problema não é que nossas ferramentas de segurança de IA estejam defeituosas. É que estamos protegendo componentes individuais enquanto os invasores exploram as conexões entre eles.

Por que a segurança centrada em modelos perde o ponto principal

A abordagem atual para a segurança da IA ​​se baseia em um equívoco fundamental sobre o funcionamento dos ataques modernos. Tratamos a IA como um ativo isolado que precisa de proteção, de forma semelhante à proteção de um banco de dados ou aplicativo web. Mas a IA em produção não existe isoladamente. Ela é um nó em um grafo complexo de identidades, permissões, APIs e fluxos de dados.

Considere uma implementação típica de IA empresarial. Você tem um agente de IA com acesso ao seu Google Workspace. Ele está conectado ao Salesforce por meio de APIs. Está integrado ao Slack para notificações. Extrai dados de buckets do AWS S3. É autenticado pelo Okta ou Azure AD. E aciona fluxos de trabalho no ServiceNow.

A segurança tradicional da IA ​​concentra-se no próprio modelo: sua postura de segurança, validação rápida e segurança da saída. Mas os atacantes estão focados nas integrações: o que eles podem alcançar por meio de contas de serviço comprometidas, para onde podem direcionar seus ataques por meio de manipulações de API e quais limites de confiança podem ultrapassar por meio de integrações exploradas.

O ataque não começa nem termina com o modelo de IA. O modelo é apenas o ponto de entrada.

Os caminhos de ataque não respeitam os limites do produto.

É aqui que a maioria das organizações trava. Elas implantaram ferramentas de segurança que oferecem visibilidade a um único domínio. Uma ferramenta monitora permissões na nuvem. Outra rastreia configurações de SaaS. Uma terceira gerencia a governança de identidades. Uma quarta lida com o gerenciamento de vulnerabilidades.

Cada ferramenta mostra a sua parte do quebra-cabeça. Nenhuma delas mostra como as peças se encaixam.

De acordo com o GartnerAtualmente, as organizações utilizam, em média, mais de 45 ferramentas de segurança. No entanto, apesar desse investimento maciço, os atacantes conseguem encadear com sucesso configurações incorretas em todos esses domínios, pois nenhuma ferramenta isolada consegue visualizar todo o caminho do ataque.

Um atacante não precisa encontrar uma vulnerabilidade crítica no seu modelo de IA. Ele só precisa encontrar uma cadeia de eventos. Talvez seja uma função IAM mal configurada associada ao seu serviço de IA, que tenha permissões para um bucket S3, que por sua vez contém credenciais para um aplicativo SaaS com acesso administrativo ao seu ambiente de produção.

Cada configuração incorreta individual pode ter uma classificação "média" ou "baixa" em suas ferramentas de segurança. Mas, em conjunto? Isso representa uma exposição crítica. E é completamente invisível se você analisar cada domínio de segurança isoladamente.

O Imperativo da Gestão da Exposição

Por isso, a conversa precisa mudar de "segurança da IA" para gerenciamento contínuo da exposição a ameaças em ambientes integrados à IA.

Não basta perguntar se nossos modelos de IA são seguros. As equipes de segurança precisam entender o que um invasor pode realmente alcançar se comprometer uma conta de serviço de IA. Elas precisam ter visibilidade de como configurações incorretas em nuvem, SaaS e sistemas de identidade podem ser encadeadas. Precisam saber como as integrações de IA estão alterando sua superfície de ataque em tempo real. E precisam priorizar os riscos com base na capacidade real de serem atacados, não apenas em pontuações de gravidade.

A maioria dos programas de segurança ainda prioriza os riscos isoladamente, usando pontuações CVSS e listas de verificação de conformidade que ignoram completamente se uma vulnerabilidade é realmente explorável em seu ambiente específico.

Essa discrepância é ainda mais acentuada em sistemas de IA, pois eles estão em constante mudança. Novas integrações são adicionadas semanalmente. As permissões evoluem. As conexões de API se alteram. Sua superfície de ataque do mês passado não é a mesma de hoje, mas sua avaliação de segurança provavelmente é.

Como é, na prática, a segurança com reconhecimento de caminhos de ataque?

Garantir a segurança da IA ​​em produção exige uma abordagem fundamentalmente diferente, e isso se resume a quatro mudanças essenciais de mentalidade.

Primeiro, você precisa de visibilidade unificada em todos os domínios de segurança. Pare de exigir que cada ferramenta de segurança opere isoladamente. Suas ferramentas de segurança na nuvem, governança de identidade, gerenciamento de SaaS e varredura de vulnerabilidades detêm peças do quebra-cabeça do caminho de ataque. Elas precisam compartilhar dados em tempo real para que você possa ver como as configurações incorretas se encadeiam.

Em segundo lugar, adote a simulação contínua de caminhos de ataque. Não espere por testes de penetração ou exercícios de equipe vermelha para descobrir vulnerabilidades. Teste continuamente como um invasor poderia se mover pelo seu ambiente, concentrando-se na explorabilidade real em vez de confiar em pontuações de gravidade teóricas.

Em terceiro lugar, priorize com base no contexto. Um bucket S3 mal configurado não é crítico apenas por ser público. Ele se torna crítico se for público, contiver credenciais com acesso privilegiado e for acessível a partir de um recurso exposto à internet. O contexto importa mais do que qualquer pontuação individual.

Em quarto lugar, priorize a remediação preventiva. Quando sua equipe do SOC começa a investigar um alerta, você já perdeu um tempo de resposta valioso. A defesa moderna exige a capacidade de fechar brechas de segurança antes que elas sejam exploradas, não depois de um incidente.

O aviso que não podemos ignorar

À medida que a IA se torna integrada em todas as camadas da infraestrutura empresarial, a superfície de ataque está se expandindo mais rápido do que as equipes de segurança conseguem analisar manualmente. Estamos adicionando integrações de IA a uma velocidade 10 vezes maior do que a que conseguimos protegê-las.

Se você está protegendo a IA de forma isolada, protegendo o modelo enquanto ignora o ecossistema em que ela opera, você já está em desvantagem. Os invasores não pensam em ferramentas, eles pensam em caminhos. Eles não exploram vulnerabilidades individuais. Eles encadeiam configurações incorretas em todo o seu ambiente.

As empresas que conseguirem proteger a IA com sucesso não serão aquelas que possuírem o maior número de ferramentas de segurança para IA. Serão aquelas que compreenderem que a segurança da IA ​​é inseparável da gestão da exposição em toda a sua superfície de ataque.

A segurança do modelo é o mínimo necessário. O que importa é entender o que um invasor pode alcançar ao comprometer uma integração de IA. Até que as equipes de segurança consigam responder a essa pergunta continuamente, em tempo real e em todo o seu ambiente, elas não estarão protegendo a IA. Estarão apenas torcendo para que as barreiras que construíram estejam nos lugares certos.

Piyush Sharma, cofundador e CEO de TuskiraPiyush traz consigo mais de duas décadas de experiência em cibersegurança, fundamentadas em um bacharelado em Ciência da Computação e um MBA. Empreendedor serial com duas empresas vendidas com sucesso, Piyush ocupou importantes cargos de liderança em produtos e negócios, inclusive na Symantec e na Tenable. Ele também atuou como CEO e cofundador da Accurics, que posteriormente foi adquirida pela Tenable Inc. Inventor talentoso, Piyush detém uma dúzia de patentes em cibersegurança, demonstrando suas contribuições inovadoras para a área.