Descripción general de UDM

Compatible con:

Google SecOps SIEM

En este documento, se proporciona una descripción general del modelo de datos unificado (UDM). Para obtener más detalles sobre los campos de UDM, incluida una descripción de cada uno, consulta la lista de campos de UDM. Para obtener más información sobre la asignación de analizadores, consulta Campos de UDM importantes para la asignación de analizadores.

El UDM es una estructura de datos estándar de Google Security Operations que almacena información sobre los datos recibidos de las fuentes. También se denomina esquema. Google SecOps almacena los datos originales que recibe en dos formatos: como el registro sin procesar original y como un registro de UDM estructurado. El registro de UDM es una representación estructurada del registro original.

Si existe un analizador para el tipo de registro especificado, el registro sin procesar se usa para crear un registro de UDM. Los clientes también pueden transformar los registros sin procesar en formato de UDM estructurado antes de enviar los datos a Google SecOps con la API de Ingestion.

Algunos de los beneficios del UDM son los siguientes:

• Almacena el mismo tipo de registro de diferentes proveedores con la misma semántica.
• Es más fácil identificar las relaciones entre los usuarios, los hosts y las direcciones IP, ya que los datos se normalizan en el esquema de UDM estándar.
• Es más fácil escribir reglas, ya que pueden ser independientes de la plataforma.
• Es más fácil admitir tipos de registros de dispositivos nuevos.

Nota: El motor de reglas de Google SecOps usa los mismos nombres de campo de UDM. Puedes usar estos mismos nombres de campo cuando crees reglas.

Aunque puedes buscar eventos con una búsqueda de registros sin procesar, una búsqueda de UDM funciona más rápido y con más precisión debido a su especificidad. Google SecOps recopila datos de registro sin procesar y almacena los detalles del registro de eventos en el esquema de UDM. El UDM proporciona un marco de trabajo integral de miles de campos para describir y categorizar diversos tipos de eventos, por ejemplo, eventos de procesos de extremos y eventos de comunicación de red.

Estructura de UDM

Los eventos de UDM se componen de varias secciones. La primera sección que se encuentra en cada evento de UDM es la sección de metadatos. Proporciona una descripción básica del evento, incluida la marca de tiempo en la que ocurrió el evento y la marca de tiempo en la que se ingirió en Google SecOps. También incluye la información del producto, la versión y la descripción. El analizador de transferencia clasifica cada evento según un tipo de evento predefinido, independientemente del registro de producto específico. Solo con los campos de metadatos, puedes comenzar a buscar los datos rápidamente.

Además de la sección de metadatos, otras secciones describen aspectos adicionales del evento. Si una sección no es necesaria, no se incluye, lo que ahorra memoria.

• principal: Es la entidad que origina la actividad en el evento. También se incluyen las secciones que hacen referencia al origen (src) y al destino (target).
• intermediary: Son los sistemas por los que pasan los eventos, como un servidor proxy o una retransmisión de SMTP.
• observer: Son sistemas, como los analizadores de paquetes, que supervisan el tráfico de forma pasiva.

Asigna un formato a un evento de UDM

Para dar formato a un evento de UDM y prepararlo para enviarlo a Google, debes completar los siguientes pasos:

1. Especifica el tipo de evento: El tipo de evento que selecciones determinará qué campos también debes incluir con el evento.
2. Especifica la marca de tiempo del evento.
3. Especifica sustantivos (entidades): Cada evento debe incluir, al menos, un sustantivo que describa un dispositivo o usuario participante que esté involucrado en el evento.
4. Opcional: Especifica el resultado de seguridad: Especifica los resultados de seguridad incluyendo detalles sobre los riesgos y las amenazas que encuentra un sistema de seguridad. Incluye las acciones específicas que se tomaron para mitigar esos riesgos y amenazas.
5. Completa el resto de la información obligatoria y opcional del evento con los campos de eventos de UDM.

Especifica el tipo de evento

