Descripción general del modelo de datos unificado

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 del analizador, consulta Campos importantes del UDM para la asignación del analizador.

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 al formato estructurado del UDM antes de enviar los datos a Google SecOps con la API de Ingestion.

Estos son algunos de los beneficios del UDM:

• 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 estándar del UDM.
• 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.

Si bien 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. Las Operaciones de seguridad de Google recopilan datos de registro sin procesar y almacenan los detalles del registro de eventos en el esquema del UDM. El UDM proporciona un marco integral de miles de campos para describir y categorizar diversos tipos de eventos, por ejemplo, eventos de procesos de endpoints y eventos de comunicación de red.

Estructura del UDM

Los eventos del UDM se componen de varias secciones. La primera sección que se encuentra en cada evento del UDM es la sección de metadatos. Proporciona una descripción básica del evento, incluida la marca de tiempo en la que ocurrió y la marca de tiempo en la que se transfirió a Google SecOps. También incluye la información, la versión y la descripción del producto. El analizador de la transferencia clasifica cada evento según un tipo de evento predefinido, independientemente del registro específico del producto. Con solo 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 secciones que hacen referencia a la fuente (src) y el destino (target).
• intermediary: Sistemas por los que pasan los eventos, como un servidor proxy o una retransmisión de SMTP.
• observer: Sistemas como los analizadores de paquetes que supervisan el tráfico de forma pasiva.

Ejemplos de búsquedas de UDM

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

Ejemplo: Búsqueda de inicios de sesión exitosos de Microsoft Windows 4624

La siguiente búsqueda enumera los eventos de acceso exitoso 4624 de Microsoft Windows, junto con la fecha y hora en que se generaron, basándose en solo dos campos del UDM:

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

Ejemplo: Busca todos los accesos exitosos

La siguiente búsqueda enumera todos los eventos de acceso exitoso, independientemente del proveedor o la aplicación:

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

Ejemplo: Cómo buscar inicios de sesión de usuarios exitosos

En el siguiente ejemplo, se ilustra cómo buscar userid "fkolzig" y determinar cuándo el usuario con este ID de usuario accedió correctamente. 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 el objetivo también podría ser un archivo, un parámetro de configuración del registro o un activo. 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 tus datos de red

En el siguiente ejemplo, se buscan en los datos de red 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: Cómo 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 su ruta esperada. El campo que buscas es target.process.file.full_path. Para esta búsqueda, debes incluir el comando específico que se emitió en el campo target.process.command_line. También puedes agregar un campo en la sección Acerca de que sea la descripción del código de evento 1 (ProcessCreate) de Microsoft Sysmon.

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 los accesos de usuarios exitosos asociados a 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. Si bien target.user.department no está conectado directamente con los eventos de acceso del usuario, sigue presente en los datos de LDAP que se transfieren sobre tus usuarios.

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

Objetos lógicos: Evento y Entidad

El esquema del 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 qué valor se establece en el campo metadata.event_type o metadata.entity_type.

• Evento de UDM: Almacena datos de una acción que ocurrió 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 del 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 única de verdad.

A continuación, se incluyen dos representaciones visuales de alto nivel del modelo de datos de Evento y del modelo de datos de Entidad.

Figura: Modelo de datos de eventos

Figura: Modelo de datos de entidad

Estructura de un evento del UDM

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

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

• extensiones

  

  Figura: Modelo de datos de eventos

La sección metadata almacena la marca de tiempo, define el event_type y 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 desempeña cada objeto en el evento.

En la sección Red, se almacena información relacionada con la actividad de red, como la comunicación por correo electrónico y la comunicación relacionada con la red.

• 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

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

Las secciones about y extensions almacenan información adicional del evento específica del proveedor que no se captura en las otras secciones. La sección extensions es un conjunto de pares clave-valor de formato libre.

