Escalando a triagem de alertas de segurança com agentes especializados no Databricks

E se baixa gravidade não significasse baixa prioridade?

A Databricks ingere petabytes de logs de segurança de uma variedade de fontes, incluindo ferramentas de segurança de endpoint, logs de atividade na nuvem e feeds de inteligência de ameaças em nosso lakehouse de segurança. Nossa arquitetura de detecção monitora continuamente esses dados em busca de atividades maliciosas. Cada sinal identificado vai para uma tabela de alertas centralizada, onde aguarda a revisão de um analista de Incident Response (IR).

Encontrar uma ameaça real em milhares de alertas diários de segurança é o clássico problema de encontrar uma agulha no palheiro. A maioria das equipes lida com a carga priorizando os alertas por gravidade. As equipes fazem a triagem dos alertas de gravidade ALTA (HIGH) e MÉDIA (MEDIUM) e trabalham nos de gravidade BAIXA (LOW) conforme a disponibilidade de tempo.

Na Databricks, nossa equipe de IR lida com alertas de segurança em todos os três níveis de prioridade. Historicamente, a equipe priorizava alertas de gravidade ALTA e MÉDIA devido ao volume e à baixa fidelidade dos alertas de gravidade BAIXA. Toda equipe de segurança em grande escala enfrenta esse mesmo dilema: aumentar o número de analistas, elevar os limites de alerta e aceitar pontos cegos, ou encontrar uma maneira de automatizar o processo. Escolhemos a última opção, aproveitando agentes que podem raciocinar e tomar decisões em escala.

O caso dos agentes especializados

Para validar se os agentes podiam fazer a triagem e encaminhar alertas de segurança de forma confiável, começamos com alertas de baixa gravidade. Nosso objetivo era simples: identificar os alertas que justificavam uma investigação mais aprofundada.

No início, adotamos uma abordagem simples: colocamos todos os dados relevantes do alerta em um único prompt e deixamos que um modelo de fundação decidisse o que encaminhar. Essa abordagem resultou em uma taxa de encaminhamento de 50%. Enviar metade de todos os alertas para os analistas não era triagem, era apenas um tipo diferente de ruído.

O problema era o contexto. Um único agente raciocinando sobre cada alerta não tem como distinguir o que é um comportamento anormal para cada fonte. Tudo o que é necessário para fazer a triagem de um alerta com precisão — seus padrões de falsos positivos, linhas de base comportamentais e enriquecimento relevante — é específico da fonte. Sem esse contexto, o conhecimento geral de segurança cibernética era tudo o que o modelo tinha para trabalhar, e isso não era suficiente para uma triagem precisa.

Arquitetura: uma frota de agentes

Reconstruímos o pipeline em torno de 17 agentes específicos de origem, cada um ajustado para uma única fonte de detecção, pois o contexto necessário para uma triagem precisa é altamente específico da fonte. Uma única fonte pode emitir dezenas de detecções distintas, e seu agente lida com todas elas.

Também temos um agente dedicado de Threat Intelligence (TI) que atua junto à frota de triagem de agentes de baixa gravidade e pode ser chamado por qualquer agente quando este encontra um indicador ou comportamento que justifique uma investigação mais profunda. O agente de TI consulta nossas fontes de inteligência de ameaças e retorna uma avaliação estruturada: se este artefato é sabidamente malicioso, desconhecido ou benigno. Isso importa porque indicadores brutos de comprometimento não têm significado sem contexto. Um endereço IP é apenas um número. O mesmo IP enriquecido com “associado à infraestrutura C2 nos últimos 14 dias, alta confiança” torna-se imediatamente acionável pelo agente.

Usando o Structured Streaming na Databricks, os alertas de baixa gravidade são ingeridos à medida que são acionados, enriquecidos com contexto adicional pelo agente de TI e roteados para o subagente apropriado para revisão.

Cada agente segue os mesmos princípios de design:

Filtragem determinante. Verificações programáticas comparam o título do alerta e os campos de contexto para suprimir sinais sabidamente benignos (nuances específicas do ambiente, como listas de IPs confiáveis, atividade de contas de serviço, comportamento esperado de ferramentas) e produzir resoluções instantâneas sem qualquer chamada de LLM. Elas lidam com 30% a 95% do volume de alertas, dependendo da fonte. Coisas como “função IAM sabidamente segura realizando operações esperadas” ou “e-mail de administrador realizando governança rotineira do workspace”. A filtragem pode ocorrer na camada de detecção ou junto à própria lógica de triagem.

