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 sequências de verdade são artefatos de ataque curados por especialistas, reportados independentemente por fornecedores de cibersegurança durante os exercícios de avaliação MITRE ATT&CK e, portanto, refletem os padrões estruturais que analistas humanos e fornecedores documentam na prática. Os resultados abaixo focam no comportamento do fluxo de trabalho, correção estrutural e resultados de avaliação relevantes para a análise operacional de logs e detecção.

Uma visão geral do pipeline de ponta a ponta é fornecida na Figura 1, que resume os estágios de encontro do grupo de captura e geração de regex que moldam o restante dos resultados representativos.

Etapa 1: Análise de Documentos Resultados

A Figura 2 mostra a saída da Etapa 1, onde um relatório CTI de entrada é analisado em uma representação Markdown unificada. Após execução bem-sucedida, a interface exibe uma pré-visualização estruturada do documento, incluindo limites de seção e indicadores de relevância.

A execução correta é indicada por segmentação coerente de parágrafos e preservação de artefatos técnicos como caminhos de arquivos, chaves de registro e fragmentos de linha de comando. Truncamento excessivo ou perda de formatação nesta fase pode afetar a análise a jusante e deve ser abordada antes de prosseguir.

Etapa 2: Extração da IOC baseada em consenso

A Figura 3 ilustra a saída da Etapa 2, onde os IOCs candidatos são extraídos usando votação em conjunto multi-LLM. A interface resultante apresenta uma coleção IOC formatada em JSON, anotada com contagens de votos e modelos contribuintes.

Apenas IOCs que atingem o limite mínimo de consenso configurado são mantidos. IOCs excluídos neste estágio normalmente refletem alucinações específicas do modelo ou fragmentos de texto ambíguos. A exclusão deles é um resultado esperado e desejável, indicando que a votação em conjunto está funcionando corretamente.

Etapa 3: Análise e Classificação do COI

A Tabela 2 resume a saída esperada, as etapas de validação automatizada e as verificações de controle de qualidade voltadas para analistas para cada etapa do protocolo.

A Figura 4 mostra os candidatos do IOC que não atingiram o limiar de consenso durante a votação do conjunto na Etapa 2 e que a interface surge para inspeção por analistas. Esses candidatos normalmente refletem alucinações específicas de modelos ou fragmentos de texto ambíguos. A Figura 4 e a Figura 5 , portanto, correspondem a saídas distintas do estágio — o conjunto descartado do Estágio 2 e o conjunto retido do Estágio 3 — em vez de visões alternativas do mesmo processo do Estágio 3.

A Figura 5 apresenta a tabela do IOC mantida produzida pelo Estágio 3 após análise sintática JSON, categorização baseada em regras e deduplicação do IOC. Para cada IOC retido, o estágio registra uma categoria padronizada, a tag de origem e a chave de extração original quando disponível, antes de passar o IOC para a normalização posterior.

Estágio 4: Normalização de IOC Assistida por Graf entre Tipos de IOC

As Figuras 6, Figura 7 e Figura 8 ilustram resultados de normalização representativa para três categorias de IOC abordadas no estudo atual: caminhos de arquivo, chaves de registro e indicadores de linha de comando. Para cada categoria, os números comparam o IOC original extraído do relatório CTI com a representação normalizada produzida por análise assistida por grafos.

Em todos os tipos de IOC, o protocolo decompõe cada IOC em componentes semânticos e resolve relações hierárquicas usando conhecimento estruturado codificado no banco de dados de grafos. Na implementação atual, o Neo4j armazena nós normalizados de Caminho, Registro e CLI e utiliza relações de adjacência para testar se os componentes pertencem a cadeias reconhecidas. Esse papel é análogo ao uso do conhecimento estruturado de ATT&CK durante a engenharia de^{detecção 2}.

Importante, essa etapa de normalização registra papéis semânticos explícitos para os componentes IOC, rotulando-os como keep ou descart, em vez de removê-los silenciosamente do registro de análise. A string normalizada é reconstruída principalmente a partir dos componentes de conservação, enquanto os componentes de descarte permanecem disponíveis como metadados para geração e validação de regex a jusante.

A execução correta dessa etapa é indicada por IOCs normalizados que mantêm contexto estrutural significativo e exibem rotulagem consistente de grupos de captura entre diferentes tipos de IOC. A comparação visual entre representações originais e normalizadas fornece um mecanismo prático de controle de qualidade para verificar se a resolução do grupo de captura foi aplicada de forma consistente e sem perda não intencional de informação.

