Como este tema funciona na sua empresa
Plano simplificado com roles claros (CEO, gestor TI, técnico), playbooks básicos (malware, vazamento de dados) e checklist de ações. Implementação: 1-2 semanas. Teste: tabletop simples 1x/ano.
Plano estruturado com CIRT (Crisis/Computer Incident Response Team), playbooks detalhados por tipo de incidente, automação de primeiros passos (isolamento de endpoint, coleta de logs). Implementação: 30-60 dias. Teste: tabletop 2x/ano + simulado 1x/ano.
Plano enterprise com CIRT dedicado, playbooks por criticidade, orquestração automática de resposta (SOAR), integração com legal/compliance/comunicação. Implementação: 90+ dias. Teste: simulados trimestrais + exercício full-scale 1x/ano.
Plano de resposta a incidentes é documento estruturado que define como a organização reage quando há evento de segurança (ataque, vazamento, malware, indisponibilidade). Diferencia-se de política de segurança (que diz o que fazer) ao detalhar procedimentos específicos durante crise: quem chamar, em quanto tempo, qual é a cadeia de escalação, como comunicar ao negócio e à ANPD. Um plano bem estruturado reduz MTTR (Mean Time To Recover) em 60–70% e custo de incidente em 40%. Sem plano, crise resulta em caos (ninguém sabe quem ligar, que dados coletar, como comunicar). O desafio é estrutura prática implementável, não documento teórico.
As sete fases de resposta a incidente
1. Preparação: Antes do incidente — governança, ferramentas, contatos, treinamento. 2. Detecção: Incidente é descoberto (alerta de sensor, usuário reporta). 3. Análise: O que aconteceu? Qual é o impacto? 4. Contenção: Parar o dano — isolar sistema comprometido, bloquear acesso atacante. 5. Erradicação: Remover atacante completamente. 6. Recuperação: Restaurar sistemas e dados ao estado normal. 7. Lições aprendidas: Postmortem — o que falhou, como prevenir recorrência[1].
Timing é crítico. Incidente de hoje pode ter impacto massivo amanhã se não contém. Plano define SLA por fase: detecção < 4h, contenção < 8h, erradicação < 72h, recuperação < 1 semana.
Estrutura de CIRT (Computer Incident Response Team)
CIRT é time dedicado a resposta. Em empresas pequenas, é informalmente atribuído (gestor TI é "CIRT"). Em médias/grandes, é estrutura formal com papéis: Incident Commander: liderança técnica durante incidente, coordena ações. Security Lead: especialista em segurança, conduz análise técnica. Communications Lead: redige comunicações internas/externas. Legal/Compliance: avalia obrigação legal (comunicar ANPD?). Operations Lead: coordena recuperação técnica. Executives Sponsor: comunicação com C-level, decisão de escalação.
Contatos 24/7 de cada papel devem estar documentados. Um incidente crítico às 22h exigem que chefes de TI recebam alertas imediatos.
Playbooks por tipo de incidente
Plano não detalha cada tipo de incidente — seria 500 páginas. Melhor: playbooks por tipo mais comum. Malware/Ransomware: (1) isolar sistema comprometido, (2) notificar CIO, (3) coletar evidência forense, (4) avaliar se backup está comprometido, (5) restaurar se necessário, (6) comunicar executivos. Vazamento de dados: (1) confirmar que vazamento ocorreu, (2) avaliar que dados foram vazados, (3) avaliar risco aos titulares, (4) notificar ANPD se necessário, (5) notificar titulares afetados, (6) comunicar mídia. DDoS: (1) ativar CDN para absorver tráfego, (2) notificar ISP, (3) monitorar se ainda está em andamento, (4) documentar para análise, (5) investigar origem[2].
Cada playbook deve ser 1–2 páginas, acionável, testado.
Comunicação durante crise: interna e externa
Comunicação é tão crítica quanto técnico. Durante incidente: (1) Interno: Notificar stakeholders (CEO, CFO, clientes-key). Frequência: atualização a cada 4h durante crise. (2) Clientes: Se impacta operação do cliente, comunicar o que está acontecendo, ETA de recuperação. (3) Mídia: Se incidente é público (vazamento), preparar comunicado. (4) Reguladores: Se obrigação legal, notificar ANPD. Sem plano de comunicação, empresa fica sitiada por mídia, relatórios divergentes causam pânico.
Recomendação: ter template de comunicação preparado antes do incidente. "Um incidente crítico foi detectado em [data/hora]. Estamos investigando e tomaremos ação para proteger dados."
Preservação de evidência forense
Resposta rápida é importante, mas preservação de evidência é crítica para análise e possível investigação legal. Ações que destroem evidência: reboot de servidor (apaga memória), limpeza de logs, desligamento de rede. Plano deve equilibrar: contém incidente rapidamente (isola sistema), mas coleta evidência forense antes de fazer mudanças permanentes. Recomendação: se incidente pode ter implicação legal, envolver forensic specialist antes de fazer qualquer ação que altere estado do sistema.
- Nenhum plano documentado ou plano com 3+ anos sem revisão
- Incidente recente levou mais tempo do que "deveria" porque ninguém sabia papéis
- Comunicação durante crise foi caótica ou contraditória
- Falta de teste do plano (plano não testado é pior que não ter plano)
- Contatos de emergência desatualizados (pessoas saíram, números antigos)
- Diferença significativa entre "plano" e "o que realmente fazemos em crise"
Pequena: Documento com roles, contatos, playbooks básicos, checklist. Assinado por diretor. Revisão anual. Teste: tabletop.
Média: Plano estruturado com CIRT, playbooks detalhados, integrações (ferramentas de detecção). Treinamento de papéis. Teste: tabletop + simulado.
Grande: CIRT dedicada, playbooks por criticidade, SOAR (automação de resposta), integração com legal/compliance, simulados frequentes.
Design de plano: Consultoria especializada em incident response (SANS, Deloitte) pode estruturar plano customizado.
Facilitação de teste: Empresa especializada em tabletop exercises pode conduzir simulação de incidente para validar plano.
Resposta gerenciada: MSP (Managed Security Provider) pode oferecer CIRT como serviço (custo por resposta ou retainer).
Perguntas frequentes
Quais são as etapas de resposta a um incidente de segurança?
Preparação ? Detecção ? Análise ? Contenção ? Erradicação ? Recuperação ? Lições aprendidas. Cada fase tem objetivo e SLA específico.
Como estruturar um plano de resposta a incidentes?
Defina papéis (Incident Commander, Security, Comms, Legal), contatos 24/7, playbooks por tipo de incidente, cronograma de teste, procedimento de comunicação.
O que é playbook de resposta a incidentes?
Documento 1–2 páginas acionável que detalha passos para um tipo específico de incidente (malware, vazamento, DDoS). Deve ser testado e fácil de seguir sob pressão.
Como testar plano de resposta a incidentes (tabletop, simulado)?
Tabletop: discussão de cenário, sem executar ações. Simulado: execução parcial (teste ferramentas, comms). Exercício full-scale: simulação completa incluindo legal, mídia. Todos são validações necessárias.
Qual é a diferença entre triage, containment e eradication?
Triage: avaliar severidade e impacto. Containment: parar o dano (isolar sistema). Eradication: remover atacante completamente. Sequencial.
Como automatizar resposta a incidentes?
SOAR (Security Orchestration, Automation, Response) integra ferramentas de detecção com ações automáticas (isolamento de endpoint, bloqueio de IP, coleta de logs). Automação reduz MTTR, não elimina decisão humana.