Reglas Sigma: qué son, cómo funcionan y cómo utilizarlas

El problema: un comportamiento, múltiples dialectos #

Supongamos que en tu equipo de seguridad identificas una técnica recurrente y necesitas detectar esto en los puestos de trabajo corporativos:

WINWORD.EXE
└── powershell.exe

En Splunk podrías escribir una consulta en SPL buscando eventos de creación de procesos.

En Elastic, escribirías una consulta con Lucene, KQL o EQL adaptada al Elastic Common Schema (ECS).

En Microsoft Sentinel, redactarías una consulta KQL sobre la tabla DeviceProcessEvents o SecurityEvent.

En otro SIEM de mercado, formularías una sentencia en otro dialecto propietario.

El comportamiento adverso que necesitas detectar no cambió en lo más mínimo.

Lo único que cambió fue el lenguaje y la sintaxis necesaria para buscarlo.

Ahí es donde aparece Sigma.

Sigma permite expresar detecciones sobre logs mediante un formato estructurado basado en YAML, intentando separar con claridad la lógica de detección del lenguaje concreto utilizado por cada backend de almacenamiento y análisis.

Pero hay una precisión importante que debemos asumir desde el principio:

Sigma no hace que todos los SIEM sean iguales.

Y tampoco convierte automáticamente una buena idea en una detección funcional.

Qué es Sigma y especificación vigente #

Sigma es un formato genérico para representar detecciones sobre datos estructurados de logs.

Una regla Sigma describe formalmente:

• qué tipo de telemetría necesita para operar (fuente de logs);
• qué valores, patrones o cadenas de texto busca en los eventos;
• cómo deben relacionarse esas condiciones booleanas;
• qué comportamiento o técnica adversaria intenta identificar;
• información contextual para documentar, clasificar y operar la alerta resultante.

La especificación oficial y estable vigente es Sigma Specification 2.1.0. Mantiene definidos con precisión la sintaxis YAML, los bloques de fuentes de datos, las selecciones, modificadores, filtros y convenciones de etiquetado. Aunque la comunidad de SigmaHQ desarrolla trabajo de cara a una futura revisión 2.2.0 (con ampliaciones en reglas de correlación), la 2.1.0 constituye la referencia operativa formal.

Una regla Sigma representativa y sencilla se estructura de la siguiente manera:

title: Office Spawning PowerShell
id: 4dc7ab2e-f639-4da6-82f1-93467b55c85b
status: experimental
description: Detects Microsoft Office applications spawning PowerShell.
author: Achirou
date: 2026-10-07

logsource:
    category: process_creation
    product: windows

detection:
    selection_parent:
        ParentImage|endswith:
            - '\WINWORD.EXE'
            - '\EXCEL.EXE'
            - '\POWERPNT.EXE'
            - '\OUTLOOK.EXE'

    selection_child:
        Image|endswith:
            - '\powershell.exe'
            - '\pwsh.exe'

    condition: selection_parent and selection_child

falsepositives:
    - Legitimate administrative or automation activity

level: medium

Antes de copiarla o desplegarla en ningún entorno, debemos comprender exactamente qué significa cada una de sus partes.

Sigma no es una herramienta de detección por sí sola #

Éste es uno de los malentendidos más extendidos entre analistas que recién se aproximan al ecosistema defensivo.

Una regla Sigma es una representación abstracta de una detección.

No es un agente que monitoriza tus endpoints en tiempo real.

No recibe flujos de logs por la red.

No genera por sí sola una notificación ni crea un ticket en la cola de incidencias.

No sustituye a tu SIEM.

No sustituye a una plataforma EDR.

No sustituye la telemetría de Sysmon ni los Windows Event Logs.

Analiza el flujo real por el que viaja la información defensiva en una infraestructura corporativa:

Sigma se ubica conceptualmente en un nivel superior de abstracción analítica:

La documentación de SigmaHQ define Sigma como un formato genérico de firma y consulta para logs. Es el plano de diseño; no el motor de ejecución ni el sensor recolector.

Por qué existe Sigma: portabilidad real vs universalidad #

Imagina que tu equipo SOC o de Detection Engineering gestiona un catálogo interno de 300 detecciones avanzadas.

Si la empresa utiliza Splunk, todas las reglas estarán codificadas directamente en SPL con comandos de búsqueda y filtros ad-hoc.

