Home Comunidade Eventos YouTube Networks Desafios // produtos Academy News CTI | CVE Contato

02 - Threat Prevalence e Priorização

video explicativo
Video explicativoEspaco reservado para o video desta anotação — adicione video: https://youtu.be/... no frontmatter da nota.

Threat Prevalence e Priorização

Nota do Capítulo 18, pasta de Métricas de Qualidade de Detecção.
Define prevalência como a frequência com que o comportamento de uma técnica aparece na telemetria legítima do ecossistema e usa a medida para priorizar detecções e caças.
Dialoga com a nota de SNR e a de Cobertura por Tática ATT&CK da mesma pasta, com a Pirâmide de Dor do capítulo 4 e com a priorização de hipóteses do framework CTH no capítulo 15.

1. Contexto e Posicionamento na Biblioteca

A nota anterior mediu a qualidade operacional de uma regra com o SNR, e esta nota mede o valor da técnica que a regra pretende cobrir. Prevalência, no vocabulário de detecção, é a medida de quão comum é o comportamento associado a uma técnica na telemetria legítima do próprio ecossistema, independentemente de haver adversário envolvido. A medida é a ponte mais econômica entre inteligência de ameaças e engenharia de detecção, porque transforma a pergunta subjetiva de quais técnicas priorizar em uma comparação numérica entre o uso pelo adversário e a frequência no ambiente.

O posicionamento na biblioteca é o de instrumento de decisão. No capítulo 15, o controle TH.5 trata a priorização de hipóteses de caça e pede critérios objetivos, e prevalência é um desses critérios, junto com criticidade do ativo e uso conhecido pelo adversário. No capítulo 4, a Pirâmide de Dor já sugeriu que indicadores raros valem mais que indicadores banais, e a prevalência operacionaliza essa intuição em número medido, aplicado agora a técnicas e não a indicadores.

A nota se organiza em três movimentos: definir e medir prevalência com dados próprios, ajustar a medida com fontes externas e usar o resultado na fila de detecções e caças por meio de uma matriz de decisão. O leitor que já mantém catálogo de detecções encontrará aqui a justificativa quantitativa para a ordem da fila, e o leitor que está começando encontrará a primeira pergunta a fazer antes de escrever qualquer regra.

2. O Conceito de Prevalência

Prevalência de uma técnica é a fração do parque monitorado que apresentou o comportamento característico da técnica em uma janela de tempo, sem considerar intenção. Na forma mais usada, divide-se o número de hosts distintos que produziram o evento característico pelo número total de hosts monitorados na janela. Dependendo da técnica, a unidade muda: usuários para técnicas de conta, inquilinos de SaaS para técnicas de cloud, processos por imagem de máquina para técnicas de execução. O que não muda é a lógica, quanto menor a fração, mais discriminante é o comportamento e menor a pressão de falsos positivos sobre qualquer regra que o observe.

Técnica (ATT&CK) Evento característico Hosts com o evento Hosts totais Prevalência
T1053.005 Scheduled Task Criação de tarefa agendada 1.840 2.300 80,0%
T1059.001 PowerShell Execução de powershell.exe 2.070 2.300 90,0%
T1105 Ingress Tool Transfer Certutil com download remoto 23 2.300 1,0%
T1003.001 LSASS Memory Handle de leitura em lsass.exe 4 2.300 0,17%
T1021.002 SMB/Admin Shares Execução via Admin$ 2 2.300 0,09%
T1078 Valid Accounts Conta administrativa usada fora de janela 610 2.300 26,5%
T1110.001 Password Guessing Rajada de autenticações falhas 1 2.300 0,04%

A leitura da tabela revela o motivo prático do conceito. Uma regra para criação de tarefa agendada lida com um comportamento presente em 80% do parque, e cada exceção legítima que ela não conhecer vira falso positivo em escala. Uma regra para handle de leitura em LSASS por processo incomum lida com um comportamento presente em 4 máquinas, e praticamente qualquer alerta dela merece olhar humano. A técnica é a mesma em termos de ATT&CK, o que muda é a prevalência, e é ela que define o desenho da detecção: comportamento frequente exige correlação e contexto, comportamento raro admite regra direta e barata.

Uma distinção evita confusões frequentes: prevalência é medida sobre o ambiente, e não sobre o adversário. Quão usada uma técnica é por grupos de ameaça é outra variável, derivada de inteligência, e as duas se cruzam na priorização. Também não se deve confundir prevalência de comportamento com prevalência de ferramenta: rundll32.exe é onipresente, mas rundll32.exe carregando DLL sem exportação válida de caminho de usuário pode ser raríssimo, e a segunda é a unidade que interessa à detecção.

3. Por que Prevalência Baixa Vale Ouro

