Un flujo de trabajo estructurado para transformar la inteligencia de amenazas cibernéticas en patrones de detección computables

Resumen

Aquí presentamos un protocolo para convertir indicadores de compromiso de informes de inteligencia cibernética, rutas de archivos, claves de registro e indicadores de línea de comandos en expresiones regulares validadas para las reglas de detección de información y gestión de eventos de seguridad (SIEM), utilizando extracción de conjuntos con grandes modelos de lenguaje (LLMs) y etiquetado de componentes asistido por grafos.

Resumen

Los Centros de Operaciones de Seguridad (SOC) convierten rutinariamente los informes de inteligencia de amenazas cibernéticas (CTI) en contenido de detección operativa. Un cuello de botella persistente en este flujo de trabajo es la traducción de indicadores extraídos de compromiso (IOC), especialmente rutas de archivos, claves de registro y cadenas de línea de comandos, en expresiones regulares desplegables (regexes) adecuadas para incrustarse en reglas de correlación de información de seguridad y gestión de eventos (SIEM). Aunque trabajos previos han mejorado la extracción automatizada por indicadores de compromiso (IOC), transformar cadenas extraídas en patrones regex validados sigue siendo en gran medida manual, requiere especialización y es propenso a errores. El objetivo de este protocolo es proporcionar un procedimiento estandarizado y reproducible para la traducción de IOC a regex. El flujo de trabajo consta de cinco etapas: (1) analizar informes CTI heterogéneos en una representación unificada de Markdown; (2) extracción de la IOC utilizando múltiples grandes modelos de lenguaje (LLM) con voto por consenso; (3) normalización, categorización y deduplicación basada en reglas de IOCs extraídos; (4) etiquetado asistido por grafo de los componentes IOC como keep (grupo de captura) o descarte (grupo no de captura); y (5) generación iterativa de regex con validación diagnóstica frente a las cadenas IOC originales. Para evaluar la utilidad, el flujo de trabajo se aplicó a 3.156 informes CTI, y los regex resultantes se evaluaron frente a más de 2.400 cadenas de verificación de terreno recogidas de forma independiente de diez escenarios de evaluación de Tácticas, Técnicas y Conocimiento Común (ATT&CK) de MITRE, lo que arrojó una tasa media de aciertos del 99,1 % y una tasa media de desajuste entre COI del 0,8 %. Por tanto, el protocolo documenta una implementación reproducible para la traducción de IOC a regex y delimita explícitamente su alcance actual, supuestos operativos y casos de fallo conocidos.

Introducción

El cibercrimen sigue imponiendo cargas operativas y financieras sustanciales a las organizaciones tanto públicas como privadas. En 2023, las pérdidas reportadas debidas a la ciberdelincuencia en Estados Unidos superaron los 12.500 millones de dólares^, lo que pone de manifiesto la magnitud y persistencia de la actividad maliciosa. Dentro de este entorno, los Centros de Operaciones de Seguridad (SOC) actúan como las principales unidades operativas responsables de detectar, analizar y responder a amenazas en tiempo real.
La lógica de detección en muchos flujos de trabajo SOC se implementa mediante mecanismos basados en reglas dentro de plataformas de Gestión de Información y Eventos de Seguridad (SIEM), que son ampliamente utilizadas porque son interpretables, deterministas y compatibles con los flujos de trabajo SOC existentes. Entre los diferentes tipos de reglas, las reglas SIEM basadas en correlación son especialmente importantes para identificar comportamientos de ataque que abarcan múltiples eventos, hosts y ventanas temporales. Dentro de estas reglas, las expresiones regulares (regexes) funcionan como primitivas de búsqueda reutilizables: los analistas las integran en reglas de detección más amplias que añaden restricciones de campo, filtros específicos de la plataforma y lógica de correlación de eventos, en lugar de desplegarlas como detectores autónomos.

En la práctica, los analistas SOC suelen comenzar el desarrollo de reglas con indicadores de compromiso (IOCs) derivados de informes de inteligencia de amenazas cibernéticas (CTI) publicados por proveedores de seguridad, investigadores independientes o bases de conocimiento públicas como MITRE Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK⁾². Estas cadenas IOC pueden incluir rutas de archivo, fragmentos de línea de comandos, claves de registro u otros artefactos estructurados observados durante ataques³. Traducir tales cadenas en patrones regex adecuados para las reglas de correlación SIEM es una tarea recurrente en el flujo de trabajo de creación de reglas.

Este paso de traducción es un cuello de botella operativo práctico. Crear patrones regex lo suficientemente generales para captar variaciones significativas pero lo bastante precisos para evitar coincidencias no deseadas requiere una experiencia especializada; pequeños errores sintácticos o decisiones incorrectas sobre qué componentes preservar o generalizar pueden hacer que una regla de detección que de otro modo sería útil sea ineficaz. Debido a que este trabajo es manual, repetitivo y detallista, puede retrasar el despliegue de detección para amenazas emergentes, requerir revisión por analistas más experimentados y contribuir a la carga de trabajo de los analistas en entornos operativos^{SOC 4,5}.

El reto central en la traducción de IOC a regex es decidir qué partes de una IOC codifican un comportamiento estable y relevante para el atacante y, por tanto, deben preservarse, y cuáles reflejan variaciones específicas del entorno o del host y deben generalizarse. Por ejemplo, las raíces canónicas de registros como HKEY_CLASSES_ROOT\CLSID, directorios de sistema como System32 y nombres ejecutables conocidos como rundll32.exe suelen permanecer explícitos, mientras que las rutas de perfil de usuario, los Identificadores de Seguridad específicos del host (SID) y los Identificadores Globalmente Únicos (GUIDs) deberían abstraerse normalmente. Hacer esto de forma consistente entre tipos heterogéneos de IOC es lo que hace que la tarea de traducción no sea trivial. A lo largo de este protocolo, nos referimos a los primeros como componentes preservados o de grupo de captura, y a los segundos como componentes abstractos o no de grupo de captura.

