A triagem de alertas no SOC é a disciplina que separa o time de operações de segurança do caos: sem um método definido, cada analista decide por intuição, o backlog cresce e incidentes reais apodrecem na fila. O ponto de partida conceitual vem do guia de resposta a incidentes do NIST, para o qual um evento é qualquer ocorrência observável em um sistema ou rede, e apenas a análise de contexto separa o ruído cotidiano do incidente real. Este artigo apresenta uma metodologia prática de triagem em seis etapas, com critérios de priorização, tabela de decisão e checklist de encerramento, aplicável tanto a SOCs internos quanto a operações de segurança gerenciada.
O que é triagem de alertas
Triagem (triage) é o ato de receber cada alerta disparado por SIEM, EDR, firewall ou ferramenta cloud e decidir, em minutos, três coisas: se é falso positivo, se precisa de investigação imediata e quem é o dono da próxima ação. A triagem não é investigação profunda — é classificação rápida com contexto mínimo suficiente. Um SOC maduro mede triagem por tempo médio de reconhecimento (MTTA) e taxa de falsos positivos por regra, não por volume bruto de alertas fechados. Quando o volume supera a capacidade, a resposta errada é abrir mais abas; a resposta certa é atacar a qualidade das regras e o enriquecimento automático. Vale lembrar que técnicas como o pass-the-hash no movimento lateral raramente aparecem como um único alerta óbvio: elas surgem como uma sequência de eventos que só a triagem estruturada consegue ligar.
Criticidade de ativo e contexto
A mesma detecção tem pesos diferentes conforme o alvo. Um acesso anômalo a uma estação de laboratório e o mesmo padrão contra o controlador de domínio não podem compartilhar fila nem prazo. Para o guia do NIST, a priorização de incidentes deve considerar fatores explícitos de impacto funcional, impacto informacional e recuperabilidade do afetado — ou seja, o que a operação perde, quais dados estão em jogo e o quão rápido o dano pode ser revertido. Na prática, isso vira uma matriz simples na ferramenta de ticketing: ativo com classificação de criticidade herdada do CMDB, mapeamento da técnica ao MITRE ATT&CK, que é uma base de conhecimento global de táticas e técnicas de adversários construída a partir de observações reais, e histórico recente do mesmo comportamento no ambiente. Sem essas três camadas de contexto, severidade virou sinônimo de cor do alerta — e cor não é prioridade. Cenários como o bypass de MFA pelo ransomware Gunra mostram o custo de ignorar contexto: o alerta individual parece benigno até ser lido junto com a cadeia de ataque completa.
| Dimensão | Pergunta da triagem | Ação padrão |
|---|---|---|
| Criticidade do ativo | O alvo é de missão crítica ou contém dados sensíveis? | Escalar para analista nível imediatamente superior |
| Confiança da detecção | A regra tem histórico alto de falso positivo? | Enriquecer antes de decidir; revisar regra depois |
| Estágio da cadeia | O comportamento indica acesso inicial, execução ou movimento lateral? | Priorizar fases tardias; abrir caça a eventos correlatos |
| Abrangência | Affeta um host ou um conjunto deles? | Verificar telemetria de vizinhos e contas relacionadas |
| Recuperabilidade | Existe backup/rollback testado para o ativo? | Confirmar antes de contenção destrutiva |
Enriquecimento antes de escalar
Enriquecimento é a coleta automática de contexto que evita o analista gastar os primeiros cinco minutos em buscas manuais. O mínimo operacional: reputação do IP e domínio externo, idade da conta envolvida, dono do ativo no inventário, presença do hash em bases de amostras e existência de advisory público relacionado. Para vulnerabilidades e avisos de fabricantes, o consumo estruturado importa: o padrão aberto CSAF, mantido pela OASIS, funciona como referência definitiva para a criação e o intercâmbio interoperável de avisos de segurança estruturados, permitindo que feeds de fabricante entrem direto na esteira de triagem em vez de virar e-mail solto. Enriquecimento não substitui julgamento: ele reduz o tempo até a decisão correta e padroniza a informação disponível para quem pega o caso depois.
Fluxo de triagem em etapas
- Recebimento: alerta entra na fila única com ID, regra disparadora e timestamp normalizado em UTC.
- Classificação inicial: atribuir severidade combinando criticidade do ativo, confiança da detecção e estágio da cadeia; documentar a justificativa em uma linha.
- Enriquecimento automático: rodar playbooks de contexto (reputação, inventário, histórico) antes da decisão humana.
- Decisão: fechar como falso positivo com motivo, transformar em incidente ou devolver para tuning de regra — nunca fechar sem classificação do motivo.
- Escalar quando necessário: incidente confirmado vai para resposta com pacote de evidências, escopo preliminar e técnica mapeada em ATT&CK.
- Feedback: falsos positivos recorrentes alimentam revisão de regra na mesma semana; a fila de tuning é tão importante quanto a fila de alertas.
Cada etapa precisa de dono e prazo. Sem prazo para a etapa de decisão, o MTTA degrada silenciosamente e o backlog vira métrica escondida do relatório.
Erros comuns na triagem
Três falhas dominam pós-mortens de SOC. Primeira, alert fatigue tratado com fila infinita em vez de tuning: o time desiste de ler tudo e começa a fechar em massa, o que é pior do que não ter regra. Segunda, severidade copiada do fabricante sem ajuste de contexto local: a ferramenta não conhece o seu ambiente, e criticidade é decisão do SOC. Terceira, ausência de registro do motivo de fechamento: sem essa dado, nenhuma melhoria de regra é possível e o mesmo falso positivo volta amanhã. Nenhum desses erros se resolve contratando mais pessoas; resolve-se com metodologia, automação de contexto e disciplina de registro — exatamente o que as seis etapas acima formalizam.