Comportamento de prevalência baixa é matéria-prima de detecção de alto valor por três razões que se somam. Primeira, o potencial de falsos positivos é estruturalmente pequeno, porque quase ninguém no parque produz o comportamento por motivos legítimos, o que significa SNR alto com menos esforço de tuning. Segunda, o adversário não pode evitar facilmente o comportamento sem abandonar a técnica, então a detecção cobre variantes em vez de variantes específicas. Terceira, o custo de triagem é baixo, porque a fila raramente é acionada, e quando é, quase sempre vale a pena.

Na Pirâmide de Dor, esse argumento aparece em outro nível: ferramentas e comportamentos raros custam mais para o adversário trocar que hashes e domínios. A prevalência transfere essa lógica para o lado defensivo e dá um número para o trade-off. Técnicas de prevalência alta e uso adversário alto, como execução de script e criação de tarefa agendada, continuam valendo detecção, mas o desenho precisa incluir contexto e correlação, porque a regra direta nelas é uma fábrica de falsos positivos. Técnicas de prevalência baixa e uso adversário alto são os pontos doces da fila.

Perfil da técnica Exemplo Implicação de desenho
Prevalência baixa, uso adversário alto Handle de leitura em LSASS por processo incomum Regra direta, alerta com severidade alta
Prevalência alta, uso adversário alto PowerShell com linha de comando ofuscada Correlação com contexto, raridade e linhagem
Prevalência baixa, uso adversário baixo Comportamento específico de grupo APT distante Cobertura se houver exposição ou setor-alvo
Prevalência alta, uso adversário baixo Consultas administrativas rotineiras de inventário Analytics agendado e baseline, não alerta

Um cuidado temporal completa o argumento: prevalência é variável viva. A implantação de um novo agente de TI, uma ferramenta de DevOps adotada por uma squad ou uma atualização de pacote pode mover uma técnica de 0,5% para 15% de prevalência em uma semana, transformando uma regra silenciosa em fonte de ruído. Por isso a medição é recorrente e a mudança de prevalência é evento que dispara revisão da regra associada, preferencialmente pela mesma esteira que já versiona detecções.

A prevalência também fundamenta a conversa com donos de negócio quando uma detecção precisa de cooperação para reduzir ruído. Pedir a desativação de um script legítimo ou a troca de uma ferramenta administrativa é conversa dura sem número, e o valor de 31% de prevalência na frota de servidores transforma a negociação em decisão de risco documentada. Times que medem prevalência antes de pedir mudança a outros times negociam com dado, e não com reclamação de fila.

4. Como Estimar a Prevalência com Dados Próprios

A estimativa mais valiosa é a medida no próprio parque, porque reflete a combinação exata de software, rotina e telemetria local. O procedimento básico tem quatro passos: definir o evento característico da técnica com o máximo de fidelidade ao ATT&CK, escolher a janela de 30 a 90 dias cobrindo sazonalidade de negócio, contar entidades distintas que apresentaram o evento e dividir pelo inventário vigente de entidades monitoradas. O inventário é o insumo mais negligenciado, e sem ele a fração fica indefinida, por isso o primeiro passo prático costuma ser apenas garantir que o número de hosts monitorados é consultável.

let janela = 90d;
let hosts_monitorados = toscalar(
    Inventario
    | where timestamp > ago(1d)
    | summarize total = dcount(host));
Processo
| where timestamp > ago(janela)
| where process_name =~ "certutil.exe"
    and command_line has_any ("http://", "https://", "ftp://")
| summarize hosts_com_comportamento = dcount(host)
| extend prevalencia_pct = round(hosts_com_comportamento * 100.0 / hosts_monitorados, 3)

A consulta acima mede a prevalência do download remoto via certutil, evento característico de Ingress Tool Transfer, e exemplifica as duas decisões que toda medição exige. A primeira é a definição do evento característico, que deve ser ampla o bastante para incluir usos legítimos, porque prevalência subestimada leva a regra superestimada, e estreita o bastante para representar a técnica. A segunda é a base de comparação, aqui o inventário do dia, que precisa ser a mesma base usada nos relatórios de cobertura para que os números conversem.

O roteiro de coleta a seguir organiza o trabalho de medição no ambiente e evita os tropeços mais comuns da primeira rodada.

  • Confirmar o inventário de referência antes de qualquer contagem, com fonte, data e critério de inclusão de host documentados no próprio repositório.
  • Validar a telemetria do evento característico em um host de teste, porque contagem sobre evento mal coletado produz prevalência falsa com aparência de precisão.
  • Executar a consulta por função de host, sistema operacional ou região, porque a prevalência agregada esconde bolsões de comportamento que seriam alvos melhores de detecção.
  • Registrar a consulta junto do resultado, com autoria e data, transformando a medição em artefato reutilizável e auditável.
  • Agendar a reexecução mensal da mesma consulta, criando a série histórica que revela deriva.

