Signal-to-Noise Ratio (SNR)

Nota do Capítulo 18, pasta de Métricas de Qualidade de Detecção.
Trata o SNR (signal-to-noise ratio) como métrica de qualidade operacional de regras de detecção: fórmula, mensuração por regra, interpretação e técnicas de melhoria.
Dialoga com as notas de Threat Prevalence e de Cobertura por Tática ATT&CK da mesma pasta, com a nota de Sobrecarga de Alertas do capítulo 12 e com os KPIs do capítulo 11.

1. Contexto e Posicionamento na Biblioteca

A engenharia de detecção tratada neste capítulo produz um catálogo de regras, e todo catálogo precisa de um juiz que diga quais regras valem o custo de operá-las. Esta nota apresenta o SNR como esse juiz: a relação entre o que uma regra acerta, o sinal, e o que ela erra, o ruído. A métrica é simples de calcular e difícil de interpretar, e a maior parte do valor está justamente na interpretação, porque SNR alto e SNR baixo contam histórias diferentes sobre a mesma regra.

O posicionamento metodológico é o ponto mais importante da nota: SNR é métrica de regra, não de equipe. Um SOC pode ter uma regra de SNR espetacular e, ainda assim, estar cego para a maioria das técnicas de um adversário relevante, e pode ter uma regra de SNR modesto que é a única coisa entre o ambiente e um ransomware. Por isso a mensuração é feita por regra, com janela temporal fixa e disposição registrada pelos analistas, e a decisão final de tunar, reescrever, mover para analytics agendado ou aposentar nunca sai do número sozinho.

Na biblioteca, a nota sustenta o triângulo de qualidade desta pasta: o SNR mede operação, a Threat Prevalence mede o valor da técnica no ecossistema e a Cobertura por Tática ATT&CK mede abrangência. As três medidas juntas respondem à pergunta que gerência e time técnico fazem de formas diferentes: esta detecção merece existir?

2. Conceito e Fórmula

O sinal de uma regra é o conjunto de alertas verdadeiros positivos, casos em que o comportamento pretendido pela regra realmente aconteceu e merecia atenção. O ruído é o conjunto de falsos positivos, alertas disparados por atividade legítima que casou com a condição sem representar ameaça. A fórmula operacional é direta e trabalha com contagens obtidas da disposição registrada pelos analistas sobre cada alerta da janela avaliada.

SNR      = verdadeiros_positivos / falsos_positivos
Precisão = verdadeiros_positivos / (verdadeiros_positivos + falsos_positivos)

SNR e precisão são lentes complementares sobre o mesmo dado. A precisão, equivalente ao valor preditivo positivo, expressa em porcentagem a chance de um alerta aleatório da regra ser verdadeiro, e funciona bem para comunicação com gestão. O SNR expressa a proporção por unidade de ruído e funciona melhor para engenharia, porque indica quantos falsos positivos a regra precisa eliminar para dobrar de qualidade. Uma regra com 12 verdadeiros positivos e 3 falsos positivos tem SNR de 4 e precisão de 80%, números que descrevem uma regra saudável na maioria dos contextos.

Não existe SNR universalmente aceitável, porque o custo de um falso positivo depende da regra e do ambiente. Uma regra de lançamento de payload a partir de documento Office pode conviver com SNR 2, porque cada falso positivo barato compra cobertura contra um evento caro. Uma regra de enumeração de rede, que dispara centenas de vezes por dia, precisa de SNR muito maior para não afogar a fila. A prática saudável é definir faixas de referência por categoria de regra e revisar as faixas com o histórico do próprio SOC, tema retomado mais adiante.

3. Mensuração por Regra

A mensuração por regra exige três insumos que o SOC precisa garantir por processo, e não por boa vontade. O primeiro é a janela de avaliação, tipicamente 30 dias para regras de volume alto e 90 a 180 dias para regras raras, porque uma regra que dispara 4 vezes por ano não produz estatística em 30 dias. O segundo é a disposição registrada por analista para cada alerta, com taxonomia fixa. O terceiro é a atribuição da disposição à regra específica, e não ao incidente, para que a estatística sobreviva quando o alerta é correlacionado a outros.

• Janela fixa e documentada: cada regra declara sua janela de avaliação no catálogo, e a métrica é recalculada automaticamente nesse ritmo, sem extração manual.
• Disposição obrigatória: nenhum alerta é encerrado sem disposição, porque alerta sem triagem é ruído na prática e precisa contar como tal no fim da janela.
• Taxonomia fechada: as opções de disposição são verdadeiro positivo, falso positivo benigno e falso positivo desconhecido, e qualquer outra categoria é redirecionada para essas três.
• Duplicatas herdadas: alertas encerrados como duplicata herdam a disposição do alerta original, evitando inflar artificialmente qualquer um dos lados.

let janela = 30d;
let disposicoes = dynamic(["verdadeiro_positivo", "falso_positivo_benigno",
                          "falso_positivo_desconhecido"]);
