Descripción general del modelo de datos unificado

En este documento, se proporciona una descripción general del modelo de datos unificados (UDM). Para ver más información detallada sobre los campos de UDM, incluida una descripción de cada uno, consulta el campo de UDM lista. Para obtener más información asignación de analizadores, consulta Campos UDM importantes para el analizador mapeo.

La 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 lo conoce como esquema. Google Security Operations almacena los datos originales que recibe en dos formatos, registro original sin procesar y como un registro de UDM estructurado. El registro UDM es un única del registro original.

Si existe un analizador para el tipo de registro especificado, el registro sin procesar se usa con el objetivo de crear un registro de UDM. Los clientes también pueden transformar registros sin procesar en formato UDM estructurado antes de enviarlos a Google Security Operations mediante la API de transferencia.

Estos son algunos de los beneficios de UDM:

• Almacena el mismo tipo de registro de distintos proveedores que utilizan el mismo semántica.
• Es más fácil identificar las relaciones entre usuarios, hosts y direcciones IP. porque 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 más precisión debido a su especificidad.

Google Security Operations utiliza el esquema de UDM para todos los eventos que recopila. UDM incluye miles de campos que se usan para describir y categorizar eventos. Por ejemplo, UDM puede manejar eventos de procesos de extremos tan fácilmente como los eventos de de comunicación.

Estructura de UDM

Los eventos de UDM constan de varias secciones. La primera sección que se encuentra El evento 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 produjo se transfieren a Google Security Operations. También incluye la información del producto, versión y descripción. El analizador de transferencia clasifica cada evento según una tipo de evento predefinido, independientemente del registro de producto específico. Con la solo en los campos de metadatos, puedes comenzar a buscar los datos con rapidez.

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. Secciones que hacen referencia al origen (src) y al destino (target).
• intermediary: Sistemas por los que pasan los eventos, como un proxy o una retransmisión de SMTP.
• observer: Sistemas como detectores de paquetes que de forma pasiva supervisar a través del tráfico.

Ejemplos de búsquedas de UDM

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

Ejemplo: Busca accesos exitosos de Microsoft Windows 4624

La siguiente búsqueda muestra los eventos de acceso exitoso de Microsoft Windows 4624. junto con cuándo se generaron los eventos, basados en solo dos campos UDM:

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

Ejemplo: Buscar todos los accesos exitosos

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

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

Ejemplo: buscar accesos exitosos de los usuarios

En el siguiente ejemplo, se muestra cómo buscar userid "fkolzig" y determina cuándo el usuario con este ID de usuario accede correctamente. Puedes completa esta búsqueda usando la sección objetivo. La sección objetivo incluye subsecciones y campos que describen el objetivo. Por ejemplo, el objetivo de esta caso es un usuario y tiene un número de atributos asociados, pero el objetivo puede ser un archivo, una configuración de 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 datos de red para eventos de RDP con un target.port

de 3389 y una principal.ip de 35.235.240.5 También incluye un campo UDM de la sección de red, la dirección de la 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 de la net.exe y busca este archivo específico en su ruta de acceso esperada. El que estás buscando es target.process.file.full_path. Para esta búsqueda, debes incluir el comando específico emitido en el archivo target.process.command_line

cibernética en la nube. También puedes agregar un campo en la sección Acerca de que es la descripción del Código de evento de Microsoft Sysmon 1 (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 kubectl.
• principal.process.file.md5: Identifica el hash MD5.
• principal.process.command_line: Línea de comandos

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

El siguiente ejemplo busca los accesos de los usuarios (metadata.event_type) Está USER_LOGIN) asociada con el departamento de marketing (target.user.department) es marketing) de tu empresa. Aunque target.user.department no es directamente conectada con eventos de acceso del usuario, sigue presente en los datos 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 UDM registro identifica 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 un Entity y también qué valor se establece en metadata.event_type o metadata.entity_type.

• Evento de UDM: Almacena los datos de una acción que ocurrió en el en un entorno de nube. El registro de eventos original describe la acción tal como se grabó por el dispositivo, como un firewall o un proxy web. Estos son los datos de eventos de UDM un modelo de responsabilidad compartida.
• Entidad de UDM: Representa la representación contextual de elementos, como recursos, los usuarios y los recursos de tu entorno. Se obtiene de una fuente de verdad. Este es el modelo de datos de entidades de UDM.

