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

Quando um analista SOC deve escalar um incidente para o Tier 2 ou IR

8 min de leituraPublicado: 5 de agosto de 2026

Representação visual profissional sobre a escalada de incidentes em SOC na área de SOC e operações

Resposta rápida

Um analista SOC deve escalar um incidente quando o nível de risco, incerteza ou o âmbito das ações necessárias excedem a autoridade e capacidade do Tier 1. Uma boa escalada não é "passar um problema", mas sim entregar um pacote de investigação organizado que inclui factos, evidências, cronograma, impacto estimado, ações já tomadas e uma pergunta clara para a próxima equipa. Em caso de violação ativa, ativo crítico ou suspeita de fuga de informação, envolve-se a Resposta a Incidentes (IR) rapidamente de acordo com os procedimentos.

No centro de operações de segurança (SOC), uma das competências mais importantes não é apenas saber investigar um alerta, mas saber quando parar de investigar sozinho. Um analista Tier 1 que persiste por demasiado tempo pode atrasar a contenção de um incidente real; um analista que escala todos os pequenos sinais cria sobrecarga, perde confiança e dificulta a identificação de casos críticos pelo Tier 2. Portanto, a escalada é uma decisão profissional que deve ser baseada em critérios, não em intuição.

A divisão de responsabilidades varia entre as organizações. De acordo com a orientação da Microsoft para processos de Resposta a Incidentes, o Tier 1 foca-se na triagem de eventos e na triagem, o Tier 2 realiza uma investigação mais aprofundada, e o Tier 3 ou Threat Hunting lida com ameaças complexas e busca proativa. O NIST SP 800-61 Rev. 3 enfatiza que a resposta a incidentes é uma capacidade organizacional que inclui coordenação, responsabilidade, reporte e melhoria contínua. Consequentemente, a questão não é "conseguirei abrir outro ecrã", mas sim "quem deve tomar a próxima decisão e que informação é que essa pessoa precisa de receber".

Neste artigo, construiremos um modelo prático para escalada: gatilhos técnicos, impacto nos negócios, limites de autoridade, pacote de transferência, envolvimento de stakeholders e métricas para verificar a qualidade das escaladas.

O que é uma escalada profissional

A escalada é a transferência ou partilha de responsabilidade para uma entidade com maior autoridade, especialização ou acesso. É necessária quando há uma lacuna entre as necessidades do incidente e a capacidade de tratamento atual: não há permissão para recolher um determinado artefacto, é necessário isolar um servidor de produção, há indicação de movimento lateral, ou a decisão pode afetar as operações comerciais.

É importante distinguir entre escalada funcional e escalada hierárquica. A escalada funcional é direcionada a um especialista — por exemplo, Tier 2, investigador DFIR, administrador do Active Directory ou equipa de cloud. A escalada hierárquica é direcionada a um gestor de turno, CISO, gestão superior ou parte interessada do negócio devido ao impacto, risco ou necessidade de decisão. Num incidente complexo, ambos os caminhos podem ocorrer em paralelo.

A escalada não isenta o analista inicial da responsabilidade pela documentação e continuidade. Até que a próxima parte confirme o recebimento, o proprietário do ticket deve manter o controlo, evitar ações destrutivas e observar quais as ações urgentes que ainda estão pendentes.

A diferença entre Tier 1, Tier 2 e Resposta a Incidentes

O Tier 1 verifica se o alerta é relevante, verifica o contexto básico, remove ruído óbvio e identifica sinais que exigem investigação aprofundada. O Tier 2 conecta fontes adicionais, executa consultas complexas, constrói uma linha temporal ampla, verifica o Scope e formula uma Hipótese. A equipa de Resposta a Incidentes (IR) entra em ação quando há um incidente confirmado ou uma suspeita significativa que requer contenção, recolha de evidências, coordenação entre sistemas e recuperação.

O limite não é determinado apenas pelo tempo. Um analista Tier 1 pode resolver um caso complexo se tiver formação e autoridade, enquanto um incidente simples pode exigir IR devido a um ativo sensível. Por isso, cada organização deve definir antecipadamente as autoridades: quem pode isolar um Endpoint, desativar uma conta, bloquear um endereço, redefinir um Token, recolher uma Imagem de Memória ou contactar um fornecedor externo.

Um bom modelo também apresenta um SLA para escalada: quanto tempo é permitido manter um novo incidente sem um Proprietário, em que janela de tempo um incidente de Alta Prioridade deve ser transferido, e quando um gestor de turno deve receber uma atualização, mesmo que a investigação ainda não tenha terminado.

Gatilhos técnicos para escalada

