Tabla de Contenidos

Guía completa de reglas Sigma para SOC y SIEM: sintaxis, ejemplos prácticos, conversión a SIEM, integración con MITRE ATT&CK y mejores prácticas para escribir detecciones portables.
Puntos clave
- Sigma es el formato estándar abierto para escribir reglas de detección portables entre cualquier SIEM (Splunk, Elastic, Sentinel, Wazuh, etc.).
- La sintaxis YAML de Sigma permite definir detecciones con condiciones booleanas, modificadores de campo y correlación temporal.
- El repositorio SigmaHQ contiene más de 3.000 reglas mantenidas por la comunidad, listas para convertir y desplegar.
- sigma-cli permite convertir reglas a SPL, KQL, Lucene y otros lenguajes de consulta de SIEM con un solo comando.
- Escribir reglas Sigma propias es la forma más eficiente de construir un programa de detection engineering portable y mantenible.
¿Qué son las reglas Sigma?
Sigma es un formato genérico y abierto para escribir reglas de detección de seguridad. Su propósito es resolver un problema fundamental: cada SIEM tiene su propio lenguaje de consulta (SPL en Splunk, KQL en Elastic/Sentinel, SQL en Graylog) y escribir detecciones directamente en el lenguaje del SIEM te ata a ese producto.
Sigma funciona como un intermediario. Escribes la regla una vez en formato YAML y luego la conviertes al lenguaje de consulta de tu SIEM. Si cambias de SIEM, no reescribes las reglas: solo cambias el backend de conversión.
El proyecto fue creado en 2017 por Florian Roth y Thomas Patzke, inspirado en lo que Snort/YARA hacen para detección en red y ficheros respectivamente. Si YARA es para ficheros y Snort es para paquetes de red, Sigma es para logs.
La analogía YARA/Snort/Sigma
| Dominio | Formato estándar | Qué analiza |
|---|---|---|
| Ficheros | YARA | Patrones en binarios y documentos |
| Tráfico de red | Snort/Suricata | Paquetes de red |
| Logs | Sigma | Eventos de logs de cualquier fuente |
Por qué adoptar Sigma
- Portabilidad: una regla Sigma funciona en cualquier SIEM con un backend compatible.
- Compartibilidad: la comunidad comparte reglas en un formato común. SigmaHQ tiene más de 3.000 reglas.
- Versionado: al ser YAML plano, las reglas se gestionan en Git con diff, review y CI/CD.
- Estandarización: todos los analistas del equipo escriben detecciones en el mismo formato.
- Independencia de vendor: no estás atado al SIEM que uses hoy.
Anatomía de una regla Sigma
Cada regla Sigma es un fichero YAML con una estructura definida. Vamos a desglosar cada campo.
Estructura básica
title: Detección de Brute Force por RDP
image: "cover.png"
id: a]1b2c3d4-e5f6-7890-abcd-ef1234567890
status: test
description: >
Detecta múltiples intentos fallidos de autenticación RDP
desde una misma IP en un periodo corto de tiempo.
references:
- https://attack.mitre.org/techniques/T1110/001/
author: SOC Team - Riskitera
date: 2026/05/01
modified: 2026/05/15
tags:
- attack.credential_access
- attack.t1110.001
logsource:
category: authentication
product: windows
detection:
selection:
EventID: 4625
LogonType: 10 # RemoteInteractive (RDP)
timeframe: 5m
condition: selection | count(TargetUserName) by SourceNetworkAddress > 10
falsepositives:
- Usuarios con problemas de credenciales
- Escaneos de vulnerabilidades autorizados
level: high
Campos de metadatos
| Campo | Obligatorio | Descripción |
|---|---|---|
title | Sí | Nombre descriptivo de la regla |
id | Sí | UUID único (usar uuidgen para generarlo) |
status | Sí | experimental, test, stable, deprecated, unsupported |
description | Sí | Explicación detallada del comportamiento detectado |
references | No | URLs a documentación, blog posts, técnicas ATT&CK |
author | Sí | Quién escribió la regla |
date | Sí | Fecha de creación (formato YYYY/MM/DD) |
modified | No | Fecha de última modificación |
tags | Sí | Etiquetas ATT&CK y otras clasificaciones |
level | Sí | informational, low, medium, high, critical |
falsepositives | Sí | Escenarios conocidos de falsos positivos |
El bloque logsource
El logsource define de dónde vienen los logs que analiza la regla. Es lo que hace a Sigma portable: en lugar de referenciar un índice específico de Elastic o un sourcetype de Splunk, defines la fuente de forma abstracta.
# Logs de procesos en Windows
logsource:
category: process_creation
product: windows
# Logs de firewall (cualquier vendor)
logsource:
category: firewall
# Logs de proxy web
logsource:
category: proxy
# Sysmon específico
logsource:
product: windows
service: sysmon
category: process_creation
# Logs de Active Directory
logsource:
product: windows
service: security
# Logs de Linux auditd
logsource:
product: linux
service: auditd
Las categorías más comunes:
| Categoría | Descripción | Fuentes típicas |
|---|---|---|
process_creation | Creación de procesos | Sysmon 1, Windows 4688, EDR |
authentication | Eventos de autenticación | Windows 4624/4625, Linux auth.log |
firewall | Logs de firewall | pfSense, iptables, Palo Alto |
proxy | Logs de proxy web | Squid, Zscaler, BlueCoat |
dns_query | Consultas DNS | Sysmon 22, Pi-hole, Zeek |
network_connection | Conexiones de red | Sysmon 3, Zeek, Suricata |
file_event | Operaciones con ficheros | Sysmon 11, EDR |
registry_event | Cambios en registro Windows | Sysmon 12/13/14 |
driver_load | Carga de drivers | Sysmon 6 |
image_load | Carga de DLLs | Sysmon 7 |
El bloque detection
El bloque detection es el corazón de la regla. Define las condiciones que deben cumplirse para que la regla dispare.
Selecciones simples
detection:
selection:
EventID: 4625
LogonType: 10
condition: selection
Esto equivale a: EventID = 4625 AND LogonType = 10.
Múltiples valores (OR implícito)
detection:
selection:
EventID:
- 4624
- 4625
- 4648
condition: selection
Equivale a: EventID IN (4624, 4625, 4648).
Múltiples selecciones con operadores booleanos
detection:
selection_process:
ParentImage|endswith: '\cmd.exe'
selection_command:
CommandLine|contains:
- 'whoami'
- 'net user'
- 'net group'
filter_legitimate:
User|endswith: '$' # Cuentas de máquina
condition: selection_process and selection_command and not filter_legitimate
Modificadores de campo
Los modificadores de campo son una de las funcionalidades más potentes de Sigma. Se aplican al nombre del campo con el operador |.
| Modificador | Descripción | Ejemplo |
|---|---|---|
contains | El campo contiene el valor | CommandLine|contains: 'mimikatz' |
startswith | El campo empieza por | Image|startswith: 'C:\Temp' |
endswith | El campo termina por | Image|endswith: '\powershell.exe' |
re | Expresión regular | CommandLine|re: '.*-enc.*[A-Za-z0-9+/=]{50,}' |
cidr | Rango de red CIDR | SourceIP|cidr: '10.0.0.0/8' |
all | Todos los valores deben coincidir (AND) | CommandLine|contains|all: ['net', 'user', '/add'] |
base64 | Busca valor codificado en base64 | CommandLine|base64: 'IEX' |
base64offset | Busca con offset de base64 | CommandLine|base64offset: 'IEX' |
windash | Coincide con - y / en argumentos Windows | CommandLine|windash|contains: '-enc' |
Condiciones de agregación
Sigma soporta funciones de agregación para detecciones basadas en umbrales:
detection:
selection:
EventID: 4625
timeframe: 10m
condition: selection | count() by SourceIP > 20
Funciones disponibles: count(), min(), max(), avg(), sum(), near.
Ejemplos completos de reglas Sigma
Ejemplo 1: Detección de brute force SSH
title: SSH Brute Force Attempt
image: "cover.png"
id: 5c2a8e1d-9f3b-4a7c-b6d2-e8f1234abcde
status: stable
description: >
Detecta múltiples intentos fallidos de autenticación SSH
desde una misma IP de origen, indicativo de un ataque
de fuerza bruta contra el servicio SSH.
references:
- https://attack.mitre.org/techniques/T1110/001/
- https://www.sshaudit.com/
author: SOC Team
date: 2026/04/10
modified: 2026/05/20
tags:
- attack.credential_access
- attack.t1110.001
- attack.t1110.003
logsource:
product: linux
service: sshd
detection:
selection:
sshd_result: 'Failed'
timeframe: 5m
condition: selection | count() by src_ip > 15
falsepositives:
- Usuarios legítimos que olvidan la contraseña
- Conexiones automatizadas con credenciales caducadas
- Herramientas de escaneo de compliance
level: medium
Ejemplo 2: Movimiento lateral vía WMI
title: Remote WMI Command Execution
image: "cover.png"
id: 7a9b3c4d-2e1f-5678-90ab-cdef12345678
status: stable
description: >
Detecta la ejecución remota de comandos a través de WMI
(Windows Management Instrumentation), técnica común de
movimiento lateral usada por atacantes y herramientas
como Impacket wmiexec.
references:
- https://attack.mitre.org/techniques/T1047/
- https://github.com/fortra/impacket
author: SOC Team
date: 2026/04/15
modified: 2026/05/25
tags:
- attack.lateral_movement
- attack.execution
- attack.t1047
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith: '\WmiPrvSE.exe'
selection_suspicious_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\mshta.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\rundll32.exe'
- '\regsvr32.exe'
filter_legitimate:
CommandLine|contains:
- 'Windows\CCM' # SCCM
- 'Windows\ccmsetup' # SCCM setup
condition: selection_parent and selection_suspicious_child and not filter_legitimate
falsepositives:
- Administradores IT usando WMI para gestión remota
- SCCM y otras herramientas de gestión de endpoints
- Scripts de inventario y monitoreo
level: high
Ejemplo 3: Persistencia vía tarea programada
title: Scheduled Task Creation for Persistence
image: "cover.png"
id: 3b5c7d9e-1a2f-4e6g-8h0i-jklm12345678
status: stable
description: >
Detecta la creación de tareas programadas que apuntan
a ejecutables en ubicaciones sospechosas, técnica
frecuente de persistencia usada por malware y atacantes.
references:
- https://attack.mitre.org/techniques/T1053/005/
author: SOC Team
date: 2026/05/01
modified: 2026/05/28
tags:
- attack.persistence
- attack.execution
- attack.t1053.005
logsource:
product: windows
service: security
detection:
selection_event:
EventID: 4698 # A scheduled task was created
selection_suspicious_path:
TaskContent|contains:
- '\AppData\Local\Temp\'
- '\AppData\Roaming\'
- '\Users\Public\'
- '\ProgramData\'
- '\Windows\Temp\'
- 'C:\Temp\'
filter_known_tools:
TaskContent|contains:
- 'GoogleUpdate'
- 'MicrosoftEdgeUpdate'
- 'OneDrive'
condition: selection_event and selection_suspicious_path and not filter_known_tools
falsepositives:
- Software legítimo que instala tareas programadas en rutas de usuario
- Herramientas de IT que usan tareas programadas para mantenimiento
level: high
Ejemplo 4: Exfiltración vía DNS tunneling
title: Possible DNS Tunneling vía Long Subdomain Queries
image: "cover.png"
id: 9e8d7c6b-5a4f-3210-fedc-ba9876543210
status: test
description: >
Detecta consultas DNS con subdominios anormalmente largos,
indicativo de DNS tunneling donde se codifican datos en
las consultas DNS para exfiltrarlos sin pasar por controles
de proxy o firewall.
references:
- https://attack.mitre.org/techniques/T1048/
- https://attack.mitre.org/techniques/T1071/004/
- https://www.sans.org/white-papers/dns-tunneling/
author: SOC Team
date: 2026/05/10
tags:
- attack.exfiltration
- attack.t1048
- attack.command_and_control
- attack.t1071.004
logsource:
category: dns_query
detection:
selection:
query|re: '^[a-zA-Z0-9]{30,}\.[a-zA-Z0-9]{10,}\.'
filter_cdn:
query|endswith:
- '.amazonaws.com'
- '.cloudfront.net'
- '.akamaiedge.net'
- '.googleusercontent.com'
filter_internal:
query|endswith:
- '.internal.corp'
- '.ad.company.local'
condition: selection and not filter_cdn and not filter_internal
falsepositives:
- Servicios cloud con subdominios largos generados automáticamente
- Certificados de seguridad con hashes en subdominios
- Servicios de CDN con identificadores largos
level: medium
Convertir reglas Sigma a tu SIEM con sigma-cli
sigma-cli es la herramienta oficial de línea de comandos para convertir reglas Sigma al lenguaje de consulta de tu SIEM. Reemplazo al antiguo sigmac a partir de Sigma v2.
Instalación
# Instalar sigma-cli vía pip
pip install sigma-cli
# Instalar backends (plugins) para tu SIEM
pip install pySigma-backend-splunk
pip install pySigma-backend-elasticsearch
pip install pySigma-backend-microsoft365defender
pip install pySigma-backend-kusto # Microsoft Sentinel
# Instalar pipelines de procesamiento
pip install pySigma-pipeline-sysmon
pip install pySigma-pipeline-windows
# Verificar instalación
sigma version
sigma list backends
sigma list pipelines
Conversión básica
# Convertir una regla a Splunk SPL
sigma convert -t splunk -p sysmon rules/brute_force_ssh.yml
# Convertir a Elastic/Lucene
sigma convert -t elasticsearch -p ecs_windows rules/wmi_lateral.yml
# Convertir a Microsoft Sentinel KQL
sigma convert -t kusto -p microsoft365defender rules/scheduled_task.yml
# Convertir un directorio completo
sigma convert -t splunk -p sysmon rules/ -o output/splunk/
# Convertir con formato de output específico
sigma convert -t splunk -p sysmon --format savedsearches rules/
Ejemplo de conversión: regla de brute force a SPL
Regla Sigma de entrada:
title: Windows Logon Brute Force
image: "cover.png"
logsource:
product: windows
service: security
detection:
selection:
EventID: 4625
timeframe: 5m
condition: selection | count() by SourceNetworkAddress > 10
level: high
Salida SPL (Splunk):
source="WinEventLog:Security" EventCode=4625
| bucket span=5m _time
| stats count by SourceNetworkAddress, _time
| where count > 10
Ejemplo de conversión: regla de WMI a KQL (Elastic)
Salida KQL (Elastic):
process.parent.executable:*\\WmiPrvSE.exe AND
process.executable:(*\\cmd.exe OR *\\powershell.exe OR *\\pwsh.exe
OR *\\mshta.exe OR *\\wscript.exe OR *\\cscript.exe
OR *\\rundll32.exe OR *\\regsvr32.exe) AND
NOT process.command_line:(*Windows\\CCM* OR *Windows\\ccmsetup*)
Ejemplo de conversión: regla a KQL (Microsoft Sentinel)
SecurityEvent
| where EventID == 4698
| where TaskContent has_any (
"\\AppData\\Local\\Temp\\",
"\\AppData\\Roaming\\",
"\\Users\\Public\\",
"\\ProgramData\\",
"\\Windows\\Temp\\",
"C:\\Temp\\"
)
| where TaskContent !has "GoogleUpdate"
and TaskContent !has "MicrosoftEdgeUpdate"
and TaskContent !has "OneDrive"
Pipelines de procesamiento
Los pipelines de procesamiento transforman los nombres de campo genéricos de Sigma a los nombres específicos de tu SIEM. Sin un pipeline adecuado, la conversión puede generar nombres de campo que tu SIEM no reconoce.
# Ver pipelines disponibles
sigma list pipelines
# Pipelines comunes:
# - sysmon: mapea campos de Sysmon
# - ecs_windows: mapea a Elastic Common Schema
# - splunk_windows: mapea a campos de Splunk para Windows
# - microsoft365defender: mapea a campos de M365 Defender
# Usar múltiples pipelines
sigma convert -t elasticsearch -p ecs_windows -p sysmon rules/
Crear un pipeline custom
Si tu SIEM usa nombres de campo personalizados, puedes crear un pipeline de procesamiento propio:
# custom_pipeline.yml
name: Custom Field Mapping
priority: 50
transformations:
- id: custom_field_mapping
type: field_name_mapping
mapping:
Image: process.executable.path
ParentImage: process.parent.executable.path
CommandLine: process.command_line
User: user.name
SourceIP: source.ip
DestinationIP: destination.ip
DestinationPort: destination.port
# Usar pipeline custom
sigma convert -t elasticsearch -p custom_pipeline.yml rules/
Riskitera automatiza el triage, la correlación y el reporting de tu SOC con IA soberana. Compatible con cualquier SIEM.
Ver demo SOCIntegración con MITRE ATT&CK
Una de las ventajas de Sigma es su integración nativa con MITRE ATT&CK. Cada regla puede (y debería) estar etiquetada con las tácticas y técnicas ATT&CK correspondientes.
Convenciones de etiquetado
Las etiquetas ATT&CK en Sigma siguen un formato estándar:
tags:
- attack.táctica # Nombre de la táctica en minúsculas
- attack.tXXXX # ID de la técnica
- attack.tXXXX.YYY # ID de la sub-técnica
Ejemplos:
tags:
- attack.credential_access
- attack.t1110 # Brute Force
- attack.t1110.001 # Password Guessing
- attack.t1110.003 # Password Spraying
Mapear cobertura de reglas Sigma a ATT&CK
Puedes generar una matriz de cobertura automáticamente a partir de tus reglas Sigma:
# sigma_coverage.py
import yaml
import glob
from collections import defaultdict
def extract_attack_tags(rules_path):
"""Extrae tags ATT&CK de todas las reglas Sigma."""
coverage = defaultdict(list)
for rule_file in glob.glob(f"{rules_path}/**/*.yml", recursive=True):
with open(rule_file) as f:
rule = yaml.safe_load(f)
tags = rule.get("tags", [])
title = rule.get("title", "Unknown")
status = rule.get("status", "unknown")
for tag in tags:
if tag.startswith("attack.t"):
technique_id = tag.replace("attack.", "").upper()
coverage[technique_id].append({
"title": title,
"status": status,
"file": rule_file
})
return coverage
def print_coverage_report(coverage):
"""Imprime un resumen de cobertura."""
print(f"\nCobertura ATT&CK: {len(coverage)} técnicas cubiertas\n")
for technique, rules in sorted(coverage.items()):
stable = sum(1 for r in rules if r["status"] == "stable")
test = sum(1 for r in rules if r["status"] == "test")
print(f" {technique}: {len(rules)} regla(s) "
f"({stable} stable, {test} test)")
if __name__ == "__main__":
coverage = extract_attack_tags("rules/")
print_coverage_report(coverage)
python sigma_coverage.py
# Output:
# Cobertura ATT&CK: 47 técnicas cubiertas
#
# T1047: 2 regla(s) (1 stable, 1 test)
# T1053.005: 3 regla(s) (2 stable, 1 test)
# T1059.001: 5 regla(s) (3 stable, 2 test)
# T1110.001: 2 regla(s) (2 stable, 0 test)
# ...
Usar SigmaHQ para cerrar gaps de cobertura
El repositorio SigmaHQ es la mayor colección pública de reglas Sigma. Para cerrar gaps en tu cobertura:
- Identifica técnicas ATT&CK sin cobertura en tu entorno.
- Busca reglas en SigmaHQ para esas técnicas.
- Evalúa si las fuentes de datos necesarias están disponibles.
- Adapta las reglas a tu entorno (exclusiones, umbrales).
- Despliega siguiendo tu proceso de CI/CD.
# Buscar reglas de SigmaHQ para una técnica específica
find sigma/rules/ -name "*.yml" -exec grep -l "t1059.001" {} \;
# O usando sigma-cli
sigma list rules --tag attack.t1059.001
El repositorio SigmaHQ
SigmaHQ es el repositorio oficial y centralizado de reglas Sigma mantenido por la comunidad. Es el equivalente a lo que las reglas de Snort son para la detección de intrusiones en red.
Estructura del repositorio
sigma/
├── rules/
│ ├── windows/
│ │ ├── builtin/ # Reglas basadas en logs nativos de Windows
│ │ │ ├── security/
│ │ │ ├── system/
│ │ │ └── application/
│ │ ├── create_remote_thread/
│ │ ├── dns_query/
│ │ ├── driver_load/
│ │ ├── file/
│ │ ├── image_load/
│ │ ├── network_connection/
│ │ ├── pipe_created/
│ │ ├── process_creation/ # La categoría con más reglas
│ │ ├── ps_script/
│ │ └── registry/
│ ├── linux/
│ │ ├── auditd/
│ │ ├── process_creation/
│ │ └── ...
│ ├── macos/
│ ├── cloud/
│ │ ├── aws/
│ │ ├── azure/
│ │ ├── gcp/
│ │ └── m365/
│ ├── network/
│ │ ├── dns/
│ │ ├── firewall/
│ │ └── proxy/
│ └── application/
│ ├── antivirus/
│ └── ...
├── rules-emerging-threats/ # Reglas para amenazas activas
├── rules-threat-hunting/ # Reglas más amplias para hunting
├── rules-compliance/ # Reglas orientadas a compliance
└── pipelines/ # Pipelines de procesamiento
Niveles de status en SigmaHQ
Las reglas en SigmaHQ tienen un status que indica su madurez:
| Status | Descripción | Recomendación |
|---|---|---|
stable | Testeada y validada en múltiples entornos | Desplegar directamente |
test | Funcional pero necesita más validación | Desplegar en staging primero |
experimental | Nueva, puede generar falsos positivos | Solo para hunting o lab |
deprecated | Reemplazada por otra regla | No usar |
unsupported | Ya no se mantiene | No usar |
Curar reglas de SigmaHQ para tu entorno
No todas las reglas de SigmaHQ funcionan directamente en tu entorno. El proceso de curación incluye:
- Filtrar por fuentes de datos disponibles: si no tienes Sysmon desplegado, las reglas que dependen de Sysmon no te sirven (a menos que tengas un EDR equivalente).
- Ajustar exclusiones: las exclusiones de SigmaHQ son genéricas. Necesitas añadir las específicas de tu entorno.
- Calibrar niveles de severidad: lo que es
highen un entorno puede sermediumen otro según el contexto de negocio. - Validar contra logs históricos: ejecutar la regla contra 7-30 días de logs para entender la tasa de falsos positivos esperada.
Escribir reglas Sigma propias
Las reglas de SigmaHQ cubren muchos escenarios comunes, pero cada organización tiene necesidades específicas que requieren reglas propias.
Proceso de desarrollo
Paso 1: Definir la hipótesis de detección
Documenta qué comportamiento quieres detectar, por qué es malicioso y qué técnica ATT&CK mapea.
Paso 2: Identificar la fuente de datos
Determina qué logs contienen la evidencia del comportamiento. Verifica que esos logs están disponibles y con la calidad necesaria.
Paso 3: Investigar el comportamiento normal
Antes de escribir la regla, entiende cómo se ve la actividad normal. Ejecuta queries exploratorias contra logs históricos.
Paso 4: Escribir la regla
title: Descarga de herramienta de hacking desde GitHub
image: "cover.png"
id: nuevo-uuid-generado
status: test
description: >
Detecta el uso de curl, wget o Invoke-WebRequest para
descargar herramientas de hacking conocidas desde GitHub
o repositorios públicos.
references:
- https://attack.mitre.org/techniques/T1105/
author: Tu Nombre - Tu Organización
date: 2026/06/01
tags:
- attack.command_and_control
- attack.t1105
logsource:
category: process_creation
product: windows
detection:
selection_tool:
Image|endswith:
- '\curl.exe'
- '\wget.exe'
- '\powershell.exe'
- '\pwsh.exe'
selection_url:
CommandLine|contains:
- 'github.com'
- 'raw.githubusercontent.com'
selection_hacking_tool:
CommandLine|contains:
- 'mimikatz'
- 'rubeus'
- 'SharpHound'
- 'Certify'
- 'Seatbelt'
- 'winPEAS'
- 'LaZagne'
- 'BloodHound'
- 'Covenant'
- 'Sliver'
condition: selection_tool and selection_url and selection_hacking_tool
falsepositives:
- Red team autorizado descargando herramientas
- Investigadores de seguridad analizando malware
level: high
Paso 5: Validar la regla
# Verificar que la sintaxis es correcta
sigma check rules/custom/download_hacking_tool.yml
# Convertir a tu SIEM para verificar la query generada
sigma convert -t splunk -p sysmon rules/custom/download_hacking_tool.yml
# Ejecutar contra logs históricos (ejemplo Splunk)
# source="XmlWinEventLog:Microsoft-Windows-Sysmon/Operational" EventCode=1
# (Image="*\\curl.exe" OR Image="*\\wget.exe" OR ...)
# AND (CommandLine="*github.com*" OR CommandLine="*raw.githubusercontent.com*")
# AND (CommandLine="*mimikatz*" OR CommandLine="*rubeus*" OR ...)
Paso 6: Desplegar y monitorizar
Despliega en staging con status test. Monitoriza durante 1-2 semanas. Ajusta exclusiones según los falsos positivos observados. Cuando la tasa de falsos positivos sea aceptable (< 20%), cambia a status stable y promueve a producción.
Errores comunes al escribir reglas
1. Reglas demasiado amplias
# MAL: detecta cualquier ejecución de PowerShell
detection:
selection:
Image|endswith: '\powershell.exe'
condition: selection
# Resultado: miles de alertas diarias
# BIEN: detecta PowerShell con comportamiento sospechoso específico
detection:
selection_process:
Image|endswith: '\powershell.exe'
selection_suspicious:
CommandLine|contains|all:
- '-EncodedCommand'
- '-WindowStyle Hidden'
condition: selection_process and selection_suspicious
2. Reglas demasiado estrechas
# MAL: solo detecta un hash específico de mimikatz
detection:
selection:
Hashes|contains: 'SHA256=abc123...'
condition: selection
# Resultado: solo detecta una versión específica
# BIEN: detecta el comportamiento, no el artefacto
detection:
selection:
TargetFilename|contains: 'mimikatz'
selection_alt:
CommandLine|contains:
- 'sekurlsa::logonpasswords'
- 'lsadump::sam'
- 'kerberos::golden'
condition: selection or selection_alt
3. Omitir falsos positivos conocidos
Siempre documenta escenarios de falsos positivos, incluso si no tienes exclusiones implementadas todavía. Ayuda a otros analistas a entender por que pueden ver falsos positivos y a decidir si una alerta requiere investigación.
4. No usar modificadores apropiados
# MAL: búsqueda exacta que falla con variaciones de ruta
detection:
selection:
Image: 'C:\Windows\System32\cmd.exe'
condition: selection
# BIEN: usar endswith para ser resiliente a variaciones
detection:
selection:
Image|endswith: '\cmd.exe'
condition: selection
Metodología de testing para reglas Sigma
Testear reglas Sigma es crítico para garantizar que funcionan como se espera antes de llegar a producción.
Testing en tres niveles
Nivel 1: Validación de sintaxis
# sigma check válida la estructura YAML y los campos obligatorios
sigma check rules/custom/my_rule.yml
# Verificar que la conversión no produce errores
sigma convert -t splunk rules/custom/my_rule.yml > /dev/null
Nivel 2: Testing con logs sintéticos
Crea logs de ejemplo que representen tanto el comportamiento malicioso como el normal, y verifica que la regla produce los resultados esperados.
# test_data/wmi_lateral_positive.json
# Debe disparar la regla
{
"EventID": 1,
"ParentImage": "C:\\Windows\\System32\\wbem\\WmiPrvSE.exe",
"Image": "C:\\Windows\\System32\\cmd.exe",
"CommandLine": "cmd.exe /c whoami",
"User": "DOMAIN\\admin_user"
}
# test_data/wmi_lateral_negative.json
# NO debe disparar la regla (SCCM legítimo)
{
"EventID": 1,
"ParentImage": "C:\\Windows\\System32\\wbem\\WmiPrvSE.exe",
"Image": "C:\\Windows\\System32\\cmd.exe",
"CommandLine": "cmd.exe /c C:\\Windows\\CCM\\ccmsetup.exe",
"User": "SYSTEM"
}
Nivel 3: Testing con simulación de ataque
Usar Atomic Red Team o herramientas equivalentes para ejecutar la técnica real en un entorno de laboratorio y verificar que la regla la detecta.
# Ejecutar simulación de WMI lateral movement
Invoke-AtomicTest T1047 -TestNumbers 1
# Esperar a que los logs se procesen (2-5 minutos)
# Ejecutar la regla convertida en el SIEM de test
# Verificar que se generó la alerta esperada
Automatizar el testing en CI/CD
# .github/workflows/sigma-ci.yml
name: Sigma Rules CI
on:
pull_request:
paths: ['rules/**']
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Python
uses: actions/setup-python@v5
with:
python-version: '3.11'
- name: Install sigma-cli
run: |
pip install sigma-cli
pip install pySigma-backend-splunk
pip install pySigma-backend-elasticsearch
- name: Check Sigma syntax
run: sigma check rules/
- name: Convert to Splunk (validate)
run: sigma convert -t splunk rules/ > /dev/null
- name: Convert to Elastic (validate)
run: sigma convert -t elasticsearch rules/ > /dev/null
- name: Check mandatory fields
run: |
python scripts/check_mandatory_fields.py rules/
# Verifica: title, id, status, description, author,
# date, tags, logsource, detection, falsepositives, level
- name: Check ATT&CK tags
run: |
python scripts/check_attack_tags.py rules/
# Verifica que cada regla tiene al menos un tag ATT&CK
Mejores prácticas para reglas Sigma
1. Una regla, un comportamiento
Cada regla debe detectar un comportamiento específico. No intentes detectar múltiples técnicas en una sola regla.
2. Siempre incluir un UUID
El campo id debe ser un UUID único generado con uuidgen. Esto permite rastrear la regla a través de sistemas y evitar duplicados.
3. Tags ATT&CK obligatorios
Cada regla debe tener al menos un tag de táctica y técnica ATT&CK. Esto facilita medir la cobertura.
4. Documentar falsos positivos
El campo falsepositives no es opcional. Incluso si no conoces falsos positivos, documenta “Unknown” en lugar de omitirlo.
5. Usar modificadores en lugar de expresiones regulares
Los modificadores (contains, startswith, endswith) son más legibles y más fáciles de convertir que las expresiones regulares. Reserva re para casos donde los modificadores no son suficientes.
6. Organizar por táctica ATT&CK
Estructura el directorio de reglas siguiendo las tácticas ATT&CK:
rules/
├── initial_access/
├── execution/
├── persistence/
├── privilege_escalation/
├── defense_evasion/
├── credential_access/
├── discovery/
├── lateral_movement/
├── collection/
├── exfiltration/
└── command_and_control/
7. Revisar y actualizar regularmente
Las reglas no son estáticas. Programa revisiones trimestrales para:
- Verificar que las reglas siguen siendo relevantes.
- Ajustar exclusiones según cambios en el entorno.
- Actualizar referencias y mapeos ATT&CK.
- Eliminar reglas obsoletas (status
deprecated).
8. Naming convention consistente
# Formato: {tactica}_{tecnica_corta}_{variante}.yml
credential_access_kerberoasting_rc4.yml
lateral_movement_psexec_service.yml
persistence_scheduled_task_temp_folder.yml
defense_evasion_process_injection_createremotethread.yml
Limitaciones de Sigma
Sigma es una herramienta poderosa, pero tiene limitaciones que debes conocer:
1. No todos los SIEM son iguales
La conversión no siempre es perfecta. Algunos SIEM no soportan todas las funcionalidades de Sigma (especialmente agregaciones complejas y correlación temporal). Siempre verifica la query generada.
2. Dependencia del backend
La calidad de la conversión depende del backend (plugin) de tu SIEM. Algunos backends están más maduros que otros. Splunk y Elastic tienen los backends más completos.
3. Campos no estandarizados
Sigma define nombres de campo genéricos, pero no todos los proveedores de logs usan los mismos nombres. Los pipelines de procesamiento mitigan esto, pero requieren mantenimiento.
4. Agregaciones limitadas
Las funciones de agregación de Sigma son básicas comparadas con lo que ofrecen los lenguajes nativos de los SIEM. Para detecciones que requieren correlación compleja, estadísticas avanzadas o machine learning, necesitarás escribir queries nativas.
5. No reemplaza el conocimiento del analista
Sigma facilita escribir y compartir detecciones, pero no sustituye el conocimiento de un analista experimentado que entiende el entorno, las amenazas relevantes y el contexto de negocio.
6. Correlación entre fuentes de datos
Sigma opera sobre una fuente de datos a la vez. Si necesitas correlacionar eventos de múltiples fuentes (por ejemplo, un login exitoso seguido de una ejecución de proceso en otro sistema), necesitas herramientas complementarias o reglas nativas del SIEM.
Solicita una demo personalizada para tu SOC y descubre cómo Riskitera integra detecciones Sigma con IA soberana para priorizar alertas.
Solicitar demoArtículos relacionados:
Preguntas que surgen en la práctica
¿Sigma reemplaza las reglas nativas de mi SIEM?
No. Sigma complementa las reglas nativas, no las reemplaza. Para detecciones estándar que se benefician de portabilidad (brute force, movimiento lateral, persistencia común), Sigma es ideal. Para detecciones que requieren funcionalidades específicas de tu SIEM (machine learning, correlación compleja entre múltiples fuentes, queries de rendimiento optimizado), seguirás necesitando reglas nativas. El enfoque recomendado es usar Sigma para el 70-80% de tus detecciones y reglas nativas para el 20-30% restante.
¿Cuántas reglas de SigmaHQ debería desplegar?
No despliegues todas las 3.000+ reglas de golpe. Empieza con las reglas marcadas como stable que cubren las tácticas más críticas para tu entorno (initial access, execution, persistence, credential access). Un buen punto de partida son 50-100 reglas cuidadosamente seleccionadas y validadas. Después, expande gradualmente basándote en los gaps de cobertura ATT&CK y la threat intelligence relevante para tu sector.
¿Qué SIEM tiene mejor soporte para Sigma?
Splunk y Elastic Security son los SIEM con los backends de conversión más maduros y mejor mantenidos. Microsoft Sentinel también tiene buen soporte vía el backend Kusto. Wazuh, Graylog y QRadar tienen backends funcionales pero con algunas limitaciones en funcionalidades avanzadas. Si usas un SIEM menos común, verifica la lista de backends disponibles en el repositorio de pySigma antes de invertir tiempo en adoptar Sigma.
¿Puedo contribuir reglas a SigmaHQ?
Sí. SigmaHQ acepta contribuciones vía pull request en GitHub. Tu regla debe cumplir los estándares de calidad del proyecto: campos obligatorios completos, tags ATT&CK correctos, falsos positivos documentados, y status apropiado (normalmente test o experimental para reglas nuevas). Antes de contribuir, revisa las guías de contribución y busca si ya existe una regla similar.
¿Cómo integro Sigma con mi pipeline de detection-as-code?
La integración típica es: (1) almacena tus reglas Sigma en un repositorio Git, (2) configura un pipeline de CI que ejecute sigma check y sigma convert para validar las reglas en cada pull request, (3) cuando se aprueba y mergea el PR, un pipeline de CD convierte las reglas al formato de tu SIEM y las despliega automáticamente, (4) monitoriza las métricas de las reglas desplegadas (volumen de alertas, tasa de falsos positivos) y retroalimenta el proceso. Herramientas como GitHub Actions o GitLab CI son suficientes para montar este pipeline sin infraestructura adicional.
¿Conoces tu nivel de madurez en ciberseguridad?
Diagnóstico gratuito en 3 minutos. Score personalizado, mapa de brechas y plan de acción adaptado a tu sector.
Posts Relacionados

Feeds de CTI gratuitos: los 15 mejores y cómo integrarlos
Los 15 mejores feeds de threat intelligence gratuitos en 2026: MISP, AlienVault OTX, Abuse.ch, CIRCL y más. Como integrarlos en tu SIEM y maximizar su valor.

Respuesta a incidentes de seguridad
Playbook completo de respuesta a incidentes para SOC: fases NIST, roles, comunicación, contención, erradicación, recuperación y lecciones aprendidas con.

Cómo montar y operar un SOC en 2026: guía definitiva
Guía definitiva para montar y operar un SOC en 2026: modelos organizativos, equipo, herramientas, procesos, métricas, automatización con IA y costes reales.