Sigma rules avanzado: correlación, near-real-time y testing CI/CD

Las reglas Sigma simples son el punto de partida de cualquier SOC que quiera detection-as-code: describen un patrón en un evento y el conversor lo traduce al lenguaje del SIEM. Pero un atacante competente rara vez deja su huella en un solo log. La kill chain genera decenas de eventos relacionados, y la detección que mira uno solo produce demasiado ruido o no tiene contexto suficiente para distinguir actividad legítima de un ataque real.

Las reglas de correlación resuelven ese problema: combinan múltiples eventos, los agrupan por un campo común (host, usuario, proceso) y aplican condiciones temporales o estadísticas. El resultado es una alerta de mayor fidelidad que reduce falsos positivos y detecta cadenas de ataque que una regla simple jamás captaría. Es la sexta lección de la Tanda 8.

Las reglas Sigma de correlación son herramientas defensivas. Conocer las técnicas ofensivas que detectan es necesario para escribir buenas detecciones, pero toda práctica debe realizarse exclusivamente en entornos autorizados y controlados.

Qué son las reglas de correlación Sigma#

Una regla Sigma estándar describe una condición sobre un solo evento: un proceso con cierto nombre de comando, un login fallido con un código de error específico, una conexión a un puerto inusual. Detecta el evento, pero no su contexto.

Una regla de correlación toma como entrada el resultado de una o varias reglas base y aplica una lógica adicional:

• Ventana temporal: los eventos deben ocurrir dentro de un periodo (por ejemplo, 5 minutos).
• Agrupación: los eventos deben compartir un campo (mismo host, mismo usuario, misma IP de origen).
• Condición agregada: un conteo mínimo, una combinación obligatoria, o un valor que supera un umbral.

El resultado no es un evento detectado, sino una cadena de eventos correlacionada que indica un comportamiento de mayor riesgo.

La especificación de correlación se incorporó a Sigma en 2023 y herramientas como pySigma 0.10+ y sigma-cli la soportan. Los backends de conversión (Splunk, Elastic, Microsoft Sentinel) generan las queries de correlación nativas del SIEM a partir del YAML.

Por qué las reglas simples son insuficientes#

Una regla que detecta powershell.exe con DownloadString en la línea de comandos parece útil. En un entorno corporativo con automatización legítima de PowerShell, esa regla puede disparar docenas de veces al día con actividad completamente benigna. El analista SOC deja de mirarla y, cuando un atacante real la activa, nadie responde.

El problema de raíz es que un evento aislado carece de contexto. Las causas más comunes de falsos positivos en reglas simples son:

• Actividad administrativa legítima que usa las mismas herramientas que un atacante.
• Software de automatización (SCCM, Ansible, scripts de IT) que genera los mismos patrones.
• Herramientas de seguridad propias (vulnerability scanners, EDR) que disparan detecciones de reconocimiento o ejecución.

La correlación soluciona esto exigiendo que varios indicadores coincidan. Un DownloadString seguido de la instalación de un servicio nuevo en el mismo host en menos de cinco minutos es mucho más sospechoso que cualquiera de los dos por separado.

Tipos de correlación en Sigma#

La especificación define tres tipos principales de regla de correlación. Cada uno responde a un escenario distinto.

Correlación temporal#

Es la más expresiva. Define una lista de reglas base y exige que todas (o un subconjunto) disparen en una ventana, agrupadas por un campo común. Ejemplo conceptual en YAML:

title: Execution followed by persistence and C2
type: correlation
rules:
    - sigma_execution_download_cradle
    - sigma_persistence_new_service
    - sigma_network_c2_beacon
group-by:
    - ComputerName
timespan: 5m
condition:
    gte: 3
level: high

Esta regla solo dispara si las tres reglas base se activan en el mismo host dentro de cinco minutos. El false positive rate cae drásticamente respecto a cada regla individual.

Correlación por conteo de eventos#

Cuenta cuántas veces dispara una regla base. Es ideal para detectar fuerza bruta:

title: Brute force login attempts
type: correlation
rules:
    - sigma_failed_logon
group-by:
    - TargetUserName
timespan: 2m
condition:
    gte: 10
level: high

Diez logins fallidos del mismo usuario en dos minutos. Una regla simple que detectara cada login fallido individual sería inútil por el volumen de ruido.

Correlación por conteo de valores#

Cuenta valores distintos de un campo. Detecta password spray, donde un atacante prueba una contraseña contra muchas cuentas:

title: Password spray detection
type: correlation
rules:
    - sigma_failed_logon
group-by:
    - IpAddress
timespan: 10m
condition:
    field: TargetUserName
    gte: 15
level: high

Si desde una misma IP se intentan logins fallidos contra 15 o más cuentas distintas en diez minutos, se activa la alerta.

Dónde se aplica la correlación#

