Crea consultas de varias etapas

Compatible con:

En este documento, se describe cómo las consultas de varias etapas en YARA-L te permiten ingresar el resultado de una etapa de la consulta directamente en la entrada de una etapa posterior. Este proceso te brinda un mayor control sobre la transformación de datos que una sola consulta monolítica.

Integrar consultas de varias etapas con funciones existentes

Las consultas de varias etapas funcionan en conjunto con las siguientes funciones existentes en Google Security Operations:

  • Reglas de detección compuestas: Las consultas de varias etapas complementan las reglas de detección compuestas, ya que cierran la brecha entre la detección automatizada y la investigación activa. Si bien las reglas compuestas son excelentes para identificar correlaciones complejas de varios eventos en períodos prolongados, las consultas de varias etapas permiten a los analistas pasar de esas detecciones a búsquedas iterativas en tiempo real para validar y delimitar instantáneamente una amenaza en desarrollo.

  • Períodos y reglas de varios eventos: Puedes usar consultas de varias etapas para detectar anomalías comparando diferentes períodos dentro de tus datos. Por ejemplo, puedes usar tus búsquedas iniciales para establecer un valor de referencia durante un período prolongado y, luego, usar búsquedas posteriores para evaluar la actividad reciente en comparación con ese valor de referencia. También puedes usar reglas de varios eventos para crear un tipo de comparación similar.

Las consultas de varias etapas en YARA-L son compatibles con los paneles y la búsqueda.

Las uniones ayudan a correlacionar datos de varias fuentes para proporcionar más contexto para una investigación. Al vincular eventos, entidades y otros datos relacionados, puedes investigar situaciones de ataque complejas. Para obtener más información, consulta Cómo usar las uniones en la Búsqueda.

Consideraciones clave

A medida que configures una consulta de varias etapas, ten en cuenta lo siguiente:

  • Etapa de límite: Las consultas de varias etapas deben contener entre una y cuatro etapas con nombre, además de la etapa raíz.
  • Sintaxis de orden: Siempre define la sintaxis de la etapa con nombre antes de definir la sintaxis de la etapa raíz.

Te recomendamos que revises los siguientes problemas conocidos y las soluciones alternativas recomendadas cuando implementes consultas de varias etapas:

  • Todas las consultas de varias etapas se comportan como consultas de búsqueda de estadísticas (el resultado consta de estadísticas agregadas en lugar de eventos sin agregar o filas de tablas de datos).

  • El rendimiento de las combinaciones con eventos de UDM y de entidades en un lado puede ser bajo debido al tamaño de ese conjunto de datos. Te recomendamos que filtres los eventos de UDM y de entidades del lado de la unión tanto como sea posible (por ejemplo, filtra por tipo de evento).

Para obtener orientación general sobre las prácticas recomendadas, consulta Prácticas recomendadas de YARA-L 2.0 y, para obtener información específica sobre las uniones, consulta Prácticas recomendadas.

Terminología clave

En el contexto de las uniones, una etapa con ventanas se refiere a una etapa con una sección match que contiene una ventana. En cambio, una etapa de tabla no genera ventanas.

Crea una consulta de YARA-L de varias etapas

Para crear una consulta de YARA-L de varias etapas, completa los siguientes pasos.

Estructura y sintaxis de la etapa

Ve a Investigación > Búsqueda. Sigue esta estructura cuando definas las etapas de tu búsqueda:

Sintaxis: Usa la siguiente sintaxis para nombrar cada etapa y separarla de otras etapas:

stage <stage name> { }

  • Llaves: Coloca toda la sintaxis de la etapa dentro de llaves {}.

  • Orden: Define la sintaxis para todas las etapas con nombre antes de definir la etapa raíz.

  • Referencias: Cada etapa puede hacer referencia a etapas definidas anteriormente en la consulta.

  • Etapa raíz: Una búsqueda debe tener una etapa raíz, que se procesa después de todas las etapas con nombre.

La siguiente etapa de ejemplo, daily_stats, recopila estadísticas diarias de la red:

stage daily_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $source = principal.hostname
  $target = target.ip
  $source != ""
  $target != ""
  match:
    $source, $target by day
  outcome:
    $exchanged_bytes = sum(network.sent_bytes + network.received_bytes)
}

