Modelo de Maturidade de Pipeline de Deteccao

A edição #155 do Detection Engineering Weekly (DEW) chega como uma compilação das melhores “Gems” publicadas nos primeiros cinco meses de 2026. Zack, o curador, selecionou artigos que abordam desde modelos de maturidade para pipelines de detecção até refinamentos teóricos na taxonomia MITRE ATT&CK, passando por implementações práticas de supressão centralizada de alertas e métodos estatísticos para baselining comportamental. É uma edição densa, voltada para engenheiros de detecção que buscam elevar tanto a arquitetura de seus sistemas quanto a profundidade analítica de suas regras.

Detection Pipeline Maturity Model: Medindo a Sanidade do Pipeline

Scott Plastine propõe um modelo de maturidade para pipelines de detecção, organizado em seis níveis que vão de “nenhuma maturidade” — onde analistas mantêm dezenas a centenas de abas do Chrome abertas para investigar alertas em ferramentas isoladas — até um estágio “Líder”, onde o foco não é adicionar mais regras, mas reduzi-las através de correlação baseada em entidades, detecção baseada em risco e regras orientadas por data science.

O insight central do artigo é que a armadilha mais comum entre times em progressão de maturidade é acreditar que mais regras equivalem a melhor detecção. Plastine argumenta que uma função de detecção verdadeiramente madura é medida pela capacidade de reduzir a contagem de regras — e, consequentemente, a complexidade do gerenciamento — sem perder cobertura. A arquitetura “Standard+” apresentada no artigo ilustra como ferramentas de orquestração, normalização de logs e motores de alerta baseados em risco podem substituir o modelo fragmentado de dezenas de consoles individuais.

“As you progress through maturity, the trap teams fall into is more rules is better. I think the measure of a Leading detection function is reducing rule count thereby reducing the complexity of managing rule sprawl.” — Scott Plastine

TTPIs: Estendendo o Modelo Clássico com o Conceito de “Instance”

Andrew VanVleet propõe uma extensão ao modelo TTP do MITRE ATT&CK, introduzindo o conceito de “Instance”. A crítica central é que as Procedures (Procedimentos) na taxonomia atual são frequentemente vagas por design — o que é necessário para manter a independência de contexto ambiental, mas que dificulta a reprodutibilidade e o teste de detecções.

VanVleet usa a analogia de que Procedures são como um bolo, enquanto a “Instance” seria a receita — os detalhes específicos de implementação que permitem a um engenheiro de detecção recriar o ataque em seu próprio ambiente. O MITRE ATT&CK se aproxima desse conceito através das Detection Strategies, que fornecem pistas sobre IDs de eventos, mas sem a implementação técnica, pode ser difícil recriar e testar a detecção.

O artigo propõe uma “Pirâmide da Permanência” como alternativa à clássica Pirâmide da Dor, onde as Procedures ocupam o topo (o que realmente queremos capturar) e as Instances são os meios que sustentam cada Procedure. É uma contribuição valiosa para o debate sobre lexicografia de ameaças e modelagem de detecções.

Supressão Centralizada com Macros e Lookups no Splunk

Harrison Pomeroy detalha uma abordagem engenhosa para supressão de alertas no Splunk sem necessidade de reimplantar regras. Utilizando macros e lookup tables, é possível implementar lógica dinâmica de supressão que avalia, em tempo de consulta, se um alerta deve ser suprimido com base em contextos como contas de serviço conhecidas, tarefas agendadas ou ferramentas internas.

O diagrama Mermaid apresentado no artigo mostra como uma macro aplicada a cada regra Splunk pode avaliar se a supressão está habilitada (valor T) e, em caso positivo, consultar uma lookup table específica para a regra, aplicando filtros NOT() para evitar falsos positivos. O benefício é duplo: reduz o custo de triagem de falsos positivos e torna as regras mais resilientes a mudanças no ambiente, sem exigir modificações no código da regra em si.

Baselining com Estatística: Z-Score Modificado e o Fim do Palpite

Brandon Lyons oferece um dos artigos mais práticos da compilação, estabelecendo um processo de 7 etapas para criar baselines de detecção baseados em dados. O coração do método é o Modified Z-Score, uma métrica estatística que mede o quão distante um valor está da mediana em unidades de desvio absoluto mediano (MAD).

Diferentemente do Z-Score tradicional (que usa média e desvio padrão e é sensível a outliers), o Modified Z-Score é robusto para distribuições com valores extremos — exatamente o cenário típico de dados de segurança. Lyons usa o exemplo de chamadas de API do CloudTrail: em vez de definir um limite absoluto arbitrário (“1000 chamadas é suspeito”), o método calcula quantos desvios da mediana um valor representa, removendo o julgamento humano do processo de definição de limites.

As 7 etapas propostas são:

• Backtesting da lógica da regra — validar a detecção contra dados históricos antes de implantar
• Processo de pensamento codificado — documentar por que limites e métodos específicos foram escolhidos
• Contexto histórico — capturar como o ambiente estava quando o baseline foi criado
• Processo reproduzível — permitir reexecução ao ajustar ou validar lógica de detecção
• Fundação para ADS — alimentar diretamente a documentação da Estratégia de Detecção de Alertas
• Combustível para colaboração entre times — superfícies padrões inseguros com evidências baseadas em dados
• Pista para Threat Hunting — quando a precisão do alerta não é alcançável, converter o baseline em uma caça programada

Lyons disponibilizou um Jupyter Notebook com dados sintéticos para que engenheiros possam reproduzir as medições e adaptar o método aos seus próprios ambientes — um recurso raro e valioso em um campo onde a transparência metodológica ainda é exceção, não regra.

Análise e Recomendações Práticas

• Avalie a maturidade do seu pipeline: O modelo de Plastine oferece um framework concreto para diagnosticar onde seu time está e para onde deveria evoluir. Se você ainda está no estágio “nenhuma maturidade” (dezenas de abas do Chrome abertas), o próximo passo é centralizar o gerenciamento de casos.
• Adote o conceito de “Instance”: Ao documentar detecções, inclua não apenas a Técnica e o Procedimento MITRE, mas uma receita detalhada (Instance) que permita a qualquer engenheiro recriar o ataque e testar a telemetria no ambiente local.
• Implemente supressão centralizada: A abordagem de Pomeroy com macros e lookup tables é aplicável não apenas no Splunk, mas como conceito em qualquer SIEM que suporte funções de lookup e macros. Reduza o atrito entre geração de alertas e triagem.
• Pare de chutar limites: O método do Modified Z-Score de Lyons substitui limites absolutos arbitrários por medições relativas baseadas em dados históricos do seu próprio ambiente. Implemente um processo de baselining estatístico antes de implantar a próxima regra.

Análise baseada no Detection Engineering Weekly #155 — Gems from the 2026 Trenches (11/05/2026). Curadoria de Zack. Redação técnica: N00TROP1C — NULLTROPIC, 2026.