Um Fluxo de Trabalho Estruturado para Transformar Inteligência de Ameaças Cibernéticas em Padrões de Detecção Computáveis

Resumo

Aqui, apresentamos um protocolo para converter indicadores de comprometimento de relatórios de inteligência cibernética, caminhos de arquivos, chaves de registro e indicadores de linha de comando em expressões regulares validadas para regras de detecção de gerenciamento de informações e eventos de segurança (SIEM), usando extração em conjunto com grandes modelos de linguagem (LLMs) e rotulagem de componentes assistida por grafos.

Resumo

Os Centros de Operações de Segurança (SOCs) rotineiramente convertem relatórios de inteligência de ameaças cibernéticas (CTI) em conteúdo de detecção operacional. Um gargalo persistente nesse fluxo de trabalho é a tradução de indicadores extraídos de compromisso (IOCs), especialmente caminhos de arquivo, chaves de registro e cadeias de linha de comando, em expressões regulares implantáveis (regexes) adequadas para incorporação em regras de correlação de segurança e gerenciamento de eventos (SIEM). Embora trabalhos anteriores tenham melhorado a extração automatizada por indicador de compromisso (IOC), transformar cadeias extraídas em padrões regex validados permanece em grande parte manual, requer expertise especializada e é propenso a erros. O objetivo desse protocolo é fornecer um procedimento padronizado e reproduzível para tradução IOC para regex. O fluxo de trabalho é composto por cinco etapas: (1) analisar relatórios CTI heterogêneos em uma representação unificada do Markdown; (2) extração do IOC usando múltiplos grandes modelos de linguagem (LLMs) com votação por consenso; (3) normalização, categorização e deduplicação baseadas em regras dos IOCs extraídos; (4) rotulagem assistida por grafo dos componentes IOC como keep (grupo de captura) ou descarte (grupo não-captura); e (5) geração iterativa de regex com validação diagnóstica contra as strings originais do IOC. Para avaliar a utilidade, o fluxo de trabalho foi aplicado a 3.156 relatórios CTI, e os regex resultantes foram avaliados contra mais de 2.400 sequências de verdade coletadas independentemente de dez cenários de avaliação de Táticas, Técnicas e Conhecimento Comum (MITRE), resultando em uma taxa média de acerto de 99,1% e uma taxa média de incompatibilidade entre o IOC de 0,8%. Portanto, o protocolo documenta uma implementação reproduzível para tradução IOC para regex e delimita explicitamente seu escopo atual, suposições operacionais e casos conhecidos de falha.

Introdução

O cibercrime continua a impor encargos operacionais e financeiros substanciais às organizações dos setores público e privado. Em 2023, as perdas relatadas devido ao cibercrime nos Estados Unidos ultrapassaram US$ 12,5^bilhões, destacando a escala e persistência da atividade maliciosa. Dentro desse cenário, os Centros de Operações de Segurança (SOCs) atuam como as principais unidades operacionais responsáveis por detectar, analisar e responder a ameaças em tempo real.
A lógica de detecção em muitos fluxos de trabalho SOC é implementada por meio de mecanismos baseados em regras dentro das plataformas de Gerenciamento de Informações e Eventos de Segurança (SIEM), que são amplamente utilizadas porque são interpretáveis, determinísticas e compatíveis com fluxos de trabalho SOC existentes. Entre os diferentes tipos de regras, as regras SIEM baseadas em correlação são especialmente importantes para identificar comportamentos de ataque que abrangem múltiplos eventos, hosts e janelas de tempo. Dentro dessas regras, expressões regulares (regexes) funcionam como primitivas de busca reutilizáveis: analistas as incorporam em regras de detecção mais amplas que adicionam restrições de campo, filtros específicos da plataforma e lógica de correlação de eventos, em vez de implantá-las como detectores autônomos.

Na prática, analistas de SOC frequentemente iniciam o desenvolvimento de regras com indicadores de comprometimento (IOCs) derivados de relatórios de inteligência de ameaças cibernéticas (CTI) publicados por fornecedores de segurança, pesquisadores independentes ou bases de conhecimento públicas como o MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK⁾². Essas strings IOC podem incluir caminhos de arquivo, fragmentos de linha de comando, chaves de registro ou outros artefatos estruturados observados durante ataques³. Traduzir essas strings em padrões regex adequados para regras de correlação SIEM é uma tarefa recorrente no fluxo de trabalho de autoria de regras.

