De un log a una detección que funciona en cualquier SIEM

Durante una investigación encuentras el patrón: un 4625 seguido de un 4624 desde la misma IP, o un PowerShell con -enc. Bien. Ahora conviértelo en una detección permanente. Y aquí llega el problema de siempre: la escribes en KQL y solo vale para Sentinel; tu compañero la necesita en SPL para Splunk; el de al lado, en Elastic. Tres veces el mismo trabajo, tres sitios donde se desincroniza.

Sigma: el «YAML de las detecciones»

Sigma es un formato abierto y neutral para reglas de detección. Escribes la lógica una vez, en YAML legible, y un conversor la traduce al lenguaje de tu SIEM: KQL, SPL, Lucene/EQL de Elastic, Wazuh… Es a las detecciones lo que las reglas YARA son a los ficheros: portable y compartible. Por eso las publican vendors, CERTs y proyectos como el repo oficial de reglas Sigma.

Anatomía de una regla

title: Inicio de sesión fallido
name: fallo_login
status: experimental
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4625
  condition: selection
---
title: Inicio de sesión correcto
name: exito_login
status: experimental
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID: 4624
  condition: selection
---
title: Racha de fallos de inicio de sesión
name: muchos_fallos
status: experimental
correlation:
  type: event_count
  rules:
    - fallo_login
  group-by:
    - TargetUserName
    - IpAddress
  timespan: 10m
  condition:
    gte: 5
---
title: Fallos seguidos de éxito (posible fuerza bruta)
status: experimental
correlation:
  type: temporal_ordered
  rules:
    - muchos_fallos
    - exito_login
  group-by:
    - TargetUserName
    - IpAddress
  timespan: 1h
falsepositives:
  - VPN corporativa con reintentos legítimos
level: medium
tags:
  - attack.credential-access
  - attack.t1110.001

Las piezas que importan: logsource (de dónde salen los eventos), detection con una o varias selecciones y una condition que las combina, el level (severidad) y —clave— falsepositives y los tags de MITRE ATT&CK, que enganchan la regla a una técnica concreta. Cuando hay que enlazar varios eventos, entra en juego correlation.

Una corrección. La primera versión de este artículo usaba una sola regla con condition: fallo and exito. Esa regla nunca salta: la condition se evalúa sobre cada evento por separado, y ningún evento es a la vez un 4625 y un 4624. «Primero esto, luego aquello» es una correlación: event_count cuenta los fallos y temporal_ordered exige que el éxito llegue después.

Del log a la regla, paso a paso

1. Aísla el evento en el log real: qué campos lo identifican (EventID, imagen del proceso, línea de comandos, puerto…).
2. Escribe la selección con esos campos. Sé específico: Image|endswith: '\powershell.exe' y CommandLine|contains: '-enc' es mucho mejor que buscar solo «powershell».
3. Define la condición (una selección, varias con and/or, o exclusiones con not filtro).
4. Mapea a ATT&CK y documenta los falsos positivos que ya conoces.
5. Convierte y prueba en tu SIEM antes de darla por buena.

El enemigo real: los falsos positivos

Una regla que dispara cien veces al día no es una detección, es ruido que el analista aprende a ignorar —y ahí es donde se cuela el ataque de verdad—. Selecciones precisas, exclusiones de lo legítimo conocido, y un level honesto separan una regla útil de una que acaba silenciada.

Checklist

• ✅ ¿La detección está atada a UN SIEM? Escríbela en Sigma y conviértela.
• ✅ Selección específica (imagen + argumentos + campos), no palabras sueltas.
• ✅ condition clara; usa not para excluir lo legítimo conocido.
• ✅ Mapea a MITRE ATT&CK y rellena falsepositives.
• ✅ Pruébala con un evento real antes de desplegarla.

Escribir en Sigma no es una capa más de trabajo: es escribir una vez en lugar de tres, y dejar la detección donde cualquiera —tú incluido dentro de seis meses— pueda leerla y llevarla a su plataforma.

Sergio Belmonte Morales
Analista de Ciberseguridad · SOC · Especialista en Sentinel/KQL