AUT.5 - Orquestração de Resposta Automatizada

Nota do grupo AUT (Automação e Orquestração) da seção 15 do Framework CTH.
Deriva do Capítulo 14 do PDF de referência, controle AUT.5, com os subcontroles AUT.5.1 a AUT.5.5.
Define como automatizar contenção com segurança: espectro de ações, classificação por reversibilidade e impacto, guardrails de aprovação humana e auditoria de cada ação executada.

1. Contexto e Posicionamento no Framework CTH

A resposta automatizada reduz o dwell time de dias para minutos para padrões de ameaça conhecidos, limitando o dano que o adversário consegue causar em cada hora de liberdade. Em incidente real, cada minuto conta, e a automação permite que a contenção execute imediatamente após a detecção, sem esperar a disponibilidade de um analista para ações mecânicas como isolar host ou bloquear IP. O AUT.5 é o controle que transforma essa velocidade em prática governada, e não em risco operacional disfarçado de eficiência.

No Framework CTH, o AUT.5 executa o que o AUT.1 orquestra e o AUT.3 detecta, e por isso herda todos os guardrails desses controles. A regra central é human-in-the-loop para toda ação com impacto operacional significativo, com aprovação explícita, timeout configurável e trilha de auditoria completa. A maturidade cresce por níveis: do bloqueio de IOC confirmado até playbooks adaptativos que escolhem o nível de contenção conforme confiança do IOC e criticidade do ativo.

2. O Espectro de Ações de Resposta Automatizável

O catálogo de ações automatizáveis é amplo, mas não uniforme em risco. Conhecer o espectro completo, com o efeito colateral de cada ação, é pré-requisito para decidir o que pode executar sem humano e o que precisa de aprovação.

A leitura da tabela deve produzir uma lista explícita na organização, com responsável técnico por mecanismo e teste periódico de cada integração. Ação que ninguém testou não é resposta, é esperança. O teste vale para o caminho de reversão com o mesmo rigor aplicado à execução.

3. Classificação por Reversibilidade e Impacto no Negócio

A decisão de automação não depende da ferramenta, e sim de duas variáveis combinadas: a reversibilidade da ação e o impacto potencial no negócio. A matriz abaixo classifica o espectro da seção 2 e define o regime de aprovação correspondente.

A matriz é ponto de partida, e cada organização deve revisá-la contra seu mapa de ativos críticos do INS.1. Um servidor que para outra empresa é simples pode sustentar faturamento na sua, e a classificação reflete o negócio, e não a conveniência do SOC. A revisão da matriz acompanha a governança trimestral dos playbooks.

4. Guardrails Indispensáveis

Guardrails são os freios que permitem acelerar sem medo, e a lista abaixo é o mínimo aceitável para qualquer ação com efeito no ambiente. Cada item precisa de implementação técnica real, e não apenas de política escrita.

• Lista de isenção de ativos críticos: exceções explícitas para controladores de domínio, servidores de produção sensível, sistemas industriais e contas de quebra de emergência, consultada por todo playbook antes de agir.
• Aprovação humana por nível de impacto: ações de alto impacto exigem aprovação nominal com timeout configurável, e expiração devolve o caso para monitoramento aumentado em vez de executar por omissão.
• Janela de execução: restrição de horário para ações de maior impacto, evitando contenção disruptiva no meio de processos críticos de negócio, como fechamento contábil ou operação industrial noturna.
• Rate limit e cooldown: limite de ações por minuto por playbook e por integração, impedindo que um falso positivo em massa vire cascata de bloqueios.
• Rollback documentado: caminho de reversão conhecido, testado e executável em minutos, registrado junto ao playbook e não na memória de uma pessoa.
• Kill switch global: interrupção imediata de um playbook ou de uma integração inteira, testada em drill, com acesso restrito e conhecido por mais de um analista.

O timeout de aprovação merece desenho cuidadoso, porque aprovação que nunca expira vira gargalo silencioso em madrugada, e expiração mal desenhada vira aprovação por omissão. O padrão recomendado é timeout de 15 minutos para alto impacto, com escalonamento para o próximo nível de plantão antes de expirar, e fallback de monitoramento aumentado quando ninguém responde.

5. Exemplo de Playbook de Resposta a IOC

O playbook abaixo mostra a decisão automática para casos de baixo impacto e a aprovação humana para alto impacto, implementando o padrão adaptativo do AUT.5.5 em formato textual auditável.

Playbook: Resposta a IOC confirmado (confiança >= 80%)
Gatilho:  IOC confirmado no TIP com confiança >= 80% e fonte primária
          ou IOC de fonte secundária com correlação interna no SIEM
Passo 0:  Consultar lista de isenção de ativos críticos
          |__ Alvo protegido: aprovação humana obrigatória em qualquer cenário
          |__ Alvo comum: seguir classificação de impacto
Classificação de impacto:
Baixo  (IP externo, domínio, hash sem host interno associado)
  Ação 1: bloquear no firewall, proxy e DNS via API
  Ação 2: criar caso com evidências e dossiê do IOC
  Ação 3: notificar canal do SOC com resumo das ações
Alto   (host interno, conta de usuário, faixa de IP, sessão de VPN)
  Ação 1: criar caso de alta prioridade com dossiê de contexto
  Ação 2: enviar solicitação de aprovação ao analista sênior
          |__ Aprovado em até 15 min: executar ação classificada
              (isolamento, desativação, revogação) e registrar aprovador
          |__ Expirado: manter monitoramento aumentado e escalar para
              coordenador de plantão com dossiê pronto