Estágio 5: Geração de Expressões Regulares com Seleção Baseada em Restrições Auxiliares

A Figura 9 ilustra a saída do Estágio 5, onde o protocolo gera expressões regulares estruturalmente compatíveis a partir de IOCs normalizados por meio de um fluxo de trabalho iterativo de validação. A implementação combina um prompt de geração inicial, re-prompting diagnóstico quando um candidato não corresponde ao IOC, validação consciente do descarte e loops de retentativa limitados.

Dado um IOC normalizado e sua especificação associada de componente/descarte, o fluxo de trabalho primeiro gera um candidato inicial a regex. O candidato é então testado contra o IOC, resolicitado diagnosticamente quando a correspondência falha, verificado para tokens descartados proibidos e avaliado quanto à supergeneralização usando cadeias negativas aleatórias.

Quando múltiplos candidatos atendem às verificações básicas de validação, o protocolo aplica um mecanismo auxiliar de seleção baseado em restrições para manter um regex representativo para uso posterior. A implementação atual pontua os candidatos com 'Score = n_cg - n_wc', onde 'n_cg' é o número de componentes de keep representados e 'n_wc' é o número de tokens descartados ou não mapeados presentes no regex.

A função de seleção é definida como:

Placar = n_cg − n_wc

Esta é a especialização de peso igual (α = β = 1) da forma mais geral Score = α·n_cg − β·n_wc. Aqui, n_cg denota o número de componentes de keep representados e n_wc denota o número de componentes descartados ou tokens extras não mapeados reintroduzidos pelo regex. A implementação também registra contagens de iterações, listas de emissões, consumo estimado de tokens, uso de cache e telemetria de latência para cada IOC. A configuração de peso igual foi usada como um padrão determinístico simples para a implementação de referência; Como trata um componente de keep ausente e um componente de descarte reintroduzido como igualmente indesejáveis, outras ponderações podem ser preferidas em contextos de implantação onde falsos negativos e falsos positivos têm custos operacionais diferentes.

O regex final é selecionado como o candidato que melhor satisfaz essas restrições. Regexes que colocam componentes de grupo de captura exigidos dentro de construções opcionais, por exemplo ( ... )?, são excluídos da seleção porque enfraquecem a consistência semântica. Essa etapa de seleção é auxiliar ao processo de geração e não tem a intenção de servir como uma métrica de qualidade independente.

Visão Geral de Análise Analítica do Processamento CTI

A Figura 10 apresenta uma visão geral dos resultados da análise CTI em todos os documentos processados. Na avaliação de referência, a extração do IOC de mais de 3.156 relatórios CTI produziu mais de 63.000 candidatos ao IOC, incluindo 12.195 caminhos de arquivo, 2.302 chaves de registro e 10.286 indicadores de linha de comando, com os demais candidatos pertencendo a tipos IOC não-alvo regex.

Essas contagens fornecem uma validação de alto nível de que os indicadores extraídos estão concentrados nas três categorias IOC alvo do protocolo atual, ao mesmo tempo em que mostram que muitos artefatos extraídos permanecem fora do escopo da geração de regex. Ao reproduzir o fluxo de trabalho, informe o número exato de relatórios de CTI processados, o total de candidatos ao IOC, contagens por categoria, e o provedor, modelo, versão do modelo, temperatura, contagem de repetições e limiar de consenso usado durante a extração.

Na avaliação de referência, os regex gerados foram avaliados contra mais de 2.400 sequências de verificação coletadas independentemente de dez cenários de avaliação MITRE ATT&CK e alcançaram uma taxa média de acerto de 99,1%, juntamente com uma taxa média de incompatibilidade entre COI de 0,8%. Neste manuscrito, a taxa de descorrespondência é usada como uma medida de especificidade semântica: uma descorrespondência ocorre quando um regex gerado para um IOC também corresponde a uma string de verdade associada a um IOC diferente. Essa quantidade não deve ser interpretada como uma taxa operacional de alerta de ponta a ponta falsos positivos, que também depende da lógica das regras a jusante e do contexto de implantação.

A distribuição reflete a composição estrutural do corpus CTI e permite aos usuários verificar se os indicadores extraídos estão alinhados com os tipos esperados de IOC. Grandes desvios em relação às proporções esperadas podem indicar problemas de análise ou extração a montante e devem ser examinados antes de prosseguir para a normalização a jusante e geração de regex.

Análise das Ações de Otimização Regex

A Figura 11 resume as ações realizadas durante a geração e refinamento de expressões regulares. A distribuição inclui três tipos de ações: geração inicial de regex, etapas de otimização orientadas por LLM e regeneração baseada em retentativas.

