Sigma Pipelines: Procesamiento, Backends y Conversión Avanzada a tu SIEM

El problema que nadie te cuenta al convertir reglas Sigma

Escribir una regla Sigma es la parte fácil. Convertirla a tu SIEM y que funcione en producción es donde la mayoría de equipos SOC se atascan.

El motivo: ejecutar sigma convert -t splunk rule.yml genera una query SPL sintácticamente válida, pero con nombres de campo como Image, CommandLine o ParentImage. En tu Splunk, esos campos se llaman process_name, process o parent_process_name dependiendo de tu fuente de logs, tu CIM model y cómo tengas configurado el forwarder.

pySigma resuelve esto con un sistema de procesamiento en tres capas: pipelines que transforman el contenido, backends que generan la sintaxis, y processing rules que encadenan transformaciones específicas de tu entorno. Este artículo cubre la arquitectura completa.

Arquitectura de pySigma: pipeline, backend, output

pySigma procesa una regla Sigma en tres fases secuenciales:

Regla Sigma (YAML)
       │
       ▼
┌──────────────┐
│   Pipeline    │  → Field mapping, logsource mapping, transformaciones
│  (semántica)  │
└──────┬───────┘
       │
       ▼
┌──────────────┐
│   Backend     │  → Genera sintaxis del lenguaje objetivo (SPL, KQL, Lucene...)
│  (sintaxis)   │
└──────┬───────┘
       │
       ▼
   Output (query ejecutable en tu SIEM)

El pipeline opera sobre la representación intermedia de la regla (el objeto SigmaRule de pySigma). Modifica nombres de campo, traduce logsources a índices o tablas, y aplica transformaciones condicionales. El backend toma esa representación ya transformada y genera la query final en el lenguaje del SIEM.

Esta separación es la clave de diseño. Puedes usar el mismo backend de Splunk con pipelines distintos: uno para Sysmon + Splunk CIM, otro para Windows Event Forwarding + custom field names, otro para CrowdStrike Falcon Data Replicator enviando a Splunk. Cada pipeline adapta los campos, el backend genera SPL.

Instalación del ecosistema

pip install pySigma

# Backend de tu SIEM
pip install pySigma-backend-splunk
pip install pySigma-backend-elasticsearch
pip install pySigma-backend-kusto          # Microsoft Sentinel / Defender
pip install pySigma-backend-crowdstrike

# Pipelines preconfigurados
pip install pySigma-pipeline-sysmon
pip install pySigma-pipeline-windows
pip install pySigma-pipeline-crowdstrike

Processing pipelines: transformando reglas

Un pipeline es una lista ordenada de processing items, cada uno con una transformación y una condición que determina cuándo se aplica.

Anatomía de un processing item

from sigma.processing.pipeline import ProcessingPipeline, ProcessingItem
from sigma.processing.transformations import FieldMappingTransformation
from sigma.processing.conditions import LogsourceCondition

pipeline = ProcessingPipeline(
    name="Custom Splunk Pipeline",
    priority=20,
    items=[
        ProcessingItem(
            identifier="sysmon_process_creation_fieldmapping",
            transformation=FieldMappingTransformation({
                "Image": "process_name",
                "CommandLine": "process",
                "ParentImage": "parent_process_name",
                "ParentCommandLine": "parent_process",
                "User": "user",
                "IntegrityLevel": "integrity_level",
                "Hashes": "file_hash",
                "OriginalFileName": "original_file_name",
            }),
            rule_conditions=[
                LogsourceCondition(
                    category="process_creation",
                    product="windows"
                )
            ]
        ),
    ]
)

Cada ProcessingItem tiene tres componentes:

1. transformation: qué hacer (renombrar campos, cambiar valores, añadir condiciones).
2. rule_conditions: cuándo aplicarlo (solo si la regla tiene cierto logsource, cierto level, etc.).
3. identifier: nombre único para debugging y trazabilidad.

