Triagem de alertas no SOC: metodologia em cinco etapas

Triagem de alertas no SOC é o processo de qualificar cada evento gerado pelas ferramentas de segurança, decidir se ele representa uma ameaça real e definir a ordem de tratamento com base em severidade, criticidade do ativo e impacto potencial para o negócio. A referência normativa vigente é o NIST SP 800-61 Rev. 3, que transformou o guia de resposta a incidentes em um perfil da comunidade do CSF 2.0 e conecta detecção, resposta e recuperação ao gerenciamento de risco da organização. Uma triagem madura reduz o tempo entre detecção e contenção, protege o backlog dos analistas e evita que incidentes reais morram afogados em ruído.

Neste guia você encontra uma metodologia em cinco etapas, um modelo de priorização por severidade e um checklist pronto para adaptar ao runbook do seu time. Os passos seguem a lógica de correlação e qualificação descrita no CSIRT Services Framework do FIRST e aplicável a plataformas como Splunk, Microsoft Sentinel, Elastic e Wazuh.

O que é triagem de alertas

Triagem é o filtro de entrada do SOC. Todo alerta que chega à fila passa por uma decisão rápida e documentada: descartar como falso positivo, mesclar com outros eventos correlacionados ou escalar como incidente confirmado. O trabalho não é investigar a fundo cada sinal — isso cabe à investigação de incidentes — e sim classificar rápido o que merece essa investigação.

O CSIRT Services Framework do FIRST formaliza essa atividade ao definir um documento estruturado que descreve serviços e funções de segurança para equipes de resposta a incidentes, servindo de base para montar o catálogo de serviços do time. Para um SOC, isso significa que a triagem deixa de ser um hábito interno e passa a ter papéis, entradas e saídas definidos.

No campo normativo, vale registrar a transição recente: a revisão anterior do guia, o SP 800-61 Rev. 2, foi formalmente retirada em 3 de abril de 2025 e substituída pela Rev. 3, o que obriga equipes que citam a norma em políticas, propostas e auditorias a atualizar as referências internas.

Metodologia em cinco etapas

Uma metodologia explícita transforma a triagem de decisão intuitiva em processo auditável. A sequência abaixo cabe em runbook e pode ser medida com métricas de tempo médio de triagem e taxa de falsos positivos por regra.

1. Validação do alerta. Confirme se o evento contém os campos mínimos: timestamp em UTC, ativo afetado, identidade envolvida, regra de detecção que disparou e severidade sugerida pela ferramenta. Alerta sem ativo identificável volta para o engenheiro de detecção, não para a fila de triagem.
2. Correlação com outros sinais. Busque eventos relacionados na mesma janela de tempo: autenticações anômalas, execuções de processo, tráfego de saída incomum e mudanças de grupo. No modelo do FIRST, a correlação e a qualificação são funções formais do serviço de análise de eventos, não etapas informais deixadas ao critério do analista de plantão.
3. Enriquecimento contextual. Consulte a criticidade do ativo no CMDB, o dono do sistema, a presença dos indicadores em threat intelligence e o histórico de alertas anteriores do mesmo host ou usuário. Contexto vale mais que volume de dados brutos.
4. Classificação da severidade. Aplique a matriz de prioridade combinando impacto técnico e valor do ativo. Registre a justificativa da nota: ela alimenta o tuning futuro das regras e a revisão dos casos de uso de detecção.
5. Decisão e encaminhamento. Feche como falso positivo com motivo documentado, crie o incidente com severidade atribuída ou escale para o time de resposta. Toda decisão fica rastreável no ticket, do primeiro toque ao encerramento.

Priorização por severidade e contexto

Severidade não depende apenas da técnica observada: o mesmo PowerShell suspeito tem pesos diferentes num domain controller e numa estação de quiosque. Combine impacto e criticidade do ativo antes de escalar, e trate prazos como parte do contrato interno do SOC.

Os prazos acima são ponto de partida: calibre com o apetite a risco e os requisitos contratuais ou regulatórios da organização. O que não pode variar é a existência de um prazo definido — fila sem SLA é fila infinita, e o backlog escondido vira incidente na pior hora possível.

Falsos positivos e enriquecimento

A maior parte das filas de SOC é ruído, e o tratamento dele é trabalho contínuo, não campanha única. Cada falso positivo fechado deve gerar um caso de teste: se a mesma regra disparar de novo pelo mesmo motivo, ela precisa de tuning, exceção documentada ou desativação.

Enriquecimento acelera a decisão: integrar o EDR com o catálogo de ativos, o IAM com o padrão de comportamento da identidade e a inteligência de ameaças com indicadores atualizados reduz o trabalho manual em cada ticket. Detecções compostas — que cruzam sinal de endpoint, rede e identidade — tendem a sobreviver melhor ao tuning do que regras de evento único, como mostram casos reais de detecção de pass-the-hash em movimento lateral e de bypass de MFA pelo ransomware Gunra detectado no SOC.

Checklist de triagem no SOC

• Alerta possui ativo, identidade, timestamp e regra de detecção identificáveis
• Correlação executada na janela de trinta minutos em torno do evento
• Criticidade do ativo confirmada no CMDB antes de atribuir severidade
• Indicadores verificados em inteligência de ameaças interna e pública
• Severidade atribuída com justificativa registrada no ticket
• Falso positivo fechado com motivo padronizado para alimentar o tuning
• Escalonamento segue a matriz de prioridade e o contato de plantão definido

Fontes

• NIST — SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST CSRC — página oficial do SP 800-61 Rev. 2 com registro de retirada
• FIRST — CSIRT Services Framework