Siempre debes especificar el tipo de evento para cada evento enviado en formato de UDM. Especifica este valor con uno de los valores posibles disponibles para metadata.event_type. Estos incluyen valores como PROCESS_OPEN, FILE_CREATION, USER_CREATION y NETWORK_DNS (para obtener la lista completa, consulta Metadata.event_type). Cada tipo de evento requiere que también completes un conjunto de otros campos y valores con la información vinculada al evento original. Para obtener detalles sobre qué campos incluir para cada tipo de evento, consulta Campos obligatorios y opcionales para cada tipo de evento.

En el siguiente ejemplo, se muestra cómo especificar PROCESS_OPEN como el tipo de evento con la notación de texto de Proto3:

metadata {
    event_type: PROCESS_OPEN
}

Especifica la marca de tiempo del evento

Debes especificar la marca de tiempo de GMT para cualquier evento enviado en formato de UDM con Metadata.event_timestamp. El sello debe codificarse con uno de los siguientes estándares:

• Para JSON, usa RFC 3339
• Marca de tiempo de Proto3

En el siguiente ejemplo, se muestra cómo especificar la marca de tiempo con el formato RFC 3339. Para este ejemplo, aaaa-mm-ddThh:mm:ss+hh:mm: año, mes, día, hora, minuto, segundo y la diferencia con la hora UTC. La diferencia con respecto a la hora UTC es de menos 8 horas, lo que indica la hora PST.

metadata {
  event_timestamp: "2019-09-10T20:32:31-08:00"
}

Especifica sustantivos (entidades)

Define uno o más sustantivos para cada evento de UDM. Los sustantivos representan participantes o entidades, como el usuario que realiza la actividad, el objetivo de la acción o el dispositivo de seguridad que observa el evento (por ejemplo, un proxy de correo electrónico o un router). Los sustantivos también representan objetos, como URLs o archivos adjuntos.

Precaución: En los eventos de UDM, los campos de nombre de host tienen un límite de caracteres de 256 (por ejemplo, principal.hostname o target.hostname). La asignación de registros sin procesar (desde una fuente como ArcSight) que superan este límite genera fallas de validación y registros descartados. Esto no es específico de los analizadores individuales.

Un evento de UDM debe tener uno o más de los siguientes sustantivos especificados:

principal: Representa la entidad que actúa o el dispositivo que origina la actividad descrita en el evento. La entidad principal debe incluir al menos un detalle de la máquina (nombre de host, MAC, IP, puerto, identificadores específicos del producto, como un GUID de máquina de CrowdStrike) o un detalle del usuario (por ejemplo, el nombre de usuario) y, de forma opcional, incluir detalles del proceso. NO debe incluir ninguno de los siguientes campos: correo electrónico, archivos, claves de registro o valores.

Si toda la actividad se produce en una sola máquina, descríbela solo en el bloque principal. No dupliques los detalles de la máquina en target ni en src.

Nota: No describas los dispositivos de seguridad en el campo principal, incluso si originan el evento. En su lugar, usa los campos observer o intermediary. Si el software de seguridad se ejecuta en el mismo dispositivo que originó la actividad (como un agente de EDR en un extremo de Windows), ese dispositivo sigue siendo la principal.

En el siguiente ejemplo, se muestra cómo se podrían propagar los campos principal:

principal {
  hostname: "jane_win10"
  asset_id: "Sophos.AV:C070123456-ABCDE"
      ip: "10.0.2.10"
      port: 60671
      user {  userid: "john.smith" }
}

En este ejemplo, se proporcionan detalles sobre el dispositivo y el usuario que fue el actor principal del evento. También incluye un identificador de recurso específico del proveedor (de Sophos), que es un ID único que genera el producto de seguridad de terceros.

target: Representa el dispositivo o el objeto al que hace referencia el evento. En una conexión de firewall del dispositivo A al dispositivo B, A es la principal y B es el destino. En una inyección de proceso en la que el proceso C se inserta en el proceso D, C es el principal y D es el destino.

Principal versus destino en UDM

En el siguiente ejemplo, se muestra cómo se completan los campos de un destino:

target {
   ip: "198.51.100.31"
   port: 80
}

