Plano de resposta a incidentes: o runbook que falta

Pergunte a um gestor de TI o que ele faria se descobrisse, agora, que um invasor está dentro da rede. Quase sempre a resposta é técnica e razoável: isolar, olhar os logs, ver o que foi acessado.

Agora pergunte quem autoriza parar o sistema de faturamento. Quem liga para o cliente. Quem fala com a imprensa se vazar. Quem decide se paga o resgate. Em que momento o jurídico entra. Onde está o telefone de emergência do provedor de nuvem.

Esse segundo bloco de perguntas é o plano de resposta a incidentes — e é ele que quase ninguém tem. A parte técnica geralmente é improvisável por gente competente. A parte de decisão, não: ela exige acordos feitos com calma, por pessoas que não estão com o coração acelerado.

A tese em uma frase: o plano de resposta a incidentes não existe para ensinar o time a conter um ataque — existe para que as decisões caras já estejam tomadas quando ninguém tiver condições de tomá-las bem.

O ciclo, e por que a primeira fase decide tudo

O NIST SP 800-61 organiza a resposta em fases: preparação; detecção e análise; contenção, erradicação e recuperação; e atividade pós-incidente. É a referência internacional, e a estrutura vale independentemente do porte.

A observação que costuma passar batida é que só a primeira fase acontece antes do ataque — e a qualidade dela determina o resultado de todas as outras. Preparação não é comprar ferramenta: é decidir papéis, escrever contatos, definir limites de autoridade e ensaiar.

Os cinco papéis de um plano de resposta a incidentes

Numa empresa pequena, uma pessoa acumula dois ou três. O que não pode é o papel não ter nome.

• Coordenador do incidente. Decide, não executa. Prioriza, autoriza, controla o relógio e mantém o registro do que foi decidido e quando. É o papel mais importante e o mais frequentemente esquecido — quando o coordenador é a mesma pessoa que está no teclado, ninguém está olhando o quadro.
• Técnico. Executa contenção e investigação. Precisa de acesso privilegiado já provisionado — descobrir que a senha do firewall está com quem saiu de férias é um clássico.
• Comunicação. Cliente, parceiro, imprensa, time interno. Fala uma versão só, aprovada.
• Jurídico. Avalia obrigações de notificação, orienta preservação de evidência e participa da decisão sobre resgate. Entra no alerta inicial, não depois.
• Patrocinador executivo. Autoriza o que é caro: parar produção, desligar um sistema que fatura, contratar resposta externa de emergência. Sem esse papel definido, o time técnico trava esperando permissão.

O plano de duas páginas

Documento grande não é lido no dia do incidente. Este é o conteúdo mínimo que serve para uma empresa sem equipe de segurança dedicada.

Página 1 — Acionamento

1. Quem é quem. Os cinco papéis, com nome, celular pessoal e um suplente. Celular pessoal porque o corporativo pode estar comprometido ou indisponível.
2. Como acionar. Um canal fora da infraestrutura da empresa. Se o ataque derrubou o e-mail e o chat interno, o plano precisa funcionar mesmo assim — um grupo de mensagens fora do domínio corporativo resolve.
3. Contatos externos. Provedor de nuvem com número de contrato, serviço de MDR ou SOC, advogado, seguradora cyber se houver, e o contato da operadora.
4. Critério de severidade. Três níveis bastam, com exemplos concretos: o que é chamado normal, o que aciona o time e o que acorda a diretoria de madrugada.

Página 2 — As primeiras duas horas

5. Registrar o relógio. Data e hora exatas da detecção e como se chegou a ela. Vira a origem de todos os prazos regulatórios.
6. Conter. Isolar host, revogar sessões, trocar credenciais privilegiadas, cortar integração suspeita.
7. Preservar. Não apagar log, não formatar, não "limpar para voltar rápido". A pressa de restaurar destrói a evidência que explicaria como evitar a repetição.
8. Comunicar internamente. Uma mensagem, aprovada, para o time — senão a versão que circula é a do corredor.
9. Avaliar obrigação de notificar. É aqui que a régua legal entra, e ela merece leitura própria no post sobre notificação de incidente.

