Uso del gráfico de contexto de la entidad (ECG)

Compatible con:

Google SecOps SIEM

En este documento, se proporciona una descripción general del Gráfico de contexto de entidades (ECG), que abarca sus fuentes de datos, su canalización de procesamiento y sus aplicaciones en reglas y búsquedas. El ECG es un modelo de datos de entidades principal que proporciona contexto esencial para la detección avanzada de amenazas, la investigación y la búsqueda de amenazas en las reglas de detección, la búsqueda y los paneles. La canalización de procesamiento de ECG combina información contextual de cada entorno de Google SecOps.

El ECG también calcula métricas de resumen para las entidades. Estos incluyen la prevalencia (con qué frecuencia aparece una entidad específica en tus datos del UDM en comparación con otras entidades) y los atributos first-seen-time y last-seen-time de una entidad. También identifica fuentes clave de enriquecimiento y fuentes de indicadores de compromiso (IOC), como Google Threat Intelligence (GTI), Navegación Segura, WHOIS y datos de VirusTotal.

El ECG usa eventos de UDM para realizar las siguientes acciones:

• Crea una vista enriquecida, correlacionada y completa de las entidades internas (recursos y usuarios) y las entidades externas (IOC).
• Identifica las relaciones entre estas entidades.

Fuentes de datos del ECG

La canalización del ECG combina datos de las siguientes fuentes:

Fuente de contexto	Fuente	Descripción
Contexto de la entidad	Proporcionado por el cliente	Google SecOps incorpora directamente datos organizacionales estructurados, como detalles autorizados sobre usuarios y activos, desde sistemas externos. Estas fuentes incluyen proveedores de identidad (IDP), sistemas de bases de datos de administración de configuración (CMDB) (como ServiceNow CMDB y Duo User Context) y sistemas de gestión de vulnerabilidades.
Contexto derivado	Generado por Google SecOps	Google SecOps genera datos estadísticos basados en el análisis de la actividad transferida. Enriquece los eventos y las entidades de varias fuentes dentro de tu entorno (por ejemplo, Windows AD, Azure AD, Okta, Google Cloud, IAM). Por ejemplo: Calcula y enriquece cada entidad con una estadística de prevalencia que indica su popularidad en el entorno. Calcula y enriquece los campos entity first-seen-time y last-seen-time.
Contexto global	Obtenido de Google	Las fuentes globales proporcionan inteligencia contra amenazas y datos de reputación internos y externos. Por ejemplo: Ingiere y almacena datos de Google Threat Intelligence. Enriquece las entidades con información de las listas de amenazas de la Navegación segura. Enriquece las entidades con datos de WHOIS.

Canalización de procesamiento de datos del ECG

La canalización de procesamiento de datos del ECG crea un perfil enriquecido y autorizado para cada entidad. Para ello, combina el contexto de varios orígenes (como proveedores de identidad, bases de datos de administración de configuración [CMDB], feeds de inteligencia contra amenazas y contexto derivado) en un solo perfil de entidad consolidado. La combinación de ECG permite lo siguiente:

• Se agregan nuevas conexiones, propiedades y relaciones al ECG.
• Crear y actualizar el contexto derivado

El proceso general implica primero normalizar los eventos de seguridad sin procesar en estructuras del UDM con el alias y el enriquecimiento del UDM, y, luego, combinar estos datos de eventos con varias fuentes contextuales para crear perfiles de entidades enriquecidos.

Creación de alias de UDM y combinación de ECG

En primer lugar, la canalización de alias y enriquecimiento del UDM ingiere eventos de seguridad sin procesar y los normaliza en estructuras del UDM.

Nota: La "combinación de ECG" no es lo mismo que la "creación de alias de UDM". Si bien el alias de UDM enriquece los eventos agregando identificadores (por ejemplo, asignando una dirección IP a un nombre de host dentro de un evento), ECG combina el contexto de múltiples fuentes (como IdP, CMDB y la inteligencia contra amenazas) para crear un solo perfil para una entidad.

Entidades temporales y atemporales

El ECG construye entidades temporales y atemporales. Las entidades cronometradas se evalúan dentro de los rangos de tiempo de búsqueda y de la regla especificados. Las entidades atemporales se evalúan sin tener en cuenta el período de la búsqueda o la regla.

