Aplica uniones en la búsqueda y los paneles

Se admite en los siguientes sistemas operativos:

Las uniones ayudan a correlacionar datos de varias fuentes para proporcionar más contexto a una investigación. Al vincular eventos, entidades y otros datos relacionados, puedes investigar situaciones de ataque complejas y visualizar tendencias.

En este documento, se explica cómo usar la operación de unión en el campo de búsqueda y los paneles del tablero de Google SecOps. En él, se abordan los tipos de unión admitidos, los casos de uso y las prácticas recomendadas.

Conceptos básicos de las uniones

Puedes crear una unión conectando fuentes de datos con variables de marcador de posición compartidas o instrucciones de igualdad explícitas (por ejemplo, $e1.hostname = $e2.hostname). Cuando defines una unión en la sección match de una consulta basada en estadísticas, debes usar variables de marcador de posición.

En los siguientes ejemplos, se muestra cómo vincular fuentes de datos con dos campos que incluyen un signo igual (=) y una variable de marcador de posición compartida.

  • Ejemplo 1: Unión implícita con variables de marcador de posición

    events:
  // Assign a value from the first event to the placeholder variable $user
  $user = $e1.principal.user.userid

  // The second assignment creates an implicit join, linking $e2 to $e1
  // where the user ID is the same.
  $user = $e2.principal.user.userid

match:
  $user over 1h

condition:
  $e1 and $e2

  • Ejemplo 2: Unión explícita con igualdad y marcadores de posición

    $e1.principal.ip = $ip
$e1.metadata.event_type = "USER_LOGIN"
$e1.principal.hostname = $host

$e2.target.ip = $ip
$e2.principal.hostname = "altostrat"
$e2.target.hostname = $host

match:
  $ip, $host over 5m

En los ejemplos de esta sección, se muestra la sintaxis que se usa en la Búsqueda.

De forma predeterminada, las búsquedas en Search no distinguen mayúsculas de minúsculas.

Unión de evento a evento

  • Una unión de evento a evento conecta dos eventos diferentes del modelo universal de datos (UDM). En el siguiente ejemplo de consulta, se vincula un evento USER_LOGIN con otro evento para encontrar el nombre de host (altostrat) con el que interactuó el usuario, según una dirección IP común:

    $e1.principal.ip = $ip
$e1.metadata.event_type = "USER_LOGIN"

$e2.target.ip = $ip
$e2.principal.hostname = "altostrat"

match:
  $ip over 5m

Unión de eventos y ECG

  • Una unión Event-ECG conecta un evento del UDM con una entidad del gráfico de contexto de entidades (ECG). En el siguiente ejemplo de consulta, se buscan un evento NETWORK_CONNECTION y un ASSET del gráfico de entidades que comparten el mismo nombre de host en un período de 1 hora:

    events:
  $e1.metadata.event_type = "NETWORK_CONNECTION"
  $g1.graph.metadata.entity_type = "ASSET"
  $e1.principal.asset.hostname = $g1.graph.entity.asset.hostname
  $x = $g1.graph.entity.asset.hostname

match:
  $x over 1h

condition:
  $e1 and $g1

Unión de eventos de tabla de datos

  • Una unión de evento de tabla de datos conecta los eventos del UDM con las entradas de una tabla de datos personalizada. Esto es útil para verificar los datos de eventos en vivo en una lista definida por el usuario, como direcciones IP maliciosas conocidas o agentes de amenazas. La siguiente consulta de ejemplo une eventos de NETWORK_CONNECTION con una tabla de datos para encontrar conexiones que involucran direcciones IP específicas de esa lista:

    $ip = %DATATABLE_NAME.COLUMN_NAME
$ip = $e1.principal.ip
$e1.metadata.event_type = "NETWORK_CONNECTION"

match:
  $ip over 1h

Usa la cláusula IN con tablas de datos

