Plano de resposta a incidentes de segurança: guia prático

Uma sexta-feira à tarde, o financeiro recebe a ligação de um cliente: ele recebeu um boleto com os dados corretos do pedido, mas com outra conta para pagamento. Em seguida aparece um segundo caso. Alguém sugere trocar todas as senhas, outro quer tirar o sistema do ar, um terceiro já está apagando usuários estranhos do painel. Na segunda-feira, ninguém sabe dizer quais dados saíram, desde quando, nem o que contar aos clientes.

O problema raramente é falta de boa vontade. É falta de roteiro. Sem um plano combinado antes, cada pessoa reage do jeito que acha certo, as ações se atropelam e as evidências que responderiam "o que aconteceu" somem no meio da faxina.

Um plano de resposta a incidentes de segurança é esse roteiro: um documento curto, combinado antes, que diz quem decide, como conter o ataque sem apagar pistas, o que investigar e como avisar clientes e autoridade. Este texto mostra como montar um plano enxuto, que cabe numa empresa média sem equipe de segurança dedicada, e o que o sistema precisa registrar para que, no dia ruim, seja possível dizer com precisão o que foi acessado.

O plano em uma página

Se você só tiver tempo para uma coisa, comece por aqui. Um plano de resposta a incidentes funcional responde seis perguntas, por escrito, antes de qualquer incidente:

1. Quem decide. Uma pessoa nomeada (e um substituto) com autoridade para tirar um sistema do ar, acionar fornecedores e aprovar comunicados.
2. Como o alerta chega. Por quais canais um sinal de problema é reportado e quem o recebe, inclusive fora do horário comercial.
3. Como classificar. Critérios simples para separar o que é incidente grave do que é ruído.
4. Como conter. Ações pré-aprovadas para isolar o problema sem destruir o que vai ser investigado.
5. Como comunicar. Quem fala com clientes, titulares de dados, autoridade e imprensa, e quem não fala.
6. Como encerrar. Registro do que aconteceu, correções feitas e o que muda no sistema e no processo.

O resto deste texto detalha cada parte. O documento final não precisa passar de poucas páginas; o que importa é estar acessível fora do sistema afetado (se o plano mora no servidor comprometido, ele não existe) e ter sido lido pelas pessoas citadas nele.

Por que o improviso piora o incidente

No improviso, três erros se repetem.

Apagar antes de entender. Excluir o usuário invasor, reinstalar o servidor ou restaurar o backup parece responsável, mas elimina a pista de como o atacante entrou. Se a porta de entrada continua aberta, ele volta.

Conter tarde ou conter demais. Sem critério combinado, a empresa ou demora horas discutindo se desliga o sistema, ou derruba tudo e para a operação inteira por um problema que afetava um módulo.

Comunicar no susto. Um e-mail apressado, com informação errada, cria um segundo problema: corrigir o comunicado.

Papéis: quem decide, quem age, quem comunica

Em empresa pequena, a mesma pessoa pode acumular papéis. O que não pode é o papel ficar sem dono.

Dois detalhes que fazem diferença:

• Contatos fora do sistema. Telefones pessoais dos envolvidos, do fornecedor de hospedagem, do suporte da plataforma e do jurídico, numa lista impressa ou guardada fora do ambiente da empresa. Se o e-mail corporativo foi comprometido, ele não serve para coordenar a resposta.
• Fornecedor no plano. Se o sistema é mantido por terceiros, o contrato deveria dizer em quanto tempo eles atendem um incidente de segurança e o que entregam (logs, relatório, correção). Descobrir isso no dia é tarde.

Detectar: alertas e sinais de comprometimento

Boa parte dos incidentes é descoberta por quem está de fora: um cliente, um banco, um parceiro. Quanto mais cedo a própria empresa percebe, menor o estrago. Sinais que merecem alerta automático:

• Logins fora do padrão. Acesso de madrugada, de outro país ou de vários lugares ao mesmo tempo com o mesmo usuário; sequências de senhas erradas seguidas de um acerto.
• Volume anormal de leitura. Um usuário que costuma ver dez fichas de cliente por dia exportando a base inteira.
• Mudanças sensíveis. Criação de usuário administrador, alteração de dados bancários de fornecedor ou de chave Pix de recebimento, desativação de autenticação em dois fatores.
• Comportamento da infraestrutura. Processos desconhecidos, tráfego de saída incomum, arquivos sendo renomeados ou criptografados em massa.
• Relatos externos. Clientes recebendo cobranças falsas com dados reais, credenciais da empresa aparecendo em listas vazadas.

Alertas só funcionam se alguém olha. Defina para onde vão e evite o excesso: alerta que dispara toda hora é ignorado no dia em que importa. A base técnica para isso está em observabilidade com logs, métricas e traces.

