AUT.1 - Orquestração com SOAR

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.1, com os subcontroles AUT.1.1 a AUT.1.5.
Posiciona o SOAR como motor de orquestração que conecta SIEM, EDR, TIP, serviços de reputação e gestão de casos, escalando CTI e Threat Hunting além do esforço manual.

1. Contexto e Posicionamento no Framework CTH

A velocidade é fator decisivo no enfrentamento de ameaças modernas, e processos puramente manuais não sustentam o volume de alertas, a complexidade das investigações e a exigência de resposta rápida. O SOAR (Security Orchestration, Automation and Response) automatiza tarefas repetitivas, orquestra fluxos que atravessam múltiplas ferramentas e reduz o dwell time de dias para minutos. Sem essa camada, o analista consome o turno em atividades mecânicas, como copiar indicadores entre consoles, consultar manualmente serviços de reputação e abrir tickets, em vez de dedicar tempo à análise que exige raciocínio humano.

No Framework CTH, o AUT.1 é o controle central do grupo AUT e atua em conjunto com o AUT.2, que cobre automações leves de integração, com o AUT.3, que industrializa as detecções produzidas pelo hunting, e com o AUT.5, que governa a resposta automatizada. A eficácia do SOAR depende da telemetria centralizada pelo grupo DAT e das plataformas do grupo PLT, porque todo fluxo automatizado herda a qualidade dos dados que consome. A adoção recomendada é progressiva: primeiro enriquecimento e triagem, depois orquestração semi-automatizada de incidentes e, por fim, playbooks adaptativos que ajustam a resposta conforme a confiança do IOC e a criticidade do ativo.

2. Orquestração, Automação e Resposta

Os três termos que formam o nome SOAR descrevem capacidades distintas e frequentemente confundidas. Distingui-los com precisão evita promessas de projeto mal calibradas e delimita o escopo de cada playbook antes da implementação. A tabela a seguir fixa o vocabulário usado nesta nota e nas demais do grupo AUT.

Uma plataforma SOAR madura combina construtor visual de workflows, gerenciador de casos, biblioteca de integrações via API e execução paralela de ações. O gerenciador de casos merece atenção especial, pois entrega um contêiner de investigação com timeline, artefatos, anotações e evidências, o que preserva o contexto para auditoria e para a troca de turno. A regra prática de divisão de trabalho é simples: automatize o mecânico, orquestre o multi-ferramenta e mantenha humano o julgamento analítico.

Há espaço legítimo para o manual, e reconhecê-lo evita automação por modismo. Investigação nova sem padrão conhecido, resposta a incidente complexo e decisão de negócio sobre disponibilidade de serviço continuam sendo território humano. O SOAR se paga justamente quando devolve tempo para essas atividades de maior valor.

3. Componentes da Plataforma e Candidatos à Automação

Antes de desenhar playbooks, o time precisa conhecer os blocos funcionais da plataforma e mapear onde o tempo humano está sendo gasto. Um inventário simples de duas semanas, anotando tarefas repetitivas e minutos consumidos, fornece a lista priorizada de candidatos. O critério de priorização combina volume, tempo por execução, estabilidade do processo e risco de erro humano.

Os candidatos clássicos à automação inicial são enriquecimento de IOCs, triagem de alertas de alta prioridade, notificação de alertas críticos, fechamento assistido de falso positivo e geração de relatórios de situação. Contenção automática aparece em seguida, quando as métricas de erro estabilizam e os guardrails do AUT.5 estão definidos. Essa ordem protege a confiança do time na automação, que é o ativo mais difícil de reconstruir após um incidente causado por fluxo mal testado.

4. Casos de Uso em CTI e Threat Hunting

O retorno mais rápido do SOAR aparece em padrões que atacam minutos mecânicos por ação, os quais, multiplicados por centenas de eventos diários, representam horas de capacidade devolvida ao time. Os casos abaixo são implementáveis em semanas e se apoiam apenas nas integrações básicas do AUT.1.2. Cada um deles já foi validado em operações reais de SOC de médio porte.

