Heptagon (Framework Formal para IR)

Nota da subpasta 04 - Ferramentas de Análise de Memória e DFIR, no Capítulo 24 (Ferramentas e Plataformas Atualizadas).
Trata do Heptagon como abordagem formal para incident response: o incidente modelado como máquina de estados com transições guardadas, invariantes verificáveis e trilha de auditoria por transição.
Dialoga com as notas de Volatility 3 e SPECTRE da mesma subpasta, que produzem a evidência que alimenta os estados, e com os conteúdos de resposta a incidentes baseados no NIST SP 800-61.

1. Contexto e Posicionamento na Biblioteca

A maior parte das organizações opera resposta a incidentes com playbooks em prosa, e essa escolha tem preço: dois analistas seguem o mesmo playbook e produzem caminhos diferentes, a auditoria não consegue provar o que foi feito em qual ordem, e a automação via SOAR herda a ambiguidade do texto. O Heptagon parte da premissa oposta, a de que o incidente pode ser modelado formalmente como uma máquina de estados, com estados, transições, guardas e invariantes declarados de forma explícita e verificável. O resultado é uma resposta que se comporta mais como engenharia e menos como improviso coordenado.

O nome do framework remete ao heptágono, e o desenho canônico organiza o ciclo em sete estados, do registro do indício ao encerramento do caso. A proposta não substitui o julgamento humano nem o conhecimento técnico do analista; o que ela muda é a estrutura em que esse julgamento é exercido, porque cada decisão vira uma transição com guarda, evidência exigida e registro imutável. Esta nota cobre a motivação da formalização, a estrutura do framework, a comparação com os modelos consagrados, os benefícios e custos e um exemplo completo de modelagem.

2. Por que Formalizar a Resposta a Incidentes

A formalização responde a três problemas recorrentes que os playbooks em prosa não resolvem. O primeiro é a variabilidade entre analistas: sem estados e guardas explícitos, a contenção pode acontecer antes ou depois da preservação de evidência dependendo de quem está de plantão, e essa diferença é exatamente o que destroi processos judiciais e pós-mortems. O segundo é a ausência de propriedades verificáveis: ninguém consegue testar de forma automática se um caso passou por todas as etapas exigidas, porque as etapas não foram declaradas como algo testável. O terceiro é a integração com automação: um SOAR só executa com segurança o que está definido com condições de entrada e saída precisas, e prosa não fornece essa precisão.

A ideia central é transferir para a resposta a incidentes a disciplina que os métodos formais levaram à engenharia de software. Em vez de descrever o incidente em parágrafos, descreve-se um grafo no qual cada estado tem precondições de entrada, cada transição tem uma guarda lógica que deve ser verdadeira para ocorrer e cada ação produz evidência registrada. Com o grafo declarado, propriedades globais passam a ser verificáveis, como garantir que nenhum caminho alcança a recuperação sem passar pela contenção, e a trilha de transições se torna o registro auditável do caso.

Honestamente, a formalização não é gratuita e nem sempre cabe ao caso. Incidentes caóticos, com informação parcial e pressão de minutos, resistem a modelos rígidos, e a modelagem por tipo de incidente exige investimento inicial de tempo de gente sênior. O framework se paga em incidentes recorrentes e de alto impacto, onde a repetição, a auditoria e a automação valem o custo de declarar o modelo uma vez e mantê-lo versionado.

3. Estrutura do Framework: Estados, Transições e Invariantes

O modelo se apoia em quatro elementos. O estado define uma condição do caso, com precondição de entrada, evidência mínima exigida para habitar aquele estado e papéis autorizados a operar nele. A transição liga dois estados, com uma guarda lógica que deve ser verdadeira, as ações executadas no disparo e a evidência que a transição produz. O invariante é uma propriedade global que todo caminho no grafo precisa satisfazer, como a exigência de evidência volátil preservada antes de qualquer ação destrutiva. A trilha é o registro imutável de cada transição executada, com ator, insumos, resultado e carimbo de tempo.

Elementos do modelo:
- Estado: id, precondicao de entrada, evidencia minima exigida, papeis autorizados
- Transicao: origem, destino, guarda logica, acoes executadas, evidencia produzida
- Invariante: propriedade global que todo caminho no grafo deve satisfazer
- Trilha: registro imutavel de cada transicao com ator, insumo e carimbo de tempo

Estados canonicos do ciclo heptagonal:
1. DETECTADO: indicio registrado, caso aberto e preservacao volatil iniciada
2. CONFIRMADO: comprometimento verificado por evidencia tecnica e escopo inicial
3. CONTIDO: propagacao interrompida sem destruir evidencia nem ampliar dano
4. ERRADICADO: vetor inicial documentado, persistencias removidas com comprovacao
5. RECUPERADO: servicos restaurados de fonte limpa e sob vigilancia reforcada
6. APRENDIZADO: licoes, deteccoes novas e correcoes de processo registradas
7. ENCERRADO: caso fechado com trilha completa e metricas extraidas