Como classificar a gravidade

Uma escala de três níveis resolve na maioria das empresas:

• Baixo: tentativa bloqueada, sem acesso a dados. Registra e acompanha.
• Médio: acesso indevido confirmado a um sistema, sem indício de dados pessoais ou financeiros expostos. Aciona o responsável técnico e o coordenador.
• Alto: dados pessoais, financeiros ou sigilosos possivelmente expostos, ou operação parada. Aciona todos os papéis, inclusive jurídico e comunicação.

Na dúvida entre dois níveis, trate pelo mais alto e rebaixe depois. O contrário costuma custar caro.

Conter sem destruir evidências

Conter é impedir que o problema se espalhe. Investigar é entender o que aconteceu. As duas coisas precisam acontecer juntas, e a ordem das ações importa.

Passo a passo da contenção

1. Abra a linha do tempo. Antes de mexer em qualquer coisa, anote horário, quem detectou, o que foi visto. Tudo o que vier depois entra nesse registro.
2. Preserve antes de limpar. Tire cópia dos logs do período, gere uma cópia instantânea (snapshot) dos servidores e bancos afetados, salve e-mails suspeitos com cabeçalho completo. Guarde essas cópias num local com acesso restrito e fora do ambiente comprometido.
3. Isole em vez de apagar. Bloqueie o usuário suspeito em vez de excluí-lo; retire o servidor da rede em vez de desligá-lo ou reinstalá-lo; revogue a chave de API em vez de apagar a integração.
4. Corte o acesso do invasor. Troque senhas e chaves das contas envolvidas, encerre sessões ativas, revogue tokens. Comece pelas contas com mais poder.
5. Mantenha o essencial rodando, se for seguro. Se o problema está em um módulo, isole o módulo. Derrubar a operação inteira é decisão do coordenador, não do primeiro técnico que chegar.
6. Só então corrija e restaure. Feche a porta de entrada, aplique a correção e, se necessário, restaure a partir de um backup que você sabe ser anterior ao comprometimento.

O último passo depende de backups confiáveis e testados. Se o incidente for um sequestro de dados (ransomware), a resposta se encontra com o plano de recuperação de desastres: o backup precisa existir, estar isolado e ter sido restaurado antes, em teste.

Logs que respondem o que foi acessado

Esta é a parte em que o sistema decide se a empresa vai conseguir responder à pergunta mais importante do incidente: quais dados, de quem, foram acessados ou alterados, e quando.

Sem registro adequado, a resposta honesta é "não sabemos". E "não sabemos" geralmente obriga a tratar o incidente como se todos os dados de todos os clientes tivessem sido expostos.

O que o sistema precisa registrar

Algumas regras para que esse registro sirva no dia do incidente:

• O log não pode conter o dado sensível. Registre o identificador do cliente consultado, não o CPF e o endereço completos. Um log cheio de dados pessoais vira, ele mesmo, um alvo.
• O log precisa estar fora do alcance de quem é auditado. Se um administrador comprometido consegue apagar os registros, eles não provam nada. Envie os logs para um armazenamento separado, com retenção definida e sem permissão de exclusão para usuários comuns do sistema.
• Relógio sincronizado. Servidores com horários diferentes tornam a reconstrução da linha do tempo um quebra-cabeça.
• Retenção compatível com a descoberta. Muitos incidentes são percebidos semanas depois do início. Log guardado só por poucos dias não alcança a origem.

O desenho de perfis e da trilha de auditoria está detalhado em controle de acesso e trilha de auditoria. E as demais obrigações de privacidade que o software precisa suportar, como mapeamento dos dados pessoais e minimização, aparecem em LGPD no desenvolvimento de sistemas.

Comunicação com clientes e titulares

Quando dados pessoais estão envolvidos, a LGPD exige que o controlador comunique à Autoridade Nacional de Proteção de Dados (ANPD) e aos titulares os incidentes que possam causar risco ou dano relevante. O Regulamento de Comunicação de Incidente de Segurança da ANPD (Resolução CD/ANPD nº 15/2024) fixa prazo curto, de três dias úteis a partir do momento em que a empresa sabe que o incidente afetou dados pessoais, e define o conteúdo mínimo da comunicação. As regras podem ser atualizadas e a aplicação depende do caso: a avaliação de quando e como comunicar deve ser feita com o encarregado de dados e o jurídico. O papel do plano é garantir que essa avaliação comece cedo, não no último dia.

Para o lado prático, o que acelera a comunicação é ter as informações prontas:

• O que aconteceu, em linguagem simples, sem jargão técnico.
• Quais dados foram afetados (nome, e-mail, CPF, dados financeiros), e de quantos titulares, se for possível saber.
• O que a empresa já fez para conter e corrigir.
• O que o titular deve fazer: desconfiar de cobranças, trocar senha, conferir dados bancários antes de pagar.
• Um canal para dúvidas, com alguém preparado para atender.