También puedes usar la cláusula in para verificar si un valor de campo existe en una columna de la tabla de datos. Esta sintaxis se admite en todas las fuentes de datos (por ejemplo, ioc.type in %abc.type) y proporciona una forma conveniente de filtrar eventos en función de listas de referencia sin definir variables de marcador de posición explícitas para la unión.

Casos de uso habituales

En esta sección, se enumeran algunas formas comunes de usar las uniones.

Detectar el robo y el uso de credenciales

Objetivo: Encontrar instancias en las que un usuario accede correctamente y, luego, borra rápidamente un archivo crítico del sistema. Esto podría sugerir una apropiación de cuenta o actividad maliciosa de un usuario interno.

Tipo de unión: Unión de evento a evento

Descripción: Esta búsqueda conecta dos eventos distintos que no son sospechosos por sí solos, pero se vuelven muy sospechosos cuando ocurren juntos. Primero, busca un evento USER_LOGIN y, luego, un evento FILE_DELETION. Estos se unen con el user.userid común en un período breve.

  • Consulta de detección de robo de credenciales

    // Event 1: A user successfully logs in
$e1.metadata.event_type = "USER_LOGIN"
$e1.security_result.action = "ALLOW"
$e1.principal.user.userid = $user

// Event 2: The same user deletes a critical file
$e2.metadata.event_type = "FILE_DELETION"
$e2.target.file.full_path = /etc\/passwd|C:\\Windows\\System32\\/
$e2.principal.user.userid = $user

match:
  $user over 10m

condition:
  $e1 and $e2

Identifica las conexiones riesgosas de los recursos críticos

Objetivo: Enriquecer los datos de la red activa con información de los recursos para encontrar conexiones salientes desde servidores que no deberían comunicarse con dominios externos de baja prevalencia (por ejemplo, un servidor de base de datos de producción).

Tipo de unión: Unión de ECG de evento

Descripción: Una sola conexión de red a un dominio poco común podría no tener una prioridad alta. Sin embargo, esta búsqueda aumenta la importancia de ese evento, ya que lo une con el gráfico de contexto de entidades (ECG). Busca específicamente eventos NETWORK_CONNECTION que provienen de recursos etiquetados como "Servidor de base de datos crítico" en el gráfico de entidades.

  • Consulta de conexiones riesgosas

    events:
  $e.metadata.event_type = "NETWORK_CONNECTION"
  $e.target.domain.prevalence.day_count <= 5

  $asset.graph.metadata.entity_type = "ASSET"
  $asset.graph.entity.asset.labels.value = "Critical Database Server"

  $e.principal.asset.hostname = $asset.graph.entity.asset.hostname
  $host = $e.principal.asset.hostname

match:
  $host over 1h

condition:
  $e and $asset

Busca IOCs de agentes de amenazas

Objetivo: Buscar de forma activa indicadores de compromiso (IoC) verificando todas las consultas de DNS activas en una lista de dominios que se sabe que usa un agente de amenazas específico.

Tipo de unión: Unión de tabla de datos y evento

Descripción: Tu equipo de inteligencia contra amenazas mantiene una tabla de datos llamada ThreatActor_Domains que enumera los dominios maliciosos. Esta consulta une todos los eventos NETWORK_DNS_QUERY en tiempo real con esta tabla de datos. Muestra de inmediato cualquier instancia en la que un host de tu red intente resolver un dominio de tu lista de inteligencia contra amenazas.

  • Consulta de búsqueda de IOC de agentes de amenazas

    // Datatable: Get the list of malicious domains
$domain = %DATATABLE_NAME.COLUMN_NAME

// Event: A DNS query is made
$e.metadata.event_type = "NETWORK_DNS"
$e.network.dns.questions.name = $domain

match:
  $domain over 5m

condition:
  $e

Uniones en los paneles

Los paneles admiten una mayor variedad de fuentes de datos y períodos de correlación más largos que en Search. A diferencia de las consultas en SQL estándar, YARA-L 2.0 no usa instrucciones JOIN explícitas, sino que conecta fuentes de datos correlacionando variables de marcador de posición compartidas o usando consultas de varias etapas.