O ciclo heptagonal tem duas propriedades estruturais que explicam o desenho. A primeira é que evidência precede ação: os estados que autorizam ações intrusivas, como contenção e erradicação, exigem guardas de preservação, evitando o erro clássico de formatar a máquina que ainda tinha o vetor inicial vivo na memória. A segunda é que aprendizado é estado obrigatório, e não recomendação: o caminho para encerramento passa por aprendizado por construção, o que impede o caso técnico de encerrar sem que a detecção nova e a correção de processo existam.

4. Comparação com NIST SP 800-61, SANS PICERL e DAIR

O NIST SP 800-61 continua sendo o marco de referência da disciplina, com seu ciclo de preparação, detecção e análise, contenção, erradicação e recuperação e atividade pós-incidente. O SANS PICERL traduz o ciclo em seis passos operacionais com forte apelo didático, e é a linguagem que muitos times usam no dia a dia. O DAIR, proposto na literatura recente, estrutura a resposta como um ciclo adaptativo orientado a iteração contínua entre detecção, análise e resposta, com a sigla aparecendo na literatura com pequenas variações de definição; o ponto relevante aqui é o contraste entre adaptabilidade iterativa e estados formais verificáveis. O Heptagon se diferencia de todos por tratar o ciclo não como descrição, mas como modelo executável e verificável.

Os modelos não competem na prática, eles se empilham. O NIST define o que a organização deve fazer e serve ao compliance; o PICERL ensina o fluxo em treinamento; o DAIR lembra que o ambiente muda durante a resposta e que iteração é necessária; e o Heptagon transforma essa stacked semantics em grafo executável, que o SOAR pode operar e a auditoria pode inspecionar. A recomendação de adoção é mapear o playbook do NIST que a organização já usa para dentro de um modelo heptagonal, começando pelo tipo de incidente com maior frequência ou maior risco.

5. Benefícios e Custos da Formalização

Os benefícios se concentram em quatro pontos. A reprodutibilidade garante que o mesmo insumo de evidência conduza ao mesmo caminho de resposta, o que permite comparar casos e treinar juniores com cenários determinísticos. A auditabilidade garante que cada ação tenha registro de quem a autorizou, com qual insumo e em que hora, o que atende tanto ao jurídico quanto ao pós-mortem. A automação ganha base segura, porque as guardas do modelo mapeiam diretamente em checagens que o SOAR executa antes de cada ação. A verificação de propriedades, por fim, permite testar o modelo em si, antes de qualquer incidente real, procurando caminhos proibidos no grafo.

Os custos são reais e precisam ser orçados. A modelagem inicial consome tempo de gente sênior que já é escassa, a manutenção exige disciplina de versionamento sempre que o ambiente muda, e a rigidez pode atrapalhar incidentes verdadeiramente fora do padrão se o modelo não tiver transições de exceção. A mitigação prática é começar estreito, com um ou dois tipos de incidente, e prever um estado de exceção explícito, no qual a decisão humana registra o desvio como transição documentada, em vez de o analista simplesmente contornar o modelo.

O mecanismo de exceção merece exemplo declarado, porque é ele que evita o contorno silencioso do modelo. Quando o caso apresenta risco imediato de propagação, o analista executa a transição de exceção, que é um caminho declarado no grafo, com guarda própria, ações limitadas e pós-condição de revisão obrigatória. A diferença para o atalho fora do processo é que a exceção tem registro, dono e revisão na fase de aprendizado, e não apenas a memória de quem decidiu.

transicao_de_excecao:
  de: QUALQUER_ESTADO
  para: CONTIDO
  tipo: excecao_emergencial
  guard: risco_imediato_de_propagacao == true
  acoes: [isolar_host, registrar_desvio, notificar_gestor_do_caso]
  pos_condicao: revisao do desvio obrigatoria no estado APRENDIZADO

6. Exemplo de Modelagem de Incidente em Estados

O exemplo modela um caso de ransomware em servidor de arquivo, com os estados canônicos, as transições principais e os invariantes do caso. O formato YAML é ilustrativo e serve como contrato que o SOAR ou um verificador simples consome.

caso: IR-2025-0142
tipo: ransomware em servidor de arquivo
modelo: heptagon-v1
estados:
  - id: DETECTADO
    precondicao: alerta de cifragem em massa confirmado pelo analista
    evidencia_minima: [dump_memoria, imagem_disco, extrato_siem]
    papeis_autorizados: [analista_n1, analista_n2]
  - id: CONFIRMADO
    precondicao: grupo de cifragem identificado e amostra isolada
  - id: CONTIDO
    precondicao: host isolado e credenciais privilegiadas revogadas
  - id: ERRADICADO
    precondicao: vetor inicial documentado e persistencias removidas
  - id: RECUPERADO
    precondicao: restauracao a partir de backup limpo validada
  - id: APRENDIZADO
    precondicao: licoes e deteccoes novas registradas
  - id: ENCERRADO
    precondicao: trilha completa revisada e metricas extraidas