Trabajos previos han explorado la extracción automatizada de inteligencia de amenazas a partir de texto no estructurado utilizando técnicas de procesamiento de lenguaje natural y extracción de entidades ^6,7. Más recientemente, varios estudios han investigado la generación directa de reglas de detección a partir de informes CTI utilizando grandes modelos de lenguaje (LLMs⁾⁸. Estos enfoques demuestran que partes del flujo de trabajo de creación de reglas pueden ser asistidas por modelos de lenguaje, pero normalmente no se centran en el problema operativo específico de generar patrones regex que preserven la semántica de grupo de captura y sigan siendo adecuados para el despliegue posterior de SIEM. Las líneas de trabajo complementarias han estructurado contenido CTI para su uso posterior de diferentes maneras, incluyendo representaciones basadas en grafos de conocimiento como TINKER⁹ y la generación impulsada por CTI de consultas de búsqueda de logs como ThreatRaptor¹⁰, que convierten CTI no estructuradas en lenguajes de consulta de conocimiento estructurado o específicos de dominio en lugar de en patrones regex destinados a incrustarse en reglas de correlación SIEM.

Paralelamente, estudios previos han explorado la síntesis automática de regex utilizando métodos basados en ejemplos, traducción neuronal y enfoques de generación y^reparación 11,12,13,14,15,16. Sin embargo, estos métodos suelen estar diseñados para entornos que dependen de grandes conjuntos de ejemplos representativos o descripciones en lenguaje natural en lugar de contextos de detección impulsados por IOC. En los flujos de trabajo SOC, las cadenas IOC suelen ser escasas, estructuralmente heterogéneas y estrechamente ligadas a la semántica operativa. Esta descoordinación motiva un flujo de trabajo adaptado a la traducción de IOC a regex en lugar de afirmar que los métodos existentes de generación de regex son en general insuficientes.

El protocolo presentado aquí se centra específicamente en la etapa de traducción de IOC a regex del flujo de trabajo de detección SOC. La extracción IOC se trata como una entrada ascendente que puede originarse a partir de análisis manual, herramientas automatizadas o una combinación de ambas; el protocolo no intenta generar reglas SIEM completas. En su lugar, proporciona un procedimiento sistemático para convertir cadenas IOC en patrones regex que sean sintácticamente válidos, semánticamente interpretables y adecuados para su despliegue operativo. El alcance actual de la IOC es deliberado: las rutas de archivos, claves de registro e indicadores de línea de comandos contienen componentes estructurales tanto estables como variables que se benefician de la generalización regex, mientras que los indicadores atómicos como direcciones IP, dominios y hashes se operacionalizan de forma más natural mediante condiciones de coincidencia exacta o búsquedas de reputación y, por tanto, quedan fuera del ámbito principal. Dentro de estos límites, el protocolo está pensado para ser portátil entre entornos SOC que compartan formatos de entrada y precondiciones de herramientas comparables.

Protocolo

Utilice el siguiente flujo de trabajo de cinco etapas para transformar un informe CTI en patrones regex validados con salidas intermedias trazables (véase la Figura 1 para una visión general).

1. Configuración del sistema

1. Requisitos previos para la instalación.
   1. Instala Python 3.8 o posterior, todas las dependencias de Python listadas en requirements.txt y una base de datos de grafos Neo4j.
      1. Confirma el acceso a una o más interfaces de programación de aplicaciones (APIs) para los grandes modelos de lenguaje elegidos y verifica que el servicio Neo4j está en funcionamiento y es accesible desde la máquina local.
   2. Confirma que la Tabla de Materiales está completa.
      1. Verifica que las dependencias en tiempo de ejecución estén listadas, incluyendo la versión del intérprete de Python, las dependencias de la canalización, la versión Neo4j y el backend de extracción de texto Portable Document Format (PDF).
      2. Verifica que las opciones de configuración del LLM estén listadas, incluyendo los proveedores de LLM, nombres y versiones de modelos, temperatura, opciones de esfuerzo de razonamiento y configuraciones de votación en conjunto.
      3. Verifica que los formatos de entrada y salida estén listados, incluyendo los formatos de archivo de entrada soportados y los formatos de exportación compatibles.
2. Lanza la interfaz de usuario web (UI).
   1. Abre un terminal, navega hasta el directorio raíz de la implementación de referencia y inicia la aplicación usando el comando de lanzamiento documentado (en la implementación de referencia: cd langchain_pipeline seguido de streamlit run app_v2.py).
   2. Comprueba que la aplicación se carga en http://localhost:8501 y que el panel de configuración de la barra lateral sea visible.
3. Configura el proveedor de LLM.
   1. En la sección de Configuración de LLM de la barra lateral, selecciona un proveedor de LLM, introduce el nombre del modelo y proporciona una clave válida de interfaz de programación de aplicaciones (API).
   2. Registra el proveedor, nombre del modelo, versión del modelo, temperatura, opciones de razonamiento y la fecha de acceso para la Tabla de Materiales.
      NOTA. En la implementación de referencia, la extracción IOC de un LLM único se asigna por defecto al LLM comercial primario listado en la Tabla de Materiales con temperatura = 0,0; La generación de regex por defecto es temperatura = 0,3.
4. Activar la votación en conjunto (opcional pero recomendado para resultados reproducibles).
   1. Activa la opción de Votación en Conjunto en la barra lateral para conservar solo los IOCs que cumplan un umbral mínimo de voto (se recomienda Votos mínimos ≥ 2).
   2. Añade instancias adicionales de LLM especificando proveedor, nombre del modelo, clave API y número de repeticiones de ejecución por modelo.
      1. Registrar el recuento de repeticiones de cada proveedor y el umbral mínimo de votos seleccionado.
         NOTA. La votación en conjunto es opcional. Cuando se desactiva, la tubería realiza la extracción de un solo LLM y se omite el filtro de consenso. Los ajustes predeterminados del conjunto son repeticiones = 1 por modelo configurado y min_votes = 2.
5. Conéctate a Neo4j.
   1. En la sección de Conexión Neo4j de la barra lateral, introduce el URI de conexión (por ejemplo, bolt://localhost:7687), el nombre de usuario y la contraseña.
   2. Confirma que la interfaz informa de una conexión exitosa. No continúes sin una conexión activa.
6. Asegura todas las credenciales.
   1. Trata las claves API de LLM y la contraseña de Neo4j como credenciales sensibles. Guárdalas en variables de entorno o en un gestor de secretos en lugar de en archivos fuente, informes exportados o capturas de pantalla, y rota cualquier clave rápidamente si se sospecha una filtración.
      NOTA. Este protocolo de software no requiere una campana extractora química, un armario de bioseguridad ni otro equipo físico de contención; gestionar informes y credenciales confidenciales de CTI según las políticas institucionales de seguridad de datos.

2. Fase 1: análisis sintáctico de documentos

1. Procedimiento.
   1. Navega a la pestaña de Procesamiento en la interfaz principal.
   2. Sube un informe CTI en un formato compatible (.pdf, .docx, .md, .txt o .html).
   3. Haz clic en "Ejecutar siguiente etapa" para ejecutar la etapa 1, o en "Ejecutar todas las etapas" para ejecutar toda la pipeline en secuencia.
2. Confirma el control de la Fase 1.
   1. Confirma que se muestra una vista previa Markdown del documento de entrada.
   2. Verifica que las rutas de archivos, claves de registro, fragmentos de línea de comandos y límites de sección permanezcan intactos en la vista previa.
   3. Si las cadenas técnicas se truncan o se elimina el formato, corrija el archivo fuente o preprocesa el documento con un convertidor externo antes de volver a subirlo.

3. Etapa 2: Extracción del COI

1. Procedimiento.
   1. Confirma la configuración del LLM (y la votación del conjunto, si está activada).
   2. Haz clic en "Ejecutar siguiente etapa" para ejecutar la segunda etapa.
2. Confirma el punto de control de la Fase 2.
   1. Confirme que la interfaz muestra una colección IOC en formato JavaScript Object Notation (JSON) con tres claves de primer nivel: Rutas de Archivo, Líneas de Comandos y Claves de Registro.
   2. Cuando se habilite la votación en conjunto, verifica que los conteos de votos y los metadatos del modelo contribuyente se registren para cada IOC retenido.
      NOTA. El sistema literal de la Etapa 2 y los prompts humanos, junto con los prompts de generación y optimización de la Etapa 5, se publican como Archivo Suplementario 1 (Supplemental_File_1_Prompts.txt).

4. Etapa 3: Análisis y clasificación del COI

1. Procedimiento.
   1. Haz clic en "Ejecutar siguiente etapa" para ejecutar la etapa 3.
2. Confirma el punto de control de la Fase 3.
   1. Confirma que cada IOC conservado está listado con una categoría estandarizada, una etiqueta de origen y la clave de extracción original cuando esté disponible.

5. Etapa 4: Normalización de la IOC asistida por Neo4j

1. Procedimiento.
   1. Confirma que la conexión Neo4j está activa.
   2. Haz clic en "Ejecutar siguiente etapa" para ejecutar la etapa 4.
   3. Inspecciona la salida de normalización por IOC y verifica que se producan etiquetas de conservación/descarte para los componentes de ruta y línea de comandos, y que las claves de registro generen una subcadena canónica contigua.
2. Confirma el punto de control de la Etapa 4.
   1. Confirma que se producen tablas IOC normalizadas para cada tipo de IOC (rutas de archivos, claves de registro, indicadores de línea de comandos).
   2. Verifica que cada entrada incluya el valor original, el valor normalizado y una lista de componentes de pares elemento/estado etiquetada como conservar o descartar.
      NOTA. El esquema detallado de Neo4j, las consultas de cifrado, las reglas de decisión y el procedimiento de normalización de claves de registro se listan en el Archivo Suplementario 2; un ejemplo trabajado se proporciona en Resultados Representativos.

6. Etapa 5: generación y puntuación de regex

1. Procedimiento.
   1. Haz clic en "Ejecutar siguiente etapa" para ejecutar la etapa 5. Confirma que cada IOC normalizado y su lista de tokens prohibidos han sido sometidos para generación de regex y validación determinista.
   2. Si un candidato falla la validación, permite que el bucle de optimización refine el regex hasta que se produzca un candidato conforme o se alcance el límite de iteración.
   3. Inspecciona la salida diagnóstica, el historial de optimización y los conteos de iteraciones de cualquier IOC cuyo regex final pase de cumplir a coincidencia parcial con la puntuación más alta (registrado como used_fallback = Verdadero).
2. Confirma el punto de control de la Etapa 5.
   1. Confirma que se produce un regex final para cada IOC conservado.
   2. Verifica que se registren las puntuaciones de los candidatos, los historiales de optimización, las listas de incidencias y el número de iteraciones.
   3. Verifica que la telemetría por IOC, incluyendo el uso estimado de tokens y la latencia, esté registrada.
      NOTA. Las reglas detalladas de validación regex, la fórmula de puntuación y los parámetros de control de iteración se listan en el Archivo Suplementario 2.

7. Análisis y validación

1. Abre la pestaña de Analítica para revisar las distribuciones IOC, resultados de votación en conjunto (cuando estén habilitados), resúmenes de calidad regex y estadísticas de optimización. Utiliza estos resúmenes para detectar anomalías como desequilibrio en la extracción o fallos repetidos de optimización.

8. Resultados de exportación

1. En la pestaña Exportar, selecciona el formato de exportación (texto plano, JSON o YAML) y descarga el conjunto de regex. Confirma que los regex exportados incluyen las puntuaciones asociadas y los metadatos de categorización.
2. Genera y descarga el informe JSON completo que contiene documentos analizados, IOCs extraídos, representaciones normalizadas, regex candidatos y resultados finales. Conserva este informe como un registro de reproducibilidad.

9. Resolución de problemas

1. Si la Etapa 1 devuelve contenido PDF truncado o vacío, preprocesa el documento con un convertidor externo o una herramienta de reconocimiento óptico de caracteres antes de volver a subirlo, y confirma que los artefactos técnicos siguen siendo visibles en la vista previa de Markdown.
2. Si la Etapa 2 devuelve muy pocos IOCs de consenso, verifica la configuración del proveedor, modelo, clave API, conteo de repeticiones y votos mínimos antes de cambiar el umbral. Inspeccionar a los candidatos excluidos para distinguir alucinaciones de votaciones excesivamente estrictas.
3. Si la Etapa 4 etiqueta todos los componentes como descartados, verifica la conectividad Neo4j y confirma que el grafo contiene el vocabulario relevante de Ruta, Registro o interfaz de línea de comandos (CLI) para el tipo IOC que se está analizando.
4. Si la etapa 5 produce un regex que se compila pero no coincide o generaliza en exceso, inspecciona el historial de optimización, la posición de fallo diagnóstico y las comprobaciones de sobregeneralización antes de regenerar el candidato.

10. Confirmar las salidas finales del protocolo.

1. Confirma que el archivo Markdown analizado, el conjunto IOC (validado por consenso cuando se habilita la votación en conjunto, o modelo único cuando está deshabilitado), la tabla IOC categorizada y las representaciones IOC normalizadas por grafos están todos presentes.
2. Confirma que el conjunto de regex compatible con SIEM, los resúmenes analíticos y el informe JSON completo están presentes, y archiva el informe JSON como el registro de reproducibilidad.

Resultados

Esta sección presenta resultados representativos producidos por el protocolo IOC-a-regex y resume la evaluación de referencia utilizada para evaluar su aplicabilidad operativa. La evaluación de referencias procesó 3.156 informes CTI asociados con técnicas MITRE ATT&CK, analizó más de 230.000 frases, extrajo más de 63.000 candidatos IOC y evaluó regex generados frente a más de 2.400 cadenas de verificación sobre el terreno recogidas de forma independiente de diez escenarios de evaluación MITRE ATT&CK. Estas cadenas de verificación son artefactos de ataque curados por expertos que reportan de forma independiente los proveedores de ciberseguridad durante los ejercicios de evaluación MITRE ATT&CK y, por tanto, reflejan los patrones estructurales que los analistas y proveedores humanos documentan en la práctica. Los resultados siguientes se centran en el comportamiento de los flujos de trabajo, la corrección estructural y los resultados de evaluación relevantes para el análisis operativo de registros y los flujos de detección.

En la Figura 1 se ofrece una visión general de la pipeline de extremo a extremo, que resume las etapas de búsqueda del grupo de captura y generación de regex que enmarcan el resto de los resultados representativos.

Etapa 1: Análisis de Documentos Resultados

La Figura 2 muestra la salida de la Etapa 1, donde un informe CTI de entrada se analiza en una representación Markdown unificada. Tras la ejecución exitosa, la interfaz muestra una vista previa estructurada del documento, incluyendo los límites de sección e indicadores de relevancia.

La ejecución correcta se indica mediante una segmentación coherente de párrafos y la preservación de artefactos técnicos como rutas de archivos, claves de registro y fragmentos de línea de comandos. Un truncamiento excesivo o la pérdida de formato en esta etapa puede afectar al análisis posterior y debe abordarse antes de continuar.

Fase 2: Extracción de la IOC basada en consenso

La Figura 3 ilustra el resultado de la Fase 2, donde se extraen los IOC candidatos mediante votación en conjunto multi-LLM. La interfaz resultante presenta una colección IOC en formato JSON anotada con recuentos de votos y modelos contribuyentes.

Solo se conservan las IOC que cumplen el umbral mínimo de consenso configurado. Los IOC excluidos en esta etapa suelen reflejar alucinaciones específicas del modelo o fragmentos de texto ambiguos. Su exclusión es un resultado esperado y deseable, lo que indica que la votación colectiva está funcionando correctamente.

Fase 3: Análisis y clasificación del COI

La Tabla 2 resume la salida esperada, los pasos de validación automatizada y las comprobaciones de control de calidad orientadas a los analistas para cada etapa del protocolo.

La Figura 4 muestra los candidatos del COI que no alcanzaron el umbral de consenso durante la votación del conjunto en la Fase 2 y que la interfaz aparece para la inspección por parte de los analistas. Estos candidatos suelen reflejar alucinaciones específicas del modelo o fragmentos de texto ambiguos. Por tanto, la Figura 4 y la Figura 5 corresponden a salidas de etapa distintas — el conjunto descartado de la Etapa 2 y el conjunto retenido de la Etapa 3 — en lugar de a vistas alternativas del mismo proceso de la Etapa 3.

La Figura 5 presenta la tabla de IOC retenida producida por la Etapa 3 tras el análisis JSON, la categorización basada en reglas y la deduplicación IOC. Para cada IOC retenido, la etapa registra una categoría estandarizada, una etiqueta de origen y la clave de extracción original cuando está disponible, antes de pasar la IOC a la normalización posterior.

Etapa 4: Normalización de IOC asistida por grafo entre tipos de IOC

Las Figuras 6, 7 y 8 ilustran los resultados representativos de normalización para tres categorías IOC abordadas en el estudio actual: rutas de archivos, claves de registro e indicadores de línea de comandos. Para cada categoría, las figuras comparan el IOC original extraído del informe CTI con la representación normalizada producida mediante análisis asistido por grafos.

En todos los tipos de IOC, el protocolo descompone cada IOC en componentes semánticos y resuelve relaciones jerárquicas utilizando conocimientos estructurados codificados en la base de datos de grafos. En la implementación actual, Neo4j almacena nodos normalizados de Path, Registry y CLI y utiliza relaciones de adyacencia para comprobar si los componentes pertenecen a cadenas reconocidas. Este papel es análogo al uso del conocimiento estructurado de ATT&CK durante la ingeniería de detección².

Es importante destacar que este paso de normalización registra roles semánticos explícitos para los componentes IOC etiquetandolos como keep o descartar en lugar de eliminarlos silenciosamente del registro de análisis. La cadena normalizada se reconstruye principalmente a partir de componentes de conservación, mientras que los componentes de descarte permanecen disponibles como metadatos para la generación y validación de regex posteriores.

La correcta ejecución de esta etapa se indica mediante IOCs normalizados que mantienen un contexto estructural significativo y exhiben un etiquetado consistente de grupos de captura entre diferentes tipos de IOC. La comparación visual entre representaciones originales y normalizadas proporciona un mecanismo práctico de control de calidad para verificar que la resolución del grupo de captura se ha aplicado de forma consistente y sin pérdida de información no intencionada.

Etapa 5: Generación de expresiones regulares con selección basada en restricciones auxiliares

La Figura 9 ilustra la salida de la Etapa 5, donde el protocolo genera expresiones regulares estructuralmente compatibles a partir de IOCs normalizados mediante un flujo de trabajo de validación iterativo. La implementación combina un prompt de generación inicial, re-prompting diagnóstico cuando un candidato no coincide con el IOC, validación consciente de descartes y bucles de reintento limitados.

Dado un IOC normalizado y su especificación asociada de componente/descarte, el flujo de trabajo genera primero un candidato inicial a regex. El candidato es entonces evaluado contra el IOC, se le vuelve a solicitar diagnósticos cuando falla la coincidencia, se comprueba si hay tokens descartados prohibidos y se evalúa por generalización excesiva usando cadenas negativas aleatorias.

Cuando varios candidatos cumplen las comprobaciones básicas de validación, el protocolo aplica un mecanismo auxiliar de selección basado en restricciones para conservar un regex representativo para uso posterior. La implementación actual puntua a los candidatos con 'Puntuación = n_cg - n_wc', donde 'n_cg' es el número de componentes de conservación representados y 'n_wc' es el número de tokens descartados o no mapeados presentes en el regex.

La función de selección se define como:

Marcador = n_cg − n_wc

Esta es la especialización de igual peso (α = β = 1) de la forma más general Puntuación = α·n_cg − β·n_wc. Aquí, n_cg denota el número de componentes de keep representados y n_wc denota el número de componentes de descarte o tokens extra no mapeados reintroducidos por la regex. La implementación también registra el número de iteraciones, listas de emisión, consumo estimado de tokens, uso de caché y telemetría de latencia para cada IOC. La configuración de peso igual se utilizó como un valor determinista simple por defecto para la implementación de referencia; Dado que considera igualmente indeseable un componente de conservación faltante y un componente de descarte reintroducido, pueden preferirse otras ponderaciones en contextos de despliegue donde los falsos negativos y falsos positivos conllevan diferentes costes operativos.

El regex final se selecciona como el candidato que mejor satisface estas restricciones. Las regex que colocan componentes de grupo de captura requeridos dentro de constructos opcionales, por ejemplo ( ... )?, se excluyen de la selección porque debilitan la consistencia semántica. Este paso de selección es auxiliar al proceso de generación y no pretende servir como una métrica de calidad independiente.

Visión general analítica del procesamiento CTI

La Figura 10 ofrece una visión general de los resultados del análisis CTI en todos los documentos procesados. En la evaluación de referencias, la extracción de IOC de más de 3.156 informes CTI produjo más de 63.000 candidatos IOC, incluyendo 12.195 rutas de archivo, 2.302 claves de registro y 10.286 indicadores de línea de comandos, mientras que los candidatos restantes pertenecían a tipos IOC no objetivo regex.

Estos recuentos proporcionan una validación de alto nivel de que los indicadores extraídos están concentrados en las tres categorías IOC dirigidas por el protocolo actual, al tiempo que muestran que muchos artefactos extraídos permanecen fuera del alcance de la generación de regex. Al reproducir el flujo de trabajo, informa del número exacto de informes CTI procesados, el total de candidatos a IOC, los recuentos por categorías y el proveedor, modelo, versión del modelo, temperatura, recuento de repeticiones y umbral de consenso utilizado durante la extracción.

En la evaluación de referencia, los regex generados se compararon con más de 2.400 cadenas de verificación en el terreno recogidas de forma independiente de diez escenarios de evaluación MITRE ATT&CK y alcanzaron una tasa media de aciertos del 99,1 % junto con una tasa media de desajuste entre COI del 0,8 %. En este manuscrito, la tasa de desajuste se utiliza como medida de especificidad semántica: una desadaptación ocurre cuando un regex generado para un COI también coincide con una cadena de verificación asociada a otro COI. Esta cantidad no debe interpretarse como una tasa de falsos positivos operativos de alerta de extremo a extremo, que también depende de la lógica de reglas aguas abajo y del contexto de despliegue.

La distribución refleja la composición estructural del corpus CTI y permite a los usuarios verificar que los indicadores extraídos se alinean con los tipos esperados de IOC. Grandes desviaciones respecto a las proporciones esperadas pueden indicar problemas de análisis o extracción aguas arriba y deben examinarse antes de proceder a la normalización posterior y generación de regex.

Análisis de las acciones de optimización Regex

La Figura 11 resume las acciones realizadas durante la generación y refinamiento de expresiones regulares. La distribución incluye tres tipos de acciones: generación inicial de regex, pasos de optimización impulsados por LLM y regeneración basada en reintentos.

La optimización impulsada por LLM representa el 51,7 % de todas las acciones observadas. Esta prevalencia indica que la generación inicial por sí sola suele ser insuficiente para producir regex que cumplan con las restricciones de grupo de captura y los requisitos de exclusión. En su lugar, la optimización iterativa se aplica activa y repetidamente para refinar los regex candidatos.

En lugar de reflejar ineficiencia, esta distribución demuestra que el flujo de trabajo de optimización es un componente necesario e integral del protocolo al generar regexes estructuralmente compatibles a partir de entradas complejas de IOC.

Una caracterización de escalabilidad separada sobre una muestra aleatoria de 6.000 IOCs generados con el LLM de prueba de escalabilidad (véase la Tabla de Materiales) reportó una latencia mediana de 2,95 s por IOC y una latencia media de 23,18 s. En la misma caracterización, la compilación de regex sintaxis válida alcanzó el 99,56 %, el éxito general de generación alcanzó el 99,4 %, el uso estimado medio de tokens fue de aproximadamente 3.986 tokens por IOC, y el flujo de trabajo requirió aproximadamente 7,89 llamadas LLM por IOC de media. Las tasas de éxito en la primera pasada fueron del 56,46 % para el bucle de emparejamiento y depuración y del 72,92 % para el bucle de validación no capturado por grupo. Estas mediciones ayudan a caracterizar el coste computacional y el rendimiento operativo para uso por lotes.

No se utilizó ninguna revisión experta de un subconjunto de salida muestreada para el reentrenamiento del modelo en la caracterización de referencia actual; Los resultados reportados reflejan la ejecución automatizada de la tubería y los conjuntos de datos de evaluación aguas abajo descritos anteriormente.

Evidencia operativa y manejo de fallos. La Figura 12 muestra la estructura del archivo regulares SIEM exportado producido por el protocolo, junto con evidencia de validación a nivel de regla para patrones representativos de ruta de archivo, clave de registro y línea de comandos. La Figura 13 muestra el informe JSON completo correspondiente, que expone todas las salidas de la etapa (IOCs extraídos, analizados y normalizados junto con los patrones regex generados y las banderas de validación por IOC) y es el artefacto principal que consume la herramienta aguas abajo. La Figura 14 ilustra el manejo por parte del protocolo de una entrada CTI ruidosa: en la fase de análisis se marca una ruta de archivo desconectada y perturbada por espacios en blanco, se corrige, se normaliza a la plantilla canónica %TEMP% y luego se convierte en una regla regular compiladora y coincidente. Este ejemplo resuelto complementa la evidencia operativa en la Figura 12 y la Figura 13 documentando cómo se comporta el protocolo cuando el texto en bruto de la IOC se aparta de la forma canónica.

Figura 1: Arquitectura general del protocolo IOC-a-regex. La figura resume la línea de conductos de extremo a extremo. Las cadenas IOC candidatas producidas por el extractor IOC aguas arriba se descomponen y comparan con nodos de referencia en un grafo Neo4j repoblado desde la documentación de Windows (paso 1), que recupera componentes conocidos de camino, registro y línea de comandos (paso 2). Los fragmentos variables o específicos del entorno se etiquetan como descartados y se excluyen de la reconstrucción normalizada mientras se conservan en los metadatos de los componentes, lo que da lugar a una IOC normalizada con etiquetas de conservación y descarte a nivel de componente (paso 3). Estos IOCs normalizados se pasan luego a una etapa de generación de regex basada en LLM (paso 4) que produce expresiones regulares candidatas, que se puntuan y optimizan iterativamente según las restricciones del grupo de captura y las reglas de tokens descartados (paso 5) antes de seleccionar un regex final (paso 6). Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 2: Etapa 1 de la salida del análisis sintáctico. Comparación lado a lado del informe original del CTI y la vista previa del documento analizado. El panel izquierdo muestra el informe CTI original en formato PDF, mientras que el panel derecho muestra la representación unificada de Markdown generada por el analizador. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 3: Extracción de COI basada en consenso usando votación en conjunto multi-LLM. La interfaz ilustra el proceso de extracción de IOC basado en conjuntos y sus resultados intermedios. El recuadro rojo destaca las instancias configuradas del LLM que participan en la extracción IOC, incluyendo los proveedores seleccionados y el número de ejecuciones de extracción repetidas realizadas para cada modelo. El recuadro azul indica el umbral de consenso definido por el usuario, que especifica el número mínimo de ocurrencias requeridas para que se mantenga un IOC. Tras agregar los resultados de extracción en todos los modelos y repeticiones, se descartan los IOC candidatos que aparecen menos veces que el umbral. El recuadro naranja muestra el conjunto final de IOCs retenidos que cumplen el criterio de consenso y se pasan a las etapas posteriores de análisis. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 4: COI descartados por votación conjunta en la Fase 2. Vista lado a lado de los candidatos del COI que no alcanzaron el umbral mínimo de voto configurado durante la votación conjunta y que se presentan para la inspección de analistas. Los candidatos descartados suelen reflejar alucinaciones específicas del modelo o fragmentos de texto ambiguos y no se pasan al paso de categorización de la Etapa 3. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 5: Conjunto de IOC retenido con clasificación estandarizada. Los candidatos IOC retenidos tras el procesamiento de la Etapa 3 se muestran junto con sus categorías estandarizadas, etiquetas de origen y claves de extracción originales cuando están disponibles. Esta tabla proporciona la entrada estructurada del IOC utilizada por la etapa de normalización. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 6: Normalización de IOC en la ruta de archivo usando análisis asistido por grafos. Comparación lado a lado de un IOC original de ruta de archivo y su representación normalizada. Las consultas de recorrido basadas en grafos conocen a los componentes de Path por nombre normalizado y etiquetan cada componente como keep o descart. Por tanto, los identificadores de unidad y los fragmentos de nombres de archivo variables pueden marcarse como descartados en el registro de componentes, mientras que la forma normalizada se reconstruye principalmente a partir de segmentos estructurales conservados necesarios para la construcción de patrones aguas abajo. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 7: Normalización de IOC de clave de registro usando análisis asistido por grafos. Normalización de una clave de registro IOC mediante resolución asistida por grafos de estructuras jerárquicas de registros. Las claves raíz abreviadas se expanden a colmenas canónicas de registros, y el analizador extrae la subcadena de registro contigua más larga conocida mientras omite los marcadores de lugar del host, valores similares a SID y tokens similares a GUID. Los registros de salida conservan/descartan etiquetas para cada componente retenido y producen una ruta canónica de registro para el procesamiento posterior. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 8: Normalización IOC en línea de comandos usando análisis asistido por grafos. Comparación de un IOC original de línea de comandos y su representación normalizada. El protocolo tokeniza la línea de comandos mientras conserva las cadenas comilladas, normaliza el token de comando principal mediante búsqueda en Neo4j cuando es posible, y analiza recursivamente fragmentos incrustados tipo path o registry. Los componentes estables relacionados con comandos se etiquetan como keep, los argumentos de variables se etiquetan como descart, y la estructura de comandos canónica final se reconstruye a partir de los elementos mantenidos. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 9: Selección basada en restricciones de candidatos a expresión regular. Se generan múltiples candidatos regex para cada IOC normalizado utilizando un flujo de trabajo de validación iterativo. Se aplica un mecanismo de puntuación impulsado por restricciones para seleccionar un regex final que preserve los componentes designados del grupo de captura mientras limita las subcadenas de variables no deseadas. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 10: Distribución de los IOCs extraídos entre los informes de CTI. Resumen de los resultados de extracción de IOC que muestran el número total de indicadores identificados a partir de informes CTI y su distribución entre rutas de archivos, claves de registro e indicadores de línea de comandos. Esta vista proporciona una validación de alto nivel de la cobertura de contenido y el comportamiento de extracción de CTI. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 11: Distribución de las acciones de optimización durante la generación de expresiones regulares. Desglose de las acciones realizadas durante la generación de regex, incluyendo la generación inicial, la optimización impulsada por LLM y la regeneración basada en reintentos. La optimización impulsada por LLM representa el 51,7 % de todas las acciones, lo que ilustra que el refinamiento iterativo es un componente esencial del protocolo para producir regex que cumplan con las restricciones del grupo de captura. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 12: Archivo regex representativo exportado. Contenido de muestra de la exportación de regex SIEM (siem_rules.txt) generada por el protocolo. Cada entrada incluye el IOC de origen, la categoría inferida (ruta de archivo, clave de registro o línea de comandos) y el patrón regex validado. La tabla de validación adjunta resume el comportamiento esperado y la evidencia del sistema utilizada para confirmar la corrección de cada tipo de regla. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 13: Informe representativo completo de JSON. Salida de la tubería de extremo a extremo producida tras ejecutar las cinco etapas del protocolo en un informe CTI representativo. El documento JSON registra el archivo fuente, el recuento de secciones analizadas, los IOCs extraídos agrupados por categoría, los registros categorizados de la etapa 3 con etiquetas de fuente, la diferencia de normalización de la etapa 4 y los patrones regex de la etapa 5 con flags de validación por IOC. El informe también expone metadatos de éxito y errores de alto nivel que permiten a las herramientas posteriores detectar fallos parciales. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Figura 14: Entrada fallida o ruidosa: identificación y corrección. Ejemplo práctico de cómo el protocolo identifica y recupera de un IOC ruidoso. La entrada en bruto %T E M P%\malware[.]EXE se marca porque su token de variable de entorno contiene espacios insertados y su extensión de archivo ha sido eliminada. El paso de corrección elimina el espacio en blanco insertado y restaura el punto literal; La normalización de la etapa 4 amplía entonces %TEMP% a la plantilla canónica de directorios Windows Temp; y la etapa 5 genera un regex que compila y coincide con el IOC normalizado corregido. Este ejemplo ilustra el manejo de entradas ruidosas discutido en la Discusión. Por favor, haz clic aquí para ver una versión ampliada de esta figura.

Elemento	Tipo	Valor / Esquema	Ejemplo	Notas
Etiqueta de nodo	Sello	:P ath	Windows, System32, cmd.exe	Almacena componentes de ruta de archivos de Windows
Etiqueta de nodo	Sello	:Registro	SOFTWARE, Microsoft, Windows NT	Almacena componentes clave del registro bajo colmenas de raíz
Etiqueta de nodo	Sello	:CLI	powershell.exe, -Política de Ejecución, Bypass	Almacena, tokens de comando y parámetros
Propiedad del nodo	Cuerda	Nombre	cmd.exe	Carcasa original; Usado para visualización en salida normalizada
Propiedad del nodo	Cuerda	name_lower	cmd.exe	Forma minúscula; se usa como clave de búsqueda para todas las consultas MATCH
Relación	Arista dirigida	(a)-[:SIGUIENTE]->(b)	(Windows)-[:SIGUIENTE]->(System32)	Ambos extremos comparten la misma etiqueta; codifica adyacencia nativa en sistemas Windows
Limitaciones	Singularidad	n.name_lower ÚNICO por etiqueta	-	Solicité :P ath, :Registry, :CLI
Fuente de datos	Cobertura	Windows 8, 10, 11	-	Sistema operativo cliente poblado en grafo
Fuente de datos	Cobertura	Windows Server 2012, 2016, 2019, 2022	-	Servidor operativo poblado en grafos

Tabla 1: Esquema de grafo Neo4j utilizado para la normalización del IOC (Etapa 4). Enumera las tres etiquetas de nodos (Ruta, Registro, CLI), su esquema de propiedades compartidas (nombre, name_lower), la relación de adyacencia dirigida utilizada para el orden nativo de las aristas, las restricciones de unicidad y las versiones cliente y servidor de Windows que pueblan el grafo.

Escenario	Producción esperada	Validación automatizada	Control de calidad orientado a analistas
Etapa 1: Análisis de documentos	Texto Markdown unificado, fragmentado en 4.000 caracteres antes del procesamiento del LLM.	—	Comprobación visual de la vista previa de Markdown para confirmar que las rutas de archivos, claves de registro, fragmentos de línea de comandos y límites de sección sobreviven al análisis sintáctico; Cambia de backend si las cadenas técnicas están truncadas.
Fase 2: Extracción del COI	JSON con tres claves de nivel superior (Rutas de archivo, Líneas de comandos, Claves de registro); los conteos de votos por COI y los metadatos del modelo contribuyente cuando se habilita la votación en conjunto.	El filtro umbral de consenso (min_votes) excluye a los IOC cuyo recuento de votos esté por debajo del umbral configurado.	Inspección de los candidatos excluidos para distinguir alucinaciones de votos excesivamente estrictos antes de ajustar min_votes.
Fase 3: Análisis y clasificación del COI	Lista IOC categorizada: cada IOC emparejado con una categoría estandarizada, etiqueta de origen y clave de extracción original cuando está disponible.	Mapeo de categorías estandarizadas mediante reglas regulares y heurísticas de patrones IOC; (COI, categoría) deduplicación de pares.	Comprobación puntual de la salida categorizada para candidatos ambiguos o ruidosos (Figura 4A).
Etapa 4: Normalización asistida por Neo4j	Formulario normalizado por IOC con etiquetas de conservación/descarte a nivel de componente.	Consultas cifradas (i)-(iii) sobre el grafo de referencia de Windows; Respaldo de preprocesamiento determinista cuando Neo4j no está disponible.	Inspección de casos totalmente descartables para identificar brechas en la cobertura de grafos; Extensión de datos de grafos con referencias específicas de proveedor o entorno cuando sea necesario.
Fase 5: Generación y puntuación de regex	Regex final por IOC con puntuaciones de candidatos, historial de optimización, recuento de iteraciones y telemetría por IOC.	Prueba de emparejamiento, controles de calidad estáticos, comprobación de tokens prohibidos consciente de fronteras, prueba de sobregeneralización contra 5 muestras deterministas negativas; Retrocediendo a la partida parcial con mayor puntuación (used_fallback bandera).	Revisión del historial de optimización para regex de respaldo; inspección diagnóstica de la posición de fallo por IOC antes de regenerar.

Tabla 2: Resumen de la salida de etapas y la validación. Mapea cada etapa del protocolo (1–5) a su artefacto esperado, a la evidencia de validación automatizada producida por la tubería (estado de compilación regex, tasa de acierto, tasa de desajustes entre IOC, recuentos de iteraciones de optimización) y la comprobación de control de calidad correspondiente dirigida a los analistas (comparación visual, inspección de candidatos descartados y revisión de categorías).

Archivo suplementario 1: Prompts de LLM literalmente. El sistema literal y los prompts humanos usados para la extracción de IOC de la Etapa 2 y la generación y optimización de regex de la Etapa 5. Por favor, haga clic aquí para descargar este archivo.

Archivo suplementario 2: Detalles de implementación para las etapas 4 y 5. Detalles algorítmicos e implementadores que soportan la normalización IOC asistida por grafos de la Etapa 4 y la validación, puntuación e iteración de regex de la Etapa 5. Por favor, haga clic aquí para descargar este archivo.

Discusión

Traducir informes CTI no estructurados en lógica de detección ejecutable sigue siendo una tarea que consume mucho tiempo y es propensa a errores en los flujos de trabajo de seguridad operativa. Aunque los esfuerzos previos han explorado la automatización a nivel de extracción de IOC o generación de reglas de alto nivel, los profesionales aún enfrentan desafíos importantes para convertir cadenas IOC extraídas en regex estructuralmente correctos, semánticamente precisos y adecuados para el uso posterior de SIEM. El protocolo presentado aquí aborda esa brecha mediante un flujo de trabajo escalonado en el que cada fase produce un artefacto intermedio bien definido y aplica una validación explícita antes de pasar los resultados a la siguiente etapa. La Figura 14 documenta uno de estos casos, en el que se identifica, corrige, normaliza y convierte en una ruta de archivo con descolmillos y perturbación en espacio en blanco; El manejo ruidoso de entradas del protocolo y su alcance actual se discuten conjuntamente con las limitaciones enumeradas a continuación.

Una contribución central de este protocolo es su descomposición explícita del flujo de trabajo en etapas con salidas intermedias inspeccionables. La implementación ahora se describe concretamente: el análisis de documentos produce Markdown y texto fragmentado para el procesamiento de LLM; La extracción IOC emite JSON estructurado para rutas de archivos, claves de registro e indicadores de línea de comandos; el análisis IOC basado en reglas estandariza y deduplica los valores extraídos; La normalización asistida por Neo4j etiqueta cada componente IOC como conservar o descartar; y la generación de regex aplica comprobaciones de depuración de coincidencias, validación de descartes y sobregeneralización antes de la selección de candidatos.

El protocolo trata la generación de expresiones regulares como una tarea de construcción iterativa en lugar de un problema de predicción puntual. La implementación utiliza un aviso de generación inicial, diagnósticos automáticos de coincidencias, bucles de refinamiento limitados y una función de puntuación basada en componentes para preservar elementos estructuralmente importantes de IOC mientras penaliza subcadenas descartadas o no mapeadas. Este diseño iterativo, junto con validadores deterministas aplicados en cada paso, permite la producción de patrones regex que permanecen estructuralmente fieles a lo largo de un conjunto de evaluación grande y heterogéneo. En la evaluación de referencia, este flujo de trabajo se aplicó a 3.156 informes CTI y se evaluó frente a más de 2.400 cadenas independientes de verificación en el terreno, lo que dio una tasa media de aciertos del 99,1 % y una tasa media de desajustes entre COI del 0,8 %. Debido a que estas cadenas de verificación de terreno son artefactos seleccionados por expertos reportados por proveedores de ciberseguridad durante los ejercicios de evaluación MITRE ATT&CK, esta evaluación compara implícitamente la salida del protocolo con los patrones del IOC documentados por analistas humanos en lugar de con los generados automáticamente.

Como se muestra en los resultados representativos, la optimización iterativa es especialmente importante cuando el flujo de trabajo maneja estructuras complejas de IOC como rutas de archivo anidadas o cadenas largas de línea de comandos. Los resultados de la evaluación de referencias también indican que los casos no coincididos más comunes ocurren cuando los atacantes utilizan ejecutables o parámetros personalizados que no están representados en la base de datos de grafos o que no están explícitamente documentados en los informes CTI de origen. En uso operativo, estos modos de fallo deben tratarse como condiciones de contorno esperadas en lugar de errores silenciosos y deberían desencadenar la revisión de la cobertura de grafos, la completitud del informe fuente y la telemetría de depuración regex.

El protocolo puede compararse con tres familias de métodos alternativos. Primero, métodos de síntesis de regex basados en ejemplos como TransRegex¹¹ y Regex+¹² aprenden regex a partir de conjuntos seleccionados de ejemplos de cadenas positivas y negativas. Estos métodos funcionan bien cuando existen conjuntos de ejemplo representativos pero son menos directamente aplicables a contextos SOC, donde cada IOC reportado en CTI suele aparecer como una sola cadena representativa, y el límite de generalización requerido está guiado por semántica operacional más que por cobertura de ejemplo. En segundo lugar, los enfoques de programación genética como los introducidos por Bartoli et ^al.13,14 buscan en el espacio de regexes mediante operadores evolutivos y normalmente requieren un corpus etiquetado de cadenas de coincidencia y no coincidencia; son muy adecuados para la construcción por lotes de patrones de extracción, pero no consumen directamente narrativas CTI no estructuradas. En tercer lugar, los enfoques neuronales y basados en LLM^{recientes 15,16} traducen descripciones en lenguaje natural directamente a cadenas regex; estos métodos son potentes para prompts bien especificados pero, en uso de un solo disparo, pueden producir regex sintácticamente válidos pero que no cumplen con los componentes requeridos del grupo de captura o se generalizan en exceso entre variantes IOC no relacionadas. El protocolo actual complementa estas instrucciones (i) tomando informes CTI no estructurados en lugar de conjuntos de ejemplo seleccionados o consultas en lenguaje natural como entrada, (ii) descomponiendo cada IOC en componentes de keep y descart mediante normalización asistida por grafo antes de generar cualquier regex, y (iii) validando cada regex candidato con comprobaciones deterministas de coincidencia, descarte y sobregeneralización dentro de un bucle iterativo limitado. El objetivo no es superar a los métodos previos en sus propios benchmarks, sino proporcionar una cadena reproducible de IOC a regex cuyas decisiones intermedias sean inspeccionables y auditables por los analistas SOC.

El protocolo hace varias suposiciones sobre la calidad de los informes CTI de entrada. Asume que (i) las cadenas de IOC aparecen en forma textual recuperable después del análisis de documentos, es decir, que las rutas de archivos, claves de registro e indicadores de línea de comandos no están incrustados exclusivamente en imágenes, capturas de pantalla o codificaciones ofuscadas; (ii) los fragmentos IOC reportados en el CTI son lo suficientemente completos para preservar sus anclajes estructurales (por ejemplo, las claves de registro conservan su prefijo colmena, las rutas de archivo conservan al menos un ancla de directorio reconocible para el grafo de documentación de Windows, y las líneas de comandos conservan el ejecutable que invoca o una referencia conocida a un módulo); y (iii) los IOC reportados no se truncan, redactan ni se reescriben de manera que eliminen los componentes del grupo de captura de los que depende el protocolo. Los informes CTI que cumplen estas suposiciones incluyen la mayoría de las descripciones de técnicas MITRE ATT&CK, avisos a proveedores, informes de respuesta a incidentes y boletines de amenazas bien formateados. Los informes que dependen principalmente de capturas de pantalla, listas IOC muy abreviadas sin contexto circundante o paráfrasis en texto libre sin cadenas explícitas de IOC quedan fuera del ámbito operativo previsto y deben esperarse que produzcan una reducción en la recuperación de extracción y una normalización menos fiel; Estos informes pueden beneficiarse de un preprocesamiento de imagen a texto o revisión por parte de los analistas antes de entrar en la pipeline.

Deben considerarse varias limitaciones al aplicar este protocolo. En primer lugar, la implementación actual se centra en rutas de archivos, claves de registro e indicadores de línea de comandos, en lugar de categorías más amplias de IOC como dominios, artefactos de correo electrónico, cadenas de usuario-agente o secuencias de comportamiento. Esta es una elección deliberada de alcance, ya que los indicadores atómicos suelen estar bien servidos por flujos de trabajo de coincidencia exacta y el protocolo actual apunta a IOCs de estructura variable que se benefician de la generalización regex; sin embargo, limita la aplicabilidad a tipos IOC que actualmente no están representados en el gráfico. En segundo lugar, los escenarios de fallo actuales se dividen en tres categorías principales: rutas no nativas o argumentos de línea de comandos que están ausentes en el grafo del sistema operativo, cobertura incompleta del grafo para utilidades o estructuras relevantes, e incompletitud en la propia fuente CTI cuando fragmentos de comandos importantes o cmdlets nunca se reportan. En tercer lugar, la métrica de desajuste entre IOC utilizada en la evaluación de referencia mide la especificidad semántica de los regex generados en lugar de los falsos positivos de alerta de extremo a extremo bajo la lógica SIEM desplegada.

Reproducibilidad bajo la variabilidad y el versionado de los LLM. Dado que las etapas de extracción y generación de regex de IOC dependen de endpoints LLM comerciales, dos fuentes de variabilidad afectan a la reproducibilidad: las actualizaciones del modelo del lado del proveedor a lo largo del tiempo y la estocasticidad del muestreo por llamada. Para mitigar el primero, todos los campos relacionados con LLM en la Tabla de Materiales registran los identificadores exactos del modelo y la fecha de acceso utilizada en la evaluación de referencia, y el protocolo recomienda fijar a una instantánea específica del modelo siempre que el proveedor exponga una. Para mitigar la segunda, la implementación de referencia fija la temperatura de extracción de IOC en 0,0 y utiliza una temperatura distinta de cero solo en la etapa de generación de regex, donde la votación en conjunto y los validadores deterministas en las etapas 2 y 5 absorben la variación residual. Al replicar estos resultados, los usuarios deben registrar la versión exacta del modelo, la fecha de acceso, la temperatura y el umbral de voto del conjunto utilizado; Se debe esperar que las desviaciones sustantivas en cualquiera de estos ejes desvíen las métricas de tasa de aciertos y desajustes.

Varios modos de fallo recuperables pueden abordarse a nivel de la etapa que los produjo. Fallos de análisis de la etapa 1 (por ejemplo, PDFs escaneados que producen Markdown vacíos o distorsionados): preprocesar la entrada con reconocimiento óptico de caracteres o un convertidor externo antes de volver a subir; Verifica que el conteo de secciones analizadas y el total de caracteres sean distintos de cero antes de continuar. Fallos de extracción de la etapa 2 (sin IOCs devueltos ni entradas alucinadas): aumentar el umbral de voto en conjunto (votos mínimos ≥ 2), habilitar instancias adicionales del modelo o reducir la temperatura del LLM; verificar la conectividad de la API y que el modelo configurado acepte salida en formato JSON. Normalización de la etapa 4 con etiquetas totalmente descartadas (cada componente IOC se etiqueta como descartado): extender el grafo de referencia Neo4j con componentes de ruta específicos de proveedor o entorno y raíces de registro; los scripts de importación de cifrado y la regla de decisión de conservar/descartar están listados en el Archivo Suplementario 2. Fallas regex de la etapa 5 (used_fallback = rechazos verdaderos, o repetidos por validación de descartes): inspeccionar el campo de historial de optimización por IOC para identificar el validador que falla; si el COI realmente carece de componentes estables de mantenimiento, considera la creación manual de regex para ese COI o excluirlo de la generación automatizada de reglas mientras lo conserva en la tabla categorizada del COI para revisión por analistas.

En consonancia con las limitaciones anteriores, los regex generados se tratan mejor como primitivas de búsqueda reutilizables dentro de contenido más amplio de detección de SOC en lugar de detectores autosuficientes. En entornos operativos, los analistas pueden combinarlos con lógica de campo específica de la plataforma, listas blancas, comprobaciones de procedencia o condiciones de correlación para suprimir coincidencias benignas que surjan de rutas inusuales pero no maliciosas.

El trabajo futuro puede incluir comparaciones sistemáticas con regex creados por humanos, una evaluación más amplia en categorías adicionales de IOC, estudios estructurados de retroalimentación entre analistas, una cobertura ampliada de grafos para utilidades y cmdlets creados por atacantes, y un reporte más completo de la latencia y el coste de extremo a extremo en entornos de despliegue. No obstante, el protocolo actual proporciona un marco reproducible y operativamente interpretable para la traducción de IOC a regex que documenta tanto sus fortalezas como sus límites actuales.

Materiales

Lista de materiales utilizados en este artículo

Nombre	Empresa	Número de catálogo	Comentarios
Computer (CPU)	—	≥ 4 cores recomendados	No se requiere GPU
LangChain	LangChain	≥ 0.1.x	Marco de orquestación LLM
LLM (extracción de IOC, modelo único)	OpenAI	gpt-5.1	Utilizado para la extracción de IOC (Etapa 2) cuando la votación del conjunto está deshabilitada. temperatura = 0.0; max_workers = 5. Accedido: 2025-12-15.
LLM (Generación de Regex)	OpenAI	gpt-5.1	Utilizado para la generación de Regex (Etapa 5). temperatura = 0.3 antes de la validación descendente. Accedido: 2025-12-15.
LLM (Caracterización de escalabilidad)	OpenAI	gpt-5.1	Utilizado para la ejecución de escalabilidad de 6,000 IOC reportada en Resultados Representativos. Accedido: 2025-12-15.
Memoria (RAM)	—	≥ 16 GB recomendado	Requerido para el procesamiento de documentos
Neo4j	Neo4j, Inc.	≥ 5.x	Base de datos gráfica para la normalización de IOC
Neo4j Python Driver	Neo4j, Inc.	≥ 5.x	Interfaz Python para Neo4j
Sistema Operativo	Microsoft / Apple / Linux	Windows, macOS o Linux	Soporte multiplataforma
Análisis PDF — backend principal	Microsoft	MarkItDown ≥ 0.0.x	Backend de la Etapa 1; convierte entradas PDF/DOCX/HTML/TXT a Markdown. Salida analizada dividida en fragmentos de 4,000 caracteres antes del procesamiento LLM. Accedido: 2025-12-15. https://github.com/microsoft/markitdown
Configuración del Pipeline (Etapa 2 — extracción de IOC)	—	Referencia a los valores predeterminados	Modo de LLM único: temperatura = 0.0, max_workers = 5. Los valores predeterminados del modo de votación del conjunto: repeticiones = 1 por modelo configurado, min_votes = 2.
Configuración del Pipeline (Etapa 5 — generación de regex)	—	Referencia a los valores predeterminados	Temperatura de generación = 0.3. Validación: overgen_random_tests = 5 muestras negativas deterministas por IOC. Límites de iteración: max_iterations = 10, debug_loop_cap = 5, discard_validation_cap = 5.
Python	Python Software Foundation	≥ 3.8	Entorno de tiempo de ejecución requerido
Motor de expresiones regulares	Biblioteca estándar de Python	módulo re	Utilizado para la validación y prueba de expresiones regulares
Streamlit	Streamlit Inc.	≥ 1.25	Interfaz de usuario basada en web
Código fuente de la implementación de referencia	Autores / GitHub | Repositorio de GitHub		Código fuente para la interfaz Streamlit, el pipeline LangChain, la normalización asistida por Neo4j, la generación de regex, utilidades de validación y archivos de configuración de ejemplo. Disponible en https://github.com/SOCautomatic/cti-ioc-regex-pipeline. Accedido: 11 de junio de 2026.