A otimização orientada por LLM representa 51,7% de todas as ações observadas. Essa prevalência indica que a geração inicial sozinha é frequentemente insuficiente para produzir regexes que satisfazem as restrições do grupo de captura e requisitos de exclusão. Em vez disso, a otimização iterativa é aplicada de forma ativa e repetida para refinar regex candidatos.

Em vez de refletir ineficiência, essa distribuição demonstra que o fluxo de trabalho de otimização é um componente necessário e integral do protocolo ao gerar regexes estruturalmente compatíveis a partir de entradas complexas de IOC.

Uma caracterização separada de escalabilidade sobre uma amostra aleatória de 6.000 IOCs gerada com o LLM de teste de escalabilidade (veja a Tabela de Materiais) relatou uma latência mediana de 2,95 s por IOC e uma latência média de 23,18 s. Na mesma caracterização, a compilação de regex sintaxe válida atingiu 99,56 %, o sucesso geral da geração atingiu 99,4 %, o uso médio estimado de tokens foi de aproximadamente 3.986 tokens por IOC, e o fluxo de trabalho exigiu aproximadamente 7,89 chamadas LLM por IOC em média. As taxas de sucesso na primeira passagem foram de 56,46% para o loop de depuração de correspondência e 72,92% para o loop de validação sem grupo de captura. Essas medições ajudam a caracterizar o custo computacional e o throughput operacional para uso em lote.

Nenhuma revisão de especialistas de um subconjunto de saída amostrada foi usada para retreinamento de modelos na caracterização atual de referência; Os resultados relatados refletem a execução automatizada do pipeline e os conjuntos de dados de avaliação a jusante descritos acima.

Evidências operacionais e manejo de falhas. A Figura 12 mostra a estrutura do arquivo regulares SIEM exportado produzido pelo protocolo, juntamente com evidências de validação em nível de regra para padrões representativos de caminho de arquivo, chave de registro e linha de comando. A Figura 13 mostra o relatório JSON completo correspondente, que expõe todas as saídas do estágio (IOCs extraídos, analisados e normalizados junto com os padrões regex gerados e as flags de validação por IOC) e é o principal artefato que as ferramentas a jusante consomem. A Figura 14 ilustra o tratamento do protocolo com uma entrada CTI ruidosa: um caminho de arquivo despresado e perturbado pelo espaço em branco é sinalizado na fase de análise, corrigido, normalizado para o template canônico %TEMP% e então convertido em um regex compilador e correspondente. Este exemplo trabalhado complementa a evidência operacional nas Figuras 12 e 13 ao documentar como o protocolo se comporta quando o texto bruto do IOC se afasta da forma canônica.

Figura 1: Arquitetura geral do protocolo IOC-para-regex. A figura resume o pipeline de ponta a ponta. Cadeias de IOC candidatas produzidas pelo extrator IOC a montante são decompostas e comparadas com nós de referência em um grafo Neo4j preenchido pela documentação do Windows (passo 1), que recupera componentes conhecidos de caminho, registro e linha de comando (passo 2). Fragmentos variáveis ou específicos do ambiente são rotulados como descarte e excluídos da reconstrução normalizada enquanto mantidos nos metadados dos componentes, resultando em um IOC normalizado com rótulos de keep e descarte em nível de componente (passo 3). Esses IOCs normalizados são então passados para uma etapa de geração de regex baseada em LLM (passo 4) que produz expressões regulares candidatas, que são pontuadas e otimizadas iterativamente contra restrições de grupo de captura e regras de tokens descartados (etapa 5) antes de selecionar um regex final (passo 6). Por favor, clique aqui para ver uma versão ampliada desta figura.

Figura 2: Fase 1 da análise do documento de saída. Comparação lado a lado do relatório original do CTI e da prévia do documento analisado. O painel à esquerda mostra o relatório original do CTI em formato PDF, enquanto o painel direito exibe a representação unificada do Markdown gerada pelo parser. Por favor, clique aqui para ver uma versão ampliada desta figura.

Figura 3: Extração de IOC baseada em consenso usando votação em conjunto multi-LLM. A interface ilustra o processo de extração do IOC baseado em conjunto e seus resultados intermediários. A caixa vermelha destaca as instâncias de LLM configuradas que participam da extração IOC, incluindo os provedores selecionados e o número de execuções repetidas de extração realizadas para cada modelo. A caixa azul indica o limiar de consenso definido pelo usuário, que especifica o número mínimo de ocorrências necessárias para que um IOC seja mantido. Após agregar os resultados de extração em todos os modelos e repetições, os IOCs candidatos que aparecem menos vezes do que o limite são descartados. A caixa laranja mostra o conjunto final de IOCs retidos que atendem ao critério de consenso e são encaminhados para as fases de análise a jusante. Por favor, clique aqui para ver uma versão ampliada desta figura.