transicoes:
  - de: DETECTADO
    para: CONFIRMADO
    guard: amostra_coletada == true and escopo_inicial_definido == true
    acoes: [abrir_caso, acionar_time_ir, preservar_volatil]
  - de: CONFIRMADO
    para: CONTIDO
    guard: dump_memoria_preservado == true and isolamento_confirmado == true
    acoes: [isolar_host, revogar_credenciais_privilegiadas]
  - de: CONTIDO
    para: ERRADICADO
    guard: vetor_inicial_documentado == true
    acoes: [remover_persistencias, aplicar_patch, revisar_contas]
invariantes:
  - nenhum caminho alcanca RECUPERADO sem passar por CONTIDO e ERRADICADO
  - nenhuma transicao dispara acao destrutiva sem evidencia volatil preservada
  - toda transicao registra ator, insumo e carimbo de tempo na trilha

As propriedades do modelo se verificam sobre o grafo, e não sobre um caso individual, o que permite encontrar defeitos de desenho antes do incidente real.

P1: todo caminho ate ENCERRADO inclui o estado APRENDIZADO
P2: nenhuma transicao entra em CONTIDO sem guarda de evidencia preservada
P3: o grafo nao possui transicao de RECUPERADO de volta a DETECTADO no mesmo caso
P4: toda acao destrutiva exige guarda de snapshot concluido

A leitura do exemplo deixa claro como o modelo disciplina a operação. A reinfecção do mesmo host não é um retorno ao estado detectado do mesmo caso, e sim um novo caso, conforme a propriedade P3, o que preserva a integridade das métricas e da trilha. A contenção só ocorre com o dump de memória preservado, conforme a guarda da transição, e é exatamente essa guarda que impede o erro recorrente de rebootar o servidor antes da coleta, tema que a nota de Volatility 3 desta subpasta cobre pelo lado técnico da evidência.

7. Verificação de Propriedades e Trilha de Auditoria

Na prática, a verificação completa por model checking é rara em SOCs, e não é essa a entrada sugerida. O caminho pragmático é implementar as guardas como checagens executáveis no SOAR, que recusa a transição quando a condição não é verdadeira, e manter os invariantes como testes automatizados sobre o arquivo do modelo, executados em pipeline sempre que o modelo muda de versão. Com isso, o erro de desenho como um caminho que alcança recuperação sem erradicação é pego no repositório, e não na madrugada de um incidente.

A trilha de auditoria é o produto que sobrevive ao caso. Cada transição registrada com ator, insumo, guarda avaliada e carimbo de tempo permite reconstruir o incidente inteiro a posteriori, medir o tempo gasto em cada estado e comparar a execução real com o modelo declarado. Os desvios recorrentes entre modelo e prática são o insumo da revisão mensal do modelo, e é nessa revisão que o framework evita o destino comum de processos documentados, que é virar papel morto que ninguém consulta.

8. Erros Comuns e Pontos de Atenção

• Modelar todos os tipos de incidente de uma vez, travando o programa antes da primeira execução; comece pelo tipo mais frequente ou mais crítico.
• Tratar o modelo como substituto do julgamento humano; o modelo estrutura a decisão, e a decisão segue sendo do analista.
• Definir guardas tão rígidas que impeçam contenção urgente; preveja transição de exceção com registro formal do desvio e aprovação sênior.
• Ignorar a manutenção do modelo depois de cada incidente, deixando o grafo divergir da prática até perder credibilidade.
• Permitir que o analista contorne o modelo sem registro, o que destrói exatamente a auditabilidade que o framework entrega.
• Confundir a formalização do processo com a automação total, tentando remover o humano de estados que exigem julgamento técnico.
• Usar nomes de estado vagos, como resolvido, que escondem múltiplas condições; cada estado precisa de precondição testável.
• Cobrar métricas de MTTR sobre um modelo que nunca foi executado como grafo, medindo o que a trilha não registrou.

9. Integração com o Restante da Biblioteca

O framework consome a evidência que as notas técnicas da mesma subpasta produzem: o dump analisado no Volatility 3 fornece a prova de comprometimento que habilita a transição de confirmação, e o alerta do SPECTRE fornece o indício que abre o estado de detecção. As guardas das transições mapeiam diretamente nas checagens das notas de SOAR da pasta 02, em especial o Splunk com ES e SOAR, e a CTI entra como insumo na definição dos tipos de incidente que valem modelagem prioritária, usando as notas de TIP da pasta 01. O programa purple da pasta 03 fecha o laço, emulando tipos de incidente com o Caldera para testar se as transições e guardas do modelo resistem a uma execução real.

A recomendação de adoção é tratar o primeiro modelo heptagonal como produto, com dono, versão e testes. Comece pelo playbook de phishing ou de malware, os tipos com maior volume na maioria dos SOCs, derive os estados a partir do playbook NIST que já existe, implemente as guardas como checagens no SOAR e execute as propriedades como testes em pipeline. O que o framework entrega de mais valioso não é o diagrama, e sim a mudança de regime em que cada decisão de resposta passa a ter condição de entrada declarada, evidência exigida e registro imutável, e é nesse regime que auditoria, automação e treinamento passam a compartilhar o mesmo artefato.