Deteccao
| where timestamp > ago(janela) and regra_id == "DETEC-0142"
| where disposicao in (disposicoes)
| summarize alertas_triados = count(),
            verdadeiros = countif(disposicao == "verdadeiro_positivo"),
            falsos = countif(disposicao != "verdadeiro_positivo")
| extend snr = round(verdadeiros * 1.0 / max_of(falsos, 1), 2),
         precisao_pct = round(verdadeiros * 100.0 / max_of(alertas_triados, 1), 1)

A consulta acima ilustra o padrão mínimo: agrupar por regra, contar por disposição e derivar as duas métricas. Detalhes de implantação mudam por plataforma, mas as decisões de janela, taxonomia e herança de duplicatas precisam ser tomadas uma única vez e documentadas no repositório de detecções, porque cada alteração nessas decisões quebra a comparabilidade histórica das métricas.

4. Taxonomia de Disposição e Armadilhas de Coleta

A qualidade do SNR é limitada pela qualidade da disposição, e a taxonomia precisa ser operacionalmente clara para analistas sob pressão. Falso positivo benigno é o alerta gerado por atividade legítima conhecida, como ferramenta de inventário rodando script de enumeração. Falso positivo desconhecido é o alerta que o analista não consegue explicar no tempo da triagem, e essa categoria é a mais valiosa do ponto de vista de engenharia, porque aponta tanto ruído a tunar quanto lacuna de visibilidade a investigar.

• Verdadeiro positivo: o comportamento pretendido pela regra aconteceu e merecia atenção, seja incidente real, seja emulação controlada de exercício purple team devidamente marcada.
• Falso positivo benigno: atividade legítima identificada e explicável, candidata direta a exclusão com justificativa e data de expiração no tuning da regra.
• Falso positivo desconhecido: atividade inexplicada na triagem, que abre dois caminhos de trabalho, o tuning se for ruído e a investigação se for sinal real ainda não compreendido.

O efeito mais destrutivo sobre a métrica é o abandono silencioso da disposição. Quando o time aprende a ignorar uma regra ruidosa, os falsos positivos somem da contagem não porque a regra melhorou, mas porque ninguém mais a tria, e o SNR melhora no dashboard enquanto piora na realidade. O antídoto é administrativo: percentual mínimo de alertas com disposição registrada por semana entra no quadro de saúde do catálogo, e regras com taxa de não triagem crescente entram em revisão prioritária antes que a métrica delas fique inutilizável.

5. Por que SNR Alto Demais Esconde Técnica Fraca

A intuição de que SNR alto é sempre bom falha em três situações recorrentes. A primeira é a regra que só dispara em evidência incontestável, como hash de malware confirmado ou execução de ferramenta ofensiva conhecida. O SNR é quase infinito e a técnica é fraca: o adversário troca uma linha de código e a regra nunca mais alerta, exatamente o fundo da Pirâmide de Dor. SNR alto nesse caso mede o fato de a regra exigir certeza absoluta, o que é outra forma de dizer que ela exige que a detecção já tenha acontecido em outro lugar.

A segunda situação é o tuning predatório, que afina a regra até ela cobrir apenas o cenário exato usado no teste que a aprovou. A regra alerta de forma limpa quando o time roda o mesmo atômico do mesmo jeito e fica muda diante de qualquer variação trivial do adversário. O terceiro caso é o ruído invisível descrito na seção anterior, com falsos positivos deixando de ser registrados. A lição é tratar o SNR como sinal a interpretar junto de prevalência e cobertura, e nunca como nota final da regra.

A leitura da tabela conduz a um hábito de engenharia: todo SNR alto merece uma pergunta de auditoria sobre o que a regra exige para alertar. Se a resposta envolve certeza absoluta, cenário de teste exato ou base de reputação de terceiros que já decide por si, a regra provavelmente soma SNR e subtrai cobertura, e a conta honesta precisa considerar os dois lados antes de comemorar.

6. Como Melhorar o SNR

As alavancas de melhoria se organizam em três famílias, e a ordem de aplicação importa porque cada uma tem custo e risco próprios. Tuning restringe a condição da regra com exclusões justificadas e datadas. Escopo limita onde a regra roda, por tipo de ativo, função do host, grupo de usuários ou período. Enriquecimento adiciona corroboração antes do alerta, exigindo que o comportamento case com raridade, linhagem de processo suspeita ou contexto de inteligência para virar alerta. A família que resolve o problema depende do diagnóstico: ruído de software legítimo pede tuning, ruído de ativos irrelevantes pede escopo e ruído de comportamento ambíguo pede enriquecimento.

• Tuning com governança: toda exclusão carrega justificativa, autor, data de expiração e teste de regressão, porque exclusão sem expiração vira buraco de cobertura que ninguém lembra de revisar.
• Escopo por relevância: regra de criação de serviço em controlador de domínio roda apenas em controladores de domínio, o que corta ruído sem tocar na lógica da detecção.
• Enriquecimento barato antes do caro: exigir que o processo pai seja incomum já elimina boa parte do ruído antes de investir em reputação de arquivo ou decomposição de linha de comando.
• Correlação em dois estágios: eventos fracos viram observações silenciosas que só alertam quando somados a outro sinal da mesma entidade em janela curta, trocando latência por precisão.