Enriquecimento de contexto. Antes que o LLM veja o alerta, o agente busca o histórico recente de alertas da entidade afetada, atividades relacionadas e outros sinais relevantes. Os agentes também podem invocar outros recursos de agentes durante o enriquecimento — por exemplo, chamando o agente dedicado de Threat Intelligence quando um alerta contém um IP ou domínio que vale a pena investigar.

Funções de prompt especializadas. Cada título de alerta é mapeado para uma função de prompt. Por exemplo, alertas de acesso anômalo ao S3 vão para uma função com instruções para avaliar reconhecimento de IAM, e alertas de escalonamento de privilégios vão para uma que conhece padrões esperados versus inesperados de assunção de função. Se nenhuma função dedicada corresponder, um prompt de fallback genérico lidará com o alerta. As funções de prompt são executadas no modo de turno único (uma chamada de LLM) ou no modo de agente (loop de chamada de ferramenta multiturno), dependendo se o alerta precisa de contexto adicional para uma triagem confiável.

Ferramentas compartilhadas. As ferramentas são opcionais e específicas de cada agente. Quando a triagem exige mais contexto — logs brutos de auditoria em nuvem, alertas correlacionados de várias fontes ou histórico de atividades do IdP —, equipamos o agente com ferramentas para recuperá-lo, e o LLM decide se e quando invocá-las com base na ambiguidade das evidências.

Utilitários compartilhados. Para gerenciar a sobrecarga de manutenção de vários agentes, refatoramos o código de utilitários compartilhados em um framework comum que lida com a invocação de agentes, tentativas de repetição e avaliação de desempenho. Toda a lógica consistente entre as fontes de dados reside aqui, incluindo o loop de chamada de LLM, análise de resolução, envio de ferramentas, persistência de resultados em tabelas Delta, rastreamento de tokens, rastreamento do MLflow e detecção de injeção de prompt.

Raciocínio e resolução do LLM. O modelo analisa o pacote de evidências e retorna uma saída estruturada, incluindo uma resolução (encaminhar, monitorar ou fechar) com uma análise de suporte.

Gerenciamento de custos. Existem três controles de gastos. Primeiro, a filtragem determinante garante que os alertas que correspondem a padrões sabidamente benignos nunca cheguem a um LLM. A chamada mais barata é aquela que você nunca faz. Segundo, um rastreador de custos acumula os gastos estimados de cada lote e interrompe o processamento se um limite configurável for atingido, registrando os alertas restantes como ignorados. Terceiro, um limite diário de alertas estabelece um teto para o custo diário total, independentemente do volume de entrada. Dentro de cada alerta, orçamentos de chamadas de ferramentas por categoria evitam loops de descoberta contínuos, nos quais o LLM poderia continuar consultando contexto adicional indefinidamente.

Se o agente decidir encaminhar, o alerta se torna um ticket na fila de IR, onde os analistas revisam tanto o alerta bruto quanto a análise do agente antes de tomar uma decisão final de triagem. Quando um analista discorda do encaminhamento de um agente, o ticket é rotulado como falso positivo, e esse feedback é usado para ajustar o desempenho do agente. Descobrimos que os alertas de baixa gravidade encaminhados por agentes tinham cerca de 10 vezes mais chances de serem verdadeiros positivos do que os alertas existentes priorizados como de gravidade ALTA e MÉDIA.

O benchmark humano por trás de cada decisão do agente

Quando um analista humano revisa um ticket encaminhado, sua decisão de confirmar ou anular a ação do agente se torna a verdade fundamental (ground truth) para a avaliação. Ao contrário de programas determinísticos, onde você pode testar em relação a uma especificação fixa, os agentes exercem julgamento. O mesmo alerta pode produzir saídas diferentes em várias execuções. Portanto, em vez de testar em relação a uma especificação, testamos em relação a um conjunto de dados padrão desenvolvido por analistas de IR que já sabem como é uma decisão de triagem de alta qualidade.