Cómo acceder a la salida de la etapa

Se puede acceder al resultado de una etapa con nombre en etapas posteriores a través de los campos de etapa. Los campos de etapa corresponden a las variables match y outcome de la etapa, y se pueden usar de manera similar a los campos del modelo de datos unificado (UDM).

Usa la siguiente sintaxis para acceder a un campo de etapa:

$<stage name>.<variable name>

Opcional: Accede a las marcas de tiempo de las ventanas

Si una etapa con nombre usa una ventana de salto, deslizante o ventana de saltos de tamaño constante, accede al inicio y al final de la ventana para cada fila de salida con estos campos reservados:

  • $<stage name>.window_start

  • $<stage name>.window_end

window_start y window_end son campos de números enteros expresados en segundos desde la época de Unix. Las ventanas en diferentes etapas pueden variar en tamaño.

Ejemplos de consultas de varias etapas

Los ejemplos de esta sección ayudan a ilustrar cómo puedes crear una consulta de YARA-L completa de varias etapas.

Ejemplo: Buscar conexiones de red inusualmente activas (horas)

En este ejemplo de YARA-L de varias etapas, se identifican pares de direcciones IP con actividad de red superior a la normal, y se segmentan los pares que mantienen una actividad alta durante más de tres horas. La consulta incluye dos componentes obligatorios: la etapa con nombre, hourly_stats, y la etapa root.

La etapa hourly_stats busca pares de principal.ip y target.ip con altos niveles de actividad de red.

Esta etapa devuelve un solo valor por hora para los siguientes campos:

  • Estadísticas de la IP de origen (cadena): $hourly_stats.src_ip

  • Estadísticas de la IP de destino (cadena): $hourly_stats.dst_ip

  • Estadísticas para el recuento de eventos (número entero): $hourly_stats.count

  • Desviación estándar de los bytes recibidos (número de punto flotante): $hourly_stats.std_recd_bytes

  • Promedio de bytes recibidos (número de punto flotante): $hourly_stats.avg_recd_bytes

  • Hora de inicio del intervalo horario en segundos desde la época de Unix (número entero): $hourly_stats.window_start

  • Hora de finalización del intervalo horario en segundos desde la época de Unix (número entero): $hourly_stats.window_end

La etapa raíz procesa el resultado de la etapa hourly_stats. Calcula estadísticas para los pares principal.ip y target.ip con actividad que supera el umbral especificado por $hourly_stats. Luego, filtra los pares con más de tres horas de actividad alta.


stage hourly_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $src_ip = principal.ip
  $dst_ip = target.ip
  $src_ip != ""
  $dst_ip != ""

  match:
    $src_ip, $dst_ip by hour

  outcome:
    $count = count(metadata.id)
    $avg_recd_bytes = avg(network.received_bytes)
    $std_recd_bytes = stddev(network.received_bytes)

  condition:
    $avg_recd_bytes > 100 and $std_recd_bytes > 50
}

$src_ip = $hourly_stats.src_ip
$dst_ip = $hourly_stats.dst_ip
$time_bucket_count = strings.concat(timestamp.get_timestamp($hourly_stats.window_start), "|", $hourly_stats.count)

match:
 $src_ip, $dst_ip

outcome:
 $list = array_distinct($time_bucket_count)
 $count = count_distinct($hourly_stats.window_start)

condition:
 $count > 3

Si modificas la condición de coincidencia en la etapa raíz de la siguiente manera, puedes introducir una agregación con ventanas por día para la consulta de varias etapas.

match:
 $src_ip, $dst_ip by day

Ejemplo: Busca conexiones de red inusualmente activas (con la puntuación Z)

Esta consulta de varias etapas compara la actividad de red promedio diaria con la actividad de hoy usando un cálculo de la puntuación Z (que mide la cantidad de desviaciones estándar con respecto a la media). Esta consulta busca de manera eficaz actividad de red inusualmente alta entre los activos internos y los sistemas externos.

Condición previa: El período de la consulta debe ser mayor o igual a 2 días y debe incluir el día actual para que la puntuación Z calculada sea efectiva.