Si la compañía adquiere un data lake en Elastic o migra parte de su analítica a Microsoft Sentinel, la lógica defensiva sigue siendo exactamente la misma. Sin embargo, todo el código de búsqueda queda obsoleto.

Sin un formato común de abstracción, el equipo defensivo se ve forzado a mantener múltiples bifurcaciones de la misma regla:

Detección conceptual: Inyección de Procesos
├── Versión SPL (Splunk)
├── Versión KQL (Sentinel / Defender)
├── Versión EQL (Elastic)
├── Versión Lucene (Kibana clásico)
└── Versión QRadar AQL

Sigma transforma ese modelo en un flujo centralizado y sostenible:

            Detección conceptual
                     ↓
             Regla Sigma (YAML)
                     ↓
       ┌─────────────┼─────────────┐
       ↓             ↓             ↓
  Splunk SPL    Elastic EQL    Sentinel KQL

Pero debemos mantener la prudencia técnica:

Portable no significa universal sin adaptación.

La portabilidad significa que la intención analítica puede trasladarse, pero cada destino exige saber cómo interpreta y normaliza la información en sus propios índices.

Las tres piezas más importantes de una regla Sigma #

Aunque un archivo de regla alberga metadatos documentales, referencias y clasificaciones, para comprender la mecánica interna de Sigma basta centrarse en tres bloques estructurales indispensables:

La propia especificación de Sigma organiza formalmente cualquier regla operativa en torno a esta tríada fundamental.

1. `logsource`: ¿sobre qué datos debería funcionar? #

Observa con atención la declaración de origen en una regla:

logsource:
    category: process_creation
    product: windows

Esta declaración no significa en modo alguno:

“Busca esta cadena en todos y cada uno de los eventos de cualquier máquina Windows.”

Declara explícitamente qué categoría y tipo de telemetría necesita la lógica de detección para tener sentido analítico. En este caso concreto:

• Producto: Entorno de sistema operativo windows.
• Categoría: Eventos de creación de procesos (process_creation).

La especificación de Sigma define principalmente cuatro elementos para calificar y dirigir las consultas:

Compara estas dos declaraciones:

# Opción A: categoría funcional genérica
logsource:
    category: process_creation
    product: windows

# Opción B: servicio específico de registro
logsource:
    product: windows
    service: security

No son equivalentes en absoluto. La primera busca telemetría de procesos (que podría provenir de Sysmon Event ID 1 o de la auditoría de seguridad de Windows con Event ID 4688). La segunda restringe la consulta estrictamente al registro del canal Security.

El campo definition resulta fundamental cuando se requiere una configuración previa específica en el endpoint:

logsource:
    product: windows
    category: ps_script
    definition: 'Script Block Logging (Event ID 4104) must be enabled via Group Policy'

Si la organización no tiene activado Script Block Logging en sus endpoints, la regla Sigma es impecable desde el punto de vista sintáctico, pero no producirá jamás una coincidencia porque la telemetría requerida sencillamente no existe.

Sigma no crea la telemetría #

Supongamos que tomamos una regla comunitaria con este encabezado:

logsource:
    category: process_creation
    product: windows

Y dentro de su bloque de detección exige evaluar los siguientes campos:

ParentImage
Image
CommandLine

Pero en los servidores de tu entorno corporativo, la recolección de eventos sólo está ingiriendo:

Image
User
Computer
Timestamp

¿Qué hace Sigma con el campo ParentImage?

Absolutamente nada mágico.

Ese dato no existe en tus almacenes de eventos. Ningún compilador de reglas puede inventar la relación de proceso padre si tus sensores no la registran.

Sigma no crea la telemetría.

Toda detección queda inexorablemente delimitada por la evidencia disponible en tus logs de seguridad. Esta realidad conecta de manera directa con las tres preguntas axiales de Detection Engineering:

1. ¿Qué comportamiento técnico necesito detectar?
2. ¿Qué evidencia y telemetría concreta revela ese comportamiento?
3. ¿Tengo recolectada, normalizada e indexada esa evidencia en mi plataforma?

Sigma aparece únicamente después de haber respondido con solvencia a esas preguntas.

2. `detection`: qué estamos buscando #

El núcleo de la lógica analítica reside en el bloque detection. Analicemos de nuevo nuestra regla de ejemplo:

detection:
    selection_parent:
        ParentImage|endswith:
            - '\WINWORD.EXE'
            - '\EXCEL.EXE'

    selection_child:
        Image|endswith:
            - '\powershell.exe'
            - '\pwsh.exe'

    condition: selection_parent and selection_child