Incluye cualquier otra información disponible en el bloque target, como el nombre de host, las direcciones IP o dirección MAC adicionales y los identificadores de recursos de propiedad.

Tanto principal como destino (y otros sustantivos) pueden hacer referencia a actores en la misma máquina. Por ejemplo, si el proceso A (principal) que se ejecuta en la máquina X actúa en el proceso B (destino) también en la máquina X, debes describir ambos en sus bloques respectivos.

• src: Representa el objeto de origen sobre el que se actúa y su contexto, como la máquina en la que reside. Por ejemplo, si el usuario U copia el archivo A en la máquina X en el archivo B en la máquina Y, especifica el archivo A y la máquina X en el bloque src.

• intermediary: Contiene detalles de uno o más dispositivos que procesaron la actividad descrita en el evento. Esto incluye información para dispositivos, como servidores proxy y retransmisiones SMTP.

• observer: Representa un dispositivo que no es un intermediario directo, pero supervisa y genera informes sobre la actividad. Esto incluye dispositivos como analizadores de paquetes o escáneres de vulnerabilidades basados en la red.

• about: Almacena detalles de cualquier objeto al que haga referencia el evento que no se ajuste a participant, src, target, intermediary o observer. Úsala para hacer un seguimiento de lo siguiente:

  • Archivos adjuntos de correos electrónicos
  • Dominios, URLs o IPs incorporados en el cuerpo de un correo electrónico
  • DLL que se cargan durante un evento de PROCESS_LAUNCH

Las secciones de entidad de los eventos de UDM incluyen información sobre los distintos participantes (dispositivos, usuarios, objetos como URLs, archivos, etc.) que se describen en el evento. El UDM de Google Security Operations tiene requisitos obligatorios cuando se trata de completar campos de sustantivos. Estos requisitos se describen en Campos obligatorios y opcionales para cada tipo de evento de UDM. El conjunto de campos de entidad que se deben completar varía según el tipo de evento.

Especifica el resultado de seguridad

De manera opcional, puedes especificar los resultados de seguridad completando los campos de SecurityResult, incluidos los detalles sobre los riesgos y las amenazas de seguridad que encontró el sistema de seguridad, así como las medidas que se tomaron para mitigar esos riesgos y amenazas. A continuación, se muestran ejemplos de algunos de los tipos de eventos de seguridad que requerirían completar los campos de SecurityResult:

• Un firewall de proxy de seguridad de correo electrónico detectó dos archivos adjuntos infectados (SOFTWARE_MALICIOUS). Los puso en cuarentena y los desinfectó (CUARENTENA, PERMITIR_CON_MODIFICACIÓN) y, luego, reenvió el correo electrónico desinfectado.

• Un sistema de SSO facilitó un intento de acceso que generó un AUTH_VIOLATION y se bloqueó (BLOCK).

• Una zona de pruebas de software malicioso detectó software espía (SOFTWARE_MALICIOUS) en un archivo adjunto cinco minutos después de que el sistema entregara (ALLOW) el correo electrónico a la carpeta Recibidos del usuario.

Ejemplos de búsquedas de UDM

En esta sección, se proporcionan ejemplos de búsquedas de UDM que demuestran algunas de las sintaxis, funciones y capacidades básicas de la búsqueda de UDM.

Ejemplo: Busca accesos exitosos de Microsoft Windows 4624

En la siguiente búsqueda, se enumeran los eventos de acceso exitoso de Microsoft Windows 4624, junto con el momento en que se generaron, según solo dos campos de UDM:

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624"

Ejemplo: Busca todos los accesos exitosos

En la siguiente búsqueda, se enumeran todos los eventos de acceso exitosos, sin importar el proveedor ni la aplicación:

metadata.event_type = "USER_LOGIN" AND security_result.action = "ALLOW" AND target.user.userid != "SYSTEM" AND target.user.userid != /.*$/

Ejemplo: Busca accesos de usuario exitosos