Claves de combinación de ECG

El ECG combina los registros de contexto haciendo coincidir los identificadores de clave comunes en diferentes fuentes de datos. Entre los ejemplos de estos identificadores, se incluyen hostname, MAC address, user ID o email address. El ECG combina los registros que coinciden en cualquiera de estos valores para crear una vista integral y enriquecida de una entidad.

El alias de ECG usa los siguientes campos de UDM como claves de combinación:

• Asset
  • entity.asset.product_object_id
  • entity.asset.hostname
  • entity.asset.asset_id
  • entity.asset.mac
• User
  • entity.user.product_object_id
  • entity.user.userid
  • entity.user.windows_sid
  • entity.user.email_addresses
  • entity.user.employee_id
• Resource
  • entity.resource.product_object_id
  • entity.resource.name
• Group
  • entity.group.product_object_id
  • entity.group.email_addresses
  • entity.group.windows_sid

Cómo combinar tipos de entidades específicos (archivo, URL y dominio)

Además de las merge-keys, el ECG combina el contexto para tipos de entidades específicos (archivo, URL y dominio) con los siguientes identificadores únicos:

• File

  • entity.file.md5
  • entity.file.sha1
  • entity.file.sha256
  • (y entity.file.product_object_id si se proporciona)

• URL

  • entity.url.url
  • (y entity.url.product_object_id si se proporciona)

• Domain

  • entity.domain.domain
  • (y entity.domain.product_object_id si se proporciona)

El ECG solo combina un registro de contexto de entidad para un File, URL o Domain con otro registro si todos los identificadores únicos presentes en ambos registros coinciden.

Por ejemplo, si el ECG considera dos contextos de entidades File para una combinación:

• Si ambos tienen un hash de md5, el ECG requiere que coincidan.
• Si uno tiene un md5 y el otro tiene un sha256, el ECG no los combinará según el hash.
• Si se proporciona un product_object_id, el ECG también debe coincidir con él si está presente en ambos registros que se comparan, además de los identificadores basados en el contenido (como md5, url o domain).

Esto significa que, para estos tipos, los campos como entity.file.md5, entity.url.url y entity.domain.domain deben estar presentes y coincidir para el proceso de combinación, además de cualquier product_object_id proporcionado.

Resolución de conflictos

Durante el proceso de combinación, si los campos tienen valores en conflicto, el ECG actualiza la entidad seleccionando el valor con la hora de inicio más reciente. Cuando el ECG actualiza un atributo de entidad con un valor nuevo, conserva el valor anterior en los resultados de la búsqueda durante el intervalo de tiempo en el que ese valor anterior era válido. Por lo tanto, una búsqueda que abarque un período durante el cual cambió un atributo puede devolver varios contextos de entidad para esa entidad.

Anulación de duplicación e intervalos

Para crear una entidad combinada común, el ECG elimina los datos redundantes a través de la anulación de duplicación. Los duplicados se identifican a través de la correlación de todos los identificadores únicos pertinentes de una entidad en diferentes fuentes de contexto. Genera intervalos de tiempo en lugar de coincidencias exactas de marcas de tiempo.

Por ejemplo, considera dos entidades e1 y e2 con marcas de tiempo t1 y t2, respectivamente. Si e1 y e2 son idénticos en otros aspectos, el ECG los anula ignorando las diferencias de marcas de tiempo en los siguientes campos:

• collected_timestamp
• creation_timestamp
• interval

Nota: Si se producen conflictos en campos no repetidos, se usan los datos de la entidad más reciente.

Ventana de visualización

El ECG crea datos de contexto de la entidad con un período de observación de cinco días. Este proceso ayuda a controlar los datos que llegan tarde y establece un tiempo de actividad implícito para los datos de contexto de la entidad.

El ECG distingue entre los datos contextuales (assets, users, resources, groups) y los indicadores de compromiso (IOC).

Ejemplo: Fusión de datos del usuario con la fusión de ECG