As decisões que precisam estar tomadas antes

Quatro perguntas que ninguém consegue responder bem sob pressão. Decida com calma, registre, e comunique a quem precisa saber.

1. Quando paramos a produção? Qual sistema pode ser desligado por decisão do técnico, qual exige o patrocinador e qual não pode parar em hipótese alguma. Sem esse limite definido, ou o time trava esperando autorização, ou desliga algo caro sem mandato.

2. Pagamos resgate? A posição técnica de todos os CERTs é não pagar — não garante recuperação, financia a próxima campanha e marca a empresa como pagadora. O tema está no post sobre ransomware. O ponto aqui é outro: essa decisão precisa estar tomada e registrada antes, com o conselho ciente. Decidir isso com o sistema parado e o relógio correndo é como escolher seguro durante o acidente.

3. O que contamos e quando? Comunicar cedo e errado gera pânico e retratação; comunicar tarde destrói confiança de forma permanente. Ter um texto-base com lacunas resolve 80% do problema.

4. Quem pode falar em nome da empresa? Uma pessoa. As outras encaminham. Duas versões públicas diferentes valem mais dano do que o incidente.

O exercício de mesa

É a prática de maior retorno em segurança e a que quase ninguém faz. Uma hora, uma sala, zero sistema tocado.

O formato: alguém lê um cenário em voz alta e vai revelando fatos aos poucos. As pessoas dizem o que fariam. Alguém anota o que travou.

Um cenário que costuma render:

São 22h de uma sexta. O gerente financeiro liga dizendo que não consegue abrir os arquivos do compartilhamento — todos com uma extensão estranha. Existe um arquivo de texto na pasta com um endereço de e-mail. O servidor de arquivos ainda responde. Ninguém sabe se o backup da noite rodou.

O que aparece nesse exercício, quase sempre:

• Ninguém sabe quem tem autoridade para desligar o servidor.
• Ninguém sabe se o backup restaura — só que ele "roda".
• O contato do fornecedor está num e-mail que talvez esteja comprometido.
• Ninguém pensou em avisar o cliente até alguém perguntar.

Cada um desses buracos custou uma hora para descobrir e custaria dias no incidente real.

O que precisa existir antes do plano

Um plano de resposta não conserta ausência de base. Três pré-requisitos:

• Backup 3-2-1 testado. Restauração ensaiada, não configurada. E cópia imutável ou offline, porque ransomware moderno procura o backup primeiro.
• RPO e RTO definidos. Quanto dado você aceita perder e em quanto tempo precisa voltar. Sem esses dois números, "restaurar rápido" não quer dizer nada.
• Telemetria existindo. Se os sistemas não geram log ou ninguém os retém, a fase de análise não acontece. Um SIEM ajuda, mas o mínimo é reter o que já existe.

Por que isso vai deixar de ser opcional

Vale registrar o contexto regulatório. O Marco Legal da Cibersegurança caminha para exigir de operadores de infraestrutura crítica exatamente o que este post descreve — e a exigência escorre pela cadeia de fornecimento via contrato. Quem vende para banco, operadora, hospital ou concessionária vai receber essa cláusula na próxima renovação.

Além disso, a Resolução CD/ANPD nº 15/2024 já obriga a manter registro de incidentes por cinco anos, inclusive dos que não foram comunicados. Registro exige processo. Processo exige plano.

O ponto que fica

A parte difícil de um incidente de segurança não é técnica. É que ele acontece no pior horário possível, com informação incompleta, e exige decisões caras de pessoas que estão assustadas.

O plano não elimina nada disso. Ele apenas move as decisões para um dia em que todo mundo está calmo — e deixa, para a noite do incidente, só a execução.

Duas páginas, cinco nomes, quatro decisões e uma hora de ensaio por ano. É o investimento de melhor retorno em segurança, e o único que não depende de orçamento.