IR.1 - Gestão de Incidentes com Plataforma DFIR

Nota do grupo RES (Resposta a Incidentes Integrada) da seção 15 do Framework CTH.
Deriva do Capítulo 16 do PDF de referência, controle IR.1, com os subcontroles IR.1.1 a IR.1.5.
Posiciona a plataforma DFIR como sistema central de registro e coordenação de casos, mostrando por que casos estruturados substituem planilhas e e-mail, quais funcionalidades são essenciais e como o caso conecta detecção, inteligência e resposta.

1. Contexto e Posicionamento no Framework CTH

A gestão de incidentes é a capacidade operacional que transforma detecção e inteligência em ação concreta de defesa. O grupo DET gera alertas, o grupo HNT produz achados proativos e o grupo ANA dissemina inteligência, mas nenhum desses produtos reduz dano por si só; é o caso de incidente bem gerido que converte sinal em contenção, erradicação e recuperação documentadas. Sem plataforma dedicada, todo o investimento da esteira perde valor prático, porque a ameaça detectada não é tratada de forma consistente, rastreável e mensurável.

Dentro do framework, o IR.1 é o ponto de encontro da esteira: todo incidente detectado por regra do DET, confirmado por simulação do SIM ou descoberto por hunt do HNT precisa nascer, viver e morrer dentro de um caso rastreável. O caso é também a unidade básica de medição do grupo MET.x, pois MTTD, MTTR e tempo de contenção só são confiáveis quando derivam de registros estruturados de casos. Por fim, o fechamento do caso alimenta o CTI.9 com lições, novos IOC e TTPs observados, fechando o ciclo virtuoso entre resposta e inteligência.

2. Por que Plataforma Dedicada e Não E-mail ou Planilha

O caos durante incidentes é a principal causa de falha na resposta: informação espalhada em canais de chat, decisões verbais sem registro e evidências anexadas em e-mails que ninguém encontra depois. Ferramentas genéricas de ticketing resolvem fila de trabalho, mas não foram desenhadas para investigação, pois não suportam cadeia de custódia, linha do tempo visual nem correlação de indicadores. A tabela abaixo compara as abordagens comuns e mostra por que a plataforma DFIR é o padrão exigido pelo IR.1.1.

Rastreabilidade significa que qualquer ação registrada responde quem fez, quando e por quê, requisito de auditoria interna e de regimes regulatórios. Evidência protegida com hash garante que o arquivo coletado na madrugada do incidente seja o mesmo analisado semanas depois em eventual ação legal ou contrato de seguro. Colaboração em um caso único elimina a pergunta clássica de crise, que é quem sabe onde está aquela informação, e permite que turnos se revezem sem perda de contexto.

3. Funcionalidades Essenciais da Plataforma

A escolha da plataforma deve partir das funções que sustentam a operação de resposta, e não de recursos de marketing. O conjunto mínimo testado em avaliação técnica deve cobrir o ciclo completo do caso, do alerta que originou a abertura até a lição aprendida registrada no fechamento. A tabela abaixo resume o núcleo funcional esperado.

A funcionalidade de timeline merece atenção especial porque não é apenas registro administrativo. Quando cada tarefa concluída, cada IOC adicionado e cada nota de análise recebem carimbo de tempo, a timeline do caso vira matéria-prima do post-mortem do IR.4 e do relatório tático do CTI.7, sem retrabalho de reconstrução por memória dos analistas.

4. Exemplos de Plataformas e Ecossistemas

No ecossistema open source, o TheHive é a referência de mercado: organiza o trabalho em casos, observables e tarefas, com timeline nativa e fluxo de alertas recebidos por webhook. Sua força multiplicadora está na integração com o MISP, do qual importa eventos de inteligência para correlação, e com o Cortex, que executa analisadores de enriquecimento e respondedores sobre os observables do caso. Essa tríade TheHive, MISP e Cortex reproduz, em software livre, a espinha dorsal esperada pelo IR.1.

No universo comercial, a tendência dominante é o módulo de caso integrado à plataforma SOAR, em que o caso, o playbook e a automação compartilham o mesmo motor: Splunk SOAR, Microsoft Sentinel com playbooks de automação, Cortex XSOAR e IBM SOAR são exemplos dessa categoria. Consoles de XDR também evoluíram para incluir gestão de incidentes com timeline e evidência, úteis como ponto de partida quando o time ainda não consolidou ferramenta dedicada. A decisão deve ponderar integração com o stack existente, curva de aprendizado, custo por analista e abertura de API, pois trocar de plataforma depois que o histórico de casos acumula valor é operação cara e política.