Figura 4: COI descartados por votação em conjunto na Fase 2. Visão lado a lado dos candidatos do COI que não atingiram o limite mínimo de voto configurado durante a votação em conjunto e são apresentados para inspeção por analistas. Candidatos descartados normalmente refletem alucinações específicas do modelo ou fragmentos de texto ambíguos e não são encaminhados para a etapa de categorização do Estágio 3. Por favor, clique aqui para ver uma versão ampliada desta figura.

Figura 5: Conjunto de IOC retido com classificação padronizada. Candidatos ao IOC mantidos após o processamento do Estágio 3 são mostrados junto com suas categorias padronizadas, tags de origem e chaves originais de extração quando disponíveis. Esta tabela fornece a entrada estruturada do IOC usada pela etapa de normalização. Por favor, clique aqui para ver uma versão ampliada desta figura.

Figura 6: Normalização do IOC do caminho do arquivo usando análise assistida por grafo. Comparação lado a lado de um IOC do caminho original do arquivo e sua representação normalizada. Consultas de percurso baseadas em grafos conhecem os componentes do Path por nome normalizado e rotulam cada componente como keep ou descart. Identificadores de drive e fragmentos de nome de arquivo variável podem, portanto, ser marcados como descartados no registro de componentes, enquanto a forma normalizada é reconstruída principalmente a partir de segmentos estruturais mantidos necessários para a construção de padrões a jusante. Por favor, clique aqui para ver uma versão ampliada desta figura.

Figura 7: Normalização do IOC da chave do registro usando análise assistida por grafos. Normalização de uma chave de registro IOC por meio da resolução assistida por grafos de estruturas hierárquicas de registros. Chaves raiz abreviadas são expandidas para colmeias canônicas de registro, e o analisador extrai a substring contígua mais longa conhecida enquanto pula marcadores de hospedagem, valores semelhantes a SID e tokens semelhantes a GUID. Os registros de saída mantêm/descartam rótulos para cada componente retido e produzem um caminho canônico de registro para processamento posterior. Por favor, clique aqui para ver uma versão ampliada desta figura.

Figura 8: Normalização IOC de linha de comando usando análise assistida por grafos. Comparação entre um IOC original de linha de comando e sua representação normalizada. O protocolo tokeniza a linha de comando enquanto preserva as cadeias aspas, normaliza o token de comando principal por meio de consulta no Neo4j sempre que possível, e analisa recursivamente fragmentos embutidos, semelhantes a caminhos ou registros. Componentes estáveis relacionados a comandos são rotulados como mantenhação, argumentos variáveis são rotulados como descarte, e a estrutura final de comando canônica é reconstruída a partir dos elementos mantidos. Por favor, clique aqui para ver uma versão ampliada desta figura.

Figura 9: Seleção baseada em restrições de candidatos a expressão regular. Múltiplos candidatos regex são gerados para cada IOC normalizado usando um fluxo de trabalho iterativo de validação. Um mecanismo de pontuação orientado por restrições é aplicado para selecionar um regex final que preserva os componentes designados do grupo de captura enquanto limita substrings de variáveis indesejadas. Por favor, clique aqui para ver uma versão ampliada desta figura.

Figura 10: Distribuição dos IOCs extraídos entre os relatórios de CTI. Resumo dos resultados da extração do IOC mostrando o número total de indicadores identificados a partir de relatórios CTI e sua distribuição entre caminhos de arquivo, chaves de registro e indicadores de linha de comando. Essa visão fornece uma validação de alto nível da cobertura de conteúdo e do comportamento de extração do CTI. Por favor, clique aqui para ver uma versão ampliada desta figura.

Figura 11: Distribuição das ações de otimização durante a geração de expressões regulares. Análise das ações realizadas durante a geração de regex, incluindo geração inicial, otimização orientada por LLM e regeneração baseada em retentativas. A otimização orientada por LLM representa 51,7% de todas as ações, ilustrando que o refinamento iterativo é um componente essencial do protocolo para produzir regexes que satisfazem as restrições do grupo de captura. Por favor, clique aqui para ver uma versão ampliada desta figura.