Para técnicas cujo evento característico é um conjunto de condições, a prática recomendada é medir a prevalência em camadas, primeiro a prevalência do componente mais comum e depois a das combinações. Medir que 90% do parque roda PowerShell diz pouco, medir que 2,4% roda PowerShell com linha de comando contendo codificação em base64 diz muito mais, e a diferença entre as duas medições é exatamente o espaço que a detecção tem para trabalhar sem afogar a fila.

5. Dados Externos e Seus Vieses

Dados próprios não cobrem tudo, especialmente no planejamento de detecções para técnicas que o ambiente nunca produziu, e aí entram fontes externas de prevalência. Relatórios anuais de resposta gerenciada publicam rankings de técnicas observadas em dezenas de milhares de endpoints de clientes, plataformas de detecção agregam prevalência de comportamentos entre seus inquilinos e datasets públicos de telemetria de laboratório oferecem amostras para exercícios. Cada fonte tem viés próprio, e usá-las em conjunto mitiga, mas não elimina, a distância entre a realidade delas e a do seu parque.

Fonte Granularidade Custo Viés principal
Telemetria própria Alta, por técnica e por ativo Média, exige pipeline Espelho fiel, mas só do que já é coletado
Relatórios de MDR e vendors Média, rankings por técnica Baixa Viés de base de clientes, setor e frota
Datasets públicos de telemetria Média, por evento Baixa Ambiente de laboratório, pouco ruído real
Comunidades de detecção e regras Média, por regra publicada Baixa Viés de popularidade de ferramenta

O uso prudente segue uma regra simples: fontes externas definem o candidato, dados próprios decidem. Um relatório indicando que técnica X aparece em 8% dos incidentes da indústria cria hipótese de valor; a decisão de escrever a regra só sai depois de medir a prevalência local do comportamento característico. O inverso também vale, e técnica com uso adversário documentado e prevalência local nula costuma ser a melhor candidata da fila, porque o ambiente provavelmente nunca mediu o comportamento por falta de telemetria, o que é lacuna a tratar antes da regra.

Cada fonte externa pede um ajuste de viés conhecido antes de alimentar a fila.

  • Normalizar a base dos relatórios de resposta gerenciada para o setor da organização, porque técnica prevalente em varejo pode ser irrelevante em financeira.
  • Tratar datasets públicos como prova de conceito de consulta, e não como medida de frequência, dado o ambiente de laboratório onde foram gerados.
  • Registrar a fonte usada em cada estimativa externa, para que a priorização possa ser reconstruída quando o relatório seguinte mudar os números.

6. Uso na Priorização de Detecções e Caças

Com prevalência medida e uso adversário estimado pela inteligência, a fila de detecções ganha um escore objetivo. A fórmula a seguir é deliberadamente simples e serve para ordenar, não para decidir sozinha: uso adversário e criticidade empurram a técnica para cima, prevalência empurra para baixo, e o produto final cria a ordem de ataque da sprint de engenharia. O mesmo escore ordena hipóteses de caça no controle TH.5 do capítulo 15, garantindo que caça e detecção disputem as mesmas prioridades com a mesma régua.

escore = (uso_adversario * criticidade_ativo) / prevalencia_ponderada
uso_adversario      = 1 a 5, conforme relatos e perfis de ameaça relevantes
criticidade_ativo   = 1 a 5, conforme valor do ativo mais exposto à técnica
prevalencia_ponderada = prevalencia_pct + 1, evitando divisão por zero
Técnica candidata Uso adversário Criticidade Prevalência Escore Decisão
LSASS Memory via processo incomum 5 5 0,17 147 Regra direta nesta sprint
DLL Side-Loading em software de nicho 4 5 0,9 27,8 Caça antes da regra
PowerShell ofuscado 5 3 2,4 6,3 Correlação com contexto
Criação de tarefa agendada 4 2 80,0 0,13 Analytics agendado

O escore também serve como linguagem de defesa do backlog contra pedidos externos. Quando uma regra chega por pressão de fornecedor, de auditoria ou de noticiário, a pergunta certa não é se a técnica é boa, e sim qual escore ela obtém contra as técnicas já na fila, e a resposta numérica encerra a discussão com respeito. A fila de engenharia é um orçamento, e o escore é a moeda.

A tabela mostra o efeito prático do escore: técnicas raras no ambiente e caras para o adversário trocar sobem naturalmente, e técnicas banais não somem da lista, apenas mudam de modalidade, de alerta para analytics ou baseline. Vale registrar a exceção de julgamento humano: técnica com escore baixo, mas com relato recente de exploração ativa no setor, pode subir na fila por decisão de inteligência, e o escore existe para fundamentar a discussão, não para substituí-la.

7. Matriz Prevalência x Criticidade

