Incident response: o que fazer quando algo dá errado

1. Fundamentos do Incident Response para Desenvolvedores

Um incidente de segurança não é apenas um evento qualquer — é uma ocorrência que compromete a confidencialidade, integridade ou disponibilidade de um sistema. A diferença entre evento, incidente e violação é crucial:

  • Evento: qualquer ação observável no sistema (ex: login falho).
  • Incidente: evento com potencial de dano real (ex: múltiplos logins falhos indicando ataque de força bruta).
  • Violação: incidente confirmado com acesso não autorizado a dados sensíveis.

Desenvolvedores precisam de um plano de resposta porque, na prática, o SOC nem sempre detecta problemas no código — quem entende a aplicação é você. As fases clássicas do incident response são: Preparação, Detecção, Contenção, Erradicação, Recuperação e Pós-incidente.

2. Preparação: Antes do Incidente Acontecer

A preparação é a fase mais negligenciada, mas a mais crítica. Defina:

  • Canais de comunicação de emergência: um canal privado no Slack, integração com PagerDuty ou Opsgenie.
  • Checklist de acessos: liste dashboards de logs (Datadog, Grafana), chaves SSH, consoles cloud.
  • Runbooks: crie documentos simples por tipo de incidente.

Exemplo de runbook mínimo para vazamento de credenciais:

1. Receber alerta de credencial exposta (ex: GitHub secret scanning)
2. Revogar token imediatamente
3. Verificar logs de acesso nos últimos 30 minutos
4. Notificar time de segurança
5. Rotacionar chaves relacionadas
6. Documentar no ticket #incident-xxx

3. Detecção e Triagem: Como Saber que Algo deu Errado

Monitoramento em tempo real é essencial. Configure alertas para:

  • Picos de erro 500
  • Tentativas de autenticação suspeitas
  • Tráfego para endpoints incomuns

Use critérios de severidade (P0 a P4) para diferenciar falso positivo de ameaça real. Exemplo de payload de alerta:

{
  "severity": "critical",
  "service": "api-pagamentos",
  "indicator": "500_rate > 30% em 5 min",
  "timestamp": "2025-03-20T14:30:00Z",
  "affected_user_count": 1200
}

Um alerta P0 como esse exige resposta imediata — não é falso positivo se o número de usuários afetados é alto.

4. Contenção: Parando o Sangramento

A contenção visa minimizar danos sem destruir evidências. Ações imediatas:

  • Revogar tokens e chaves de API
  • Desativar chaves SSH comprometidas
  • Bloquear IPs ofensivos via firewall ou WAF
  • Fazer rollback rápido de deploys recentes (deploy reverso ou feature flags)

Cuidado: não delete logs ou containers — eles são evidências forenses. Isole o ambiente, mas preserve os artefatos.

5. Erradicação e Recuperação: Removendo a Causa Raiz

Após conter, identifique o ponto de entrada:

  • Commit malicioso em repositório
  • Vulnerabilidade em dependência (ex: Log4j)
  • Configuração incorreta de permissões

Corrija definitivamente:

  • Aplique patch ou atualize dependências
  • Rotacione todas as senhas e chaves (não só as comprometidas)
  • Restaure serviços a partir de backups seguros, validando integridade com checksums

6. Pós-Incidente: Aprendendo com o Erro

A post-mortem deve ser blameless — sem culpa. O foco é no processo, não na pessoa. Documente:

  • O que aconteceu (linha do tempo)
  • O que funcionou e o que falhou
  • Ações corretivas (tickets, melhorias de código)

Exemplo de ação corretiva: "Adicionar validação de input no endpoint /api/checkout para evitar SQL injection."

Atualize runbooks e crie testes de segurança automatizados (SAST, DAST) para evitar reincidência.

7. Compliance e Comunicação Durante o Incidente

Dependendo da jurisdição, você tem obrigações legais:

  • LGPD (Brasil): notificar a ANPD em caso de incidente com dados pessoais.
  • GDPR (Europa): notificar a autoridade em até 72 horas.

Comunique-se com stakeholders internos (gestão, jurídico, marketing) de forma clara e sem pânico. Para usuários afetados, seja transparente: informe o que aconteceu, quais dados foram expostos e quais medidas foram tomadas. Não divulgue detalhes técnicos que possam agravar a vulnerabilidade.

8. Ferramentas e Automação para Acelerar a Resposta

Automação reduz o tempo de resposta. Use:

  • SOAR (Security Orchestration, Automation and Response): playbooks que executam ações automaticamente (ex: revogar tokens, isolar servidor).
  • SIEM (Security Information and Event Management): centraliza logs e gera alertas.
  • Webhooks: integre alertas do seu monitoramento com canais de comunicação.

Exemplo de script minimalista para revogar chaves de API comprometidas:

# Exemplo de comando para revogar chaves de API comprometidas
curl -X POST https://api.exemplo.com/v1/revoke \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"keys": ["sk_live_abc123", "sk_live_def456"]}'

Automatize também a rotação de chaves via cron job ou função serverless.

Incident response não é sobre evitar erros — é sobre responder rápido e aprender com eles. Com preparação, automação e uma cultura blameless, você transforma incidentes em oportunidades de melhoria contínua.

Referências