Ciberseguridad y seguridad de la información

Reglas Sigma: escritura, prueba y conversión a SIEM

6 min de lecturaPublicado: 5 de agosto de 2026

Ilustración visual profesional sobre la escritura de reglas Sigma en el ámbito de la caza de amenazas y la detección

Respuesta rápida

Escribir reglas Sigma comienza con una pregunta o comportamiento a identificar, continúa con la definición de telemetría y lógica, y finaliza con pruebas, ajuste, documentación y despliegue controlado. La calidad se mide por la cobertura y la capacidad de investigación.

Threat Hunting e Ingeniería de Detección transforman el conocimiento del comportamiento del adversario en preguntas medibles, fuentes de datos y reglas de detección. El objetivo no es generar más alertas, sino mejorar la cobertura y la calidad de las decisiones. Este artículo se centra en la escritura de reglas Sigma y está dirigido a analistas SOC y personal de detección principiante. El objetivo es proporcionar una metodología de trabajo aplicable en la práctica, en entrevistas profesionales y en el entorno laboral, sin limitarse a una definición de diccionario.

El principal desafío es que los datos casi siempre son parciales. title/id/status, logsource, detection selections pueden indicar una dirección, pero su significado depende del tiempo, el activo, el usuario y la actividad esperada. Por lo tanto, construiremos la prueba en torno a una pregunta de investigación, la evidencia requerida y un criterio claro de finalización.

El escenario práctico en el artículo es: escribir una regla para la creación de procesos anómalos en el laboratorio. Todos los ejemplos son datos de laboratorio o descripciones de procesos. Cuando se trata de Penetration Testing, Web o Cloud, solo se debe trabajar con autorización explícita, un alcance definido y la capacidad de detener la prueba.

Estructura Sigma

Los campos importantes no son necesariamente los que se muestran en la parte superior de la pantalla. Al escribir reglas Sigma, se deben identificar identificadores estables, tiempo, origen, destino, resultado y contexto. Ejemplos útiles son title/id/status, logsource, detection selections, condition, falsepositives, tags. El objetivo es permitir la correlación entre registros y no solo la lectura de un solo evento.

Se recomienda crear un pequeño diccionario de datos: nombre del campo, significado, formato, origen, valores Null esperados y si es confiable para vincular. De esta manera, se puede distinguir entre un campo de visualización y un identificador forense, y detectar cuándo un conector o una versión ha cambiado el esquema.

Logsource y campos

Selection y Condition

El tema 'Selection y Condition' es una parte central del trabajo de escritura de reglas Sigma. Se recomienda desglosarlo en tres preguntas: cuál es la entrada, qué decisión se desea tomar y qué evidencia es suficiente para justificarla. Estas preguntas evitan el uso automático de la herramienta sin comprender el objetivo.

En la práctica, registre title/id/status, logsource, detection selections, condition, falsepositives, compare con el comportamiento esperado y defina al menos un Pivot. El resultado debe ser verificable por otro analista, incluyendo limitaciones y próximos pasos.

False positives y Level

La mejora de la escritura de reglas Sigma debe comenzar con una línea base. Se mide el volumen, la tasa de casos útiles, el tiempo de investigación, las fuentes faltantes y la razón del cierre. Un cambio que reduce las alertas pero oculta actividad real no es un éxito.

Las opciones de ajuste incluyen un umbral, una ventana de tiempo, una lista blanca específica, el contexto del activo, la supresión y una excepción basada en un proceso aprobado. Cada excepción debe tener un propietario, una validez y condiciones de cancelación. Después del cambio, se ejecuta un corpus de prueba y se compara antes/después.

Conversión y Testing en SIEM

Una prueba profesional para la escritura de reglas Sigma comienza con condiciones de éxito y condiciones de fracaso. Se define un caso positivo, un caso negativo, un caso límite y una actividad legítima similar. De esta manera, se pueden identificar tanto falsos negativos como falsos positivos.

En un entorno autorizado, se utiliza una acción mínima que demuestra la afirmación sin causar daño. Se guardan la entrada, la salida, el tiempo y la versión, y después de la corrección se realiza una nueva prueba en el mismo escenario y también se verifica la regresión en funciones cercanas.

Puntos de prueba únicos

En este tema, se recomienda construir de antemano un mapa de evidencia específico. Los principales puntos de prueba son: title/id/status, logsource, detection selections, condition, falsepositives, tags. La lista no es una lista de verificación automática; cada elemento se elige porque puede vincular una entidad, una acción y un tiempo, o explicar un comportamiento legítimo.

title/id/status: Defina cuál es el valor esperado, qué se considerará anómalo y qué fuente adicional confirmará el hallazgo.
logsource: Defina cuál es el valor esperado, qué se considerará anómalo y qué fuente adicional confirmará el hallazgo.
detection selections: Defina cuál es el valor esperado, qué se considerará anómalo y qué fuente adicional confirmará el hallazgo.
condition: Defina cuál es el valor esperado, qué se considerará anómalo y qué fuente adicional confirmará el hallazgo.
falsepositives: Defina cuál es el valor esperado, qué se considerará anómalo y qué fuente adicional confirmará el hallazgo.
tags: Defina cuál es el valor esperado, qué se considerará anómalo y qué fuente adicional confirmará el hallazgo.

