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

Severity vs. Priority: Como Classificar Incidentes de Segurança

6 min de leituraPublicado: 5 de agosto de 2026

Ilustração visual profissional sobre Severity versus Priority em cibersegurança no campo de SOC e operações

Resposta rápida

Severity descreve o impacto potencial e a gravidade do incidente; Priority determina a ordem e a velocidade do tratamento real. Um incidente pode ser grave, mas não urgente, se estiver isolado e contido, ou de gravidade média, mas com alta prioridade, se estiver ativo num ativo crítico. Uma classificação profissional combina confiança, âmbito, criticidade do ativo, identidade, exposição comercial, estado de contenção e tempo.

Nos sistemas SOC, por vezes, aparecem vários scores em simultâneo: Alert Severity, Incident Severity, Risk Score, Magnitude ou Priority. Quando a equipa os usa como se fossem a mesma coisa, o resultado é uma fila de trabalho inconsistente: um incidente “High” antigo e isolado empurra para segundo plano uma atividade “Medium” que está a ocorrer agora na conta de um gestor.

A Microsoft descreve Severity como uma medida do impacto potencial nos ativos, enquanto a fila unificada de incidentes adiciona um mecanismo de Priority que também considera a criticidade do ativo, a raridade, as técnicas MITRE e as ameaças de alto perfil. No QRadar, a Magnitude de uma Offense é calculada a partir de uma combinação de Severity, Relevance e Credibility, juntamente com outros fatores. Os exemplos ilustram que não existe um único score adequado para todas as decisões.

O objetivo não é substituir os scores das ferramentas, mas sim criar uma linguagem organizacional que explique por que razão um incidente está a ser tratado agora, quem o está a tratar e o que levará a uma mudança na classificação.

O que é Severity

Severity descreve a gravidade do resultado possível ou observado: impacto na confidencialidade, integridade ou disponibilidade; número de ativos e utilizadores; criticidade do sistema; sensibilidade dos dados; e o nível de controlo do atacante. Responde à pergunta: “Se o cenário for real, quão grave é?”

Na maioria das ferramentas, os valores são Informational, Low, Medium e High, e por vezes Critical. É importante entender quem definiu o valor: o fabricante da Deteção, uma Regra local, um motor analítico ou um analista. A Alert Severity pode ser herdada para um Incidente, mas após investigação, é permitido e, por vezes, necessário atualizá-la.

Severity não é prova de veracidade. Uma regra High com um False Positive alto não transforma cada correspondência num incidente grave. Por isso, é preciso separar a gravidade da Confiança.

O que é Priority

Priority determina a ordem de tratamento e o nível de urgência. Responde: “O que trataremos primeiro?” Além da gravidade, considera o tempo, o estado do incidente, a capacidade de contenção, as pessoas disponíveis, os SLA e o contexto comercial.

Um incidente de Ransomware ativo numa única estação pode receber uma Priority crítica devido à velocidade de propagação, mesmo antes de o Scope ser conhecido. Em contraste, uma fuga histórica grave que já foi contida pode manter uma Severity alta, mas uma Priority mais baixa para investigação imediata, desde que não haja impacto ativo.

A Priority deve ser dinâmica. Com a descoberta de um ativo adicional, um logon bem-sucedido, uma alteração de Privilege ou uma falha de Containment — a Priority aumenta. Após isolamento, Revoke e verificação de que não há propagação — a urgência pode ser reduzida sem necessariamente alterar a gravidade do incidente.

Por que as duas métricas são diferentes

Se for usada apenas a Severity, a fila de trabalho é controlada pela classificação inicial da ferramenta. Se a Priority for usada apenas manualmente, é difícil comparar incidentes e realizar uma revisão. A combinação correta é uma Severity relativamente estável que descreve o Impacto, e uma Priority operacional que é atualizada de acordo com o estado do incidente.

Pode-se adicionar Confidence ou Likelihood como um terceiro eixo. Por exemplo: Severity alta, Confidence baixa, Priority média até à verificação; ou Severity média, Confidence alta e incidente ativo — Priority alta.

No QRadar, a Magnitude é um exemplo de pontuação combinada: Severity, Relevance e Credibility juntamente com Asset Weight, número de Events, idade da Offense e vulnerabilidades. É útil para a priorização, mas ainda requer a compreensão do contexto.

Fatores que afetam a Severity

Impacto na confidencialidade, integridade e disponibilidade.
Criticidade do ativo e do serviço comercial.
Sensibilidade e volume da informação.
Nível de acesso: User, Local Admin, Domain Admin ou Cloud Admin.
Número de ativos, utilizadores e ambientes envolvidos.
Fase do ataque: Initial Access versus Exfiltration ou Impact.
Capacidade de recuperação e se existem backups válidos.

Fatores que afetam a Priority