En el siguiente ejemplo, se ilustra cómo buscar userid "fkolzig" y determinar cuándo accedió correctamente el usuario con este ID de usuario. Puedes completar esta búsqueda con la sección de destino. La sección de destino incluye apartados y campos que describen el destino. Por ejemplo, el objetivo en este caso es un usuario y tiene una serie de atributos asociados, pero el objetivo también podría ser un archivo, un parámetro de configuración del registro o un recurso. En este ejemplo, se busca "fkolzig" con el campo target.user.userid.

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624" AND target.user.userid = "fkolzig"

Ejemplo: Busca los datos de tu red

En el siguiente ejemplo, se buscan datos de red para eventos de RDP con un target.port de 3389 y un principal.ip de 35.235.240.5. También incluye un campo de UDM de la sección de red, la dirección de los datos (network.direction).

metadata.product_event_type = "3" AND target.port = 3389 AND network.direction = "OUTBOUND" and principal.ip = "35.235.240.5"

Ejemplo: Busca un proceso específico

Para examinar los procesos creados en tus servidores, busca instancias del comando net.exe y busca este archivo específico en su ruta de acceso esperada. El campo que buscas es target.process.file.full_path. Para esta búsqueda, incluye el comando específico emitido en el campo target.process.command_line. También puedes agregar un campo en la sección de información, que es la descripción del código de evento 1 de Microsoft Sysmon (ProcessCreate).

Esta es la búsqueda de UDM:

metadata.product_event_type = "1" AND target.process.file.full_path = "C:\Windows\System32\net.exe"

De manera opcional, puedes agregar los siguientes campos de búsqueda de UDM:

• principal.user.userid: Identifica al usuario que emite el comando.
• principal.process.file.md5: Identifica el hash MD5.
• principal.process.command_line: Línea de comandos.

Ejemplo: Busca accesos de usuarios exitosos asociados con un departamento específico

En el siguiente ejemplo, se buscan los accesos de los usuarios (metadata.event_type es USER_LOGIN) asociados con el departamento de marketing (target.user.department es marketing) de tu empresa. Aunque target.user.department no está conectado directamente con los eventos de acceso de los usuarios, sigue presente en los datos de LDAP transferidos sobre tus usuarios.

metadata.event_type = "USER_LOGIN" AND target.user.department = "Marketing"

Objetos lógicos: Evento y Entidad

El esquema de UDM describe todos los atributos disponibles que almacenan datos. Cada registro de UDM identifica si describe un evento o una entidad. Los datos se almacenan en diferentes campos según si el registro describe un evento o una entidad, y también según el valor que se establece en el campo metadata.event_type o metadata.entity_type.

• Evento de UDM: Almacena datos de una acción que se produjo en el entorno. El registro de eventos original describe la acción tal como la registró el dispositivo, como el firewall y el proxy web.
• Entidad de UDM: Es la representación contextual de elementos, como recursos, usuarios y recursos en tu entorno. Se obtiene de una fuente de datos de fuente de verdad.

A continuación, se muestran dos representaciones visuales de alto nivel del modelo de datos de eventos y el modelo de datos de entidades.

Nota: El término Sustantivo describe el tipo de atributo. Los términos principal, target, src, intermediary, observer y about son los nombres de los campos en los que se almacenan los datos.

Figura: Modelo de datos de eventos

Nota: El término Sustantivo describe el tipo de atributo. Los términos recurso, usuario y recurso son los nombres de los campos en los que se almacenan los datos.

Figura: Modelo de datos de entidad

Estructura de un evento de UDM

El evento de UDM contiene varias secciones que almacenan un subconjunto de los datos para un solo registro. Las secciones son las siguientes:

• metadatos
• entidad
• objetivo
• src
• observador
• intermediario
• acerca de
• red
• security_result

• extensiones

  

  Figura: Modelo de datos de eventos

En la sección metadata, se almacena la marca de tiempo, se define el event_type y se describe el dispositivo.

En las secciones principal, target, src, observer y intermediary, se almacena información sobre los objetos involucrados en el evento. Un objeto puede ser un dispositivo, un usuario o un proceso. La mayoría de las veces, solo se usa un subconjunto de estas secciones. Los campos que almacenan datos se determinan según el tipo de evento y el rol que cada objeto desempeña en el evento.