Tipos de transformaciones

pySigma incluye transformaciones predefinidas que cubren los escenarios más comunes:

Transformación	Función	Uso típico
FieldMappingTransformation	Renombra campos	Image → process_name
AddConditionTransformation	Añade condición a la detección	Filtrar por sourcetype=WinEventLog
ChangeLogsourceTransformation	Cambia el logsource	category: process_creation → index: windows
DropDetectionItemTransformation	Elimina un item de detección	Quitar campos no soportados
ReplaceStringTransformation	Reemplaza strings en valores	C:\Windows\ → C:\\Windows\\
SetStateTransformation	Almacena estado para pipeline chaining	Pasar contexto entre items
WildcardPlaceholderTransformation	Expande placeholders con wildcards	%SystemRoot% → C:\Windows\*
ValueListPlaceholderTransformation	Expande listas de valores	Lookup tables
QueryPostprocessingTransformation	Modifica la query final	Añadir prefijo/sufijo

Field mapping: el reto central

El mayor dolor de cabeza al convertir reglas Sigma es que cada SIEM, cada fuente de logs y cada configuración usa nombres de campo distintos para los mismos datos. El campo CommandLine de Sigma puede corresponder a:

SIEM / Fuente	Campo equivalente
Sysmon	CommandLine
Windows Security 4688	NewProcessName + CommandLine (si está habilitado)
Splunk CIM	process
Elastic ECS	process.command_line
Microsoft Sentinel	ProcessCommandLine
CrowdStrike	CommandLine
Carbon Black	process_cmdline
SentinelOne	TgtProcCmdLine

Un FieldMappingTransformation con diccionario cubre el caso simple. Para escenarios complejos donde un campo Sigma se mapea a varios campos del SIEM (o viceversa), pySigma soporta mappings uno a muchos:

FieldMappingTransformation({
    "Image": ["process_name", "process_path"],  # busca en ambos
    "SourceIp": "src_ip",
    "DestinationIp": "dest_ip",
    "DestinationPort": "dest_port",
})

Logsource mapping: traducir categorías a índices

Las reglas Sigma usan logsources abstractos (category: process_creation, product: windows). Tu SIEM necesita saber dónde buscar: un índice, una tabla, un data source.

ProcessingItem(
    identifier="splunk_windows_logsource",
    transformation=ChangeLogsourceTransformation(
        category="process_creation",
        product="windows",
    ),
    rule_conditions=[
        LogsourceCondition(
            category="process_creation",
            product="windows"
        )
    ]
),
ProcessingItem(
    identifier="splunk_index_mapping",
    transformation=AddConditionTransformation({
        "source": "WinEventLog:Microsoft-Windows-Sysmon/Operational",
        "sourcetype": "XmlWinEventLog:Microsoft-Windows-Sysmon/Operational",
    }),
    rule_conditions=[
        LogsourceCondition(
            category="process_creation",
            product="windows"
        )
    ]
),

La diferencia entre Windows Security Event Log y Sysmon es fundamental. Un entorno con Sysmon genera process_creation como Event ID 1 con campos ricos (Image, CommandLine, Hashes, ParentImage). Un entorno sin Sysmon usa Security Event ID 4688, que tiene menos campos y requiere habilitar "Audit Process Creation" + "Include command line in process creation events" via GPO.

Tu pipeline debe reflejar exactamente qué fuentes de logs tienes desplegadas.

Pipelines built-in: los que ya vienen hechos

pySigma y la comunidad mantienen pipelines preconfigurados para los SIEM más comunes. Instálalos como paquetes Python independientes.

Splunk

pip install pySigma-pipeline-splunk

from sigma.backends.splunk import SplunkBackend
from sigma.pipelines.splunk import splunk_cim_data_model

backend = SplunkBackend(processing_pipeline=splunk_cim_data_model())