Aquí observamos dos componentes analíticos claramente nombrados:

• selection_parent: describe las características que debe cumplir el proceso progenitor.
• selection_child: describe las características del proceso hijo generado.

Qué es una `selection` y nomenclatura descriptiva

Una selección agrupa uno o varios criterios de evaluación sobre campos de los eventos. Por ejemplo:

selection:
    Image|endswith: '\powershell.exe'

Indica conceptualmente: “Selecciona aquellos eventos donde el campo Image finalice con la cadena \powershell.exe”.

En lugar de llamar a todo simplemente selection, la buena práctica en ingeniería de detección consiste en utilizar identificadores descriptivos:

• selection_office
• selection_powershell
• selection_suspicious_args
• selection_target_paths

Estos nombres permiten que cualquier colega del SOC entienda de inmediato la estructura modular de la regla y facilitan enormemente la depuración booleana dentro de condition.

Lógica booleana: listas (OR) y mapas (AND)

Comprender cómo interpreta Sigma las estructuras YAML es el secreto para leer y escribir reglas con fluidez:

1. Las listas en YAML representan una disyunción lógica (OR):

Image|endswith:
    - '\powershell.exe'
    - '\pwsh.exe'

Se traduce analíticamente como:

(Image termina en \powershell.exe) OR (Image termina en \pwsh.exe)

2. Múltiples campos dentro de una misma selección representan una conjunción lógica (AND):

selection:
    Image|endswith: '\powershell.exe'
    User: 'CONTOSO\admin'

Se traduce analíticamente como:

(Image termina en \powershell.exe) AND (User = 'CONTOSO\admin')

Este estándar de mapeo entre estructuras de datos (clave-valor = AND, array/lista = OR) permite modelar escenarios altamente complejos de manera limpia y sin paréntesis redundantes.

3. `condition`: cuándo se cumple la detección #

Una regla puede contener múltiples selecciones y filtros. La cláusula condition es la encargada de determinar cuándo el motor debe disparar la coincidencia.

# Coincidencia directa simple
condition: selection

# Conjunción lógica: ambas selecciones deben ser verdaderas
condition: selection_parent and selection_child

# Disyunción lógica: basta con que cualquiera sea verdadera
condition: selection_a or selection_b

# Negación / exclusión: se cumple la selección pero NO el filtro
condition: selection and not filter

La especificación 2.1.0 admite además agrupaciones con paréntesis, operadores como 1 of selection_* (si cualquiera de las selecciones que comiencen por dicho prefijo se cumple) y all of selection_* (todas deben cumplirse obligatoriamente).

Una regla con filtro y el criterio de exclusión #

Considera este escenario habitual en organizaciones con automatización:

detection:
    selection:
        ParentImage|endswith:
            - '\WINWORD.EXE'
            - '\EXCEL.EXE'
        Image|endswith:
            - '\powershell.exe'
            - '\pwsh.exe'

    filter_legitimate:
        CommandLine|contains:
            - 'C:\Company\Scripts\Approved\'

    condition: selection and not filter_legitimate

Conceptualmente expresa:

Detectar: Office iniciando PowerShell
EXCEPTO:
Línea de comandos ejecutando scripts en la ruta C:\Company\Scripts\Approved\

Aquí es donde el analista de SOC debe aplicar criterio de seguridad y no mero formateo de texto:

• ¿Es esa carpeta realmente de sólo lectura para usuarios estándar?
• ¿Puede un atacante escribir un archivo o colocar un enlace simbólico en esa ruta?
• ¿Es la ruta susceptible a Path Traversal o colisión de nombres?
• ¿Debemos además exigir que el script esté firmado digitalmente o ejecutado por una cuenta de servicio específica?

Sigma puede expresar un filtro. No puede decidir si el filtro es sensato.

Los modificadores de Sigma y wildcards (* y ?) #

En las reglas analizadas habrás notado construcciones como Image|endswith: o CommandLine|contains:. La barra vertical (|) aplica un modificador de campo (field modifier), indicando cómo debe realizarse la comparación sin depender de funciones propias del SIEM.

Respecto a los comodines o wildcards, Sigma contempla:

• *: coincide con cualquier cantidad de caracteres (cero o más).
• ?: coincide con exactamente un carácter.