Por ejemplo, Google SecOps ingiere datos del usuario para jdoe desde tres fuentes: Okta, Azure AD y un verificador de vulnerabilidades. El ECG combina estos tres registros en función de los identificadores coincidentes (como [e-mail]). Esto crea una entidad de usuario jdoe unificada en el ECG, que contiene atributos de las tres fuentes.

Fuentes de datos de ECG de contexto de entidades y eventos críticos

Google SecOps requiere varias fuentes de datos específicas para crear y actualizar entidades.

Fuentes de datos de ECG de contexto de entidades críticas

Las fuentes de datos autorizadas para los usuarios y los activos de tu entorno proporcionan los datos de registro más importantes para crear un modelo de datos de entidades. Por ejemplo:

Categoría	Fuentes de datos críticas	Entidades completadas
Administración de identidades y accesos	Active Directory, Azure AD, Okta, Google Cloud Identity	user, group
Inventario de recursos	CMDB, JAMF, Microsoft Intune	asset
Inteligencia contra amenazas	Feeds personalizados o de terceros, Google Threat Intelligence (GTI)	ip_address, domain_name, file

Ejemplo de búsqueda

Para enumerar los analizadores que admiten cada categoría, haz lo siguiente:

1. Ve a Tipos de registros admitidos con un analizador predeterminado.

2. Escribe una categoría en la barra de búsqueda, por ejemplo:

   • Para los analizadores relevantes para el inventario de activos, escribe inventory o asset.
   • Para los analizadores relevantes para la administración de identidades y accesos, escribe identity.
   • Para los analizadores pertinentes a la inteligencia contra amenazas, escribe IOC.

Fuentes de datos y campos críticos de UDM para la creación de perfiles de entidades

Google SecOps mejora los perfiles de entidades en función de fuentes de datos de contexto de entidades autorizadas y campos críticos del UDM:

Tipo de entidad	Fuentes de datos	Campos críticos del UDM (para alias e indexación)
Proceso	Los registros de extremos proporcionan el PSPI (`principal.process.product_specific_process_id`), un identificador estable fundamental para la creación de alias de procesos sólidos. Entre los ejemplos, se incluyen CrowdStrike EDR (CS_EDR) y Windows Sysmon (WINDOWS_SYSMON).	source.process.product_specific_process_id
Usuario	Estas fuentes proporcionan información de identidad y atributos del usuario. Por ejemplo, los datos de contexto de la entidad de Duo (DUO_CONTEXT) y Okta (OKTA).	source.user.userid, source.user.email_address, source.user.windows_sid, source.user.product_object_id
Activo o extremo	Estas fuentes proporcionan información autorizada sobre los activos. Por ejemplo, ServiceNow CMDB (SERVICENOW_CMDB) y Tanium Asset (TANIUM_ASSET).	source.ip, source.hostname, source.asset_id, principal.asset.hostname
Hash del archivo	Proporciona una "huella digital" única del contenido de los datos para verificar la integridad de los datos.	source.file.sha256, source.file.sha1, source.file.md5

Campos del UDM de datos de contexto de eventos críticos

Google SecOps requiere varios campos de datos de contexto de eventos críticos del UDM.

• Los campos de UDM más importantes actúan como identificadores y indicadores de relación estables (campos principal.*, target.*, src_* y dst_*).

• Consulta la lista de campos clave de UDM que pertenecen al área de funciones de Entity graph.

• Para crear un ECG integral, prioriza las fuentes de datos que aportan identificadores valiosos y datos de relaciones. Por ejemplo:

  Tipo de entidad	Fuentes de datos críticas	Campos de UDM críticos para la creación de entidades
  Recurso (host)	EDR y XDR, DNS y DHCP, firewall, Google Cloud registros de auditoría de la consola	metadata.event_type, principal.asset.asset_id, principal.asset.hostname, principal.ip
  Usuario	Registros del proveedor de identidad (IdP), feed de RR.HH. (contexto), registros de Cloud Identity y puerta de enlace de correo electrónico	principal.user.userid, principal.user.email_addresses, target.user.userid, principal.ip
  Red	Firewall, VPN, DNS, registros de flujo de VPC	principal.ip, target.ip, src_ip, dst_ip, network.direction
  Archivo y proceso	EDR y XDR, registros de aplicaciones	target.file.full_path, target.process.file.full_path, target.process.command_line

