O tempo entre detectar um incidente de segurança e contê-lo de fato é um dos fatores que mais influencia o custo final do problema para a empresa. Não é a existência do incidente que determina o estrago, é a velocidade e a ordem das decisões tomadas nas primeiras horas. E é justamente nesse ponto que a maioria das empresas brasileiras falha, mesmo aquelas que já sabem, em tese, que deveriam estar preparadas.
Saber que um incidente pode acontecer é diferente de saber exatamente o que fazer quando ele acontece. A maior parte das empresas de pequeno e médio porte não tem um roteiro escrito com a sequência literal de ações, responsáveis e decisões dos primeiros minutos e das primeiras horas. O resultado é improviso: alguém desliga um servidor por impulso, outro manda um e-mail alarmante para todos os clientes antes de confirmar o que realmente aconteceu, e a liderança perde tempo decidindo quem deveria estar tomando as decisões. Este artigo resolve isso com um runbook concreto, fase por fase, que qualquer empresa pode adaptar e ter pronto antes que precise dele.
O que é um runbook de resposta a incidentes
Um runbook de resposta a incidentes é um documento operacional, não estratégico, que descreve a sequência exata de ações a serem tomadas assim que um incidente de segurança é identificado, com nomes ou papéis responsáveis por cada ação, critérios objetivos de decisão e modelos prontos de comunicação. Ele difere de uma política de segurança ou de um plano de continuidade de negócios porque não trata de princípios gerais, trata do que literalmente se faz, em que ordem, nas primeiras horas críticas.
A utilidade de um runbook está exatamente na sua rigidez controlada: quando um incidente acontece, o nível de estresse da equipe é alto e a capacidade de julgamento cuidadoso cai. Um documento que já define, com antecedência e cabeça fria, quem isola o quê, quem comunica quem e em que ordem, remove a necessidade de inventar um processo no meio da crise. Empresas que testam esse runbook ao menos uma vez por ano, com um exercício simulado, reduzem drasticamente o tempo de reação real quando o incidente é genuíno.
| Fase | Resposta improvisada | Resposta seguindo runbook definido |
|---|---|---|
| Detecção | Incidente é notado por acaso, muitas vezes por reclamação de cliente | Alertas monitorados e critérios claros definem o que caracteriza um incidente confirmado |
| Contenção | Decisões de isolamento tomadas sob pressão, sem critério de priorização | Sistemas críticos isolados segundo ordem pré-definida, minimizando dano colateral |
| Comunicação | Mensagens inconsistentes, informação vaza antes de ser confirmada | Modelos de comunicação prontos, com porta-voz único e sequência definida de públicos |
| Erradicação | Causa raiz não é totalmente eliminada, incidente se repete semanas depois | Investigação estruturada garante que a vulnerabilidade explorada seja de fato corrigida |
| Recuperação | Sistemas voltam ao ar sem verificação, risco de reincidência imediata | Retorno gradual e verificado, com validação de integridade antes da liberação total |
As cinco fases de um runbook de resposta a incidentes
- Detecção e confirmação do incidente: a primeira ação não é reagir, é confirmar que o evento é de fato um incidente de segurança, com critérios objetivos definidos previamente (padrão anômalo de acesso, alerta de antivírus, comportamento incomum de sistema), e registrar hora exata da detecção, que servirá de referência para toda a linha do tempo.
- Contenção imediata: isolar os sistemas afetados da rede, sem necessariamente desligá-los, para preservar evidências e impedir a propagação do problema; esta fase exige que já exista, com antecedência, uma lista de prioridade de quais sistemas isolar primeiro e quem tem autoridade para tomar essa decisão sem esperar aprovação em cascata.
- Comunicação: acionar, em ordem definida, a liderança interna, depois a equipe técnica responsável pela remediação, e só então, quando houver confirmação real dos fatos, comunicar clientes afetados e, quando a natureza do incidente envolver dados pessoais, notificar a ANPD dentro dos prazos aplicáveis; comunicação prematura ou contraditória costuma causar mais dano reputacional do que o próprio incidente.
- Erradicação da causa raiz: identificar e eliminar de fato a vulnerabilidade ou vetor que permitiu o incidente, seja uma credencial comprometida, uma falha de configuração ou um software desatualizado, com verificação técnica de que a causa foi removida, não apenas o sintoma mais visível.
- Recuperação e retorno à operação normal: restaurar sistemas de forma gradual e verificada, com testes de integridade antes de liberar o acesso pleno aos usuários, seguido, dias depois, de um post-mortem documentado, que registra o que aconteceu, o que funcionou no runbook, o que falhou e o que precisa ser ajustado antes do próximo incidente.
A explicação para essa posição está na natureza do problema: ferramentas de segurança técnica (antivírus, firewall, backup) reduzem a probabilidade e a gravidade de um incidente, mas não substituem a coordenação humana no momento em que ele ocorre. Um runbook bem escrito custa pouco para produzir e testar, comparado ao custo de uma resposta desorganizada, que tipicamente envolve retrabalho, comunicação contraditória com clientes, e decisões técnicas tomadas sem critério sob pressão. A diferença entre empresas que se recuperam rápido e empresas que sofrem danos prolongados quase nunca está na sofisticação da tecnologia, está na existência de um roteiro claro e testado antes do problema acontecer.
Vale reforçar que o runbook não precisa nascer perfeito. A primeira versão de um plano de resposta a incidentes costuma ter lacunas, papéis mal definidos ou uma sequência de comunicação que parece boa no papel, mas falha na prática. O que separa empresas bem preparadas não é a perfeição do primeiro rascunho, é a disciplina de revisar o documento após cada simulado ou incidente real, incorporando o que foi aprendido. Um runbook vivo, atualizado a cada ciclo, vale muito mais do que um documento extenso escrito uma única vez e nunca mais revisitado.
Como a Vetor Advisory aplica isso na prática
No trabalho de Governança de TI, a Vetor Advisory constrói o runbook de resposta a incidentes junto com a liderança do cliente, não como um documento genérico adaptado de um template encontrado online. Isso significa mapear os sistemas reais daquela empresa, definir com nomes específicos quem tem autoridade para isolar um servidor, quem é o porta-voz de comunicação e qual a cadeia de decisão quando o responsável principal não está disponível.
O runbook, uma vez criado, só tem valor se for testado. Por isso, o processo inclui pelo menos um exercício simulado por ano, no qual a equipe percorre as cinco fases com um cenário fictício, identifica gargalos reais na comunicação interna e ajusta o documento antes que um incidente genuíno exponha essas falhas na pior hora possível.