Incident Response

Resposta a Incidentes

Skill de resposta a incidentes para o ciclo de vida completo desde a triagem inicial até a coleta forense, declaração de severidade e roteamento de escalação. Esta skill NÃO cobre caça a ameaças (veja threat-detection) ou mapeamento de conformidade pós-incidente (veja governance/compliance-mapping) — trata de classificar, triar e gerenciar incidentes de segurança declarados.

Sumário

• Visão Geral
• Ferramenta de Triagem de Incidentes
• Classificação de Incidentes
• Framework de Severidade
• Filtragem de Falsos Positivos
• Coleta de Evidências Forenses
• Caminhos de Escalação
• Obrigações de Notificação Regulatória
• Fluxos de Trabalho
• Anti-Padrões
• Referências Cruzadas

Visão Geral

O que Esta Skill Faz

Esta skill fornece a metodologia e ferramentas para triagem e resposta a incidentes — classificando eventos de segurança em incidentes tipificados, pontuando severidade, filtrando falsos positivos, determinando caminhos de escalação e iniciando coleta de evidências forenses sob controles de cadeia de custódia.

Distinção de Outras Skills de Segurança

Pré-requisitos

Um evento de segurança deve ser ingerido antes da triagem. Os eventos podem vir de alertas SIEM, detecções EDR, feeds de inteligência de ameaças ou relatórios de usuários. A ferramenta de triagem aceita payloads de eventos JSON; consulte o schema de entrada abaixo.

Ferramenta de Triagem de Incidentes

A ferramenta incident_triage.py classifica eventos, verifica falsos positivos, pontua severidade, determina escalação e realiza pré-análise forense.

# Classificar um evento a partir de arquivo JSON
python3 scripts/incident_triage.py --input event.json --classify --json

# Classificar com filtragem de falsos positivos habilitada
python3 scripts/incident_triage.py --input event.json --classify --false-positive-check --json

# Forçar um nível de severidade para exercícios de tabletop
python3 scripts/incident_triage.py --input event.json --severity sev1 --json

# Ler evento do stdin
echo '{"event_type": "ransomware", "host": "prod-db-01", "raw_payload": {}}' | \
  python3 scripts/incident_triage.py --classify --false-positive-check --json

Schema do Evento de Entrada

{
  "event_type": "ransomware",
  "host": "prod-db-01",
  "user": "svc_backup",
  "source_ip": "10.1.2.3",
  "timestamp": "2024-01-15T14:32:00Z",
  "raw_payload": {}
}

Códigos de Saída

Classificação de Incidentes

Eventos de segurança são classificados em 14 tipos de incidentes. A classificação orienta a severidade padrão, o mapeamento de técnica MITRE e o SLA de resposta.

Taxonomia de Incidentes

Gatilhos de Escalação de Severidade

Qualquer um dos seguintes re-declara automaticamente uma severidade maior:

Framework de Severidade

Matriz de Nível de Severidade

Filtragem de Falsos Positivos

A ferramenta de triagem aplica cinco filtros antes de escalar para prevenir inflação de falsos positivos.

Tipos de Filtro de Falsos Positivos

Um falso positivo confirmado suprime a escalação e registra o motivo da supressão para fins de auditoria. Falsos positivos recorrentes da mesma fonte devem ser ajustados na camada de detecção, não filtrados repetidamente na triagem.

Coleta de Evidências Forenses

A coleta de evidências segue o framework de seis fases do DFRWS e o princípio da aquisição volátil primeiro.

Seis Fases do DFRWS

Evidências Voláteis — Coletar Primeiro

1. Memória ao vivo (dump de RAM) — perdida ao reiniciar
2. Processos em execução e conexões de rede abertas (netstat, ps)
3. Usuários logados e sessões ativas
4. Uptime do sistema e hora atual (para ancoragem de linha do tempo)
5. Variáveis de ambiente e módulos de kernel carregados

Requisitos de Cadeia de Custódia

Cada item de evidência deve ser registrado com:

• Hash SHA-256 no momento da aquisição
• Timestamp de aquisição em UTC com offset de fuso horário
• Proveniência da ferramenta (FTK Imager, Volatility, dd, exportação do AWS CloudTrail)
• Identidade do investigador
• Log de transferência (quem teve custódia e quando)

Caminhos de Escalação

Por Severidade

Por Tipo de Incidente

Obrigações de Notificação Regulatória

O relógio de notificação começa na declaração do incidente, não na conclusão da investigação.

Regra operacional: Se o escopo não estiver claro na declaração, assuma o prazo aplicável mais restritivo e confirme o escopo dentro da primeira janela de resposta.