Ejemplo

El ECG se basa en estos campos del UDM para unir los datos de contexto de la entidad y los datos de eventos del UDM en reglas, búsquedas y paneles.

Por ejemplo, puedes unir datos de contexto del usuario en una regla de supervisión de "fuerza bruta" para generar alertas solo si el usuario implicado también forma parte del grupo "Administradores del dominio" y el activo implicado es un controlador de dominio:

events:
  $fail.metadata.event_type = "USER_LOGIN"
  $fail.metadata.vendor_name = "Microsoft"
  $fail.principal.hostname = $hostname
  $fail.target.user.userid = $target_user
  $fail.security_result.action = "BLOCK"
  $fail.metadata.product_event_type = "4625"
 
  $fail.metadata.event_timestamp.seconds < $success.metadata.event_timestamp.seconds
 
  $success.metadata.event_type = "USER_LOGIN"
  $success.metadata.vendor_name = "Microsoft"
  $success.target.user.userid = $target_user
  $success.principal.hostname = $hostname
  $success.security_result.action = "ALLOW"
  $success.metadata.product_event_type = "4624"
  $user.graph.entity.user.userid = $target_user
  $user.graph.metadata.entity_type = "USER"
  $user.graph.metadata.source_type = "ENTITY_CONTEXT"
  any $user.graph.relations.entity.group.group_display_name = "Domain Admins"

  $asset.graph.entity.asset.hostname = $hostname
  $asset.graph.metadata.entity_type = "ASSET"
  $asset.graph.metadata.source_type = "ENTITY_CONTEXT"
  any $asset.graph.relations.entity.group.group_display_name = "Domain Controllers"
 
match:
  $target_user, $hostname over 15m
condition:
  #fail > 4 and $success and $user and $asset

Enriquecimientos de contexto derivados

Google SecOps genera datos de inferencia dinámicos basados en eventos para cada entidad en todos los espacios de nombres a partir de los datos de eventos de tu organización. Utiliza información de alias, datos de procesos internos de enriquecimiento y datos de eventos de seguridad para establecer relaciones (por ejemplo, un asset asociado a un IP address).

Este proceso agrega contexto valioso para mejorar los perfiles de entidades. Estos son algunos ejemplos:

• entity.file.sha256 a file (hash) entidades
• (principal or target).ip_geo_artifact.location.country_or_region a network (geolocation) entidades

El equipo de Google SecOps analiza varios indicadores de la actividad incorporada para enriquecer los eventos con información de contexto. Ejecuta funciones de enriquecimiento críticas para generar, por ejemplo, métricas de rareza de entidades, como estadísticas de prevalencia, y métricas temporales, como first-seen-time y last-seen-time.

Estadísticas de prevalencia

La canalización de ECG analiza los datos existentes y los entrantes para calcular y almacenar las métricas de prevalencia como un campo de contexto derivado. Estas métricas representan un valor numérico de "popularidad" para entidades como domain, file hash o IP address dentro de tu entorno. Esto te ayuda a detectar la actividad inusual o poco frecuente, ya que las entidades más populares suelen representar menos riesgo.

Google SecOps actualiza estas estadísticas con regularidad y las almacena en un contexto de entidad independiente. El motor de detección puede usar estos valores, y puedes buscarlos con la sintaxis de consultas de UDM. Sin embargo, la consola no muestra estos valores con otros detalles de la entidad.

Puedes usar los siguientes campos cuando crees reglas del motor de detección.

Tipo de entidad	Campos de UDM
Dominio	entity.domain.prevalence.day_count entity.domain.prevalence.day_max entity.domain.prevalence.day_max_sub_domains entity.domain.prevalence.rolling_max entity.domain.prevalence.rolling_max_sub_domains
Archivo (hash)	entity.file.prevalence.day_count entity.file.prevalence.day_max entity.file.prevalence.rolling_max
Dirección IP	entity.artifact.prevalence.day_count entity.artifact.prevalence.day_max entity.artifact.prevalence.rolling_max

Google SecOps calcula los valores de day_max y rolling_max de manera diferente, como se indica a continuación:

• day_max representa la puntuación de prevalencia máxima del artefacto durante el día (un día se define como de las 12:00:00 a.m. a las 11:59:59 p.m. UTC).
• rolling_max representa la puntuación de prevalencia máxima por día (es decir, day_max) para el artefacto durante el período de 10 días anterior.
• day_count se usa para calcular rolling_max, y su valor siempre es 10.

Cuando se calculan estos valores para un domain, la diferencia entre day_max y day_max_sub_domains (y rolling_max en comparación con rolling_max_sub_domains) es la siguiente:

• rolling_max y day_max representan la cantidad de direcciones IP internas únicas diarias que acceden a un dominio determinado (se excluyen los subdominios).
• rolling_max_sub_domains y day_max_sub_domains representan la cantidad de direcciones IP internas únicas que acceden a un dominio determinado (se incluyen los subdominios).

Google SecOps calcula las estadísticas de prevalencia con los datos de entidades recién incorporados. Google SecOps no realiza cálculos de forma retroactiva sobre los datos que se incorporaron anteriormente. Google SecOps tarda aproximadamente 36 horas en calcular y almacenar las estadísticas.

Precaución: Incluir el argumento prevalence puede aumentar significativamente los datos consultados, lo que podría generar un error de regla. Si encuentras un error de regla, ajusta los parámetros de la regla. Por ejemplo, agrega más filtros o reduce el período especificado en la sección match.

Ejemplo

La canalización de ECG requiere estos campos del UDM para unir los datos de contexto pertinentes en una regla o búsqueda. Debes unir de forma explícita todos los datos relacionados con el ECG a los datos de eventos del UDM.

Por ejemplo, puedes usar los datos de prevalence en ECG para determinar las conexiones a dominios "poco comunes" en tus registros de seguridad:

    $dns.metadata.event_type = "NETWORK_DNS"
    $dns.network.dns.questions.name != ""
    $dns.network.dns.questions.name = $domain
    $prevalence.graph.metadata.entity_type = "DOMAIN_NAME"
    $prevalence.graph.metadata.source_type = "DERIVED_CONTEXT"
    $prevalence.graph.entity.hostname = $domain
    $prevalence.graph.entity.domain.prevalence.day_count = 10
    $prevalence.graph.entity.domain.prevalence.rolling_max > 0
    $prevalence.graph.entity.domain.prevalence.rolling_max <= 3

  match:
    $domain over 5m
  condition:
    $dns and $prevalence

Nota: Search y Dashboards admiten un máximo de una unión, mientras que Rules admite un máximo de dos.

Nota: Incluir el argumento prevalence puede hacer que la búsqueda consulte muchos más datos.

Horas de la primera y la última vez que se vieron las entidades

Google SecOps analiza los datos entrantes para enriquecer los registros de contexto de la entidad con los siguientes campos críticos:

• first-seen-time: Es la fecha y la hora en que se vio la entidad por primera vez en tu entorno.
• last-seen-time: La fecha y la hora de la observación más reciente.

Estos campos derivados te permiten correlacionar la actividad en las entidades domain, file hash, asset, user o IP address.

Estos valores se almacenan en los siguientes campos del UDM:

Tipo de entidad	Campos de UDM
Dominio	entity.domain.first_seen_time entity.domain.last_seen_time
Archivo (hash)	entity.file.first_seen_time entity.file.last_seen_time
Dirección IP	entity.artifact.first_seen_time entity.artifact.last_seen_time
Recurso	entity.asset.first_seen_time
Usuario	entity.user.first_seen_time

Excepciones para los cálculos de la fecha de la primera y la última vez que se vio:

• Para las entidades asset y user, Google SecOps solo completa el campo first_seen_time, pero no el campo last_seen_time.
• Google SecOps no calcula las estadísticas de cada entidad dentro de los espacios de nombres individuales.
• Google SecOps no exporta estas estadísticas al esquema de events de Google SecOps en BigQuery.
• Google SecOps no calcula estos valores para otros tipos de entidades, como group o resource.

Enriquecimientos del contexto global

Estas fuentes incluyen inteligencia contra amenazas externa y datos de reputación de fuentes globales internas y de terceros.