O exemplo a seguir mostra um trecho de regra antes e depois de um ciclo de melhoria guiado pelo SNR, com a exclusão de build de software documentada como deve ser. A diferença entre as duas versões é pequena em texto e grande em operação, porque o bloco de exclusão explica ao próximo engenheiro por que aquilo foi removido e até quando vale.

regra: DETEC-0142
versao: 2
condicao: processo == "certutil.exe" AND comando CONTÉM "http"
exclusoes:
  - id: EXC-2025-011
    justificativa: "pipeline de build baixa binários com certutil em CI"
    escopo: hosts_com_tag == "build_agent"
    autor: engenharia_deteccao
    expira_em: 2026-03-31
corroboracao_exigida: processo_pai NOT IN ["explorer.exe", "cmd.exe_interativo"]

7. Exemplo de Cálculo por Regra

O exemplo a seguir mostra um painel de catálogo com quatro regras de um SOC hipotético, com contagens de 30 dias e decisões decorrentes. A regra DETEC-0127 tem SNR modesto e permanece, porque cobre um comportamento de cadeia de ransomware com poucos substitutos. Já a regra DETEC-0142 é o caso clássico de regra publicada por terceiro que não foi calibrada para o ambiente, e por isso vira projeto de reescrita em vez de vira excluída.

Duas observações sobre a leitura da tabela reforçam o método. A regra DETEC-0051 alertou nove vezes em 30 dias com precisão total porque o comportamento é raro na telemetria legítima, o que a caracteriza como detecção de prevalência baixa, conceito tratado na próxima nota, e não como prova de genialidade do autor. O par de regras DETEC-0093 e DETEC-0142 mostra por que o volume importa: ambas têm contagens pequenas demais para estatística estável, e a decisão correta passa por estender a janela ou gerar verdadeiros positivos controlados via emulação.

8. Faixas de Referência por Categoria de Regra

Faixas de referência transformam o SNR de curiosidade em ferramenta de gestão, e a forma mais útil de defini-las é por categoria de regra, considerando o custo do falso positivo e o volume natural do comportamento. As faixas abaixo servem de ponto de partida e devem ser recalibradas com o histórico do próprio ambiente, porque um SOC que recebe 200 alertas por dia tem tolerâncias diferentes de um que recebe 2 mil.

As faixas funcionam como gatilho de processo, e não como sentença. Regra abaixo do mínimo aceitável entra na fila de tuning com prazo, regra consistentemente acima do alvo entra em auditoria de cobertura para verificar se o tuning não a transformou em regra de cenário único, e regra sem disparo na janela entra na rotina de teste agendado, porque silêncio não é qualidade e pode ser regressão.

9. Erros Comuns e Pontos de Atenção

• Calcular SNR sem janela fixa por regra, o que permite comparar regras com períodos diferentes e produz decisões sem sentido.
• Tratar ausência de disposição como verdadeiro positivo por omissão, inflando o sinal com alertas que ninguém leu.
• Perseguir SNR máximo como meta de equipe, o que incentiva tuning predatório e regras que só alertam o óbvio.
• Medir SNR de detecções de vendor no lugar das regras próprias, já que alertas de produto chegam com qualidade decidida pelo fabricante e a alavanca do time é outra.
• Ignorar regras silenciosas, que não produzem sinal nem ruído e escondem regressão de cobertura que só um teste agendado revelaria.
• Somar SNR de regras em uma média por equipe, escondendo justamente as regras individuais que precisam de intervenção.

O ponto de atenção que mais reduz erros é separar as duas perguntas que o número responde. Para a operação, SNR baixo é dor imediata de fila e pede ação de tuning na semana. Para a engenharia, SNR alto em regra de técnica fraca é dor silenciosa e pede ação de cobertura no próximo ciclo. Conflar as duas perguntas em uma única nota de performance é a receita para otimizar o dashboard e empobrecer o catálogo.

10. Integração com o Restante da Biblioteca

A nota de Threat Prevalence, imediatamente seguinte nesta pasta, fornece o contrapeso do SNR: prevalência baixa explica por que uma regra pode ter SNR alto sem ser fraca, e a matriz de prevalência por criticidade ajuda a decidir quais regras merecem investimento de reescrita. A nota de Cobertura por Tática ATT&CK consome o SNR como um dos filtros para separar cobertura nominal de cobertura real, porque regra com ruído crônico tende a ser desligada e a virar buraco disfarçado. Juntas, as três notas formam o quadro de qualidade desta pasta.

Fora da pasta, o SNR alimenta os KPIs de detecção do capítulo 11, que usam precisão e volume como linguagem de gestão, e dialoga com a nota de Sobrecarga de Alertas do capítulo 12, que trata o mesmo fenômeno na escala do analista e da fila. A conexão com o capítulo 19 é direta: exercícios purple team geram os verdadeiros positivos controlados que permitem validar o SNR sem esperar um incidente real, e o documento de promoção da nota de Hunting-to-Detection Bridge já exige estimativa de ruído antes de a caça virar regra.