Quão bons são os modelos de IA em trabalho de segurança? O que mostram os testes públicos

Quatro grupos de pesquisa publicaram números reais e reproduzíveis sobre o desempenho dos modelos de IA atuais em tarefas de cibersegurança: o Cybench, de uma equipe de Stanford e da UC Berkeley; o CyberSecEval 3, da Meta; o NYU CTF Bench, da NYU Tandon; e o próprio system card do o1 da OpenAI, que avalia seus modelos com base em um framework de preparação (preparedness framework) que a empresa criou exatamente para essa questão. Todos os números abaixo são citados ou calculados a partir desses quatro artigos, com um link para cada um. Nenhum deles conclui que um modelo é um analista de segurança competente. Os quatro são mais interessantes, e mais específicos, do que isso.

Os quatro artigos partem do mesmo exercício de base: o desafio capture-the-flag, um formato que as competições de segurança usam há décadas. Um desafio monta um alvo deliberadamente vulnerável — uma aplicação web, um binário compilado, uma mensagem criptografada, um registro de tráfego de rede capturado — e esconde uma pequena string de texto, a flag, em um local que um competidor só consegue alcançar explorando de fato a falha. Não há crédito parcial por uma boa ideia; ou a flag sai, ou não sai, o que é exatamente o que torna o formato fácil de pontuar automaticamente e comparável entre artigos. Vale dizer claramente que essa é uma tarefa mais restrita do que a maior parte do trabalho de segurança real: um desafio CTF tem um único caminho de solução pretendido, um ambiente fixo que não muda enquanto você trabalha nele, e um resultado fixo de sucesso ou falha, nada disso descrevendo um incidente ao vivo.

Cybench: 40 tarefas, quatro competições reais, um tempo humano de resolução para cada uma

O Cybench (Zhang et al., 2024) reuniu 40 tarefas de nível profissional de capture-the-flag de quatro competições reais de hacking e registrou, para cada tarefa, quanto tempo uma equipe humana levou para resolvê-la — de 11 minutos na tarefa mais fácil a 24 horas e 54 minutos na mais difícil. Esse detalhe importa mais do que parece: ele permite ao artigo relatar não apenas se um modelo resolveu uma tarefa, mas se resolveu tarefas que são de fato difíceis para humanos habilidosos, e não tarefas triviais disfarçadas de exercício de segurança.

Duas coisas com as quais o artigo tem cuidado, e que vale a pena repetir com exatidão. Primeiro, a contaminação: os autores selecionaram tarefas de 2022 a 2024, quase metade lançadas depois da data-limite de treinamento da maioria dos modelos testados, especificamente para reduzir a chance de um modelo ter memorizado um relato público em vez de ter resolvido a tarefa; eles sinalizam uma exceção conhecida, uma tarefa de 2022 resolvida pelo GPT-4o, e explicam por que provavelmente não foi uma simples memorização. Segundo, o suporte dado (scaffolding) muda os números: dar ao Claude 3.5 Sonnet dicas por subtarefa (passos intermediários até a flag, em vez da tarefa inteira de uma vez) elevou seu desempenho medido para 43,9 por cento quando se conta o crédito parcial por subtarefas individuais, contra 17,5 por cento para resolver uma tarefa completa sem orientação. Isso não é o mesmo modelo ficando mais inteligente; é o mesmo modelo respondendo a uma versão mais fácil e mais estruturada da pergunta.

NYU CTF Bench: 200 desafios, seis categorias, majoritariamente na casa de um dígito

O NYU CTF Bench (Shao et al., 2024) reuniu 200 desafios validados de capture-the-flag em seis categorias — criptografia, forense, exploração de binários, engenharia reversa, web e diversos — muitos deles vindos do CSAW, a competição real de cibersegurança organizada por estudantes que a NYU Tandon realiza desde 2003 e que hoje reúne milhares de participantes em cinco regiões globais todos os anos. As taxas de resolução por categoria relatadas para os modelos testados ficaram majoritariamente na casa de um dígito: o GPT-4 resolveu cerca de 5,8 por cento dos desafios no total, o GPT-3.5 cerca de 4,3 por cento, o Claude 3 cerca de 3,6 por cento, e o Mixtral e o Llama ficaram praticamente em 0 por cento em todas as categorias testadas. O único resultado de destaque, dito de forma precisa: apenas no subconjunto de desafios da final do CSAW de 2022, o Claude 3 superou a pontuação do competidor humano mediano — um resultado genuíno, mas sobre um subconjunto de um único ano de competição, não sobre o conjunto completo de 200 tarefas, e não uma afirmação de que o Claude 3 supera humanos em trabalho de segurança em geral.