Um gatilho técnico é um sinal que aumenta a probabilidade de um ataque, a extensão do incidente ou a necessidade de uma capacidade especial. Exemplos principais incluem a execução de código desconhecido num servidor crítico, Credential Dumping, alteração de permissões privilegiadas, Persistence, movimento lateral, uso de uma conta de serviço, eliminação de logs, desativação de EDR, comunicação para infraestrutura hostil ou uma sequência de várias técnicas MITRE ATT&CK.

A falta de dados também pode justificar a escalada. Se o EDR não estiver disponível, o servidor não enviar logs ou houver um desvio de relógio significativo (Clock Skew), o Tier 1 não pode fechar com segurança. Nesse caso, o pacote de escalada deve indicar explicitamente o que está em falta e o que precisa de ser recolhido.

Outro gatilho é um Scope instável. Se o mesmo Hash, utilizador ou IP aparecer em vários ativos, não trate cada alerta separadamente. Escalone para um incidente unificado para evitar ações contraditórias e para entender se se trata de uma campanha ampla.

Ativo crítico: Domain Controller, servidor de backup, sistema financeiro ou ambiente de produção.
Identidade sensível: Global Admin, conta de serviço ou utilizador com acesso a informações sensíveis.
Comportamento com impacto: encriptação de ficheiros, Exfiltration, Persistence ou Lateral Movement.
Comprometimento da capacidade de monitorização: eliminação de logs, desativação de Agent ou alteração da Política de Auditoria.
Incidente multi-sistema: identidade, Endpoint, e-mail e cloud na mesma linha temporal.
Necessidade de ação irreversível ou com impacto nos negócios.

Gatilhos de negócios e organizacionais

A gravidade técnica por si só não é suficiente. Uma conexão anómala a uma conta de teste pode ser de baixa prioridade, enquanto a mesma conexão a uma conta de gestor financeiro antes de uma transferência de pagamento pode receber alta prioridade. Verifique a criticidade do serviço, o tipo de informação, o número de utilizadores, a janela de atividade, a regulamentação relevante e a dependência dos processos de negócio.

Há incidentes em que é necessário envolver um interveniente não técnico precocemente: preocupação com fuga de dados pessoais, atividade de um funcionário, violação de cliente, incidente com fornecedor, interrupção de serviço público ou aviso de ransomware. O analista não decide sozinho sobre a obrigação de reporte ou sobre uma comunicação externa; ele fornece factos e ativa o canal de coordenação definido no plano de resposta.

Se não existir uma política clara, não a invente durante o incidente. Deve contactar o gestor de turno e documentar que a decisão foi tomada a um nível de autoridade superior.

O que deve ser incluído no pacote de escalada

Um bom pacote de escalada permite que a próxima parte comece onde a investigação terminou, e não repita as mesmas ações. Deve ser suficientemente conciso para uma leitura rápida e suficientemente preciso para uma tomada de decisão. Comece com uma frase: o que aconteceu, a quem, quando e porque está a escalar.

Em seguida, separe os factos, a interpretação e as suposições. Anexe os identificadores de Incident e Alert, ativos e utilizadores, linha temporal principal, Queries executadas, evidências de suporte, ações de resposta, limitações de informação e avaliação de impacto. Termine com uma pergunta clara: "É necessária uma decisão sobre o isolamento do servidor e a recolha de Memória", não "Por favor, verifique".

Se o incidente estiver ativo, indique também o Next Check Time e quem mantém a Ownership até que a escalada seja recebida. Não envie ficheiros suspeitos por um canal não autorizado nem cole informações sensíveis num sistema não concebido para esse fim.

Resumo de 2 a 4 linhas.
Severidade e Prioridade com justificação.
Entidades: utilizadores, Hosts, IP, Domínios, Hashes.
Linha temporal condensada dos eventos essenciais.
Ações já realizadas e os seus resultados.
Evidências e fontes de dados, incluindo lacunas.
Scope conhecido e Scope ainda não verificado.
A pergunta ou decisão necessária da próxima equipa.

Quando envolver IT, Jurídico, Gestão ou uma entidade externa

A equipa de IT é necessária quando é preciso realizar uma alteração operacional: desligar um serviço, repor uma conta, bloquear uma regra, restaurar a partir de um backup ou verificar uma alteração. A equipa de IR ou DFIR é necessária para a recolha e preservação de evidências, um Scope amplo e contenção coordenada. O Jurídico e a Privacidade são envolvidos quando existe a possibilidade de exposição legal, contratual ou regulamentar. A Gestão é necessária quando a decisão afeta a continuidade do negócio, clientes ou comunicação.