5. Fluxo de Caso Integrado de Ponta a Ponta

O fluxo abaixo descreve o padrão de caso integrado que a implantação deve perseguir, do alerta ao aprendizado. O objetivo operacional declarado pelo framework é medir esse ciclo em horas, e não em dias, com automação cuidando das etapas mecânicas.

1. O SIEM gera alerta de alta severidade, por exemplo comunicação C2 confirmada pelo sensor de rede, e dispara webhook para a plataforma DFIR.
2. O caso é criado automaticamente com o detalhe do alerta, a consulta original, os IOC associados e o link para investigação como contexto inicial.
3. O enriquecimento automático consulta o TIP, serviços de reputação e o inventário do INS.1, anexando o dossiê do indicador e a criticidade do ativo.
4. O analista de triagem classifica severidade e tipo segundo o IR.2, e o caso recebe tasks por fase: evidência, contenção, erradicação e recuperação.
5. Durante a investigação, cada novo IOC extraído é adicionado como observable, enriquecido e correlacionado com inteligência preexistente no TIP.
6. A timeline é atualizada em tempo real conforme cada task é concluída, incluindo ações de contenção executadas por playbook do AUT.5, com registro de aprovador.
7. Após verificação de erradicação e recuperação validada, o caso é fechado com lições aprendidas documentadas e post-mortem agendado conforme o IR.4.
8. Os IOC e TTPs observados alimentam o TIP e o CTI.9, e os carimbos de tempo alimentam as métricas do MET.x.

O payload ilustrado abaixo mostra o contrato mínimo que a integração SIEM para plataforma deve carregar ao criar o caso. Contexto que não chega no payload vira trabalho manual de caça à informação justamente na hora mais crítica.

{
  "fonte": "siem",
  "alerta_id": "ALT-2025-118342",
  "titulo": "Comunicação C2 suspeita de servidor de produção",
  "severidade_siem": "alta",
  "tipo_sugerido": "atividade suspeita",
  "consulta_original": "index=netflow dest_port=443 beacon_interval=60s",
  "observables": [
    {"tipo": "ip", "valor": "203.0.113.55", "direcao": "destino"},
    {"tipo": "hostname", "valor": "srv-app-04", "direcao": "origem"}
  ],
  "ativo": {"id": "AST-0044", "criticidade": "alta", "fonte": "cmdb"},
  "timestamp_deteccao": "2025-03-08T14:21:04Z",
  "link_investigacao": "https://siem.int/app/search?id=ALT-2025-118342"
}

6. Template de Caso com Campos Mínimos

Templates padronizados aceleram a abertura e forçam o registro dos campos que depois viram métrica e lição. O template abaixo é um ponto de partida compatível com o IR.1.2, que exige campos obrigatórios para descrição, severidade, afetados, linha do tempo e evidências.

Título:            [Tipo] em [ativo ou usuário] com [efeito principal]
ID do caso:        IR-AAAA-NNNN (gerado pela plataforma)
Fonte:             Alerta SIEM [ID] | Achado de hunt [ID] | Simulação [ID] | Reporte externo
Tipo de incidente: malware | ransomware | phishing | conta comprometida |
                   exfiltração | acesso não autorizado | atividade suspeita
Severidade:        Crítico | Alto | Médio | Baixo (justificativa obrigatória)
Ativos afetados:   [lista com criticidade do INS.1]
Usuários afetados: [identidades e privilégios envolvidos]
Descrição:         [o que é conhecido no momento da abertura, em 3 a 5 linhas]
IOC observados:    [hashes, IPs, domínios, URLs como observables do caso]
Timeline:          [primeiro sinal, detecção, triagem, contenção, erradicação,
                   recuperação, fechamento, com carimbo de cada evento]
Evidências:        [anexos com hash SHA256, coleta forense, capturas]
Tasks:             [por fase, com responsável e prazo]
Comunicações:      [quem foi notificado, quando e por qual canal]
Lição aprendida:   [o que funcionou, o que falhou, ação de melhoria com dono]
Status:            Novo | Em triagem | Em contenção | Em erradicação |
                   Em recuperação | Fechado

