Información general sobre el modelo de datos unificado

En este documento se ofrece una descripción general del modelo de datos unificado (UDM). Para obtener más información 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 registro sin procesar original y como registro UDM estructurado. El registro UDM es una representación estructurada del registro original.

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

Estas son algunas de las ventajas de la gestión unificada de datos:

• Almacena el mismo tipo de registro de diferentes proveedores con la misma semántica.
• Es más fácil identificar las relaciones entre usuarios, hosts y direcciones IP, ya que los datos se normalizan en el esquema 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.

Aunque puedes buscar eventos con una búsqueda de registros sin procesar, una búsqueda de UDM funciona más rápido y con mayor precisión debido a su especificidad. Google SecOps recoge datos de registro sin procesar y almacena los detalles del registro de eventos en el esquema del modelo de datos unificado (UDM). UDM proporciona un marco de trabajo completo con miles de campos para describir y categorizar diversos tipos de eventos, como eventos de procesos de endpoint 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 todos los eventos de UDM es la sección de metadatos. Proporciona una descripción básica del evento, incluida la marca de tiempo en la que se produjo 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 ingestión clasifica cada evento en función de un tipo de evento predefinido, independientemente del registro de producto específico. Con los campos de metadatos, puedes empezar a buscar datos rápidamente.

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

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

Ejemplos de búsquedas de UDM

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

Ejemplo: buscar inicios de sesión correctos de Microsoft Windows 4624

La siguiente búsqueda muestra los eventos de inicio de sesión correctos de Microsoft Windows 4624, junto con la hora en la que se generaron, basándose en solo dos campos de UDM:

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

Ejemplo: buscar todos los inicios de sesión correctos

La siguiente búsqueda muestra todos los eventos de inicio de sesión correctos, independientemente del proveedor o de la aplicación:

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

Ejemplo: buscar inicios de sesión de usuarios correctos

En el siguiente ejemplo se muestra cómo buscar userid "fkolzig" y determinar cuándo inició sesión correctamente el usuario con este ID de usuario. Puedes completar esta búsqueda en la sección de segmentación. La sección de destino incluye subsecciones y campos que describen el destino. Por ejemplo, en este caso, el objetivo es un usuario y tiene varios atributos asociados, pero también podría ser un archivo, un ajuste 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: buscar en los datos de tu red

En el siguiente ejemplo se buscan datos de red de eventos RDP con un target.port de 3389 y un principal.ip de 35.235.240.5. También incluye un campo 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: buscar 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 la ruta esperada. El campo que estás buscando 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 añadir un campo en la sección de información que sea 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"

También puede añadir los siguientes campos de búsqueda de UDM:

• principal.user.userid: identifica al usuario que envía el comando.
• principal.process.file.md5: identifica el hash MD5.
• principal.process.command_line: línea de comandos.

Ejemplo: buscar inicios de sesión de usuarios correctos asociados a un departamento concreto

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

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

Objetos lógicos: Event y Entity

El esquema de UDM describe todos los atributos disponibles que almacenan datos. Cada registro de UDM indica si describe un evento o una entidad. Los datos se almacenan en campos diferentes en función de si el registro describe un evento o una entidad, y también en función del valor que se haya definido en el campo metadata.event_type o metadata.entity_type.

• Evento UDM: almacena datos de una acción que se ha producido en el entorno. El registro de eventos original describe la acción tal como la ha registrado el dispositivo, como el firewall y el proxy web.
• Entidad de UDM: representación contextual de elementos como recursos, usuarios y recursos de su entorno. Se obtiene de una fuente de datos fuente de veracidad.

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

Gráfico: modelo de datos de eventos

Imagen: Modelo de datos de entidad

Estructura de un evento de UDM

El evento de UDM contiene varias secciones, cada una de las cuales almacena un subconjunto de los datos de un solo registro. Las secciones son las siguientes:

• metadata
• capital
• target
• src
• observador
• intermediario
• about
• red
• security_result

• extensiones

  

  Gráfico: modelo de datos de eventos

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

Las secciones principal, target, src, observer y intermediary almacenan información sobre los objetos implicados 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 en función del tipo de evento y del rol que desempeña cada objeto en el evento.

La sección Red 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 de los campos to, from, cc, bcc y otros campos de correo electrónico.
• Datos HTTP: como method, referral_url y useragent.

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

Las secciones about y extensions almacenan información adicional sobre eventos específicos del proveedor que no se recoge en las demás 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. En función del tipo de evento, algunos atributos son obligatorios y otros opcionales. Los atributos obligatorios y opcionales se determinan en función del metadata.event_type valor. Google SecOps lee metadata.event_type y realiza una validación de campo específica para ese tipo de evento después de recibir 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 de un evento de UDM.

El campo event_timestamp

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

En los siguientes ejemplos se muestra 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 UTC es de -8 horas, lo que indica la zona horaria PST.

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

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

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

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

Campo event_type

El campo más importante del 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. Por ejemplo, PROCESS_OPEN, FILE_CREATION, USER_CREATION y NETWORK_DNS. Para ver la lista completa, consulta el documento Lista de campos de UDM.