Figura 12: Arquivo regex representativo exportado. Conteúdo de exemplo da exportação regex SIEM (siem_rules.txt) gerada pelo protocolo. Cada entrada inclui o IOC de origem, a categoria inferida (caminho do arquivo, chave de registro ou linha de comando) e o padrão regex validado. A tabela de validação que acompanha resume o comportamento esperado e as evidências do sistema usadas para confirmar a correção para cada tipo de regra. Por favor, clique aqui para ver uma versão ampliada desta figura.

Figura 13: Relatório completo do JSON representativo. Saída do pipeline de ponta a ponta produzida após executar todos os cinco estágios do protocolo em um relatório representativo de CTI. O documento JSON registra o arquivo fonte, contagem de seções analisadas, IOCs extraídos agrupados por categoria, registros categorizados do estágio 3 com tags de origem, diferença de normalização do estágio 4 e padrões regex do estágio 5 com flags de validação por IOC. O relatório também expõe metadados de sucesso de alto nível e erro que permitem que ferramentas posteriores detectem falhas parciais. Por favor, clique aqui para ver uma versão ampliada desta figura.

Figura 14: Entrada falhada ou ruidosa: identificação e correção. Exemplo funcionário de como o protocolo identifica e recupera de um IOC barulhento. A entrada bruta %T E M P%\malware[.]O EXE é sinalizado porque seu token de variável ambiental contém espaços inseridos e sua extensão de arquivo foi desativada. A etapa de correção remove o espaço em branco inserido e restaura o ponto literal; A normalização do Estágio 4 então expande o %TEMP% para o modelo canônico de diretório Windows Temp; e o Estágio 5 gera um regex que compila e corresponde ao IOC normalizado corrigido. Este exemplo ilustra o tratamento de entrada ruidosa discutido na Discussão. Por favor, clique aqui para ver uma versão ampliada desta figura.

Elemento	Tipo	Valor / Esquema	Exemplo	Notas
Rótulo de nó	Selo	:P ath	Windows, System32, cmd.exe	Armazena componentes do caminho de arquivo do Windows
Rótulo de nó	Selo	:Registro	SOFTWARE, Microsoft, Windows NT	Armazena componentes da chave do registro abaixo das colmeias raiz
Rótulo de nó	Selo	:CLI	powershell.exe, -Política de Execução, Desvio	Armazena tokens de comando e parâmetros
Propriedade do nó	Corda	Nome	cmd.exe	Revestimento original; Usado para exibição em saída normalizada
Propriedade do nó	Corda	name_lower	cmd.exe	Forma minúscula; usado como chave de consulta para todas as consultas MATCH
Relacionamento	Aresta direcionada	(a)-[:PRÓXIMO]->(b)	(Windows)-[:NEXT]->(System32)	Ambos os extremos compartilham o mesmo rótulo; codifica adjacência nativa em sistemas Windows
Restrição	Singularidade	n.name_lower ÚNICO por rótulo	-	Candidatei-me ao :P ath, :Registry, :CLI
Fonte dos dados	Cobertura	Windows 8, 10, 11	-	O sistema operacional cliente preenchido em grafo
Fonte dos dados	Cobertura	Windows Server 2012, 2016, 2019, 2022	-	Sistema operacional do servidor preenchido em grafos

Tabela 1: Esquema de grafo Neo4j usado para normalização do IOC (Estágio 4). Lista os três rótulos de nós (Caminho, Registro, CLI), seu esquema de propriedades compartilhadas (nome, name_lower), a relação de adjacência direcionada usada para ordenação nativa de aristas, restrições de unicidade e as versões do cliente e servidor do Windows que preenchem o grafo.

