Runbooks, resposta e hardening pós-incidente
O runbook faz a contenção acontecer em minutos, e o pós-incidente transforma o que doeu em uma defesa permanente, na aplicação e não só na borda.
O que é
Runbooks são roteiros curtos e acionáveis para os incidentes mais prováveis: quem decide, o que checar, qual ação tomar e como desfazer. Bom runbook cabe em uma tela e funciona às três da manhã, para quem acabou de acordar.
O hardening pós-incidente é o outro lado: a borda contém, mas só a correção na aplicação e na configuração evita a repetição.
Escada de contenção com prazo
Em ataques volumétricos ou de abuso, a resposta escala em degraus, cada um com TTL, para que um erro de classificação não bloqueie ninguém para sempre. Começar por desafio (barato para o legítimo, caro para o robô) e só então bloquear.
trigger: alerta login_failures_zscore > 4 por 3 minutos
owner: soc-l7 (plantão)
steps:
- verificar: ASNs e fingerprints dominantes, contas tentadas (distintas vs repetidas)
- conter:
1: Managed Challenge nos ASNs ofensores # TTL 30 min
2: Block nos fingerprints confirmados # TTL 4 h
3: exigir MFA / reset forçado nas contas com sucesso suspeito
- comunicar: canal #incidentes, atualização a cada 30 min
- desfazer: remover regras se a taxa de falhas voltar ao baseline por 30 min
after: pós-mortem em até 5 dias úteisPós-mortem sem culpa
O objetivo é aprender, não achar culpado. Um bom pós-mortem registra a linha do tempo (quando começou, quando detectamos, quando contivemos), a causa, o que funcionou, o que atrapalhou e ações com dono e prazo. As métricas de detecção e contenção saem dele e alimentam o tuning.
Hardening na aplicação
Cada incidente aponta controles que não deveriam depender da borda. Três exemplos frequentes:
- CSP com nonce: política de segurança de conteúdo que só executa scripts com um nonce gerado por requisição, reduzindo o impacto de .
- estrito: origens permitidas explícitas, sem coringa em endpoints com credenciais.
- Validação de schema no gateway: rejeitar corpos e parâmetros que não casam com a especificação da API, o aplicado perto da aplicação.
Exemplo: CSP com nonce
Content-Security-Policy:
default-src 'self';
script-src 'self' 'nonce-{random-por-requisição}' 'strict-dynamic';
object-src 'none';
base-uri 'none';
frame-ancestors 'none'Exercícios
Runbook não testado é suposição. Exercícios de mesa (tabletop) e simulações com tráfego sintético revelam lacunas de permissão, de contato e de ferramenta antes do incidente real, e mantêm o time treinado.
conexões no mapa
- Bot managementacionaRunbooks, resposta e hardening pós-incidente
- WAF - observação, shadow e enforcementexecutaRunbooks, resposta e hardening pós-incidente
atualizado em 14/10/2026 · fontes para aprofundar · reportar erro
em outros domínios
- O ciclo de vida da resposta a incidentesresponserunbooks são o ciclo ensaiado e escrito
- SASTappseco hardening do pós-incidente vira regra e correção no código
- Resposta a incidentes em cloudcloudseco runbook de L7 é um caso específico da resposta geral
- Automação de segurança e playbooks como códigosecengo runbook que vira playbook automatizado, com freios
Estude antes
teste o que entendeu
Carregando perguntas…