Benchmark para Avaliar LLMs em Triagem de Descobertas de Segurança
Um novo benchmark avalia modelos de linguagem (LLMs) na triagem de descobertas de segurança, focando em como as diferentes modelos lidam com falsos positivos e negativos. O artigo detalha a metodologia, métricas e resultados, destacando a importância de escolher modelos com base em perfis operacionais específicos.
MundiX News·01 de junho de 2026·15 min de leitura·👁 21 views
Benchmark para Avaliar LLMs em Triagem de Descobertas de Segurança
Eu criei meu próprio benchmark para avaliar modelos de linguagem porque os testes públicos padrão não respondem à minha principal pergunta: qual modelo é melhor em lidar com a triagem de descobertas de segurança. Essa tarefa é diferente de avaliar a inteligência geral do modelo.
Por que os Benchmarks Padrão Não São Adequados
THOR é um scanner forense que desenvolvemos na Nextron Systems. Ele procura por sinais de comprometimento, artefatos suspeitos, ferramentas de ataque, malware, rastros de persistência e outras evidências relevantes para a segurança. O benchmark usa as descobertas do THOR como entrada, mas o problema em si não é específico do THOR.
A descoberta do THOR não é um problema de programação, um quebra-cabeça matemático ou uma tarefa criativa. É um pedaço de contexto forense ou de segurança de um sistema real. Pode indicar malware, uma ferramenta de ataque, persistência suspeita, um artefato de cache estranho, um utilitário de administrador de uso duplo ou simplesmente um falso positivo que parece assustador à primeira vista.
O modelo deve tomar uma decisão:
Suprimir como um falso positivo
Deixar para verificação manual
Escalar como um possível incidente
Essas decisões têm custos de erro diferentes. Se o modelo marca uma descoberta inofensiva como suspeita, isso desperdiça o tempo do analista. É especialmente ruim se houver muitas descobertas como essa; ao escanear centenas ou milhares de sistemas, mesmo uma pequena porcentagem de falsas escalações cria muito trabalho extra. Mas é muito pior se o modelo marca um incidente real como inofensivo. Isso pode esconder o invasor e remover a única descoberta que deveria ter iniciado a investigação. O modelo pode ser excelente em código, problemas lógicos ou redação de relatórios de vulnerabilidade, mas ruim em avaliar eventos de segurança reais. E vice-versa: um modelo menos conhecido pode ser mais conservador e tomar melhores decisões operacionais para essa tarefa específica.
Orientações Gerais em Comparação com a Classificação por Nível de Ameaça de Segurança
Eu construí o benchmark em torno da triagem das descobertas do THOR. O objetivo não é encontrar o melhor LLM em geral, mas entender como diferentes modelos se comportam ao classificar descobertas de segurança como verdadeiramente positivas, falsos positivos ou inconclusivas.
É importante não apenas se a resposta do modelo está correta, mas também o que acontece quando a resposta está incorreta. Um modelo que envia muitas coisas para verificação é barulhento. Um modelo que suprime ameaças reais é perigoso.
Estrutura do Benchmark
O benchmark começa intencionalmente com uma folha em branco. Cada modelo recebe uma descoberta THOR enriquecida e deve classificá-la. Em seguida, o contexto é redefinido e a próxima descoberta é avaliada. Não há memória de longo prazo, nenhum feedback dos analistas, nenhuma lista de permissões específica do cliente, nenhum RAG, VirusTotal, sandbox ou pesquisa no SIEM. Isso não significa que o modelo receba apenas uma dica sutil. A descoberta do THOR já é enriquecida por design - isso não é algo que adicionamos especificamente para o benchmark. O THOR usa a mesma estrutura em seus relatórios regulares. O THOR não apenas diz "entrada suspeita no ShimCache" e deixa o resto para o LLM, mas analisa o artefato forense, adiciona o contexto da detecção e enriquece o evento com informações sobre o arquivo, sempre que possível.
Por exemplo, um artefato bruto do ShimCache fornece apenas parte do quadro: o caminho do arquivo, o carimbo de data/hora do artefato, a flag de execução (se disponível) e o local do registro de onde a entrada foi obtida. Se o arquivo ainda existir no disco, o THOR pode adicionar muito mais contexto: o tipo de arquivo, tamanho, hashes, primeiros bytes, carimbos de data/hora, proprietário, permissões e imphash. A razão da detecção, dados correspondentes, um link para a assinatura, uma avaliação e o contexto da classificação também são adicionados.
O benchmark não pede que o modelo raciocine do zero. Ele pede que interprete uma descoberta de segurança estruturada e enriquecida. Removemos intencionalmente ferramentas externas, memória de longo prazo, feedback anterior e contexto específico do cliente.
Em produção, um LLM pode fazer parte de um fluxo de trabalho de agente. Ele pode ter ferramentas, pode consultar o VirusTotal, verificar o inventário de ativos, procurar casos anteriores, visualizar árvores de processos no EDR, inspecionar eventos no SIEM, usar listas de permissões específicas do cliente ou obter feedback dos analistas de uma base de conhecimento. Tudo isso pode melhorar a avaliação final. Mas isso muda o que estamos medindo. O benchmark para de medir apenas a capacidade do modelo de triagem. Ele começa a medir todo o sistema: o modelo, o prompt, a escolha de ferramentas, a qualidade dos dados, a qualidade da extração, o contexto do cliente, o design do fluxo de trabalho e o feedback acumulado de decisões anteriores dos analistas.
Para este benchmark, eu queria uma linha de base limpa. O modelo recebe uma descoberta. Nada mais. Isso torna o benchmark menos semelhante a um fluxo de trabalho de produção completo, mas mais comparável. Todos os modelos trabalham com a mesma entrada, com a mesma tarefa, sem ajuda externa.
Configuração de Teste em Comparação com os Processos de Trabalho SOC Reais
O benchmark atual usa uma configuração controlada: uma descoberta, uma decisão, nenhuma ferramenta, nenhuma memória, nenhum feedback. Esta não é a versão final de como um grande modelo de linguagem funcionará como parte de um fluxo de trabalho completo de automação SOC.
O Que é Triagem de Descobertas THOR
O THOR verifica os sistemas em busca de arquivos suspeitos, artefatos forenses, ferramentas de ataque, mecanismos de persistência, linhas de comando suspeitas, entradas de cache, rastros em logs e muitos outros sinais. Quando o THOR encontra algo relevante, ele cria uma descoberta. Uma descoberta significa: "Isso parece relevante o suficiente para que alguém o avalie".
Pode ser um acerto explícito em malware, um web shell, um credential dumper, um rastro da execução de uma ferramenta de ataque no ShimCache ou AmCache. Pode ser um utilitário de administrador legítimo, um binário estranho do fornecedor, um produto de gerenciamento remoto ou um script que parece suspeito, mas é normal neste ambiente.
A tarefa real não é apenas a detecção. A tarefa real é a triagem. Para cada descoberta, alguém deve decidir o que ela significa operacionalmente. Neste benchmark, usamos três classes:
True Positive - a descoberta representa uma ameaça real ou um indicador de comprometimento
Inconclusive - incerteza, a descoberta deve permanecer visível para verificação manual
False Positive - a descoberta é inofensiva neste contexto
True Positive significa que a descoberta representa uma ameaça real ou um indicador de atividade do invasor. Ele precisa ser investigado e geralmente escalado.
False Positive significa que a descoberta é inofensiva neste contexto. Pode ter sido acionado por uma regra, mas não requer ação do analista.
Inconclusive - uma interessante categoria intermediária. Inconclusive significa que a descoberta deve permanecer visível para verificação manual. Pode ser uma anomalia legítima, uma ferramenta de uso duplo, atividade suspeita do administrador, um mecanismo de persistência incomum ou um artefato que requer contexto específico do cliente para avaliação. Em verificações reais, a maioria das descobertas são falsos positivos ou coincidências inofensivas. Uma parte menor são anomalias legítimas: coisas que não são incidentes, mas também não devem ser suprimidas automaticamente. E às vezes há aquelas poucas descobertas que realmente importam - indicadores reais de um incidente.
Um bom modelo de triagem não deve gritar com tudo. Mas também não deve suprimir aquela única descoberta que aponta para o invasor.
Neste benchmark, estamos tentando simular o problema da tomada de decisão: o modelo pode tomar uma decisão útil de classificação com base no mesmo conjunto de dados aprimorado do THOR? Esta não é uma solução perfeita fora do contexto. Mas pode ser útil.
Por que a Pontuação é Diferente
A primeira versão do benchmark foi mais simples. O modelo classificou a descoberta como TP, FP ou Inconclusive. Comparamos a resposta com a verdade fundamental e calculamos uma pontuação. Isso parece simples, mas não é suficiente. O problema é que os erros de triagem não são equivalentes. Em tarefas de classificação normais, uma resposta incorreta é apenas uma resposta incorreta. Em descobertas de segurança, é importante qual erro o modelo cometeu.
Um falso positivo classificado como TP cria uma carga para os analistas. Alguém deve olhar para isso, possivelmente abrir um caso, perguntar ao proprietário do sistema, verificar vários artefatos. Isso é irritante e caro, especialmente em larga escala. Mas é muito pior quando uma ameaça real é classificada como FP. Essa descoberta desaparece do fluxo de trabalho. O modelo está efetivamente dizendo: "ignore isso". Se esse fosse o único rastro de uma ferramenta de ataque, persistência suspeita ou execução de malware, o analista nunca poderia vê-lo.
Mas é muito pior quando uma ameaça real é classificada como FP. Essa descoberta desaparece do fluxo de trabalho. O modelo está efetivamente dizendo: "ignore isso". Se esse fosse o único rastro de uma ferramenta de ataque, persistência suspeita ou execução de malware, o analista nunca poderia vê-lo. Um modelo que reescalona descobertas inofensivas é barulhento. Um modelo que suprime ameaças reais é perigoso. Estes são diferentes tipos de erros.
Inconclusive significa que a descoberta deve permanecer visível para verificação manual. A decisão TP→Inc não é perfeita, mas é segura para verificação. O modelo não identificou claramente o incidente, mas também não o suprimiu. A decisão Inc→FP é mais problemática. Isso significa que uma anomalia digna de verificação desaparece. Pode ser uma ferramenta de uso duplo, comportamento suspeito do administrador, persistência incomum ou outro sinal dependente do contexto que não deve ser descartado automaticamente.
Portanto, adicionamos uma camada operacional de pontuação. O benchmark mede não apenas a qualidade da classificação, mas também a utilidade prática da decisão no fluxo de trabalho de triagem real.
A pontuação deve refletir o custo da decisão. Simplificando, é assim:
Tipos de erros na avaliação de segurança
Erro crítico (TP→FP): a ameaça real é suprimida
Reescalonamento (FP→TP): uma descoberta inofensiva é marcada como uma ameaça
Supressão de anomalia (Inc→FP): uma descoberta que requer verificação desaparece
O benchmark usa várias métricas:
Pontuação clássica ponderada por confiança
Pontuação operacional de triagem
Pontuação balanceada por FP, Inc e TP
Taxa de falha crítica
Taxa de captura de ameaças
Carga de revisão falsa
Custo
Velocidade
O objetivo não é complicar o benchmark por complicar. O próprio fluxo de trabalho de triagem é confuso. Não se trata apenas de correção, mas também de como o modelo comete erros para que o fluxo de trabalho dos analistas possa suportá-los.
Linhas de Base Ingênuas
Rapidamente ficou claro que esse benchmark precisava de linhas de base ingênuas. Caso contrário, os números podem parecer melhores do que realmente são.
Para esta tarefa, três linhas de base óbvias:
Classificar tudo como falso positivo
Classificar tudo como inconclusivo
Classificar tudo como verdadeiro positivo
Ninguém implementará essas estratégias, mas elas são úteis como referência. Eles mostram o que o modelo deve superar para que seu comportamento possa ser chamado de significativo.
A estratégia "tudo como falso positivo" é perigosa. Ele suprime tudo. Em um ambiente onde a maioria das descobertas é inofensiva, isso pode parecer bom em algumas métricas. Ele cria uma carga quase zero para os analistas. Mas o problema é óbvio: ele também suprime todos os incidentes reais.
A estratégia "tudo como verdadeiro positivo" tem o problema oposto. Ele evita a supressão de ameaças reais, mas transforma cada descoberta em um incidente. No papel, isso parece seguro, mas na prática destrói o fluxo de trabalho. Os analistas têm que processar tudo como urgente. Isso não é triagem, é pânico como uma estratégia de classificação.
A estratégia "tudo como inconclusivo" é mais interessante. Ele deixa tudo visível para verificação manual. Do ponto de vista da segurança, isso é atraente porque não esconde TP ou anomalias que valem a pena verificar. Mas isso significa que o modelo na verdade não reduz a carga. Ele simplesmente encaminha todo o monte para o analista.
Essa linha de base criou mais problemas na pontuação. Se o benchmark recompensa muito a segurança e não pune a carga de verificação o suficiente, "tudo como inconclusivo" começa a parecer uma boa estratégia. Mas não é. É apenas um fallback seguro. Ele pega tudo, mas quase não filtra nada. Um modelo de triagem útil deve equilibrar esses extremos. Ele não deve se comportar como "tudo falso positivo", porque isso esconde incidentes. Ele não deve se comportar como "tudo verdadeiro positivo", porque isso transforma a triagem em spam de alerta. E não deve se comportar como "tudo inconclusivo", porque isso simplesmente devolve toda a carga aos analistas.
O modelo deve fazer algo mais complicado: deixar as descobertas perigosas e dignas de verificação visíveis, mas, ao mesmo tempo, suprimir ruído suficiente inofensivo para ser útil.
Por que Não Há um Único Melhor Modelo
Depois de adicionar a pontuação operacional e as linhas de base ingênuas, ficou claro: não há um único melhor modelo para esta tarefa.
A triagem de segurança não é uma única tarefa de otimização fixa. Diferentes equipes se preocupam com diferentes tipos de erros. Em alguns ambientes, os incidentes perdidos não podem ser tolerados. Outros processam tantas descobertas que um modelo com alta carga de verificação não é útil, mesmo que seja muito seguro. Alguém precisa de processamento local. Alguém se preocupa com o custo. Alguém se preocupa com a velocidade, porque quer processar milhares de eventos em pouco tempo. Em vez de procurar um único vencedor global, começamos a analisar os perfis dos modelos.
Um perfil de alta segurança prefere modelos que quase nunca suprimem TPs. Esses modelos podem enviar muitas descobertas aos analistas, mas isso é aceitável em ambientes onde perder um incidente é o pior resultado. Por exemplo, infraestrutura crítica, sistemas de alto valor, ambientes regulamentados ou investigações pós-compromisso, onde a prioridade é não perder nada importante.
Um perfil SOC balanceado tenta manter ambos os lados sob controle. É necessária uma baixa taxa de falha crítica, mas também é preciso reduzir a carga sobre os analistas. Este é provavelmente o cenário mais comum: o modelo deve ajudar os analistas a processar as descobertas mais rapidamente, mas não suprimir muito.
O perfil de redução de ruído ou alto volume é diferente. Aqui, o principal é o volume. O modelo deve suprimir descobertas inofensivas suficientes para que o fluxo de trabalho seja dimensionado. Mas este perfil é perigoso sem proteções. Uma baixa carga de verificação é útil apenas se o modelo não a atingir suprimindo ameaças reais.
Há também o aspecto da implantação. Um modelo por meio de uma API de fornecedor pode ser conveniente e geralmente funciona bem, mas nem sempre é aplicável. Alguns ambientes não podem enviar descobertas de segurança a um provedor externo. Alguém quer um custo fixo previsível. Alguém quer controle local completo. Alguém quer executar modelos de peso aberto em seu próprio hardware, mesmo que isso signifique processamento mais lento ou menor qualidade.
Portanto, dividimos os resultados em níveis:
Fonte fechada / API do fornecedor
Código aberto / hardware profissional
Código aberto / hardware do consumidor
Isso torna o benchmark mais útil na prática. Uma tabela de classificação global pode dizer qual modelo teve o melhor resultado geral, mas não dirá qual modelo se adapta às suas restrições.
Primeiros Resultados
Quando a pontuação estava em uma forma aceitável, a coisa mais interessante começou: executar um grande conjunto de modelos nas mesmas descobertas e analisar seu comportamento.
A primeira coisa que percebi: a tabela de classificação usual é insuficiente. Um modelo pode parecer bom na pontuação clássica ponderada por confiança, mas ser uma escolha duvidosa para a triagem de segurança se tiver muitos erros críticos. Neste benchmark, um erro crítico é quando a verdade fundamental é TP, mas o modelo classifica como FP. Esse é o erro que mais me preocupa, porque significa que uma ameaça real é suprimida.
Portanto, os gráficos mais úteis não são simples "modelo A é melhor que o modelo B", mas gráficos de trade-off. Um dos mais importantes é a taxa de falha crítica versus a carga de revisão falsa. A taxa de falha crítica mostra com que frequência o modelo suprime ameaças reais. A carga de revisão falsa mostra quantas descobertas inofensivas ainda chegam ao analista. Idealmente, o modelo deve ser baixo em ambas as métricas: não esconder incidentes reais, mas também reduzir o ruído. O modelo ideal estaria no canto inferior esquerdo do gráfico.
Na prática, isso é difícil. Alguns modelos são seguros, mas barulhentos. Eles deixam os TPs visíveis, mas enviam muitos FPs para verificação. Isso pode ser aceitável para fluxos de trabalho de alta segurança, mas não reduz a carga sobre os analistas para ambientes de alto volume. Outros modelos são mais agressivos na redução da carga de verificação. Eles parecem eficazes, mas alguns deles pagam por isso com uma taxa de falha crítica mais alta. Este é um trade-off perigoso. Um modelo que reduz o ruído suprimindo ameaças reais é inútil.
O próximo gráfico útil é OTS balanceado vs. Carga de revisão falsa. OTS balanceado é nossa pontuação operacional, balanceada por FP, Inc e TP. Ele não permite que o benchmark seja dominado pela classe majoritária. Isso é importante, porque os resultados de verificações reais são frequentemente fortemente tendenciosos para FP. Se você avaliar apenas pela distribuição da maioria, o modelo pode parecer melhor do que realmente é, sendo bom em suprimir descobertas inofensivas, mas com mau desempenho em casos raros e importantes.
OTS balanceado mostra se o modelo toma decisões operacionais úteis em todas as classes. A carga de revisão falsa mostra se ele reduz a carga sobre os analistas. Novamente, o trade-off é importante. Um modelo com alto OTS balanceado, mas alta carga de revisão falsa pode ser seguro, mas barulhento. Um modelo com baixa carga de revisão falsa, mas baixo OTS balanceado pode ser eficaz, mas muito arriscado ou superficial. Os modelos que mantêm a segurança operacional e, ao mesmo tempo, reduzem o ruído são interessantes.
Outro gráfico compara CW% e OTS balanceado. É útil porque mostra como a qualidade clássica da classificação e a utilidade operacional podem divergir. CW% recompensa a proximidade da resposta especializada, levando em consideração a confiança. Isso ainda é valioso, mas não reflete totalmente o custo operacional de diferentes erros. Alguns modelos têm boa aparência em CW%, mas são menos atraentes se você levar em consideração a taxa de falha crítica, a supressão de anomalias e a carga de revisão falsa. Outros podem não parecer impressionantes na pontuação clássica, mas se comportam de forma mais conservadora em aspectos úteis para a triagem.
Os primeiros resultados mostraram algo inesperado: o modelo maior ou mais caro nem sempre é o melhor para este fluxo de trabalho. Alguns modelos mais leves tiveram um desempenho surpreendentemente bom. Em alguns casos, eles foram a melhor escolha operacional do que modelos pro maiores da mesma família. Minha suposição atual: alguns desses modelos se comportam com mais cautela. Eles podem ser menos propensos a fazer afirmações fortes, e isso ajuda na triagem de segurança, onde suprimir uma ameaça real é o pior erro.
Os primeiros resultados também tornaram mais importante a separação por níveis. Os modelos de API de fonte fechada são convenientes e geralmente fortes, mas nem sempre aplicáveis em ambientes com requisitos rígidos de controle de dados. Os modelos de código aberto em hardware profissional podem ser mais atraentes para implantações controladas. Modelos de código aberto menores, executados em hardware do consumidor, podem ser interessantes para triagem local ou fluxos de trabalho com orçamento limitado, mesmo que não ganhem a tabela de classificação global.
Por que Não Publicamos os Dados Brutos do Benchmark
Há duas razões pelas quais publicamos resultados, gráficos e metodologia de pontuação, mas não os dados brutos do benchmark.
A primeira razão é a contaminação do benchmark. Se publicarmos as descobertas exatas, prompts, classificações esperadas e rótulos de verdade fundamental, esses dados podem acabar em futuros conjuntos de treinamento. Mesmo que o provedor do modelo não treine intencionalmente neste benchmark, os repositórios públicos são verificados, copiados, espelhados e usados de várias maneiras. Assim que os dados brutos do benchmark se tornam públicos, não posso mais ter certeza de que os modelos futuros não os viram.
Isso tornará gradualmente o benchmark menos útil. Ele medirá não apenas o quão bem o modelo lida com essa tarefa de triagem de segurança, mas também quanto do benchmark ou dados semelhantes vazaram para os materiais de treinamento.
A segunda razão é mais prática: alguns relatórios e descobertas são baseados em casos reais ou resultados de verificações reais. Mesmo que os dados sejam limpos, não quero publicar descobertas brutas se não tiver certeza de que todo o contexto sensível foi removido. Caminhos, nomes de hosts, nomes de usuários, hashes, locais de ferramentas, carimbos de data/hora, nomes de software interno e o contexto forense circundante podem revelar mais do que o esperado.
Portanto, o repositório público contém o que considero útil e seguro para publicação:
Abordagem de pontuação
Tabelas de resultados
Gráficos
Metodologia de benchmark
Comparações de modelos
Perfis operacionais
Ele não contém relatórios THOR brutos, arquivos de verdade fundamental privados ou material detalhado de casos por trás das descobertas.
Como Usar o Benchmark
Eu não usaria este benchmark como uma tabela de classificação simples. A primeira pergunta não deve ser "qual modelo está em primeiro lugar?", a melhor pergunta é: qual modelo se adapta ao meu fluxo de trabalho e tolerância ao risco?
Para triagem de segurança, eu começaria com o tipo de erro que posso tolerar menos. Na maioria dos fluxos de trabalho, esta é uma falha crítica: TP classificado como FP. Se o modelo suprime incidentes reais, eu não justificaria isso pelo custo, velocidade ou alta pontuação geral. Portanto, as primeiras métricas a serem verificadas são a taxa de falha crítica e a taxa de captura de ameaças. O modelo deve deixar os TPs visíveis, seja como TPs claros ou como Inc, que ainda chegam ao humano.
Em seguida, eu olharia para a carga de revisão falsa. Isso mostrará se o modelo reduz a carga sobre os analistas. O modelo pode ser seguro, mas ainda enviar muito para verificação. Isso pode ser aceitável em fluxos de trabalho de alta segurança, mas não resolve o problema da triagem de alto volume.
Somente depois que o perfil de segurança e carga parecer aceitável, eu olharia para o custo e a velocidade.
O custo é importante se você deseja processar regularmente um grande número de resultados. A área útil é a alta qualidade a baixo custo, mas somente se as falhas críticas e os falsos positivos do modelo forem aceitáveis. Um modelo barato com muitas falhas críticas é inútil.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Benchmark para Avaliar LLMs em Triagem de Descobertas de Segurança
Eu criei meu próprio benchmark para avaliar modelos de linguagem porque os testes públicos padrão não respondem à minha principal pergunta: qual modelo é melhor em lidar com a triagem de descobertas de segurança. Essa tarefa é diferente de avaliar a inteligência geral do modelo.
Por que os Benchmarks Padrão Não São Adequados
THOR é um scanner forense que desenvolvemos na Nextron Systems. Ele procura por sinais de comprometimento, artefatos suspeitos, ferramentas de ataque, malware, rastros de persistência e outras evidências relevantes para a segurança. O benchmark usa as descobertas do THOR como entrada, mas o problema em si não é específico do THOR.
A descoberta do THOR não é um problema de programação, um quebra-cabeça matemático ou uma tarefa criativa. É um pedaço de contexto forense ou de segurança de um sistema real. Pode indicar malware, uma ferramenta de ataque, persistência suspeita, um artefato de cache estranho, um utilitário de administrador de uso duplo ou simplesmente um falso positivo que parece assustador à primeira vista.
O modelo deve tomar uma decisão:
Suprimir como um falso positivo
Deixar para verificação manual
Escalar como um possível incidente
Essas decisões têm custos de erro diferentes. Se o modelo marca uma descoberta inofensiva como suspeita, isso desperdiça o tempo do analista. É especialmente ruim se houver muitas descobertas como essa; ao escanear centenas ou milhares de sistemas, mesmo uma pequena porcentagem de falsas escalações cria muito trabalho extra. Mas é muito pior se o modelo marca um incidente real como inofensivo. Isso pode esconder o invasor e remover a única descoberta que deveria ter iniciado a investigação. O modelo pode ser excelente em código, problemas lógicos ou redação de relatórios de vulnerabilidade, mas ruim em avaliar eventos de segurança reais. E vice-versa: um modelo menos conhecido pode ser mais conservador e tomar melhores decisões operacionais para essa tarefa específica.
Orientações Gerais em Comparação com a Classificação por Nível de Ameaça de Segurança
Eu construí o benchmark em torno da triagem das descobertas do THOR. O objetivo não é encontrar o melhor LLM em geral, mas entender como diferentes modelos se comportam ao classificar descobertas de segurança como verdadeiramente positivas, falsos positivos ou inconclusivas.
É importante não apenas se a resposta do modelo está correta, mas também o que acontece quando a resposta está incorreta. Um modelo que envia muitas coisas para verificação é barulhento. Um modelo que suprime ameaças reais é perigoso.
Estrutura do Benchmark
O benchmark começa intencionalmente com uma folha em branco. Cada modelo recebe uma descoberta THOR enriquecida e deve classificá-la. Em seguida, o contexto é redefinido e a próxima descoberta é avaliada. Não há memória de longo prazo, nenhum feedback dos analistas, nenhuma lista de permissões específica do cliente, nenhum RAG, VirusTotal, sandbox ou pesquisa no SIEM. Isso não significa que o modelo receba apenas uma dica sutil. A descoberta do THOR já é enriquecida por design - isso não é algo que adicionamos especificamente para o benchmark. O THOR usa a mesma estrutura em seus relatórios regulares. O THOR não apenas diz "entrada suspeita no ShimCache" e deixa o resto para o LLM, mas analisa o artefato forense, adiciona o contexto da detecção e enriquece o evento com informações sobre o arquivo, sempre que possível.
Por exemplo, um artefato bruto do ShimCache fornece apenas parte do quadro: o caminho do arquivo, o carimbo de data/hora do artefato, a flag de execução (se disponível) e o local do registro de onde a entrada foi obtida. Se o arquivo ainda existir no disco, o THOR pode adicionar muito mais contexto: o tipo de arquivo, tamanho, hashes, primeiros bytes, carimbos de data/hora, proprietário, permissões e imphash. A razão da detecção, dados correspondentes, um link para a assinatura, uma avaliação e o contexto da classificação também são adicionados.
O benchmark não pede que o modelo raciocine do zero. Ele pede que interprete uma descoberta de segurança estruturada e enriquecida. Removemos intencionalmente ferramentas externas, memória de longo prazo, feedback anterior e contexto específico do cliente.
Em produção, um LLM pode fazer parte de um fluxo de trabalho de agente. Ele pode ter ferramentas, pode consultar o VirusTotal, verificar o inventário de ativos, procurar casos anteriores, visualizar árvores de processos no EDR, inspecionar eventos no SIEM, usar listas de permissões específicas do cliente ou obter feedback dos analistas de uma base de conhecimento. Tudo isso pode melhorar a avaliação final. Mas isso muda o que estamos medindo. O benchmark para de medir apenas a capacidade do modelo de triagem. Ele começa a medir todo o sistema: o modelo, o prompt, a escolha de ferramentas, a qualidade dos dados, a qualidade da extração, o contexto do cliente, o design do fluxo de trabalho e o feedback acumulado de decisões anteriores dos analistas.
Para este benchmark, eu queria uma linha de base limpa. O modelo recebe uma descoberta. Nada mais. Isso torna o benchmark menos semelhante a um fluxo de trabalho de produção completo, mas mais comparável. Todos os modelos trabalham com a mesma entrada, com a mesma tarefa, sem ajuda externa.
Configuração de Teste em Comparação com os Processos de Trabalho SOC Reais
O benchmark atual usa uma configuração controlada: uma descoberta, uma decisão, nenhuma ferramenta, nenhuma memória, nenhum feedback. Esta não é a versão final de como um grande modelo de linguagem funcionará como parte de um fluxo de trabalho completo de automação SOC.
O Que é Triagem de Descobertas THOR
O THOR verifica os sistemas em busca de arquivos suspeitos, artefatos forenses, ferramentas de ataque, mecanismos de persistência, linhas de comando suspeitas, entradas de cache, rastros em logs e muitos outros sinais. Quando o THOR encontra algo relevante, ele cria uma descoberta. Uma descoberta significa: "Isso parece relevante o suficiente para que alguém o avalie".
Pode ser um acerto explícito em malware, um web shell, um credential dumper, um rastro da execução de uma ferramenta de ataque no ShimCache ou AmCache. Pode ser um utilitário de administrador legítimo, um binário estranho do fornecedor, um produto de gerenciamento remoto ou um script que parece suspeito, mas é normal neste ambiente.
A tarefa real não é apenas a detecção. A tarefa real é a triagem. Para cada descoberta, alguém deve decidir o que ela significa operacionalmente. Neste benchmark, usamos três classes:
True Positive - a descoberta representa uma ameaça real ou um indicador de comprometimento
Inconclusive - incerteza, a descoberta deve permanecer visível para verificação manual
False Positive - a descoberta é inofensiva neste contexto
True Positive significa que a descoberta representa uma ameaça real ou um indicador de atividade do invasor. Ele precisa ser investigado e geralmente escalado.
False Positive significa que a descoberta é inofensiva neste contexto. Pode ter sido acionado por uma regra, mas não requer ação do analista.
Inconclusive - uma interessante categoria intermediária. Inconclusive significa que a descoberta deve permanecer visível para verificação manual. Pode ser uma anomalia legítima, uma ferramenta de uso duplo, atividade suspeita do administrador, um mecanismo de persistência incomum ou um artefato que requer contexto específico do cliente para avaliação. Em verificações reais, a maioria das descobertas são falsos positivos ou coincidências inofensivas. Uma parte menor são anomalias legítimas: coisas que não são incidentes, mas também não devem ser suprimidas automaticamente. E às vezes há aquelas poucas descobertas que realmente importam - indicadores reais de um incidente.
Um bom modelo de triagem não deve gritar com tudo. Mas também não deve suprimir aquela única descoberta que aponta para o invasor.
Neste benchmark, estamos tentando simular o problema da tomada de decisão: o modelo pode tomar uma decisão útil de classificação com base no mesmo conjunto de dados aprimorado do THOR? Esta não é uma solução perfeita fora do contexto. Mas pode ser útil.
Por que a Pontuação é Diferente
A primeira versão do benchmark foi mais simples. O modelo classificou a descoberta como TP, FP ou Inconclusive. Comparamos a resposta com a verdade fundamental e calculamos uma pontuação. Isso parece simples, mas não é suficiente. O problema é que os erros de triagem não são equivalentes. Em tarefas de classificação normais, uma resposta incorreta é apenas uma resposta incorreta. Em descobertas de segurança, é importante qual erro o modelo cometeu.
Um falso positivo classificado como TP cria uma carga para os analistas. Alguém deve olhar para isso, possivelmente abrir um caso, perguntar ao proprietário do sistema, verificar vários artefatos. Isso é irritante e caro, especialmente em larga escala. Mas é muito pior quando uma ameaça real é classificada como FP. Essa descoberta desaparece do fluxo de trabalho. O modelo está efetivamente dizendo: "ignore isso". Se esse fosse o único rastro de uma ferramenta de ataque, persistência suspeita ou execução de malware, o analista nunca poderia vê-lo.
Mas é muito pior quando uma ameaça real é classificada como FP. Essa descoberta desaparece do fluxo de trabalho. O modelo está efetivamente dizendo: "ignore isso". Se esse fosse o único rastro de uma ferramenta de ataque, persistência suspeita ou execução de malware, o analista nunca poderia vê-lo. Um modelo que reescalona descobertas inofensivas é barulhento. Um modelo que suprime ameaças reais é perigoso. Estes são diferentes tipos de erros.
Inconclusive significa que a descoberta deve permanecer visível para verificação manual. A decisão TP→Inc não é perfeita, mas é segura para verificação. O modelo não identificou claramente o incidente, mas também não o suprimiu. A decisão Inc→FP é mais problemática. Isso significa que uma anomalia digna de verificação desaparece. Pode ser uma ferramenta de uso duplo, comportamento suspeito do administrador, persistência incomum ou outro sinal dependente do contexto que não deve ser descartado automaticamente.
Portanto, adicionamos uma camada operacional de pontuação. O benchmark mede não apenas a qualidade da classificação, mas também a utilidade prática da decisão no fluxo de trabalho de triagem real.
A pontuação deve refletir o custo da decisão. Simplificando, é assim:
Tipos de erros na avaliação de segurança
Erro crítico (TP→FP): a ameaça real é suprimida
Reescalonamento (FP→TP): uma descoberta inofensiva é marcada como uma ameaça
Supressão de anomalia (Inc→FP): uma descoberta que requer verificação desaparece
O benchmark usa várias métricas:
Pontuação clássica ponderada por confiança
Pontuação operacional de triagem
Pontuação balanceada por FP, Inc e TP
Taxa de falha crítica
Taxa de captura de ameaças
Carga de revisão falsa
Custo
Velocidade
O objetivo não é complicar o benchmark por complicar. O próprio fluxo de trabalho de triagem é confuso. Não se trata apenas de correção, mas também de como o modelo comete erros para que o fluxo de trabalho dos analistas possa suportá-los.
Linhas de Base Ingênuas
Rapidamente ficou claro que esse benchmark precisava de linhas de base ingênuas. Caso contrário, os números podem parecer melhores do que realmente são.
Para esta tarefa, três linhas de base óbvias:
Classificar tudo como falso positivo
Classificar tudo como inconclusivo
Classificar tudo como verdadeiro positivo
Ninguém implementará essas estratégias, mas elas são úteis como referência. Eles mostram o que o modelo deve superar para que seu comportamento possa ser chamado de significativo.
A estratégia "tudo como falso positivo" é perigosa. Ele suprime tudo. Em um ambiente onde a maioria das descobertas é inofensiva, isso pode parecer bom em algumas métricas. Ele cria uma carga quase zero para os analistas. Mas o problema é óbvio: ele também suprime todos os incidentes reais.
A estratégia "tudo como verdadeiro positivo" tem o problema oposto. Ele evita a supressão de ameaças reais, mas transforma cada descoberta em um incidente. No papel, isso parece seguro, mas na prática destrói o fluxo de trabalho. Os analistas têm que processar tudo como urgente. Isso não é triagem, é pânico como uma estratégia de classificação.
A estratégia "tudo como inconclusivo" é mais interessante. Ele deixa tudo visível para verificação manual. Do ponto de vista da segurança, isso é atraente porque não esconde TP ou anomalias que valem a pena verificar. Mas isso significa que o modelo na verdade não reduz a carga. Ele simplesmente encaminha todo o monte para o analista.
Essa linha de base criou mais problemas na pontuação. Se o benchmark recompensa muito a segurança e não pune a carga de verificação o suficiente, "tudo como inconclusivo" começa a parecer uma boa estratégia. Mas não é. É apenas um fallback seguro. Ele pega tudo, mas quase não filtra nada. Um modelo de triagem útil deve equilibrar esses extremos. Ele não deve se comportar como "tudo falso positivo", porque isso esconde incidentes. Ele não deve se comportar como "tudo verdadeiro positivo", porque isso transforma a triagem em spam de alerta. E não deve se comportar como "tudo inconclusivo", porque isso simplesmente devolve toda a carga aos analistas.
O modelo deve fazer algo mais complicado: deixar as descobertas perigosas e dignas de verificação visíveis, mas, ao mesmo tempo, suprimir ruído suficiente inofensivo para ser útil.
Por que Não Há um Único Melhor Modelo
Depois de adicionar a pontuação operacional e as linhas de base ingênuas, ficou claro: não há um único melhor modelo para esta tarefa.
A triagem de segurança não é uma única tarefa de otimização fixa. Diferentes equipes se preocupam com diferentes tipos de erros. Em alguns ambientes, os incidentes perdidos não podem ser tolerados. Outros processam tantas descobertas que um modelo com alta carga de verificação não é útil, mesmo que seja muito seguro. Alguém precisa de processamento local. Alguém se preocupa com o custo. Alguém se preocupa com a velocidade, porque quer processar milhares de eventos em pouco tempo. Em vez de procurar um único vencedor global, começamos a analisar os perfis dos modelos.
Um perfil de alta segurança prefere modelos que quase nunca suprimem TPs. Esses modelos podem enviar muitas descobertas aos analistas, mas isso é aceitável em ambientes onde perder um incidente é o pior resultado. Por exemplo, infraestrutura crítica, sistemas de alto valor, ambientes regulamentados ou investigações pós-compromisso, onde a prioridade é não perder nada importante.
Um perfil SOC balanceado tenta manter ambos os lados sob controle. É necessária uma baixa taxa de falha crítica, mas também é preciso reduzir a carga sobre os analistas. Este é provavelmente o cenário mais comum: o modelo deve ajudar os analistas a processar as descobertas mais rapidamente, mas não suprimir muito.
O perfil de redução de ruído ou alto volume é diferente. Aqui, o principal é o volume. O modelo deve suprimir descobertas inofensivas suficientes para que o fluxo de trabalho seja dimensionado. Mas este perfil é perigoso sem proteções. Uma baixa carga de verificação é útil apenas se o modelo não a atingir suprimindo ameaças reais.
Há também o aspecto da implantação. Um modelo por meio de uma API de fornecedor pode ser conveniente e geralmente funciona bem, mas nem sempre é aplicável. Alguns ambientes não podem enviar descobertas de segurança a um provedor externo. Alguém quer um custo fixo previsível. Alguém quer controle local completo. Alguém quer executar modelos de peso aberto em seu próprio hardware, mesmo que isso signifique processamento mais lento ou menor qualidade.
Portanto, dividimos os resultados em níveis:
Fonte fechada / API do fornecedor
Código aberto / hardware profissional
Código aberto / hardware do consumidor
Isso torna o benchmark mais útil na prática. Uma tabela de classificação global pode dizer qual modelo teve o melhor resultado geral, mas não dirá qual modelo se adapta às suas restrições.
Primeiros Resultados
Quando a pontuação estava em uma forma aceitável, a coisa mais interessante começou: executar um grande conjunto de modelos nas mesmas descobertas e analisar seu comportamento.
A primeira coisa que percebi: a tabela de classificação usual é insuficiente. Um modelo pode parecer bom na pontuação clássica ponderada por confiança, mas ser uma escolha duvidosa para a triagem de segurança se tiver muitos erros críticos. Neste benchmark, um erro crítico é quando a verdade fundamental é TP, mas o modelo classifica como FP. Esse é o erro que mais me preocupa, porque significa que uma ameaça real é suprimida.
Portanto, os gráficos mais úteis não são simples "modelo A é melhor que o modelo B", mas gráficos de trade-off. Um dos mais importantes é a taxa de falha crítica versus a carga de revisão falsa. A taxa de falha crítica mostra com que frequência o modelo suprime ameaças reais. A carga de revisão falsa mostra quantas descobertas inofensivas ainda chegam ao analista. Idealmente, o modelo deve ser baixo em ambas as métricas: não esconder incidentes reais, mas também reduzir o ruído. O modelo ideal estaria no canto inferior esquerdo do gráfico.
Na prática, isso é difícil. Alguns modelos são seguros, mas barulhentos. Eles deixam os TPs visíveis, mas enviam muitos FPs para verificação. Isso pode ser aceitável para fluxos de trabalho de alta segurança, mas não reduz a carga sobre os analistas para ambientes de alto volume. Outros modelos são mais agressivos na redução da carga de verificação. Eles parecem eficazes, mas alguns deles pagam por isso com uma taxa de falha crítica mais alta. Este é um trade-off perigoso. Um modelo que reduz o ruído suprimindo ameaças reais é inútil.
O próximo gráfico útil é OTS balanceado vs. Carga de revisão falsa. OTS balanceado é nossa pontuação operacional, balanceada por FP, Inc e TP. Ele não permite que o benchmark seja dominado pela classe majoritária. Isso é importante, porque os resultados de verificações reais são frequentemente fortemente tendenciosos para FP. Se você avaliar apenas pela distribuição da maioria, o modelo pode parecer melhor do que realmente é, sendo bom em suprimir descobertas inofensivas, mas com mau desempenho em casos raros e importantes.
OTS balanceado mostra se o modelo toma decisões operacionais úteis em todas as classes. A carga de revisão falsa mostra se ele reduz a carga sobre os analistas. Novamente, o trade-off é importante. Um modelo com alto OTS balanceado, mas alta carga de revisão falsa pode ser seguro, mas barulhento. Um modelo com baixa carga de revisão falsa, mas baixo OTS balanceado pode ser eficaz, mas muito arriscado ou superficial. Os modelos que mantêm a segurança operacional e, ao mesmo tempo, reduzem o ruído são interessantes.
Outro gráfico compara CW% e OTS balanceado. É útil porque mostra como a qualidade clássica da classificação e a utilidade operacional podem divergir. CW% recompensa a proximidade da resposta especializada, levando em consideração a confiança. Isso ainda é valioso, mas não reflete totalmente o custo operacional de diferentes erros. Alguns modelos têm boa aparência em CW%, mas são menos atraentes se você levar em consideração a taxa de falha crítica, a supressão de anomalias e a carga de revisão falsa. Outros podem não parecer impressionantes na pontuação clássica, mas se comportam de forma mais conservadora em aspectos úteis para a triagem.
Os primeiros resultados mostraram algo inesperado: o modelo maior ou mais caro nem sempre é o melhor para este fluxo de trabalho. Alguns modelos mais leves tiveram um desempenho surpreendentemente bom. Em alguns casos, eles foram a melhor escolha operacional do que modelos pro maiores da mesma família. Minha suposição atual: alguns desses modelos se comportam com mais cautela. Eles podem ser menos propensos a fazer afirmações fortes, e isso ajuda na triagem de segurança, onde suprimir uma ameaça real é o pior erro.
Os primeiros resultados também tornaram mais importante a separação por níveis. Os modelos de API de fonte fechada são convenientes e geralmente fortes, mas nem sempre aplicáveis em ambientes com requisitos rígidos de controle de dados. Os modelos de código aberto em hardware profissional podem ser mais atraentes para implantações controladas. Modelos de código aberto menores, executados em hardware do consumidor, podem ser interessantes para triagem local ou fluxos de trabalho com orçamento limitado, mesmo que não ganhem a tabela de classificação global.
Por que Não Publicamos os Dados Brutos do Benchmark
Há duas razões pelas quais publicamos resultados, gráficos e metodologia de pontuação, mas não os dados brutos do benchmark.
A primeira razão é a contaminação do benchmark. Se publicarmos as descobertas exatas, prompts, classificações esperadas e rótulos de verdade fundamental, esses dados podem acabar em futuros conjuntos de treinamento. Mesmo que o provedor do modelo não treine intencionalmente neste benchmark, os repositórios públicos são verificados, copiados, espelhados e usados de várias maneiras. Assim que os dados brutos do benchmark se tornam públicos, não posso mais ter certeza de que os modelos futuros não os viram.
Isso tornará gradualmente o benchmark menos útil. Ele medirá não apenas o quão bem o modelo lida com essa tarefa de triagem de segurança, mas também quanto do benchmark ou dados semelhantes vazaram para os materiais de treinamento.
A segunda razão é mais prática: alguns relatórios e descobertas são baseados em casos reais ou resultados de verificações reais. Mesmo que os dados sejam limpos, não quero publicar descobertas brutas se não tiver certeza de que todo o contexto sensível foi removido. Caminhos, nomes de hosts, nomes de usuários, hashes, locais de ferramentas, carimbos de data/hora, nomes de software interno e o contexto forense circundante podem revelar mais do que o esperado.
Portanto, o repositório público contém o que considero útil e seguro para publicação:
Abordagem de pontuação
Tabelas de resultados
Gráficos
Metodologia de benchmark
Comparações de modelos
Perfis operacionais
Ele não contém relatórios THOR brutos, arquivos de verdade fundamental privados ou material detalhado de casos por trás das descobertas.
Como Usar o Benchmark
Eu não usaria este benchmark como uma tabela de classificação simples. A primeira pergunta não deve ser "qual modelo está em primeiro lugar?", a melhor pergunta é: qual modelo se adapta ao meu fluxo de trabalho e tolerância ao risco?
Para triagem de segurança, eu começaria com o tipo de erro que posso tolerar menos. Na maioria dos fluxos de trabalho, esta é uma falha crítica: TP classificado como FP. Se o modelo suprime incidentes reais, eu não justificaria isso pelo custo, velocidade ou alta pontuação geral. Portanto, as primeiras métricas a serem verificadas são a taxa de falha crítica e a taxa de captura de ameaças. O modelo deve deixar os TPs visíveis, seja como TPs claros ou como Inc, que ainda chegam ao humano.
Em seguida, eu olharia para a carga de revisão falsa. Isso mostrará se o modelo reduz a carga sobre os analistas. O modelo pode ser seguro, mas ainda enviar muito para verificação. Isso pode ser aceitável em fluxos de trabalho de alta segurança, mas não resolve o problema da triagem de alto volume.
Somente depois que o perfil de segurança e carga parecer aceitável, eu olharia para o custo e a velocidade.
O custo é importante se você deseja processar regularmente um grande número de resultados. A área útil é a alta qualidade a baixo custo, mas somente se as falhas críticas e os falsos positivos do modelo forem aceitáveis. Um modelo barato com muitas falhas críticas é inútil.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