Por ejemplo, CommandLine|contains: 'Invoke-*' localizará comandos como Invoke-Mimikatz o Invoke-Expression. Sin embargo, en entornos de gran volumen, el abuso de comodines sin delimitar provoca consultas muy lentas en el SIEM y puede incrementar falsos positivos si no se acompaña de campos estructurados.

Construyamos una regla paso a paso #

Veamos el ciclo completo de modelado a partir de una hipótesis técnica: “Queremos detectar aplicaciones del paquete Office ejecutando PowerShell en estaciones de trabajo Windows.”

Regla completa y documentada

El archivo final resultante incluye metadatos y especificación completa de campos útiles para la investigación:

title: Office Application Spawning PowerShell
id: 4dc7ab2e-f639-4da6-82f1-93467b55c85b
status: experimental
description: Detects Microsoft Office applications spawning PowerShell or PowerShell Core.
author: Achirou
date: 2026-10-07

logsource:
    category: process_creation
    product: windows

detection:
    selection_parent:
        ParentImage|endswith:
            - '\WINWORD.EXE'
            - '\EXCEL.EXE'
            - '\POWERPNT.EXE'
            - '\OUTLOOK.EXE'

    selection_child:
        Image|endswith:
            - '\powershell.exe'
            - '\pwsh.exe'

    condition: selection_parent and selection_child

fields:
    - Computer
    - User
    - ParentImage
    - Image
    - CommandLine

falsepositives:
    - Legitimate Office macros or enterprise automation

level: medium

Los metadatos también importan: especificación vs SigmaHQ #

Una regla Sigma profesional es mucho más que su bloque detection. Los metadatos permiten que un equipo SOC clasifique, priorice, versione y audite el arsenal de detección.

Es importante distinguir entre la especificación oficial de Sigma (que exige un conjunto mínimo para compilar) y las convenciones del repositorio oficial SigmaHQ (que exigen requisitos documentales adicionales para mantener la consistencia comunitaria):

Una aclaración vital sobre falsepositives: este campo no excluye automáticamente eventos. Es documentación operativa destinada a quien investiga la alerta, evitando que un analista asuma compromiso inmediato ante un script corporativo conocido.

Mapear Sigma a MITRE ATT&CK sin sobreetiquetar #

Sigma define el namespace attack dentro de la lista tags para categorizar detecciones contra la matriz de MITRE ATT&CK:

tags:
    - attack.execution
    - attack.t1059.001

Estas etiquetas corresponden a la táctica Execution (attack.execution) y a la técnica específica PowerShell (attack.t1059.001).

Pero debemos evitar una tentación común: añadir etiquetas ATT&CK por decorar.

Asignar attack.t1059.001 no significa que la regla detecte cualquier variante o abuso posible de PowerShell. Indica únicamente que la regla monitoriza una manifestación particular de esa técnica (un proceso Office invocando la shell).

Sobre-etiquetar reglas con técnicas que la lógica no valida directamente arruina los mapas de cobertura del SOC, distorsiona los reportes de ingeniería y genera una falsa sensación de inmunidad.

Sigma no significa “copiar reglas de GitHub” #

El repositorio público de SigmaHQ alberga miles de reglas mantenidas por la comunidad global de ciberseguridad. Representa una de las fuentes abiertas más ricas de conocimiento defensivo disponible.

Sin embargo, en muchos equipos noveles surge una ilusión operativa sumamente peligrosa:

Esta práctica conduce directamente a dos escenarios desastrosos:

1. La avalancha de ruido: Reglas diseñadas para entornos de estricto aislamiento disparan miles de falsos positivos diarios en redes corporativas con actividad administrativa legítima, saturando a los analistas L1 con fatiga de alertas.
2. El silencio ciego: Cientos de reglas convertidas quedan activadas en el SIEM sin fallar formalmente, pero buscando campos o canales que tu empresa jamás ha ingestado. No alertan nunca y generan una falsa ilusión de blindaje.

Cada regla pública fue concebida bajo supuestos técnicos específicos: una versión de sistema operativo concreta, un agente de auditoría determinado o un nivel particular de verbosidad en el registro.

Preguntas obligatorias antes de importar una regla ajena #

Antes de integrar cualquier regla comunitaria en tu entorno de producción, sométela a este cuestionario de evaluación técnica:

Una regla pública es un punto de partida. No una garantía.

El problema de los nombres de campo y la dispersión de esquemas #

En el estándar genérico de Sigma, los eventos de procesos habitualmente utilizan nombres como:

Image
ParentImage
CommandLine

Estos nombres proceden históricamente del modelo de Sysmon en Windows. Sin embargo, en el mundo real, cada fabricante y plataforma utiliza su propia convención taxonómica:

• Elastic Common Schema (ECS): emplea nombres jerárquicos como process.executable, process.parent.executable y process.command_line.
• Microsoft Defender / Sentinel (Advanced Hunting): utiliza tablas con columnas como FolderPath, InitiatingProcessFolderPath y ProcessCommandLine.
• Splunk CIM (Common Information Model): normaliza a campos como process_path, parent_process_path y process_exec en el modelo Endpoint.

Si intentamos traducir directamente la regla sin transformar los nombres de los atributos, la consulta resultante buscará campos inexistentes en la base de datos de seguridad. Para solucionar esta brecha conceptual existen los processing pipelines.

Processing pipelines y backends en pySigma #

En la arquitectura moderna de Sigma, el proceso de traducción se divide limpiamente en dos componentes especializados:

1. ¿Qué es un processing pipeline?

Un pipeline de procesamiento es una capa intermedia de transformación que adapta una regla abstracta a las peculiaridades del entorno de destino antes de generar el código final. Se encarga de:

• Mapeo de nombres de campo: convierte Image en process.executable o en FolderPath.
• Mapeo de fuentes de log: traduce category: process_creation a index=sysmon EventCode=1 o a DeviceProcessEvents.
• Transformación de valores: adapta barras invertidas en rutas de archivo según requiera el motor de búsqueda.
• Inyección de filtros locales: añade automáticamente exclusiones de índices o condiciones corporativas específicas.

2. ¿Qué es un backend?

El backend es el compilador que toma la estructura abstracta ya transformada y escribe la sintaxis ejecutable en el dialecto concreto de la plataforma:

• Backend Splunk: genera sintaxis SPL con comandos de búsqueda.
• Backend Elastic: genera consultas en EQL, KQL o filtros DSL JSON.
• Backend Microsoft Sentinel: genera sentencias estructuradas en Kusto Query Language (KQL).
• Backend QRadar: genera sentencias en AQL.

pySigma y sigma-cli: la cadena de herramientas actual #

Durante años, la comunidad utilizó una herramienta monolítica en Python conocida como sigmac. Esa implementación histórica presentaba limitaciones severas de extensibilidad y acoplaba rígidamente la lógica de parseo con los destinos.

Actualmente, el ecosistema oficial de SigmaHQ está gobernado por pySigma, una librería modular, extensible y moderna en Python que separa por completo el analizador léxico de los backends y pipelines. La herramienta de consola estándar para interactuar con esta arquitectura es sigma-cli.

Instalación y flujo de conversión con sigma-cli

En cualquier entorno de laboratorio o estación de análisis defensivo, sigma-cli puede instalarse cómodamente con Python:

# Instalación recomendada mediante pip o pipx
python -m pip install sigma-cli

# O bien mediante pipx en entornos aislados
pipx install sigma-cli

La herramienta utiliza un sistema de complementos desacoplados. Para consultar qué plugins y backends están disponibles en el registro oficial:

sigma plugin list

Para añadir el backend de Splunk y el de Elasticsearch:

sigma plugin install splunk
sigma plugin install elasticsearch

La sintaxis general para compilar una regla o una carpeta completa es:

sigma convert -t <backend> -p <pipeline> <ruta_regla.yml>

Por ejemplo, para transformar nuestra regla de Office invocando PowerShell hacia Splunk asumiendo telemetría de Sysmon:

sigma convert -t splunk -p sysmon office_powershell.yml

¿Qué hace realmente esa conversión? #

El compilador de Sigma no realiza ningún análisis mágico de amenazas. Su tarea consiste estrictamente en traducir:

Por eso, la consulta resultante jamás debe inyectarse a ciegas en producción sin revisión humana.

Conversión válida no significa detección válida #

Supongamos que ejecutas sigma convert y obtienes una consulta SPL o KQL con sintaxis impecable que compila en menos de un segundo.

Eso no garantiza bajo ningún concepto que tu entorno esté detectando la amenaza.

Conversión válida no significa detección válida.

Una consulta traducida perfectamente puede fracasar por múltiples motivos en tu infraestructura real:

• Tu índice en el SIEM se llama idx_endpoints_prod y la regla compiló buscando en index=wineventlog.
• El sourcetype de tus eventos es personalizado y no coincide con el pipeline estándar.
• El endpoint no tiene habilitada la auditoría de línea de comandos en Windows Event Logs.
• Sysmon no está instalado en esa flota de servidores.
• Los nombres de campo se ingirieron en minúsculas en Elastic y la consulta busca mayúsculas estrictas.
• La retención del índice es de sólo 3 días y la correlación exige una ventana de búsqueda de 7.

Sigma describe intención. El pipeline conecta esa intención con tus datos.

Si la intención es sólida pero el pipeline no refleja con exactitud la topología de tus índices, la consulta devolverá cero resultados mientras el adversario ejecuta comandos con total impunidad.

La cadena completa de diagnóstico en 8 capas #

Cuando una regla convertida no genera alertas tras reproducir la actividad maliciosa en un laboratorio, muchos analistas cometen el error de modificar apresuradamente el archivo YAML de Sigma. En lugar de tocar la regla a ciegas, debemos recorrer metódicamente cada eslabón de la cadena:

Laboratorio: crear tu primera regla Sigma paso a paso #

Para asentar los conceptos sin incurrir en riesgos operativos, desarrollaremos un ejercicio práctico con un comportamiento estrictamente benigno y controlado en un entorno Windows de laboratorio.

Objetivo analítico: Detectar cuándo una consola de PowerShell genera un proceso secundario de símbolo del sistema (cmd.exe).

Start-Process cmd.exe -ArgumentList '/c whoami'

powershell.exe
└── cmd.exe
    └── whoami.exe

title: PowerShell Spawning Command Shell
id: 1d6203a0-d20b-4b72-a920-4b5803b53ced
status: experimental
description: Detects PowerShell console spawning cmd.exe.
author: Achirou
date: 2026-10-07

logsource:
    category: process_creation
    product: windows

detection:
    selection:
        ParentImage|endswith:
            - '\powershell.exe'
            - '\pwsh.exe'
        Image|endswith: '\cmd.exe'

    condition: selection

fields:
    - Computer
    - User
    - ParentImage
    - Image
    - CommandLine

falsepositives:
    - Legitimate administration scripts and build tools

level: low

sigma convert -t splunk -p sysmon powershell_spawning_cmd.yml

sigma convert -t elasticsearch -p ecs powershell_spawning_cmd.yml

Cómo mejorar nuestra regla de Office y PowerShell #

Retomemos la regla inicial donde una aplicación ofimática invoca PowerShell. En su forma genérica, alertaba ante cualquier proceso hijo:

detection:
    selection_parent:
        ParentImage|endswith:
            - '\WINWORD.EXE'
            - '\EXCEL.EXE'
    selection_child:
        Image|endswith:
            - '\powershell.exe'
    condition: selection_parent and selection_child

Si en nuestra organización existen complementos corporativos aprobados que ejecutan scripts legítimos, podríamos caer en la tentación de restringir drásticamente la detección para alertar sólo ante argumentos fuertemente sospechosos:

detection:
    selection_parent:
        ParentImage|endswith:
            - '\WINWORD.EXE'
            - '\EXCEL.EXE'
            - '\POWERPNT.EXE'
            - '\OUTLOOK.EXE'

    selection_child:
        Image|endswith:
            - '\powershell.exe'
            - '\pwsh.exe'

    selection_args:
        CommandLine|contains:
            - '-enc'
            - '-EncodedCommand'
            - '-w hidden'
            - '-windowstyle hidden'
            - 'downloadstring'

    condition: selection_parent and selection_child and selection_args

¿Es esta segunda versión mejor que la primera?

No necesariamente.

Hemos incrementado la especificidad y reducido el volumen de alertas, pero a costa de introducir un grave punto ciego: si un adversario ejecuta un payload en texto claro o sin el modificador -enc, la regla no se disparará jamás.

La regla más específica puede ser adecuada como alerta de alta prioridad (P1), mientras que la versión genérica puede mantenerse como señal de media severidad para correlación.

No optimices únicamente para reducir alertas #

Supongamos que comparas dos implementaciones:

• Regla A: Produce 100 alertas semanales en el SOC.
• Regla B: Produce 2 alertas semanales en el SOC.

¿Cuál de las dos reglas es técnicamente superior?

Es imposible saberlo sin contexto operacional.

La Regla B podría ser una obra de arte en precisión quirúrgica. O podría ser un desastre analítico que silenció 98 intrusiones reales porque alguien añadió filtros agresivos para no atender avisos de guardia.