La sección network almacena información relacionada con la actividad de red, como la comunicación relacionada con la red y el correo electrónico.

• Datos de correo electrónico: Información en los campos to, from, cc, bcc y otros campos de correo electrónico.
• Datos HTTP: como method, referral_url y useragent.

En la sección security_result, se almacena una acción o clasificación registrada por un producto de seguridad, como un producto antivirus.

Las secciones about y extensions almacenan información adicional de eventos específicos del proveedor que no capturan las otras secciones. La sección extensions es un conjunto de pares clave-valor de formato libre.

Cada evento de UDM almacena valores de un evento de registro sin procesar original. Según el tipo de evento, algunos atributos son obligatorios, mientras que otros son opcionales. Los atributos obligatorios y opcionales se determinan según el valor de metadata.event_type. Google SecOps lee metadata.event_type y realiza la validación de campos específica para ese tipo de evento después de que se reciben los registros.

Si no se almacenan datos en una sección del registro de UDM, por ejemplo, la sección de extensiones, esa sección no aparecerá en el registro de UDM.

Los campos de metadatos

En esta sección, se describen los campos obligatorios en un evento de UDM.

El campo event_timestamp

Los eventos de UDM deben incluir datos para el metadata.event_timestamp, que es la marca de tiempo de GMT en la que se produjo el evento. El valor debe codificarse con uno de los siguientes estándares: RFC 3339 o marca de tiempo de Proto3.

En los siguientes ejemplos, se ilustra cómo especificar la marca de tiempo con el formato RFC 3339, yyyy-mm-ddThh:mm:ss+hh:mm (año, mes, día, hora, minuto, segundo y la diferencia con la hora UTC). La diferencia con respecto a la hora UTC es de menos 8 horas, lo que indica la hora PST.

metadata {
  "event_timestamp": "2019-09-10T20:32:31-08:00"
}

metadata {
  event_timestamp: "2021-02-23T04:00:00.000Z"
}

También puedes especificar el valor con el formato de época.

metadata {
event_timestamp: {
  "seconds": 1588180305
 }
}

El campo event_type

El campo más importante en el evento de UDM es metadata.event_type. Este valor identifica el tipo de acción realizada y es independiente del proveedor, el producto o la plataforma. Entre los valores de ejemplo, se incluyen PROCESS_OPEN, FILE_CREATION, USER_CREATION y NETWORK_DNS. Para obtener la lista completa, consulta el documento Lista de campos de UDM.

El valor metadata.event_type determina qué campos obligatorios y opcionales adicionales se deben incluir en el registro de UDM. Para obtener información sobre qué campos incluir para cada tipo de evento, consulta la guía de uso de UDM.

Los atributos principal, target, src, intermediary, observer y about

Los atributos principal, target, src, intermediary y observer describen los recursos que participan en el evento. Cada uno almacena información sobre los objetos involucrados en la actividad, según lo registrado por el registro sin procesar original. Puede ser el dispositivo o el usuario que realizó la actividad, o el dispositivo o el usuario que es el objetivo de la actividad. También puede describir un dispositivo de seguridad que observó la actividad, como un proxy de correo electrónico o un router de red.

Los atributos de uso frecuente son los siguientes:

• principal: Es el objeto que realizó la actividad.
• src: Es el objeto que inicia la actividad, si es diferente de la principal.
• target: Es el objeto sobre el que se actúa.

Cada tipo de evento requiere que al menos uno de estos campos contenga datos.

Los campos auxiliares son los siguientes:

• intermediary: Cualquier objeto que haya actuado como intermediario en el evento. Esto podría incluir objetos como servidores proxy y servidores de correo electrónico.
• observer: Cualquier objeto que no interactúe directamente con el tráfico en cuestión. Podría ser un escáner de vulnerabilidades o un dispositivo de análisis de paquetes.
• about: Cualquier otro objeto que haya desempeñado un rol en el evento y que sea opcional.

