CTI-LLM (Processamento, Análise e Defesa em Um Modelo)

Nota de abertura da pasta de LLMs do capítulo 17, dedicada à automação do ciclo de CTI.
Apresenta a proposta CTI-LLM, um modelo de linguagem único ajustado para processar, analisar e apoiar a defesa sobre conteúdo de inteligência de ameaças.
Dialoga com AUT.4 (Machine Learning e AI para Hunting), com o pipeline de coleta e enriquecimento da seção 02 e com a nota de geração de regras Sigma deste mesmo capítulo.

1. Contexto e Posicionamento na Biblioteca

O ciclo de inteligência descrito na seção 01 da biblioteca depende de etapas manuais intensivas: ler relatos de fornecedores, recortar indicadores, classificar técnicas, redigir resumos e responder perguntas dos clientes internos. Cada uma dessas etapas consome horas de analista sênior e cria gargalos entre a coleta da seção 02 e a análise da seção 05. A proposta CTI-LLM ataca exatamente esse gargalo ao concentrar várias dessas tarefas em um único modelo de linguagem ajustado ao domínio, em vez de encadear ferramentas especializadas heterogêneas.

Esta nota posiciona o modelo como fundamento conceitual das demais notas da pasta: IntelForge decompõe o problema em agentes especializados, LLMCloudHunter converte o conteúdo extraído em regras de detecção cloud, e a nota de Sigma generaliza esse último passo. Entender o desenho de um modelo único, com suas vantagens e limites, é pré-requisito para avaliar quando a decomposição multi-agente vale o custo adicional de operação.

2. A Proposta do Modelo Único para o Ciclo

A tese central de CTI-LLM é que as tarefas do ciclo de inteligência compartilham uma mesma matéria-prima, o texto técnico de ameaças, e que um modelo único ajustado a esse domínio pode executá-las com qualidade aceitável sem trocar de sistema a cada etapa. Em vez de um extrator de IOCs baseado em expressões regulares, um classificador de técnicas treinado separadamente e um sumarizador genérico, o time opera um modelo que recebe o relato bruto e devolve, conforme o comando, o indicador extraído, a técnica classificada ou o resumo executivo.

Essa concentração traz três ganhos operacionais imediatos. Primeiro, a manutenção reduz a uma infraestrutura de inferência e a um ciclo de ajuste fino, em vez de meia dúzia de pipelines com dependências distintas. Segundo, o contexto compartilhado melhora a consistência, pois a mesma representação interna que extrai um domínio também participa da classificação da técnica que o usou. Terceiro, a curva de aprendizado do analista encurta, já que a interface de uso é sempre a mesma: texto de entrada, comando de tarefa, saída estruturada.

3. Tarefas Suportadas

A tabela abaixo resume as tarefas típicas atribuídas ao modelo, com o insumo esperado e o produto entregue ao fluxo de CTI. O conjunto cobre processamento de dados brutos, análise propriamente dita e apoio à defesa, os três eixos da proposta.

Duas observações de engenharia merecem destaque na prática. A extração de IOCs convive mal com técnicas de evasão como defanging, e o ajuste fino em corpora de CTI ensina o modelo a reconhecer variantes como domínios entre colchetes e IPs fragmentados, coisa que regex simples omite. A resposta a perguntas exige ancoragem em trechos recuperados do corpus, no estilo retrieval-augmented, pois o modelo ajustado responde melhor sobre o texto fornecido do que de memória paramétrica, reduzindo o risco de inventar indicador que não existe na fonte.

A resposta a perguntas merece exemplo próprio porque é a tarefa mais sensível ao desenho de recuperação. Quando o analista pergunta qual foi o mecanismo de persistência usado na campanha X, o sistema primeiro recupera os trechos relevantes do corpus por busca vetorial, depois entrega esses trechos ao modelo como contexto restrito e exige resposta com citação. Sem a etapa de recuperação, o modelo responde de memória e mistura campanhas semelhantes, erro frequente em domínios com padrões de infraestrutura repetidos entre atores diferentes.

4. Arquitetura: Modelo Base e Fine-Tuning em Corpora de CTI

A arquitetura de referência combina um modelo base aberto de porte médio, na faixa de 7 bilhões de parâmetros, com ajuste fino supervisionado em corpora públicos e privados de CTI. O corpus de treino reúne relatórios de laboratórios, posts de pesquisadores, feeds técnicos e bases anotadas como a coletânea APTnotes e conjuntos com técnicas ATT&CK rotuladas. O resultado é um modelo especializado que mantém a fluência geral da linguagem natural e ganha vocabulário e convenções do domínio, como nomenclatura ATT&CK, formato STIX e convenções de defanging.

O pipeline de preparação segue um desenho típico de ajuste fino por instrução, exemplificado abaixo de forma simplificada. Cada amostra pareia um trecho de relato com a tarefa e a saída esperada, e o treinamento alterna entre as tarefas para evitar que o modelo perca desempenho em uma enquanto melhora em outra.