Deixe modelos de comunicado prontos, revisados pelo jurídico, para os cenários mais prováveis: vazamento de cadastro, acesso indevido a conta de cliente, fraude de boleto ou Pix. No dia, basta preencher e revisar.

Internamente, combine uma regra simples: só fala sobre o incidente quem está no papel de comunicação. Vendedor que comenta com o cliente "parece que hackearam a gente" desmonta qualquer comunicado cuidadoso.

Lições aprendidas e correções

Incidente fechado sem revisão tende a se repetir. Em até duas semanas depois do encerramento, reúna os envolvidos para uma revisão sem caça a culpados. O foco é o processo e o sistema, não a pessoa que clicou no link.

Perguntas da revisão:

• Como o atacante entrou, e por que isso era possível?
• Quanto tempo passou entre o início e a detecção? O que teria encurtado esse tempo?
• O plano foi seguido? Em que ponto ele falhou ou faltou?
• Os logs responderam o que foi acessado? O que faltou registrar?
• A comunicação foi clara e no prazo?

Cada resposta vira uma ação com dono e data: ativar autenticação em dois fatores para todo o painel administrativo, registrar exportações que hoje não são registradas, revisar permissões de integração, ajustar o próprio plano.

Checklist para montar o plano

• Coordenador do incidente e substituto nomeados, com autoridade por escrito.
• Lista de contatos guardada fora dos sistemas da empresa.
• Contrato com fornecedores definindo prazo de atendimento e entrega de logs em incidente.
• Alertas automáticos para login suspeito, exportação em massa e mudança de dado bancário.
• Critério de gravidade em três níveis, conhecido pela equipe técnica.
• Procedimento de preservação de evidências antes da limpeza.
• Logs de acesso e alteração em armazenamento separado, com retenção definida.
• Backups isolados e testados por restauração.
• Modelos de comunicado revisados pelo jurídico.
• Simulação do plano pelo menos uma vez, com um cenário realista.

A simulação é o item mais ignorado. Uma hora percorrendo um cenário fictício revela contato desatualizado, log inexistente e decisão sem dono antes que custem caro.

Perguntas frequentes

Qual o prazo para comunicar um incidente de segurança à ANPD?

Pelo Regulamento de Comunicação de Incidente de Segurança da ANPD, o prazo é de três dias úteis a partir do momento em que a empresa sabe que o incidente afetou dados pessoais, quando houver risco ou dano relevante aos titulares. As regras podem mudar, por isso a avaliação deve começar cedo, com o encarregado de dados e o jurídico.

Qual a diferença entre plano de resposta a incidentes e plano de recuperação de desastres?

O plano de resposta a incidentes trata de ataques e acessos indevidos: quem decide, como conter sem apagar evidências, o que investigar e como comunicar. O plano de recuperação de desastres trata de voltar a operar depois de perda de dados ou de infraestrutura, com backup e restauração testados. Num ransomware, os dois são acionados juntos.

Empresa pequena precisa de plano de resposta a incidentes?

Precisa, e ele pode ser curto. Numa empresa pequena, a mesma pessoa acumula papéis, mas cada papel precisa ter dono: quem decide, quem age, quem comunica. Um plano de resposta a incidentes de poucas páginas, guardado fora dos sistemas da empresa e lido pelas pessoas citadas, já evita boa parte dos erros do improviso.

De quanto em quanto tempo revisar o plano de resposta a incidentes?

Sempre que mudar algo que o plano cita: pessoas, contatos, fornecedores ou sistemas. Também depois de cada incidente real, na revisão de lições aprendidas, e depois de cada simulação. Uma simulação periódica com um cenário realista é a forma mais barata de descobrir contato desatualizado, log inexistente e decisão sem dono.

Como a Pervian Tech trabalha resposta a incidentes

Na Pervian Tech, resposta a incidentes faz parte do trabalho de arquitetura de software. Começamos pelo sistema: mapeamos onde estão os dados pessoais e financeiros, verificamos o que hoje é registrado e o que faltaria para responder "o que foi acessado", e desenhamos a trilha de auditoria, os alertas e o isolamento dos logs. Em paralelo, ajudamos a montar o plano em uma página, com papéis, critérios de gravidade e passo a passo de contenção adaptados à realidade da empresa.

Cada empresa tem sistemas, fornecedores e riscos diferentes, então o trabalho é sob medida e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito. Para mais conteúdo do tema, veja a categoria Segurança e LGPD. Se hoje a sua empresa não saberia dizer quais dados foram expostos num incidente, vamos conversar.