La correlación Sigma es útil en cualquier entorno con un SIEM capaz de ejecutar queries sobre ventanas temporales. Los escenarios más frecuentes son:

• Detección de kill chains: encadenar ejecución inicial, movimiento lateral, persistencia y exfiltración en una sola alerta de alta fidelidad.
• Detección de fuerza bruta y password spray: conteos de eventos o valores que superan umbrales en ventanas cortas.
• Anomalías de comportamiento: un usuario que accede a más de N sistemas distintos en una hora, cuando su baseline es de 2-3.
• Correlación cross-source: un login exitoso desde una IP que coincide con un indicador de compromiso en el feed de threat intel.
• Detección de exfiltración: volumen de datos salientes que supera el baseline del usuario o equipo en una ventana.

CI/CD para reglas Sigma#

Una regla que no se prueba es una regla que no se puede confiar. Detection-as-code significa aplicar las mismas prácticas de ingeniería de software a las detecciones: versionado en Git, code review, testing automatizado y deploy controlado.

Estructura del repositorio#

detections/
├── sigma/
│   ├── rules/
│   │   ├── windows/
│   │   │   ├── process_creation/
│   │   │   └── authentication/
│   │   └── linux/
│   ├── correlations/
│   │   ├── lateral_movement_chain.yml
│   │   └── brute_force.yml
│   └── tests/
│       ├── true_positives/
│       │   └── lateral_movement_chain_tp.json
│       └── false_positives/
│           └── lateral_movement_chain_fp.json
└── .github/
    └── workflows/
        └── sigma-ci.yml

Cada regla tiene al menos un test de true positive (evento que DEBE detectar) y un test de false positive (evento que NO debe detectar).

Pipeline paso a paso#

El pipeline de CI/CD para Sigma tiene cinco etapas. Cada una atrapa un tipo distinto de error.

Paso 1: Lint y validación de esquema. sigma-cli valida la sintaxis YAML, comprueba que los campos obligatorios existen (title, id, logsource, detection, level), que los tags MITRE son válidos y que el UUID es único en el repositorio.

pip install sigma-cli
sigma check rules/windows/lateral_movement_chain.yml

Un error de lint frecuente es un campo de logsource que no coincide con ningún pipeline del backend: la regla es válida sintácticamente pero el conversor la ignora.

Paso 2: Unit test con true positives. Un archivo JSON con un evento que la regla debe detectar. El framework de testing carga el evento, aplica la regla y verifica que la alerta se dispara.

pytest tests/ -v --sigma-backend splunk

Paso 3: Unit test con false positives. Un evento benigno que la regla no debe detectar. Si la regla dispara sobre actividad legítima en el test, el pipeline falla y el autor debe refinar la condición antes de mergear.

Paso 4: Integración con logs reales. Replay de una muestra de logs anonimizados del entorno de producción. Mide el false positive rate estimado antes de que la regla llegue a producción. Esta etapa es la más costosa de implementar pero la que más valor aporta.

Paso 5: Deploy a producción. Si todas las etapas pasan, el pipeline convierte la regla al lenguaje del SIEM destino y la publica vía API. Un rollback automático desactiva la regla si el FP rate en las primeras horas supera un umbral definido.

sigma convert -t splunk -p splunk_windows rules/windows/lateral_movement_chain.yml
curl -X POST https://splunk.internal/api/saved_searches -d @converted_rule.json

Métricas de calidad#

Construyendo una correlación paso a paso#

Ejemplo práctico: detectar movimiento lateral vía PsExec seguido de ejecución de herramienta de reconocimiento en el host destino.

Paso 1: Regla base para PsExec remoto#

title: PsExec Remote Service Installation
id: b5c7e29c-1f1a-4c3d-ae9b-d8f742a1e001
logsource:
    product: windows
    service: system
detection:
    selection:
        EventID: 7045
        ServiceName|contains: 'PSEXE'
    condition: selection
level: medium
tags:
    - attack.lateral_movement
    - attack.t1021.002

Paso 2: Regla base para herramienta de reconocimiento#

title: Network Reconnaissance Commands
id: b5c7e29c-1f1a-4c3d-ae9b-d8f742a1e002
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        CommandLine|contains:
            - 'net group "domain admins"'
            - 'nltest /dclist'
            - 'net view /all'
    condition: selection
level: low
tags:
    - attack.discovery
    - attack.t1018

Cada regla por separado genera ruido: PsExec se usa legítimamente en administración, y los comandos de reconocimiento son comunes en scripts de IT. Pero la combinación es distinta.

Paso 3: Regla de correlación temporal#

title: Lateral Movement followed by Reconnaissance
type: correlation
rules:
    - b5c7e29c-1f1a-4c3d-ae9b-d8f742a1e001
    - b5c7e29c-1f1a-4c3d-ae9b-d8f742a1e002
