Triagem e Classificação de Incidentes de Segurança

Triagem de incidentes é o processo pelo qual um SOC determina, de forma rápida e sistemática, se um alerta representa uma ameaça real, qual é a sua gravidade e qual tratamento deve receber — tudo isso antes que o dano se materialize. É a linha entre um incidente contido em minutos e uma crise que dura dias.

Evento, alerta e incidente: filtrando o ruído

Um ambiente corporativo de médio porte gera dezenas de milhões de eventos de log por dia. A maior parte desses registros é operacional e irrelevante para a segurança. O primeiro trabalho do analista de SOC é distinguir três categorias conceituais que o NIST SP 800-61 Rev. 2 define com precisão:

• Evento: qualquer ocorrência observável em um sistema ou rede — um login bem-sucedido, uma consulta DNS, uma transferência de arquivo. Eventos são neutros por natureza.
• Alerta: evento ou conjunto de eventos que ativou uma regra de detecção e foi encaminhado ao analista para avaliação. Todo incidente começa com um ou mais alertas, mas a maioria dos alertas não vira incidente.
• Incidente: alerta confirmado como atividade adversária ou violação de política com impacto real ou iminente sobre confidencialidade, integridade ou disponibilidade de ativos da organização.

O processo de triagem percorre exatamente esse caminho: recebe alertas, avalia contexto, descarta falsos positivos e eleva a incidente apenas o que apresenta evidência suficiente de ameaça genuína. Sem essa filtragem disciplinada, o SOC afoga em volume e perde os sinais que importam.

Classificação por severidade: a matriz impacto × urgência

Classificar um incidente é atribuir a ele coordenadas em duas dimensões: impacto (quão grave é o dano potencial) e urgência (quão rápido esse dano pode se materializar ou se propagar). A severidade resultante determina o SLA de resposta e os recursos alocados.

O impacto é avaliado pelos ativos envolvidos (criticidade do sistema, classificação dos dados, número de usuários afetados), pelos regulamentos incidentes (LGPD, PCI DSS, regulações setoriais) e pela exposição financeira ou reputacional. A urgência é avaliada pela capacidade de propagação lateral, pela janela de contenção disponível e pela atividade ativa do atacante.

Os SLAs acima são de referência. Cada organização deve calibrá-los com base em seu apetite a risco, obrigações contratuais e capacidade operacional do SOC. O que não é negociável é que eles existam, sejam formalizados e medidos em todas as ocorrências.

Categorização por tipo de incidente

Além da severidade, todo incidente recebe uma categoria que determina qual playbook será ativado. O SANS Institute e o NIST convergem nas seguintes categorias primárias:

• Malware e ransomware: código malicioso executando em ativos da organização, seja para espionagem, destruição ou extorsão. Prioridade máxima de contenção e isolamento de rede.
• Phishing e BEC (Business Email Compromise): engenharia social para coleta de credenciais ou indução a transferências financeiras fraudulentas. Exige bloqueio imediato de sessão e revisão de regras de e-mail.
• Acesso não autorizado: uso de credenciais legítimas roubadas ou exploração de vulnerabilidade para acessar sistemas sem permissão. Investigação de movimento lateral é obrigatória.
• Negação de serviço (DoS/DDoS): ataque volumétrico ou de protocolo com objetivo de interromper a disponibilidade de serviços. Coordenação imediata com provedor de conectividade e CDN.
• Vazamento de dados: exfiltração intencional ou exposição acidental de informações sensíveis. Ativa obrigações de notificação regulatória nos prazos da LGPD e setoriais.
• Ameaça interna: abuso de acesso privilegiado por colaborador, terceiro ou ex-funcionário. Exige protocolos especiais de evidência para preservar rastreabilidade jurídica.

Critérios de escalonamento L1, L2 e L3

A estrutura de níveis do SOC existe para garantir que o grau de especialização aplicado ao incidente seja proporcional à sua complexidade, sem sobrecarregar especialistas com triagem de baixo valor nem deixar incidentes complexos nas mãos de analistas sem ferramentas adequadas.

L1 — Triagem e primeira resposta: analistas L1 recebem todos os alertas, executam a triagem inicial, descartam falsos positivos com procedimentos documentados, classificam os incidentes confirmados e executam playbooks de contenção para severidades Baixa e Média. São responsáveis por registrar toda a evidência coletada no ticket antes de qualquer escalonamento.