El pipeline splunk_cim_data_model() mapea campos Sigma al Common Information Model de Splunk. Si tu entorno no usa CIM, necesitas un pipeline custom.

Elastic / OpenSearch

pip install pySigma-pipeline-elasticsearch

from sigma.backends.elasticsearch import LuceneBackend
from sigma.pipelines.elasticsearch import ecs_windows

backend = LuceneBackend(processing_pipeline=ecs_windows())

El pipeline ecs_windows() mapea a Elastic Common Schema (ECS). Campos como Image se convierten en process.executable, CommandLine en process.command_line, SourceIp en source.ip.

Microsoft Sentinel / Defender

pip install pySigma-backend-kusto
pip install pySigma-pipeline-microsoft365defender

from sigma.backends.kusto import KustoBackend
from sigma.pipelines.microsoft365defender import microsoft_365_defender_pipeline

backend = KustoBackend(processing_pipeline=microsoft_365_defender_pipeline())

Sentinel usa tablas como DeviceProcessEvents, DeviceFileEvents, DeviceNetworkEvents. El pipeline traduce los logsources Sigma a las tablas correctas y mapea campos a los nombres de Sentinel.

CrowdStrike Falcon

pip install pySigma-backend-crowdstrike
pip install pySigma-pipeline-crowdstrike

CrowdStrike usa su propio esquema de campos. Image se convierte en ImageFileName, CommandLine se mantiene, pero ParentImage es ParentBaseFileName. El pipeline de CrowdStrike maneja estas diferencias.

Pipelines custom: adaptándote a tu entorno

Los pipelines preconfigurados cubren el caso genérico. En la realidad, cada organización tiene variaciones: campos custom, sourcetypes específicos, índices con naming conventions propias, lookups que añaden contexto.

Pipeline custom en YAML

pySigma soporta pipelines definidos en YAML, más accesibles para equipos que no programan en Python:

name: Acme Corp Splunk Pipeline
priority: 20
transformations:
  - id: acme_process_creation_fields
    type: field_name_mapping
    mapping:
      Image: process_exec
      CommandLine: process_cmd
      ParentImage: parent_exec
      ParentCommandLine: parent_cmd
      User: src_user
      Hashes: file_hash
      TargetFilename: file_path
      SourceIp: src
      DestinationIp: dest
      DestinationPort: dest_port
    rule_conditions:
      - type: logsource
        category: process_creation
        product: windows

  - id: acme_sysmon_index
    type: add_condition
    conditions:
      index: sysmon_logs
      sourcetype: xmlwineventlog
    rule_conditions:
      - type: logsource
        product: windows

  - id: acme_network_fields
    type: field_name_mapping
    mapping:
      SourceIp: src_ip
      DestinationIp: dest_ip
      DestinationPort: dest_port
      DestinationHostname: dest_host
    rule_conditions:
      - type: logsource
        category: network_connection

  - id: acme_dns_index
    type: add_condition
    conditions:
      index: dns_logs
    rule_conditions:
      - type: logsource
        category: dns_query

Cargar el pipeline YAML en Python:

from sigma.processing.pipeline import ProcessingPipeline

with open("acme_pipeline.yml", "r") as f:
    pipeline = ProcessingPipeline.from_yaml(f.read())

Y desde sigma-cli:

sigma convert -t splunk -p acme_pipeline.yml rules/

Pipeline custom en Python API

Para transformaciones complejas que YAML no cubre (lógica condicional, lookups dinámicos, validaciones), usa la API Python:

from sigma.processing.pipeline import ProcessingPipeline, ProcessingItem
from sigma.processing.transformations import (
    FieldMappingTransformation,
    AddConditionTransformation,
    ChangeLogsourceTransformation,
    DropDetectionItemTransformation,
)
from sigma.processing.conditions import (
    LogsourceCondition,
    RuleContainsDetectionItemCondition,
)