A matriz de decisão cruza prevalência com criticidade dos ativos envolvidos e entrega quatro quadrantes com condutas distintas, funcionando como política visual para a fila. O eixo de prevalência separa comportamento raro de comportamento comum, e o eixo de criticidade separa ativos que importam de ativos de apoio. A matriz também é a forma mais rápida de explicar a diretores por que duas técnicas do mesmo ATT&CK podem ter investimentos completamente diferentes.

Quadrante Conduta de detecção Exemplo típico
Prevalência baixa, criticidade alta Regra direta imediata, severidade alta, teste obrigatório Dump de credenciais em controlador de domínio
Prevalência baixa, criticidade baixa Regra simples ou observação silenciosa, sem fila dedicada Comportamento raro em frota de apoio
Prevalência alta, criticidade alta Correlação, raridade e linhagem, alerta composto Script de execução em servidores críticos
Prevalência alta, criticidade baixa Baseline, analytics agendado e revisão periódica Ferramentas administrativas rotineiras

A matriz resolve também a disputa clássica entre times sobre o que é prioridade, porque desloca a discussão de opinião para quadrante. Uma regra do quadrante raro e crítico entregue na sprint vale mais para o programa que cinco regras do quadrante comum e de apoio, e essa comparação fica visível quando as decisões são registradas com o quadrante anotado, permitindo auditar ao fim do trimestre se o esforço foi gasto onde a matriz mandava.

Quatro regras de uso mantêm a matriz honesta ao longo do tempo.

  • Classificar toda nova proposta de detecção no quadrante antes de aceitá-la na fila, sem exceção, porque a exceção destrói a política.
  • Revisar o quadrante das detecções existentes quando a prevalência medida muda de faixa, migrando o formato da detecção junto.
  • Registrar nas ADS os dois eixos da matriz no momento da criação, para que a classificação sobreviva aos autores.
  • Recusar quadrantes por escrito quando o ambiente não tem telemetria, em vez de simplesmente deixar o quadrante vazio.

8. Erros Comuns e Pontos de Atenção

  • Medir prevalência com janela curta demais, capturando picos de rotina, como inventário mensal, e confundindo sazonalidade com frequência real.
  • Usar como denominador o número de hosts que enviam um log específico, e não o inventário total, inflando a prevalência sempre que a cobertura de coleta é ruim.
  • Medir prevalência de ferramenta em vez de comportamento, mantendo rundll32 no lugar do padrão específico de carga que interessa à detecção.
  • Aplicar prevalência de relatório externo sem ajuste local, herdando a mistura de frota e setor de outra base de clientes.
  • Tratar prevalência baixa como imunidade a tuning, esquecendo que um único processo legítimo raro pode responder por todos os falsos positivos da regra.
  • Ignorar a deriva de prevalência depois de mudanças no parque, deixando regras silenciosas virarem geradoras de ruído sem que ninguém conecte as duas coisas.
  • Comparar prevalências medidas com denominadores diferentes, um mês com frota de 2.100 hosts e outro com 2.400, sem ajuste da base.

O ponto de atenção central é documentar a definição do evento característico junto com o número de prevalência. Um valor de 0,9% sem a consulta anexada é intransferível, e a próxima pessoa que medir com outra definição vai discordar sem que haja erro de fato. A prevalência vira ativo institucional quando a medição é versionada no repositório de detecções, junto da regra que ela justifica.

9. Integração com o Restante da Biblioteca

Na pasta, a prevalência completa o SNR, explicando por que regras de comportamento raro são naturalmente limpas, e alimenta a cobertura por tática, ajudando a decidir quais técnicas merecem o esforço de teste e emulação. No capítulo 15, o escore da seção 6 é exatamente o tipo de critério objetivo que o controle TH.5 pede para priorizar hipóteses, e a matriz de quadrantes dialoga com os heatmaps do grupo MAP, que mostram onde a cobertura existe e a prevalência mostra onde ela vale mais.

Com os capítulos anteriores, a nota concretiza a Pirâmide de Dor em métrica de engenharia e conecta os PIRs do capítulo 1 à fila de detecção, fechando o caminho que vai do requisito de inteligência à regra no repositório. Com o capítulo 19, a conexão é operacional: o ciclo purple mensal escolhe suas técnicas de emulação priorizando comportamentos de prevalência baixa e uso adversário alto, garantindo que o esforço de validação recaia sobre as detecções de maior valor do catálogo.

Uma nota de sequenciamento encerra a aplicação da ferramenta. O time que começa agora deve medir a prevalência das técnicas já cobertas pelo catálogo antes de medir as candidatas, porque a primeira série histórica revela de imediato quais regras existentes estão operando em quadrantes errados, e essas migrações costumam ser mais baratas que qualquer regra nova. O número de prevalência, usado primeiro como espelho e depois como bússola, paga o esforço de medição já no primeiro mês.