Incident Response Plan

Este plano estabelece os procedimentos para identificar, conter, erradicar e recuperar-se de incidentes de segurança que afetem a plataforma Forms2You, os dados dos Clientes ou a infraestrutura.

O objetivo é minimizar o impacto dos incidentes, preservar evidências, cumprir obrigações legais de notificação e aprender com cada evento para melhorar continuamente a postura de segurança.

2. Escopo e Definições

O que é um incidente de segurança

Qualquer evento real ou suspeito que comprometa (ou tente comprometer) a confidencialidade, integridade ou disponibilidade de:

Dados pessoais de Clientes ou respondentes;

Sistemas e infraestrutura do Forms2You;

Credenciais ou chaves de acesso;

A disponibilidade da plataforma.

Exemplos

Acesso não autorizado a dados de Clientes

Vazamento de credenciais (banco de dados, API keys)

Infecção por malware no servidor

DDoS com impacto significativo na disponibilidade

Vulnerabilidade explorada em produção

Exfiltração de dados

3. Classificação de Incidentes

Severidade	Critérios	Tempo de resposta inicial
P1 — Crítico	Vazamento de dados pessoais; comprometimento de produção; acesso não autorizado a dados de múltiplos Clientes	Imediato (< 1 hora)
P2 — Alto	Comprometimento de conta de Cliente; vulnerabilidade explorada sem exfiltração confirmada; downtime > 2h	< 4 horas
P3 — Médio	Tentativa de ataque contida; vulnerabilidade descoberta (não explorada); comportamento anômalo	< 24 horas
P4 — Baixo	Scan de vulnerabilidades externo; tentativas de brute force bloqueadas; alertas informativos	< 72 horas

4. Equipe de Resposta

Papéis no incidente

Papel	Responsabilidade
Coordenador do Incidente	Lidera a resposta, coordena comunicações, toma decisões
Responsável Técnico	Investiga, contém e resolve o problema técnico
Responsável por Comunicação	Gerencia comunicações com Clientes, parceiros e autoridades
DPO / Responsável por Privacidade	Avalia obrigações de notificação LGPD, notifica ANPD se necessário

Contatos de emergência

[REVISAR] — Preencher com contatos reais da equipe:

Papel	Nome	Contato principal	Contato alternativo
Coordenador do Incidente	`[Nome]`	`[Telefone/WhatsApp]`	`[E-mail]`
Responsável Técnico	`[Nome]`	`[Telefone/WhatsApp]`	`[E-mail]`
DPO	`[Nome]`	`[E-mail]`	`[Telefone]`

5. Ciclo de Vida do Incidente

```

DETECÇÃO → TRIAGEM → CONTENÇÃO → ERRADICAÇÃO → RECUPERAÇÃO → PÓS-INCIDENTE

```

6. Fase 1 — Detecção e Triagem

6.1 Fontes de detecção

Alertas automáticos de monitoramento

Relato da equipe interna

Relato de Cliente ou usuário

Relato externo via Política de Divulgação Responsável

Notificação de subprocessador ou parceiro

6.2 Triagem inicial (primeiros 30 minutos)

1. Registrar o incidente com data/hora, fonte e descrição inicial;

2. Classificar a severidade (P1–P4) com base nos critérios da seção 3;

3. Notificar o Coordenador do Incidente;

4. Para P1/P2: convocar a equipe de resposta imediatamente;

5. Para P3/P4: atribuir responsável e definir prazo.

6.3 Registro do incidente

Criar entrada no registro de incidentes (documento/planilha dedicada) com:

ID único do incidente (INC-YYYYMMDD-NNN)

Data e hora de detecção

Severidade inicial

Descrição do evento

Sistemas/dados potencialmente afetados

Fonte da detecção

Responsável pelo incidente

7. Fase 2 — Contenção

7.1 Princípios

Preservar evidências antes de qualquer ação (tirar snapshot, copiar logs);

Não apressar a limpeza em detrimento da investigação;

