Resposta a incidentes: como montar um plano de IR e o papel do SOC

Não existe empresa que nunca será atacada. Existe a empresa que se preparou para o incidente e a que vai descobri-lo pela imprensa. A diferença entre as duas raramente está na sofisticação do atacante, e sim na qualidade do plano de resposta a incidentes e na capacidade de detecção do time de defesa.

Este guia explica o que é resposta a incidentes, percorre as fases do ciclo segundo o NIST, mostra como classificar severidade, quais métricas acompanhar e qual o papel do SOC. O foco é prático: o que precisa estar pronto antes do incidente, porque no meio dele já é tarde para improvisar.

O que é resposta a incidentes

Resposta a incidentes (em inglês, Incident Response ou IR) é o conjunto organizado de processos que uma empresa usa para se preparar, detectar, conter e se recuperar de eventos de segurança. Um incidente é qualquer evento que comprometa, ou ameace comprometer, a confidencialidade, a integridade ou a disponibilidade de sistemas e dados.

A palavra-chave é processo. Responder a um incidente no improviso, decidindo cada passo na hora do pânico, é a receita para piorar o estrago: derrubar evidências, comunicar tarde, tomar decisões irreversíveis sob estresse. Um plano de IR transforma o caos em uma sequência de passos conhecidos, com papéis definidos e decisões já pensadas a frio.

As fases do ciclo de resposta a incidentes

O framework mais usado é o do NIST (publicação SP 800-61), que organiza a resposta em quatro fases que formam um ciclo contínuo.

1. Preparação

A fase mais importante, e a única que acontece antes do incidente. Aqui se define o plano, os papéis (quem decide, quem comunica, quem investiga), os canais de comunicação, as ferramentas e os contatos de emergência. Inclui também o trabalho preventivo: logs centralizados, monitoramento ativo, backups testados e treinamento do time. Uma empresa bem preparada já tem os playbooks prontos para os cenários mais prováveis.

2. Detecção e análise

É quando o incidente é identificado e compreendido. Os sinais vêm de várias fontes: alertas de ferramentas de segurança, comportamento anômalo nos logs, um aviso de terceiro ou a reclamação de um usuário. O trabalho aqui é separar ruído de ameaça real, determinar o escopo (o que foi afetado), classificar a severidade e iniciar a documentação. Cada minuto desta fase conta, porque o atacante está se movendo enquanto ela acontece.

3. Contenção, erradicação e recuperação

A fase de ação, dividida em três momentos:

• Contenção: impedir que o incidente se espalhe. Pode ser isolar uma máquina da rede, revogar credenciais ou bloquear um IP. A contenção rápida limita o dano sem, idealmente, destruir evidências.
• Erradicação: remover a causa raiz, eliminar o acesso do atacante, fechar a vulnerabilidade explorada e limpar artefatos maliciosos.
• Recuperação: restaurar os sistemas a partir de fontes confiáveis, validar que estão limpos e monitorar de perto para garantir que o atacante não retorne.

4. Lições aprendidas (pós-incidente)

Depois que a poeira baixa, o time se reúne para o post-mortem: o que aconteceu, como respondemos, o que funcionou e o que falhou. O objetivo nunca é culpar pessoas, e sim corrigir o sistema. As conclusões alimentam de volta a fase de preparação, fechando o ciclo e deixando a organização mais forte para o próximo evento.

O papel do SOC

O SOC (Security Operations Center) é o time, e a estrutura, responsável por monitorar, detectar e responder a ameaças de forma contínua. Enquanto o plano de IR é o processo, o SOC é frequentemente quem o executa na linha de frente.

Um SOC maduro opera em camadas:

• Monitoramento contínuo (24/7): alguém ou algo está sempre olhando, porque atacantes não respeitam horário comercial.
• Triagem de alertas: filtrar o volume enorme de alertas e identificar os que merecem investigação.
• Investigação e resposta: aprofundar os casos reais e acionar a contenção.
• Caça a ameaças (threat hunting): buscar ativamente sinais de comprometimento que passaram pelos alertas automáticos.

