Pablo Zavala · Avaliação de segurança de IA · Engenharia de pesquisa

Detecção de anomalias em cibersegurança

Um projeto de análise de segurança da Carnegie Mellon que ajusta um Isolation Forest sobre tráfego de kernel Linux exclusivamente benigno do dataset de honeypot BETH, e então o avalia sob um limiar congelado. Em um holdout de 18.000 eventos, com prevalência de ataque simulada de 1%, o detector captura 90% das intrusões (162 de 180) a uma taxa de falsos positivos de 1,94%, com ROC AUC de 0,9714. A entrada audita seu próprio resultado principal: a precisão situa-se em 0,3189, de modo que aproximadamente um em cada três alertas sinaliza um ataque real, e três atributos dominantes entregam a um atacante um playbook de spoofing, o que mantém o detector como apenas uma camada da defesa em profundidade.

Precisão da afirmação

O que a evidência demonstra
Holdout de limiar congelado: recall 0,9000 (162 de 180 ataques; IC de 95% 0,85 a 0,94) com FPR 0,0194, ROC AUC 0,9714, a partir de um Isolation Forest ajustado sobre tráfego exclusivamente benigno
Fronteira de capacidade e evidência
A precisão no limiar escolhido é de 0,3189 a uma prevalência simulada de 1%, a classe maliciosa contém uma única campanha de preparação de botnet em um único host de honeypot, e três atributos dominantes deixam o detector suscetível a spoofing.

Repositório público reproduzível + notebook executado

Papel: Autor único: engenharia de atributos, análise de separabilidade, ajuste do detector com dados exclusivamente benignos, governança de limiar, análise de erros e o pacote público de reprodução.

Cartão de avaliação

Desempenho de detecção

Amostra
Holdout de 18.000 eventos, com prevalência simulada de 1%, limiar congelado após a validação
Avaliador
Recall, FPR, precisão, ROC AUC e PR AUC, com ICs de 95% via bootstrap a partir de 400 reamostragens do holdout
Resultado
Recall 0,9000 (162 de 180 ataques; IC 0,85 a 0,94) com FPR 0,0194 (346 de 17.820 eventos benignos); ROC AUC 0,9714; PR AUC 0,2972; precisão 0,3189 (IC 0,28 a 0,36); orçamento de alertas de 2.822 por 100k eventos.
Escopo de verificação
Uma única campanha de ataque e um único ambiente de honeypot; as métricas avaliam este dataset, e não tráfego de produção.

Análise de erros

Amostra
Os 346 falsos positivos que o limiar congelado sinaliza no holdout
Avaliador
Taxonomia de processos e eventos sobre o tráfego benigno sinalizado
Resultado
Os processos systemd concentram 86% do volume de falsos positivos, e a enumeração de diretórios via getdents64 dispara a uma taxa 37x acima de sua linha de base benigna, de modo que um alerta de getdents64 vindo de systemd merece uma regra de revisão prioritária antes que qualquer analista humano seja acionado.
Escopo de verificação
As diretrizes de triagem derivam da linha de base benigna de um único ambiente.

Nível de evidência

Amostra
Repositório público: notebook executado com saídas incorporadas, nove figuras versionadas, dependências fixadas e um script de reconstrução dos dados
Avaliador
Reexecução com RANDOM_STATE=42, além de verificações de contagem no script de reconstrução
Resultado
A reexecução reproduziu exatamente cada número do resultado principal, com 14 das 15 células de código idênticas byte a byte (uma diferença cosmética de rótulo de dtype no pandas); o script de reconstrução verifica as três contagens de linhas que definem o conjunto; a licença MIT cobre o código, e o dataset é licenciado sob CC0 1,0.
Escopo de verificação
O subconjunto de 95 MB permanece fora do controle de versão, de modo que uma reconstrução completa exige uma conta no Kaggle; uma amostra estratificada de 500 linhas é distribuída para inspeção do esquema.

Afiliação

Amostra
Trabalho de curso da Carnegie Mellon University, outono de 2024, revisado em fevereiro de 2025
Avaliador
Atribuição no README do repositório
Resultado
Trabalho de curso individual em análise de segurança, transformado em repositório público reproduzível.
Escopo de verificação
Apostilas do curso, enunciados e o contexto de avaliação permanecem privados.

Página atualizada