En ingeniería de detección, la métrica clave no es “menos alertas significa mejor regla”. La pregunta rigurosa es:

¿Qué actividad valiosa seguimos detectando y qué visibilidad crítica estamos perdiendo al restringir la regla?

Sigma Filters y Correlation rules modernas #

A medida que una organización madura en la gestión de sus detecciones, modificar los archivos base de Sigma para adaptar exclusiones locales se vuelve insostenible. Si descargas una actualización del repositorio de SigmaHQ y habías editado el YAML original, sobrescribirás tus cambios o tendrás conflictos en Git.

1. Sigma Filters: adaptaciones locales desacopladas

La especificación 2.1.0 define formalmente el concepto de Sigma Filters. Un filtro es un documento YAML independiente que se vincula a una regla existente (mediante su id) y declara criterios de exclusión específicos del entorno sin alterar la regla de detección original:

title: Exclude Corp Deployment Automation
id: f0a82b91-4c12-4e89-b1d3-a9d0234857b2
filter:
    rules:
        - 4dc7ab2e-f639-4da6-82f1-93467b55c85b # ID de la regla de Office
    selection:
        User: 'CORP\svc_deploy'
        CommandLine|contains: 'C:\Deploy\automation.ps1'
    condition: selection

Al compilar las detecciones mediante el pipeline, pySigma aplica el filtro sobre la regla referenciada. Esto permite actualizar el repositorio comunitario de reglas limpiamente y mantener las excepciones locales en un directorio separado.

Pero recuerda el principio analítico:

Una excepción incorrecta sigue siendo un error de seguridad aunque esté elegantemente separada en otro archivo.

2. Sigma Correlation Rules

Sigma ya no se limita a evaluar eventos individuales aislados. La especificación actual incluye un formato dedicado a reglas de correlación para modelar escenarios avanzados:

• Agrupación temporal: Detectar más de N intentos fallidos de autenticación en una ventana de 5 minutos procedentes del mismo origen.
• Diversidad de valores: Un usuario accediendo a más de 10 estaciones de trabajo diferentes en menos de 1 hora.
• Secuencias ordenadas: Evento de creación de proceso sospechoso seguido en menos de 60 segundos por una conexión de red hacia una IP externa inusual.

Esto demuestra que Sigma es un lenguaje formal de modelado de amenazas y no una mera utilidad para buscar cadenas de texto en un archivo de log.

¿Sigma sustituye a KQL, SPL o EQL? #

La respuesta contundente es no.

En el día a día operativo de un equipo de seguridad, los analistas siguen necesitando dominar en profundidad el dialecto nativo de su plataforma:

• Para depurar por qué una consulta convertida se ejecuta con excesiva lentitud en el cluster.
• Para optimizar el uso de índices y aceleradores de búsqueda.
• Para realizar investigaciones ad-hoc durante el triage de alertas o un incidente en curso.
• Para aprovechar funciones avanzadas de la plataforma (como joins complejos o llamadas a modelos de Machine Learning) que escapan a las capacidades comunes de Sigma.

Sigma abstrae la lógica compartida; no suprime la necesidad de conocimiento técnico sobre la base de datos subyacente.

Sigma y la cultura de Detection as Code #

Dado que las reglas Sigma se escriben en texto plano estructurado mediante YAML, encajan de forma natural en los flujos modernos de Detection as Code:

Una estructura de proyecto típica en una organización defensiva suele organizarse por taxonomía:

detections/
├── windows/
│   ├── process_creation/
│   │   ├── proc_creation_win_office_powershell.yml
│   │   └── proc_creation_win_powershell_cmd.yml
│   └── registry/
├── linux/
├── cloud/
└── filters/
    └── corp_exclusions.yml

Sin embargo, almacenar archivos YAML en un repositorio de Git no equivale por sí solo a implementar Detection as Code. Requiere pruebas unitarias automatizadas, control riguroso de versiones, planes de rollback y revisión por pares obligatoria antes de desplegar cualquier cambio en la consola del SOC.

Una regla Sigma válida no es necesariamente una buena regla #

Considera este ejemplo sintácticamente perfecto:

detection:
    selection:
        Image|endswith: '\powershell.exe'
    condition: selection

Cualquier compilador de Sigma la aceptará sin emitir la más mínima advertencia. Sin embargo, en un entorno de producción con 5.000 puestos de trabajo generará decenas de miles de eventos diarios por actualizaciones, scripts de inicio de sesión y telemetría de soporte técnico.