Palco	Produção esperada	Validação automatizada	Controle de qualidade voltado para analistas
Etapa 1: Análise sintática de documentos	Texto Markdown unificado, dividido em 4.000 caracteres antes do processamento do LLM.	—	Verificação visual da pré-visualização do Markdown para confirmar que caminhos de arquivo, chaves de registro, fragmentos de linha de comando e limites de seção sobrevivem à análise sintática; Troque o backend se as strings técnicas estiverem truncadas.
Estágio 2: Extração do IOC	JSON com três chaves de nível superior (Caminhos de Arquivo, Linhas de Comando, Chaves de Registro); contagens de votos por COI e metadados do modelo contributivo quando a votação em conjunto está habilitada.	O filtro de limiar de consenso (min_votes) exclui IOCs cuja contagem de votos está abaixo do limite configurado.	Inspeção dos candidatos excluídos para distinguir alucinações de votação excessivamente rigorosa antes de ajustar min_votes.
Etapa 3: Análise e classificação do COI	Lista de IOC categorizada: cada IOC combinado com uma categoria padronizada, etiqueta de origem e chave de extração original quando disponível.	Mapeamento de categorias padronizadas por meio de regras baseadas em regex e heurísticas de padrões IOC; (COI, categoria) deduplicação de pares.	Verificação pontual da saída categorizada para candidatos ambíguos ou barulhentos (Figura 4A).
Estágio 4: Normalização assistida por Neo4j	Formulário normalizado por IOC com etiquetas de conservação/descarte em nível de componente.	Consultas cifras (i)-(iii) sobre o gráfico de referência do Windows; Reserva de pré-processamento determinístico quando o Neo4j não está disponível.	Inspeção de casos totalmente descartáveis para identificar lacunas na cobertura de grafos; extensão dos dados de grafos com referências específicas do fornecedor ou do ambiente quando necessário.
Etapa 5: Geração e pontuação de Regex	Regex final por IOC com pontuações de candidatos, histórico de otimização, contagem de iterações e telemetria por IOC.	Teste de correspondência, verificações estáticas de qualidade, verificação de token proibido consciente de fronteiras, teste de supergeneralização contra 5 amostras determinísticas negativas; Retorno para a partida parcial de maior pontuação (used_fallback bandeira).	Revisão do histórico de otimização para regex de reserva; por inspeção diagnóstica de posição de falha por IOC antes da regeneração.

Tabela 2: Estágio e resultado e resumo de validação. Mapeia cada estágio do protocolo (1–5) para seu artefato esperado, as evidências automatizadas de validação produzidas pelo pipeline (status de compilação regex, taxa de acerto, taxa de descorrespondência entre IOC, contagens de iterações de otimização) e a verificação de controle de qualidade correspondente voltada para analistas (comparação visual, inspeção de candidatos descartados e revisão de categoria).

Arquivo Suplementar 1: Prompts de LLM verbatim. O sistema literal e os prompts humanos usados para extração do IOC do Estágio 2 e geração e otimização de regex do Estágio 5. Por favor, clique aqui para baixar este arquivo.

Arquivo Suplementar 2: Detalhes da implementação para as Etapas 4 e 5. Detalhes algorítmicos e de implementação que suportam a normalização IOC assistida por grafo do Estágio 4 e a validação, pontuação e controle de iteração regex do Estágio 5. Por favor, clique aqui para baixar este arquivo.

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. O protocolo apresentado aqui aborda essa lacuna por meio de um fluxo de trabalho em etapas, no qual cada fase produz um artefato intermediário bem definido e aplica validação explícita antes de passar os resultados para a próxima etapa. A Figura 14 documenta um desses casos, no qual um caminho de arquivo despresado e perturbado por espaços em branco é identificado, corrigido, normalizado e convertido em um regex de compilação; O tratamento de entrada ruidosa do protocolo e seu escopo atual são discutidos conjuntamente, com as limitações enumeradas abaixo.

Uma contribuição central desse protocolo é a decomposição explícita do fluxo de trabalho em estágios com saídas intermediárias inspecionáveis. A implementação agora é descrita de forma concreta: a análise sintática de documentos produz Markdown e texto em blocos para processamento de LLMs; A extração IOC emite JSON estruturado para caminhos de arquivo, chaves de registro e indicadores de linha de comando; a análise IOC baseada em regras padroniza e desduplica valores extraídos; A normalização assistida por Neo4j rotulou cada componente IOC como keep ou descarte; e a geração de regex aplica verificações de depuração de correspondências, validação de descartes e supergeneralização antes da seleção do candidato.

O protocolo trata a geração de expressões regulares como uma tarefa iterativa de construção, e não como um problema de previsão de uma única vez. A implementação utiliza um prompt de geração inicial, diagnósticos automáticos de correspondência, loops de refinamento limitados e uma função de pontuação baseada em componentes para preservar elementos estruturalmente importantes do IOC enquanto penaliza substrings descartadas ou não mapeadas. Esse projeto iterativo, juntamente com validadores determinísticos aplicados em cada etapa, suporta a produção de padrões regex que permanecem estruturalmente fiéis em um grande e heterogêneo conjunto de avaliação. Na avaliação de referência, esse fluxo de trabalho foi aplicado a 3.156 relatórios CTI e avaliado contra mais de 2.400 sequências independentes de verificação no terreno, resultando em uma taxa média de acertos de 99,1% e uma taxa média de desajuste entre IOCs de 0,8%. Como essas cadeias de verdade são artefatos curados por especialistas relatados por fornecedores de cibersegurança durante os exercícios de avaliação MITRE ATT&CK, essa avaliação compara implicitamente a saída do protocolo com padrões do IOC documentados por analistas humanos, em vez de com padrões gerados automaticamente.

