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ê".
Sua app em produção passa por essa análise?
Rode uma varredura autônoma em ~60 segundos. Sem cadastro.