O contacto com um fornecedor MSSP, Cloud Provider, Cyber Insurance ou autoridades será feito de acordo com o acordo e o procedimento. Documente quem aprovou, o que foi transferido, por que canal e o que foi retido. O objetivo da documentação não é burocracia, mas sim manter a continuidade e a responsabilidade.

Exercício: Oito cenários

Cenário	Decisão Proposta	Razão Principal
Password Spray sem sucesso contra utilizadores regulares	Continuar Tier 1 e monitorizar	Sem sucesso; é necessário verificar o Scope e a origem
Login bem-sucedido para Global Admin a partir de um dispositivo não gerido	Escalada imediata para Tier 2/IR	Identidade crítica e sessão ativa
PowerShell assinado numa estação de IT durante a Change	Verificação e documentação; não necessariamente escalada	Existe uma explicação legítima, mas é necessária aprovação
EDR desativado num servidor de backup	Escalada imediata	Comprometimento do controlo de segurança e ativo crítico
O mesmo Hash em três estações	Unificar e escalar para um Scope amplo	Incidente multi-ativo
Utilizador reportou um e-mail suspeito, sem clique	Tratamento pelo Tier 1 e enriquecimento do e-mail	Nenhum ataque confirmado atualmente
Ficheiros encriptados e serviços interrompidos	IR, IT e Gestão de acordo com o Playbook	Incidente ativo com impacto nos negócios
Acesso anómalo à base de dados de clientes	IR e Privacidade/Legal de acordo com o procedimento	Preocupação com a exposição de informações sensíveis

Medição da qualidade das escaladas

Não meça apenas quantos incidentes foram escalados. Verifique quantas escaladas foram aceites sem pedidos de informações adicionais, quantas foram devolvidas por falta de evidências, o tempo desde a deteção até à escalada, a taxa de incidentes que se revelaram críticos e quais os gatilhos recorrentes que não foram definidos no Playbook.

Deve-se ter cuidado com a "gamificação": um objetivo de "menos escaladas" pode encorajar o fecho precoce; um objetivo de "escalada em cinco minutos" pode criar transferências vazias. A métrica correta combina velocidade, qualidade, precisão e impacto.

Checklist prático

O incidente excede a minha autoridade operacional?
Um ativo ou identidade crítica está envolvida?
Existe indicação de um ataque ativo ou de uma expansão de Scope?
Falta informação que não consigo obter sozinho?
É necessária uma ação com impacto nos negócios?
Criei um resumo, uma linha temporal e uma lista de evidências?
Formulei uma pergunta clara para a próxima parte?
Documentei o Proprietário e a próxima hora de verificação?

Erros comuns

Escalar sem resumir o que já foi investigado.
Esperar por 100% de certeza enquanto o ataque está ativo.
Usar a Severidade da ferramenta como critério único.
Transferir a responsabilidade sem garantir que a outra parte a recebeu.
Envolver demasiadas partes desnecessariamente e criar canais de comunicação paralelos.
Realizar isolamento ou desativação além da autoridade sem aprovação.

Resumo e CTA

Escolha três incidentes que tratou no laboratório e escreva um pacote de escalada de uma página para cada um. Em seguida, compare-o com a estrutura de investigação no artigo "Como Investigar um Alerta de Segurança SOC de Ponta a Ponta". No curso Cybersecurity & AI da HPI, pratica-se o trabalho com alertas, SIEM, documentação e escalada como parte de um processo SOC prático.

Perguntas frequentes

Todo incidente de alta prioridade precisa de ser encaminhado para o Tier 2?

Não necessariamente. A Severidade do produto é um ponto de partida. É preciso considerar a criticidade do ativo, a confiabilidade da deteção, o Scope, o impacto e a capacidade do Tier 1. No entanto, o procedimento da organização pode exigir escalada automática.

Quanto tempo é que um Tier 1 pode investigar antes de escalar?

Não há um número universal. Defina janelas de acordo com a Severidade e o SLA. Num incidente ativo ou num ativo crítico, escale imediatamente e continue a recolher dados em paralelo.

O que fazer se o Tier 2 não responder?

Ativar o caminho de Escalada hierárquica: gestor de turno, On-call ou gestor de IR. Documentar as tentativas e manter a Ownership.

É necessário escalar um Falso Positivo?

Se for claro e documentado, não. Se a regra for sistematicamente ruidosa ou o fecho exigir uma alteração na Deteção, é enviado feedback para a Detection Engineering e não necessariamente um incidente para o IR.

Quem decide envolver o Jurídico ou a Gestão?

A decisão é definida no plano de resposta e na política da organização. O analista identifica o gatilho e fornece os factos; não fornece sozinho aconselhamento jurídico ou comunicação externa.