Fluxo de preparação (visão de alto nível)
1. Coleta: relatórios e feeds em texto, normalização de codificação e limpeza de HTML.
2. Segmentação: divisão em trechos com contexto suficiente, respeitando limite de tokens.
3. Rotulagem: pares de tarefa e saída, com extração assistida e revisão humana por amostra.
4. Mistura de tarefas: proporção controlada entre extração, classificação, resumo e QA.
5. Ajuste fino: treinamento supervisionado com LoRA sobre o modelo base congelado em parte.
6. Avaliação: conjunto de teste separado, com métricas por tarefa e revisão de amostras.
7. Empacotamento: peso final versionado, cartão de modelo e suíte de regressão de prompts.

A escolha do modelo base aberto não é estética, é requisito de operação. Inteligência de ameaças frequentemente envolve conteúdo sensível, com nomes de clientes, indicadores ainda não públicos e avaliações de risco internas, o que inviabiliza o envio desse material a serviços externos. Rodar o modelo ajustado em infraestrutura própria mantém o dado sob controle, alinha-se à proteção de fontes e métodos discutida no controle CTI.10 do framework CTH e evita que o provedor externo incorpore o conteúdo corporativo ao treino do serviço.

A operação diária também precisa de desenho, e não apenas o treino. O empacotamento típico usa um serviço de inferência com fila de requisições, telemetria de latência e log de prompts com retenção controlada, pois o prompt recebido muitas vezes contém o próprio material sensível que motivou a escolha do modelo aberto. A versionamento do peso do modelo, do corpus de treino e do conjunto de prompts de regressão forma o trio que permite reprodutibilidade, e cada nova versão deve passar pela suíte de avaliação antes de substituir a anterior na fila de processamento dos feeds.

5. Resultados Reportados e Limitações

Os resultados reportados nas avaliações do tipo, quando comparados com modelos base de mesmo porte sem ajuste, mostram ganhos consistentes nas tarefas de extração e classificação sobre texto de CTI, com melhor aderência ao formato de saída pedido e menor taxa de alucinação de indicadores. O resumo também melhora em fidelidade terminológica, usando os termos do domínio com precisão. Em contrapartida, o porte médio impõe limites claros: raciocínio longo de várias etapas degrada, janela de contexto restringe relatos muito extensos a estratégias de segmentação e tarefas que exigem conhecimento factual além do corpus podem herdar lacunas dele.

As limitações operacionais pesam tanto quanto as técnicas. O modelo não substitui o juízo analítico da seção 05, pois extrai e classifica o que está no texto, sem avaliar credibilidade da fonte nem resolver contradições entre relatos. A data de corte do corpus congela o conhecimento, exigindo ciclos de re-treino ou anexação de conteúdo recente. E qualquer saída segue para consumo humano ou para downstream com validação obrigatória, porque indicador inventado que entra no TIP vira falso positivo em produção, problema tratado em detalhe na nota de validação deste capítulo.

Uma limitação sutil merece registro porque confunde equipes na avaliação inicial: o modelo tende a reproduzir o viés do corpus de treino. Se a maioria dos relatos rotulados descreve ataques a Windows em inglês, o desempenho cai de forma invisível sobre relatos de Linux, macOS ou em outro idioma, e a queda só aparece quando a avaliação é estratificada. A recomendação prática é medir por segmento de texto, separando idioma, plataforma e estilo de fonte, e publicar as métricas por segmento no cartão do modelo para que o consumidor saiba onde confiar menos.

As métricas de avaliação por tarefa estruturam a suíte de regressão citada na seção 4 e dão ao programa um contrato objetivo de qualidade. O exemplo abaixo define limiares de referência típicos para aceitar uma nova versão, valores que cada time deve calibrar contra o próprio baseline manual.

6. Comparação com Pipelines Tradicionais

O pipeline tradicional de processamento de CTI combina regex e listas de padrões para indicadores, classificadores menores como naive Bayes ou gradient boosting para categorização e templates para resumo. Essa abordagem é determinística, barata de executar e totalmente explicável, e continua sendo a escolha correta quando o formato de entrada é estável e o vocabulário é fechado. O custo aparece quando o texto varia: relato informal de pesquisador, relatório com formatação exótica, gíria de fórum, e cada variação nova exige manutenção das expressões regulares.

A tabela abaixo contrasta os dois desenhos nos critérios que importam para decisão de arquitetura. A leitura prática é de complementaridade e não de substituição absoluta: muitos programas mantêm regex para o caso trivial e modelo ajustado para o material difuso, com um roteador de entrada que decide o caminho por heurística simples.

A decisão por modelo único, por decomposição multi-agente como no IntelForge ou por híbrido determinístico e generativo deve partir do volume, da criticidade e do perfil das fontes. Volume alto de feeds bem formatados com orçamento apertado favorece pipeline tradicional com bolsões de LLM. Volume moderado de relatos longos e heterogêneos com equipe pequena favorece o modelo único. A nota seguinte da pasta explora o meio termo, em que agentes especializados colaboram sobre cada indicador.