Amostra
Julho de 2026
Avaliador
Registro de conteúdo do site
Resultado
Entrada redigida em 10 de julho de 2026 a partir do repositório público: seu README, a documentação dos dados e as saídas do notebook executado.
Escopo de verificação
Os números citam o notebook executado versionado e sua reexecução documentada, e não uma nova execução sobre tráfego inédito.
Eixos de avaliação com amostra, avaliador, resultado e escopo de verificação.
EixoAmostraAvaliadorResultadoEscopo de verificação
Desempenho de detecçãoHoldout de 18.000 eventos, com prevalência simulada de 1%, limiar congelado após a validaçãoRecall, FPR, precisão, ROC AUC e PR AUC, com ICs de 95% via bootstrap a partir de 400 reamostragens do holdoutRecall 0,9000 (162 de 180 ataques; IC 0,85 a 0,94) com FPR 0,0194 (346 de 17.820 eventos benignos); ROC AUC 0,9714; PR AUC 0,2972; precisão 0,3189 (IC 0,28 a 0,36); orçamento de alertas de 2.822 por 100k eventos.Uma única campanha de ataque e um único ambiente de honeypot; as métricas avaliam este dataset, e não tráfego de produção.
Análise de errosOs 346 falsos positivos que o limiar congelado sinaliza no holdoutTaxonomia de processos e eventos sobre o tráfego benigno sinalizadoOs processos systemd concentram 86% do volume de falsos positivos, e a enumeração de diretórios via getdents64 dispara a uma taxa 37x acima de sua linha de base benigna, de modo que um alerta de getdents64 vindo de systemd merece uma regra de revisão prioritária antes que qualquer analista humano seja acionado.As diretrizes de triagem derivam da linha de base benigna de um único ambiente.
Nível de evidênciaRepositório público: notebook executado com saídas incorporadas, nove figuras versionadas, dependências fixadas e um script de reconstrução dos dadosReexecução com RANDOM_STATE=42, além de verificações de contagem no script de reconstruçãoA reexecução reproduziu exatamente cada número do resultado principal, com 14 das 15 células de código idênticas byte a byte (uma diferença cosmética de rótulo de dtype no pandas); o script de reconstrução verifica as três contagens de linhas que definem o conjunto; a licença MIT cobre o código, e o dataset é licenciado sob CC0 1,0.O subconjunto de 95 MB permanece fora do controle de versão, de modo que uma reconstrução completa exige uma conta no Kaggle; uma amostra estratificada de 500 linhas é distribuída para inspeção do esquema.
AfiliaçãoTrabalho de curso da Carnegie Mellon University, outono de 2024, revisado em fevereiro de 2025Atribuição no README do repositórioTrabalho de curso individual em análise de segurança, transformado em repositório público reproduzível.Apostilas do curso, enunciados e o contexto de avaliação permanecem privados.
Página atualizadaJulho de 2026Registro de conteúdo do siteEntrada redigida em 10 de julho de 2026 a partir do repositório público: seu README, a documentação dos dados e as saídas do notebook executado.Os números citam o notebook executado versionado e sua reexecução documentada, e não uma nova execução sobre tráfego inédito.

Como inspecionar este trabalho

Governança de limiar

Todo número do resultado principal vem de um único desenho de avaliação: uma amostra de 60.000 eventos, com prevalência de ataque simulada de 1%, se divide em 52,5/17,5/30 entre ajuste, validação e holdout, estratificada pelo rótulo, e o limiar de alerta (0,6892, o ótimo de F2 na curva de precisão-recall de validação) se congela antes que o holdout de 18.000 eventos seja avaliado. O recall e a taxa de falsos positivos reportados, portanto, medem uma regra de decisão governada, e não uma curva buscada a posteriori.

Onde os rótulos entram

A chamada de ajuste da floresta recebe somente atributos, e seu conjunto de treinamento de 31.185 eventos não contém nenhuma linha de ataque. Os rótulos entram exatamente em três pontos: filtrar a divisão de ajuste para tráfego benigno, escolher o limiar de validação e avaliar o holdout congelado, o formato padrão de uma implantação de detecção de novidade.

Verificação do leitor