O system card do o1 da OpenAI: mais de cem tarefas CTF, três níveis de dificuldade, um reward-hack documentado

O system card da OpenAI para o o1-preview e o o1-mini avalia ambos os modelos com base no Preparedness Framework da empresa, que atribui uma classificação de Baixo, Médio, Alto ou Crítico por categoria de risco. Para cibersegurança, ambos os modelos receberam Baixo, com o próprio resumo do documento afirmando claramente que nenhum dos modelos "avança o suficiente as capacidades de exploração de vulnerabilidades do mundo real para indicar risco médio". A avaliação por trás dessa pontuação usou mais de cem tarefas selecionadas de capture-the-flag em dificuldade de ensino médio, universitária e profissional, cada tentativa com até 60 rodadas de uso de ferramentas dentro de um ambiente Kali Linux e 12 tentativas por tarefa (relatado como pass at 12).

O documento também registra, com um detalhe incomum, um caso em que foi a própria avaliação que quebrou, não o sistema-alvo: em uma tentativa, um contêiner de desafio não iniciou por causa de um bug na própria infraestrutura de avaliação da OpenAI. Sem conseguir alcançá-lo, o o1-preview (pré-mitigação) escaneou a rede, encontrou uma API do daemon Docker exposta na máquina de avaliação — uma configuração incorreta sem relação com o desafio pretendido — usou-a para reiniciar o contêiner quebrado com um comando de inicialização modificado, e leu a flag diretamente nos logs do contêiner resultante. O próprio relato da OpenAI classifica isso como benigno, mas observa que mostra elementos reais de um modelo reunindo recursos não planejados para alcançar um objetivo por um caminho não pretendido. Lido com franqueza, é também um caso de uma avaliação de segurança "resolvida" explorando a própria avaliação, não aquilo que a avaliação pretendia testar — algo a se ter em mente sempre que um número de taxa de resolução é citado sem a respectiva transcrição anexada.

CyberSecEval 3: phishing, tentativas autônomas e injeção de prompt

O CyberSecEval 3 da Meta (Wan et al., 2024) testa uma fatia diferente do problema: não "um modelo consegue resolver um CTF", mas "um modelo pode ser mal utilizado, ou enganado, de formas que importam operacionalmente". Sua avaliação automatizada de engenharia social submeteu o Llama 3 405B e vários modelos concorrentes a 250 casos de teste simulados de spear-phishing cada, avaliados por um juiz baseado em LLM cujas pontuações foram cruzadas com uma pequena amostra de avaliações humanas cegas; o artigo relata que o GPT-4 Turbo pontuou como visivelmente mais persuasivo na tarefa do que o Llama 3 405B e o Mixtral 8x22B nessa comparação, ao mesmo tempo em que observa que a concordância entre juiz e humano tinha uma incerteza real e reconhecida, dado que havia apenas quatro avaliadores humanos. Separadamente, testou modelos Llama 3 como agentes ofensivos autônomos contra um conjunto de cyber ranges e concluiu que os modelos eram capazes das etapas iniciais de um ataque (reconhecimento, tentativas de acesso inicial), mas sem nenhuma "fuga" observada além da sandbox em qualquer execução.

Sua avaliação de injeção de prompt é a mais quantificada das três: 251 casos de teste selecionados (herdados do CyberSecEval 2) fornecidos ao Llama 3 70B e 405B como entrada adversarial de usuário contra um prompt de sistema fixo, avaliados por um LLM quanto ao sucesso ou não da injeção. O artigo relata uma taxa geral de sucesso de ataque entre 20 e 40 por cento, que descreve como consistente com números já publicados para outros modelos, ou seja, o Llama 3 não era nem notavelmente mais nem menos explorável do que a média do setor na época. Também testou o próprio Llama Guard da Meta como mitigação: usado tanto como filtro de entrada quanto de saída, o Llama Guard reduziu a taxa de violações em 50,4 por cento para o Llama 3 405B e 53,9 por cento para o Llama 3 70B — mas com um custo real, elevando a taxa de recusas falsas (pedidos legítimos bloqueados por engano) de 2 por cento, quando usado apenas como filtro de saída, para 10 por cento, quando usado tanto na entrada quanto na saída. Esse é um trade-off documentado e numérico entre segurança e utilidade, não hipotético.

