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 ...

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...

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.