Esta consulta de varias etapas incluye la etapa daily_stats y la etapa root, que trabajan en conjunto para calcular la puntuación Z de la actividad de la red:

  • La etapa daily_stats realiza la agregación diaria inicial. Calcula el total de bytes intercambiados cada día para cada par de IPs (source y target) y devuelve los siguientes campos de etapa (que corresponden a las columnas de las filas de salida):

    • $daily_stats.source: singular, cadena
    • $daily_stats.target: singular, cadena
    • $daily_stats.exchanged_bytes: Singular, número entero
    • $daily_stats.window_start: Singular, número entero
    • $daily_stats.window_end: Singular, número entero

  • La etapa raíz agrega el resultado de la etapa daily_stats para cada par de IP. Calcula el promedio y la desviación estándar de los bytes diarios intercambiados en todo el rango de búsqueda, junto con los bytes intercambiados hoy. Utiliza esos tres valores calculados para determinar la puntuación Z.

  • En el resultado, se muestran las puntuaciones Z de todos los pares de IP de hoy, ordenadas de forma descendente.

// Calculate the total bytes exchanged per day by source and target

stage daily_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $source = principal.hostname
  $target = target.ip
  $source != ""
  $target != ""

  match:
    $source, $target by day

  outcome:
    $exchanged_bytes = sum(network.sent_bytes + network.received_bytes)
}

// Calculate the average per day over the time window and compare with the bytes exchanged today

$source = $daily_stats.source
$target = $daily_stats.target
$date = timestamp.get_date($daily_stats.window_start)

match:
  $source, $target

outcome:
  $today_bytes = sum(if($date = timestamp.get_date(timestamp.current_seconds()), cast.as_int($daily_stats.exchanged_bytes), 0))
  $average_bytes = window.avg($daily_stats.exchanged_bytes)
  $stddev_bytes = window.stddev($daily_stats.exchanged_bytes)
  $zscore = ($today_bytes - $average_bytes) / $stddev_bytes

order:
  $zscore desc

Cómo exportar variables sin agregar de etapas

En una consulta típica de varias etapas, los datos suelen pasar entre las etapas a través de un proceso de agregación, que puede "colapsar" varios eventos en un solo resumen. Sin embargo, hay situaciones en las que necesitas conservar los detalles específicos de cada evento, como un ID de proceso único o una línea de comandos específica, sin perder esa granularidad. Para admitir esto, puedes exportar variables directamente sin una función de agrupación.

Las etapas con nombre pueden incluir una sección outcome sin agregar. Esto significa que las variables definidas dentro de esa sección outcome se generan directamente desde la etapa, lo que permite que las etapas posteriores accedan a ellas como campos de etapa sin requerir una agregación agrupada.

Este detalle es beneficioso porque hace lo siguiente:

  • Conserva la fidelidad de los datos: Puedes pasar los atributos exactos de un evento (por ejemplo, una ruta de acceso de archivo específica) a la siguiente etapa sin tener que usar una agregación artificial de "marcador de posición" como max() o array_distinct().
  • Reduce la complejidad de las consultas: Simplifica tu lógica de YARA-L, ya que elimina la necesidad de una sección match o de agrupar instrucciones solo para transportar un valor de la etapa 1 a la etapa 2.
  • Optimiza el rendimiento: Al omitir el motor de agregación, el sistema puede transmitir datos entre etapas de manera más eficiente, lo que genera tiempos de ejecución más rápidos para las búsquedas complejas y de gran volumen.

Ejemplo: Exporta una variable sin agregar

En este ejemplo, se muestra cómo exportar variables sin agregar. Ten en cuenta la siguiente lógica:

  • La etapa top_5_bytes_sent busca los cinco eventos con la mayor actividad de red.

  • La etapa top_5_bytes_sent genera los siguientes campos de etapa que corresponden a las columnas de las filas de salida:

    • $top_5_bytes_sent.bytes_sent: Singular, número entero
    • $top_5_bytes_sent.timestamp_seconds: Singular, número entero

  • La etapa root calcula las marcas de tiempo más recientes y más antiguas para los cinco eventos con la mayor actividad de red.

stage top_5_bytes_sent {
  metadata.event_type = "NETWORK_CONNECTION"
  network.sent_bytes > 0

  outcome:
    $bytes_sent = network.sent_bytes
    $timestamp_seconds = metadata.event_timestamp.seconds

  order:
    $bytes_sent desc

  limit:
    5
}

