IA na Cibersegurança: Por Que Ela Não Deve Ter a Palavra Final

No momento, você está visualizando IA na Cibersegurança: Por Que Ela Não Deve Ter a Palavra Final

O entusiasmo dos investidores com a inteligência artificial criou uma expectativa enorme: a de que ela vai transformar radicalmente o desenvolvimento de software, a automação e, claro, as operações de cibersegurança. E não dá para negar que muita coisa já mudou. A IA alterou a forma como o software é construído, como os ataques são gerados e a velocidade com que ambos circulam dentro das empresas.

Junto com isso vieram novas promessas para quem defende os sistemas: análises mais rápidas, melhor priorização de alertas e decisões cada vez mais automatizadas. Mas existe um detalhe importante que costuma passar batido nessa conversa. Quando tanto os atacantes quanto os desenvolvedores passam a operar em velocidade de máquina, a prevenção depende menos de previsões “inteligentes” e mais de decisões claras, aplicáveis e baseadas na real intenção do código. É sobre isso que vamos conversar aqui.

Organização de TI

Segurança probabilística não é o bastante

A maioria das ferramentas de segurança, sobretudo as que usam aprendizado de máquina ou grandes modelos de linguagem, é probabilística por natureza. Elas trabalham com likelihoods, ou seja, com probabilidades: este arquivo é provavelmente malicioso, este comportamento é possivelmente suspeito, esta atividade tem alta chance de ser um ataque.

Esse tipo de abordagem funciona muito bem para triagem e investigação. Ajuda os analistas a filtrar o ruído, priorizar alertas e identificar padrões que, de outra forma, passariam despercebidos. O problema é que essas qualidades nem sempre se traduzem em decisões confiáveis de bloqueio ou liberação. Um sistema probabilístico pode simplesmente não oferecer o grau de certeza necessário para definir se um determinado software deve ou não ser executado em um ambiente de produção.

E o cenário só fica mais complicado. Os atacantes hoje geram código polimórfico de uso único, que muda de forma a cada execução. Já os desenvolvedores dependem cada vez mais de automação, de dependências de código aberto e de componentes gerados por IA que atravessam as pipelines sem qualquer revisão humana. Nos dois casos, o volume e a velocidade do software ultrapassam tanto os limites do julgamento humano quanto a confiabilidade da pontuação probabilística. O resultado costuma ser uma lacuna perigosa entre identificar o risco e, de fato, preveni-lo.

Se as decisões de segurança não podem ser tomadas com confiança suficiente no momento da execução, elas precisam se apoiar em algo mais estável do que a probabilidade — e ser aplicadas antes que o código rode. É justamente essa a base da abordagem conhecida como Zero Trust for Code (ou “confiança zero para o código”), em que nenhum software é considerado confiável para executar até que seu comportamento seja avaliado em relação a uma política definida.

A necessidade de controles de segurança explicáveis

À medida que o software se torna mais autônomo, as decisões de segurança também precisam ser mais precisas e confiáveis. Não basta mais detectar anomalias ou atribuir notas de risco. As decisões precisam ser explicáveis, repetíveis e auditáveis. As equipes de segurança precisam entender por que um artefato foi liberado ou bloqueado, se o mesmo artefato produziria o mesmo resultado amanhã e se aquela decisão pode ser defendida diante de uma auditoria de conformidade ou de uma análise de incidente.

E é exatamente nesses três pontos que os modelos probabilísticos costumam tropeçar. Isso não significa que eles sejam ineficazes — muito pelo contrário. Boa parte dos programas modernos de segurança combina análise preditiva com controles baseados em política, usando cada abordagem onde ela rende mais.

O ponto frágil é a variabilidade. Pequenas mudanças nos dados de entrada ou no estado do modelo podem gerar resultados diferentes. Essa variação é perfeitamente aceitável quando o objetivo é apoiar um analista, mas se torna um problema sério quando o que está em jogo é decidir se um código pode ou não rodar em um ambiente regulado. E o risco cresce ainda mais nas cadeias de suprimentos de software, onde uma decisão de confiança afeta não apenas um sistema, mas também todas as dependências downstream, os ambientes de produção e os dados dos clientes.

Quando o tempo é o verdadeiro inimigo