def acme_pipeline():
    return ProcessingPipeline(
        name="Acme Corp Enterprise Pipeline",
        priority=20,
        items=[
            # Mapeo de campos para process_creation
            ProcessingItem(
                identifier="acme_proc_fields",
                transformation=FieldMappingTransformation({
                    "Image": "process_exec",
                    "CommandLine": "process_cmd",
                    "ParentImage": "parent_exec",
                    "User": "src_user",
                    "Hashes": "file_hash",
                }),
                rule_conditions=[
                    LogsourceCondition(
                        category="process_creation",
                        product="windows",
                    )
                ],
            ),
            # Añadir index y sourcetype para Sysmon
            ProcessingItem(
                identifier="acme_sysmon_source",
                transformation=AddConditionTransformation({
                    "index": "sysmon_logs",
                    "sourcetype": "xmlwineventlog",
                }),
                rule_conditions=[
                    LogsourceCondition(product="windows")
                ],
            ),
            # Eliminar campo no soportado en nuestro entorno
            ProcessingItem(
                identifier="acme_drop_integrity",
                transformation=DropDetectionItemTransformation(),
                rule_conditions=[
                    LogsourceCondition(
                        category="process_creation",
                        product="windows",
                    )
                ],
                detection_item_conditions=[
                    RuleContainsDetectionItemCondition(
                        field="IntegrityLevel"
                    )
                ],
            ),
        ],
    )

Pipeline chaining: combinando transformaciones

pySigma permite aplicar múltiples pipelines en secuencia. El caso más habitual: un pipeline de logsource (define qué fuente de logs usas) seguido de un pipeline de producto (adapta al esquema del SIEM).

from sigma.processing.pipeline import ProcessingPipeline
from sigma.pipelines.sysmon import sysmon_pipeline
from sigma.pipelines.splunk import splunk_cim_data_model

# Pipeline 1: adapta logsources a Sysmon event IDs
# Pipeline 2: mapea campos al CIM de Splunk
combined = ProcessingPipeline.from_list([
    sysmon_pipeline(),
    splunk_cim_data_model(),
])

backend = SplunkBackend(processing_pipeline=combined)

Desde sigma-cli, el chaining se hace con múltiples -p:

sigma convert -t splunk -p sysmon -p splunk_cim rules/

El orden importa. Si el pipeline de Sysmon renombra Image a process_name y después el pipeline de Splunk CIM busca Image para renombrarlo, no lo encontrará. Revisa la prioridad de cada pipeline (campo priority) para entender el orden de ejecución.

Backend plugins: tabla de referencia

La comunidad mantiene backends para la mayoría de SIEM y herramientas de seguridad del mercado:

Backend	Paquete pip	Salida	Notas
Splunk	pySigma-backend-splunk	SPL, savedsearches.conf	Soporte CIM, datamodels
Elasticsearch	pySigma-backend-elasticsearch	Lucene, EQL, ES|QL	Soporte ECS
Kusto (Sentinel)	pySigma-backend-kusto	KQL	Defender + Sentinel
CrowdStrike	pySigma-backend-crowdstrike	FQL / LogScale	Falcon Data
QRadar	pySigma-backend-qradar	AQL	IBM QRadar
Chronicle	pySigma-backend-chronicle	YARA-L	Google SecOps
Cortex XSIAM	pySigma-backend-cortexxdr	XQL	Palo Alto
SentinelOne	pySigma-backend-sentinelone	PowerQuery	Deep Visibility
Loki	pySigma-backend-loki	LogQL	Grafana Loki
STIX	pySigma-backend-stix	STIX Patterns	Interoperabilidad
InsightIDR	pySigma-backend-insightidr	LEQL	Rapid7
Hawk	pySigma-backend-hawk	Hawk QL	OverWatch
SQLite	pySigma-backend-sqlite	SQL	Análisis offline
NetWitness	pySigma-backend-netwitness	NW Query	RSA NetWitness
Datadog	pySigma-backend-datadog	Datadog Query	Cloud SIEM
Securonix	pySigma-backend-securonix	Spotter Query	Securonix