Referência completa de prazos: references/regulatory-deadlines.md

Fluxos de Trabalho

Fluxo de Trabalho 1: Triagem Rápida (15 Minutos)

Para um único alerta que requer classificação antes da decisão de escalação:

# 1. Classificar o evento com filtragem de falsos positivos
python3 scripts/incident_triage.py --input alert.json \
  --classify --false-positive-check --json

# 2. Revisar severidade, escalation_path e false_positive_flag na saída
# 3. Se severidade = sev1 ou sev2, acionar o Líder do SOC imediatamente
# 4. Se false_positive_flag = true, documentar e fechar

Decisão: Código de saída 2 = war room SEV1 agora. Código de saída 1 = chamada de bridge SEV2 em 30 minutos.

Fluxo de Trabalho 2: Resposta Completa a Incidente (SEV1)

T+0   Detecção chega (alerta SIEM, EDR, relatório de usuário)
T+5   Classificar com incident_triage.py --classify --false-positive-check
T+10  Se SEV1: acionar CISO, abrir war room, iniciar relógio regulatório
T+15  Iniciar coleta forense (evidências voláteis primeiro)
T+15  Avaliação de contenção (em paralelo com forense)
T+30  Gate de aprovação humana para qualquer ação de contenção
T+45  Executar contenção aprovada
T+60  Avaliar eficácia da contenção, informar Jurídico se escopo PII/PHI
T+4h  Pacote final de evidências forenses, estimativa de tempo de permanência
T+8h  Plano de erradicação e recuperação
T+72h Submissão de notificação regulatória (se LGPD/NIS2 acionado)

# Classificação completa com contexto forense
python3 scripts/incident_triage.py --input incident.json \
  --classify --false-positive-check --severity sev1 --json > incident_triage_output.json

# Pré-análise forense
python3 scripts/incident_triage.py --input incident.json --json | \
  jq '.forensic_findings, .chain_of_custody_steps'

Fluxo de Trabalho 3: Simulação de Exercício de Tabletop

Simular incidentes em níveis específicos de severidade sem eventos reais:

# Simular incidente de ransomware SEV1
echo '{"event_type": "ransomware", "host": "prod-db-01", "user": "svc_backup"}' | \
  python3 scripts/incident_triage.py --classify --severity sev1 --json

# Simular comprometimento de credenciais SEV2
echo '{"event_type": "credential_compromise", "user": "admin_user", "source_ip": "203.0.113.5"}' | \
  python3 scripts/incident_triage.py --classify --false-positive-check --json

# Verificar caminhos de escalação para todos os 14 tipos de incidente
for type in ransomware data_exfiltration credential_compromise lateral_movement; do
  echo "{\"event_type\": \"$type\"}" | python3 scripts/incident_triage.py --classify --json
done

Anti-Padrões

1. Iniciar o relógio de notificação na conclusão da investigação — Os relógios regulatórios (LGPD 72 horas, PCI 24 horas) começam na descoberta, não na conclusão da investigação. Declarar tarde expõe a organização às penalidades máximas mesmo que o incidente em si tenha sido menor.
2. Conter antes de coletar evidências voláteis — Reiniciar ou isolar um sistema destrói RAM, processos em execução e conexões ativas. A coleta forense de evidências voláteis deve acontecer em paralelo com a contenção, nunca depois.
3. Pular a verificação de falsos positivos antes da escalação — Escalar cada alerta para SEV1 degrada a credibilidade do SOC e causa fadiga de alertas. Sempre execute filtros de falsos positivos antes de acionar o CISO.
4. Decisões de comando de incidente não documentadas — Toda decisão tomada durante um SEV1, incluindo decisões tomadas sob incerteza, deve ser registrada na cadeia de evidências com timestamp e justificativa. Decisões não documentadas não podem ser defendidas em investigações regulatórias.
5. Tratar o fechamento do incidente como conclusão da investigação — Incidentes são fechados quando a erradicação e recuperação estão completas, não quando a investigação termina. O relatório forense e as submissões regulatórias podem continuar após o fechamento operacional.
6. Classificação de fonte única — Classificar um incidente a partir de uma única fonte de dados (um alerta SIEM) sem evidências corroborativas frequentemente leva à classificação incorreta. Colete pelo menos dois sinais independentes antes de declarar SEV1.
7. Ignorar gates de aprovação humana para contenção — Ações de contenção automatizadas (isolamento de rede, revogação de credenciais) tomadas sem aprovação humana podem causar interrupções em produção, destruir evidências e criar responsabilidade. A aprovação humana é inegociável para todas as ações de contenção mutantes.

Referências Cruzadas