• Enriquecimento automático de IOC na abertura do caso: ao criar o caso, o playbook consulta reputação externa, o TIP interno, o SIEM por ocorrências históricas e o GeoIP, gravando um dossiê estruturado na timeline antes do primeiro clique do analista.
• Triagem inicial de phishing: o e-mail reportado chega por webhook, cabeçalhos, URLs e anexos são extraídos, anexos vão para sandbox e URLs para reputação, e o veredito preliminar classifica o caso como spam, phishing simulado ou ameaça real.
• Fechamento assistido de falso positivo: quando o fluxo reconhece padrão conhecido de ruído, como varredura interna de vulnerabilidade, propõe template de fechamento com justificativa pré-preenchida, mantendo a decisão humana no clique final.
• Alimentação da fila de hunting: achados anômalos sem regra determinística são agrupados e enviados como candidatos de hipótese ao backlog do hunting, conectando o SOC ao TH de forma contínua e rastreável.
• Coleta forense assistida: diante de host suspeito, o fluxo aciona a API do EDR para reunir processos, persistência e artefatos de rede em um pacote único, encurtando o início da investigação.

5. Estrutura de um Playbook e Exemplos

Todo playbook expressa cinco componentes estruturais, independentemente da plataforma escolhida. O gatilho define o que inicia o fluxo, as condições filtram e roteiam a execução, as ações chamam ferramentas, as decisões ramificam o caminho com lógica condicional e as saídas formalizam o resultado com notificação, ticket ou encerramento. Documentar esses cinco elementos fora do canvas garante que o conhecimento sobreviva a trocas de equipe e facilita a revisão de governança.

Playbook: Enriquecimento de IOC na abertura de caso
Gatilho:  Webhook da plataforma de gestão de incidentes (novo caso criado)
Condição: Artefato do caso é IP público, domínio, URL ou hash
          (IPs internos RFC 1918 são ignorados e marcados como fora de escopo)
Ação 1:   Consultar serviço de reputação externa (score, detecções, primeiro e último visto)
Ação 2:   Consultar TIP interno por contexto de campanha e ocorrências anteriores
Ação 3:   Consultar SIEM por presença do artefato nos últimos 30 dias
Decisão:  Detecções >= 10 E ocorrências internas > 0
          |__ Verdadeiro: classificar como malicioso confirmado
          |__ Falso: classificar como requer análise humana
Ação 4:   Gravar resumo estruturado na timeline do caso
Saída:    Notificar canal do SOC e aplicar etiqueta de prioridade ao caso
Tempo alvo de execução: 60 segundos por caso

O exemplo anterior ilustra o padrão de enriquecimento, o mais seguro para começar porque não altera nada no ambiente, apenas informa. O segundo padrão recomendado é a triagem, que já decide classificações, mas ainda delega a ação ao analista. Contenção direta entra por último, herdando os guardrails do AUT.5.

Playbook: Triagem inicial de e-mail reportado como phishing
Gatilho:  Mensagem encaminhada à caixa dedicada de reporte (webhook do mail gateway)
Ação 1:   Extrair remetente, cabeçalhos, URLs e anexos da mensagem original
Condição: Há anexo executável?
          |__ Sim: enviar à sandbox e aguardar veredito antes de seguir
          |__ Não: seguir direto para análise de URLs
Ação 2:   Verificar cada URL contra serviço de reputação e TIP interno
Ação 3:   Buscar remetente e domínio no SIEM por outros destinatários nas últimas 24 horas
Decisão:  URL maliciosa OU veredito de sandbox malicioso
          |__ Verdadeiro: criar caso, etiquetar phishing confirmado e listar destinatários que clicaram
          |__ Falso: etiquetar falso positivo, responder ao repórter e encerrar assistido
Saída:    Responder ao repórter, notificar o canal do SOC e anexar evidências ao caso

Triagem e enriquecimento compartilham a mesma espinha dorsal de gatilho, condições, ações e decisões, mudando apenas o grau de autonomia. Antes de publicar qualquer playbook, execute no mínimo vinte execuções em ambiente de teste e documente os falsos positivos observados. Esse histórico vira a linha de base que a governança usa para autorizar a entrada em produção.

6. Métricas de Automação

Automatizar sem medir é executar processos opacos em escala, e o painel de métricas é o contraponto do entusiasmo com a tecnologia. Cada playbook precisa de painel próprio, alimentado pela plataforma ou exportado para a ferramenta de observabilidade do time. As métricas mínimas estão na tabela a seguir e devem ser revisadas na governança mensal.

