Os sistemas de detecção de intrusões estão migrando da dependência quase total de assinaturas conhecidas para uma arquitetura híbrida que combina correspondência tradicional, aprendizado de máquina e investigação agencial. Uma análise publicada no blog do Stack Overflow considera o SnortML uma camada de sensoriamento de baixo nível dentro do Snort 3, enquanto a inteligência artificial agencial conecta eventos ao longo do tempo e entre fontes e decide o próximo passo da investigação.
O problema das assinaturas tradicionais não é que sejam imprecisas, mas que são precisas em relação àquilo para o qual foram projetadas. Uma regra específica para uma determinada vulnerabilidade, como a CVE-2024-12345, pode capturar a exploração conhecida com uma taxa muito baixa de falsos positivos, mas talvez não responda a uma carga útil modificada que passe pelo mesmo caminho vulnerável do código. Entre o surgimento de uma nova exploração em circulação, sua análise, a elaboração de uma regra, seus testes e sua distribuição, podem passar dias ou semanas — uma lacuna perigosa quando a vulnerabilidade está sendo efetivamente explorada.
Como o SnortML funciona dentro do Snort 3?
A Cisco Talos apresentou o mecanismo SnortML em março de 2024 como um mecanismo de detecção por aprendizado de máquina executado nativamente dentro do Snort 3. O mecanismo não depende de um serviço de nuvem externo, pois a inferência ocorre localmente, no mesmo caminho de processamento usado para avaliar as regras, e produz um resultado em menos de um milissegundo.
A implementação é composta pelo módulo snort_ml_engine, que carrega modelos TensorFlow previamente treinados na inicialização, e pelo inspetor snort_ml, que recebe dados dos inspetores de serviços existentes no Snort 3 por meio de uma interface de publicação e assinatura. Quando o inspetor HTTP termina de analisar a requisição, ele envia a string de consulta e o conteúdo POST ao barramento de eventos; em seguida, o SnortML os classifica e retorna um valor de probabilidade que indica a possibilidade de conterem uma tentativa de exploração.
O modelo utiliza uma rede LSTM precedida por uma camada de incorporação que transforma valores brutos de bytes em representações vetoriais, permitindo capturar as relações e o contexto entre os bytes, antes que a LSTM processe sua ordem e sua sequência. Uma camada densa final reduz o resultado a um único valor de probabilidade. O LibML, incluído no SnortML, utiliza a biblioteca XNNPACK para acelerar as operações matriciais. Segundo o material, uma única classificação leva aproximadamente 350 microssegundos em um processador AMD de 4,7 gigahertz.
A partir do Secure Firewall 10.0.0, o SnortML seleciona automaticamente um modelo adequado para comprimentos de 256, 512 ou 1024 bytes. As requisições que excedem 1024 bytes são truncadas nesse limite antes da classificação. A primeira versão começou detectando injeção de SQL; até o final de 2025, a cobertura havia sido ampliada para incluir XSS e injeção de comandos, e as atualizações dos modelos são distribuídas pelo próprio sistema Lightweight Security Package usado para distribuir o conteúdo das regras.
Força e limitações da abordagem híbrida
O SnortML funciona em paralelo à correspondência de assinaturas, e não como substituto dela. O modelo é capaz de capturar novas versões de ataques que se enquadram em categorias conhecidas, enquanto as assinaturas tradicionais fornecem uma linha de baixo ruído para padrões confirmados. Quando os dois caminhos geram um alerta para a mesma carga útil, isso pode ser considerado um sinal mais forte do que um alerta emitido apenas pelo aprendizado de máquina, embora cada mecanismo mantenha características de erro diferentes.
No entanto, o SnortML analisa um único parâmetro HTTP, como uma string de consulta URI ou o conteúdo POST, e não sabe o que aconteceu antes ou depois da requisição, nem o que o endereço de origem fez nos minutos anteriores. Assim, uma sequência de reconhecimento, seguida de enumeração e exploração personalizada, pode passar sem que qualquer etapa isolada ultrapasse o limiar de detecção. Além disso, o modelo atual não observa túneis DNS, ataques na camada TLS, exploração de SMB ou comportamentos anômalos em protocolos que não sejam HTTP, pois os modelos disponíveis estão vinculados ao caminho de dados do inspetor HTTP.
O tempo de processamento de aproximadamente 350 microssegundos também acrescenta um custo real, embora limitado e previsível graças ao XNNPACK. Portanto, o desempenho do modelo não deve ser analisado isoladamente do tamanho do conjunto de regras, da complexidade dos protocolos e do orçamento de processamento do dispositivo de segurança.
O que a inteligência artificial agencial acrescenta?
A análise diferencia um modelo de aprendizado de máquina que avalia apenas o que está diante dele, um playbook SOAR que segue etapas fixas e um agente que mantém o estado de uma investigação em múltiplos estágios e decide o que deve ser examinado em seguida com base nos resultados anteriores. De acordo com a concepção apresentada, o agente pode consultar o SIEM em busca de eventos relacionados, verificar a impressão digital de um arquivo por meio de uma plataforma de inteligência contra ameaças, recuperar a atividade de um usuário do provedor de identidade e, então, reunir o contexto antes de recomendar uma resposta ou encaminhá-la a um analista humano.
O artigo menciona o lançamento da plataforma ATOM, ou Autonomous Threat Operations Machine, pela IBM em abril de 2025, e o lançamento do Agentic SIEM pela Trend Micro em agosto de 2025. Esses sistemas são apresentados como plataformas de coordenação e investigação com múltiplos agentes, e não apenas como interfaces de conversação equipadas com informações de segurança. A análise relaciona sua disseminação à pressão causada pela escassez de profissionais; menciona uma lacuna global de aproximadamente quatro milhões de vagas não preenchidas em cibersegurança, além de uma pesquisa de 2025 segundo a qual 82% dos analistas de centros de operações de segurança se preocupam em deixar passar ameaças reais devido ao volume de alertas.
Nessa arquitetura, o Snort 3 e o SnortML tornam-se sensores próximos da rede, fornecendo à camada superior de inferência aquilo que foi efetivamente observado. Contudo, o aumento do nível de automação torna mais importante a precisão do sensor: um falso positivo não consome apenas o tempo do analista, mas também os recursos dos agentes e pode iniciar ações de contenção em ambientes mal configurados. Além disso, o resultado probabilístico do SnortML permite construir uma pontuação de confiança composta; um alerta que combine uma assinatura tradicional e uma pontuação de ML de 0,97 deve ser tratado de maneira diferente de um alerta emitido apenas pelo ML com pontuação de 0,61.
Arquitetura de integração e o problema do ciclo de feedback
O artigo propõe uma arquitetura que começa com uma camada de captura de pacotes por meio do DAQ, usando AFPacket RSS ou DPDK de acordo com os requisitos de taxa de transferência, seguida por uma camada de detecção que executa em paralelo o mecanismo MPSE Hyperscan e o SnortML. As duas camadas enviam eventos em formato JSON, incluindo alertas, pontuações de probabilidade e dados de fluxo, para um barramento de telemetria unificado.
Depois disso, as tarefas são distribuídas entre agentes especializados: um agente de triagem, desduplicação e estimativa de gravidade; agentes de enriquecimento e inteligência contra ameaças; um agente de investigação que conecta registros do SIEM, do provedor de identidade e dados de endpoints; e um agente de contexto que compara a atividade com padrões históricos e campanhas conhecidas. A concepção enfatiza a necessidade de devolver os resultados das investigações confirmadas aos mecanismos de modelos e regras, em vez de interromper o fluxo na etapa de resposta.
Cargas úteis que tenham sido comprovadamente ataques, mas que tenham recebido uma pontuação baixa ou não tenham correspondido a uma assinatura, podem ser transformadas em dados de treinamento ou em insumos para a formulação de novas regras. Entretanto, esse caminho exige validação humana e mecanismos para detectar envenenamento dos dados de treinamento, pois um invasor pode tentar manipular os resultados da investigação automatizada para inserir amostras corrompidas no processo de retreinamento.
Limitações de implantação e recomendações práticas
A análise identifica outras lacunas, incluindo a cobertura atual do SnortML restrita a parâmetros HTTP, a falta de maturidade dos protocolos de coordenação entre agentes e a baixa interpretabilidade dos alertas do modelo. As saídas atuais exibem a pontuação de probabilidade e a carga útil que levou ao alerta, mas não esclarecem quais bytes ou regiões da entrada influenciaram o resultado. Além disso, a robustez do modelo diante de ofuscação, codificação, manipulação de espaços e injeção de comentários SQL não foi descrita publicamente em avaliações divulgadas, segundo o material.
Na prática, o artigo recomenda iniciar o SnortML em uma porta de monitoramento e no modo somente alerta, não no caminho direto com bloqueio. Os falsos positivos devem ser medidos no tráfego de aplicações conhecidas durante pelo menos duas semanas que cubram os ciclos de trabalho habituais; em seguida, os limites devem ser ajustados antes de ativar a implantação inline seletiva. A pontuação de ML também deve ser tratada como um fator no cálculo de uma confiança composta, e não como substituta da assinatura tradicional ou como gatilho isolado para bloqueio.
Já as medidas de contenção de alto impacto, como bloquear endereços IP, isolar dispositivos ou redefinir credenciais, devem permanecer sob revisão humana. A principal conclusão da análise é que a automação pode cuidar da triagem, do enriquecimento, da correlação e da agregação intensiva de contexto, enquanto a decisão final de resposta permanece mais segura quando revisada por uma pessoa com base no contexto reunido pelo agente.