SOC

Reglas Sigma: guía práctica para escribir detecciones

Publicado David Moya
· 22 min de lectura
Tabla de Contenidos
Reglas Sigma: guía práctica para escribir detecciones

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

DominioFormato estándarQué analiza
FicherosYARAPatrones en binarios y documentos
Tráfico de redSnort/SuricataPaquetes de red
LogsSigmaEventos de logs de cualquier fuente

Por qué adoptar Sigma

  1. Portabilidad: una regla Sigma funciona en cualquier SIEM con un backend compatible.
  2. Compartibilidad: la comunidad comparte reglas en un formato común. SigmaHQ tiene más de 3.000 reglas.
  3. Versionado: al ser YAML plano, las reglas se gestionan en Git con diff, review y CI/CD.
  4. Estandarización: todos los analistas del equipo escriben detecciones en el mismo formato.
  5. 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

CampoObligatorioDescripción
titleNombre descriptivo de la regla
idUUID único (usar uuidgen para generarlo)
statusexperimental, test, stable, deprecated, unsupported
descriptionExplicación detallada del comportamiento detectado
referencesNoURLs a documentación, blog posts, técnicas ATT&CK
authorQuién escribió la regla
dateFecha de creación (formato YYYY/MM/DD)
modifiedNoFecha de última modificación
tagsEtiquetas ATT&CK y otras clasificaciones
levelinformational, low, medium, high, critical
falsepositivesEscenarios 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íaDescripciónFuentes típicas
process_creationCreación de procesosSysmon 1, Windows 4688, EDR
authenticationEventos de autenticaciónWindows 4624/4625, Linux auth.log
firewallLogs de firewallpfSense, iptables, Palo Alto
proxyLogs de proxy webSquid, Zscaler, BlueCoat
dns_queryConsultas DNSSysmon 22, Pi-hole, Zeek
network_connectionConexiones de redSysmon 3, Zeek, Suricata
file_eventOperaciones con ficherosSysmon 11, EDR
registry_eventCambios en registro WindowsSysmon 12/13/14
driver_loadCarga de driversSysmon 6
image_loadCarga de DLLsSysmon 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 |.

ModificadorDescripciónEjemplo
containsEl campo contiene el valorCommandLine|contains: 'mimikatz'
startswithEl campo empieza porImage|startswith: 'C:\Temp'
endswithEl campo termina porImage|endswith: '\powershell.exe'
reExpresión regularCommandLine|re: '.*-enc.*[A-Za-z0-9+/=]{50,}'
cidrRango de red CIDRSourceIP|cidr: '10.0.0.0/8'
allTodos los valores deben coincidir (AND)CommandLine|contains|all: ['net', 'user', '/add']
base64Busca valor codificado en base64CommandLine|base64: 'IEX'
base64offsetBusca con offset de base64CommandLine|base64offset: 'IEX'
windashCoincide con - y / en argumentos WindowsCommandLine|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 SOC

Integració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:

  1. Identifica técnicas ATT&CK sin cobertura en tu entorno.
  2. Busca reglas en SigmaHQ para esas técnicas.
  3. Evalúa si las fuentes de datos necesarias están disponibles.
  4. Adapta las reglas a tu entorno (exclusiones, umbrales).
  5. 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:

StatusDescripciónRecomendación
stableTesteada y validada en múltiples entornosDesplegar directamente
testFuncional pero necesita más validaciónDesplegar en staging primero
experimentalNueva, puede generar falsos positivosSolo para hunting o lab
deprecatedReemplazada por otra reglaNo usar
unsupportedYa no se mantieneNo 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:

  1. 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).
  2. Ajustar exclusiones: las exclusiones de SigmaHQ son genéricas. Necesitas añadir las específicas de tu entorno.
  3. Calibrar niveles de severidad: lo que es high en un entorno puede ser medium en otro según el contexto de negocio.
  4. 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 demo

Artí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.

Hacer diagnóstico

Posts Relacionados

Respuesta a incidentes de seguridad
· 21 min

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.

SOC Operaciones Seguridad
Compartir