outcome:
  $latest_timestamp = timestamp.get_timestamp(max($top_5_bytes_sent.timestamp_seconds))
  $earliest_timestamp = timestamp.get_timestamp(min($top_5_bytes_sent.timestamp_seconds))

Implementa el sistema de ventanas en consultas de varias etapas

En las detecciones de varias etapas, el encuadre te permite definir límites de tiempo específicos para la correlación de eventos dentro de una etapa. Si particionas los datos en buckets temporales discretos, como una ventana deslizante de 5 minutos o una ventana de saltos de tamaño constante de 1 hora, puedes identificar patrones como ataques de fuerza bruta o comportamiento de balizas que solo se hacen visibles cuando se analizan como una secuencia limitada por el tiempo.

Las consultas de varias etapas admiten todos los tipos de ventanas (salto, deslizamiento y rotación) en etapas con nombre. Esto te ayuda a pasar datos contextualizados en el tiempo entre etapas, por ejemplo, usar la etapa 1 para identificar una ventana de eventos de alta frecuencia y la etapa 2 para correlacionar esa ventana específica con acciones administrativas posteriores.

Si una etapa con nombre incluye una ventana, se puede acceder al inicio y al final de la ventana para cada fila de salida con los siguientes campos reservados:

  • $stage_window_start: Es la marca de tiempo de Unix que indica el comienzo del período.
  • $stage_window_end: Es la marca de tiempo de Unix que marca el final del período.

Para obtener más detalles sobre las ventanas, consulta Lógica de ventanas de YARA-L 2.0.

Casos de uso habituales

  • Detección secuencial: Se pasa el período específico de un aumento detectado en los accesos fallidos a una segunda etapa que busca un acceso exitoso poco después.
  • Análisis de duración: Se calcula el "tiempo hasta la vulneración" comparando el $stage_window_start de una etapa inicial de explotación con las marcas de tiempo de los eventos en una etapa posterior.
  • Comparación histórica con el valor de referencia: Se usan ventanas para comparar los recuentos de eventos actuales con las variables de salida de una ventana anterior.

Ejemplo: Ventana de salto

En el siguiente ejemplo, se ilustra cómo podrías usar ventanas de salto en una consulta de varias etapas:

  • La etapa hourly_stats busca pares de IP que tengan una alta actividad de red en la misma hora.

  • hourly_stats genera los siguientes campos de etapa que corresponden a las columnas de las filas de salida:

    • $hourly_stats.src_ip: singular, cadena
    • $hourly_stats.dst_ip: singular, cadena
    • $hourly_stats.count: Singular, número entero
    • $hourly_stats.std_recd_bytes: Singular, número de punto flotante
    • $hourly_stats.avg_recd_bytes: Singular, número de punto flotante
    • $hourly_stats.window_start: Singular, número entero
    • $hourly_stats.window_end: Singular, número entero

  • La etapa raíz filtra los pares de IP con más de 3 horas de actividad alta. Las horas podrían superponerse debido al uso de una ventana de salto en la etapa hourly_stats.

stage hourly_stats {
  metadata.event_type = "NETWORK_CONNECTION"
  $src_ip = principal.ip
  $dst_ip = target.ip
  $src_ip != ""
  $dst_ip != ""

  match:
    $src_ip, $dst_ip over 1h

  outcome:
    $count = count(metadata.id)
    $avg_recd_bytes = avg(network.received_bytes)
    $std_recd_bytes = stddev(network.received_bytes)

  condition:
    $avg_recd_bytes > 100 and $std_recd_bytes > 50
}

$src_ip = $hourly_stats.src_ip
$dst_ip = $hourly_stats.dst_ip
$time_bucket_count = strings.concat(timestamp.get_timestamp($hourly_stats.window_start), "|", $hourly_stats.count)

match:
 $src_ip, $dst_ip

outcome:
 $list = array_distinct($time_bucket_count)
 $count = count_distinct($hourly_stats.window_start)

condition:
 $count > 3

Uniones internas en consultas de varias etapas