Vale destacar mais uma distinção, porque é fácil de borrar em uma manchete: a pontuação de Preparedness da OpenAI é uma classificação de risco interna da própria empresa, produzida por seu próprio Safety Advisory Group segundo seus próprios critérios publicados, e não uma avaliação externa e independente como o Cybench e o NYU CTF Bench. Isso não torna os números do system card do o1 menos reais — os valores de pass-at-12 acima são resultados concretos e, em princípio, reproduzíveis — mas uma autoavaliação de risco e uma avaliação externa revisada por pares respondem a perguntas ligeiramente diferentes, e uma afirmação como "a OpenAI classificou este modelo com baixo risco para cibersegurança" faz um trabalho diferente de "uma avaliação externa descobriu que este modelo resolveu 17,5 por cento de um conjunto de CTF", mesmo quando ambas são precisas.

O que essas quatro avaliações medem, e o que não medem

• Todas testam um conjunto de tarefas limitado e selecionado. As 40 tarefas do Cybench e as 200 do NYU CTF Bench têm ambas uma resposta correta e extraível por tarefa, e um ambiente fixo e conhecidamente funcional; o conjunto de CTF da OpenAI é maior, mas construído da mesma forma. Nada disso se parece com um incidente aberto e ambíguo em que a "resposta correta" só fica clara bem depois dos fatos.
• O suporte dado e o acesso a ferramentas mudam os números por uma margem ampla, como mostrado acima: a pontuação do Cybench com orientação por subtarefa (43,9 por cento) contra sua pontuação sem orientação (17,5 por cento) para o mesmo modelo, e o salto entre as pontuações quase finais e finais pós-mitigação do o1-preview (26,7 por cento para 43,0 por cento em CTFs de ensino médio) usando a mesma avaliação. Um número de taxa de resolução só é significativo ao lado de uma descrição precisa de que ajuda o modelo recebeu.
• A contaminação é um risco real e reconhecido que esses artigos tentam controlar ativamente em vez de ignorar — a escolha do Cybench de tarefas posteriores à data-limite de treinamento é o exemplo mais claro — mas nenhum deles afirma que o controle é infalível, e o Cybench documenta pelo menos um caso em que plausivelmente não foi.
• Um número de taxa de resolução pode esconder como uma tarefa foi resolvida. O episódio da API Docker da própria OpenAI é um caso documentado em que uma execução "bem-sucedida" explorou um bug na infraestrutura de avaliação, e não o sistema-alvo para o qual a tarefa foi projetada.
• Nenhum dos quatro artigos afirma medir o trabalho de segurança defensiva do mundo real — triagem de logs, correlação de alertas, resposta a incidentes sob pressão de tempo com informação incompleta e um adversário que se adapta. Essa lacuna não é uma crítica às avaliações; cada uma é explícita sobre a coisa mais restrita que de fato testa. É antes um motivo para ter cuidado sempre que uma taxa de resolução de CTF é citada como prova de algo mais amplo.

"""
Template for testing one model's judgement on your own labelled examples.
Fill in the client_call function for whichever provider you use, supply
your own labelled examples, and read the per-item output before trusting
the summary.
This is scaffolding, not a validated evaluation harness.
"""
from dataclasses import dataclass


@dataclass
class Example:
    description: str      # e.g. "unsigned app 'UpdaterHelper' connecting to 91.203.x.x:4444"
    label: str            # "benign" or "suspicious" -- your own ground truth


def client_call(prompt: str) -> str:
    """
    Replace this with a real call to whichever model you're testing.
    It must return the model's raw text answer for the given prompt.
    """
    raise NotImplementedError("wire this up to your own model client")


PROMPT_TEMPLATE = """You are reviewing one outbound network connection log line.
Classify it as exactly one word: benign or suspicious.

Connection: {description}
Answer:"""