Meça uma linha de base manual antes de implantar cada playbook, porque sem ela a economia vira argumento de opinião. Registre também o custo de manutenção dos fluxos, pois um playbook que consome horas de ajuste por semana pode evaporar o benefício nominal. Publicar essas métricas para o patrocínio executivo do CTI.1 sustenta o financiamento contínuo da automação.

7. Riscos da Automação Mal Governada

O risco mais grave é o bloqueio errado, quando um falso positivo dispara contenção em massa e interrompe serviços legítimos de produção, transformando o SOC em origem do incidente. O segundo risco estrutural é a dependência de API que muda, já que integrações quebram silenciosamente quando o fornecedor altera versão, autenticação ou campos de resposta. Somam-se as falhas silenciosas, fluxos que param de executar sem alerta, e a automação de processos mal definidos, que apenas acelera o erro com fidelidade industrial.

Esses riscos não argumentam contra o SOAR, mas contra a implantação sem freio. A defesa é arquitetural: ambientes de teste, limites de taxa, aprovação por nível de impacto e monitoramento ativo de execuções. Um playbook que gera ação com efeito no ambiente deve sempre ter trilha de auditoria e caminho de reversão conhecidos antes de entrar em produção.

8. Governança de Playbooks

Governança é o conjunto de práticas que mantém a automação saudável ao longo do tempo, e não um documento formal arquivado. Sem dono, revisão e histórico, um catálogo de playbooks degrada em dívida técnica que ninguém confia. As cinco práticas mínimas estão na lista a seguir.

• Versionamento no repositório: exporte o workflow para Git, com commits vinculados a chamados, permitindo comparar versões e reverter com segurança.
• Dono nominal por playbook: um analista responsável pela saúde, pelos limiares e pelo ciclo de revisão, registrado no catálogo.
• Revisão programada, tipicamente trimestral: verificação de integrações, limiares, relevância do caso e taxas de erro acumuladas.
• Ambiente de teste: execução com dados sintéticos ou cópia filtrada antes de produção, obrigatória para qualquer mudança de lógica.
• Changelog obrigatório: descrição de motivação, impacto, testes executados e plano de rollback registrada a cada alteração.

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

O avanço de nível só deve ocorrer com as métricas da seção 6 estáveis por pelo menos um ciclo de revisão. Tentar saltar do básico para contenção adaptativa sem histórico de erro é a receita clássica do bloqueio errado descrito na seção 7. Cada subida de nível deve ser aprovada na governança com evidência de testes.

10. Erros Comuns e Pontos de Atenção

• Automatizar antes de documentar o processo: fluxo que replica processo confuso apenas acelera o caos; desenhe e estabilize o processo manual primeiro.
• Tratar o SOAR como substituto da gestão de incidentes: o SOAR orquestra e executa, mas o registro canônico do caso permanece na plataforma de incidentes.
• Lógica de negócio escondida no canvas: regras críticas invisíveis tornam o conhecimento indivíduo-dependente; documente a lógica fora da plataforma.
• Ignorar limites de API: fluxos que estouram rate limit em picos falham exatamente quando mais necessários; use cache, lote e fila.
• Playbook sem plano de desligamento: todo fluxo precisa de kill switch documentado e testado, capaz de interromper execuções em minutos.
• Enriquecimento como fim: dossiê bonito que ninguém lê é custo; alinhe o enriquecimento às EEI definidas no processo de CTI.
• Dependência individual: conhecimento concentrado em quem construiu os fluxos é risco de continuidade; exija documentação e segunda pessoa treinada.

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

O AUT.1 consome e produz inteligência ao longo de toda a esteira do framework. Ele consome IOCs e contexto dos controles PLT.1 e PLT.2, dispara coletas complementares alinhadas ao DAT.1 e ao DAT.2, aciona o AUT.3 quando a análise valida uma hipótese que merece virar regra Sigma e cede a execução de contenção ao AUT.5, que impõe os guardrails de impacto. Na frente analítica, o enriquecimento padronizado alimenta os controles ANA.x com contexto consistente e entrega candidatos à fila de hunting governada pelos controles TH.x, fechando o ciclo entre SOC, CTI e Threat Hunting com trilha auditável do alerta à resposta.