El valor de metadata.event_type determina qué campos obligatorios y opcionales adicionales se deben incluir en el registro de UDM. Para obtener información sobre los campos que debe incluir en cada tipo de evento, consulte 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 implicados en la actividad, tal como se registra en el registro sin procesar original. Puede tratarse del dispositivo o del usuario que ha realizado la actividad, o bien del dispositivo o del usuario que es el objetivo de la actividad. También puede describir un dispositivo de seguridad que haya observado la actividad, como un proxy de correo o un router de red.

Los atributos más habituales son los siguientes:

• principal: objeto que ha realizado la actividad.
• src: objeto que inicia la actividad, si es diferente del principal.
• target: objeto sobre el que se actúa.

En cada tipo de evento, al menos uno de estos campos debe contener 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.
• observer: cualquier objeto que no interactúe directamente con el tráfico en cuestión. Puede tratarse de un escáner de vulnerabilidades o de un dispositivo de rastreo de paquetes.
• about: cualquier otro objeto que haya tenido un papel en el evento (opcional).

Atributos principales

Representa la entidad o el dispositivo que ha iniciado la actividad. El 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, opcionalmente, detalles del proceso. No debe incluir ninguno de los siguientes campos: correo electrónico, archivos, claves o valores del registro.

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

En el siguiente fragmento de JSON se muestra cómo se puede rellenar 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 del 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 generado por el producto de seguridad de terceros.

Los atributos de destino

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

En 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 de destino.

Gráfico: Principal frente a objetivo

En el siguiente ejemplo se muestra cómo se podría rellenar 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 propietarios, también se debe incluir en los campos de destino y principal.

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

Atributo src

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

Atributo intermediary

Representa los detalles de uno o varios dispositivos intermedios que procesan la actividad descrita en el evento. Esto podría incluir detalles sobre dispositivos como servidores proxy y servidores de retransmisión SMTP.

Atributo observer

Representa un dispositivo observador que no es un intermediario directo, sino que observa e informa sobre el evento en cuestión. Esto podría incluir un analizador de paquetes o un escáner de vulnerabilidades basado en la red.

El atributo about

Almacena detalles sobre un objeto al que hace referencia el evento y que no se describe en los campos principal, src, target, intermediary u observer. Por ejemplo, podría registrar lo siguiente:

• Archivos adjuntos de correo electrónico.
• Dominios, URLs o direcciones IP insertados en el cuerpo de un correo.
• DLLs que se cargan durante un evento PROCESS_LAUNCH.

Atributo security_result

Esta sección contiene información sobre los riesgos y las amenazas de seguridad que detecta un sistema de seguridad, así como las medidas que se toman para mitigarlos.

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

• Un proxy de seguridad de correo ha detectado un intento de phishing (security_result.category = MAIL_PHISHING) y ha bloqueado (security_result.action = BLOCK) el correo.
• Un cortafuegos proxy de seguridad de correo ha detectado dos archivos adjuntos infectados (security_result.category = SOFTWARE_MALICIOUS) y los ha puesto en cuarentena y desinfectado (security_result.action = QUARANTINE or security_result.action = ALLOW_WITH_MODIFICATION). Después, ha reenviado el correo desinfectado.
• Un sistema de SSO permite un inicio de sesión (security_result.category = AUTH_VIOLATION) que se ha bloqueado (security_result.action = BLOCK).
• Un entorno aislado de malware ha detectado spyware (security_result.category = SOFTWARE_MALICIOUS) en un archivo adjunto cinco minutos después de que se enviara (security_result.action = ALLOW) al usuario en su bandeja de entrada.

Atributo de red

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

Atributo extensions

Los campos de este atributo almacenan metadatos adicionales sobre el evento registrado 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 de una organización. Si el valor de 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 recurso, como una estación de trabajo, un portátil, un teléfono o una máquina virtual.

Gráfico: modelo de datos de eventos

Los campos de metadatos

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

• collection_timestamp: fecha y hora en las que se recogió el registro.
• entity_type: el tipo de entidad, como recurso, usuario y recurso.

El atributo de entidad

Los campos 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 el SID de Windows y la dirección de correo electrónico si se trata de un usuario. Ten en cuenta que el nombre del campo es entity, pero el tipo de campo es un sustantivo. Un sustantivo es una estructura de datos que se usa con frecuencia y 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 metadata.entity_type es ASSET, los datos se almacenan en el atributo entity.asset.

Atributo de relación

Los campos del atributo de relación almacenan información sobre otras entidades con las que está relacionada la entidad principal. Por ejemplo, si la entidad principal es un usuario y se le ha asignado un portátil. El portátil es una entidad relacionada. La información sobre el portátil se almacena como un registro entity con 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 registra la relación entre el usuario y el portátil mediante los campos del atributo relation. El campo relation.relationship almacena la relación que tiene el usuario con el portátil, concretamente que el usuario es el propietario del portátil. El campo relation.entity_type almacena el valor ASSET, porque el portátil es un dispositivo.

Los campos del atributo relations.entity almacenan información sobre el portátil, como el nombre de host y la dirección MAC. Fíjate de nuevo en que el nombre del campo es entity y el tipo de campo es Noun. Un sustantivo es una estructura de datos que se usa con frecuencia. Los campos del atributo relation.entity almacenan información sobre el portátil.

El campo relation.direction almacena la direccionalidad de la relación entre el usuario y el portátil, concretamente si la relación es bidireccional o unidireccional.

¿Necesitas más ayuda? Recibe respuestas de los miembros de la comunidad y de los profesionales de Google SecOps.