Estas son dos representaciones visuales de alto nivel del modelo de datos de Eventos y el Modelo de datos de entidad.

Figura: Modelo de datos de eventos

Figura: Modelo de datos de la entidad

Estructura de un evento de UDM

El evento de UDM contiene múltiples secciones y cada una almacena un subconjunto de los datos para un solo registro. Las secciones son las siguientes:

• metadatos
• principal
• objetivo
• src
• observador
• intermediario
• about
• network
• security_result

• extensions

  

  Figura: Modelo de datos de eventos

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

Los principal, target, src, Las secciones observer y intermediary almacenan información sobre los objetos involucrados en el evento. Un objeto puede ser un dispositivo, usuario o proceso. La mayoría de las veces, solo un subconjunto de estas secciones que se usan. Los campos que almacenan datos están determinados por el tipo de evento y por la función de cada objeto en el evento.

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

• Datos del correo electrónico: Información en 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 más seguro, como un antivirus.

Las secciones Acerca de y Extensiones almacenan eventos adicionales específicos del proveedor. información no capturada por las otras secciones. La sección extensions es una un conjunto de pares clave-valor de formato libre.

Cada evento de UDM almacena valores de un evento de registro original sin procesar. Según el de evento, algunos atributos son obligatorios y otros opcionales. El Los atributos obligatorios y opcionales se determinan mediante metadata.event_type valor. Google Security Operations lee metadata.event_type y ejecuta campos la validación 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 UDM, por ejemplo, las extensiones no aparece 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 GMT cuando ocurrió el evento. El valor se debe codificar tiene uno de los siguientes estándares: marca de tiempo RFC 3339 o Proto3.

En los siguientes ejemplos, se muestra cómo especificar la marca de tiempo con el estándar RFC 3339 formato, yyyy-mm-ddThh:mm:ss+hh:mm (año, mes, día, hora, minuto, segundo y la diferencia con respecto a la hora UTC). La compensación desde UTC es de menos 8 horas, 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 del evento de UDM es metadata.event_type. Este valor identifica el tipo de acción realizada y es independiente del proveedor, producto o plataforma. Los valores de ejemplo incluyen PROCESS_OPEN, FILE_CREATION, USER_CREATION y NETWORK_DNS. Para ver la lista completa, consulta el campo UDM list.

El valor metadata.event_type determina qué recursos adicionales y los campos opcionales deben incluirse en el registro de UDM. Para obtener información sobre qué campos incluir para cada tipo de evento, consulta Uso de UDM .

Los atributos principal, target, src, intermediario, observador y Acerca de

Los principal, target, src, Los atributos intermediary y observer describen los recursos que participan en el evento. Cada uno almacena información sobre los objetos involucrados en la actividad, tal y como la registró el registro sin procesar original. Este podría ser el dispositivo o usuario que realizó la actividad, el dispositivo o el usuario objetivo de la actividad. También podría 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 usados son los siguientes:

• principal: Es el objeto que realizó la actividad.
• src: El objeto que inicia la actividad, si es diferente de el 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: Es cualquier objeto que actuó como intermediario en el para cada evento. Esto podría incluir objetos como servidores proxy y servidores de correo.
• observer: Es cualquier objeto que no interactúa directamente con el el tráfico en cuestión. Puede ser un escáner de vulnerabilidades o un paquete sniffer.
• about: cualquier otro objeto que tuvo un rol en el evento y que opcional.

Los atributos principales

Representa la entidad activa o el dispositivo que originó la actividad. El la principal debe incluir al menos un detalle de máquina (nombre de host, dirección MAC, IP dirección, identificadores específicos de productos, como un GUID de máquina de CrowdStrike) o detalle (por ejemplo, nombre de usuario) y, opcionalmente, incluir detalles del proceso. Debe no deben incluir ninguno de los siguientes campos: correo electrónico, archivos, claves de registro o valores.

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

En el siguiente fragmento de JSON, se ilustra cómo el atributo principal puede completarse.

