Aplica la lógica de segmentación de YARA-L 2.0

Se admite en los siguientes sistemas operativos:

Google SecOps SIEM

En esta guía, se ayuda a los ingenieros de seguridad a elegir el tipo de ventana correcto para las consultas y evitar errores del compilador del tipo "variable no acotada". La transición de ventanas deslizantes a ventanas de saltos de tamaño constante te permite crear una lógica que dependa de la ausencia de eventos, como una señal de monitoreo de funcionamiento faltante o una fuente del archivo de registro con errores.

Antes de comenzar

Confirma que tu cuenta tenga uno de los siguientes roles para crear y modificar consultas de YARA-L:

• Administrador de Detection Engine (roles/chronicle.detectionEngineAdmin)
• Editor de SecOps (roles/chronicle.editor)

Tipos de ventanas admitidos

YARA-L 2.0 usa diferentes comportamientos de segmentación para determinar cómo se divide el tiempo y cómo se agrupan los eventos. Puedes agrupar los campos y marcadores de posición de eventos en la sección match según una granularidad temporal especificada con las siguientes ventanas admitidas:

Tipo de ventana admitido	Sintaxis	Descripción	Caso de uso común
Hop	$key over <duration>	Crea intervalos de tiempo fijos y superpuestos. El sistema define la superposición y la alineación para captar eventos cerca de los límites.	Correlación general de varios eventos, independientemente de las horas de inicio exactas
Rotación	$key by <duration>	Segmenta los datos en bloques continuos, no superpuestos y de tamaño fijo. Se evalúa de forma independiente de la llegada de eventos.	Cuantificar la actividad en intervalos fijos (por ejemplo, $user by 30m) o detectar la ausencia de eventos
Deslizamiento	$key over <duration> [before|after] $pivot	Ancla la ventana a un evento "pivot" específico. Se requiere que exista el pivote para activar una búsqueda hacia atrás o hacia adelante.	Secuenciación estricta en la que el orden de los eventos es fundamental (por ejemplo, File Download after Login)

Comprende la lógica de window_start y window_end

Google Security Operations proporciona dos palabras clave universales reservadas que se resuelven directamente en marcas de tiempo de GoogleSQL para su uso en consultas. Estas palabras clave te permiten acceder a los límites de tus buckets de tiempo:

• window_start: Es el límite inicial del intervalo.
• window_end: Es el límite de cierre del intervalo.

Restricciones de uso

• Requisito de coincidencia: Debes definir un período (by o over) en la sección match para usar estas palabras clave.
• Restricción de sección: Usa estas palabras clave en condition, order o outcome. No son válidos en la sección events.
• Espacio de nombres: No los uses como nombres de variables personalizadas (por ejemplo, $window_start).

Determina el tipo y la sintaxis de la ventana

Usa esta tabla como referencia rápida cuando determines qué tipo de ventana y sintaxis usar para tus reglas de detección.

Situación	Período recomendado	Palabras clave recomendadas	Ventaja principal
Detecciones de alta frecuencia (por ejemplo, ataques de fuerza bruta)	Ventana deslizante (over)	window_start, window_end	Se activa inmediatamente cuando se alcanza el umbral dentro de un período continuo.
Ausencia o inexistencia (por ejemplo, latidos cardíacos faltantes)	Ventana de saltos de tamaño constante (by)	window_start, window_end	Evalúa los bloques de tiempo fijos incluso si no se producen eventos, lo que evita errores de Variable Not Bounded.
Informes cronológicos	Deslizamiento o caída	order: window_start asc	Estandariza el resultado de las alertas para facilitar el análisis de la cronología en la IU de Chronicle.
Filtrado por período	Deslizamiento o caída	condition: window_start > "2026-01-01 00:00:00Z"	Limita la evaluación de la regla a fechas específicas con la coerción de marcas de tiempo de GoogleSQL.

Compara tipos de marcas de tiempo y zonas horarias

YARA-L admite la comparación de window_start y window_end directamente con cadenas en el formato de marca de tiempo de GoogleSQL. Esto te permite realizar un filtrado preciso sin necesidad de realizar una conversión de tipo manual.

Nota: Siempre especifica la hora UTC con el sufijo Z (por ejemplo, "2026-03-17T17:35:00Z") para alinearte con las marcas de tiempo de los eventos del UDM.

Usa filtros de marcas de tiempo para mejorar el rendimiento. Si solo necesitas confirmar que un evento ocurrió después de otro, una comparación de marcas de tiempo en la sección condition suele ser más eficiente: $e1.metadata.event_timestamp.seconds < $e2.metadata.event_timestamp.seconds.