Cada evento del UDM almacena valores de un evento de registro sin procesar original. Según el tipo de evento, algunos atributos son obligatorios y otros son opcionales. Los atributos obligatorios y opcionales se determinan según el valor de metadata.event_type. El equipo de Operaciones de seguridad de Google 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 del UDM, por ejemplo, la sección de extensiones, esa sección no aparecerá en el registro del UDM.

Los campos de metadatos

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

El campo event_timestamp

Los eventos del UDM deben incluir datos para metadata.event_timestamp, que es la marca de tiempo en GMT en la que ocurrió 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 compensación de UTC es de menos 8 horas, lo que indica 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 del UDM es metadata.event_type. Este valor identifica el tipo de acción que se realizó 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 del UDM.

El valor de metadata.event_type determina qué campos adicionales obligatorios y opcionales 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 del UDM.

Los atributos principal, objetivo, src, intermediario, observador y about

Los atributos principal, target, src, intermediary y observer describen los recursos involucrados en el evento. Cada uno almacena información sobre los objetos involucrados en la actividad, según se registró en 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 más utilizados son los siguientes:

• principal: Es el objeto que realizó la actividad.
• src: Es el objeto que inicia la actividad, si es diferente del principal.
• target: Es el objeto sobre el que se realiza la acción.

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

Los campos auxiliares son los siguientes:

• intermediary: Es cualquier objeto que actuó 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. Podría tratarse de un dispositivo de análisis de vulnerabilidades o de rastreo de paquetes.
• about: Cualquier otro objeto que haya desempeñado un papel en el evento y sea opcional.

Los atributos principales

Representa la entidad actuante o el dispositivo que originó 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, nombre de usuario) y, de manera opcional, detalles del proceso. No debe incluir ninguno de los siguientes campos: correo electrónico, archivos, claves o valores de registro.

Si el evento tiene lugar 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.

En el siguiente fragmento de JSON, se ilustra cómo se podría completar 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 activo 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 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 principal y el dispositivo B se captura como destino.

En el caso de una inyección de proceso del proceso C en el proceso objetivo D, el proceso C es el principal y el proceso D es el objetivo.

Figura: Principal versus objetivo

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

Tanto la entidad principal como el destino 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 sobre el proceso B (objetivo) también en la máquina X.

El atributo src

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

El atributo intermedio

Representa detalles sobre uno o más 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.

El atributo observer

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

Esta tienda detalla un objeto al que hace referencia el evento y que no se describe en los campos principal, src, target, intermediary o observer. Por ejemplo, podría capturar lo siguiente:

• Archivos adjuntos de correos electrónicos
• Dominios, URLs o direcciones IP incorporados en el cuerpo de un 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, así como las acciones que se toman para mitigar esos riesgos y amenazas.

A continuación, se indican 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 proxy de seguridad de correo electrónico detectó dos archivos adjuntos infectados (security_result.category = SOFTWARE_MALICIOUS), los puso en cuarentena y 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).
• Un entorno aislado de software malicioso detectó software espía (security_result.category = SOFTWARE_MALICIOUS) en un archivo adjunto cinco minutos después de que se entregó (security_result.action = ALLOW) el archivo 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 de extensiones

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 del UDM

Un registro de entidad del UDM almacena información sobre cualquier entidad dentro de una organización. Si metadata.entity_type es USER, el registro almacena información sobre el usuario en el atributo entity.user. Si el valor de 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

En esta sección, se incluyen los campos obligatorios en una entidad del UDM, como los siguientes:

• collection_timestamp: 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 de la entidad almacenan información sobre la entidad específica, como el nombre de host y la dirección IP si se trata de un activo, 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 de uso común que almacena información tanto en entidades como en eventos.

• Si 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.

El atributo de relación

Los campos 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 entregó una laptop. La laptop es una entidad relacionada. La información sobre la laptop 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 del usuario también captura la relación entre el usuario y la laptop, a través de los campos del 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 del atributo relations.entity almacenan información sobre la laptop, como el nombre de host y la dirección MAC. Ten en cuenta nuevamente que el nombre del campo es entity y el tipo de campo es un sustantivo. Un sustantivo es una estructura de datos de uso común. Los campos 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.