Cada solicitação do agente é registrada usando o MLflow, capturando entradas, etapas intermediárias e saídas finais. À medida que os analistas de IR rotulam os tickets no decorrer de seu fluxo de trabalho normal, cada rótulo é registrado diretamente no rastreamento correspondente do MLflow como uma resposta esperada. Esses rastreamentos rotulados estabelecem um conjunto de dados de verdade fundamental que captura o julgamento dos analistas em escala. Esse conjunto de dados se torna o benchmark para avaliar quaisquer alterações futuras de prompt antes de serem implementadas.

Para medir além dos falsos positivos, planejamos usar o Databricks Review App, uma interface para revisar alertas e rotular rastreamentos do MLflow. Os analistas podem ver as entradas, o raciocínio e a decisão do agente para cada alerta e registrar o resultado esperado diretamente no rastreamento. Isso permite que os analistas revisem também alertas não encaminhados, ampliando a cobertura da verdade fundamental para alertas que o agente escolheu monitorar ou fechar, nos dando um padrão completo para todas as três resoluções.

Resultados

Os agentes de segurança agora revisam 100% dos alertas de baixa gravidade. As principais métricas incluem:

• Os agentes fizeram a triagem de mais de 18.000 alertas com uma taxa de encaminhamento de 3,2%
• Os alertas de baixa gravidade encaminhados por agentes tinham cerca de 10 vezes mais chances de serem verdadeiros positivos do que os alertas de gravidade ALTA ou MÉDIA
• Tempo mediano de triagem: 10,5 segundos
• Economia de mais de 6.500 horas de analistas nos primeiros 30 dias

Descobertas notáveis que foram encaminhadas por agentes:

• Redução da taxa de falsos positivos de uma fonte de alertas de 72% para 3,4%
• Identificação de 22 domínios suspeitos, estacionados ou maliciosos
• Detecção de um caso em que um usuário baixou e executou um software craqueado; o agente sinalizou indicadores comportamentais consistentes com violação de política e intenção maliciosa.

O que aprendemos

LLMs alucinam com dados de segurança de alta entropia. Hashes, subdomínios aleatórios e nomes de arquivos gerados são difíceis para modelos de linguagem. Os modelos são bons em raciocinar sobre a linguagem porque ela possui padrões. Artefatos de segurança, como hashes, são deliberadamente livres de padrões, o que é exatamente o que os torna difíceis para LLMs. Para garantir a precisão, usamos o modelo para raciocínio e não para recuperação. Valores de artefatos específicos são recuperados por meio de chamadas de ferramentas para fontes autoritativas, não da memória de um modelo.

O contexto é rei. Os maiores ganhos de desempenho vieram da adição de dados históricos de alertas, taxas de falsos positivos por tipo de alerta e padrões de comportamento explícitos a cada prompt. Ao processar qualquer alerta, o agente de triagem busca os últimos seis meses de histórico de alertas do usuário afetado. Em vários casos, os agentes escalaram alertas não porque o evento desencadeador fosse individualmente de alta confiança, mas porque era o terceiro ou quarto sinal suspeito do mesmo usuário. Esse tipo de correlação comportamental é algo que as regras de detecção determinísticas anteriores tinham dificuldade para capturar.

Automatize o que é previsível e deixe os agentes raciocinarem apenas sobre o que não é. Sempre que possível, opte por fluxos de trabalho determinísticos para restringir o escopo do que o LLM precisa analisar. Quanto mais abertas forem as instruções, maior será a taxa de falsos positivos. Instruções de agentes com escopo bem definido e passo a passo superaram consistentemente os prompts amplos. Aplicar filtragem baseada em regras antes que o LLM veja um alerta é um dos exemplos mais eficazes disso.

Desenvolvido na Databricks

Este sistema foi desenvolvido na Databricks usando Spark Structured Streaming para ingestão de alertas em tempo real, tabelas Delta para persistência e relatórios de alertas, MLflow Tracing para capturar cada decisão do agente de ponta a ponta e o Databricks Review App para que os analistas possam rotular traces e criar o ground truth diretamente dos dados de produção.

Na Databricks, nós criamos as ferramentas que usamos. Este é um exemplo de como nossa própria plataforma está impulsionando operações de segurança nativas de IA. A seguir: como o Databricks Genie pode trazer a investigação em linguagem natural para o SOC, dando aos analistas de IR a capacidade de consultar dados de alertas, explorar o contexto e investigar ameaças de forma conversacional.

(Esta publicação no blog foi traduzida utilizando ferramentas baseadas em inteligência artificial) Publicação original