Como mostrado nos resultados representativos, a otimização iterativa é particularmente importante quando o fluxo de trabalho lida com estruturas complexas de IOC, como caminhos de arquivos aninhados ou longas cadeias de linha de comando. Os resultados da avaliação de referência também indicam que os casos não correspondidos mais comuns ocorrem quando atacantes usam executáveis ou parâmetros personalizados que não estão representados no banco de dados de grafos ou não estão explicitamente documentados nos relatórios CTI de origem. No uso operacional, esses modos de falha devem ser tratados como condições de contorno esperadas em vez de erros silenciosos e devem acionar a revisão da cobertura de grafos, completude do relatório de origem e telemetria regex-debug.

O protocolo pode ser comparado a três famílias de métodos alternativos. Primeiro, métodos de síntese regex baseados em exemplos, como TransRegex¹¹ e Regex+¹², aprendem regex a partir de conjuntos curados de exemplos de string positivos e negativos. Esses métodos têm bom desempenho quando conjuntos de exemplo representativos estão disponíveis, mas são menos diretamente aplicáveis a contextos SOC, onde cada IOC relatado no CTI normalmente aparece como uma única cadeia representativa, e a fronteira de generalização necessária é orientada por semântica operacional em vez de cobertura de exemplo. Segundo, abordagens de programação genética como as introduzidas por Bartoli et ^al.13,14 buscam o espaço dos regex por meio de operadores evolutivos e tipicamente exigem um corpus rotulado de cadeias de correspondência e não-correspondência; eles são bem adequados para a construção em lote de padrões de extração, mas não consomem diretamente narrativas não estruturadas de CTI. Terceiro, abordagens neurais recentes e baseadas em^{LLMs 15,16} traduzem descrições em linguagem natural diretamente para cadeias regulares; esses métodos são poderosos para prompts bem especificados, mas, em uso de um único disparo, podem produzir regexes que são sintaticamente válidos, mas que não passam de lado componentes do grupo de captura exigidos ou se generalizam demais entre variantes IOC não relacionadas. O protocolo atual complementa essas direções ao (i) tomar relatórios CTI não estruturados em vez de conjuntos de exemplos curados ou consultas em linguagem natural como entrada, (ii) decompondo cada IOC em componentes de keep e descarte via normalização assistida por grafo antes de qualquer regex ser gerado, e (iii) validando cada regex candidato com verificações determinísticas de correspondência, descarte e supergeneralização dentro de um ciclo iterativo limitado. O objetivo não é superar métodos anteriores em seus próprios benchmarks, mas fornecer um pipeline reproduzível IOC para regex cujas decisões intermediárias sejam inspecionáveis e auditáveis por analistas SOC.

O protocolo faz várias suposições sobre a qualidade dos relatórios CTI de entrada. Pressupõe-se que (i) strings IOC aparecem em forma textual recuperável após a análise de documentos, ou seja, caminhos de arquivo, chaves de registro e indicadores de linha de comando não são embutidos exclusivamente em imagens, capturas de tela ou codificações ofuscadas; (ii) fragmentos IOC relatados no CTI são suficientemente completos para preservar suas âncoras estruturais (por exemplo, chaves de registro mantêm seu prefixo colmeia, caminhos de arquivo mantêm pelo menos uma âncora de diretório reconhecível ao grafo de documentação do Windows, e linhas de comando mantêm o executável invocador ou uma referência conhecida a um módulo); e (iii) os IOCs relatados não são truncados, redigidos ou reescritos de maneiras que removam os componentes do grupo de captura dos quais o protocolo depende. Relatórios CTI que atendem a essas suposições incluem a maioria das descrições da técnica MITRE ATT&CK, avisos a fornecedores, relatórios de resposta a incidentes e boletins de ameaças bem formatados. Relatórios que dependem principalmente de capturas de tela, listas IOC altamente abreviadas sem contexto ao redor, ou paráfrases em texto livre sem cadeias explícitas de IOC estão fora do envelope operacional pretendido e devem ser esperados que produzam redução na recuperação de extração e normalização menos fiel; Esses relatórios podem se beneficiar de pré-processamento upstream image-to-text ou revisão por analistas antes de entrarem no pipeline.

