AUT.2 - Automação com Plataformas de Workflows (n8n)

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.2, com os subcontroles AUT.2.1 a AUT.2.5.
Apresenta plataformas low-code de workflow, com foco no n8n, como complemento do SOAR para integrações leves, ingestão de feeds e automação de CTI de ponta a ponta.

1. Contexto e Posicionamento no Framework CTH

Plataformas de automação de fluxos de trabalho complementam o SOAR fornecendo automação leve e flexível para integrações que não justificam um playbook completo de resposta. Enquanto a plataforma SOAR é otimizada para workflows de segurança complexos, com gestão de caso e trilha de auditoria, as plataformas de workflow brilham em tarefas de CTI como ingestão de feeds, geração de relatórios, sincronização de dados entre plataformas e gatilhos de webhook que conectam sistemas heterogêneos. O AUT.2 formaliza essa camada de encanamento da inteligência, mantendo a cadeia de CTI automatizada e atualizada sem sobrecarregar a plataforma de resposta.

No Framework CTH, o AUT.2 opera imediatamente abaixo do AUT.1 na pilha de automação e alimenta diretamente os controles PLT.1, PLT.2 e DAT.4 com dados normalizados. O controle não exige uma ferramenta específica, mas o n8n consolidou-se como escolha recorrente em times de segurança pela combinação de auto-hospedagem, custo acessível e amplitude de integrações. As salvaguardas por nível seguem do básico, com ingestão validada, até o avançado, com pipeline de CTI completo e notificação proativa sobre ameaças relevantes.

2. O Que São e Por Que o n8n Conquistou os Times de Segurança

Plataformas de workflow low-code permitem montar automações conectando nós visuais que representam chamadas de API, transformações de dados e lógica, sem escrever aplicações inteiras. O modelo reduz a barreira de entrada para analistas, sem impedir o programador de inserir código quando a lógica exige, recurso conhecido como escape hatch. O resultado é um meio-termo produtivo entre scripts avulsos em cron e plataformas corporativas pesadas.

O n8n conquistou espaço em times de segurança por razões objetivas, que vale explicitar para embasar a decisão de arquitetura. A implantação é auto-hospedada em Docker, o que mantém feeds, IOCs e credenciais dentro do perímetro da organização, requisito comum em políticas de dados. A biblioteca inclui centenas de integrações nativas, além do nó HTTP Request, que alcança qualquer API REST, e do nó Code, que executa JavaScript ou Python para adaptar formatos incompatíveis. O custo é previsível, baseado em infraestrutura própria, em contraste com licenças de SOAR cobradas por execução ou por usuário, que escalam mal quando a automação cresce.

3. Arquitetura Básica: Nós, Gatilhos e Fluxos

Um fluxo n8n é um conjunto de nós conectados que processam itens, onde cada item é um objeto JSON que atravessa a cadeia. A execução começa por um gatilho, prossegue pelos nós de transformação e integração e termina em uma saída, que pode ser uma notificação, uma gravação em banco ou um webhook de retorno. As credenciais ficam cifradas no banco da instância e são referenciadas pelos nós, nunca embutidas na lógica do fluxo.

Para escala, a instância pode operar em modo fila com workers dedicados, separando a interface dos executores e suportando centenas de execuções por minuto. O fluxo é exportável em JSON, o que permite versionar o encanamento em Git e revisar mudanças como qualquer código. Esse par de características, escala e versionamento, é o que permite tratar o n8n como infraestrutura, e não como coleção de scripts improvisados.

4. Casos Práticos em CTI e Threat Hunting

• Coleta agendada de feeds com parse e envio ao TIP: um Schedule Trigger baixa listas de fontes públicas, o fluxo normaliza tipo, valor e confiança, descarta duplicatas e endereços privados, e grava os atributos no MISP com etiqueta de fonte.
• Triagem de e-mail reportado de phishing: um gatilho de caixa dedicada extrai remetente, cabeçalhos, URLs e anexos, consulta reputação e TIP e responde ao repórter com classificação preliminar.
• Enriquecimento de alerta consultando MISP e VT e GeoIP: ao receber alerta do SIEM via webhook, o fluxo consulta o TIP interno, o serviço de reputação de arquivos e a localização de rede, devolvendo um dossiê compacto ao caso.
• Notificação segmentada: um fluxo classifica eventos por severidade, ativo afetado e turno, e roteia a notificação para o canal correto, evitando tanto o silêncio quanto o ruído de listas gigantes de distribuição.