group-by:
    - ComputerName
timespan: 10m
condition:
    gte: 2
level: high
tags:
    - attack.lateral_movement
    - attack.t1021.002
    - attack.discovery
    - attack.t1018

Si en el mismo host se instala un servicio PsExec y luego se ejecuta un comando de reconocimiento de dominio en menos de diez minutos, la alerta es de alta severidad. Los falsos positivos caen porque la coincidencia temporal y de host es muy infrecuente en actividad legítima.

Paso 4: Probar con Atomic Red Team#

# En el host de test: simular la cadena
Invoke-AtomicTest T1021.002 -TestNumbers 1
Start-Sleep -Seconds 30
Invoke-AtomicTest T1018 -TestNumbers 1

Verificar en el SIEM que la regla correlada dispara. Luego ejecutar cada técnica por separado, con más de diez minutos de diferencia, y verificar que la correlación NO dispara (solo las reglas base individuales).

Impacto de la correlación en el SOC#

La correlación transforma la operación del SOC. Los beneficios son medibles.

Errores comunes al implementar correlación#

• Ventanas demasiado amplias: una ventana de una hora correlaciona eventos no relacionados y genera falsos positivos. Empezar con ventanas cortas (2-10 minutos) y ampliar solo si los tests lo justifican.
• Falta de group-by: sin agrupar por host o usuario, la correlación mezcla eventos de máquinas distintas y pierde significado.
• No probar el caso negativo: verificar que la correlación dispara es fácil. Verificar que NO dispara con actividad legítima es igual de importante y se olvida con frecuencia.
• Ignorar el orden del pipeline: si el SIEM backend no soporta correlación nativa, el conversor genera queries menos eficientes o directamente no puede traducir la regla. Verificar compatibilidad antes de escribir.
• Correlación sin reglas base probadas: si la regla base tiene errores, la correlación hereda esos errores multiplicados. Cada regla base necesita sus propios tests antes de correlarse.
• Sin métricas post-deploy: una regla correlada desplegada sin medir FP rate en la primera semana puede generar ruido que pase desapercibido hasta que el equipo la silencie manualmente.

Preguntas frecuentes#

¿Todos los SIEM soportan correlación Sigma?#

No directamente. La conversión depende del backend de pySigma. Splunk (con tstats y datamodel), Elastic (EQL sequences), y Microsoft Sentinel (KQL con join/let) soportan traducción de correlaciones. Para SIEMs que no lo soportan, la alternativa es ejecutar la correlación en una capa externa (como un script que consulta el SIEM periódicamente).

¿Cuándo uso correlación temporal y cuándo event_count?#

Correlación temporal es para detectar secuencias de técnicas distintas (kill chains). Event_count es para detectar repetición de la misma técnica (brute force). Value_count es para detectar la misma técnica contra múltiples objetivos (password spray). La elección depende de lo que modela el ataque.

¿Es mejor escribir una sola regla compleja o varias correladas?#

Varias correladas. Reglas base modulares se reutilizan en múltiples correlaciones y se prueban de forma independiente. Una regla monolítica con veinte condiciones es difícil de mantener, probar y depurar.

¿Cuánto tarda implementar CI/CD para Sigma?#

Un pipeline básico (lint + schema check) se monta en una tarde. Tests con true y false positives llevan una semana de trabajo para cubrir las reglas principales. Integración con logs reales anonimizados requiere coordinación con el equipo de datos y puede llevar un sprint completo. Empieza con lint y escala.

¿Dónde practico correlación?#

Los laboratorios taurus e integrity-breach de whoami-labs generan eventos de log que puedes analizar. Para practicar con un SIEM real, instala Splunk Free (500 MB/día de ingesta), configura Sysmon con la config de SwiftOnSecurity en una VM Windows, y escribe tus primeras correlaciones contra los logs que genera Atomic Red Team.

Resumen#

• Correlación Sigma combina múltiples eventos en ventanas temporales para detectar cadenas de ataque con alta fidelidad.
• Tres tipos: temporal (secuencias), event_count (repetición), value_count (spray/amplitud).
• CI/CD obligatorio: lint, unit test con true/false positives, integración con logs reales, deploy automatizado.
• Métricas: FP rate, MTTD, cobertura ATT&CK y salud de la regla son los indicadores que importan.
• Modularidad: reglas base reutilizables que se combinan en correlaciones.
• Impacto: reducción medible de alert fatigue y mejora del tiempo de triage.

Fuentes y lecturas recomendadas#

• SigmaHQ — repositorio oficial
• sigma-cli — herramienta de línea de comandos
• pySigma — librería Python
• Sigma correlation specification
• Atomic Red Team
• MITRE ATT&CK — Lateral Movement
• MITRE ATT&CK T1021.002 — SMB/Windows Admin Shares