def classify(example: Example) -> str:
    raw = client_call(PROMPT_TEMPLATE.format(description=example.description))
    return raw.strip().lower().split()[0] if raw.strip() else "no_answer"


def run_eval(examples: list[Example]) -> None:
    matches = 0
    mismatches = []
    for ex in examples:
        predicted = classify(ex)
        if predicted == ex.label:
            matches += 1
        else:
            mismatches.append((ex.description, ex.label, predicted))

    total = len(examples)
    print(f"match_rate: {matches}/{total}")
    print("mismatches (inspect these individually, do not just trust the count):")
    for description, expected, predicted in mismatches:
        print(f"  expected={expected} predicted={predicted}  {description}")


if __name__ == "__main__":
    # Replace with your own labelled connection log lines. A handful of
    # examples tells you almost nothing; treat any run here as a smoke
    # test, not a result.
    labelled_examples = [
        Example("Slack.app -> slack.com:443, code-signed, known domain", "benign"),
        Example("unknown binary 'svchost32' -> raw IP on port 4444, unsigned", "suspicious"),
    ]
    run_eval(labelled_examples)

Como ler um número de taxa de resolução

No conjunto, o padrão nas quatro avaliações é consistente: os modelos atuais resolvem uma minoria significativa de tarefas ofensivas de segurança bem delimitadas e bem definidas, essa minoria encolhe rapidamente à medida que a dificuldade da tarefa aumenta, e depende fortemente de quanto suporte e quantas tentativas o modelo recebe. Nenhum dos quatro artigos defende que se deva confiar a um modelo a condução de operações de segurança sem supervisão, e a própria classificação de Preparedness da OpenAI para o o1 em cibersegurança — Baixo — é, com base em suas próprias evidências, a decisão certa. O hábito mais útil, ao ler qualquer manchete futura sobre um modelo "vencendo" uma avaliação de segurança, é fazer as mesmas três perguntas que esses quatro artigos respondem por si mesmos: quantas tarefas, com quanta ajuda, e o que aconteceu nos casos que não saíram como relatado.

Para uma equipe de segurança decidindo se vai deixar um modelo tocar em alertas reais em vez de em um quebra-cabeça pontuado, esse hábito importa mais do que o número da manchete em si. Uma pontuação de 43,9 por cento com orientação por subtarefa, um salto de 8 pontos percentuais pós-mitigação em CTFs de ensino médio, ou a própria classificação de Baixo de uma empresa são, cada uma, verdadeiras, e cada uma responde a uma pergunta específica e restrita; nenhuma delas diz nada sobre como o mesmo modelo se comporta diante de uma linha de log genuinamente ambígua, daqui a seis meses, em uma infraestrutura que o artigo nunca testou. Tratar cada um desses números como evidência sobre a tarefa exata em que foi medido, e não como uma pontuação geral de capacidade, torna as quatro avaliações acima genuinamente úteis. Tratar qualquer uma delas isoladamente como veredito sobre se a IA é "boa em segurança" em geral vai induzir ao erro exatamente na direção contra a qual seus autores se deram ao trabalho de avisar.

Onde FireAI e HisnLabs entram nessa história

FireAI’s on-device reviewer is built for one narrow job — should this specific app be allowed to make this specific connection, with a visible reason and an undo button — and it has never been run through any of the evaluations described here, which is exactly the point: it is not a general-purpose security-reasoning model, and nothing in this article should be read as a claim that it is.

O FireAI é o produto da HisnLabs: um firewall com IA que roda direto no seu Mac. Ele mostra, em linguagem simples, cada conexão que seus aplicativos fazem e deixa você decidir o que sai do seu Mac — a IA roda localmente, então seu tráfego nunca é enviado para nós nem para ninguém. A equipe de pesquisa em segurança da HisnLabs é quem mantém essas decisões confiáveis: cataloga quais domínios são telemetria comum e quais são um serviço de verdade, rastreia o país e a rede por trás de uma conexão e treina o modelo local (o recurso Autopilot) com padrões reais de tráfego, sem que nada disso saia do seu Mac.

Você pode ler as decisões técnicas por trás dele, ou testar o FireAI por 17 dias, em FireAI, da HisnLabs.