IR.4 - Recuperação e Lições Aprendidas

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.4, com os subcontroles IR.4.1 a IR.4.5.
Define a recuperação verificada, que devolve sistemas à produção sem recomprometimento, e o post-mortem sem culpa, que converte cada incidente em detecções novas, telemetria nova, runbooks novos e inteligência para o ciclo de CTI e de hunting.

1. Contexto e Posicionamento no Framework CTH

A recuperação verificada garante que os sistemas restaurados estão livres de comprometimento e que as vulnerabilidades exploradas foram efetivamente corrigidas. Sem verificação adequada, restaurar a partir de backup contaminado ou reativar sistema com a mesma falha resulta em recomprometimento imediato, o pior desfecho possível para o esforço de contenção e erradicação. As lições aprendidas fecham o ciclo: organizações que não conduzem revisão pós-incidente repetem os mesmos erros e não evoluem a capacidade de defesa, gastando o valor que o incidente, a duras penas, produziu.

No framework, o IR.4 é o controle que transforma resposta em melhoria permanente. A recuperação consome a verificação da erradicação do IR.3 e devolve serviços ao negócio com monitoramento intensificado; o post-mortem consome o caso estruturado do IR.1 e devolve produto para quatro destinos: novas detecções para o DET, novas fontes de telemetria para o DAT, novos runbooks para o IR.x e novos IOC e TTPs para o CTI.9 e o PLT.x. É também o controle que gera novas hipóteses de hunt, porque todo incidente real valida uma técnica adversária que merece busca retroativa em todo o parque.

2. Recuperação com Segurança

Recuperar não é ligar a máquina de volta; é devolver o serviço com confiança verificável. A restauração parte de backup confiável, preferencialmente imutável ou offline, testado em restauração periódica, porque backup nunca testado é apenas uma esperança com nome técnico. Antes de devolver qualquer sistema à produção, três verificações são obrigatórias: integridade, que confirma ausência de artefatos do adversário com antimalware, YARA e verificação de arquivos críticos; vulnerabilidade, que confirma que o vetor foi corrigido por patch, configuração ou controle adicional; e detecção, que confirma que a mesma atividade seria detectada se ocorresse novamente, gerando regras novas quando necessário.

A restauração em fases com critérios de saída explícitos evita o retorno caótico de tudo ao mesmo tempo. Cada fase exige validação antes da próxima, e o monitoramento intensificado acompanha a área recuperada por um período acordado, buscando sinais de recomprometimento.

Durante todas as fases, o caso no IR.1 permanece aberto, com tasks específicas de recuperação e carimbo de cada retorno. O monitoramento intensificado deve ter prazo e responsável definidos, pois monitoramento para sempre não existe; sem prazo, o intensificado degrada em esquecido.

Exemplos de validação pós-recuperação
Varredura por YARA no host restaurado:
  yarascanner --recursive /var/www --rules=/opt/regras/incidente_ir2025.yar
Verificação de integridade de arquivos críticos:
  Verificar hashes de binários do sistema contra baseline do INS.5
Monitoramento intensificado (48 a 72 horas) da área recuperada:
DeviceNetworkEvents
| where Timestamp > ago(72h) and DeviceName in~ (lista_recuperados)
| where RemoteUrl in~ (dominios_incidente) or RemoteIP in (ips_incidente)
| project Timestamp, DeviceName, RemoteUrl, RemoteIP, InitiatingProcessFileName
IdentityLogonEvents
| where Timestamp > ago(72h) and AccountUpn in~ (contas_afetadas)
| where LogonType in ("Interativo", "Remoto") and IPAddress !in~ (ips_corporativos)
| project Timestamp, AccountUpn, IPAddress, DeviceName

3. Post-mortem Sem Culpa

