O que é resposta a incidentes (IR) e por que playbooks mudam o jogo
Resposta a incidentes (Incident Response, IR) é a capacidade de detectar, conter, erradicar e recuperar-se de eventos de segurança que impactam confidencialidade, integridade ou disponibilidade. Na prática, IR não é “apagar incêndio” de forma improvisada; é executar um conjunto de decisões repetíveis, com critérios claros de acionamento, comunicação e registro, para reduzir impacto e tempo de indisponibilidade, preservar evidências e aprender com o ocorrido.
Playbooks são roteiros operacionais para tipos comuns de incidentes (por exemplo: phishing com credencial vazada, ransomware, vazamento de dados, comprometimento de conta privilegiada). Eles transformam conhecimento tácito em passos verificáveis: o que fazer primeiro, quem acionar, quais evidências coletar, quais sistemas isolar, quais comunicações disparar e quais critérios determinam escalonamento. Um playbook bom não é um documento “bonito”; é um guia executável, testado e atualizado, que qualquer pessoa do time consegue seguir sob pressão.
Um programa de IR pragmático costuma ter três pilares: (1) playbooks e runbooks (passo a passo técnico), (2) acionamento e coordenação (quem decide o quê, quando e como), e (3) lições aprendidas (melhoria contínua com ações concretas e prazos).
Definições práticas: incidente, evento, severidade e impacto
Para evitar confusão e atrasos, use definições simples e operacionais:
Evento: qualquer ocorrência observável (alerta do SIEM, e-mail suspeito, falha de autenticação em massa). Pode ser benigno.
Continue em nosso aplicativo
Você poderá ouvir o audiobook com a tela desligada, ganhar gratuitamente o certificado deste curso e ainda ter acesso a outros 5.000 cursos online gratuitos.
ou continue lendo abaixo...
Baixar o aplicativo
Incidente: evento confirmado (ou altamente provável) com impacto ou risco relevante para o negócio (ex.: conta comprometida, malware ativo, exfiltração suspeita, indisponibilidade causada por ataque).
Severidade: classificação para priorizar resposta (ex.: S1 crítico, S2 alto, S3 médio, S4 baixo). Deve combinar impacto e urgência.
Impacto: efeito no negócio (parada de operação, dados expostos, fraude, multas, reputação).
Uma regra útil: se o time ainda está “investigando se é incidente”, trate como incidente até reduzir incerteza. Isso acelera contenção e preservação de evidências.
Estrutura mínima de um playbook que funciona
Um playbook deve caber em poucas páginas e ser acionável. Estrutura recomendada:
Objetivo e escopo: que tipo de incidente cobre e o que não cobre.
Critérios de acionamento: sinais e gatilhos (alertas, indicadores, relatos) que iniciam o fluxo.
Severidade e SLAs: tempos-alvo para triagem, contenção inicial e atualização de status.
Checklist de triagem: perguntas e verificações iniciais para confirmar e dimensionar.
Ações de contenção: o que isolar, bloquear, desabilitar, segmentar, com critérios de risco operacional.
Coleta e preservação de evidências: o que coletar, como armazenar, cadeia de custódia.
Erradicação e recuperação: remoção da causa, restauração, validações e monitoramento pós-incidente.
Comunicação e escalonamento: quem informar, quando, e modelos de mensagem.
Lições aprendidas: como registrar, quais métricas coletar, como abrir ações corretivas.
Evite playbooks genéricos demais (“investigar logs”). Prefira passos concretos (“consultar logs de autenticação do IdP para o usuário X nas últimas 24h; verificar novos dispositivos; checar regras de encaminhamento no e-mail”).
Passo a passo prático: ciclo de resposta a incidentes
A seguir, um fluxo prático que você pode aplicar a qualquer playbook, ajustando detalhes técnicos conforme o cenário.
1) Detecção e registro inicial
Objetivo: garantir que nada se perca e que exista um “dono” do incidente desde o início.
Registrar o incidente em um sistema de tickets/IR (pode ser simples, desde que rastreável).
Capturar informações mínimas: data/hora, fonte do alerta, sistemas envolvidos, usuário(s), descrição, evidências iniciais (IDs de alerta, e-mails, prints, hashes).
Definir um Incident Commander (IC) para coordenar. Em times pequenos, pode ser o analista de plantão.
Dica operacional: padronize um formulário curto de abertura. Quanto menos fricção, mais consistente será o registro.
2) Triagem e confirmação (Triage)
Objetivo: confirmar se é incidente, estimar severidade e decidir as primeiras ações.
Validar se o alerta é falso positivo (ex.: atividade legítima, teste interno, varredura autorizada).
Determinar o “raio” inicial: quais contas, endpoints, servidores, aplicações e dados podem estar envolvidos.
Classificar severidade com base em critérios objetivos (ex.: dados sensíveis, sistemas críticos, evidência de exfiltração, impacto operacional).
Definir hipótese inicial e próximos passos (ex.: “possível comprometimento de conta via phishing”).
Saída esperada: severidade definida, IC confirmado, plano de 30–60 minutos com ações imediatas.
3) Contenção (curto prazo e longo prazo)
Objetivo: interromper o dano em curso e impedir propagação, equilibrando risco de negócio.
Contenção de curto prazo: ações rápidas para parar o sangramento (bloquear IP/domínio, desabilitar conta, isolar endpoint, revogar sessões, bloquear regra de encaminhamento de e-mail).
Contenção de longo prazo: medidas para manter o ambiente estável enquanto investiga (segmentação, regras temporárias de firewall, bloqueios adicionais, monitoramento reforçado).
Armadilha comum: “desligar tudo” sem avaliar impacto. Em alguns casos, isolar é melhor do que desligar (para preservar evidências e evitar perda de memória/estado). O playbook deve indicar quando desligar é aceitável e quando não é.
4) Preservação e coleta de evidências
Objetivo: permitir análise técnica, suporte a auditoria, e eventualmente suporte jurídico/regulatório.
Definir o que coletar: logs de autenticação, logs de e-mail, EDR, proxy, DNS, firewall, snapshots, dumps de memória (quando aplicável), amostras de malware, artefatos (arquivos, scripts, tarefas agendadas).
Armazenar evidências em local controlado, com acesso restrito e trilha de auditoria.
Registrar cadeia de custódia quando houver possibilidade de uso legal (quem coletou, quando, onde armazenou, hash do arquivo).
Prática recomendada: estabeleça um “kit de evidências” por tipo de incidente (ex.: para ransomware, sempre coletar nota de resgate, extensão de arquivos, processos, conexões, logs de backup, eventos de criação de serviços).
5) Erradicação
Objetivo: remover a causa raiz e os mecanismos de persistência.
Eliminar malware, backdoors, contas criadas indevidamente, chaves/tokens expostos, regras maliciosas (ex.: forwarding no e-mail), tarefas agendadas, serviços suspeitos.
Corrigir a vulnerabilidade explorada ou o vetor (ex.: desabilitar macro, bloquear execução, corrigir configuração, aplicar patch, ajustar política de autenticação).
Buscar sinais de comprometimento adicional (threat hunting direcionado): mesma técnica em outros ativos, indicadores correlatos.
Critério de qualidade: erradicação não é “limpar a máquina”; é garantir que o atacante não consiga voltar pelo mesmo caminho e que não há persistência ativa.
6) Recuperação e retorno seguro à operação
Objetivo: restaurar serviços com confiança e monitorar recaídas.
Restaurar a partir de backups confiáveis ou imagens limpas, validando integridade.
Reabilitar contas e acessos com credenciais redefinidas, revogação de tokens e sessões, e validação de MFA.
Executar testes de sanidade: funcionalidade, performance, logs sem anomalias, ausência de indicadores.
Ativar monitoramento reforçado por um período (ex.: 7–14 dias) para detectar retorno do atacante.
Exemplo: após comprometimento de conta, além de resetar senha, revogue sessões ativas, revise regras de e-mail, valide dispositivos confiáveis e revise permissões concedidas recentemente.
7) Comunicação, status e coordenação
Objetivo: manter alinhamento e reduzir ruído, com mensagens consistentes e no tempo certo.
Definir cadência de status conforme severidade (ex.: S1 a cada 30–60 min; S2 a cada 2–4h).
Separar canais: um canal para coordenação técnica e outro para status executivo.
Controlar o que é fato, hipótese e ação em andamento. Evitar especulação.
Modelo simples de update (para uso interno): “O que aconteceu (fatos) / Impacto atual / O que foi feito / Próximos passos / Riscos e bloqueios”.
Acionamento: como decidir rápido sem criar caos
Acionamento é o mecanismo que coloca as pessoas certas na sala no momento certo. Sem isso, incidentes viram “pingue-pongue” entre times. Um modelo prático combina: gatilhos, matriz de escalonamento e papéis no war room.
Gatilhos de acionamento (exemplos)
Sinais de exfiltração: volume anormal de upload, conexões para destinos raros, alertas de DLP, logs de download massivo.
Comprometimento de identidade: login impossível (impossible travel), MFA fatigue, criação de regras de forwarding, concessão de consentimento OAuth suspeito.
Ransomware: arquivos criptografados, processos de criptografia, nota de resgate, desativação de serviços de backup.
Indisponibilidade suspeita: picos de tráfego, falhas em serviços críticos com indicadores de ataque.
Matriz de escalonamento (quem acionar)
Defina por severidade e tipo de incidente. Exemplo de regra:
S1 (crítico): acionar imediatamente liderança de TI/Segurança, dono do sistema afetado, time de infraestrutura, comunicação corporativa/PR (se houver risco reputacional), jurídico/privacidade (se houver dados pessoais), e gestão de continuidade (se houver impacto operacional).
S2 (alto): acionar dono do sistema, segurança, suporte/infra, e privacidade conforme dados envolvidos. Liderança informada em janela curta (ex.: até 2h).
S3/S4: tratar no time técnico com comunicação sob demanda.
O playbook deve deixar explícito: “Se X acontecer, acione Y em até Z minutos”. Isso reduz dependência de experiência individual.
War room: papéis essenciais durante o incidente
Incident Commander (IC): coordena, prioriza, decide escalonamentos, mantém linha do tempo.
Líder técnico: conduz investigação e ações técnicas, delega tarefas.
Responsável por comunicações: prepara updates internos, alinha mensagens, evita vazamento de informação.
Responsável por evidências: garante coleta, armazenamento e registro.
Dono do serviço: decide trade-offs de disponibilidade e mudanças emergenciais.
Mesmo em empresas pequenas, vale “nomear chapéus” para evitar que todos façam tudo ao mesmo tempo.
Playbooks essenciais (com exemplos de passos)
Playbook 1: Phishing com credencial comprometida
Critérios de acionamento: usuário reporta phishing e clicou; alertas de login anômalo; criação de regra de encaminhamento; envio de e-mails em massa.
Passos práticos:
Confirmar usuário, horário, e-mail suspeito e URL; coletar cabeçalhos do e-mail.
Revogar sessões ativas e tokens; resetar senha; garantir MFA ativo.
Verificar regras de forwarding, delegações e caixas compartilhadas; remover alterações suspeitas.
Checar envios recentes e atividade de caixa de saída; conter envio de spam/phishing interno.
Buscar outros usuários que receberam o mesmo e-mail (campanha) e aplicar bloqueios (domínio/URL/hash).
Se houver acesso a dados sensíveis, elevar severidade e iniciar avaliação de exposição.
Playbook 2: Ransomware em endpoint/servidor
Critérios de acionamento: alertas do EDR, arquivos criptografados, nota de resgate, processos suspeitos, desativação de backups.
Passos práticos:
Isolar imediatamente o host da rede (sem desligar, salvo orientação do playbook); bloquear comunicação lateral.
Identificar “paciente zero”: primeiro host com sinais; mapear propagação por logs e EDR.
Preservar evidências: amostras, processos, conexões, eventos de criação de serviços, contas usadas.
Validar integridade e disponibilidade de backups; impedir que backups sejam sobrescritos.
Erradicar persistência e credenciais comprometidas (reset de contas privilegiadas envolvidas).
Recuperar a partir de backups confiáveis; validar antes de reconectar à rede.
Ponto de decisão: se houver evidência de exfiltração, tratar também como incidente de vazamento (com acionamento de privacidade/jurídico conforme aplicável).
Playbook 3: Vazamento de dados (suspeita de exfiltração)
Critérios de acionamento: alertas de DLP, tráfego anômalo, credenciais de API expostas, repositório público com dados, bucket/compartilhamento aberto.
Passos práticos:
Conter: revogar chaves/tokens, fechar permissões públicas, bloquear destinos, suspender integrações suspeitas.
Determinar escopo: quais dados, período, volume, e quem acessou/baixou.
Preservar logs e evidências de acesso; registrar linha do tempo.
Classificar tipo de dado e obrigações internas/legais (sem entrar em pânico; trabalhar com fatos).
Definir plano de comunicação interna e, se necessário, externa, com mensagens aprovadas.
Runbooks técnicos: quando o playbook precisa de “como fazer”
Playbook diz “o que” e “quando”. Runbook detalha “como” executar em ferramentas específicas. Exemplo: o playbook manda “revogar sessões do usuário”; o runbook ensina o caminho no provedor de identidade, quais comandos/API usar, e como registrar evidência.
Boas práticas para runbooks:
Incluir pré-requisitos (permissões necessárias, acesso de emergência, contas break-glass).
Incluir comandos/consultas prontas e exemplos de saída esperada.
Incluir “rollback” quando houver risco (ex.: bloqueio de IP que pode afetar clientes).
Incluir onde anexar evidências (prints, export de logs, IDs de alertas).
Lições aprendidas: transformar incidente em melhoria real
Lições aprendidas não é uma reunião para “apontar culpados”. É um processo curto e objetivo para capturar o que falhou, o que funcionou e o que precisa mudar. O valor aparece quando isso vira backlog priorizado e executado.
Quando fazer e quem participa
Agendar em até 3–10 dias após estabilização (memória ainda fresca, sem atrapalhar recuperação).
Participantes mínimos: IC, líder técnico, dono do serviço, alguém de operações/infra, e quem cuidou de comunicação/evidências. Incluir privacidade/jurídico se houve dados sensíveis.
Roteiro prático da reunião (60–90 minutos)
Linha do tempo: do primeiro sinal até a recuperação. Marcar tempos de detecção, triagem, contenção, erradicação e retorno.
O que funcionou: decisões rápidas, ferramentas úteis, comunicação eficiente, automações.
O que não funcionou: atrasos, falta de acesso, playbook incompleto, ruído de comunicação, falhas de monitoramento.
Causa raiz e causas contribuintes: separar “vetor inicial” (como entrou) de “amplificadores” (por que espalhou/impactou mais).
Ações corretivas: lista com dono, prazo e critério de aceite (o que prova que foi resolvido).
Exemplos de ações corretivas bem definidas
“Implementar bloqueio de regras de encaminhamento externo por padrão; exceções via aprovação; evidência: política aplicada e teste com usuário piloto.”
“Criar detecção para criação de consentimento OAuth de alto risco; evidência: regra no SIEM com alerta testado em ambiente controlado.”
“Reduzir tempo de revogação de sessão: runbook com passo a passo e automação; evidência: simulação mostra revogação em menos de 10 minutos.”
“Aprimorar restauração: teste mensal de restore do sistema X; evidência: relatório de teste com RTO/RPO medidos.”
Métricas de resposta a incidentes que ajudam (sem burocracia)
Métricas devem orientar melhoria e investimento, não virar relatório vazio. Um conjunto enxuto:
MTTD (Mean Time to Detect): tempo médio para detectar.
MTTC (Mean Time to Contain): tempo médio para conter.
MTTR (Mean Time to Recover/Respond): tempo médio para recuperar/responder.
% incidentes com playbook seguido: aderência e utilidade do material.
% incidentes com evidências completas: qualidade de investigação.
Ações corretivas concluídas no prazo: se lições aprendidas estão virando mudança real.
Use essas métricas por tipo de incidente e severidade. Um ransomware e um phishing não devem ser comparados diretamente.
Simulações e testes de mesa (tabletop): como validar playbooks
Playbook só é confiável quando testado. O tabletop é uma simulação guiada, sem mexer em produção, focada em decisões e comunicação.
Passo a passo de um tabletop eficiente
Escolher um cenário realista (ex.: “conta do financeiro comprometida e envio de e-mails para fornecedores”).
Definir objetivos: testar acionamento, decisões de contenção, comunicação, evidências.
Rodar em 45–90 minutos com injeções de eventos (“agora apareceu login de outro país”, “agora há regra de forwarding”).
Registrar gaps: falta de acesso, dúvidas de responsabilidade, passos ausentes no playbook.
Gerar ações corretivas com dono e prazo; atualizar playbook/runbook.
Uma cadência prática: 1 tabletop por trimestre para cenários críticos, alternando tipos de incidente.
Modelos prontos (para copiar e adaptar)
Template de playbook (estrutura)
Playbook: [Nome do incidente] Versão: [x.y] Dono: [time/pessoa] Última revisão: [data] Severidade típica: [S1/S2/...]
1) Critérios de acionamento
- [Gatilho 1]
- [Gatilho 2]
2) Triagem (primeiros 30 min)
- Confirmar: [itens]
- Escopo inicial: [itens]
- Evidências iniciais: [itens]
3) Contenção
- Curto prazo: [ações]
- Longo prazo: [ações]
- Critérios para escalonar para S1: [itens]
4) Evidências
- Coletar: [logs/artefatos]
- Armazenar em: [local]
5) Erradicação
- Remover: [itens]
- Corrigir vetor: [itens]
6) Recuperação
- Restaurar: [passos]
- Validar: [testes]
- Monitorar por: [período]
7) Comunicação
- Atualização interna: [cadência]
- Stakeholders: [lista]
8) Lições aprendidas
- Agendar até: [prazo]
- Métricas a registrar: [lista]Template de linha do tempo do incidente
Incidente: [ID] Severidade: [Sx]
[hh:mm] Detecção: [fonte/alerta]
[hh:mm] IC designado: [nome]
[hh:mm] Contenção inicial: [ação]
[hh:mm] Evidência coletada: [o quê/onde]
[hh:mm] Hipótese atualizada: [texto]
[hh:mm] Erradicação iniciada: [ação]
[hh:mm] Recuperação: [ação]
[hh:mm] Serviço normalizado: [critério]
Impacto:
- [sistemas]
- [usuários]
- [dados]
Decisões-chave:
- [decisão] — motivo — aprovador
