Parte: 8 — Blue Team, detección y SOC · Fuente: The Sigma Specification — proyecto SigmaHQ ⏱️ Duración estimada: 110 min · Nivel: Intermedio
Escribir reglas de detección portables en Sigma, el "YAML de las detecciones": un formato genérico que se convierte a la consulta nativa de cualquier SIEM (Splunk, Elastic, QRadar, etc.). Aprenderás la estructura de una regla, sus operadores lógicos, cómo evitar falsos positivos y cómo compilarla con sigma/pySigma a tu backend.
Al finalizar, el alumno podrá:
contains, endswith, re).filter y campo falsepositives.| # | Tema | Por qué importa |
|---|---|---|
| 1 | Por qué un formato portable | Escribe una vez, despliega en cualquier SIEM |
| 2 | Anatomía de una regla | logsource, detection, condition, metadata |
| 3 | Selecciones y condición | La lógica de detección |
| 4 | Modificadores de campo | Precisión al matchear valores |
| 5 | Filtros y falsos positivos | Detecciones que no ahogan al SOC |
| 6 | Tags ATT&CK y nivel | Contexto y priorización |
| 7 | Conversión con pySigma | Del YAML a la consulta real |
| 8 | Repositorio SigmaHQ | Miles de reglas listas para adaptar |
selection and not filter). Característica: define cuándo dispara.|contains, |endswith, |re, |base64). Característica: expresa coincidencias parciales o codificadas.pip install sigma-cli) con los plugins de backend (sigma plugin install splunk, elasticsearch).Prueba las reglas contra datos de laboratorio o el dataset BOTS; no las apliques a sistemas ajenos.
pip install sigma-cli y luego sigma plugin install splunk elasticsearch.office_spawns_powershell.yml:yaml
title: Office lanza PowerShell
logsource:
product: windows
category: process_creation
detection:
selection:
ParentImage|endswith:
- '\WINWORD.EXE'
- '\EXCEL.EXE'
Image|endswith: '\powershell.exe'
condition: selection
level: high
tags:
- attack.execution
- attack.t1059.001
falsepositives:
- Plantillas corporativas con macros firmadas
sigma convert -t splunk -p splunk_windows office_spawns_powershell.yml.sigma convert -t esql -p ecs_windows office_spawns_powershell.yml (o el backend/pipeline que uses).filter y condition: selection and not filter.rundll32.exe con argumentos sospechosos.|contains y |re para detectar PowerShell ofuscado.condition de umbral (| count() by ... > N).Entrega dos reglas Sigma propias (una de ejecución, una de persistencia) con tags ATT&CK, falsos positivos documentados y sus conversiones a tu SIEM. Criterio de aceptación: al menos una regla, ya convertida, dispara sobre tu actividad simulada en el SIEM y NO dispara con la actividad benigna de línea base; la CLI convierte ambas sin errores de sintaxis.
| Síntoma / mensaje | Causa y cómo arreglar |
|---|---|
sigma convert falla por pipeline |
Falta el pipeline (ECS/CIM); instala/indica -p correcto |
| La consulta no matchea campos | Nombres de campo distintos en tu SIEM; usa el pipeline de mapeo |
| Regla dispara con todo | condition demasiado amplia; añade selecciones y filtros |
Esperabas que \|contains fuera obligatorio para comodines |
En Sigma los comodines */? funcionan directamente en el valor; \|contains/\|endswith son azúcar que los añaden por ti (más legible). El fallo suele ser olvidar escapar un * literal. |
| YAML inválido | Indentación o listas mal formadas; valida con linter |
❓ ¿Sigma reemplaza al lenguaje de mi SIEM? No lo reemplaza: lo genera. Escribes en Sigma y compilas a SPL/EQL/KQL. Ganas portabilidad y una única fuente de verdad para tus detecciones.
❓ ¿Puedo versionar mis reglas como código? Sí, y deberías. Guarda tu carpeta de reglas en un repositorio, con revisión y CI que valide sintaxis y conversión (detección como código, clase 199).
❓ ¿Debo usar las reglas de SigmaHQ tal cual? Úsalas como base, pero adáptalas: cada entorno tiene sus falsos positivos. Copiar sin afinar genera fatiga de alertas.
Clase 185 — Elastic Stack y Wazuh