Reglas SIGMA y detección estandarizada

Splunk utiliza SPL (search EventCode=4624 ...), Elastic utiliza KQL o EQL, y Microsoft Sentinel utiliza Kusto (KQL). Cuando un equipo de inteligencia de amenazas descubre un nuevo método de ataque (por ejemplo, el volcado de contraseñas de LSASS mediante rundll32.exe), publicar la regla en un solo dialecto limita su utilidad para la comunidad. SIGMA nació como el 'Snort para registros': un estándar abierto en formato YAML para describir detecciones de forma agnóstica a la plataforma.

Una regla SIGMA es un archivo de texto estructurado que contiene: 1) Metadatos (title, status, description, author). 2) Mapeo a MITRE ATT&CK (tags: attack.t1003.001). 3) Definición del origen de datos (logsource: category: process_creation, product: windows). 4) Criterio de detección (detection: selection: Image|endswith: '\rundll32.exe', CommandLine|contains: 'comsvcs.dll'). 5) Condición lógica (condition: selection). Es legible para humanos y procesable por máquinas.

Para desplegar una regla SIGMA en producción se utiliza el compilador sigma-cli (basado en pySigma). Con un solo comando: sigma convert -t splunk regla.yml, la herramienta genera la consulta exacta en SPL para Splunk. Si el cliente migra de Splunk a Microsoft Sentinel al año siguiente, el equipo no pierde su biblioteca de detecciones: basta con volver a compilar con -t kusto para obtener las reglas listas para Azure.

Una regla SIGMA descargada de un repositorio público nunca debe aplicarse en modo de bloqueo inmediato: debe probarse en el entorno real de la empresa para identificar el software legítimo que usa comandos similares (por ejemplo, instaladores de antivirus o scripts de mantenimiento nocturno). El analista añade cláusulas de filtro (filter: selection_legit) para silenciar el ruido antes de conectar la alerta a la cola del SOC.