Cibersegurança e segurança da informação

Triage em SOC: Como priorizar alertas sem perder um incidente real

6 min de leituraPublicado: 5 de agosto de 2026

Representação visual profissional sobre Triage em SOC no campo de SOC e operações

Resposta rápida

Triage em SOC é a triagem e avaliação inicial de um alerta para determinar o que é urgente, o que requer investigação profunda e o que pode ser fechado. A decisão não se baseia apenas na Severidade que o sistema apresentou, mas numa combinação da criticidade do ativo, sensibilidade do utilizador, confiabilidade do sinal, técnica identificada, extensão da atividade e impacto potencial.

Num turno SOC, o analista não tem a possibilidade de investigar todos os alertas com a mesma profundidade e na mesma ordem. A fila de alertas continua a encher, alguns sinais repetem-se, e um incidente real pode esconder-se entre dezenas de alertas com gravidade semelhante. O objetivo do Triage é decidir rapidamente onde investir a atenção – sem transformar a velocidade num atalho perigoso.

Triage não é uma investigação completa. É uma fase curta que produz um panorama inicial: o que aconteceu, quem ou o que é afetado, quão fiáveis são os dados, existe um perigo imediato e qual é o próximo passo. O Microsoft Sentinel, por exemplo, centraliza alertas, entidades, gravidade, status e mapeamento ATT&CK num incidente, mas a responsabilidade de avaliar o contexto permanece com o analista.

O método neste artigo baseia-se em cinco fatores: ativo, identidade, comportamento, confiabilidade e impacto. É adequado para vários produtos SIEM e pode ser transformado numa tabela de decisão ou em tarefas de incidente fixas. O uso consistente do método também facilita a passagem de turno e a auditoria retrospetiva.

Objetivo do Triage e o seu limite

No final do Triage, deve haver um dos quatro resultados: fecho justificado, encaminhamento para investigação adicional, escalada imediata, ou uma ação temporária de preservação/contenção de acordo com o procedimento. Se o analista ficar com uma longa lista de perguntas sem uma decisão sobre o próximo passo, o Triage não foi concluído.

Para manter um limite claro, define-se um Timebox – um período de tempo fixo para a verificação inicial, por exemplo, 10 ou 15 minutos, dependendo do tipo de alerta e do SLA. O tempo não é uma ordem de fecho; quando surge um sinal de alto risco, o Triage é interrompido e passa-se para a via de investigação ou escalada.

O erro comum é entrar imediatamente nos detalhes de um ficheiro, endereço IP ou linha de comando, sem entender o ativo e qual é o risco de negócio. O Triage começa com o contexto mais amplo e só depois desce aos detalhes.

Para manter a consistência entre turnos, recomenda-se a calibração periódica: vários analistas classificam independentemente os mesmos cenários, comparam decisões e atualizam a tabela de priorização. As lacunas reveladas num exercício como este indicam quais critérios não são claros e onde é necessário um Playbook mais preciso.

Os cinco fatores de priorização

1. Criticidade do ativo: Domain Controller, servidor de produção, sistema financeiro e estação de trabalho de gestor sénior terão prioridade sobre uma estação de trabalho de laboratório, mesmo que o alerta seja idêntico. 2. Sensibilidade da identidade: Conta de administrador, conta de serviço, conta com acesso à nuvem ou utilizador com permissões excecionais aumentam o risco.

3. Comportamento e técnica: Uma ação que indica Credential Access, Lateral Movement ou Impacto geralmente requer maior atenção do que um evento Discovery isolado, mas o contexto deve ser examinado. 4. Confiabilidade do sinal: Correspondência com várias fontes independentes, dados EDR completos ou um IOC com contexto de alta qualidade reforçam a confiança. 5. Impacto e extensão: Quantos utilizadores/estações estão envolvidos, a atividade continua, e existe a possibilidade de dano imediato.

Os fatores podem ser traduzidos num score interno, mas o score não deve tornar-se uma verdade automática. É uma ferramenta de consistência que ajuda a explicar porque um alerta recebeu prioridade sobre outro.

Perguntas que devem ser feitas nos primeiros minutos

Qual foi a regra e o que exatamente a ativou? O alerta é novo ou faz parte de um incidente existente? Quem é o utilizador e qual é a sua função? Qual é o ativo e qual o seu nível de criticidade? A ação foi bem-sucedida ou apenas tentada? Existem alertas relacionados no mesmo utilizador, Host, IP ou janela de tempo? A atividade ainda está a ocorrer?

Verifique também sinais que podem transformar um alerta médio em urgente: conta Privileged, múltiplas estações, desativação de mecanismo de segurança, execução de código num servidor, criação de novo utilizador, ligação a um destino suspeito ou suspeita de fuga de dados. Por outro lado, Change Window, um scanner autorizado ou um sistema de gestão conhecido podem explicar a atividade – mas é necessária prova, não uma suposição.