Cuando uno de los puntos no está disponible, se debe documentar la brecha y elegir una alternativa. Por ejemplo, si un identificador de proceso no es estable, se puede usar tiempo, Host, Usuario y Padre; si la carga útil está cifrada, se utilizan metadatos, volumen, frecuencia y contexto TLS/DNS.

Proceso de trabajo recomendado

Defina un alcance y una pregunta de trabajo sobre la escritura de reglas Sigma.
Registre las fuentes de datos y la evidencia necesaria: title/id/status, logsource, detection selections, condition.
Cree una línea base corta de comportamiento normal o resultado esperado.
Realice la prueba mínima en un entorno de laboratorio y guarde el tiempo, la entrada y la salida.
Construya una línea de tiempo o una tabla de comparación y separe los hechos de las interpretaciones.
Realice un Pivot a otra fuente para confirmar o refutar la explicación inicial.
Resuma la decisión, las limitaciones, la acción recomendada y el criterio de reevaluación.

Escenario práctico

El escenario elegido es la escritura de una regla para la creación de procesos anómalos en el laboratorio. El objetivo del ejercicio no es demostrar una capacidad de ataque, sino practicar la recopilación, comparación y documentación de manera segura. Antes de comenzar el trabajo, se definen datos simulados, una ventana de tiempo y un resultado esperado.

Al finalizar el ejercicio, se debe presentar un producto que un analista u otro evaluador pueda revisar: una captura de pantalla o una exportación de la evidencia, una línea de tiempo corta, una suposición inicial, evidencia confirmatoria, una limitación y una recomendación. Cuando no hay evidencia suficiente, la conclusión correcta es que el escenario no ha sido probado.

Paso	Qué se realiza	Resultado
Preparación	Defina el alcance, el tiempo y el objetivo. Registre qué campos o evidencias de title/id/status, logsource, detection selections se esperan.	Plan de prueba corto
Creación de datos	Realice una acción segura y simulada relacionada con la escritura de reglas Sigma, sin información real o impacto en un sistema de producción.	Evento/Solicitud/Flujo controlado
Recopilación	Recopile la evidencia bruta y el contexto de una fuente adicional. Verifique la zona horaria, los identificadores y la integridad.	Dos evidencias vinculadas
Análisis	Escriba lo que cada evidencia prueba, lo que no prueba y cuál es la posible explicación legítima.	Conclusión intermedia
Finalización	Elija un cierre, escalamiento, hallazgo o ajuste; agregue una recomendación y una nueva prueba.	Producto documentado

Lista de verificación práctica

Verifique y documente: Hipótesis.
Verifique y documente: Técnica ATT&CK.
Verifique y documente: Fuentes de datos.
Verifique y documente: Lógica de detección.
Verifique y documente: Comportamiento benigno esperado.
Verifique y documente: Casos de prueba y cobertura.
Indique la zona horaria, la versión de la herramienta y la hora de recopilación.
Guarde el dato bruto antes de filtrar o modificar.
Escriba lo que el hallazgo prueba y lo que aún se desconoce.
Defina el propietario y la acción de seguimiento con una fecha.

Errores comunes

Comenzar con un IOC aleatorio sin hipótesis.
Mapear ATT&CK solo por nombre.
Escribir reglas sin casos de prueba.
Ignorar el comportamiento legítimo.
Medir reglas en lugar de cobertura.
No gestionar versiones.

Resumen y CTA

Las reglas Sigma: escritura, prueba y conversión a SIEM es un tema que conecta el conocimiento técnico con la disciplina de trabajo. Comience con una pregunta, recopile solo evidencia relevante, conserve el contexto y el tiempo, y elija una acción que pueda justificarse y volver a probarse.

En el programa Cybersecurity & AI de HPI, estos principios se practican utilizando sistemas, registros y laboratorios. Un paso natural es pasar a los artículos vinculados, realizar el ejercicio de laboratorio y guardar el producto como parte de un portafolio profesional.

Preguntas frecuentes

¿La escritura de reglas Sigma por sí sola demuestra un ataque o una debilidad?

No. Proporciona una señal o un hallazgo que necesita contexto, validación y una fuente adicional. Una conclusión profesional se basa en una secuencia de evidencias y en la conformidad con el comportamiento esperado.

¿Qué se hace cuando faltan algunos datos?

Se documenta la falta, se busca una fuente alternativa y se reduce el nivel de confianza. No se deben completar campos por suposición ni presentar 'Desconocido' como válido.

¿Cuánto tiempo se deben conservar las pruebas?

El tiempo depende de la política, la regulación, el costo y el tipo de incidente. Es importante definir de antemano la retención, la retención legal y la capacidad de exportar pruebas en un formato verificable.

¿Cómo se practica sin poner en riesgo un sistema real?

Se utilizan máquinas virtuales, datos simulados, CTF o un laboratorio dedicado. En las pruebas autorizadas, se definen el alcance, las condiciones de detención y una copia de seguridad antes de comenzar el trabajo.