Programas maliciosos de IA estão forçando a extensão do conceito de Confiança Zero ao código.

A segurança de software sempre foi construída em torno do desenvolvimento humano. Os humanos costumavam escrever, revisar e publicar código. Agora, as máquinas estão assumindo essas tarefas.

Em um artigo de pesquisa recente, a Anthropic relatou que mais de 80% do código incorporado em seu banco de dados de produtividade é de autoria de seu modelo de IA , Cloud.

As mesmas funcionalidades que aumentam a produtividade dos desenvolvedores estão mudando a economia dos ataques cibernéticos.

Enquanto os adversários ainda estão identificando o alvo, as máquinas podem gerar cargas maliciosas, testar variantes, adaptar o código a diferentes ambientes e repetir o processo a uma velocidade que o software de segurança não consegue acompanhar.

A velocidade anula os controles de segurança.

A maioria dos fluxos de trabalho de segurança de software empresarial pressupõe um período de revisão. O código é escrito, verificado, testado, aprovado e implementado. Se algo suspeito ocorrer posteriormente, as equipes de segurança investigam e respondem.

Esse modelo falha quando o programa passa de mera orientação para execução em questão de minutos.

O código gerado por IA pode ser transformado em scripts, dependências, tarefas de automação ou alterações de infraestrutura quase instantaneamente. Enquanto isso, os agentes de desenvolvimento podem modificar arquivos, resolver pacotes e executar comandos.

Os revisores humanos não fazem mais parte do processo.

Os atacantes podem usar os mesmos mecanismos para gerar vulnerabilidades, testar técnicas de evasão e modificar o comportamento de cargas maliciosas para diferentes alvos. Isso cria maior versatilidade com menos indicadores estáveis ​​que os defensores possam identificar.

Embora a análise baseada em IA possa aprimorar a triagem, ela frequentemente produz probabilidades, não políticas. E na velocidade das máquinas, "provavelmente suspeito" não é suficiente. Portanto, a necessidade de regras e estruturas de governança para IA está se tornando cada vez mais urgente.

As máquinas estão mudando o modelo de ataque.

Os atacantes humanos não desaparecerão, mas uma parte maior da cadeia de ataques agora é realizada por máquinas.

A inteligência artificial pode automatizar o reconhecimento, acelerar a descoberta de vulnerabilidades, gerar código de exploração, reescrever payloads maliciosos e adaptar sequências de comandos ao ambiente alvo. Mas a maioria das medidas defensivas são projetadas levando em conta as limitações humanas: infraestrutura reutilizada, atalhos e padrões rastreáveis. Essas limitações não se aplicam a ataques automatizados.

A carga maliciosa gerada pela máquina pode não corresponder a uma assinatura conhecida ou ter uma reputação consolidada. Ela pode ser criada, usada brevemente e descartada em seguida. Mas o malware com inteligência artificial precisa interagir com o ambiente alvo para atingir seu objetivo. Seu comportamento não pode ocultar sua intenção; ele precisa acessar recursos e alterar o ambiente de maneiras que impulsionem o ataque.

O que um código malicioso pode fazer é criar o sinal de segurança mais duradouro.

A área de segurança precisa fazer uma pergunta diferente.

A segurança da cadeia de suprimentos de software melhorou, mas grande parte dela ainda verifica as características de impacto antes da execução, em vez de controlar a própria execução.

Listas de componentes de software (SBOMs), assinaturas e código-fonte oferecem às equipes de segurança maior confiança na composição, origem e data de compilação do código. No entanto, conhecer o código-fonte não revela o que o programa fará quando executado.

Um programa pode passar por todas essas verificações e ainda assim apresentar riscos. Mesmo o impacto de um processo de compilação legítimo pode violar as políticas durante a execução, enquanto um script gerado por IA pode concluir sua tarefa pretendida de uma forma que comprometa dados ou sistemas. Consequentemente, uma lista de dependências limpa não é garantia de comportamento seguro, o que destaca a importância de não comprometer os padrões de programação, mesmo com ferramentas de IA.

A divulgação após a implementação ocorre tarde demais.

A detecção e a resposta ainda são necessárias, mas intervêm depois que a ameaça já se infiltrou no ambiente. Quando o comportamento suspeito se torna visível, o malware pode já ter acessado informações confidenciais, alterado estados do sistema, aberto conexões de rede ou estabelecido pontos de continuidade.

A inteligência artificial reduz significativamente esse período. O código pode ser criado, modificado e implementado muito mais rapidamente do que os humanos conseguem revisá-lo. Aguardar o surgimento de evidências pós-execução dá aos atacantes ampla margem de manobra.

Precisamos antecipar o processo de tomada de decisão. Em vez de perguntar: "Podemos conter este software se ele apresentar mau funcionamento?", a pergunta deveria ser: "Esse comportamento deveria ser permitido em primeiro lugar?".

Isso não significa substituir os controles existentes, mas sim mudar a localização do portão de segurança crítico.

Confiança zero em instruções de programação

O princípio de Confiança Zero transformou a segurança organizacional ao rejeitar a confiança implícita. Usuários, dispositivos, sessões e solicitações de acesso não são considerados confiáveis ​​simplesmente por parecerem familiares; todos devem ser verificados em relação às políticas estabelecidas.

A implementação do software requer o mesmo nível de verificação.

Não se deve confiar em código simplesmente por ele vir de um repositório conhecido, ser assinado por uma editora reconhecida, ter passado por um processo de compilação rigoroso ou não ter apresentado comportamento malicioso anteriormente. Esses são indicadores úteis, mas não conclusivos.

O princípio Zero Trust for Code aborda esse problema. Antes de qualquer programa ser executado, seu comportamento esperado deve ser avaliado em relação às políticas. Se o comportamento for aceitável, a execução pode continuar. Caso contrário, o elemento deve ser bloqueado, restringido, colocado em quarentena ou encaminhado para revisão. Essa necessidade destaca a importância de estabelecer regras e estruturas claras para a inteligência artificial que vão além de meras políticas.

As organizações podem começar definindo cada caminho pelo qual o código entra no ambiente ou é executado com privilégios significativos. Isso inclui canais formais de desenvolvimento, como repositórios, pacotes de código aberto, contêineres e pipelines de integração contínua/implantação contínua (CI/CD), bem como anexos de e-mail, arquivos baixados, macros, extensões de navegador, instaladores de endpoint, integrações de terceiros e scripts injetados por meio de ferramentas de IA ou automação.

Em seguida, é crucial identificar onde esses caminhos dependem de confiança herdada. Se a execução for permitida porque o software veio de uma fonte confiável, foi assinado, passou por um processo de compilação ou não possui histórico malicioso, esse controle é incompleto. O comportamento ainda precisa ser avaliado antes que o elemento possa ser executado. Isso também destaca a vulnerabilidade à vulnerabilidade decorrente da crescente dependência de fornecedores de IA.

À medida que a inteligência artificial assume cada vez mais a tarefa de criar códigos legítimos e maliciosos, as organizações não podem mais presumir que códigos que passam nas verificações atuais devam ser executados. A implementação deve se tornar uma decisão de segurança bem ponderada.

Listamos os melhores pacotes de segurança para internet para PCs, Macs e dispositivos móveis.