Distinción de mayúsculas

Las consultas del panel distinguen mayúsculas de minúsculas. Para realizar una búsqueda o una unión que no distinga entre mayúsculas y minúsculas en un panel, usa el modificador nocase.

Fuentes de datos compatibles

En los paneles, puedes combinar datos de combinaciones admitidas de fuentes de datos. (No todas las combinaciones de fuentes de datos se pueden unir en una sola consulta).

Todas las referencias de datos en una consulta de panel de varias fuentes deben incluir su calificador de prefijo de YARA-L (por ejemplo, $u1), no solo los campos unidos. Esto permite que el sistema identifique correctamente la propiedad de los campos en las fuentes de datos superpuestas.

Combinaciones de unión admitidas

Las uniones te permiten correlacionar eventos del UDM, contexto de entidades y tablas de datos en los paneles integrados. Para mantener el rendimiento del sistema, revisa las combinaciones admitidas y los límites técnicos en esta sección antes de crear tus consultas.

  • Evento de UDM a evento de UDM (varios eventos)
  • Contexto de la entidad para el evento de UDM
  • Evento de UDM a tabla de datos

  • Historial de casos: Esta combinación se limita estrictamente a exactamente una fuente de case y una fuente de case_history. No puedes incluir ninguna otra fuente de datos en esta unión.

Para obtener información sobre los límites y las protecciones, consulta Límites y restricciones técnicos.

Ejemplo: Unión de caso y case_history

Puedes correlacionar los metadatos del caso con su actividad histórica si realizas una unión en el ID único del caso.

  • En el siguiente ejemplo, se unen las fuentes de datos case y case_history para contar la cantidad total de acciones históricas de cada caso de prioridad alta.

      // 1. Establish the Join using a shared placeholder variable ($case_id)
  $h.case_history.case_response_platform_info.case_id = $case_id
  $c.case.response_platform_info.response_platform_id = $case_id

  // 2. Apply Filters
  $c.case.priority = "PRIORITY_HIGH"

  // 3. Group the correlated data by the Case ID
  match:
    $case_id

  // 4. Calculate the selected metrics to display on the dashboard
  outcome:
    $case_name = array_distinct($c.case.display_name)
    $total_historical_actions = count($h.case_history.case_activity)

Caso de uso avanzado: Cálculo del MTTR

Para métricas más complejas, como el tiempo promedio de resolución (MTTR) o el tiempo promedio de cierre (MTTC), puedes usar una consulta de varias etapas. Esto te permite calcular la duración de cada caso individual en la primera etapa y, luego, promediar esas duraciones de forma global en el bloque de resultados final.

  • La siguiente consulta calcula el tiempo promedio para cerrar casos (en minutos) en todos los casos del "Entorno predeterminado".

    stage stage1 {
  // 1. Establish the Join
  $h.case_history.case_response_platform_info.case_id = $case_id
  $c.case.response_platform_info.response_platform_id = $case_id

  // 2. Filter by specific environment
  $c.case.environment = "Default Environment"

  // 3. Group by Case ID to process per case
  match:
    $case_id

  // 4. Calculate the Time to Close (TTC) for each case individually
  outcome:
    $case_close_time = max(if($h.case_history.case_activity = "CLOSE_CASE", $h.case_history.event_time.seconds, 0))
    $status = array_distinct($h.case_history.case_activity)

    // Subtract the very first event time (creation) from the close time
    $TTC = $case_close_time - min($h.case_history.event_time.seconds)

  // 5. Filter to ensure the case has a complete lifecycle
  condition:
    arrays.contains($status, "CREATE_CASE") and
    arrays.contains($status, "CLOSE_CASE")
}

// 6. Global Aggregation: Calculate the Mean (Average) across all processed cases
outcome:
  $case_count = count($stage1.case_id)
  $MTTC = (math.round(avg($stage1.TTC) / 60))

Prácticas recomendadas