L2 — Investigação aprofundada: recebem incidentes de severidade Alta ou qualquer incidente que L1 não conseguiu conter com playbook padrão. Executam análise de causa raiz, correlacionam eventos para identificar extensão do comprometimento, analisam logs de SIEM, tráfego de rede e artefatos de endpoint. Decidem sobre contenção ampliada (isolamento de segmento de rede, reset de credenciais em massa).

L3 — Forense e resposta a incidentes avançada: acionados para incidentes Críticos, ataques persistentes avançados (APT), comprometimento de dados regulados ou qualquer situação com potencial de impacto jurídico ou financeiro significativo. Conduzem análise forense digital, reverse engineering de malware, threat hunting e suportam procedimentos legais quando necessário.

O escalonamento é uma decisão técnica, não hierárquica. O critério é a complexidade e o impacto do incidente, não a disponibilidade de analistas. Escalar tarde compromete o SLA. Escalar cedo sem critério sobrecarrega L2 e L3 desnecessariamente.

Redução de falsos positivos

Falso positivo não é só uma inconveniência operacional — é um custo real. Cada falso positivo consome tempo de analista que poderia estar investigando um incidente verdadeiro. Organizações com alta taxa de falsos positivos desenvolvem alert fatigue, o estado em que analistas param de investigar alertas com atenção porque o volume de ruído superou o sinal. Pesquisas do setor apontam que SOCs recebem entre 1.000 e 10.000 alertas por dia, com taxas de falso positivo superiores a 50 % em muitas organizações.

As principais alavancas para reduzir falsos positivos são: ajuste fino das regras de detecção com whitelist de comportamentos legítimos conhecidos, enriquecimento automático de alertas com contexto (threat intelligence, inventário de ativos, histórico do usuário) antes de chegarem ao analista, correlação de eventos no SIEM para elevar o limiar de disparo de alertas simples, e revisão contínua baseada em métricas — taxa de falso positivo por regra, por analista e por categoria.

O papel do SOAR na triagem automatizada

SOAR (Security Orchestration, Automation and Response) é a camada tecnológica que automatiza as etapas repetíveis da triagem. Quando um alerta de phishing chega ao SIEM, o playbook do SOAR pode, em segundos e sem intervenção humana: extrair URLs e hashes dos e-mails, consultá-los em fontes de threat intelligence, verificar se outros usuários receberam o mesmo e-mail, checar se algum usuário clicou no link, bloquear o domínio malicioso no gateway de e-mail e no proxy web, e abrir um ticket L2 se houver evidência de clique — tudo documentado com timestamps e evidências para auditoria.

O analista recebe um ticket já enriquecido, com as ações automáticas registradas, e foca na decisão que requer julgamento humano: há comprometimento de credencial? É necessário resetar a senha? O incidente faz parte de uma campanha maior? O SOAR reduz o MTTR (Mean Time to Respond) de horas para minutos nos tipos de incidente mais comuns e libera capacidade analítica para os casos genuinamente complexos.

Referências normativas

O processo de triagem e classificação descrito neste artigo se alinha às seguintes referências reconhecidas internacionalmente:

• NIST SP 800-61 Rev. 2 — Computer Security Incident Handling Guide: define o ciclo de vida de resposta a incidentes (preparação, detecção e análise, contenção, erradicação e recuperação, atividade pós-incidente) e estabelece os fundamentos de classificação e severidade.
• SANS Institute Incident Handler's Handbook: metodologia de seis fases (preparação, identificação, contenção, erradicação, recuperação, lições aprendidas) com guias práticos de triagem e escalonamento.
• ISO/IEC 27035: norma internacional para gestão de incidentes de segurança da informação, com ênfase em estrutura organizacional, papéis e integração com o SGSI.

Perguntas frequentes

A Decripte e a triagem de incidentes 24x7

A Decripte opera um SOC contínuo com triagem, classificação e resposta a incidentes para empresas de 1 a mais de 100.000 colaboradores no Brasil. A triagem segue a metodologia descrita neste artigo: classificação por severidade com SLAs contratuais, escalonamento L1–L3 documentado e playbooks por categoria de incidente. A plataforma DMS registra cada decisão de triagem com trilha de auditoria completa, do alerta original à resolução, garantindo rastreabilidade para conformidade com a LGPD e normas setoriais.

Organizações que desejam estruturar ou fortalecer seu processo de triagem podem começar gratuitamente com o Plano de Ameaças ou conhecer os planos de resposta a incidentes da Decripte.