Se a atividade está a ocorrer agora.
Velocidade de propagação ou uma curta janela de ação.
Confiabilidade da deteção e provas de suporte.
Ativo ou identidade críticos.
Se o incidente foi contido ou se o acesso ainda está ativo.
SLA, disponibilidade da equipa e exigência de coordenação.
Existência de uma ameaça ativa e relevante para a organização.
Impacto comercial imediato, mesmo que a gravidade técnica seja média.

Matriz de Classificação Prática

É possível começar com uma matriz de Severity e Confidence, e depois ajustar a Priority de acordo com o estado da atividade e a criticidade. Não há uma fórmula universal; o modelo deve ser transparente, documentado e testado em incidentes reais.

Recomenda-se adicionar um campo “Razão” a cada decisão. “Prioridade Alta – Sessão ativa em identidade privilegiada; contenção não concluída” é mais claro do que apenas uma pontuação.

Severity	Confidence	Estado	Priority Típica
Alta	Alta	Ativo/Não Contido	Crítica
Alta	Média	Contido Temporariamente	Alta
Alta	Baixa	Sem Prova Adicional	Média até Verificação
Média	Alta	Ativo Crítico ou Propagação	Alta
Média	Média	Atividade Concluída	Média
Baixa	Alta	Grande Volume ou Impacto Operacional	Média
Baixa	Baixa	Caso Único sem Impacto	Baixa

Exemplos do SOC

Cenário	Severity	Priority	Justificação
Malware antigo encontrado em ficheiro Archive isolado	Alta	Baixa-Média	Potencial grave, mas sem execução ativa
Password Spray ativo sem sucesso	Média	Alta	Janela de contenção curta e âmbito de utilizadores
Login de Global Admin de um novo país	Alta	Crítica	Identidade sensível e sessão potencialmente ativa
Servidor de Produção não envia logs	Média	Alta	Perda de visibilidade em ativo crítico
Adware em estação de laboratório desconectada	Baixa	Baixa	Impacto limitado e Containment existente

Como Atualizar a Classificação Durante a Investigação

Defina pontos de Revisão: após Triage, após o Scope inicial, após a primeira ação e antes do fecho. Em cada ponto, pergunte o que mudou no Impacto, Confidence e no estado da atividade. A atualização de uma pontuação deve incluir Timestamp, Owner e justificação.

Não reduza a Severity apenas para cumprir o SLA. Se o incidente é grave, mas foi contido, pode-se manter a Severity alta e reduzir a Priority. Assim, a imagem histórica do risco é preservada e o relatório não é enganador.

Nas métricas da equipa, analise também a Reclassificação: quantos incidentes subiram ou desceram de nível, e o que causou isso. Uma mudança consistente pode indicar uma Regra que classifica incorretamente ou uma Asset Criticality que não está atualizada.

Checklist Prático

Está claro quem definiu a Severity inicial?
Avaliei o Impacto e não apenas o nome da Deteção?
A Confidence é documentada separadamente?
O incidente está ativo ou contido?
Estão envolvidos ativos/identidades críticos?
A Priority inclui uma justificação operacional?
Foi definido o próximo ponto de Revisão?
A alteração da pontuação é guardada no Audit Trail?

Erros Comuns

Marcar cada Alert High como um incidente Critical.
Usar Severity e Priority como sinónimos.
Não atualizar a classificação após isolamento ou expansão do Scope.
Ignorar a criticidade do ativo e a sensibilidade da informação.
Construir uma fórmula complexa que ninguém entende.
Medir o SLA de uma forma que encoraja a redução artificial da Severity.

Resumo e CTA

Crie uma matriz com cinco cenários de laboratório e atribua a cada um Severity, Confidence e Priority com uma frase de justificação. Compare o resultado com o artigo sobre Triage e os critérios de escalada. No curso Cybersecurity & AI da HPI, praticam a tomada de decisões baseada no contexto e não apenas na leitura de uma pontuação do sistema.

Perguntas frequentes

A Severity do fabricante obriga a organização?

Não. É um ponto de partida. Deve ser adaptada ao ambiente, ao ativo, ao Scope e à política local.

A Priority pode ser maior que a Severity?

Sim. Uma atividade ativa num ativo crítico ou uma curta janela de contenção podem justificar uma Priority alta, mesmo quando o Impacto estimado é médio.

Quando se muda a Severity?

Quando as provas alteram a avaliação do impacto ou o Scope. A mudança deve ser documentada com justificação.

O que é Magnitude no QRadar?

Uma pontuação que ajuda a priorizar Offenses e é calculada, entre outros, com base em Severity, Relevance, Credibility, ativos e eventos. Não é o mesmo que apenas Severity.

É necessário Critical acima de High?

Apenas se a organização for capaz de definir critérios e ações diferentes. Demasiadas categorias criam inconsistência.