Transfiere datos de Google Threat Intelligence

Google SecOps incorpora datos de las fuentes de datos de Google Threat Intelligence (GTI), lo que proporciona información contextual para investigar la actividad en tu entorno.

Consultar las siguientes fuentes de datos:

• Nodos de salida de Tor de GTI: Direcciones IP que se conocen como nodos de salida de Tor.
• Binarios benignos de GTI: Son archivos que forman parte de la distribución original del sistema operativo o que se actualizaron con un parche oficial del sistema operativo. Se excluyen de esta fuente de datos algunos archivos binarios oficiales del sistema operativo que un adversario usó de forma inadecuada a través de actividades comunes en los ataques de "living off the land", como los que se enfocan en los vectores de entrada iniciales.
• Herramientas de acceso remoto de GTI: Son archivos que los agentes maliciosos usan con frecuencia. Por lo general, estas herramientas son aplicaciones legítimas que, a veces, se usan de forma inadecuada para conectarse de forma remota a sistemas comprometidos.

Los datos contextuales se almacenan de forma global como entidades. Puedes consultar los datos con las reglas del motor de detección. Incluye los siguientes campos y valores del UDM en la regla para consultar estas entidades globales:

• graph.metadata.vendor_name = Google Threat Intelligence
• graph.metadata.product_name = GTI Feed

Nota: En las siguientes secciones, reemplaza el marcador de posición <variable_name> por el nombre de variable único que usas en una regla para identificar un registro de UDM.

Fuentes de datos de Google Threat Intelligence temporales y permanentes

Las fuentes de datos de Google Threat Intelligence incluyen tipos temporales o atemporales.

Cada entrada de las fuentes de datos cronometradas tiene un período asociado. Por ejemplo, si Google SecOps genera una detección el día 1, se espera que genere la misma detección para el día 1 durante una búsqueda retroactiva en cualquier día futuro.

Las fuentes de datos atemporales no tienen un período asociado, ya que solo se debe tener en cuenta el conjunto de datos más reciente. Estas fuentes de datos suelen usarse para datos que no se espera que cambien, como los hashes de archivos. Si Google SecOps no genera una detección el día 1, es posible que se genere una detección para el día 1 durante una búsqueda retroactiva el día 2 si se agregó una entrada nueva a la fuente de datos independiente del tiempo.

Datos sobre las direcciones IP de los nodos de salida de Tor

Google SecOps transfiere y almacena las direcciones IP que se conocen como nodos de salida de Tor. Los nodos de salida de Tor son puntos en los que el tráfico sale de la red de Tor. Estos datos están sincronizados.

Google SecOps almacena la información que se ingiere de esta fuente de datos en los siguientes campos del UDM:

Campo de UDM	Descripción
<variable_name>.graph.metadata.vendor_name	Almacena el valor Google Threat Intelligence.
<variable_name>.graph.metadata.product_name	Almacena el valor GTI Feed.
<variable_name>.graph.metadata.threat.threat_feed_name	Almacena el valor Tor Exit Nodes.
<variable_name>.graph.entity.artifact.ip	Almacena la dirección IP transferida desde la fuente de datos de GTI.

Ejemplo de búsqueda

graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Tor Exit Nodes"

Datos sobre archivos benignos del sistema operativo

Google SecOps ingiere y almacena hashes de archivos de la fuente de datos de GTI Benign Binaries. Google SecOps almacena la información que se ingiere de esta fuente de datos en los siguientes campos del UDM. Los datos de los archivos binarios benignos son atemporales.

Campo de UDM	Descripción
<variable_name>.graph.metadata.vendor_name	Almacena el valor Google Threat Intelligence.
<variable_name>.graph.metadata.product_name	Almacena el valor GTI Feed.
<variable_name>.graph.metadata.threat.threat_feed_name	Almacena el valor Benign Binaries.
<variable_name>.graph.entity.file.sha256	Almacena el valor de hash SHA256 del archivo.
<variable_name>.graph.entity.file.sha1	Almacena el valor de hash SHA-1 del archivo.
<variable_name>.graph.entity.file.md5	Almacena el valor de hash MD5 del archivo.

Ejemplo de búsqueda

graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Benign Binaries"

