Anatomía de una regla Sigma

5 tareas · 38 min · Principiante

Una regla Sigma es un archivo de texto con una estructura fija: una parte que dice quién es la regla, una que dice de qué registros habla, una que dice qué busca y otra que dice cómo tratarla. En Distribuidora Villeta tienes ocho reglas escritas en ese formato. Aquí lees la primera de principio a fin, separas lo que la especificación exige de lo que es opcional y entiendes para qué sirve cada pieza antes de revisar una regla ajena sin ejecutarla.

0 de 5 · 0%

Objetivo de la sala

Sigma es un formato abierto para describir reglas de detección sobre registros, independiente de la plataforma que las ejecute. Una regla es un documento en YAML: pares de clave y valor, con sangría. No dice cómo se consulta un SIEM concreto; dice qué se busca y en qué datos. Otra herramienta, el conversor, traduce ese documento a la consulta de cada plataforma.

La especificación pide poco. Una regla válida necesita un nombre legible, la descripción de los registros sobre los que actúa y la lógica de detección con su condición. Todo lo demás es opcional, aunque un repositorio serio lo exige por política: identificador, estado, nivel, autor, fechas, referencias.

Responde para continuar

¿Qué campos del nivel superior exige la especificación de Sigma en toda regla?

title, logsource y detection, porque sin saber de qué registros habla la lógica no tendría dónde evaluarse title, id, status y level, porque el turno los necesita para decidir qué hacer con una alerta title y detection, porque la lógica ya indica de qué registros habla y el conversor deduce el resto del contexto

La sección logsource dice qué clase de registro lee la regla. Tiene tres claves que el conversor sí interpreta: una categoría de evento, un producto o sistema y, a veces, un servicio dentro de él. Con ellas elige el índice, la tabla o la fuente de la plataforma de destino. Una cuarta clave, definition, no la evalúa nadie: es una nota para humanos sobre qué configuración de registro hace falta.

Abre la consola y consulta el archivo de la regla DVL-101.

Responde para continuar

Escribe el valor de la clave category dentro de logsource en DVL-101.

Ver pista de ayuda

Ejecuta `SELECT * FROM regla_dvl_101` y busca el bloque logsource.

Una regla cambia de nombre, se fusiona con otra o se reemplaza. La clave related guarda esa genealogía: una lista de pares con el id de la otra regla y el tipo de relación. Los tipos son cinco: derivada de otra, obsoleta a otra, fusionada de varias, renombrada y similar. Quien hereda el repositorio la lee para saber si el identificador que aparece en un ticket viejo sigue vivo.

DVL-101 declara una relación con una regla anterior de identificador terminado en 100.

Responde para continuar

Escribe el tipo de relación que DVL-101 declara con la regla de id terminado en 100.

Ver pista de ayuda

Ejecuta `SELECT * FROM regla_dvl_101` y mira el bloque related, justo después del id.

Mirar una regla campo a campo ayuda a separar dos cosas que se confunden: lo que el formato exige para que el documento sea válido y lo que el equipo decide pedir para poder mantenerlo. Una regla sin autor o sin fecha es válida; un repositorio con cien reglas así es inmantenible.

La consola trae una tabla con cada campo de primer nivel de DVL-101 y su obligatoriedad según la especificación.

Responde para continuar

¿Cuántos de los campos del nivel superior de DVL-101 son opcionales según la especificación?

Ver pista de ayuda

Ejecuta `SELECT * FROM campos_de_la_regla` y cuenta las filas cuya columna obligatorio_segun_la_especificacion dice no.

La regla DVL-101 incluye en su logsource una línea que dice que hace falta auditoría de creación de procesos con línea de comandos. Es información útil, pero el conversor no la usa para nada. Sirve para que quien despliega la regla compruebe que el registro existe antes de activarla.

Consulta la tabla de claves de logsource antes de decidir.

Responde para continuar

El equipo quiere que el conversor falle si no existe el registro de creación de procesos. ¿Basta con escribirlo en definition?

No, porque definition es una nota para humanos y esa comprobación se hace aparte, con el inventario Sí, porque el conversor lee todas las claves de logsource y avisa de cualquier requisito que no se cumpla Sí, pero solo si la regla trae status en stable, que es el que activa esas comprobaciones

Inicia sesión para registrar tus puntos y progreso en el ranking.

Entrar · Registrarse

1 Qué exige la especificación

2 Los registros de los que habla la regla Lab

3 El historial de una regla Lab

4 Cuánto es obligatorio y cuánto es costumbre Lab

5 La nota que nadie evalúa Lab

Whoami-Labs Pro utiliza cookies