Um caso recente deixou isso bastante claro. No comprometimento da cadeia de suprimentos do LiteLLM, um pacote Python amplamente utilizado foi brevemente modificado para roubar credenciais e estabelecer persistência em ambientes de desenvolvimento. As versões maliciosas ficaram disponíveis por apenas algumas horas — e isso foi mais do que suficiente.

A falha, nesse caso, não foi de detecção, mas de tempo e de confiança. Quando os alertas finalmente puderam ser gerados, o código já havia sido executado, os segredos já estavam expostos e os mecanismos de persistência já estavam instalados. Um modelo probabilístico até poderia sinalizar aquele comportamento depois do ocorrido, mas não tem como reverter a decisão de execução que já aconteceu.

Nada disso, vale dizer, diminui o valor da IA na segurança. Ela é excelente para identificar padrões em grandes volumes de dados, correlacionar sinais, acelerar investigações, apoiar a análise de causa-raiz e reduzir o trabalho manual. Usada do jeito certo, a IA melhora bastante a visibilidade e a resposta, além de ajudar os analistas a entender o que um código pode fazer. O que ela não deve ser é a autoridade final sobre se aquele código tem permissão para executar. Essa responsabilidade exige controles determinísticos e orientados por política.

Saindo da detecção para a prevenção

Aqui está a mudança de mentalidade mais importante. Em vez de perguntar se algo é provavelmente malicioso, a análise determinística de intenção comportamental faz outra pergunta: o que este software é capaz de fazer e esse comportamento está de acordo com a política?

Um malware gerado por IA pode se transformar infinitamente, mudando hashes, strings e estrutura sob demanda. Só que a intenção dele não muda na mesma velocidade que a aparência. Isso acontece porque ele não consegue atingir seu objetivo sem realizar certas categorias de ação, como acessar dados sensíveis, modificar o estado do sistema, estabelecer persistência ou se comunicar com o exterior. Esses objetivos comportamentais tendem a permanecer consistentes mesmo quando o código por baixo muda completamente.

Esse é o coração operacional do Zero Trust for Code: avaliar o que o software é capaz de fazer antes da execução e impor uma decisão de política consistente. Ao analisar o comportamento antes de rodar, as organizações conseguem liberar o software que está de acordo com a política, bloquear aquele que viola as restrições definidas e isolar ou escalar os casos que exigem uma análise mais cuidadosa.

E o ponto mais valioso é a consistência. Quando avaliados sob as mesmas políticas e condições, os artefatos de software devem produzir resultados previsíveis, que podem ser revisados e auditados. É essa previsibilidade que viabiliza uma prevenção confiável. Na prática, isso muda o papel dos controles de segurança: em vez de reagir aos eventos de execução, eles passam a ser os guardiões da própria execução.

Velocidade exige prevenção antes da execução

A IA não está apenas tornando os ataques mais sofisticados; ela está comprimindo os prazos. Sistemas autônomos conseguem absorver dependências, implantar serviços e iniciar ações sem nenhuma intervenção humana. Nesse ambiente, a prevenção precisa acontecer antes da execução, e não depois.

É por isso que o Zero Trust for Code enfatiza a aplicação baseada em política ao lado da análise preditiva, tomando decisões a partir de uma pergunta simples e direta: este artefato de software deveria sequer ter permissão para rodar? Com isso, a execução deixa de ser um evento a ser monitorado e se transforma em um ponto de controle orientado por política.

O futuro é combinação, não escolha

Conforme a IA acelera a criação e a implantação de software, as organizações vão precisar de modelos de segurança capazes de acompanhar esse ritmo sem abrir mão da responsabilização. E aqui vale desfazer um falso dilema: o futuro provavelmente não será uma escolha entre IA e controles determinísticos.

O caminho mais promissor é a combinação dos dois — a inteligência analítica para enxergar e entender, e a política aplicável para decidir e proteger. É essa união que vai permitir às empresas se moverem com rapidez sem sacrificar a confiança. No fim das contas, a IA é uma aliada poderosa para identificar ameaças, mas a decisão final sobre segurança ainda precisa de regras claras, previsíveis e à prova de auditoria.

ChatGPT

Deixe um comentário