/ TL;DR

Playbook de 8 fases para startups sem SOC responderem a incidentes com timing t+0 a t+72h e notificação ANPD dentro de 48h.

Startup brasileira média tem menos de 15 engenheiros e nenhum SOC. Quando um incidente estoura — vazamento de credenciais, ransomware, acesso indevido — o CTO fica com a chave inglesa. Este playbook lista 8 fases numeradas com timing agressivo, responsáveis definidos e o gatilho da notificação à ANPD dentro de 48 horas exigida pela LGPD.

Antes do incidente: pré-requisitos

Três coisas precisam existir na terça-feira comum, senão a sexta-feira de crise vira caos:

  • Canal de comunicação separado (Signal ou Slack em workspace novo) para o time de resposta — o ambiente comprometido pode estar sendo monitorado.
  • Runbook impresso com contatos: DPO, jurídico, ANPD (0800-978-2660), CERT.br, provedor de nuvem.
  • Backup imutável testado nas últimas 4 semanas. Backup não testado é ficção.

Fase 1 — Detecção (t+0)

Gatilho: alerta de WAF, findings críticos do scanner contínuo, denúncia de usuário, e-mail de "seus dados estão à venda".

  • Responsáveis: dev on-call, CTO.
  • Ações: validar o sinal (falso positivo é comum), abrir canal de crise, cronometrar. t=0 é o timestamp do primeiro sinal confiável, não do primeiro alarme.
  • Meta: ir para fase 2 em menos de 15 minutos.

Fase 2 — Triagem (t+15min)

  • Responsáveis: CTO (comando), dev sênior (evidências), engenheiro de infra (isolamento).
  • Ações: classificar severidade em três buckets — S1 (dados pessoais expostos ou serviço fora), S2 (comprometimento sem exposição confirmada), S3 (tentativa contida). Se S1, ativar o cronômetro da ANPD.
  • Evidências mínimas: snapshot de logs (S3 versionado se possível), lista de IPs suspeitos, hash de artefatos suspeitos, timestamp UTC.

Fase 3 — Contenção (t+1h)

O objetivo aqui não é entender o ataque. É parar a hemorragia.

  • Responsáveis: engenheiro de infra + dev sênior.
  • Ações: rotacionar todos os secrets de escopo suspeito, revogar tokens OAuth, invalidar sessões, isolar workload em VPC restrita (não desligar — perde evidência volátil), bloquear IPs no WAF.
  • Anti-padrão: deletar o container comprometido. Preserve com snapshot antes.

Fase 4 — Erradicação (t+4h)

  • Responsáveis: dev sênior, CTO valida.
  • Ações: identificar vetor (SSRF? credencial vazada? dep vulnerável?), remover backdoors, reinstalar imagens a partir de fonte confiável, aplicar patch. Se o vetor foi uma vulnerabilidade OWASP, cruze com o findings do scanner para achar outras instâncias do mesmo padrão. A anatomia de uma SSRF explica bem como um vetor único vira multiplicador.

Fase 5 — Recuperação (t+8h)

  • Responsáveis: engenheiro de infra, QA, CTO.
  • Ações: subir versão limpa em ambiente isolado, validar integridade dos dados contra backup imutável, teste de fumaça, corte gradual de tráfego (10% → 50% → 100%), monitoramento reforçado por 72h.

Fase 6 — Notificação regulatória (t+24 a t+48h)

Gatilho: incidente S1 com dado pessoal envolvido. A LGPD art. 48 e a Resolução CD/ANPD 15/2024 exigem notificação em "prazo razoável" — a ANPD interpreta como até 48 horas do conhecimento.

  • Responsáveis: DPO, jurídico, CTO valida os fatos técnicos.
  • Conteúdo mínimo da notificação: natureza dos dados, número aproximado de titulares, medidas técnicas adotadas, riscos, providências, canal de contato.
  • Canal: peticionamento eletrônico no site da ANPD.
  • Comunicação aos titulares: obrigatória quando o risco for relevante. E-mail transacional + página pública dedicada + ticket de suporte com FAQ.
Contatos essenciais para o kit de crise:
- ANPD: 0800-978-2660 / peticionamento eletrônico
- CERT.br: [email protected]
- CGU (se envolver setor público): CTIR.gov.br
- Delegacia especializada: DECRADI (SP), DERCIFE (RJ)

Fase 7 — Comunicação externa (t+24 a t+72h)

  • Responsáveis: CEO, comunicação, jurídico.
  • Ações: statement público com fatos, não desculpas. Reserve um domínio de status page. Prepare Q&A para imprensa. Silêncio é pior que resposta ruim — Serasa e Enel foram parâmetros negativos recentes; Nubank em 2021 é um bom parâmetro positivo pela velocidade.

Fase 8 — Aprendizado (t+7 a t+30 dias)

  • Responsáveis: todo o time.
  • Ações: post-mortem blameless, timeline detalhada, root cause em 5-porquês, lista de melhorias com prazo e dono, atualização do runbook. Simular a mesma classe de ataque em 30 dias (tabletop exercise).
  • Indicador: reincidência da mesma classe em 12 meses é falha de aprendizado.

Timeline consolidada

| Fase | T alvo | Dono principal | Saída | |------|--------|----------------|-------| | 1. Detecção | t+0 | Dev on-call | Sinal validado | | 2. Triagem | t+15min | CTO | Severidade + evidências | | 3. Contenção | t+1h | Infra | Sangramento parado | | 4. Erradicação | t+4h | Dev sênior | Vetor removido | | 5. Recuperação | t+8h | Infra | Serviço restabelecido | | 6. ANPD | t+48h | DPO | Notificação protocolada | | 7. Comunicação | t+72h | CEO | Statement público | | 8. Aprendizado | t+30d | Time | Post-mortem publicado |

Como reduzir o tempo de detecção

MTTD longo é o pecado capital das startups sem SOC. Uma varredura externa contínua funciona como sensor barato: expõe vulnerabilidades antes do adversário e alerta quando algo muda na superfície pública. A Varredura testa suas aplicações 24/7 e envia findings priorizados sem falso-positivo cerimonial. Rode agora e encurte o tempo entre "algo mudou" e "sabemos o quê".

EV

Equipe Varredura

Time de pesquisa de segurança · Varredura

Sua app em produção passa por essa análise?

Rode uma varredura autônoma em ~60 segundos. Sem cadastro.

Analisar minha aplicação →