Essa etapa de tradução é um gargalo operacional prático. Criar padrões regex que sejam gerais o suficiente para capturar variação significativa, mas precisos o bastante para evitar correspondências não intencionais, requer expertise especializada; pequenos erros sintáticos ou decisões incorretas sobre quais componentes preservar ou generalizar podem tornar uma regra de detecção útil ineficaz. Como esse trabalho é manual, repetitivo e orientado aos detalhes, pode atrasar a implantação da detecção para ameaças emergentes, exigir revisão por analistas mais experientes e contribuir para a carga de trabalho dos analistas em configurações operacionais^{de SOC 4,5}.

O desafio central na tradução de IOC para regex é decidir quais partes de um IOC codificam comportamento estável e relevante para atacantes e, portanto, devem ser preservadas, e quais partes refletem variações específicas do ambiente ou do host e devem ser generalizadas. Por exemplo, raízes canônicas de registros como HKEY_CLASSES_ROOT\CLSID, diretórios de sistema como System32 e nomes executáveis conhecidos como rundll32.exe normalmente precisam permanecer explícitos, enquanto caminhos de perfil de usuário, Identificadores de Segurança específicos do host (SIDs) e Identificadores Globalmente Únicos (GUIDs) normalmente devem ser abstratos. Fazer isso de forma consistente entre tipos heterogêneos de IOC é o que torna a tarefa de tradução não trivial. Ao longo deste protocolo, referimo-nos aos primeiros como componentes preservados ou de grupo de captura, e aos segundos como componentes abstratos ou não-grupos de captura.

