Escribir una regla Sigma para una CVE o técnica: del comportamiento a una detección que no ahoga al SOC

Un informe describe una nueva técnica: la explotación de una CVE, el abuso de un binario de sistema legítimo, un comportamiento post-explotación. Quieres saber si ocurre en tu entorno. Sigma es el formato pivote para eso: un YAML legible, independiente del SIEM, que escribes una vez y conviertes a Splunk, Elastic o Sentinel. Pero escribir la regla es una cosa; escribir una regla que se dispare con el comportamiento real sin sepultar al SOC bajo falsos positivos es otra.

Un punto importante de entrada: Sigma detecta un comportamiento en los logs, no una vulnerabilidad en la red. Para una CVE, eso significa detectar la explotación (lo que el ataque hace en el host (un proceso lanzado, una clave de registro modificada, un comando característico)) no el fallo en sí. Este artículo muestra cómo pasar de un comportamiento descrito a una regla que aguanta en producción, y cómo demostrarlo.

La anatomía de una regla Sigma

Una regla Sigma se resume en unos pocos bloques:

title: Ejecución sospechosa de MSHTA desde un directorio temporal
id: 7c9d2e10-4a3b-4f8e-9c1a-000000000000
status: experimental
description: Detecta mshta.exe lanzando un script desde una ruta temporal, técnica de ejecución observada tras la explotación.
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\mshta.exe'
        CommandLine|contains:
            - '\Temp\'
            - '\AppData\Local\Temp\'
    filter_legit:
        ParentImage|endswith: '\msiexec.exe'
    condition: selection and not filter_legit
falsepositives:
    - Despliegues de software legítimos mediante MSI
level: high
tags:
    - attack.execution
    - attack.t1218.005

El logsource dice dónde buscar (aquí, los eventos de creación de procesos de Windows). El bloque detection combina una selection (los criterios que caracterizan la técnica) y, a menudo, un filter (lo que hay que excluir). La condition lo ensambla todo. Los campos falsepositives, level y tags no son decorativos: hacen la regla clasificable y utilizable por el SOC.

El logsource es la mitad del trabajo

Una regla Sigma solo vale algo si el dato que consulta existe. Dos trampas antes incluso de escribir la detection:

• La categoría correcta. process_creation, registry_event, network_connection… elegir la equivocada es escribir una regla que nunca se aplicará a los eventos correctos.
• Tu telemetría real. Si tu configuración de Sysmon no registra las líneas de comando, ninguna regla basada en CommandLine se disparará, por correcta que sea. La detección empieza por la recolección: confirma que tus logs contienen el campo del que dependes.

Partir del comportamiento, no de una regla copiada

Como en toda detección, el punto de partida es el hecho, no la expresión de otro. Un informe de análisis describe lo observable: el proceso lanzado, su padre, el argumento característico, la clave escrita. Ese hecho no pertenece a nadie, la regla que derivas de él es obra tuya. Copiar una regla publicada bajo licencia copyleft o sin licencia en un conjunto cerrado o revendido, en cambio, contaminaría sus derechos.

En concreto: lee el informe, aísla la acción mínima y fiable que prueba la técnica, y construye la selection en torno a ella, no en torno a todo lo que hizo el atacante, solo al signo más discriminante.

La disciplina del falso positivo

Aquí es donde fracasan la mayoría de reglas en producción. Una selection demasiado amplia (CommandLine|contains: 'powershell') se dispara miles de veces al día sobre actividad legítima. Tres reflejos:

• Aprieta la selección. Combina varios campos (Image y CommandLine y ParentImage) en lugar de un único patrón vago.
• Filtra lo legítimo conocido. El bloque filter retira los usos limpios que coincidirían de todos modos (una herramienta de administración, un despliegue MSI). El campo falsepositives documenta lo que queda.
• Desconfía de los tokens comunes. Una palabra aislada que aparece en eventos de autenticación o nombres de servicio triviales produce una tormenta de alertas. Prefiere siempre una combinación específica a un token único.

Cartografiar ATT&CK

Rellena los tags con la táctica y la técnica MITRE ATT&CK (attack.execution, attack.t1218.005). No es cosmético: es lo que permite al SOC clasificar, medir su cobertura y correlacionar la regla con el resto de su detección. Una regla sin etiqueta ATT&CK es una regla huérfana.

Validar no basta: hay que demostrar

Las herramientas pySigma verifican la sintaxis y la coherencia:

sigma check regla.yml

Pero «válida» no significa «se dispara en el momento correcto». La prueba es empírica, en dos pasos:

1. ¿La regla se dispara con la técnica real? Conviértela a tu SIEM (mediante el backend pySigma), dispara la técnica en un entorno de pruebas (un proyecto como Atomic Red Team reproduce cientos de técnicas ATT&CK de forma controlada) y luego confirma que aparece la alerta. Si no se dispara nada, la regla es inútil.
2. ¿Cuánto ruido sobre tráfico normal? Pasa la regla convertida sobre un día de logs reales y benignos. El número de disparos te dice si es desplegable o si ahogará al analista.

Una regla que se dispara con la técnica y permanece tranquila en el día a día vale infinitamente más que una simplemente «válida». Es la diferencia entre «compila» y «detecta, demostrado».

Las trampas que salen caras

• El token aislado en un evento común. La primera causa de tormentas de falsos positivos. Combina; nunca te fíes de una sola palabra.
• El logsource equivocado. Una regla archivada en la categoría errónea no se aplica a nada, un falso negativo silencioso.
• Los nombres de campo. Tras la conversión, Image se convierte en process.executable en ECS, otra cosa en otro sitio. Comprueba que el mapeo encaja con tu esquema, o la consulta no coincidirá con nada.
• La selección demasiado amplia. Un único contains vago desplegado en producción, y el SOC te llama en la hora siguiente.

En resumen

Escribir una buena regla Sigma para una CVE o técnica es un método: detectar la explotación (el comportamiento en los logs, no el fallo), partir del hecho del informe, apretar la selección y filtrar lo legítimo, cartografiar ATT&CK, y demostrar empíricamente que la regla se dispara con la técnica sin ahogar el día a día. El resto (validación sintáctica, etiquetas, nivel) es higiene.

Es exactamente la disciplina que aplicamos a escala en el feed Sigma de ThreatClaw: cada regla se prueba en su disparo real, se cartografía sobre ATT&CK y se entrega lista para convertir a tu SIEM. Recibes la detección, no un YAML que todavía hay que poner a prueba.