Sem monitoramento contínuo, o tempo de permanência de um atacante na rede costuma ser medido em semanas, tempo de sobra para exfiltrar dados e instalar persistência. O SOC existe para encurtar drasticamente esse intervalo.

Classificação de severidade

Nem todo incidente merece a mesma resposta. Classificar a severidade orienta a urgência, o nível de escalonamento e a comunicação.

Severidade	Descrição	Exemplo	Resposta
Crítica	Impacto grave em dados ou operação	Vazamento de dados de clientes em andamento	Acionamento imediato, força-tarefa
Alta	Comprometimento significativo	Acesso não autorizado a sistema interno	Resposta em horas, escalonamento
Média	Risco contido ou parcial	Tentativa de phishing bem-sucedida em um usuário	Investigação no dia
Baixa	Evento menor, sem impacto direto	Varredura externa sem exploração	Registro e monitoramento

A classificação não é definitiva: um incidente "médio" pode escalar para "crítico" conforme a investigação revela mais escopo. A régua deve ser revisada continuamente durante o evento.

Métricas que importam: MTTD e MTTR

A maturidade de uma operação de segurança se mede por dois números:

• MTTD (Mean Time To Detect): tempo médio entre o início do incidente e sua detecção. Quanto menor, menos tempo o atacante age livremente.
• MTTR (Mean Time To Respond): tempo médio entre a detecção e a contenção ou resolução. Mede a agilidade da resposta.

A meta é encolher os dois. Um MTTD alto significa que ataques ficam invisíveis por muito tempo; um MTTR alto significa que, mesmo detectando, o time demora a agir. Ambos são reduzidos com preparação, automação e playbooks bem ensaiados.

Playbooks: a resposta pré-escrita

Um playbook é o roteiro passo a passo para um tipo específico de incidente. Tê-los prontos remove a hesitação do momento crítico. Veja um exemplo simplificado para conta comprometida:

playbook: conta_comprometida
gatilho: "login suspeito + atividade anômala"
passos:
  - id: 1
    acao: "revogar sessões ativas e tokens da conta"
    responsavel: SOC
  - id: 2
    acao: "forçar redefinição de senha e exigir MFA"
    responsavel: SOC
  - id: 3
    acao: "coletar logs de acesso das últimas 72h"
    responsavel: analista
  - id: 4
    acao: "avaliar dados acessados e escopo do impacto"
    responsavel: lider_ir
  - id: 5
    acao: "se houver dado pessoal exposto, acionar processo LGPD"
    responsavel: lider_ir
escalonamento: "severidade alta ou superior aciona o lider de IR"

O valor do playbook é a consistência: a resposta não depende de quem está de plantão naquela madrugada.

Erros comuns que transformam incidente em crise

• Não ter plano. Improvisar sob estresse multiplica os erros.
• Destruir evidências cedo demais. Desligar a máquina pode apagar o rastro do atacante. Contenha preservando o que for possível.
• Comunicar mal. Silêncio gera pânico; comunicação precipitada gera ruído. Defina quem fala, o que e quando, antes.
• Pular as lições aprendidas. Sem post-mortem, a empresa repete o mesmo incidente.
• Confiar só em ferramentas. Alertas sem gente treinada para investigá-los são apenas barulho.

Resposta a incidentes é, no fundo, um teste de preparação. A hora de montar o plano é justamente quando tudo está calmo, não quando o alarme já está tocando.

Sua empresa está pronta para o próximo incidente?

Detectar rápido e responder com método é o que separa um susto contido de uma manchete. Na ConstructorTI, unimos blue team, SOC com monitoramento contínuo e resposta a incidentes para encurtar o tempo entre o ataque e a contenção. Se você quer um plano de IR de verdade, ensaiado e operado por gente que também sabe atacar, converse com o nosso time de CyberSecurity e saia da conversa com um diagnóstico da sua capacidade de resposta.