Las uniones internas te permiten correlacionar datos en diferentes etapas o tipos de fuentes, lo que crea flujos de trabajo analíticos complejos, como comparar eventos en tiempo real con valores de referencia estadísticos precalculados. Al unir etapas, puedes enriquecer la telemetría sin procesar con datos con estado (como medianas o tablas de búsqueda) para identificar valores atípicos o amenazas de varios vectores que un filtro de eventos de una sola etapa no detectaría.

Las uniones internas se admiten dentro de las etapas de las consultas de varias etapas y entre ellas. La funcionalidad de unión interna admite los siguientes tipos:

  • UDM y UDM: Correlaciona dos conjuntos diferentes de eventos de seguridad (por ejemplo, correlaciona un evento de acceso con un acceso posterior a un archivo).
  • UDM y ECG: Combinación de datos de eventos con información del Entity Context Graph para el enriquecimiento de identidades o recursos
  • UDM y tabla de datos: Unión de eventos en vivo con listas de referencia estáticas o subidas (por ejemplo, una lista de recursos valiosos o rangos de IP específicos del departamento)

En el siguiente ejemplo, se muestra cómo configurar una unión sin coincidencias (una unión que se realiza en la sección outcome o events en lugar de la sección match) entre los eventos del UDM y una etapa de tabla calculada. Este patrón te permite realizar la detección de anomalías estadísticas, como se muestra en el siguiente cálculo de la desviación absoluta media (MAD):

  • Etapa median: Calcula la mediana de los bytes enviados para cada par de host de origen y dirección IP de destino.
    • $median.host: singular, cadena
    • $median.target: singular, cadena
    • $median.median: Singular, número de punto flotante
  • Etapa absolute_deviations: Une cada evento del UDM con la fila correspondiente de la etapa de la mediana. Esto te permite calcular la desviación absoluta de los bytes enviados para cada evento individual en relación con su grupo de empresas similares.
    • $absolute_deviations.host: singular, cadena
    • $absolute_deviations.target: singular, cadena
    • $absolute_deviations.absolute_deviation: Singular, número de punto flotante
  • Etapa raíz: Calcula la media de esas desviaciones absolutas en todos los eventos del UDM para establecer un umbral de anomalía.

Ejemplo: Configura una unión sin coincidencias

stage median {
  metadata.event_type = "NETWORK_CONNECTION"
  $host = principal.hostname
  $target = target.ip

  match:
    $host, $target

  outcome:
    $median = window.median(network.sent_bytes, true)
}

stage absolute_deviations {
  metadata.event_type = "NETWORK_CONNECTION"
  $join_host = principal.hostname
  $join_host = $median.host
  $join_target = target.ip[0]
  $join_target = $median.target

  outcome:
    $host = $join_host
    $target = $join_target
    $absolute_deviation = math.abs(network.sent_bytes - $median.median)
}

$host = $absolute_deviations.host
$target = $absolute_deviations.target

match:
  $host, $target

outcome:
  $mean_absolute_deviation = avg($absolute_deviations.absolute_deviation)

Ejemplo: Unión sin coincidencias entre la etapa de ventana y la etapa de tabla

En el siguiente ejemplo, se ilustra cómo configurar una unión sin coincidencias entre una etapa con ventanas y una etapa de tabla en una consulta de varias etapas.

  • La etapa hourly_stats calcula la cantidad total de bytes enviados para cada par de host de origen y destino, y para cada bucket de horas.
  • La etapa hourly_stats genera los siguientes campos de etapa que corresponden a las columnas de las filas de salida:
    • $hourly_stats.source_host: singular, cadena
    • $hourly_stats.dst_host: singular, cadena
    • $hourly_stats.total_bytes_sent: Singular, número de punto flotante
    • $hourly_stats.window_start: Singular, número entero
    • $hourly_stats.window_end: Singular, número entero
  • La etapa agg_stats calcula la desviación estándar y el promedio de bytes por hora para cada par de host de origen y destino.

  • agg_stats genera los siguientes campos de etapa que corresponden a las columnas de las filas de salida:

    • $agg_stats.source_host: singular, cadena
    • $agg_stats.dst_host: singular, cadena
    • $agg_stats.avg_bytes_sent: Singular, número de punto flotante
    • $agg_stats.stddev_bytes_sent: Singular, número de punto flotante

  • La etapa raíz une cada fila de hourly_stats con la fila de agg_stats para el mismo par de host de origen y destino. Para cada par de host de origen y destino, calcula la puntuación Z con los bytes totales enviados para ese bucket de par de hosts y las estadísticas agregadas.