Isolar sistemas comprometidos sem necessariamente desligá-los.

7.2 Ações de contenção por tipo

Acesso não autorizado a conta:

Invalidar todas as sessões ativas do usuário afetado

Resetar credenciais comprometidas

Revogar tokens de API associados

Bloquear IP de origem (se identificado)

Comprometimento de servidor:

Isolar o container/serviço afetado da rede

Fazer snapshot do estado atual para investigação

Redirecionar tráfego para sistema de backup (se disponível)

Alterar imediatamente todas as credenciais que possam ter sido expostas

Vazamento de dados:

Identificar o vetor e bloqueá-lo

Determinar quais dados foram acessados e por quem

Registrar timestamp e escopo da exposição

Vulnerabilidade descoberta (não explorada):

Avaliar se pode ser explorada imediatamente

Implementar mitigação temporária (WAF, rate limit, feature flag)

Planejar correção definitiva

7.3 Evidências a preservar

Logs do servidor (access, error, application)

Logs do banco de dados (se configurado)

Snapshots de containers

Registros de rede/tráfego

Timestamps precisos de eventos

8. Fase 3 — Erradicação e Recuperação

8.1 Erradicação

Após a contenção, eliminar a causa raiz:

Corrigir a vulnerabilidade explorada

Remover artefatos maliciosos

Atualizar componentes vulneráveis

Revisar e corrigir configurações inadequadas

Validar a correção em ambiente de teste antes de produção

8.2 Recuperação

Restaurar serviços a partir de backup limpo (se necessário)

Validar a integridade dos dados

Monitorar de perto por 48–72h após a recuperação

Confirmar que o vetor de ataque foi eliminado

Comunicar o fim do incidente internamente

8.3 Validação pós-recuperação

Verificar autenticação e autorização funcionando corretamente

Verificar que logs e alertas estão ativos

Confirmar que não há outros indicadores de comprometimento

Realizar varredura básica de segurança

9. Fase 4 — Comunicação

9.1 Comunicação interna

Atualizações a cada 1–2 horas durante incidentes P1/P2

Canal dedicado (chat interno) para coordenação durante o incidente

Sem comunicação pública não autorizada por membros da equipe

9.2 Comunicação com Clientes afetados

Quando notificar: sempre que houver acesso não autorizado a dados pessoais de Clientes.

Prazo: em até 72 horas da confirmação do incidente, conforme orientações da ANPD. [REVISAR]

Conteúdo mínimo da notificação ao Cliente:

O que aconteceu (descrição clara, sem jargão técnico)

Quando aconteceu (ou quando identificamos)

Quais dados foram afetados

O que estamos fazendo

O que o Cliente deve fazer (se aplicável)

Como entrar em contato para dúvidas

Canal: e-mail direto para o administrador da conta afetada.

9.3 Comunicação pública (se necessário)

Apenas o Coordenador do Incidente ou porta-voz designado fala publicamente

Nenhuma especulação; apenas fatos confirmados

Atualização da página de status (se houver) [REVISAR]

10. Fase 5 — Pós-Incidente

10.1 Relatório pós-incidente (RCA — Root Cause Analysis)

Elaborar em até 5 dias úteis após o encerramento do incidente:

1. Linha do tempo completa do incidente

2. Causa raiz identificada

3. Impacto (dados, sistemas, Clientes afetados)

4. Ações tomadas durante a resposta

5. Lições aprendidas

6. Plano de melhoria com ações corretivas e datas

10.2 Atualização do plano

Revisar e atualizar este plano com base nas lições aprendidas de cada incidente significativo.

10.3 Encerramento formal

Confirmar encerramento com todos os envolvidos

Atualizar registro do incidente com resolução final

Comunicar encerramento aos Clientes afetados (quando aplicável)

11. Notificação à ANPD

11.1 Quando notificar

A LGPD exige notificação à ANPD e aos titulares afetados quando houver incidente de segurança que possa acarretar risco ou dano relevante aos titulares.