Esses quatro padrões cobrem a maioria das necessidades iniciais de um time de CTI e são implementáveis em semanas. Cada um deles é idempotente por construção quando as chaves naturais são respeitadas, o que permite reexecuções seguras após falha parcial. A regra de projeto é manter cada fluxo com um único propósito, facilitando revisão, métrica e desligamento.

5. Exemplo de Fluxo Passo a Passo

O primeiro fluxo demonstra o padrão de ingestão de feed, o mais usado na prática e o ponto de entrada do AUT.2.2. Os nós aparecem na ordem de execução, com a lógica de ramificação indentada.

Fluxo n8n: Ingestão agendada de feed de IOC para o TIP
Nó 1  Schedule Trigger   executa a cada 6 horas
Nó 2  HTTP Request       baixa o feed CSV de uma lista pública (URL com token)
Nó 3  Extract From File  converte o CSV em itens, uma linha por registro
Nó 4  IF                 descarta IP privado, wildcard e duplicata já vista hoje
        |__ Rejeitado: acumula em contador de rejeições por motivo
Nó 5  Code               normaliza para {type, value, confidence, source, tlp}
Nó 6  Set                adiciona metadados de coleta (data, versão do fluxo, fonte)
Nó 7  HTTP Request       envia lote de atributos ao MISP criando evento etiquetado
Nó 8  IF                 proporção de atributos aceitos abaixo de 50% do esperado?
        |__ Sim: Error Trigger do fluxo dispara alerta no canal de automação
Nó 9  Slack              publica resumo (recebidos, aceitos, rejeitados, motivos)
Nó 10 PostgreSQL         grava linha de log de execução para métricas do fluxo

Repare que os nós 8 a 10 existem para operação, não para a função principal. Esse é o padrão que separa automação amadora de automação mantida: falha notificada, métrica registrada e histórico consultável. Um fluxo sem observabilidade é uma bomba-relógio silenciosa na cadeia de inteligência.

O segundo fluxo cobre a triagem de phishing reportado, que conecta o AUT.2 ao trabalho diário do SOC.

Fluxo n8n: Triagem de e-mail reportado como phishing
Nó 1  Email Trigger (IMAP)  mensagem encaminhada à caixa de reporte
Nó 2  Code                  extrai remetente, assunto, cabeçalhos, URLs e anexos
Nó 3  IF                    há URL ou anexo para analisar?
        |__ Não: resposta automática pedindo encaminhamento correto e fim
Nó 4  HTTP Request          consulta reputação de cada URL, em lote
Nó 5  MISP                  busca URLs e domínios no TIP interno
Nó 6  Code                  calcula score preliminar (reputação, TIP, indícios de engenharia social)
Nó 7  IF                    score acima do limiar de suspeita?
        |__ Sim: cria caso na plataforma de incidentes com anexos e cabeçalhos
        |__ Não: responde ao repórter como provável spam e arquiva registro
Nó 8  HTTP Request          notifica canal do SOC com resumo e link do caso
Nó 9  PostgreSQL            grava execução, score e decisão para métricas

6. Padrões de Projeto e Métricas de Workflow

Fluxos longevos seguem padrões de projeto, e não improvisos individuais. A tabela abaixo resume os padrões que mais reduzem incidentes de automação em produção e deve fazer parte da documentação do time.

A observabilidade do encanamento precisa de métricas próprias, tratadas com o mesmo rigor dos playbooks do AUT.1. Sem elas, a queda de um feed só é percebida quando o analista percebe falta de contexto em um caso crítico.

7. Comparação com SOAR Comercial