O repositório é reexecutado de ponta a ponta: o script de reconstrução dos dados verifica as três contagens de linhas que definem o conjunto, as dependências permanecem com versões fixadas, e uma reexecução com RANDOM_STATE=42 reproduziu exatamente cada número do resultado principal, com 14 das 15 células de código idênticas byte a byte às originais, e a diferença restante sendo apenas um rótulo cosmético de dtype no pandas.

Estudo de caso

Problema

A telemetria de segurança em nível de kernel chega mais rápido do que qualquer pessoa consegue rotular, de modo que um detector implantável precisa aprender o comportamento benigno sozinho e, ainda assim, capturar ataques que nunca viu; a avaliação também precisa manter o resultado principal honesto em taxas de ataque realistas.

Contexto

O subconjunto reúne 347.399 eventos de processo do kernel com 16 campos em 5 hosts de honeypot, extraídos do corpus BETH de 8.004.918 eventos (Highnam et al. 2021): a divisão de validação totalmente rotulada, mais os 158.432 eventos confirmadamente maliciosos de um host atacado, o que enriquece a taxa de eventos maliciosos para 45,6% para fins de análise exploratória. Ambos os rótulos vêm anotados manualmente pelos autores do dataset, e os modelos de detecção reamostram para uma prevalência realista de 1%.

Método

Dezesseis campos brutos se destilam em 7 atributos projetados, seguindo as orientações do artigo do BETH; uma projeção UMAP confirma que o espaço projetado separa as classes antes de qualquer modelo ser treinado; e um Isolation Forest com 300 árvores se ajusta sobre 31.185 eventos exclusivamente benignos. Uma amostra de 60.000 eventos, com prevalência simulada de 1%, se divide em 52,5/17,5/30 entre ajuste, validação e holdout; o limiar de alerta maximiza o F2 na validação e se congela antes da avaliação do holdout, com ICs via bootstrap a partir de 400 reamostragens.

Resultado

O limiar congelado captura 162 de 180 ataques do holdout (recall 0,9000; IC de 95% 0,85 a 0,94), enquanto sinaliza 346 de 17.820 eventos benignos (FPR 0,0194), com ROC AUC 0,9714, PR AUC 0,2972, e um orçamento de alertas de 2.822 por 100k eventos. A precisão situa-se em 0,3189: a uma prevalência de 1%, aproximadamente um em cada três alertas sinaliza um ataque real, o preço deliberado de priorizar recall sobre precisão.

Escopo de verificação

A classe maliciosa contém uma única campanha de preparação de botnet em um único host, todo o tráfego vem de um único ambiente de honeypot, e o subconjunto eleva a taxa de eventos maliciosos para 45,6%, enquanto apenas a prevalência reamostrada de 1% reflete a produção; a demonstração inicial dentro da amostra do notebook (recall 1,0 com precisão de 0,034, no limite de decisão padrão) ilustra somente o comportamento do escore e fica fora do resultado principal.

Evidência

O repositório público traz o notebook executado com saídas incorporadas, nove figuras versionadas, dependências fixadas, um script de reconstrução dos dados que verifica as contagens de linhas que definem o conjunto, e uma reexecução documentada com RANDOM_STATE=42 que reproduziu exatamente cada número do resultado principal.

Resultados principais

  • Recall 0,9000 (162 de 180 ataques; IC de 95% 0,85 a 0,94) a uma taxa de falsos positivos de 1,94% no holdout de limiar congelado, com ROC AUC 0,9714
  • O Isolation Forest se ajusta sobre 31.185 eventos exclusivamente benignos, e os rótulos entram exatamente em três pontos: o filtro de ajuste benigno, a escolha do limiar de validação e a avaliação do holdout
  • Precisão 0,3189 no holdout de limiar congelado, com prevalência simulada de 1% e um orçamento de alertas de 2.822 por 100k eventos: aproximadamente um em cada três alertas sinaliza um ataque real, afirmado nesta página
  • A taxonomia de erros transforma falsos positivos em diretrizes de triagem: systemd concentra 86% do volume, e getdents64 dispara a uma taxa 37x acima de sua linha de base benigna
  • Uma reexecução com RANDOM_STATE=42 reproduziu exatamente cada número do resultado principal, com 14 das 15 células de código idênticas byte a byte às originais

Métodos

  • Isolation Forest
  • UMAP
  • Governança de limiar
  • Intervalos de confiança via bootstrap
  • Detecção de anomalias não supervisionada