Una regla Sigma válida no es necesariamente una buena regla.

La especificación de Sigma valida la corrección estructural del archivo. El valor de la detección depende de tu comprensión del comportamiento técnico, la telemetría disponible y la tolerancia al ruido de tu equipo.

Los 9 errores habituales y checklist de revisión en 12 pasos #

Los 9 errores más frecuentes al trabajar con Sigma

1. Copiar y activar a ciegas: Descargar reglas comunitarias y encenderlas en el SIEM sin validar la presencia de la telemetría correspondiente.
2. Asumir portabilidad automática: Creer que porque el archivo sea YAML funcionará sin necesidad de adaptar pipelines de procesamiento ni esquemas de datos.
3. Añadir exclusiones destructivas: Filtrar equipos, usuarios o carpetas enteras para silenciar alertas molestas hasta anular por completo la cobertura de la regla.
4. Ignorar el bloque `logsource`: Intentar ejecutar detecciones de procesos sobre canales de auditoría que sólo recopilan inicios de sesión de Active Directory.
5. Confundir los nombres de campo de Sigma con los del SIEM: Asumir que la base de datos almacena campos idénticos a los definidos en la especificación abstracta.
6. Confiar ciegamente en la conversión: Dar por buena una regla porque el compilador terminó con código de retorno cero sin auditar la consulta generada.
7. Utilizar ATT&CK como decoración estética: Poblar la sección tags con técnicas que la lógica analítica no comprueba realmente.
8. Insertar todos los casos benignos dentro de la lógica: Llenar el bloque detection de excepciones complejas en lugar de utilizar el campo documental falsepositives o Sigma Filters.
9. Desplegar reglas sin ciclo de vida (lifecycle): No revisar periódicamente el arsenal de detección ante cambios en sistemas operativos, versiones de software o comportamiento corporativo.

Checklist de revisión técnica en 12 pasos

Cuando encuentres o redactes una regla Sigma, sigue rigurosamente este orden de auditoría antes de promoverla a producción:

De Sigma a Threat Hunting #

Supongamos que tu equipo mantiene estabilizada y en producción la regla de Office invocando PowerShell.

Durante meses, la regla opera con normalidad y sin falsos positivos.

Pero un día, durante una sesión de análisis defensivo, un ingeniero plantea una pregunta inquietante:

“¿Qué otras aplicaciones de usuario habituales están invocando intérpretes de comandos en nuestros puestos de trabajo y todavía no tenemos monitorizadas?”

En ese instante ya no estamos ejecutando una detección pasiva. No queremos crear una alerta automática inmediata porque desconocemos la tasa base de actividad en la red. Queremos explorar proactivamente los datos:

• Lectores de PDF (Acrobat, Foxit) iniciando shells o utilidades del sistema.
• Navegadores web (Chrome, Edge) creando procesos como cmd.exe, powershell.exe o cscript.exe.
• Herramientas de compresión (7-Zip, WinRAR) ejecutando binarios en carpetas temporales.

Esta disciplina proactiva de interrogación de telemetría es precisamente Threat Hunting.

El hunting formula una pregunta abierta sobre los datos, explora los eventos, delimita comportamientos desconocidos y, cuando identifica patrones consistentes de ataque, los traslada a Detection Engineering para inmortalizarlos en nuevas reglas Sigma.

Preguntas frecuentes sobre reglas Sigma #

Conclusión: de la firma abstracta a la capacidad defensiva #

Sigma resulta sumamente atractivo porque parece simplificar una de las mayores dificultades de la ingeniería de seguridad: escribir una regla una sola vez y hacerla funcionar en cualquier plataforma.

Sin embargo, la realidad de las operaciones de Blue Team es mucho más exigente.

La detección no empieza en el editor de YAML. Empieza en el conocimiento profundo del adversario:

Y una vez escrita la regla, el trabajo defensivo continúa:

Por eso, al auditar tu arsenal de detección, la pregunta relevante nunca debe ser simplemente si el archivo compila sin errores.

La pregunta crítica que define la madurez de un equipo de seguridad es:

¿Detecta realmente el comportamiento técnico que creo que detecta sobre los datos reales que tengo?

Si no puedes responder afirmativamente con evidencia empírica:

Si no puedes demostrar que detecta el comportamiento, todavía tienes YAML, no una detección terminada.