A leitura correta da tabela é de complementaridade, e não de substituição. O n8n cuida do encanamento de CTI, dos feeds ao relatório, enquanto o SOAR cuida de resposta com gestão de caso e auditoria. Times com orçamento restrito usam o n8n como SOAR de entrada para enriquecimento assistido, desde que contenção automática permaneça fora do escopo até existirem os guardrails do AUT.5.

8. Boas Práticas Operacionais

• Idempotência: projete cada fluxo para reexecutar sem duplicar efeitos, com upsert no TIP por chave natural de tipo, valor e fonte, e gravação única por lote.
• Logs e observabilidade: habilite o salvamento de execuções com dados, configure o Error Trigger para notificar canal dedicado e mantenha painel de duração e taxa de falha por fluxo.
• Gestão de segredos: use variáveis de ambiente ou cofre externo referenciado pela instância, nunca cole credenciais em nós, e revise exportações antes de compartilhar, pois o JSON pode embutir dados sensíveis.
• Limites de taxa: agrupe itens em lotes, aplique throttle e cache nas chamadas a serviços de reputação para respeitar quotas, especialmente em picos de incidente.
• Ambientes e versionamento: mantenha instâncias separadas de desenvolvimento e produção, exporte os fluxos para Git e submeta mudanças a revisão por pares.
• Controle de acesso: habilite RBAC na instância, segrege credenciais por fluxo e use contas de serviço com privilégio mínimo em cada integração.

9. Quando NÃO Usar Workflow Low-Code

Há cenários em que a plataforma errada cria risco maior do que o problema que resolve. Nenhum dos itens abaixo é dogma absoluto, mas cada um pede justificativa explícita na governança antes de prosseguir.

• Playbooks de resposta com gestão de caso, aprovação e trilha regulatória: use o SOAR, que possui auditoria e certificações embutidas.
• Contenção destrutiva automática: ações sobre produção exigem os guardrails e a arquitetura de aprovação do AUT.5, e não improvisos em fluxo genérico.
• Requisito de suporte 24x7 com SLA contratual: auto-hospedagem significa que a indisponibilidade é problema do seu time.
• Integrações exigidas por auditoria externa com conectores certificados: o nó HTTP Request alcança a API, mas não entrega a certificação.
• Time sem dono e sem capacidade de operar: fluxo órfão que falha silenciosamente é pior que o processo manual que ele substituiu.

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

O salto para o nível avançado pressupõe que os fluxos intermediários possuem dono, métrica e revisão consolidados. Pipeline de CTI completo sem observabilidade apenas encadeia pontos únicos de falha. Valide a cadeia inteira com uma simulação mensal de queda de fonte antes de declarar o nível atingido.

11. Erros Comuns e Pontos de Atenção

• Catálogo de fluxos sem dono: crescimento orgânico sem inventário gera encanamento órfão que ninguém se atreve a desligar; mantenha catálogo com nome, propósito e responsável.
• Segredo embutido no nó ou na exportação: credencial vazada em JSON compartilhado é incidente clássico; adote cofre e revisão de exportação.
• Falta de idempotência: reexecução duplica atributos no TIP e corrompe métricas de volume; exija chave natural em toda escrita.
• Falha silenciosa: fluxo morto há semanas, descoberto apenas quando o feed era necessário; Error Trigger e painel de falha são obrigatórios.
• Usar o n8n como SOAR improvisado: contenção automática em plataforma sem gestão de caso e guardrails reproduz os riscos do AUT.1 sem os controles.
• Upgrade sem testes: atualização de versão pode quebrar nós customizados; teste em instância de desenvolvimento e acompanhe o changelog de nós.

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

O AUT.2 é a cola logística entre os controles de plataforma e de dados do framework. Ele alimenta o PLT.1 com atributos normalizados dos feeds, mantém o PLT.2 sincronizado com observáveis e relações, envia indicadores ao DAT.4 para indexação no SIEM e veicula os relatórios que sustentam a disseminação de inteligência do PLT.5 conforme o TLP do material. Quando um fluxo revela padrão que merece detecção permanente, o achado entra no AUT.3 como candidata a regra Sigma, e quando envolve ação com efeito no ambiente, o fluxo deve delegar ao AUT.1 e ao AUT.5, nunca agir por conta própria.