A cibersegurança agora funciona como prova de trabalho (Proof of Work)

• O LLM ‘Mythos’ da Anthropic executa simulações complexas de ataque em rede com mais rapidez e precisão do que humanos, e seu acesso é permitido apenas a desenvolvedores centrais selecionados
• Nos testes do AI Security Institute, o Mythos obteve sucesso completo em 3 de 10 execuções de uma simulação de ataque a rede corporativa em 32 etapas, e seu desempenho melhora à medida que o orçamento de tokens aumenta
• O resultado mostra que a segurança está se transformando em uma estrutura em que é preciso investir mais tokens do que o atacante para defender, ou seja, uma competição no estilo prova de trabalho
• Após os ataques à cadeia de suprimentos de LiteLLM e Axios, vêm se espalhando tentativas de substituir dependências open source por LLMs ou de reforçar a segurança investindo tokens
• Na segurança, mais do que a criatividade técnica, o fator decisivo passou a ser o volume de recursos investidos, levando à adição de uma etapa de ‘hardening’ ao processo de desenvolvimento

---

A estrutura em que a segurança funciona como ‘prova de trabalho (Proof of Work)’

• O LLM ‘Mythos’ da Anthropic apresentou desempenho excepcional em tarefas de segurança computacional, a ponto de seu acesso não ser liberado publicamente e ficar restrito apenas a criadores centrais de software
  • O Mythos executa simulações complexas de ataques em rede muito mais rápido do que humanos
  • Na avaliação do AI Security Institute (AISI), também demonstrou uma capacidade de execução de ataques cibernéticos um nível acima dos modelos anteriores
• Na simulação de ataque a rede corporativa em 32 etapas chamada ‘The Last Ones’, o Mythos teve sucesso completo em 3 de 10 tentativas
  • O AISI usou 100 milhões de tokens (cerca de US$ 12.500) em cada tentativa
  • Entre os modelos testados, apenas o Mythos concluiu o ataque inteiro, e o desempenho continuou melhorando conforme o orçamento de tokens aumentava
• O resultado leva a economia da segurança a uma fórmula simples: “para defender, é preciso gastar mais tokens do que o atacante”
  • O reforço da segurança é determinado mais pelo volume de recursos investidos do que pela criatividade
  • Trata-se de uma estrutura semelhante ao mecanismo de prova de trabalho (Proof of Work) das criptomoedas, em que vence quem investe mais recursos computacionais

Implicações da nova economia da segurança

• Reforço da importância do software open source

  • Após os recentes ataques à cadeia de suprimentos de LiteLLM e Axios, surgiram propostas de reimplementar código de dependências com agentes de IA
  • Andrej Karpathy afirmou que “as dependências precisam ser reavaliadas, e funções simples talvez sejam melhores quando implementadas diretamente com LLMs”
  • Se a segurança for proporcional ao volume de tokens investidos, então empresas podem ficar mais seguras ao investir tokens para reforçar a segurança de bibliotecas open source
  • Porém, OSS amplamente usado tem alto valor como alvo, o que também cria incentivo para que atacantes invistam ainda mais recursos

• Adição de uma etapa de ‘hardening’ ao processo de desenvolvimento

  • Hoje, desenvolvedores seguem um processo de duas etapas: desenvolvimento → revisão de código, usando modelos diferentes em cada fase
  • A Anthropic oferece um serviço dedicado de revisão de código (Code Review), com custo de cerca de US$ 15 a US$ 20 por revisão
  • No futuro, o ciclo de três etapas desenvolvimento → revisão → hardening pode se tornar o padrão
    1. Desenvolvimento: implementação de funcionalidades e iteração com base no feedback dos usuários
    2. Revisão: documentação, refatoração e melhoria de qualidade
    3. Hardening: execução de busca automatizada por vulnerabilidades dentro do limite permitido pelo orçamento
  • Na primeira etapa, o fator limitante é o tempo humano; na última, o fator limitante é o custo

Estrutura de custos e os limites da segurança