Los atributos principales

Representa la entidad que actúa o el dispositivo que originó la actividad. La principal debe incluir al menos un detalle de la máquina (nombre de host, dirección MAC, dirección IP, identificadores específicos del producto, como un GUID de máquina de CrowdStrike) o un detalle del usuario (por ejemplo, el nombre de usuario) y, de forma opcional, incluir detalles del proceso. No debe incluir ninguno de los siguientes campos: correo electrónico, archivos, claves o valores de registro.

Si el evento se produce en una sola máquina, esta se describe solo en el atributo principal. No es necesario describir la máquina en los atributos target o src.

Nota: Un dispositivo de seguridad puede registrar un evento, pero no se describiría en el atributo principal. Se describiría en el atributo de observador o intermediario. Si el software de seguridad (por ejemplo, Carbon Black) se ejecuta en el mismo dispositivo que originó la actividad (por ejemplo, un extremo de Windows en el que se detectó malware), el dispositivo de Windows sería la principal.

En el siguiente fragmento de JSON, se ilustra cómo se podría propagar el atributo principal.

"principal": {
  "hostname": "jane_win10",
  "asset_id" : "Sophos.AV:C070123456-ABCDE",
    "ip" : "10.10.2.10",
    "port" : 60671,
    "user": {  "userid" : "john.smith" }
}

Este atributo describe todo lo que se sabe sobre el dispositivo y el usuario que fue el actor principal en el evento. En este ejemplo, se incluyen la dirección IP, el número de puerto y el nombre de host del dispositivo. También incluye un identificador de recurso específico del proveedor, de Sophos, que es un identificador único que genera el producto de seguridad de terceros.

Los atributos de destino

Representa un dispositivo de destino al que hace referencia el evento o un objeto en el dispositivo de destino. Por ejemplo, en una conexión de firewall del dispositivo A al dispositivo B, el dispositivo A se captura como el principal y el dispositivo B se captura como el destino.

Para una inyección de proceso por parte del proceso C en el proceso de destino D, el proceso C es el principal y el proceso D es el destino.

Figura: Principal frente a destino

En el siguiente ejemplo, se ilustra cómo se podría propagar el campo de destino.

target {
   ip: "192.0.2.31"
   port: 80
}

Si hay más información disponible en el registro sin procesar original, como el nombre de host, las direcciones IP adicionales, las direcciones MAC y los identificadores de recursos de propiedad, también se debe incluir en los campos de destino y principal.

Tanto el principal como el objetivo pueden representar actores en la misma máquina. Por ejemplo, el proceso A (principal) que se ejecuta en la máquina X podría actuar en el proceso B (destino) también en la máquina X.

El atributo src

Representa un objeto de origen sobre el que actúa el participante junto con el contexto del dispositivo o del proceso para el objeto de origen (la máquina en la que reside el objeto de origen). Por ejemplo, si el usuario U copia el archivo A en la máquina X en el archivo B en la máquina Y, tanto el archivo A como la máquina X se especificarán en la parte src del evento de UDM.

El atributo intermediario

Representa detalles sobre la actividad de procesamiento de uno o más dispositivos intermedios descritos en el evento. Esto podría incluir detalles sobre dispositivos, como servidores proxy y servidores de retransmisión SMTP.

El atributo de observador

Representa un dispositivo observador que no es un intermediario directo, pero que observa el evento en cuestión y genera informes sobre él. Esto podría incluir un analizador de paquetes o un escáner de vulnerabilidades basado en la red.

El atributo about

En este campo, se almacenan detalles sobre un objeto al que hace referencia el evento que no se describe en los campos principal, src, target, intermediary ni observer. Por ejemplo, podría capturar lo siguiente:

• Archivos adjuntos de correos electrónicos
• Dominios, URLs o direcciones IP incorporados en el cuerpo del correo electrónico.
• Son las DLL que se cargan durante un evento PROCESS_LAUNCH.

El atributo security_result

En esta sección, se incluye información sobre los riesgos y las amenazas de seguridad que detecta un sistema de seguridad y las acciones que se realizan para mitigar esos riesgos y amenazas.