Trabalhos anteriores exploraram a extração automatizada de inteligência de ameaças a partir de texto não estruturado usando processamento de linguagem natural e técnicas de extração de^{entidades 6,7}. Mais recentemente, vários estudos investigaram a geração direta de regras de detecção a partir de relatórios CTI usando grandes modelos de linguagem (LLMs⁾⁸. Essas abordagens demonstram que partes do fluxo de trabalho de autoria de regras podem ser auxiliadas por modelos de linguagem, mas normalmente não focam no problema operacional específico de gerar padrões regex que preservem a semântica do grupo de captura e permaneçam adequados para implantação posterior de SIEM. Linhas de trabalho complementares estruturaram conteúdo CTI para uso posterior de diferentes formas, incluindo representações baseadas em grafos de conhecimento como o TINKER⁹ e geração de consultas de caça a logs orientada por CTI, como o ThreatRaptor¹⁰, que convertem CTI não estruturado em linguagens de consulta de conhecimento estruturado ou específicas de domínio, em vez de padrões regex destinados a serem incorporados em regras de correlação SIEM.

Paralelamente, estudos anteriores exploraram a síntese automatizada de regex usando métodos baseados em exemplos, tradução neural e abordagens de gerar e^reparar 11,12,13,14,15,16. No entanto, esses métodos geralmente são projetados para ambientes que dependem de grandes conjuntos de exemplos representativos ou descrições em linguagem natural, em vez de contextos de detecção baseados em IOC. Em fluxos de trabalho SOC, as cadeias IOC são frequentemente escassas, estruturalmente heterogêneas e intimamente ligadas à semântica operacional. Esse descompasso motiva um fluxo de trabalho adaptado para tradução IOC para regex, em vez de afirmar que os métodos existentes de geração de regex são amplamente inadequados.

O protocolo apresentado aqui foca especificamente na etapa de tradução IOC para regex do fluxo de trabalho de detecção de SOC. A extração do IOC é tratada como uma entrada a montante que pode originar-se de análise manual, ferramentas automatizadas ou uma combinação de ambas; o protocolo não tenta gerar regras SIEM completas. Em vez disso, fornece um procedimento sistemático para converter cadeias IOC em padrões regex que sejam sintaticamente válidos, semanticamente interpretáveis e adequados para implantação operacional. O escopo atual do IOC é deliberado: caminhos de arquivo, chaves de registro e indicadores de linha de comando contêm componentes estruturais estáveis e variáveis que se beneficiam da generalização regex, enquanto indicadores atômicos como endereços IP, domínios e hashes são operacionalizados de forma mais natural por meio de condições de correspondência exata ou buscas no estilo de reputação e, portanto, ficam fora do escopo principal. Dentro desses limites, o protocolo é projetado para ser portátil em ambientes SOC que compartilham formatos de entrada e pré-condições de ferramentas comparáveis.

Protocolo

Use o seguinte fluxo de trabalho de cinco estágios para transformar um relatório CTI em padrões regex validados com saídas intermediárias rastreáveis (veja a Figura 1 para uma visão geral).

1. Configuração do sistema

1. Pré-requisitos para instalação.
   1. Instale Python 3.8 ou posterior, todas as dependências de Python listadas no requirements.txt e um banco de dados de grafos Neo4j.
      1. Confirme o acesso a uma ou mais interfaces de programação de aplicações (APIs) para os grandes modelos de linguagem escolhidos e verifique se o serviço Neo4j está rodando e acessível a partir da máquina local.
   2. Confirme que a Tabela de Materiais está completa.
      1. Verifique se as dependências em tempo de execução estão listadas, incluindo a versão do interpretador Python, as dependências do pipeline, a versão Neo4j e o backend de extração de texto Portable Document Format (PDF).
      2. Verifique se as opções de configuração do LLM estão listadas, incluindo os provedores de LLM, nomes e versões dos modelos, temperatura, opções de esforço de raciocínio e configurações de votação em conjunto.
      3. Verifique se os formatos de entrada e saída estão listados, incluindo os formatos de arquivo de entrada suportados e os formatos de exportação suportados.
2. Inicie a interface do usuário web (UI).
   1. Abra um terminal, navegue até o diretório raiz da implementação de referência e inicie a aplicação usando o comando de lançamento documentado (na implementação de referência: CD langchain_pipeline seguido de Streamlit run app_v2.py).
   2. Verifique se a aplicação carrega em http://localhost:8501 e se o painel de configuração da barra lateral está visível.
3. Configure o provedor de LLM.
   1. Na seção de Configuração de LLM na barra lateral, selecione um provedor de LLM, insira o nome do modelo e forneça uma chave válida de interface de programação de aplicações (API).
   2. Registre o provedor, nome do modelo, versão do modelo, temperatura, opções de esforço de raciocínio e a data de acesso para a Tabela de Materiais.
      OBSERVAÇÃO. Na implementação de referência, a extração IOC de LLM único padrão é o LLM comercial primário listado na Tabela de Materiais com temperatura = 0,0; A geração de regex tem por padrão temperatura = 0,3.
4. Ativem a votação em conjunto (opcional, mas recomendada para resultados reproduzíveis).
   1. Ative a opção de Votação em Conjunto na barra lateral para manter apenas os IOCs que atendam a um limite mínimo de votos (Votos Mínimos ≥ 2 recomendados).
   2. Adicione instâncias adicionais de LLM especificando o provedor, nome do modelo, chave API e número de repetições de execução por modelo.
      1. Registre a contagem de repetições de cada provedor e o limite mínimo de votos selecionado.
         OBSERVAÇÃO. A votação em conjunto é opcional. Quando desativado, o pipeline realiza extração single-LLM e o filtro de consenso é pulado. As configurações padrão de conjunto são repetições = 1 por modelo configurado e min_votes = 2.
5. Conecte-se ao Neo4j.
   1. Na seção Conexão Neo4j da barra lateral, insira o URI de conexão (por exemplo, bolt://localhost:7687), o nome de usuário e a senha.
   2. Confirme que a interface reporta uma conexão bem-sucedida. Não prossiga sem uma conexão ativa.
6. Proteja todas as credenciais.
   1. Trate as chaves de API do LLM e a senha do Neo4j como credenciais sensíveis. Armazene-as em variáveis de ambiente ou em um gerenciador de segredos, em vez de em arquivos fonte, relatórios exportados ou capturas de tela, e gire qualquer chave rapidamente se houver suspeita de vazamento.
      OBSERVAÇÃO. Este protocolo de software não requer exaustor químico, armário de biossegurança ou outro equipamento físico de contenção; lidar com relatórios e credenciais confidenciais de CTI de acordo com políticas institucionais de segurança de dados.

2. Etapa 1: análise sintática de documentos

1. Procedimento.
   1. Navegue até a aba Processamento na interface principal.
   2. Envie um relatório CTI em um formato suportado (.pdf, .docx, .md, .txt ou .html).
   3. Clique em "Executar Próximo Estágio" para executar o Estágio 1, ou "Executar Todos os Estágios" para executar o pipeline completo em sequência.
2. Confirme o ponto de controle da Fase 1.
   1. Confirme que uma pré-visualização Markdown do documento de entrada está exibida.
   2. Verifique se os caminhos de arquivo, chaves de registro, fragmentos de linha de comando e limites de seção permanecem intactos na prévia.
   3. Se as strings técnicas forem truncadas ou a formatação for eliminada, corrija o arquivo de origem ou pré-processe o documento com um conversor externo antes de refazer o upload.

3. Estágio 2: Extração do COI

1. Procedimento.
   1. Confirme a configuração do LLM (e a votação em conjunto, se ativada).
   2. Clique em "Executar Próxima Etapa" para executar a Fase 2.
2. Confirme o ponto de controle da Fase 2.
   1. Confirme que a interface exibe uma coleção IOC no formato JavaScript Object Notation (JSON) com três chaves de nível superior: Caminhos de Arquivo, Linhas de Comando e Chaves de Registro.
   2. Quando a votação em conjunto for habilitada, verifique se as contagens de votos e os metadados do modelo contributivo são registrados para cada IOC retido.
      OBSERVAÇÃO. O sistema literalmente do Estágio 2 e os prompts humanos, juntamente com os prompts de geração e otimização do Estágio 5, são lançados como Arquivo Suplementar 1 (Supplemental_File_1_Prompts.txt).

4. Etapa 3: Análise e classificação do COI

1. Procedimento.
   1. Clique em "Executar Próximo Estágio" para executar o Estágio 3.
2. Confirme o ponto de controle do Estágio 3.
   1. Confirme que cada IOC retido está listado com uma categoria padronizada, uma tag de origem e a chave de extração original quando disponível.

5. Estágio 4: Normalização da IOC assistida por Neo4j

1. Procedimento.
   1. Confirme que a conexão Neo4j está ativa.
   2. Clique em "Executar Próxima Etapa" para executar a Etapa 4.
   3. Inspecione a saída de normalização por IOC e verifique se etiquetas de conservação/descarte são produzidas para componentes de caminho e linha de comando e que as chaves de registro produzem uma substring canônica contígua.
2. Confirme o ponto de controle da Fase 4.
   1. Confirme que tabelas IOC normalizadas são produzidas para cada tipo de IOC (caminhos de arquivo, chaves de registro, indicadores de linha de comando).
   2. Verifique se cada entrada inclui o valor original, o valor normalizado e uma lista de componentes de pares elemento/status rotulados como manter ou descartar.
      OBSERVAÇÃO. Esquema detalhado do Neo4j, consultas Cypher, regras de decisão e o procedimento de normalização da chave do registro estão listados no Arquivo Suplementar 2; um exemplo trabalhado é fornecido em Resultados Representativos.

6. Etapa 5: geração e pontuação de regex

1. Procedimento.
   1. Clique em "Executar Próximo Estágio" para executar o Estágio 5. Confirme que cada IOC normalizado e sua lista de tokens proibidos foram submetidos para geração de regex e validação determinística.
   2. Se um candidato falhar na validação, permita que o loop de otimização refine a regex até que um candidato compatível seja produzido ou o limite de iteração seja atingido.
   3. Inspecione a saída diagnóstica, histórico de otimização e contagens de iterações para qualquer IOC cujo regex final caia de compatível para a correspondência parcial de maior pontuação (registrado como used_fallback = Verdadeiro).
2. Confirme o ponto de controle do Estágio 5.
   1. Confirme que um regex final foi produzido para cada IOC retido.
   2. Verifique se as pontuações dos candidatos, históricos de otimização, listas de problemas e contagens de iterações estão registrados.
   3. Verifique se a telemetria por IOC, incluindo uso estimado de token e latência, está registrada.
      OBSERVAÇÃO. Regras detalhadas de validação regex, a fórmula de pontuação e os parâmetros de controle de iteração estão listados no Arquivo Suplementar 2.

7. Análise e validação

1. Abra a aba Analytics para revisar distribuições do IOC, resultados de votação em conjunto (quando ativados), resumos em qualidade regex e estatísticas de otimização. Use esses resumos para detectar anomalias, como desequilíbrio na extração ou falhas repetidas de otimização.

8. Resultados de exportação

1. Na aba Exportar, selecione o formato de exportação (texto simples, JSON ou YAML) e baixe o conjunto de regex. Confirme que os regexes exportados incluem as pontuações associadas e os metadados de categorização.
2. Gerar e baixar o relatório JSON completo contendo documentos analisados, IOCs extraídos, representações normalizadas, regex candidatos e resultados finais. Preserve este relatório como um registro de reprodutibilidade.

9. Solução de problemas

1. Se a Etapa 1 devolver conteúdo PDF truncado ou vazio, pré-processe o documento com um conversor externo ou ferramenta de reconhecimento óptico de caracteres antes de refazer o upload e confirme que artefatos técnicos permanecem visíveis na prévia Markdown.
2. Se a Etapa 2 devolver poucos IOCs consensuais, verifique as configurações do provedor, modelo, API-key, contagem de repetições e votos mínimos antes de alterar o limite. Inspecionar candidatos excluídos para distinguir alucinações de votação excessivamente rigorosa.
3. Se o Estágio 4 rotular todos os componentes como descartados, verifique a conectividade Neo4j e confirme se o grafo contém o vocabulário relevante de Caminho, Registro ou interface de linha de comando (CLI) para o tipo IOC analisado.
4. Se o Estágio 5 produzir um regex que compila, mas falha na correspondência ou generaliza demais, inspecione o histórico de otimização, a posição de falha no diagnóstico e as verificações de supergeneralização antes de regenerar o candidato.

10. Confirmar as saídas finais do protocolo.

1. Confirme que o arquivo Markdown analisado, o conjunto IOC (validado por consenso quando a votação em conjunto está ativada, ou modelo único quando desativado), a tabela IOC categorizada e as representações IOC normalizadas por grafo estão todos presentes.
2. Confirme que o conjunto regex compatível com SIEM, os resumos analíticos e o relatório JSON completo estão todos presentes, e arquive o relatório JSON como o registro de reprodutibilidade.

Resultados

Esta seção apresenta resultados representativos produzidos pelo protocolo IOC-para-regex e resume a avaliação de referência usada para avaliar sua aplicabilidade operacional. A avaliação de referência processou 3.156 relatórios CTI associados às técnicas MITRE ATT&CK, analisou mais de 230.000 sentenças, extraiu mais de 63.000 candidatos ao IOC e avaliou regexes gerados contra mais de 2.400 sequências de verdade coletadas independentemente de dez cenários de avaliação MITRE ATT&CK. Essas ...

Discussão

Traduzir relatórios CTI não estruturados em lógica de detecção executável continua sendo uma tarefa demorada e propensa a erros nos fluxos de trabalho de segurança operacional. Embora esforços anteriores tenham explorado a automação no nível da extração de IOC ou geração de regras em alto nível, os profissionais ainda enfrentam desafios substanciais para converter cadeias extraídas de IOC em regexes estruturalmente corretos, semanticamente precisos e adequados para uso posterior em SIEM....

Materiais

Lista de materiais utilizados neste artigo

Nome	Empresa	Número de catálogo	Comentários
Computer (CPU)	—	≥ 4 núcleos recomendados	Sem GPU necessário
LangChain	LangChain	≥ 0.1.x	Framework de orquestração LLM
LLM (extração IOC, modelo único)	OpenAI	gpt-5.1	Usado para extração de IOC (Estágio 2) quando a votação do ensemble está desativada. temperature = 0.0; max_workers = 5. Acessado: 15/12/2025.
LLM (geração de Regex)	OpenAI	gpt-5.1	Usado para geração de regex (Estágio 5). temperature = 0.3 antes da validação downstream. Acessado: 15/12/2025.
LLM (caracterização de escalabilidade)	OpenAI	gpt-5.1	Usado para a execução de escalabilidade de 6.000 IOC relatada nos Resultados Representativos. Acessado: 15/12/2025.
Memória (RAM)	—	≥ 16 GB recomendado	Necessário para processamento de documentos
Neo4j	Neo4j, Inc.	≥ 5.x	Banco de dados gráfico para normalização de IOC
Neo4j Python Driver	Neo4j, Inc.	≥ 5.x	Interface Python para Neo4j
Sistema Operacional	Microsoft / Apple / Linux	Windows, macOS ou Linux	Suporte multiplataforma
Análise PDF — backend primário	Microsoft	MarkItDown ≥ 0.0.x	Backend do Estágio 1; converte entradas PDF/DOCX/HTML/TXT em Markdown. Saída analisada em pedaços de 4.000 caracteres antes do processamento LLM. Acessado: 15/12/2025. https://github.com/microsoft/markitdown
Configuração da Pipeline (Estágio 2 — extração IOC)	—	Referência de padrões	Modo LLM único: temperature = 0.0, max_workers = 5. Padrões do modo de votação do ensemble: repeats = 1 por modelo configurado, min_votes = 2.
Configuração da Pipeline (Estágio 5 — geração de regex)	—	Referência de padrões	Temperatura de geração = 0.3. Validação: overgen_random_tests = 5 amostras negativas determinísticas por IOC. Limites de iteração: max_iterations = 10, debug_loop_cap = 5, discard_validation_cap = 5.
Python	Python Software Foundation	≥ 3.8	Ambiente de tempo de execução necessário
Regex Engine	Python Standard Library	módulo re	Usado para validação e teste de regex
Streamlit	Streamlit Inc.	≥ 1.25	Interface de usuário baseada na web
Código-fonte da implementação de referência	Autores / GitHub | Repositório GitHub		Código-fonte para a interface Streamlit, pipeline LangChain, normalização assistida por Neo4j, geração de regex, utilitários de validação e arquivos de configuração de exemplo. Disponível em https://github.com/SOCautomatic/cti-ioc-regex-pipeline. Acessado: 11 de junho de 2026.