• Escrever código em si continua sendo barato, mas para garantir segurança é preciso comprar mais tokens do que o atacante
• Mesmo que a eficiência de inferência dos modelos melhore, o custo de reforço da segurança é determinado pelo valor do ataque, o que dificulta uma redução completa de custos
• Como resultado, a segurança está deixando de ser uma questão de criatividade técnica para se tornar uma competição de recursos baseada no mercado

[GN⁺]

Comentários do Hacker News

• O acesso à base de código é o ponto central. O escaneamento de segurança baseado em LLM de hoje é, na prática, algo no nível de um simples script bash, que percorre todos os arquivos jogando prompts do tipo “encontre vulnerabilidades”
  Mas, se o defensor controla todo o código-fonte, isso pode funcionar com muito mais eficiência. Por exemplo, dá para escanear só os arquivos alterados em cada PR ou gastar mais tokens no código relacionado à segurança. O atacante precisa escanear tudo de novo a cada vez, enquanto o defensor pode encontrar preventivamente todas as vulnerabilidades potenciais com uma única varredura
  No fim, existe uma assimetria de custos, e o lado da defesa leva vantagem em eficiência. O atacante precisa completar várias etapas de uma cadeia de exploits, enquanto o defensor só precisa bloquear o elo mais fraco dela

  • Há muitos atacantes e só um defensor; então é difícil aceitar a ideia de que a economia de escala favorece a defesa. Assumir que o código não pode ser acessado não é uma boa prática de segurança. Toda revisão de segurança parte do pressuposto de acesso ao código-fonte
  • Ainda assim, esse tipo de abordagem aumenta o custo de desenvolvimento de software. A postura relaxada de “quem vai mirar justamente na gente?” já não funciona
  • Como foi mencionado recentemente no podcast Security Cryptography Whatever, foi interessante notar que, no momento, “a estratégia de esperar o próximo modelo” parece mais eficiente do que melhorar o harness
  • O problema é que essa abordagem pode escalar um incidente no nível de “o PC de um desenvolvedor foi infectado em um ataque à cadeia de suprimentos” para “vazamento de todo o código-fonte e auditoria automatizada”. Um mundo assim parece criar um ambiente de floresta sombria para startups
  • O defensor precisa reforçar todas as partes, mas o atacante só precisa encontrar uma única vulnerabilidade

• O AI Security Institute (AISI) mencionado no artigo me pareceu interessante, então fui pesquisar, e era uma organização formada principalmente por pessoas vindas do DeepMind ou da OpenAI. Quase não havia gente da indústria de segurança. Por isso, a conclusão de que “para reforçar sistemas é preciso gastar mais tokens” soa um pouco como uma lógica centrada na indústria de IA. Também fico me perguntando por que alternativas como verificação formal (formal verification) não foram mencionadas. Dá para imaginar a NVIDIA usando esse tipo de argumento para vender GPUs

  • Fico curioso sobre quais pesquisadores de segurança mais conhecidos adotariam a posição contrária. Na prática, parece que muitos pesquisadores concordam com essa tese. O foco da discussão agora é se os LLMs representam uma inovação no nível do fuzzing ou algo além disso
  • Só como referência, o AISI é um órgão do governo do Reino Unido, ligado ao Department for Science, Innovation and Technology (DSTI). Ainda assim, o método de análise, como traçar os gráficos de forma puramente linear, deixa um pouco a desejar

• Como disse Tony Hoare, “existem duas formas de projetar software: fazê-lo tão simples que obviamente não tenha deficiências, ou tão complicado que não haja deficiências óbvias”, e essa citação chamou atenção

  • Tornar tudo completamente simples não bloqueia todos os ataques, mas reduzir a superfície de ataque tem um efeito grande. Por exemplo, se o sistema for projetado para sempre verificar assinaturas antes de processar mensagens de rede, fica muito mais difícil aceitar mensagens não assinadas. Muitos sistemas atuais têm um modelo de ameaças mais amplo do que o necessário
  • Mas o critério de “complexidade” é diferente para humanos e para LLMs. Algo que parece complexo para uma pessoa pode ser simples para um LLM. Por isso, fico em dúvida sobre o quanto essa abordagem é válida