Para listar los backends y pipelines instalados:

sigma list backends
sigma list pipelines

Automatización: CI/CD para reglas Sigma

En un equipo de Detection Engineering maduro, las reglas Sigma se gestionan como código. El repositorio de reglas tiene un pipeline CI/CD que valida, convierte y despliega las detecciones automáticamente.

Estructura de repositorio

sigma-rules/
├── rules/
│   ├── windows/
│   │   ├── process_creation/
│   │   ├── file_event/
│   │   └── registry_event/
│   ├── linux/
│   └── cloud/
├── pipelines/
│   ├── acme_splunk.yml
│   ├── acme_elastic.yml
│   └── acme_sentinel.yml
├── output/
│   ├── splunk/
│   ├── elastic/
│   └── sentinel/
├── tests/
│   └── validate_rules.py
├── Makefile
├── .github/workflows/sigma-convert.yml
└── requirements.txt

Makefile

RULES_DIR = rules
PIPELINES_DIR = pipelines
OUTPUT_DIR = output

.PHONY: validate convert-splunk convert-elastic convert-sentinel convert-all clean

validate:
	sigma check $(RULES_DIR)/

convert-splunk:
	sigma convert \
		-t splunk \
		-p $(PIPELINES_DIR)/acme_splunk.yml \
		-o $(OUTPUT_DIR)/splunk/ \
		$(RULES_DIR)/

convert-elastic:
	sigma convert \
		-t elasticsearch \
		-p $(PIPELINES_DIR)/acme_elastic.yml \
		-o $(OUTPUT_DIR)/elastic/ \
		$(RULES_DIR)/

convert-sentinel:
	sigma convert \
		-t kusto \
		-p $(PIPELINES_DIR)/acme_sentinel.yml \
		-o $(OUTPUT_DIR)/sentinel/ \
		$(RULES_DIR)/

convert-all: validate convert-splunk convert-elastic convert-sentinel