stage hourly_stats {
 $source_host = principal.hostname
 $dst_host = target.hostname
 principal.hostname != ""
 target.hostname != ""
 match:
   $source_host, $dst_host by hour
 outcome:
   $total_bytes_sent = sum(network.sent_bytes)
}

stage agg_stats {
  $source_host = $hourly_stats.source_host
  $dst_host = $hourly_stats.dst_host
  match:
    $source_host, $dst_host
  outcome:
   $avg_bytes_sent = avg($hourly_stats.total_bytes_sent)
   $stddev_bytes_sent = stddev($hourly_stats.total_bytes_sent)
}

$source_host = $agg_stats.source_host
$source_host = $hourly_stats.source_host

$dst_host = $agg_stats.dst_host
$dst_host = $hourly_stats.dst_host

outcome:
  $hour_bucket = timestamp.get_timestamp($hourly_stats.window_start)
  $z_score = ($hourly_stats.total_bytes_sent - $agg_stats.avg_bytes_sent)/$agg_stats.stddev_bytes_sent

CROSS JOIN en consultas de varias etapas

Cuando usas la Búsqueda o los paneles de Google SecOps, las combinaciones cruzadas en las consultas de varias etapas te permiten comparar los datos de eventos individuales del UDM con las estadísticas agregadas que se calculan en otras etapas de YARA-L.

En YARA-L, la palabra clave cross join funciona con una etapa que devuelve solo una fila.

Cuando se usa una unión cruzada entre una etapa con un límite de 1 y otro conjunto de datos (por ejemplo, eventos del UDM), la fila única de resultado de la etapa se agrega a cada fila del otro conjunto de datos. Esto enriquece los datos del evento con las estadísticas generales.

Ejemplo: Cómo encontrar actividad de acceso inusual

En el siguiente ejemplo, se identifican los usuarios que acceden con más frecuencia de lo normal. Para ello, compara el recuento de inicios de sesión de cada usuario (con la etapa user_login_counts) con el recuento promedio de inicios de sesión de todos los usuarios (con la etapa total_users). Los usuarios que acceden una cantidad inusual de veces se pueden ordenar en los resultados de la búsqueda.

Luego, usas la palabra clave de unión cruzada para vincular los resultados de la etapa total_users con los resultados de la etapa user_login_counts.

stage user_login_counts {
    $user = principal.user.userid
    metadata.event_type = "USER_LOGIN"
    security_result.action = "ALLOW"

    match:
        $user

    outcome:
        $login_count = count(metadata.id)
}

stage total_users {
    outcome:
        $count = count($user_login_counts.user)
    limit:
        1
}

cross join $total_users, $user_login_counts

$login_count = $user_login_counts.login_count
$user = $user_login_counts.user
$tot_users = $total_users.count

// all users who logged in the same number of times are grouped together.
match:
    $login_count
outcome:
    $num_users = count($user)
    $frequency_percent = (count($user) / max($tot_users) ) * 100

Limitaciones

Las consultas de varias etapas tienen las siguientes restricciones funcionales y estructurales:

Requisitos estructurales

Debes seguir estos requisitos estructurales cuando compiles tus búsquedas:

  • Etapa raíz: Solo se permite una etapa raíz por búsqueda.
  • Etapas con nombre: Se admiten hasta cuatro etapas con nombre.
  • Referencia de etapas: Una etapa solo puede hacer referencia a etapas definidas lógicamente antes que ella en la misma consulta.
  • Uniones cruzadas: Una unión cruzada solo puede hacer referencia a una etapa que muestre una sola fila. Para cumplir con este requisito, debes incluir un límite (1) en la etapa a la que se hace referencia. Esto es beneficioso porque te permite agregar una sola estadística global (como un máximo o un promedio) a cada fila de eventos individuales para compararlas.
  • Uniones: Se permite un máximo de cuatro uniones que no sean de tablas de datos en todas las etapas.
  • Requisito de resultado: Cada etapa con nombre (excepto la etapa raíz) debe incluir una sección match o una sección outcome en la que esta última no requiera agregación.outcome

Límites de ventanas y compatibilidad