Documente as respostas em campos fixos. O Microsoft Sentinel permite adicionar Incident Tasks manual ou automaticamente, e a padronização das tarefas ajuda a garantir que todos os analistas realizem as mesmas verificações básicas.

Quando fechar, quando aprofundar e quando escalar

Fecha-se quando há evidência suficiente de que o sinal é falso ou que a atividade é legítima e aprovada, e quando não há indicação adicional de risco. Aprofunda-se quando o incidente é provável mas falta contexto: por exemplo, um processo suspeito sem informações sobre o processo pai ou a ligação de rede. Escala-se imediatamente quando há um perigo ativo, um ativo crítico, privilégios elevados, propagação, suspeita de roubo de identidade ou necessidade de ação além da autoridade do analista.

Em cada um dos resultados, deve ser escrita uma breve explicação. “Parece OK” não é uma explicação. Uma boa redação indica os factos: “A varredura foi realizada a partir do endereço IP de um scanner corporativo, existe um chamado de alteração válido, os destinos e o tempo correspondem à janela aprovada, e nenhuma outra atividade foi encontrada.”

Quando não há informações suficientes, não force uma classificação de Falso Positivo. Classificar como Indeterminado e encaminhar para investigação adicional é preferível a um fecho aparentemente seguro.

Tabela de decisão para dez alertas

Alerta	Contexto principal	Prioridade sugerida	Decisão de Triage
10 tentativas de login falhadas para um funcionário regular	Endereço corporativo, sem sucesso	Baixa	Verificar padrão e fechar se conhecido
Login bem-sucedido para Admin de um novo país	Identidade Privileged, sem dispositivo conhecido	Crítica	Escalar e verificar sessão imediatamente
PowerShell codificado em estação de IT	Ferramenta de gestão assinada, Change ativo	Média	Verificação e consideração de Benign Positive
EDR detetou Credential Dumping	Servidor de identidades, processo não assinado	Crítica	Escalada/contenção de acordo com o Playbook
Varredura interna de portas	Origem é um scanner de vulnerabilidades conhecido	Baixa	Verificar janela e fechar documentado
DNS para novo domínio	Estação de utilizador, sem evidências adicionais	Média	Enriquecer domínio e verificar processo de origem
Criação de novo utilizador local	Servidor de produção, criador desconhecido	Alta	Investigação e escalada para o proprietário do sistema
Bloqueio de ficheiro malicioso	O ficheiro foi bloqueado, não executado	Média	Verificar origem e outros ficheiros
Desativação de antivírus	Realizado em várias estações	Crítica	Incidente ativo — escalada imediata
Impossible Travel	VPN conhecida e MFA OK	Média	Verificar identidade e rota antes de fechar

Checklist prático

Compreendi o que ativou a regra.
Identifiquei utilizador, ativo e criticidade.
Verifiquei sucesso versus tentativa.
Procurei alertas relacionados.
Verifiquei se a atividade ainda está ativa.
Decidi fechar, investigar ou escalar.
Escrevi uma justificação e não apenas um status.

Erros comuns

Aceitar a Severity do produto sem verificação de contexto.
Dar prioridade apenas pela ordem de chegada.
Confundir Triage com investigação completa e ficar preso num único alerta.
Fechar porque não há IOC conhecido.
Ignorar a extensão da atividade e a criticidade do ativo.

Resumo e CTA

O próximo passo após o Triage é uma investigação baseada em Timeline. Consulte o artigo “Como investigar um alerta de segurança em SOC de ponta a ponta” e pratique a tabela de decisão em alertas do seu laboratório doméstico ou ambiente de aprendizagem HPI.

Perguntas frequentes

Qual é a diferença entre Triage e investigação?

O Triage determina a urgência e o caminho de tratamento através de uma verificação limitada. A investigação recolhe evidências e tenta explicar o incidente de ponta a ponta.

A Severity alta sempre tem prioridade?

Não. A Severity é um dado importante, mas um ativo crítico, identidade sensível, confiabilidade e extensão podem alterar a prioridade.

Quanto tempo dedicar ao Triage?

A organização deve definir um Timebox e um SLA de acordo com o tipo de incidente. O objetivo é chegar a uma decisão para o próximo passo, não concluir toda a investigação.

É possível automatizar o Triage?

É possível automatizar o enriquecimento, associação, etiquetagem, tarefas e fecho de casos conhecidos. Decisões de alto impacto devem incluir controlos e aprovação humana de acordo com o risco.

Qual é o sinal mais importante para escalada?

Não há um único sinal, mas atividade ativa num ativo crítico, comprometimento de identidade Privileged ou propagação para vários ativos exigem uma resposta particularmente rápida.