• Segurança sempre foi um jogo de quanto dinheiro o outro lado está disposto a gastar. O surgimento dos LLMs não mudou o princípio. A filosofia do Karpathy de “copiar em vez de depender” já existia como um provérbio da linguagem Go. O princípio de que “segurança não se obtém por obscuridade” também é antigo

  • Mas obscuridade (obscurity) não é totalmente inútil. Pode ajudar como uma das várias camadas de defesa. O ideal é fortalecer o sistema assumindo transparência total e, por cima disso, adicionar um pouco de opacidade
  • A ideia de que “é preciso gastar mais tokens do que o atacante usa para conseguir defender” não é nova. Na segurança física já era assim. No fim, mesmo na era da IA, será preciso usar IA para defender de IA. O primeiro passo é revisar os prompts dos modelos de geração de código usados pelos desenvolvedores

• Concordo em grande parte com o artigo. A frase “não marcamos pontos por esperteza” é um pouco perigosa. A essência da cibersegurança continua estando em sistemas humanos. Gastar muito tempo de GPU é necessário, mas, no fim das contas, é a cultura e a disciplina de segurança da organização que decidem o resultado. É preciso um nível de disciplina como o que existe na indústria nuclear ou aeronáutica, geralmente alcançado só depois de acidentes.
  Nesse contexto, este texto de um ano atrás descreve a situação atual quase de forma profética

• Sobre a afirmação de que “para reforçar o sistema é preciso gastar mais tokens do que o atacante”, eu já tive experiência prática escrevendo scripts para automatizar a API da Ticketmaster no passado. Eles reforçaram a defesa com PerimeterX, mas eu contornei isso em três dias. Mais recentemente, também implementei algo parecido para contornar o Cloudflare Turnstile do ChatGPT.
  Foi um exemplo de como produtos de segurança criados com investimentos de dezenas de milhões de dólares acabam sendo, na prática, inúteis
  Post relacionado no HN

• Fico curioso se os incidentes de segurança encontrados por LLMs são realmente vulnerabilidades novas ou apenas uma extensão do conhecimento de segurança que já existia. Se for o segundo caso, por que não conseguimos encontrá-las nós mesmos de forma sistemática?

• O motivo de essa pesquisa parecer Proof of Work é que o AISI afirmou que “quanto mais tokens são usados, mais o desempenho continua aumentando”. Ou seja, parte-se da hipótese de que a taxa de sucesso do ataque é proporcional ao consumo de tokens. Mas o experimento era um cenário de intrusão em rede com 32 etapas, e o único modelo que o completou foi o Mythos. Em bibliotecas de código simples, o ponto de retorno decrescente pode chegar muito mais cedo
  Projetos open source podem fazer com que tanto defensores quanto atacantes gastem muitos tokens, alcançando esse limite mais rapidamente

  • O Mythos não teve sucesso em todas as tentativas, e a rede experimental também não contava com sistemas de defesa reais. Ainda assim, não há motivo para subestimar a IA. O modelo de daqui a três meses estará em outro nível
  • Não entendo muito de cibersegurança, mas parece que o ponto central é a taxa de crescimento do custo em tokens para passar da etapa 32 para a 33. Se a defesa for independente em cada etapa, a probabilidade de sucesso do ataque cai rapidamente como p^N

• No fim, a pergunta é esta — é mais barato proteger uma base de código escrita por humanos ou proteger um código gerado por uma legião de agentes?

• Do jeito atual, jogar um modelo de forma indiscriminada sobre toda a base de código é ineficiente. Pelo que testei, o custo caiu bastante quando ajustei o modelo para explorar de forma estruturada o rastreamento do source até o sink (source-to-sink trace).
  Agora chegamos a uma era em que os sistemas conseguem visualizar o contexto de todo o código e apontar com precisão os pontos de ruptura. Isso deve se tornar um grande ponto de virada para melhorar a qualidade de software