O post-mortem é a reunião que transforma experiência em instituição, e ele só produz verdade em ambiente sem culpa. Se a participação exige expor erros, os erros serão escondidos, e o documento resultante vai descrever um incidente que não aconteceu. A regra cultural é explícita: o foco é o sistema e o processo, e não a pessoa; quem executou ação errada com procedimento inexistente aponta um buraco de runbook, e não uma falha de caráter.

A estrutura recomendada é enxuta e repetível. Primeiro, a timeline reconstruída a partir do caso do IR.1, com carimbos verificáveis em vez de memória. Depois, as perguntas certas, feitas em ordem: o que funcionou e deve ser preservado; o que falhou e por qual caminho; por que a detecção demorou tanto; o que a inteligência não viu e deveria ter visto; onde o processo e a ferramenta induziram o erro. Revisão pós-incidente para severidade Alta e Crítica é obrigatória dentro de 5 dias úteis após o encerramento do caso, com participação de todas as equipes envolvidas, conforme o IR.4.2.

O produto da reunião não é um parágrafo de consolo, e sim itens de ação com dono e prazo, registrados no caso e no sistema de acompanhamento. Sem dono, recomendação é opinião; sem prazo, é desejo; os dois juntos são mudança.

4. Transformação de Lições em Mudanças

Cada lição precisa aterrissar em um tipo de mudança com mecanismo conhecido. A tabela abaixo mapeia os quatro destinos típicos com exemplos concretos, dono típico e prazo de referência, no padrão de acompanhamento que o IR.4.5 exige monitorar.

A transformação precisa de trilha visível para não morrer na ata. Cada item recebe identificador ligado ao caso, dono nominal, prazo, status de implementação e critério de validação, como a detecção testada contra o dataset real do incidente. O IR.4.5 eleva esse acompanhamento a sistema: monitora a implementação das recomendações, mede a redução de incidentes similares ao longo do tempo e produz relatório trimestral de eficácia da melhoria contínua para a alta direção, que é a audiência que financia o programa e precisa ver o retorno do post-mortem.

5. Alimentação do Ciclo de CTI e do Hunting

O incidente resolvido é a fonte de inteligência mais confiável que a organização possui, porque descreve um adversário que realmente esteve lá. O caminho de volta para o ciclo de CTI passa por três produtos: os IOC observados, com confiança alta e contexto de campanha, registrados no TIP e compartilhados conforme TLP quando cabível; os TTPs observados, mapeados em ATT&CK e documentados na plataforma de CTI conforme o IR.4.4; e o relatório interno tático, que conta a cadeia de ataque completa para os públicos do CTI.8, com a técnica de acesso inicial, o caminho de movimento e os objetivos.

Para o hunting, cada incidente gera hipóteses novas de duas naturezas. A primeira busca o mesmo TTP em todo o histórico, porque se o adversário esteve aqui 47 dias, a mesma técnica pode estar presente em outro lugar; a segunda busca variações do comportamento que a detecção nova ainda não cobre, mantendo o espírito proativo que a detecção automatizada não substitui. Esse retorno opera o ciclo virtuoso do framework: CTI alimenta hunting, hunting gera detecção, detecção aciona resposta, resposta produz inteligência.

Registro de incidente no TIP (resumo mínimo)
evento:       IR-2025-0031, ransomware, severidade Crítica
grupo/ator:   atribuição provisória com nível de confiança declarado
TTPs:         T1566.001 (phishing anexo), T1053.005 (tarefa agendada),
              T1486 (ciframento), T1490 (inibição de recuperação)
IOC:          hash da amostra, domínio de distribuição, IP de C2, mutex
confiança:    fonte primária, primeira mão, período de validade definido
compartilhamento: TLP:AMBER, setores afins via ISAC após sanitização
detecções:    Sigma gerada e vinculada ao evento
hipóteses:    duas hipóteses de hunt derivadas, com dono e data

6. Template de Post-mortem

O template abaixo padroniza a revisão e garante que nenhum incidente termine sem os campos que viram métrica e melhoria. Ele pode viver como página no wiki, como tarefa no sistema de gestão ou como anexo no caso do IR.1, desde que permaneça único e rastreável.