Se aplican las siguientes restricciones a la forma en que usas las ventanas y dónde ejecutas las consultas:

  • Compatibilidad con funciones: Las consultas de varias etapas funcionan en la Búsqueda y en los paneles, pero la función no es compatible con las reglas.
  • Tipos de ventanas: Evita mezclar diferentes tipos de ventanas en una sola búsqueda.
  • Dependencia de ventana: Una etapa que usa una ventana deslizante o de salto no puede depender de otra etapa que también use una ventana deslizante o de salto.
  • Tamaño de la ventana de saltos de tamaño constante: Si bien las ventanas de saltos de tamaño constante en diferentes etapas pueden variar en tamaño, la diferencia de tamaño debe ser inferior a 720x.

Ejemplo: Diferencia de agregación de la etapa (no válida)

La siguiente configuración no es válida porque un mes contiene 44,640 minutos (44,640 / 1 > 720):

Etapa: monthly_stats { ... match: by month }

Raíz: match: by minute

Ejemplo: Diferencia de agregación por etapa (válida)

Para corregir este problema, asegúrate de que la proporción entre las etapas sea menor. Por ejemplo, agrega datos por hora en un informe diario:

Etapa: daily_stats { ... match: by day }

Raíz: match: by hour

Dado que 24 (horas en un día) es menor que 720, el sistema puede asignar de manera eficiente los datos de la etapa a la etapa raíz.

Limitaciones de las etapas y las búsquedas

Cada etapa individual dentro de una consulta de varias etapas tiene restricciones específicas. La mayoría de las limitaciones que se aplican a una consulta de una sola etapa también se aplican a cada etapa individual:

  • Requisito de salida: Cada etapa debe generar al menos una variable de coincidencia o resultado (campo de etapa).

  • Intervalo de tiempo de la búsqueda:

    • Búsquedas estándar: El máximo es de 30 días.
    • Consultas de varias etapas con uniones sin coincidencias: El máximo se restringe a 14 días.

  • Límites de tamaño de la ventana: El tamaño máximo de la ventana (salto, deslizamiento o rotación) depende de si la consulta incluye una unión:

    • Con uniones: El tamaño máximo de la ventana para cualquier tipo (salto, deslizamiento o rotación) es de 2 días. Para obtener más detalles, consulta las limitaciones de las combinaciones de búsqueda.

    • Sin uniones (un solo evento):

    • Ventanas deslizantes y de salto: El máximo es de 2 días.

    • Ventanas continuas: El máximo aumenta a 30 días.

  • Cantidad máxima de variables de resultado:

    • 20 de forma predeterminada
    • 50 para los clientes que habilitaron el límite más grande
    • Límites de arrays: Se permite un máximo de 10,000 elementos en una variable de resultado con valores de array.

  • Restricciones de eventos por búsqueda:

    • Máximo de dos eventos de UDM
    • Máximo de un evento de ECG
    • Un máximo de dos tablas de datos

Límites de servicio y rendimiento

Las consultas de varias etapas están sujetas a las mismas limitaciones que las consultas de estadísticas:

  • Consultas de estadísticas: 120 QPH (API y IU).
  • Vistas de búsqueda: 100 vistas por minuto
  • Compatibilidad con la API: El sistema Google SecOps y la API de EventService.UDMSearch admiten uniones de varias etapas, pero la API de SearchService.UDMSearch no. El sistema también te permite ejecutar consultas de varias etapas sin uniones.

Limitaciones globales y de eventos

Debes cumplir con estos límites a nivel del evento y de la plataforma:

Cantidad máxima de eventos

Las consultas de varias etapas limitan estrictamente la cantidad de eventos que pueden procesar de forma simultánea:

  • Eventos de UDM: Se permite un máximo de 2 eventos de UDM.
  • Eventos del gráfico de contexto de entidades (ECG): Se permite un máximo de un evento del ECG.

Limitaciones de las consultas globales

Estas restricciones en toda la plataforma controlan qué tan atrás y cuántos datos devuelve una consulta de varias etapas:

  • Intervalo de tiempo de la consulta: El intervalo máximo de tiempo para una consulta estándar es de 30 días.
  • Conjunto de resultados total: El tamaño máximo del conjunto de resultados total es de 10,000 resultados.

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