[REVISAR] — Verificar as orientações atuais da ANPD sobre:

Prazo exato de notificação

Formato do relato

Portal de notificação da ANPD

11.2 Responsabilidade

Como controlador dos dados de Clientes: o Forms2You é responsável pela notificação;

Como operador dos dados de respondentes de formulários: o Forms2You deve notificar o Cliente (controlador), que então decide sobre a notificação à ANPD.

11.3 Conteúdo da notificação à ANPD

Conforme Art. 48 da LGPD:

Natureza dos dados afetados

Informações sobre os titulares envolvidos

Medidas técnicas e de segurança utilizadas para proteção

Riscos relacionados ao incidente

Medidas adotadas para reverter ou mitigar os efeitos

12. Playbooks por Tipo de Incidente

Playbook A — Credenciais Comprometidas

1. Identificar quais credenciais foram expostas (senha de usuário, API key, DB password, etc.)

2. Revogar/resetar imediatamente todas as credenciais afetadas

3. Invalidar todas as sessões ativas associadas

4. Verificar logs de acesso nas últimas 72h para identificar uso indevido

5. Notificar usuário afetado (Clientes) com instruções de ação

6. Verificar se outras credenciais relacionadas foram expostas

7. Documentar e iniciar RCA

Playbook B — Dados Expostos (Vazamento)

1. Identificar quais dados foram expostos e para quem

2. Bloquear o vetor de exposição imediatamente

3. Quantificar: número de registros, categorias de dados, titulares afetados

4. Preservar logs e evidências

5. Iniciar avaliação de risco (impacto potencial aos titulares)

6. Notificar Clientes afetados em até 72h

7. Avaliar obrigação de notificação à ANPD

8. Documentar e iniciar RCA

Playbook C — Comprometimento de Servidor

1. Isolar o servidor/container da rede (sem desligar se possível — preservar evidências)

2. Fazer snapshot imediato

3. Trocar TODAS as credenciais que o servidor possuía acesso (DB, Redis, APIs, etc.)

4. Verificar se outros sistemas foram acessados a partir do servidor comprometido

5. Restaurar a partir de backup limpo em ambiente isolado

6. Validar a integridade do restore antes de recolocar em produção

7. Investigar o vetor de comprometimento

8. Corrigir antes de reingressar na rede de produção

Playbook D — DDoS / Indisponibilidade

1. Confirmar se é DDoS ou falha técnica (ver logs, métricas)

2. Ativar proteção DDoS (Cloudflare, etc.) se não estiver ativa

3. Identificar IPs ou padrões de ataque

4. Bloquear at origem (firewall, WAF)

5. Comunicar status aos Clientes via página de status [REVISAR]

6. Após mitigação, analisar padrão e fortalecer defesas

13. Ferramentas e Recursos

[REVISAR] — Preencher com ferramentas reais utilizadas:

Tipo	Ferramenta	Acesso
Logs do servidor	`[SSH/Grafana/Loki]`	`[como acessar]`
Logs da aplicação	`[Ferramenta]`	`[como acessar]`
Monitoramento	`[Ferramenta]`	`[como acessar]`
Backup	`[Local/script]`	`[como restaurar]`
Comunicação interna	`[Slack/WhatsApp/etc]`	`[canal]`
Registro de incidentes	`[Planilha/Notion/etc]`	`[link]`
Contato ANPD	Portal gov.br/anpd	`www.gov.br/anpd`

14. Testes e Exercícios

Revisão do plano: anual ou após incidente significativo

Tabletop exercise: simulação de incidente com a equipe (meta: semestral) [REVISAR]

Teste de backup: mensal (ver Runbook de Backup)

Drill de notificação: testar fluxo de notificação de Clientes anualmente

*Documento de uso interno. Manter atualizado e acessível à equipe de resposta em local seguro e de fácil acesso durante emergências.*

Plano de Resposta a Incidentes

Sumário

1. Objetivo