Estos son los tipos de información que se almacenarían en el atributo security_result:

• Un proxy de seguridad de correo electrónico detectó un intento de phishing (security_result.category = MAIL_PHISHING) y bloqueó (security_result.action = BLOCK) el correo electrónico.
• Un firewall de proxy de seguridad de correo electrónico detectó dos archivos adjuntos infectados (security_result.category = SOFTWARE_MALICIOUS), los puso en cuarentena y los desinfectó (security_result.action = QUARANTINE or security_result.action = ALLOW_WITH_MODIFICATION) y, luego, reenvió el correo electrónico desinfectado.
• Un sistema de SSO permite un acceso (security_result.category = AUTH_VIOLATION) que se bloqueó (security_result.action = BLOCK).
• Una zona de pruebas de software malicioso detectó software espía (security_result.category = SOFTWARE_MALICIOUS) en un archivo adjunto cinco minutos después de que se entregara el archivo (security_result.action = ALLOW) al usuario en su carpeta Recibidos.

El atributo de red

Los atributos de red almacenan datos sobre eventos relacionados con la red y detalles sobre los protocolos dentro de los submensajes. Esto incluye la actividad, como los correos electrónicos enviados y recibidos, y las solicitudes HTTP.

El atributo extensions

Los campos de este atributo almacenan metadatos adicionales sobre el evento capturado en el registro sin procesar original. Puede contener información sobre vulnerabilidades o información adicional relacionada con la autenticación.

Estructura de una entidad de UDM

Un registro de entidad de UDM almacena información sobre cualquier entidad dentro de una organización. Si el metadata.entity_type es USER, el registro almacena información sobre el usuario en el atributo entity.user. Si el metadata.entity_type es ASSET, el registro almacena información sobre un activo, como una estación de trabajo, una laptop, un teléfono y una máquina virtual.

Figura: Modelo de datos de eventos

Los campos de metadatos

Esta sección contiene campos obligatorios en una entidad de UDM, como los siguientes:

• collection_timestamp: Es la fecha y hora en que se recopiló el registro.
• entity_type: Es el tipo de entidad, como activo, usuario y recurso.

El atributo de entidad

Los campos que se encuentran debajo del atributo de entidad almacenan información sobre la entidad específica, como el nombre de host y la dirección IP si se trata de un recurso, o windows_sid y la dirección de correo electrónico si se trata de un usuario. Observa que el nombre del campo es entity, pero el tipo de campo es un sustantivo. Un sustantivo es una estructura de datos de uso frecuente que almacena información tanto en entidades como en eventos.

• Si el metadata.entity_type es USER, los datos se almacenan en el atributo entity.user.
• Si el metadata.entity_type es ASSET, los datos se almacenan en el atributo entity.asset.

El atributo de relación

Los campos que se encuentran debajo del atributo de relación almacenan información sobre otras entidades con las que se relaciona la entidad principal. Por ejemplo, si la entidad principal es un usuario y se le asignó una laptop. La laptop es una entidad relacionada. La información sobre la laptop se almacena como un registro entity con un metadata.entity_type = ASSET. La información sobre el usuario se almacena como un registro entity con metadata.entity_type = USER.

El registro de la entidad de usuario también captura la relación entre el usuario y la laptop, con campos en el atributo relation. El campo relation.relationship almacena la relación que tiene el usuario con la laptop, específicamente que el usuario es propietario de la laptop. El campo relation.entity_type almacena el valor ASSET, ya que la laptop es un dispositivo.

Los campos que se encuentran debajo del atributo relations.entity almacenan información sobre la laptop, como el nombre de host y la dirección MAC. Observa de nuevo que el nombre del campo es entity y el tipo de campo es un sustantivo. Un Noun es una estructura de datos de uso general. Los campos que se encuentran debajo del atributo relation.entity almacenan información sobre la laptop.

El campo relation.direction almacena la direccionalidad de la relación entre el usuario y la laptop, específicamente si la relación es bidireccional o unidireccional.

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