Para optimizar el rendimiento de tus consultas de unión y asegurarte de que se procesen de manera eficiente, sigue estas prácticas recomendadas para filtrar eventos y administrar el alcance de la búsqueda.

Usa filtros específicos para reducir la cantidad de eventos

Las consultas de unión pueden consumir muchos recursos porque combinan muchos resultados.

  • Los filtros amplios y generales pueden hacer que las consultas fallen, a veces después de una larga demora, por ejemplo:

    • target.ip != ""

    • metadata.event_type = "NETWORK_CONNECTION" (si este tipo de evento es muy común en tu entorno)

  • Te recomendamos que combines filtros generales con otros más específicos para reducir la cantidad total de eventos que debe procesar la consulta. Un filtro amplio, como target.ip != "", debe combinarse con filtros más específicos para mejorar el rendimiento de la búsqueda. Por ejemplo:

    $e1.metadata.log_type = $log
$e1.metadata.event_type = "USER_LOGIN"
$e1.target.ip != ""

$e2.metadata.log_type = $log
$e2.principal.ip = "10.0.0.76"
$e2.target.hostname != "altostrat"

match:
$log over 5m

Si la consulta sigue siendo lenta, también puedes reducir el período general de la consulta (por ejemplo, de 30 días a una semana).

Para obtener más información, consulta las prácticas recomendadas de YARA-L.

Límites y restricciones técnicas

Se aplican las siguientes limitaciones y límites cuando se usan uniones en Search y en los paneles.

Límites de consultas y ventana de coincidencia

La ventana de coincidencia define el período específico en el que se correlacionan los eventos. Esto es diferente del período de búsqueda que seleccionas en la interfaz de usuario.

La Búsqueda está optimizada para investigaciones rápidas o en vivo durante períodos más cortos.

Límite de consultas Uso
Hasta 48 horas (algunas búsquedas pueden admitir períodos más largos). Correlacionar eventos en investigaciones rápidas

Límites en los paneles

Los paneles admiten análisis históricos a largo plazo.

Tipo de unión Límite de consultas Uso
UDM a UDM y UDM a entidad 31 días Consultas de telemetría de alto volumen
Case-to-CaseHistory 90 días Consultas de seguimiento del ciclo de vida
Otros parámetros de configuración admitidos Hasta 365 días Es una alternativa para las fuentes que no son de UDM o basadas en métricas (por ejemplo, las métricas de transferencia).

Límites de fuentes de datos y tablas

La cantidad máxima de fuentes de datos y tablas que puedes combinar en una sola consulta depende de si usas la Búsqueda o los paneles.

Restricciones de búsqueda

  • Puedes usar un máximo de dos eventos de UDM por búsqueda.
  • Puedes usar un máximo de un evento de ECG por consulta.
  • Puedes usar un máximo de dos tablas de datos por consulta.
  • No puedes unir una tabla de datos directamente a una tabla de contexto de la entidad; debes usar un evento del UDM como puente intermedio (por ejemplo, correlacionar $event.target.hostname con $datatable.hostname y $asset.graph.entity.asset.hostname).

Restricciones del panel

Tipo de unión Cantidad máxima de tablas de eventos (UDM o tabla de datos) Cantidad máxima de tablas de entidades
Multi-event (UDM to UDM) 2 N/A
UDM a entidad 2 1
UDM a tabla de datos 2 N/A
Consultas de varias etapas 2 1

Rendimiento y protecciones

El sistema supervisa las consultas de unión complejas para detectar un consumo excesivo de recursos. Para proteger el rendimiento general del entorno, es posible que el sistema pause o ponga en cuarentena automáticamente las búsquedas que superen los umbrales de seguridad de los recursos.

Si una consulta falla o muestra errores que indican que superó los límites de recursos, prueba las siguientes optimizaciones:

  • Acota el período de la búsqueda.
  • Agrega filtros más específicos para reducir el tamaño del conjunto de datos antes de que se produzca la unión.
  • Simplifica tus agregaciones.

Restricciones de la API y del tipo de consulta

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