Um terceiro desenho, híbrido, costuma ser o ponto de chegada real dos programas maduros. Nele, o pipeline tradicional executa a primeira passagem barata e determinística sobre todos os itens, e o modelo ajustado recebe apenas o que ficou classificado como difuso, ambíguo ou sem padrão reconhecível. Esse roteamento reduz o custo total de inferência em ordem de grandeza nos feeds de alto volume, reserva a capacidade do modelo para o material que realmente exige compreensão de texto e mantém a trilha de auditoria simples, porque cada item carrega o caminho processado, se por regra ou por modelo, com a versão usada.

7. Exemplo de Prompt de Extração Estruturada

O prompt abaixo ilustra o padrão de comando usado para extração estruturada com o modelo ajustado, incluindo as salvaguardas que evitam alucinação: proibição de inferência além do texto, saída somente em JSON e campo de evidência para auditoria. O mesmo padrão serve para as demais tarefas da tabela da seção 3, mudando o schema.

Sistema: você é um extrator de inteligência de ameaças. Processe o relatório
abaixo e devolva SOMENTE JSON válido, sem texto extra, no schema:
{"iocs": [{"type": "ip|domain|hash|url|email", "value": "", "evidence": ""}],
 "techniques": [{"attck_id": "", "name": "", "evidence": ""}],
 "malware": [{"name": "", "evidence": ""}],
 "actors": [{"name": "", "evidence": ""}]}
Regras: use apenas valores presentes no texto; se um campo não tiver ocorrências,
devolva lista vazia; preserve o defanging do texto original; cada item precisa
de evidence com a frase de origem; não traduza nem corrija os valores.

Usuário: [texto do relatório]

Saída esperada (trecho):
{
  "iocs": [
    {"type": "domain", "value": "cdn-update[.]example-top[.]com",
     "evidence": "comunicação com cdn-update[.]example-top[.]com na porta 443"}
  ],
  "techniques": [
    {"attck_id": "T1053.005", "name": "Scheduled Task",
     "evidence": "persistência via tarefa agendada criada com schtasks /create"}
  ],
  "malware": [], "actors": []
}

O trecho de saída ilustra três convenções que reduzem retrabalho downstream. A evidência preserva a frase original, permitindo que o revisor confirme cada item com busca local. O defanging é mantido para que o JSON não se torne clicável em tickets e e-mails. E as listas vazias explícitas distinguem o campo ausente da omissão do modelo, o que facilita a validação por schema antes da carga no MISP ou no OpenCTI.

8. Erros Comuns e Pontos de Atenção

• Tratar a saída como verdade sem revisão: o modelo reduz erro, mas não zera, e todo item extraído precisa de conferência contra a fonte antes de entrar no TIP ou em regra de detecção.
• Ajustar fino com corpus pequeno e desbalanceado: milhares de amostras por tarefa e mistura equilibrada evitam que o modelo aprenda a responder "lista vazia" com frequência anômala ou viesado a um único tipo de relato.
• Ignorar a data de corte: relato recente tratado com modelo desatualizado gera lacunas silenciosas; registre a data de corte no cartão do modelo e monitore fontes novas.
• Misturar defanged e reconstituído no mesmo campo: padronize o formato de saída por convenção do programa, porque indicador ativo vazando em relatório interno é incidente à parte.
• Usar o modelo como oráculo de atribuição: a proposta processa e classifica texto, e a atribuição de ameaças com suas limitações permanece trabalho analítico da seção 02 do capítulo 5.
• Substituir regex que já funciona: regra determinística barata e explicável para feeds formatados continua correta; reserve o modelo para o material que a regex não cobre.
• Deixar o prompt sem controle de versão: mudança informal de instrução altera a saída em produção; trate prompt como código, com repositório, revisão e suite de regressão.
• Medir só a média geral: média alta pode esconder segmento ruim; avalie sempre por idioma, plataforma e tipo de fonte antes de liberar a versão.

9. Integração com o Restante da Biblioteca

A saída do modelo único alimenta diretamente o pipeline de enriquecimento da seção 02 do capítulo 2, que agrega contexto de reputação e infraestrutura aos indicadores extraídos, e a plataforma de gerenciamento descrita em PLT.1 e PLT.2 do framework CTH, onde o item revisado ganha ciclo de vida e pontuação de qualidade. O mapa de técnicas ATT&CK produzido nas extrações sustenta o controle CTI.6 do grupo ANA e as lacunas de detecção analisadas no grupo MAP, fechando o caminho do relato bruto até a decisão de cobertura.

Nas notas seguintes da pasta, o desenho de modelo único é estendido: IntelForge distribui as tarefas entre agentes com papéis distintos e verificações cruzadas, LLMCloudHunter especializa a conversão de TTPs em consultas de detecção para ambientes cloud, e a nota de Sigma formaliza o padrão de extração e geração de regras com validação automatizada. Juntas, as quatro notas formam a visão de automação do lado de CTI do capítulo 17, antes da virada para agentes autônomos de hunting na pasta seguinte.