Cada campo ausente no fechamento é uma lacuna que custará caro no post-mortem ou numa eventual disputa regulatória. A plataforma deve impor campos obrigatórios por tipo de incidente, e a revisão de qualidade dos casos fechados deve amostrar casos por semana para conferir preenchimento.

7. Integração com o Ciclo do Framework CTH

A entrada de casos vem de três fontes principais: detecção automatizada do grupo DET, achado confirmado de hunt do grupo HNT e simulação ou exercício do grupo SIM que revela lacuna real. Há ainda o reporte externo, de usuário, parceiro ou CERT, que entra pela mesma porta com severidade provisória conservadora. A regra é não deixar nenhuma dessas fontes criar fluxos paralelos de trabalho fora da plataforma.

Na saída, o caso alimenta quatro destinos: o CTI.9 recebe lições, IOC e TTPs observados para produção de inteligência interna; o PLT.x recebe indicadores para compartilhamento controlado conforme TLP; o MET.x recebe carimbos de tempo para MTTD, MTTR e tempo de contenção; e o HNT recebe novas hipóteses, porque todo incidente real é uma hipótese que o adversário já provou viável. O GOV consome o conjunto para avaliar maturidade e justificar investimento.

8. Implementação e Salvaguardas por Nível

A progressão mais crítica é do IR.1.2 para o IR.1.3, quando a plataforma deixa de ser cadastro e passa a ser parte do caminho do alerta. Antes desse salto, valide que o webhook sobrevive a pico de alertas, que a deduplicação evita tempestade de casos repetidos e que o plantão sabe agir quando a integração cai. Dashboards avançados só fazem sentido com carimbos de tempo confiáveis, e por isso dependem da disciplina dos níveis anteriores.

9. Requisitos Operacionais de Implantação e Sucesso

A plataforma só cumpre o papel de sistema central quando sua própria operação é tratada como ativo crítico. Instância em infraestrutura segura, com backup diário testado por restauração periódica e acesso restrito por MFA, é o piso do IR.1.1, e não detalhe técnico opcional. O time precisa ainda de treinamento inicial e de revisão trimestral de templates, playbooks de integração e permissões, porque organização muda e plataforma congelada vira arquivo morto.

Os critérios de sucesso abaixo permitem avaliar a implantação sem ilusão, olhando para comportamento real de uso e não para o simples fato de a ferramenta estar instalada.

10. Erros Comuns e Pontos de Atenção

• Manter incidente em chat e migrar para o caso só no fim: a timeline perde horas de decisão, e a evidência conversacional não entra em custódia; registre direto na plataforma desde o primeiro minuto.
• Caso duplicado ou fantasma: alerta repetido gerando dez casos em vez de um, diluindo a fila e corrompendo métricas; configure deduplicação por entidade e janela de tempo.
• Evidência sem hash ou fora da plataforma: arquivo salvo no desktop do analista invalida custódia e se perde com troca de turno; anexe sempre com SHA256 calculado pela ferramenta.
• Campo de severidade preenchido por hábito: severidade sem justificativa escrita impede auditoria de precisão do IR.2 e vicia os relatórios executivos.
• Plataforma sem backup ou com acesso largo: incidente que compromete o próprio sistema de resposta apaga a memória da organização; aplique backup diário, MFA e papéis mínimos desde o dia um.
• Métricas extraídas à mão: se o MET.x depende de exportação manual, os números atrasam e erram; automatize a extração dos carimbos via API.
• Fechamento sem lição: caso encerrado com status verde e campo de lição vazio é oportunidade perdida; exija no mínimo uma ação de melhoria ou declaração justificada de não aplicabilidade.

11. Integração com Outros Controles do Framework CTH

O IR.1 é consumidor direto do DAT.4, que centraliza a telemetria que sustenta a investigação, e do AUT.1 e AUT.5, que orquestram e executam ações dentro do caso com trilha de auditoria. Conecta-se ao IR.2 para classificar, ao IR.3 para conter e erradicar e ao IR.4 para recuperar e aprender, formando o ciclo completo da resposta. Sua saída organizacional, os casos fechados com timeline e evidência, é insumo de primeira ordem para o CTI.9, para o compartilhamento do PLT.5 e para o MAP.x, que consolida o mapeamento ATT&CK observado em incidentes reais.