Obtén más información sobre la sintaxis de la sección match y la sintaxis de la sección condition.

Ejemplos: window_end y window_start

• window_end < "2026-01-01T12:30:00Z" (fecha, hora y sufijo UTC)
• window_start != "2026-01-01 15:00:00+00" (con diferencia horaria UTC)

Si la comparación falla, verifica que tu cadena siga el formato canónico de marca de tiempo de GoogleSQL.

Ventanas de salto

Una ventana de salto crea intervalos de tiempo superpuestos para que no se pierdan los eventos que ocurren cerca de los límites de una ventana.

• Caso de uso: Es mejor para las detecciones en las que necesitas captar una situación específica, independientemente de cuándo comience o finalice exactamente el intervalo de la ventana.
• Compatibilidad: Se admite la agregación en la Búsqueda y los paneles.

Las consultas de YARA-L con una sección match usan ventanas de salto para correlacionar varios eventos a lo largo del tiempo. El sistema divide el intervalo de tiempo de la ejecución de la consulta en un conjunto de períodos fijos y superpuestos. Si bien especificas la duración de estas ventanas en la sección match, el sistema define el intervalo de superposición y la alineación de la ventana. Luego, los eventos se correlacionan dentro de cada una de estas ventanas predeterminadas.

Nota: Usa la ventana de salto, a menos que requieras una secuencia específica de eventos (primero el pedido A y, luego, el pedido B). Solo usa ventanas deslizantes cuando la secuencia de eventos sea fundamental o cuando busques eventos faltantes.

Obtén más información sobre la sintaxis de la sección match.

Las ventanas de salto tienen implicaciones específicas para las detecciones de reglas compuestas. Para obtener más información, consulta Reglas compuestas: intervalos de tiempo y ventanas de salto.

Ejemplo: Ventanas de tramo superpuestas para la correlación continua

En el siguiente ejemplo, se muestra una consulta que se ejecuta en el período [1:00, 2:00], con una sección match $user over 30m. Un posible conjunto de ventanas de salto superpuestas que genera el sistema es [1:00, 1:30], [1:03, 1:33] y [1:06, 1:36].

Regla

rule hop_window_brute_force_example {
meta:
  description = "Detects multiple failed logins within a shifting 30-minute window."
  severity = "Medium"

events:
  $login.metadata.event_type = "USER_LOGIN"
  $login.extensions.auth.auth_status = "FAILURE"
  $login.principal.user.userid = $user

match:
  // This creates the overlapping windows (e.g., 1:00-1:30, 1:03-1:33)
  $user over 30m

condition:
  // This will trigger if 10 or more failures fall into any single 30m hop
  #login >= 10
}

Buscar

metadata.event_type = "USER_LOGIN"
security_result.action = "FAIL"
principal.user.userid = $user

