Construindo Playbooks de Resposta a Incidentes
Quando Usar
- Estabelecer ou amadurecer um programa de resposta a incidentes do zero
- Documentar procedimentos para um novo tipo de incidente após um ataque inédito
- Automatizar fluxos de resposta em uma plataforma SOAR (Cortex XSOAR, Splunk SOAR)
- Preparar-se para auditorias de compliance que exigem procedimentos de RI documentados (SOC 2, PCI-DSS, HIPAA)
- Realizar uma análise de lacunas das capacidades de RI existentes em relação a cenários de ameaça específicos
Não use para investigações ad hoc únicas; playbooks são documentos de procedimentos reutilizáveis, não relatórios específicos de caso.
Pré-requisitos
- Avaliação de risco organizacional identificando os principais cenários de incidentes por probabilidade e impacto
- Framework NIST SP 800-61r3 ou SANS PICERL adotado como padrão organizacional de RI
- Inventário de ativos com classificações de criticidade de negócios e classificação de dados
- Gráfico RACI definindo funções: Comandante de Incidentes, analistas SOC, administradores de sistemas, jurídico, comunicações
- Inventário de capacidades de detecção existentes (regras SIEM, detecções EDR, assinaturas IDS)
- Acesso à plataforma SOAR se estiver construindo playbooks automatizados
Fluxo de Trabalho
Etapa 1: Selecionar e Escopo do Tipo de Incidente
Defina o cenário específico que o playbook abordará:
- Identifique os principais tipos de incidentes com base na avaliação de risco organizacional e dados históricos
- Escopo cada playbook para um único tipo de incidente para clareza (não combine cenários não relacionados)
- Defina as condições de gatilho que ativam o playbook
Tipos de playbook comuns:
Playbooks Prioritários (construa primeiro):
1. Resposta a incidente de ransomware
2. Comprometimento de phishing/credenciais
3. Comprometimento de e-mail comercial
4. Infecção por malware
5. Violação de dados/exfiltração
6. Ataque DDoS
7. Ameaça interna
8. Tomada de conta
9. Comprometimento de aplicação web
10. Comprometimento de infraestrutura em nuvem
Etapa 2: Definir a Estrutura do Playbook
Todo playbook deve seguir uma estrutura consistente:
TEMPLATE DE PLAYBOOK
━━━━━━━━━━━━━━━━━━━━
1. Metadados do Playbook
- Nome, versão, proprietário, data da última revisão
- Condições de gatilho
- Critérios de severidade
2. Matriz RACI
- Quem é Responsável, Accountable, Consultado, Informado para cada etapa
3. Detecção e Triagem
- Como o incidente é detectado
- Lista de verificação de triagem inicial
- Critérios de classificação de severidade
4. Conteção
- Ações de contenção de curto prazo
- Ações de contenção de longo prazo
- Requisitos de preservação de evidências
5. Erradicação
- Identificação da causa raiz
- Etapas de remoção de malware/ameaça
- Procedimentos de verificação
6. Recuperação
- Etapas de restauração do sistema
- Critérios de validação
- Requisitos de monitoramento pós-recuperação
7. Pós-Incidente
- Gatilho da reunião de lições aprendidas
- Template de relatório
- Ações de melhoria de detecção
8. Comunicação
- Matriz de notificação interna
- Requisitos de notificação externa (reguladores, clientes, aplicação da lei)
- Cadência de atualização de status
9. Apêndices
- Procedimentos específicos de ferramentas
- Listas de contatos
- Listas de verificação de coleta de evidências
Etapa 3: Escrever Árvores de Decisão e Critérios de Escalonamento
Defina pontos de decisão claros com resultados binários:
Alerta de Detecção Recebido
├── O alerta é um verdadeiro positivo?
│ ├── SIM → Classificar severidade
│ │ ├── P1 (Crítico) → Paginar o comandante do incidente, iniciar contenção imediatamente
│ │ ├── P2 (Alto) → Notificar o líder de RI, iniciar investigação em 30 min
│ │ ├── P3 (Médio) → Enfileirar para investigação em 4 horas
│ │ └── P4 (Baixo) → Documentar e investigar em 24 horas
│ └── NÃO → Documentar como falso positivo, ajustar regra de detecção
└── Não é possível determinar → Escalar para Nível 2 para análise mais aprofundada
Gatilhos de escalonamento:
- Qualquer incidente P1: Escalonamento imediato para o líder de RI e CISO
- Exfiltração de dados confirmada: Avisar assessoria jurídica e oficial de privacidade
- Dados de clientes envolvidos: Processo de notificação ao cliente ativado
- Envolvimento de terceiros: Contato de segurança do fornecedor acionado
- Aplicação da lei necessária: Assessoria jurídica geral autoriza antes do contato
Etapa 4: Definir Procedimentos Técnicos Específicos
Escreva instruções específicas da ferramenta para cada etapa (não orientações genéricas):
CONTENÇÃO - Isolamento de Endpoint via CrowdStrike:
1. Abrir Falcon Console > Hosts > Pesquisar hostname afetado
2. Clicar no host > Detalhes do Host
3. Clicar no botão "Conter Host" no canto superior direito
4. Confirmar isolamento (o host se comunicará apenas com a nuvem CrowdStrike)
5. Documentar ação de contenção no ticket de incidente com timestamp
6. Verificar contenção: O host deve exibir o selo de status "Contido"
CONTENÇÃO - Bloquear Domínio C2 no DNS:
1. SSH para o servidor DNS: ssh [email protected]
2. Adicionar à zona de bloqueio: echo "zone evil.com { type master; file /etc/bind/db.sinkhole; };" >> /etc/bind/named.conf.local
3. Recarregar DNS: rndc reload
4. Verificar: dig @dns-primary evil.com (deve resolver para o IP sinkhole 10.0.0.99)
5. Documentar domínio bloqueado no ticket de incidente
Etapa 5: Integrar com a Plataforma SOAR
Converta etapas manuais do playbook em fluxos de trabalho automatizados:
- Mapeie cada etapa do playbook para uma ação SOAR (chamada de API, script, ponto de decisão humana)
- Defina limites de automação (o que é executado automaticamente vs. o que requer aprovação do analista)
- Crie automações de enriquecimento para a fase de triagem
- Crie automações de contenção com portões de aprovação para ações de alto impacto
- Configure automações de notificação para comunicação com as partes interessadas
Etapa 6: Testar e Manter o Playbook
Valide o playbook por meio de exercícios e mantenha-o atualizado:
- Realize exercícios de mesa com a equipe de RI percorrendo o playbook
- Realize exercícios ao vivo simulando o tipo de incidente em um ambiente de teste
- Revise e atualize após cada incidente real que use o playbook
- Agende revisões trimestrais para precisão das listas de contato, procedimentos de ferramentas e caminhos de escalonamento
- Acompanhe métricas do playbook: tempo médio para conter, tempo médio para resolver, taxa de falso positivo
Conceitos Chave
| Termo | Definição |
|---|---|
| Playbook | Conjunto documentado e repetível de procedimentos para responder a um tipo específico de incidente |
| Runbook | Mais granular que um playbook; instruções técnicas passo a passo para uma tarefa específica dentro de um playbook |
| Matriz RACI | Gráfico de atribuição de responsabilidades que define quem é Responsável, Accountable, Consultado e Informado para cada atividade |
| Árvore de Decisão | Lógica baseada em fluxograma que define o caminho de resposta com base em condições binárias em cada ponto de decisão |
| Critérios de Escalonamento | Condições predefinidas que acionam a notificação de pessoal de nível superior ou partes externas |
| Playbook SOAR | Fluxo de trabalho automatizado em uma plataforma de Security Orchestration, Automation, and Response que executa etapas do playbook |
Ferramentas e Sistemas
- Cortex XSOAR: Plataforma SOAR com editor visual de playbooks, mais de 700 integrações e War Room colaborativa
- Splunk SOAR: Plataforma SOAR integrada ao Splunk ES, construtor de playbooks de arrastar e soltar com mais de 2.800 ações automatizadas
- TheHive: Plataforma de resposta a incidentes de código aberto com modelos de caso que funcionam como frameworks de playbook
- Confluence / GitLab Wiki: Plataformas de documentação para manter documentos de playbook legíveis por humanos com controle de versão
- Tines: Plataforma de automação de segurança sem código para construir fluxos de trabalho de playbook sem programação
Cenários Comuns
Cenário: Construindo um Playbook de Resposta a Phishing do Zero
Contexto: Uma organização com um SOC de 5 pessoas não possui procedimento documentado de resposta a phishing. Os analistas lidam com relatórios de phishing de forma inconsistente.
Abordagem:
- Entrevistar analistas do SOC para documentar seu processo ad hoc atual
- Definir o gatilho: usuário relata e-mail de phishing via caixa de correio abuse@ ou botão de phishing
- Escrever etapas de triagem: extrair cabeçalhos de e-mail, verificar reputação do remetente, analisar URLs/anexos em sandbox
- Definir contenção: colocar e-mail em quarentena de todas as caixas de correio, bloquear domínio do remetente, redefinir senhas se credenciais foram inseridas
- Construir automação SOAR: extrair automaticamente IOCs do e-mail relatado, enriquecer via VirusTotal, criar caso no TheHive
- Testar com e-mail de phishing simulado e medir a melhoria no tempo de resposta
Armadilhas:
- Escrever procedimentos muito genéricos que não referenciam interfaces ou comandos de ferramentas específicas
- Não incluir o plano de comunicação para notificar usuários que receberam o e-mail de phishing
- Esquecer de definir os critérios para quando um relatório de phishing se torna uma investigação de incidente completa
- Não versionar o playbook ou agendar ciclos de revisão regulares
Formato de Saída
PLAYBOOK DE RESPOSTA A INCIDENTES
====================================
Nome do Playbook: Resposta a Incidente de Phishing
Versão: 2.1
Proprietário: Gerente do SOC
Última Revisão: 2025-11-01
Próxima Revisão: 2026-02-01
Gatilho: E-mail de phishing relatado via [email protected] ou botão de phishing
MATRIZ RACI
Atividade | SOC N1 | SOC N2 | Líder RI | Jurídico | Comunicações
Triagem Inicial | R | C | I | |
Análise de E-mail | R | A | I | |
Contenção | | R | A | I |
Redefinição de Senha | | R | A | |
Notificação ao Usuário | | C | A | | R
Notificação Regulatória| | | C | R | A
Lições Aprendidas | C | C | R | I | I
ETAPAS DO PROCEDIMENTO
[Etapas detalhadas com instruções específicas da ferramenta]
ÁRVORE DE DECISÃO
[Lógica de fluxograma]
MATRIZ DE ESCALONAMENTO
[Condições e contatos]
MÉTRICAS
MTTA Alvo: 15 minutos
MTTC Alvo: 1 hora
MTTR Alvo: 4 horas