Datos sobre herramientas de acceso remoto

Las herramientas de acceso remoto incluyen hashes de archivos para herramientas de acceso remoto conocidas, como los clientes de VNC que los agentes maliciosos han usado con frecuencia. Por lo general, estas herramientas son aplicaciones legítimas que, a veces, se usan de forma inadecuada para conectarse de forma remota a sistemas comprometidos. Google SecOps almacena la información que se transfiere desde esta fuente de datos en los siguientes campos del UDM. Los datos de las herramientas de acceso remoto son atemporales.

Campo de UDM	Descripción
<variable_name>.graph.metadata.vendor_name	Almacena el valor Google Threat Intelligence.
<variable_name>.graph.metadata.product_name	Almacena el valor GTI Feed.
<variable_name>.graph.metadata.threat.threat_feed_name	Almacena el valor Remote Access Tools.
<variable_name>.graph.entity.file.sha256	Almacena el valor de hash SHA256 del archivo.
<variable_name>.graph.entity.file.sha1	Almacena el valor de hash SHA-1 del archivo.
<variable_name>.graph.entity.file.md5	Almacena el valor de hash MD5 del archivo.

Ejemplo de búsqueda

graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Remote Access Tools"

Enriquece entidades con información de las listas de amenazas de la Navegación segura

Google SecOps ingiere datos de la Navegación segura relacionados con los hashes de archivos. Google SecOps almacena los datos de cada archivo como una entidad y proporciona contexto adicional sobre el archivo. Puedes crear reglas del motor de detección que consulten estos datos de contexto de la entidad para generar estadísticas basadas en el contexto.

Nota: Solo puedes usar la Navegación Segura en las reglas, y los datos se consideran atemporales.

Google SecOps almacena la siguiente información con el registro de contexto de la entidad.

Campo de UDM	Descripción
entity.metadata.product_entity_id	Es un identificador único de la entidad.
entity.metadata.entity_type	Este valor es FILE, lo que indica que la entidad describe un archivo.
entity.metadata.collected_timestamp	Fecha y hora en que se observó la entidad o en que ocurrió el evento.
entity.metadata.interval	Almacena la hora de inicio y la hora de finalización para las que son válidos estos datos. Dado que el contenido de las listas de amenazas cambia con el tiempo, start_time y end_time reflejan el intervalo durante el cual son válidos los datos sobre la entidad. Por ejemplo, se observó que un hash de archivo era malicioso o sospechoso entre start_time y end_time.
entity.metadata.threat.category	El SecurityCategory de Google SecOps se establece en uno o más de los siguientes valores: SOFTWARE_MALICIOUS: Indica que la amenaza está relacionada con software malicioso. SOFTWARE_PUA: Indica que la amenaza se relaciona con software no deseado.
entity.metadata.threat.severity	Este es el ProductSeverity de Google SecOps. Si el valor es CRITICAL, indica que el artefacto parece malicioso. Si no se especifica el valor, no hay suficiente confianza para indicar que el artefacto es malicioso.
entity.metadata.product_name	Almacena el valor Google Safe Browsing.
entity.file.sha256	Es el valor de hash SHA256 del archivo.

Ejemplo de regla

events:
    // find a process launch event, match on hostname
    $execution.metadata.event_type = "PROCESS_LAUNCH"
    $execution.target.process.file.sha256 != ""
    $execution.principal.hostname = $hostname

    // join execution event with Safe Browsing graph
    $sb.graph.entity.file.sha256 = $execution.target.process.file.sha256

    // look for files deemed malicious
    $sb.graph.metadata.entity_type = "FILE"
    $sb.graph.metadata.threat.severity = "CRITICAL"
    $sb.graph.metadata.product_name = "Google Safe Browsing"

  match:
    $hostname over 5m

  condition:
    $execution and $sb

Enriquece entidades con datos de WHOIS

Google SecOps realiza un enriquecimiento diario de los datos de WHOIS, una función fundamental, con datos que son tanto temporales como atemporales.