match:
  // This creates the overlapping windows (e.g., 1:00-1:30, 1:03-1:33)
  $user over 30m
  ```

Panel

metadata.event_type = "USER_LOGIN"
security_result.action = "FAIL"
principal.user.userid = $user

match:
  // This creates the overlapping windows (e.g., 1:00-1:30, 1:03-1:33)
  $user over 30m

Ejemplo: Correlación de varios eventos con una ventana de salto

En el siguiente ejemplo, se capturan eventos que ocurren dentro del mismo período general:

Regla

rule hop_window_example {
meta:
  description = "Detect a user with a failed login followed by a success within 30m"

events:
  // Event 1: Capture failed login attempts
  $fail.metadata.event_type = "USER_LOGIN"
  $fail.security_result.action = "FAIL"
  $fail.principal.user.userid = $user

  // Event 2: Capture successful login attempts
  $success.metadata.event_type = "USER_LOGIN"
  $success.security_result.action = "ALLOW"
  $success.principal.user.userid = $user

match:
  // Correlate events for the SAME $user within a rolling 30-minute window.
  $user over 30m

condition:
  // Ensure both a failed ($fail) and a successful ($success) login event occurred for the same user within the 30m window.
  $fail and $success
}

Buscar

// Event 1: Capture failed login attempts
metadata.event_type = "USER_LOGIN"
security_result.action = "FAIL"
principal.user.userid = $user // Assign user ID to a placeholder

// Event 2: Capture successful login attempts
metadata.event_type = "USER_LOGIN"
security_result.action = "ALLOW"
principal.user.userid = $user // Link to the same user placeholder

match:
  // Correlate events for the SAME $user within a rolling 30-minute window.
  $user over 30m

Panel

// Event 1: Capture failed login attempts
metadata.event_type = "USER_LOGIN"
security_result.action = "FAIL"
principal.user.userid = $user // Assign user ID to a placeholder

// Event 2: Capture successful login attempts
metadata.event_type = "USER_LOGIN"
security_result.action = "ALLOW"
principal.user.userid = $user // Link to the same user placeholder

match:
  // Correlate events for the SAME $user within a rolling 30-minute window.
  $user over 30m

Ejemplo: Comparación de ventanas de salto

Para identificar un intento de ataque de fuerza bruta, una ventana de 10m agrupa todas las fallas de USER_LOGIN. Luego, la condición evalúa si el recuento (#e) dentro de ese bucket específico de 10 minutos supera tu umbral.

Regla

rule failed_logins
{
meta:
  author = "Security Team"
  description = "Detects multiple failed user logins within 10-minute windows."
  severity = "HIGH"

events:
  $e.metadata.event_type = "USER_LOGIN"
  $e.security_result.action = "FAIL"
  $user = $e.target.user.userid

match:
  $user over 10m

condition:
  #e >= 5
}

Buscar

metadata.event_type = "USER_LOGIN"
security_result.action = "FAIL"
$user = target.user.userid

match:
  $user over 10m

Panel

metadata.event_type = "USER_LOGIN"
security_result.action = "FAIL"
$user = target.user.userid

match:
  $user over 10m

Ventanas de saltos de tamaño constante

Nota: Esta función está sujeta a las Condiciones de las Ofertas de Fase Previa a la DG de las Condiciones Específicas del Servicio de Google Security Operations. Las características de la fase previa a la DG pueden tener asistencia limitada, y es posible que los cambios en las características de la fase previa a la DG no sean compatibles con otras versiones de la fase previa a la DG. Para obtener más información, consulta los Lineamientos de los Servicios de Asistencia Técnica de Google SecOps y las Condiciones Específicas del Servicio de Google SecOps.
Si esta función no está visible en tu entorno, consulta Cómo administrar las funciones en versión preliminar o comunícate con tu administrador del sistema.

Nota: Esta función no está disponible para todos los clientes en todas las regiones.

Una ventana de saltos de tamaño constante segmenta los datos en intervalos de tiempo continuos, no superpuestos y de tamaño fijo. La marca de tiempo de cada evento se incluye en exactamente una ventana. No hay superposición entre las ventanas de saltos de tamaño constante. Esto contrasta con una ventana de salto o una ventana deslizante, que pueden tener intervalos de tiempo superpuestos.

Para implementar una ventana de saltos de tamaño constante, usa el operador by en la sección match. Las ventanas de saltos de tamaño constante dividen el tiempo en bloques continuos y consecutivos, por ejemplo:

• by 1h: Crea ventanas para cada hora (por ejemplo, [00:00:00-00:59:59], [01:00:00-01:59:59]).
• by 10m: Crea ventanas para cada intervalo de 10 minutos (por ejemplo, [00:00:00-00:09:59], [00:10:00-00:19:59]).

Casos de uso habituales

Usa ventanas de saltos de tamaño constante cuando necesites hacer lo siguiente:

• Analiza los eventos en bloques de tiempo distintos y sin superposiciones.
• Produce solo una detección para una entidad determinada (según lo definen las variables de coincidencia) dentro de cada intervalo de tiempo fijo, sin importar cuántas veces ocurra el evento.
• Recuento de entidades únicas en períodos fijos

Comportamiento de anulación de duplicación

Una característica clave de las ventanas de saltos de tamaño constante es la forma en que el motor controla las detecciones dentro de cada ventana para el mismo conjunto de variables de coincidencia:

• Una detección por ventana: Para un conjunto determinado de valores de las variables de coincidencia (por ejemplo, un $userid específico), el motor genera, como máximo, una detección para cualquier ventana de saltos de tamaño constante única.
• El primero que llega gana: Los primeros eventos transferidos que cumplen con las condiciones de la regla para ese conjunto de variables de coincidencia dentro de un período específico activan la detección.
• Eliminación de duplicados: Los eventos posteriores que coincidan con los criterios dentro de la misma instancia de la ventana no generarán detecciones adicionales.

Sintaxis

La sintaxis en la sección match es: match: $variable by <duration>

• $variable es la variable de marcador de posición con la que realizas la correlación.
• duration es un número seguido de una unidad de tiempo: m (minuto), h (hora), d (día).
• Especifica un mínimo de un minuto y un máximo de 72 horas o tres días.

Ejemplo: Agrupación por intervalos fijos

La siguiente regla agrupa los inicios de sesión por $userid en ventanas de 1 hora que no se superponen.

Regla

rule TumblingWindowExample {
meta:
  description = "Example using a 1-hour tumbling window"

events:
  $e.metadata.event_type = "USER_LOGIN"
  $e.principal.user.userid = $userid

match:
  $userid by 1h

condition:
  $e
}

Buscar

metadata.event_type = "USER_LOGIN"
principal.user.userid = $userid

match:
  $userid by 1h

Panel

metadata.event_type = "USER_LOGIN"
principal.user.userid = $userid

match:
  $userid by 1h

Ejemplo: Comportamiento de detección (usuario = "Alex")

• Evento 1: Alex accede a las 00:30. Esto se incluye en la ventana de [00:00:00-00:59:59]. El motor genera una detección para Alex en esta ventana.
• Evento 2: Otro usuario, "Taylor", accede a las 00:45. Esto también se incluye en [00:00:00-00:59:59], pero como el $userid es diferente, el motor genera una detección independiente para Taylor.
• Evento 3: Alex vuelve a acceder a las 00:40. Esto aún se encuentra dentro del período de [00:00:00-00:59:59]. Como ya existe una detección para Alex, este evento se anula. No se genera una detección nueva.
• Evento 4: Alex accede a las 1:20 a.m. Esto se incluye en el siguiente período, [01:00:00-01:59:59]. El motor genera una nueva detección para Alex.

Aunque el evento 1 y el evento 4 de Alex ocurrieron con menos de una hora de diferencia, se consideran detecciones separadas porque el evento 4 cruza el límite de la ventana fija.

Configura ventanas de saltos de tamaño constante para las detecciones de ausencia

Para generar una alerta sobre un recuento de cero y evitar errores del compilador, completa los siguientes pasos:

1. Identifica el objetivo de detección. Determina si buscas una alta frecuencia o una falta de actividad.
2. Selecciona la palabra clave window. Usa over para la frecuencia y by para la ausencia.
3. Límites de la ventana de referencia. Usa las palabras clave window_start y window_end para hacer referencia a los límites específicos del intervalo.

Contexto: Usa outcome: $ext_window_end = window_end para incluir la hora de finalización exacta de un latido perdido en los metadatos de la alerta.

Ejemplo: Detecta un latido faltante con metadatos

Las ventanas de saltos de tamaño constante te permiten generar alertas sobre un recuento de cero, lo que te ayuda a evitar errores del compilador cuando buscas falta de actividad.

Regla

rule missing_heartbeat_detection {
meta:
  description = "Alert when a system fails to check in within a 24h block"

events:
  $e.metadata.event_type = "STATUS_UPDATE"
  $host = $e.principal.hostname

match:
  $host by 24h  // Tumbling window lets you detect zero counts

outcome:
  $event_count = count($e.metadata.id)
  $missing_window_start = window_start
  $missing_window_end = window_end

condition:
  $event_count = 0 and window_start > "2026-01-01T12:30:00Z"
}

Buscar

metadata.event_type = "STATUS_UPDATE"
$host = principal.hostname

match:
  $host by 24h  // Tumbling window lets you detect zero counts

outcome:
  $event_count = count(metadata.id)
  $missing_window_start = window_start
  $missing_window_end = window_end

Panel

metadata.event_type = "STATUS_UPDATE"
$host = principal.hostname

match:
  $host by 24h  // Tumbling window lets you detect zero counts

outcome:
  $event_count = count(metadata.id)
  $missing_window_start = window_start
  $missing_window_end = window_end

Ventanas deslizantes

Una ventana deslizante se fija a un evento de pivote específico y mira hacia adelante (after) o hacia atrás (before).

Nota: Solo está disponible para las reglas y no es compatible con la Búsqueda ni los paneles.

Casos de uso habituales

Usa ventanas deslizantes cuando la secuenciación de eventos sea fundamental:

• Secuenciación estricta: Detecta una cadena de ataque (por ejemplo, e1 ocurre hasta dos minutos después de e2).
• Tiempo relativo: Busca un evento que ocurra dentro de un desplazamiento específico de un activador (por ejemplo, un Network Connection dentro de los 30 segundos posteriores a un Process Start).
• Detección de ausencia: Identifica cuándo no se produce un evento obligatorio de "limpieza" o "latido" después de un evento de inicio.

Sintaxis

match: <grouping_keys> over <duration> [before|after] <$pivot_event>

Componente	Descripción	Ejemplo
Claves de agrupación	Son campos comunes que se usan para vincular eventos.	$host, $user
Duración	Es la compensación de tiempo desde el evento de pivote.	5m, 1h, 30s
Dirección	Indica si la ventana se extiende hacia adelante o hacia atrás.	after, before
Evento de pivote	Es la variable del evento que ancla la ventana.	$proc, $alert

Los siguientes son ejemplos de ventanas deslizantes válidas:

• $var1, $var2 over 5m after $e1
• $user over 1h before $e2
• $host, $ip over 1h before $e2

Requisitos y limitaciones

• Rendimiento: Las ventanas deslizantes requieren más potencia de procesamiento que las ventanas de salto. Úsalos solo cuando el orden de los eventos sea estrictamente necesario (por ejemplo, cuando un evento debe ocurrir dentro de los cinco minutos posteriores a otro evento).
• Consultas de un solo evento: No uses ventanas deslizantes para la lógica de un solo evento. En su lugar, usa varias variables de evento en la sección condition.

Ejemplo: Correlación prospectiva (after)

Regla

rule sliding_window_after_example {
meta:
  description = "Detect a network connection occurring within 1 minute after a suspicious process launch."
  severity = "High"

events:
  $proc.metadata.event_type = "PROCESS_LAUNCH"
  $proc.principal.hostname = $host

  $net.metadata.event_type = "NETWORK_HTTP"
  $net.principal.hostname = $host

match:
  // $proc is the pivot; the 1-minute window starts at the $proc timestamp
  $host over 1m after $proc

condition:
  $proc and $net
}

Buscar

after no es compatible con la Búsqueda.

Panel

after no es compatible con los paneles.

Ejemplo: Correlación retrospectiva (before)

Usa una ventana deslizante de "before" para investigar la actividad que llevó a una alerta específica. Esto se suele usar en el análisis de causa raíz para identificar lo que sucedió inmediatamente antes de una detección crítica.

Regla

rule sliding_window_before_example {
meta:
  description = "Identify file modifications occurring in the 5 minutes before a ransomware alert."
  severity = "Critical"

events:
  $file.metadata.event_type = "FILE_MODIFICATION"
  $file.principal.hostname = $host

  $alert.metadata.event_type = "ANTIVIRUS_DETECTION"
  $alert.metadata.product_name = "Premium_AV"
  $alert.principal.hostname = $host

match:
  // $alert is the pivot; the 5-minute window ends at the $alert timestamp
  $host over 5m before $alert

condition:
  $file and $alert
}

Buscar

before no es compatible con la Búsqueda.

Panel

before no es compatible con los paneles.

Soluciona problemas

Usa esta sección para comprender la latencia, los límites y las correcciones de los problemas comunes de ventana en YARA-L.

Latencia y límites

• Las reglas que usan ventanas de saltos de tamaño constante (by) solo se activan al final del período fijo. Por ejemplo, una regla con match: $user by 24h solo se evalúa una vez que transcurre por completo el período de 24 horas.

• Latencia de las alertas: Las reglas que usan by (tumbling) solo se activan después de que transcurre el período fijo. Una regla de by 24h no generará alertas a mitad de la ventana.

• Incongruencia en la IU: En la Búsqueda y los paneles, la palabra clave window_start hace referencia directamente al campo TIME_BUCKET. Cuando filtras o agrupas por window_start, el encabezado de la columna se muestra como TIME_BUCKET en la IU.Esta es una limitación conocida de la IU, pero tu lógica sigue siendo válida.

Corrección de errores

Código de error	Descripción	Corregir
Variable Not Bounded	La regla usa over (ventana deslizante) con una condición $count = 0.	Cambia la palabra clave de ventana a by (ventana de saltos de tamaño constante). Las ventanas deslizantes requieren que exista un evento para anclarlas, mientras que las ventanas de saltos de tamaño constante no.
Discrepancia en el encabezado de la IU	El usuario ve TIME_BUCKET en la IU en lugar de window_start.	No se requiere ninguna corrección. La lógica de filtrado y ordenamiento sigue funcionando correctamente con las palabras clave.
Identificador desconocido: window_start	Se usa la palabra clave, pero no se define ninguna ventana en match.	Agrega una declaración de ventana a tu sección match (por ejemplo, $hostname by 1h).
Uso no válido de window_start en los eventos	Se hace referencia a la palabra clave en la sección events.	Mueve la lógica a la sección condition o outcome. Los límites de la ventana se calculan solo después de que los eventos se agrupan en la fase de coincidencia.

¿Qué sigue?

• Biblioteca de referencia de consultas de YARA-L 2.0
• Sintaxis de la sección match
• Sintaxis de la sección condition

¿Necesitas más ayuda? Obtén respuestas de miembros de la comunidad y profesionales de Google SecOps.