Post-mortem: [ID do caso] [título curto]
Severidade: [nível] | Duração total: [da detecção ao fechamento]
Participantes: [papéis presentes na revisão]

Resumo em uma frase:
  [o que aconteceu, de forma factual e sem adjetivos]

Impacto:
  [serviços afetados, duração, volume de dados, custo estimado]

Timeline reconstruída:
  [carimbo] [evento] [fonte da evidência]
  (do primeiro sinal ao fechamento, incluindo lacunas conhecidas)

O que funcionou:
  [práticas, ferramentas e decisões a preservar]

O que falhou e por quê:
  [falhas em cadeia, distinguindo lacuna de processo, de ferramenta e de decisão]

Por que a detecção demorou:
  [cobertura de telemetria, regras ausentes, correlação faltante]

O que a inteligência não viu:
  [fontes que não cobriam, TTPs sem monitoramento, IOC que passaram]

Ações de melhoria:
  [ID] [descrição] [tipo: detecção, telemetria, runbook, PIR, controle]
  [dono] [prazo] [critério de validação]

Lições para a biblioteca:
  [o que este incidente ensina que deve ser publicado internamente]

7. Métricas de Melhoria Entre Incidentes

Métricas de melhoria são fáceis de fraudar silenciosamente, e por isso precisam de fonte nos registros do caso, e não em declaração de reunião. Reincidência é a métrica que mais interessa à direção, pois traduz o post-mortem em linguagem de risco: cada caso repetido é evidência de processo que não aprende, e o relatório trimestral do IR.4.5 existe exatamente para expor essa curva.

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

A sequência dos níveis revela a dependência real: verificação e revisão são base de processo, tradução em detecção exige engenharia organizada, e o rastreamento de eficácia pressupõe meses de casos estruturados no IR.1 e métricas do MET.x consolidadas. Tentar começar pelo avançado, com dashboard de eficácia e nenhum post-mortem acontecendo, é investir em vitrine sem loja.

9. Erros Comuns e Pontos de Atenção

• Recuperação contaminada: restaurar backup que já está dentro da janela de comprometimento devolve o adversário junto; determine o ponto de restauração por evidência forense, e não pela data mais conveniente.
• Post-mortem com culpado: a primeira busca por quem errou encerra o fluxo honesto de informações; mantenha o foco em sistema e processo com regra explícita de não punição.
• Reunião sem timeline: discussão por memória produz versões rivais do mesmo evento; reconstrua primeiro, discuta depois.
• Ações sem dono ou sem prazo: lista de boas intenções sem nome e data no sistema de acompanhamento é ata decorativa; todo item sai da sala com dono nominal.
• Conhecimento que não sai do caso: IOC e TTPs observados que não chegam ao TIP e à plataforma de CTI desaparecem com o arquivamento do caso; o IR.4.4 existe para impedir esse desperdício.
• Monitoramento intensificado eterno ou ausente: sem prazo definido, o intensificado vira esquecido; sem início, vira inexistente; defina janela e responsável.
• Verificação de detecção ignorada: devolver o sistema sem confirmar que a mesma atividade dispararia alerta é aceitar detecção no mesmo ponto de falha; teste a regra nova contra o dataset do próprio incidente.

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

O IR.4 consome a verificação do IR.3, o caso estruturado do IR.1 e os carimbos de tempo que alimentam o MET.x, e devolve produto para toda a esteira: detecções para o DET e o AUT.3, telemetria para o DAT.x, runbooks para o IR.3 e o AUT.1, requisitos para o CTI.1 e evidência de maturidade para o GOV. As hipóteses derivadas de incidente alimentam a fila do TH.5, garantindo que o hunting aprenda com o adversário que já esteve dentro, e o compartilhamento conforme TLP do PLT.5 transforma a experiência local em valor coletivo para a comunidade, fechando o ciclo entre resposta, inteligência e melhoria contínua.