Reglas portables — escribir una vez en Sigma

Sigma es un formato abierto para describir detecciones sobre registros. Una regla es un archivo YAML que dice qué fuente mira, qué tienen que cumplir los eventos y cuándo salta. No es un motor: ningún SIEM ejecuta el YAML tal cual. Un conversor lo traduce al lenguaje de cada producto, con un destino («backend») por SIEM: el mismo archivo sale como búsqueda SPL, como consulta KQL o como AQL. La herramienta de línea de comandos de la comunidad hace esa conversión indicándole el destino y el mapeo de campos que corresponde.

Lo que se gana es que la regla vive en un solo sitio. Se revisa como texto, se guarda en un repositorio con su historial y se traduce otra vez el día que cambia el SIEM. La comunidad publica miles de reglas en este formato, y eso permite partir de una regla revisada por otros en vez de escribirla desde cero.

Esta es la regla de una notificación de segundo factor no aprobada en la pasarela VPN:

title: Notificación de segundo factor no aprobada en la VPN
name: mfa_no_aprobada_vpn
id: 5b0d6c2e-8a3f-4f61-9c47-2e1d7a90b315
status: experimental
description: La persona rechaza o deja sin respuesta una notificación de segundo factor.
logsource:
  product: pasarela_vpn
  service: autenticacion
detection:
  seleccion:
    action: mfa
    result:
      - rechazado
      - sin_respuesta
  condition: seleccion
falsepositives:
  - Una persona que rechaza por error y aprueba al siguiente intento
level: low
tags:
  - attack.credential_access
  - attack.t1621

logsource dice qué registros mira la regla; el conversor lo usa para elegir el índice o la tabla. detection tiene una o varias selecciones con nombre, y condition las combina con and, or y not (seleccion and not filtro). Dentro de una selección, dos campos distintos se tienen que cumplir a la vez, y una lista de valores bajo un mismo campo vale cualquiera de ellos. El resto es para las personas: qué falsos positivos se conocen, cuánto pesa la alerta y a qué técnica de ATT&CK corresponde.

La regla habla de action y result, nombres genéricos que no son los de ningún SIEM concreto. En el de Delta Aduanas esos campos se llaman accion y resultado, y en el de la casa matriz se llaman de otra forma. El paso que traduce unos nombres en otros, y el logsource en un índice, se llama mapeo (los conversores lo llaman «pipeline»), y se elige al convertir.

Sin el mapeo correcto, la traducción sale con los nombres genéricos. La búsqueda es válida, el SIEM la ejecuta y devuelve cero resultados, sin ningún error. Una regla así aparece en la lista de detecciones activas y no vigila nada. Por eso una regla traducida se prueba siempre contra datos donde se sabe que tiene que saltar antes de darla por buena.

La regla de arriba salta con cada notificación no aprobada, incluida la persona que rechaza una por error y aprueba la siguiente. Lo que distingue un bombardeo es el umbral: cinco o más en una hora sobre la misma cuenta. Contar eventos agrupados no cabe en la selección de una regla básica; las versiones recientes del formato añaden para eso las reglas de correlación, que se apoyan en otra regla por su name:

title: Bombardeo de notificaciones de segundo factor
correlation:
  type: event_count
  rules:
    - mfa_no_aprobada_vpn
  group-by:
    - user
  timespan: 1h
  condition:
    gte: 5
level: high

Traducida a SPL, la correlación se convierte en bin _time span=1h | stats count by _time usuario | where …, lo mismo que escribiste a mano en la sala de stats. No todos los destinos ni todas las versiones del conversor admiten correlaciones: si el tuyo no las admite, la parte del umbral se escribe en el SIEM y se documenta junto a la regla.

En la consola está la regla ya traducida a SPL con el mapeo correcto: primero la selección sola, después con la correlación. Lánzala con la correlación sobre la noche, para comprobar que devuelve lo que ya conocías, y después sobre los últimos siete días. Aparece una cuenta que nadie había investigado.