Triagem de alertas é o processo que decide, em minutos, quais dos milhares de eventos gerados por EDR, SIEM, firewall e ferramentas de identidade viram investigação e quais são arquivados ou descartados. Uma metodologia explícita de triagem transforma o SOC de fila reativa em pipeline com critérios verificáveis: cada alerta recebe enriquecimento, priorização por impacto e contexto de ativo antes de consumir tempo de analista. A edição de abril de 2025 do guia de resposta a incidentes do NIST integra a triagem e o tratamento de incidentes à gestão de risco cibernético, e é essa moldura de risco — não o volume de ferramentas — que sustenta decisão consistente em plantão. Este artigo define o pipeline, os critérios de priorização e um procedimento operacional que equipes técnicas podem aplicar já no próximo turno.
O que é triagem de alertas
Triagem é a etapa entre detecção e investigação profunda. O triador recebe o alerta, valida se os dados básicos são coerentes, enriquece com contexto (identidade, ativo, reputação de indicadores, linhas de base), classifica severidade e decide: escalar para investigação de incidente, fechar como falso positivo com documentação ou sinalizar regra defeituosa. O objetivo não é investigar tudo — é garantir que o alerta certo chegue ao analista certo com o contexto mínimo para decidir rápido. A revisão vigente do guia do NIST substitui a edição de 2012 do documento, e a diferença prática é significativa: o foco saiu do ciclo isolado de resposta e passou a tratar incidente como consequência de decisões de gestão de risco. Sem triagem formal, SOCs acumulam backlog, analistas ignoram filas inteiras e ataques reais morrem em alertas nunca abertos — padrão recorrente em análises pós-incidente.
O pipeline de triagem
Um pipeline maduro tem quatro estações sequenciais. Primeira: coleta e normalização, em que alertas de fontes distintas convertem para um esquema comum com campos obrigatórios como origem, ativo, identidade, indicadores de comprometimento e timestamp. Segunda: enriquecimento automático, com consulta a threat intelligence, inventário de ativos, grupo de risco e histórico do usuário. Terceira: priorização, com pontuação que combina severidade técnica, criticidade do ativo e confiança histórica na detecção. Quarta: decisão humana documentada, que escala, fecha ou registra defeito de regra. Cada estação gera telemetria própria — taxa de falso positivo por regra, tempo médio de decisão, taxa de escalonamento — que alimenta a melhoria contínua das detecções. Equipes que ignoram a quarta estação viram fábrica de fechamento de tickets; equipes que ignoram a primeira afogam o analista em formatos incompatíveis e perdem a linha do tempo na reconstrução forense.
Critérios de priorização
Priorização saudável equilibra três eixos: o que a detecção afirma (severidade técnica), o que está em jogo (criticidade do ativo e dos dados) e o quanto se confia no alerta (precisão histórica da regra). Execução suspeita em controlador de domínio vale mais que phishing bloqueado em estação sem privilégio. Para o eixo de vulnerabilidades, a referência objetiva é o catálogo KEV da CISA: O catálogo KEV da CISA é a fonte autoritativa de vulnerabilidades exploradas no mundo real, e a inclusão exige identificador CVE atribuído, evidência confiável de exploração ativa e ação de remediação clara. Na prática do triador, alerta que referencia CVE presente no KEV sobe de fila independentemente da nota CVSS, porque exploração confirmada vale mais que score teórico. A CISA recomenda formalmente que toda organização inclua o tratamento imediato das vulnerabilidades do KEV no plano de gestão de vulnerabilidades, o que converte o catálogo em insumo direto de priorização. Detecção de técnicas de movimentação lateral, como o pass-the-hash dentro do SOC, também pesa alto na fila, pois indica pós-comprometimento ativo e não tentativa isolada.
Enriquecimento e contexto
Enriquecimento é o que separa triagem metodológica de filtro burro. Os campos que mais mudam a decisão: criticidade do ativo no CMDB, privilégio da identidade envolvida, presença do indicador em listas confiáveis, janela temporal e histórico recente do mesmo host. Alertas sobre ativos de missão crítica com identidade privilegiada escalam em minutos; o mesmo alerta em máquina de laboratório pode aguardar o fim da fila. Contexto também previne o erro oposto, descartar como benigno um evento que é o terceiro elo de uma cadeia. Um bypass de MFA isolado parece ruído; em sequência com registro de novo dispositivo e acesso a repositório sensível, é preparação de ransomware — o caso do grupo Gunra, com bypass de MFA documentado em análise dedicada, mostra como cada etapa só faz sentido quando lida em cadeia.
Procedimento em etapas
Modelo de referência adaptável ao runbook local, executável por um triador em turno:
- Receber o alerta e validar completude: origem, ativo, identidade e timestamp presentes; sem isso, devolver à fonte.
- Rodar enriquecimento automático: criticidade do ativo, privilégio da identidade, reputação dos indicadores e ocorrências anteriores do mesmo host.
- Classificar severidade pela matriz local, cruzando severidade técnica com criticidade do ativo.
- Comparar CVEs citadas com o KEV e com inteligência interna; exploração confirmada eleva a prioridade.
- Decidir e documentar: escalar, fechar como falso positivo com justificativa ou abrir ticket de ajuste de regra.
- Escalonar com pacote de contexto: alerta original, enriquecimento, hipótese inicial e ações já verificadas.
- Revisar semanalmente as métricas de fila para aposentar regras barulhentas e promover detecções subnotificadas.
Matriz de referência
Exemplo de matriz para calibrar a estação de priorização — os tempos são objetivos internos de decisão, não padrão externo:
| Severidade | Gatilho típico | Ação esperada | Objetivo de decisão |
|---|---|---|---|
| Crítica | Execução em ativo de missão crítica ou CVE listada no KEV | Escalar para investigação imediata e acionar responsável | 15 minutos |
| Alta | Credential dumping ou anomalia de identidade privilegiada | Fila prioritária de investigação | 1 hora |
| Média | Phishing reportado sem clique confirmado | Fila normal com verificação de caixa | 4 horas |
| Baixa | Malware bloqueado no download, sem pós-execução | Fechar com registro e monitorar o host | 24 horas |
Erros comuns na triagem
Cinco armadilhas concentram a maior parte das falhas. Fechar por volume: quando a fila passa de milhares, a tentação de fechamento em massa destrói a função do processo. Confundir ausência de evidência com ausência de ataque: telemetria incompleta não é prova de benignidade. Não documentar falso positivo: sem registro, a mesma regra ruim gera o mesmo alerta na semana seguinte. Priorizar só por CVSS: score teórico ignora exploração ativa e criticidade do contexto. Deixar regra barulhenta viva: cada falso positivo recorrente é débito direto no orçamento de atenção do time. Triagem é disciplina de decisão com registro, e o registro é o que permite auditar, treinar e melhorar.