Saída:    Registro completo de quem autorizou, quando, qual ação, em qual
          alvo e qual efeito observado, com caminho de rollback anexado

A diferença entre os dois ramos não é tecnologia, e sim governança expressa em código. O ramo automático só existe porque a combinação de alta confiança, fonte primária e baixo impacto foi discutida, documentada e aprovada na governança. Qualquer mudança nesse tripé devolve a ação para o ramo humano até nova decisão.

6. Registro e Auditoria de Ações Automáticas

Toda ação automática gera registro estruturado que responde, anos depois, às perguntas de auditoria: quem autorizou, quando, o que foi executado, em qual alvo e com qual efeito. O registro vai para o caso, para o log centralizado do DAT.4 e para o relatório de conformidade, em formato legível por máquina. O exemplo abaixo ilustra o padrão mínimo de evento.

{
  "acao": "block_ip",
  "ioc": "203.0.113.55",
  "confianca": 0.86,
  "playbook": "PB-IOC-RESP-01",
  "versao_playbook": "1.4.2",
  "decisao": "automatica_baixo_impacto",
  "autorizado_por": "guardrail_baixo_impacto",
  "aprovador_humano": null,
  "alvo": "fw-edge-01",
  "executado_em": "2025-03-08T14:22:31Z",
  "efeito": "regra 1041 adicionada, tráfego bloqueado",
  "reversivel": true,
  "rollback": "remover regra 1041 via PB-ROLLBACK-01"
}

O campo de aprovador humano é nulo no exemplo justamente porque a decisão foi automática, e qualquer decisão humana deve registrar o nome nominal e o carimbo de tempo da aprovação. Esses eventos alimentam as métricas da seção 7 e sustentam a revisão mensal em que o time amostra ações para conferência de qualidade. Auditoria que nunca é lida degrada em log decorativo, e por isso a amostragem é compromisso de calendário, e não boa intenção.

7. Métricas de Resposta Automatizada

Tempo de contenção é a métrica que justifica o controle, mas a taxa de reversão é a que o protege. Um playbook rápido que erra duas vezes por semana perde a autorização social para operar, mesmo com métrica de velocidade bonita. Publique as duas juntas em todo relatório executivo.

8. Relação com IR.x e com a Simulação de Resposta

Os playbooks do AUT.5 são a execução automatizada dos procedimentos definidos nos controles de resposta a incidentes do grupo IR.x, e não substituição deles. O processo de resposta define quando conter, quem decide e como comunicar; o playbook apenas executa a parte mecânica com mais velocidade e com trilha completa. Manter os dois documentos alinhados é trabalho de governança, porque procedimento que diverge do playbook cria duas verdades sobre a mesma ação.

A simulação de resposta do grupo SIM.x é o campo de prova dessa automação. Cada drill de phishing, C2 ou movimento lateral deve exercitar os guardrails, a lista de isenção, o timeout de aprovação e o kill switch, e não apenas a detecção. O drill que revela aprovação parada em fila de e-mail por quarenta minutos gera ajuste de processo tão importante quanto a lacuna de detecção que revelaria. A regra é simples: automação que nunca foi simulada não está em produção, está em teste disfarçado.

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

A progressão de níveis acompanha a matriz da seção 3, e o salto crítico é do AUT.5.2 para o AUT.5.3, quando a ação passa a tocar hosts. Antes desse salto, a lista de isenção precisa estar populada, o rollback testado e o drill de isolamento executado com o EDR real. Nível avançado sem esses três pré-requisitos é acidente agendado.

10. Erros Comuns e Pontos de Atenção

• Automatizar ação destrutiva sem freio: desativação em massa de contas ou bloqueio de faixa inteira sem aprovação converte falso positivo em incidente operacional; a matriz da seção 3 existe para impedir exatamente isso.
• Ninguém sabe desligar a automação: kill switch não testado é ilusão; execute drill de desligamento e garanta que duas pessoas sabem acioná-lo a qualquer hora.
• Lista de isenção desatualizada: ativo novo crítico sem exceção cadastrada é alvo da próxima contenção errada; integre a lista ao processo de mudança do INS.1.
• Auditoria sem aprovador: registro que não guarda quem autorizou anula a função de auditoria e transfere a culpa para a plataforma.
• Confiança cega no score do IOC: automação que bloqueia qualquer IOC acima do limiar, sem checar a fonte, bloqueia o que a fonte rotulou mal; exija fonte primária ou correlação interna.
• Contenção antes de evidência: isolamento imediato apaga sessão e memória que a forense precisaria; alinhe com o IR.x quais cenários preservam evidência antes de conter.
• Automação sobre processo imaturo: playbook que reflete processo de resposta confuso apenas erra mais rápido; estabilize o manual antes de automatizar.

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

O AUT.5 é o ponto em que a inteligência vira ação, e por isso toca praticamente todos os grupos do framework. Ele consome detecções do AUT.3 e do grupo DET, decisões orquestradas do AUT.1, inventário crítico do INS.1 para as isenções e contexto do TIP do PLT.1 sobre a confiança de cada IOC. Suas execuções alimentam os casos do IR.x com evidência e timeline, geram métricas para o grupo MET.x e recebem prova de fogo das simulações do grupo SIM.x. O resultado é uma esteira auditável que vai do indicador compartilhado à contenção executada, com decisão humana registrada em cada ponto de risco.