"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 conocía sobre el dispositivo y el usuario que fue el actor principal del evento. Este ejemplo incluye la dirección IP del dispositivo, el número de puerto y el nombre de host. También incluye un identificador de recursos específico del proveedor, de Sophos, un identificador único generado por la entidad de seguridad producto.

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 B, el dispositivo A se captura como el principal y el dispositivo B se captura como el objetivo.

Para una inserción de procesos mediante el proceso C en el proceso D de destino, el proceso C es el la principal y el proceso D es el objetivo.

Figura: Principal en comparación con el objetivo

En el siguiente ejemplo, se muestra cómo se puede propagar el campo de destino.

target {
   ip: "192.0.2.31"
   port: 80
}

Si hay más información disponible en el registro original sin procesar, como el nombre de host, direcciones IP adicionales, direcciones MAC e identificadores de activos propios, también debe incluirse en los campos objetivo y principal.

Tanto el principal como el objetivo pueden representar a perpetradores 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) en la máquina X.

El atributo src

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

El atributo intermediario

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

El atributo de observador

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

El atributo Acerca de

Este almacena detalles sobre un objeto al que hace referencia el evento, que no es se describen en los campos principal, src, objetivo, intermediario u observador. Para ejemplo, puede capturar la siguiente información:

• Enviar archivos adjuntos por correo electrónico
• Dominios, URL o direcciones IP incorporados en el cuerpo del correo electrónico.
• DLL que se cargan durante un evento PROCESS_LAUNCH

El atributo security_result

Esta sección contiene información sobre riesgos de seguridad y amenazas que se detectadas por un sistema de seguridad y las medidas que se toman para mitigar esos riesgos y las amenazas de seguridad cibernética.

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

• Un proxy de seguridad de correo electrónico detectó un intento de phishing (security_result.category = mail_PHISHING) y está bloqueada (security_result.action = BLOCK) el correo electrónico.
• Un firewall del proxy de seguridad del correo electrónico detectó dos archivos adjuntos infectados (security_result.category = SOFTWARE_MALICIOUS) se coloca en cuarentena y desinfectado (security_result.action = QUARANTINE o security_result.action = ALLOW_WITH_MODIFICATION) estos archivos adjuntos y, luego, reenvió la desinfectar el correo electrónico.
• Un sistema de SSO permite el 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 el enviado (security_result.action = ALLOW) al usuario en su bandeja de entrada.

El atributo de red

Los atributos de red almacenan datos sobre eventos relacionados con la red y detalles sobre protocolos dentro de los mensajes secundarios. 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 de UDM

Un registro de entidad 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 user en el atributo entity.user. Si el metadata.entity_type es ASSET, el almacena información sobre un activo, como estación de trabajo, laptop, teléfono, y máquina virtual.

Figura: Modelo de datos de eventos

Los campos de metadatos

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

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

El atributo de entidad

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

• Si el metadata.entity_type es USER, entonces los datos se almacenan en la Entity.user.
• Si el metadata.entity_type es ASSET, los datos se almacenan en la Entity.asset.

El atributo de relación

Los campos debajo del atributo de relación almacenan información sobre otras entidades que está relacionada la entidad principal. Por ejemplo, si la entidad principal es un Usuario y se le entrega una laptop al usuario. La laptop es una entidad relacionada. La información de la laptop se almacena como una "entidad" con una metadata.entity_type = ASSET. La información sobre el usuario se almacena como “entity” de registro con metadata.entity_type = USER.

El registro de entidad del usuario también captura la relación entre el usuario y el en una laptop con los campos “relación” . La relación.relación almacena la relación que el usuario tiene con la laptop, específicamente que el usuario es dueño de la laptop. El campo relacional.entity_type almacena el valor ASSET, porque la laptop es un dispositivo.

Los campos debajo del atributo relacionals.entity almacenan información sobre la laptop. como el nombre de host y la dirección MAC. Observa una vez más que el nombre del campo es “entity” y el tipo de campo es un sustantivo. Un sustantivo es una estructura de datos de uso frecuente. Los campos debajo del atributo relacional.entity almacenan información sobre la laptop.

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