Durante la transferencia de datos del dispositivo, Google SecOps evalúa los dominios en función de los datos de WHOIS. Cuando los dominios coinciden, Google SecOps almacena los datos de WHOIS relacionados en el registro de la entidad del dominio. Para cada entidad con entity.metadata.entity_type = DOMAIN_NAME, Google SecOps enriquece el registro con información de WHOIS.

Google SecOps completa el registro de la entidad con datos enriquecidos de WHOIS en los siguientes campos:

• entity.domain.admin.attribute.labels
• entity.domain.audit_update_time
• entity.domain.billing.attribute.labels
• entity.domain.billing.office_address.country_or_region
• entity.domain.contact_email
• entity.domain.creation_time
• entity.domain.expiration_time
• entity.domain.iana_registrar_id
• entity.domain.name_server
• entity.domain.private_registration
• entity.domain.registrant.company_name
• entity.domain.registrant.office_address.state
• entity.domain.registrant.office_address.country_or_region
• entity.domain.registrant.email_addresses
• entity.domain.registrant.user_display_name
• entity.domain.registrar
• entity.domain.registry_data_raw_text
• entity.domain.status
• entity.domain.tech.attribute.labels
• entity.domain.update_time
• entity.domain.whois_record_raw_text
• entity.domain.whois_server
• entity.domain.zone

Google SecOps enriquece las entidades domain (entity.metadata.entity_type = "DOMAIN_NAME") con datos de registrant, creation y expiration time de los registros de global context WHOIS.

Para obtener descripciones de estos campos, consulta el documento de la lista de campos del modelo de datos unificado.

Ejemplo de búsqueda

graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "WHOISXMLAPI Simple Whois"
graph.entity.domain.registry_data_raw_text != b""

Prácticas recomendadas: Identifica fuentes de datos enriquecidas con contexto global

Para mejorar el rendimiento de las reglas, incluye un filtro en las reglas que use datos de las fuentes de enriquecimiento del contexto global. Este filtro debe identificar el tipo o la fuente de enriquecimiento específicos.

Los siguientes parámetros de filtro identifican el tipo o la fuente de enriquecimiento: entity_type, product_name y vendor_name.

Por ejemplo, incluye los siguientes campos de filtro en la sección events de la regla que une los datos de WHOIS:

$enrichment.graph.metadata.entity_type = "DOMAIN_NAME"
$enrichment.graph.metadata.product_name = "WHOISXMLAPI Simple Whois"
$enrichment.graph.metadata.vendor_name = "WHOIS"

Nota: Conocer la fuente de enriquecimiento puede ser tan valioso como los datos en sí, y un solo campo del UDM puede tener varias fuentes de enriquecimiento. Puedes ver esta información en el Visor de eventos o con una búsqueda de eventos de UDM (por ejemplo, principal.hostname="john.doe.desktop" metadata.event_type="NETWORK_CONNECTION").

Prácticas recomendadas para el ECG

Cuando uses datos enriquecidos contextualmente, ten en cuenta las siguientes prácticas recomendadas para el ECG:

• No agregues intervalos a los datos de la entidad; en su lugar, deja que la canalización de ECG los cree. Google SecOps genera intervalos durante la deduplicación, a menos que se especifique lo contrario.
• Si especificas los intervalos, Google SecOps solo anula la duplicación de los eventos idénticos y conserva la entidad más reciente.
• Para garantizar que las reglas activas y las búsquedas retroactivas funcionen según lo previsto, debes transferir entidades al menos una vez al día.
• Si no ingieres entidades a diario, sino solo una vez cada dos o más días, es posible que las reglas activas sigan funcionando según lo previsto. Sin embargo, es posible que las búsquedas retroactivas pierdan algunos contextos de eventos.
• Si ingieres entidades idénticas más de una vez al día, Google SecOps las deduplica en una sola entidad.
• Si faltan datos de eventos para un día, Google SecOps usa temporalmente los datos del día anterior para garantizar que las reglas activas funcionen correctamente.

Para obtener detalles sobre los límites generales del servicio de Google SecOps, consulta Límites del servicio.

Contenido externo relacionado

• Cómo usar el Gráfico de entidad como una lista multidimensional
• Creación de alias en Chronicle SIEM
• IOCs que vencen en el gráfico de entidad
• Navegación segura de Google en Chronicle SIEM

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