Várias limitações devem ser consideradas ao aplicar esse protocolo. Primeiro, a implementação atual foca em caminhos de arquivo, chaves de registro e indicadores de linha de comando, em vez de categorias mais amplas de IOC, como domínios, artefatos de e-mail, strings de user-agent ou sequências comportamentais. Esta é uma escolha deliberada de escopo, já que indicadores atômicos geralmente são bem servidos por fluxos de trabalho de correspondência exata e o protocolo atual mira IOCs de estrutura variável que se beneficiam da generalização regex; no entanto, isso restringe a aplicabilidade a tipos IOC que atualmente não estão representados no gráfico. Segundo, os cenários de falha atuais se dividem em três categorias principais: caminhos não nativos ou argumentos de linha de comando ausentes do grafo do sistema operacional, cobertura incompleta do grafo para utilitários ou estruturas relevantes, e incompletude na própria fonte do CTI quando fragmentos de comando importantes ou cmdlets nunca são reportados. Terceiro, a métrica de descorrespondência cross-IOC usada na avaliação de referência mede a especificidade semântica dos regex gerados, em vez de falsos positivos de alerta de ponta a ponta sob lógica SIEM implantada.

Reprodutibilidade sob variabilidade e versionamento de LLM. Como os estágios de extração e geração de regex do IOC dependem de endpoints comerciais de LLM, duas fontes de variabilidade afetam a reprodutibilidade: atualizações do modelo do lado do provedor ao longo do tempo e a estocasticidade por chamada de amostragem. Para mitigar o primeiro, todos os campos relacionados a LLM na Tabela de Materiais registram identificadores exatos do modelo e a data de acesso usada na avaliação de referência, e o protocolo recomenda fixar em um snapshot específico do modelo sempre que o provedor expor um. Para mitigar a segunda, a implementação de referência fixa a temperatura de extração do IOC em 0,0 e usa uma temperatura diferente de zero apenas na etapa de geração regex, onde a votação em conjunto e validadores determinísticos nas Fases 2 e 5 absorvem variação residual. Ao replicar esses resultados, os usuários devem registrar a versão exata do modelo, data de acesso, temperatura e limiar de voto em conjunto utilizado; Desvios substantivos em qualquer um desses eixos devem ser esperados para alterar métricas de taxa de acerto e descorrespondência.

Vários modos de falha recuperáveis podem ser tratados no nível do estágio que os produziu. Falhas de análise do estágio 1 (por exemplo, PDFs escaneados que produzem Markdown vazio ou distorcido): pré-processar a entrada com reconhecimento óptico de caracteres ou um conversor externo antes de reenviar; Verifique se a contagem de seções analisadas e o total de caracteres são diferentes de zero antes de prosseguir. Falhas de extração do estágio 2 (nenhum IOC retornado, ou entradas alucinadas): aumentar o limiar de voto conjunto (Votos Mínimos ≥ 2), permitir instâncias adicionais do modelo ou diminuir a temperatura do LLM; verificar a conectividade da API e se o modelo configurado aceita saída formatada em JSON. Normalização do estágio 4 com rótulos totalmente descartados (todo componente IOC é rotulado como descarte): estender o gráfico de referência Neo4j com componentes de caminho específicos de fornecedor ou ambiente e raízes de registro; os scripts de importação do Cypher e a regra de decisão de guardar/descartar estão listados no Arquivo Suplementar 2. Falhas regex do estágio 5 (used_fallback = verdadeiras, ou rejeições repetidas de validação de descarte): inspecionar o campo de histórico de otimização por IOC para identificar o validador que falhou; se o IOC realmente carece de componentes estáveis de keep, considere a autoria manual de regex para esse IOC ou excluí-lo da geração automatizada de regras, mantendo-o na tabela categorizada do IOC para revisão por analistas.

De acordo com as limitações acima, os regexes gerados são melhor tratados como primitivas de busca reutilizáveis dentro de um conteúdo mais amplo de detecção de SOC, em vez de detectores autossuficientes. Em ambientes operacionais, analistas podem combiná-las com lógica de campo específica da plataforma, listas brancas, verificações de proveniência ou condições de correlação para suprimir correspondências benignas que surgem de caminhos incomuns, porém não maliciosos.

Trabalhos futuros podem incluir comparação sistemática com regexes escritos por humanos, avaliação mais ampla em categorias adicionais de IOC, estudos estruturados de feedback entre analistas, ampliação da cobertura de grafos para utilitários e cmdlets criados por atacantes, e relatórios mais completos de latência e custo de ponta a ponta em diferentes configurações de implantação. No entanto, o protocolo atual fornece uma estrutura reproduzível e operacionalmente interpretável para tradução IOC para regex que documenta tanto seus pontos fortes quanto seus limites atuais.

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.