clean:
	rm -rf $(OUTPUT_DIR)/*

GitHub Actions

name: Sigma Rules CI/CD

on:
  push:
    paths:
      - 'rules/**'
      - 'pipelines/**'
  pull_request:
    paths:
      - 'rules/**'

jobs:
  validate-and-convert:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.12'

      - name: Install dependencies
        run: |
          pip install sigma-cli
          pip install pySigma-backend-splunk
          pip install pySigma-backend-elasticsearch
          pip install pySigma-backend-kusto

      - name: Validate rules
        run: sigma check rules/

      - name: Convert to Splunk
        run: |
          sigma convert \
            -t splunk \
            -p pipelines/acme_splunk.yml \
            rules/ > output/splunk/all_rules.spl

      - name: Convert to Elastic
        run: |
          sigma convert \
            -t elasticsearch \
            -p pipelines/acme_elastic.yml \
            rules/ > output/elastic/all_rules.json

      - name: Upload artifacts
        uses: actions/upload-artifact@v4
        with:
          name: converted-rules
          path: output/

Conversión programática con Python

Para flujos más complejos (condicionales por carpeta, múltiples output formats, validaciones custom):

from pathlib import Path
from sigma.rule import SigmaRule
from sigma.collection import SigmaCollection
from sigma.backends.splunk import SplunkBackend
from sigma.processing.pipeline import ProcessingPipeline

def convert_rules(rules_dir: Path, pipeline_path: Path, output_dir: Path):
    # Cargar pipeline custom
    pipeline = ProcessingPipeline.from_yaml(pipeline_path.read_text())
    backend = SplunkBackend(processing_pipeline=pipeline)

    # Cargar todas las reglas del directorio
    collection = SigmaCollection.load_ruleset(
        [str(rules_dir)],
    )

    # Convertir cada regla
    results = []
    for rule in collection:
        try:
            queries = backend.convert_rule(rule)
            results.append({
                "id": str(rule.id),
                "title": rule.title,
                "level": str(rule.level),
                "queries": queries,
                "status": "success",
            })
        except Exception as e:
            results.append({
                "id": str(rule.id),
                "title": rule.title,
                "status": "error",
                "error": str(e),
            })

    # Generar reporte
    success = [r for r in results if r["status"] == "success"]
    errors = [r for r in results if r["status"] == "error"]
    print(f"Convertidas: {len(success)} | Errores: {len(errors)}")

    for error in errors:
        print(f"  ERROR: {error['title']} - {error['error']}")

    return results

sigma-cli: uso avanzado

Más allá de la conversión básica, sigma-cli ofrece funcionalidades que los equipos de detección usan diariamente.

Validación estricta

# Validar una regla individual
sigma check rules/windows/proc_creation_win_encoded_powershell.yml

# Validar un directorio completo
sigma check rules/ --fail-on-error

# Validar con nivel mínimo (rechazar reglas sin level o con status experimental)
sigma check rules/ --validation-config strict.yml

Conversión con filtros

# Solo reglas con level high o critical
sigma convert -t splunk -p sysmon rules/ --filter level=high,critical

# Solo reglas con cierto tag ATT&CK
sigma convert -t splunk rules/ --filter tag=attack.t1059.001

# Solo reglas con status stable o test (excluir experimental)
sigma convert -t splunk rules/ --filter status=stable,test

Output formats

# Query plana (default)
sigma convert -t splunk rules/rule.yml

# JSON con metadatos
sigma convert -t splunk -f json rules/rule.yml

# Splunk savedsearches.conf format
sigma convert -t splunk -f savedsearches rules/rule.yml

# NDJSON para Elastic bulk import
sigma convert -t elasticsearch -f ndjson_rule rules/rule.yml

Listar backends, pipelines y validators

sigma list backends          # backends instalados
sigma list pipelines         # pipelines disponibles
sigma list validators        # reglas de validación
sigma list modifiers         # modificadores de detección soportados

Pitfalls comunes: lo que falla en producción

1. Field names que no existen en tu SIEM

El error más frecuente. Conviertes 500 reglas Sigma a Splunk, las despliegas, y ninguna genera alertas. El motivo: los campos Image, CommandLine, ParentImage de Sigma no existen en tu Splunk porque usas process_name, process, parent_process_name.

La solución: siempre usar un pipeline con field mappings que corresponda a tu entorno real. Nunca confiar en la conversión por defecto.

# MAL: sin pipeline, campos genéricos
sigma convert -t splunk rule.yml

# BIEN: con pipeline adaptado a tu entorno
sigma convert -t splunk -p mi_entorno.yml rule.yml

2. Logsources sin mapear

Una regla con logsource: category: dns_query, product: windows asume que tienes DNS query logging habilitado. Si tu entorno no tiene Sysmon Event ID 22 ni Microsoft DNS Debug Logging, la regla no puede generar resultados aunque la query sea correcta.

Antes de desplegar, verifica que tu infraestructura genera los logs que las reglas esperan.

3. Features no soportadas por backend

No todos los backends soportan todas las features de Sigma. Ejemplos:

Feature Sigma	Backends que NO lo soportan
near (correlación temporal)	Mayoría de backends
count() con by	Algunos backends legacy
base64offset	Backends que no soportan regex avanzado
cidr	Backends sin soporte nativo de CIDR
expand (variables de entorno)	La mayoría (depende del SIEM)
Múltiples wildcards en un valor	Algunos backends generan regex ineficientes

Cuando una feature no está soportada, pySigma lanza un warning o genera una query parcial. Revisa los warnings.

4. Rendimiento de queries generadas

Una regla Sigma con 20 valores en una lista contains genera una query con 20 subcondiciones OR. En Splunk, eso puede ser lento si busca en un índice grande sin tiempo acotado. Algunas técnicas para mitigar:

• Usar startswith o endswith en lugar de contains cuando sea posible
• Agrupar reglas por logsource para buscar en el índice correcto
• Añadir restricciones temporales en la query generada (via pipeline custom)
• Usar lookups en Splunk o enrichment en Elastic en lugar de listas largas inline

5. Duplicados y conflictos entre pipelines

Al encadenar pipelines, un campo puede renombrarse dos veces. Si el pipeline A renombra Image a process_path y el pipeline B renombra Image a process_name, solo el primero se aplica (el segundo no encuentra Image). Peor: si el pipeline B renombra process_path a otra cosa, el resultado es impredecible.

Solución: revisar las prioridades de los pipelines (campo priority) y documentar qué campos transforma cada uno.

Ejemplo completo: de regla Sigma a Splunk con pipeline custom

from sigma.rule import SigmaRule
from sigma.backends.splunk import SplunkBackend
from sigma.processing.pipeline import ProcessingPipeline, ProcessingItem
from sigma.processing.transformations import (
    FieldMappingTransformation,
    AddConditionTransformation,
)
from sigma.processing.conditions import LogsourceCondition

# 1. Definir pipeline adaptado a nuestro Splunk
pipeline = ProcessingPipeline(
    name="SOC-Acme-Splunk",
    priority=20,
    items=[
        ProcessingItem(
            identifier="proc_creation_fields",
            transformation=FieldMappingTransformation({
                "Image": "process_name",
                "CommandLine": "process",
                "ParentImage": "parent_process_name",
                "ParentCommandLine": "parent_process",
                "User": "user",
                "Hashes": "file_hash",
            }),
            rule_conditions=[
                LogsourceCondition(
                    category="process_creation",
                    product="windows",
                )
            ],
        ),
        ProcessingItem(
            identifier="sysmon_index",
            transformation=AddConditionTransformation({
                "index": "win_sysmon",
                "sourcetype": "XmlWinEventLog",
            }),
            rule_conditions=[
                LogsourceCondition(product="windows")
            ],
        ),
    ],
)

# 2. Crear backend con pipeline
backend = SplunkBackend(processing_pipeline=pipeline)

# 3. Cargar y convertir regla
rule_yaml = """
title: Suspicious Encoded PowerShell
id: f3a98ce4-0000-0000-0000-000000000001
status: test
logsource:
    category: process_creation
    product: windows
detection:
    selection:
        Image|endswith: '\\\\powershell.exe'
        CommandLine|contains: '-enc'
    condition: selection
level: high
"""

rule = SigmaRule.from_yaml(rule_yaml)
result = backend.convert_rule(rule)
print(result[0])

Output:

index=win_sysmon sourcetype=XmlWinEventLog
process_name="*\\powershell.exe"
process="*-enc*"

Los campos Image y CommandLine se convirtieron a process_name y process. El índice y sourcetype se añadieron automáticamente. La query es ejecutable directamente en Splunk.

Recursos y referencias

• pySigma en GitHub: librería core de procesamiento
• sigma-cli: herramienta de linea de comandos
• SigmaHQ backends: todos los backends oficiales bajo la organización SigmaHQ
• pySigma Processing Pipelines docs: documentacion oficial de pipelines
• Elastic Common Schema (ECS): referencia de campos ECS
• Splunk CIM: Common Information Model de Splunk
• MITRE ATT&CK Navigator: visualizacion de cobertura de reglas
• SigmaHQ/sigma: 3.000+ reglas para usar como base

Siguiente paso

Dominas la cadena completa: escribir reglas, configurar pipelines y convertir a tu SIEM. El siguiente bloque de la serie cambia de formato: pasamos de Sigma (logs) a YARA (ficheros). Veremos la anatomia de una regla YARA, patrones hexadecimales, strings, condiciones booleanas y tu primera regla para detectar un dropper real.