Neste artigo
O que é Resposta a Incidentes
Resposta a Incidentes (Incident Response) é o processo estruturado de preparação, detecção, contenção, erradicação, recuperação e análise pós-incidente de eventos de segurança. Uma capacidade madura de IR é o que separa organizações que se recuperam rapidamente daquelas que sofrem danos prolongados.
Um incidente de segurança é qualquer evento que comprometa ou ameace comprometer a confidencialidade, integridade ou disponibilidade de ativos de informação. Exemplos incluem: malware/ransomware, acesso não autorizado, vazamento de dados, phishing bem-sucedido, DDoS, e comprometimento de credenciais.
Evento vs Incidente vs Breach
- Evento: Qualquer ocorrência observável (login, alerta de firewall)
- Incidente: Evento que viola política de segurança ou ameaça ativos
- Breach: Incidente confirmado com acesso/exposição de dados sensíveis
Frameworks: NIST vs SANS
Dois frameworks dominam a prática de resposta a incidentes: NIST SP 800-61 (Computer Security Incident Handling Guide) e SANS Incident Handler's Handbook. Ambos são amplamente aceitos e complementares.
| NIST SP 800-61 (4 fases) | SANS (6 fases) |
|---|---|
| 1. Preparação | 1. Preparação |
| 2. Detecção e Análise | 2. Identificação |
| 3. Contenção, Erradicação e Recuperação | 3. Contenção |
| 4. Erradicação | |
| 4. Atividade Pós-Incidente | 5. Recuperação |
| 6. Lições Aprendidas |
Na prática, o modelo SANS de 6 fases é mais detalhado e preferido para operações táticas. Vamos explorar cada fase.
As 6 Fases do Processo de Resposta a Incidentes
Preparação
A fase mais importante e frequentemente negligenciada. Inclui:
- Desenvolver e documentar o plano de resposta a incidentes
- Formar e treinar o time de resposta (CSIRT)
- Implementar ferramentas de detecção e resposta
- Criar playbooks para cenários comuns
- Estabelecer canais de comunicação de crise
- Definir SLAs e níveis de severidade
- Realizar exercícios tabletop e simulações
- Manter relacionamento com parceiros externos (forense, jurídico, PR)
Identificação
Detectar e confirmar que um incidente está ocorrendo:
- Monitoramento contínuo (SIEM, EDR, NDR)
- Triagem de alertas para separar falsos positivos
- Correlação de eventos de múltiplas fontes
- Determinação de escopo inicial (quais sistemas afetados)
- Classificação de severidade e priorização
- Documentação inicial do incidente
- Notificação das partes apropriadas
Contenção
Limitar o dano e impedir propagação:
- Contenção de curto prazo: Isolar sistemas, bloquear IPs/domínios, desabilitar contas
- Contenção de longo prazo: Aplicar patches, modificar regras de firewall, segmentar rede
- Preservar evidências antes de alterações
- Criar imagens forenses de sistemas comprometidos
- Balancear entre contenção e continuidade de negócios
- Comunicação com stakeholders sobre impacto
Erradicação
Remover completamente a ameaça do ambiente:
- Identificar e remover malware de todos os sistemas
- Eliminar mecanismos de persistência (backdoors, scheduled tasks)
- Fechar vulnerabilidades exploradas
- Reset de credenciais comprometidas
- Verificar que não há indicadores de comprometimento remanescentes
- Validar que a causa raiz foi endereçada
Recuperação
Restaurar operações normais de forma segura:
- Restaurar sistemas a partir de backups limpos (quando necessário)
- Reimplantar sistemas comprometidos com configuração segura
- Validar integridade antes de retornar à produção
- Monitoramento intensivo pós-recuperação
- Retorno gradual à operação normal
- Comunicação de restabelecimento aos usuários
Lições Aprendidas
Melhorar para o futuro - fase frequentemente pulada mas essencial:
- Realizar reunião post-mortem com todos os envolvidos
- Documentar timeline completa do incidente
- Identificar o que funcionou e o que pode melhorar
- Atualizar playbooks e procedimentos
- Ajustar detecções para pegar incidentes similares mais cedo
- Reportar métricas para liderança
- Implementar melhorias identificadas
Construindo um CSIRT
Um CSIRT (Computer Security Incident Response Team) é a equipe responsável por coordenar a resposta a incidentes. O tamanho e estrutura variam conforme a organização.
Papéis essenciais em um CSIRT
- Incident Commander: Lidera a resposta, toma decisões, coordena equipes
- Analista de Segurança: Investiga tecnicamente, analisa malware, faz forense
- Engenheiro de Segurança: Implementa contenção, aplica remediações
- Comunicação: Interface com stakeholders internos e externos
- Jurídico: Orienta sobre obrigações legais, preservação de evidências
- Representante de TI: Conhecimento de infraestrutura e sistemas
- Representante de Negócios: Avalia impacto nas operações
CSIRT vs SOC: O SOC foca em monitoramento contínuo e detecção. O CSIRT é acionado quando há incidente confirmado. Em organizações menores, as funções podem ser combinadas. Em maiores, SOC escala para CSIRT conforme severidade.
Modelos de CSIRT
- Interno dedicado: Equipe full-time de IR (grandes organizações)
- Interno virtual: Membros de diferentes áreas acionados quando necessário
- Híbrido: Núcleo interno + parceiro externo para suporte
- Terceirizado: Retainer com fornecedor de IR (comum para PMEs)
Playbooks e Procedimentos
Playbooks são procedimentos padronizados para tipos específicos de incidentes. Eles garantem resposta consistente, reduzem tempo de decisão e permitem que analistas menos experientes atuem efetivamente.
Estrutura de um Playbook
- Scope: Qual tipo de incidente este playbook cobre
- Triggers: O que indica que este playbook deve ser usado
- Ações de Contenção: Passos imediatos para limitar dano
- Investigação: O que coletar, onde procurar, como analisar
- Erradicação: Como remover a ameaça
- Recuperação: Passos para restaurar normalidade
- Comunicação: Quem notificar, quando, com que informações
- Escalação: Critérios e contatos para escalação
Exemplo: Playbook Phishing
Trigger: Usuário reporta e-mail suspeito ou alerta de email gateway
- Verificar se usuário clicou em link ou abriu anexo
- Se sim: isolar endpoint, coletar artefatos, verificar execução
- Extrair IOCs do email (URLs, hashes, remetente)
- Buscar outros destinatários da mesma campanha
- Bloquear IOCs em email gateway e proxy
- Se houve comprometimento: escalar para playbook de malware
- Se não houve: documentar e fechar como tentativa bloqueada
Playbooks Essenciais
- Phishing/Engenharia Social
- Ransomware
- Malware Genérico
- Vazamento de Dados
- Acesso Não Autorizado
- Comprometimento de Conta
- DDoS
- Insider Threat
Ferramentas Essenciais para IR
SIEM
Splunk, Microsoft Sentinel, Elastic SIEM, QRadar - agregação e correlação de logs
EDR
CrowdStrike, SentinelOne, Defender - detecção, investigação e resposta em endpoint
SOAR
Phantom, XSOAR, Swimlane - automação e orquestração de resposta
Forense
Volatility (memória), Autopsy/FTK (disco), Velociraptor (coleta remota)
Network
Wireshark, Zeek, NetworkMiner - análise de tráfego e captura de pacotes
Malware Analysis
Any.run, Joe Sandbox, VirusTotal, YARA - análise de artefatos maliciosos
Ticketing
TheHive, RTIR, ServiceNow - gestão de casos e documentação
Threat Intel
MISP, OpenCTI, ThreatConnect - IOCs e inteligência de ameaças
Métricas e KPIs de Resposta a Incidentes
Métricas permitem medir eficácia, identificar gaps e demonstrar valor para a liderança.
Métricas Principais
- MTTD (Mean Time to Detect): Tempo médio entre início do incidente e detecção. Benchmark: < 24h
- MTTA (Mean Time to Acknowledge): Tempo entre detecção e início da investigação. Benchmark: < 15min (críticos)
- MTTC (Mean Time to Contain): Tempo para implementar contenção inicial. Benchmark: < 4h (críticos)
- MTTR (Mean Time to Recover): Tempo total até recuperação completa. Benchmark: < 72h (críticos)
Outras Métricas Importantes
- Número de incidentes por severidade (tendência)
- Incidentes por tipo/categoria
- Taxa de incidentes recorrentes (mesma causa raiz)
- Custo médio por incidente
- Percentual de incidentes resolvidos dentro do SLA
- Eficácia de playbooks (tempo com vs sem playbook)
Precisa de Capacidade de Resposta a Incidentes?
Oferecemos serviços de IR retainer, desenvolvimento de planos e playbooks, e exercícios tabletop.
Falar com EspecialistaPerguntas Frequentes
SOC (Security Operations Center): Foca em monitoramento contínuo e detecção de ameaças. CSIRT (Computer Security Incident Response Team): Equipe acionada para responder a incidentes confirmados. CERT (Computer Emergency Response Team): Termo histórico, geralmente usado para equipes nacionais ou setoriais (ex: CERT.br). Na prática, CSIRT e CERT são usados de forma intercambiável.
Segundo a LGPD, incidentes que possam acarretar risco ou dano relevante aos titulares de dados pessoais devem ser comunicados à ANPD e aos titulares afetados em prazo razoável. Avalie: houve acesso a dados pessoais? Há risco aos titulares? Documente a decisão e justificativa. Em caso de dúvida, consulte assessoria jurídica.
Recomenda-se: exercícios tabletop trimestrais, simulações técnicas semestrais, e revisão completa do plano anualmente ou após incidentes significativos. Exercícios regulares revelam gaps, treinam a equipe e mantêm o plano atualizado. Um plano nunca testado é apenas documentação teórica.
Para a maioria das organizações, sim. Retainers garantem acesso rápido a especialistas quando necessário, SLAs de resposta definidos, expertise que seria custoso manter internamente, e frequentemente incluem horas de preparação (revisão de planos, exercícios). Custo típico: R$ 5.000-20.000/mês dependendo do SLA.
