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 la AUA, incluida una descripción de cada uno, consulta la lista de campos de la AUA. Para obtener más información sobre la asignación de analizador, consulta Campos importantes de la UDM para la asignación de analizador.
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 denomina esquema. Google Security Operations almacena los datos originales que recibe en dos formatos: como el registro sin procesar original y como un registro de la AUA estructurado. El registro de la UDM es una representación estructurada del registro original.
Si existe un analizador para el tipo de registro especificado, se usa el registro sin procesar para crear un registro de UDM. Los clientes también pueden transformar los registros sin procesar en formato UDM estructurado antes de enviar los datos a Google Security Operations con la API de Ingestión.
Estos son algunos de los beneficios de la 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.
Google Security Operations usa el esquema de la UDM para todos los eventos que recopila. La UDM incluye miles de campos que se usan para describir y categorizar eventos. Por ejemplo, la UDM puede controlar los eventos de proceso del extremo con la misma facilidad que los eventos de comunicación de red.
Estructura de la UDM
Los eventos de la AUA se componen de varias secciones. La primera sección que se encuentra en cada evento de la 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 las Operaciones de seguridad de Google. También incluye la información, la versión y la descripción del producto. 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 a la fuente (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: Sistemas como los sniffers de paquetes que realizan una supervisión pasiva 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 algunas de las sintaxis, funciones y capacidades básicas de la búsqueda de UDM.
Ejemplo: Buscar accesos exitosos de Microsoft Windows 4624
En la siguiente búsqueda, se enumeran los eventos de acceso exitosos 4624 de Microsoft Windows, junto con la fecha en que se generaron, en función de solo dos campos de la UDM:
metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624"
Ejemplo: Busca todos los accesos exitosos
La siguiente búsqueda muestra todos los eventos de acceso correctos, 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: Buscar accesos de usuario exitosos
En el siguiente ejemplo, se muestra cómo buscar userid "fkolzig" y determinar cuándo el usuario con este ID de usuario accedió correctamente. Puedes completar esta búsqueda con la sección de destino. La sección de destino incluye sub secciones y campos que describen el objetivo. 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: Buscar tus datos de red
En el siguiente ejemplo, se buscan eventos de RDP en los datos de red 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: 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, debes incluir el comando específico emitido 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 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 la AUA:
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: Buscar 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á directamente conectado 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 la UDM describe todos los atributos disponibles que almacenan datos. Cada registro de la UDM identifica si describe un evento o una entidad. Los datos se almacenan en distintos campos según si el registro describe un evento o una entidad, y también qué valor se establece en el campo metadata.event_type o metadata.entity_type.
- Evento de la AUA: 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. Este es el modelo de datos de eventos del UDM.
- Entidad de la UDM: Representación contextual de elementos como activos, usuarios y recursos en tu entorno. Se obtiene de una fuente de datos de fuente de la verdad. Este es el modelo de datos de entidad de la UDM.
A continuación, se muestran dos representaciones visuales de alto nivel del modelo de datos de eventos y del modelo de datos de entidades.
Figura: Modelo de datos de eventos
Figura: Modelo de datos de entidad
Estructura de un evento de la AUA
El evento de la AUA 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
- about
- 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.
Las secciones principal, target, src, observer y intermediary almacenan 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 él.
La sección Red almacena información relacionada con la actividad de la red, como el correo electrónico y la comunicación relacionada con la red.
- Datos de correo electrónico: Información en los campos
to,from,cc,bccy otros campos de correo electrónico. - Datos HTTP, como
method,referral_urlyuseragent
La sección security_result almacena una acción o clasificación registrada por un producto de seguridad, como un antivirus.
Las secciones acerca de y extensiones almacenan información adicional del evento específica del proveedor que no se captura en las otras secciones. La sección extensiones es un conjunto de pares clave-valor de formato libre.
Cada evento de la AUA 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 en comparación con los opcionales se determinan según el valor de metadata.event_type. Las Operaciones de seguridad de Google leen metadata.event_type y realizan la validación de campo específica de ese tipo de evento después de que se reciben los registros.
Si no se almacenan datos en una sección del registro de la UDM, por ejemplo, la sección de extensiones, esa sección no aparecerá en el registro de la UDM.
Los campos de metadatos
En esta sección, se describen los campos obligatorios en un evento de la AUA.
El campo event_timestamp
Los eventos de la AUA deben incluir datos para metadata.event_timestamp, que es la marca de tiempo de GMT cuando ocurrió el evento. El valor debe codificarse con 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 formato RFC 3339, yyyy-mm-ddThh:mm:ss+hh:mm (año, mes, día, hora, minuto, segundo y la desviación de 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 del evento de la AUA es metadata.event_type.
Este valor identifica el tipo de acción realizada y es independiente del proveedor, producto o 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 la UDM.
El valor de metadata.event_type determina qué campos adicionales obligatorios y opcionales se deben incluir en el registro de la UDM. Para obtener información sobre los campos que debes incluir para cada tipo de evento, consulta la guía de uso de la AUA.
Los atributos principal, objetivo, src, intermediario, observador y sobre
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, como lo registra 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 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 puede 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. Puede ser un escáner de vulnerabilidades o un dispositivo de sniffer de paquetes.about: Cualquier otro objeto que haya desempeñado un rol en el evento y que es opcional.
Los atributos principales
Representa la entidad que realiza la acción 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, el 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 del registro.
Si el evento se produce en una sola máquina, esa máquina se describe solo en el atributo principal. No es necesario describir la máquina en los atributos target o src.
En el siguiente fragmento 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 agente 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 activos 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 objetivo.
Para una inserción de proceso por parte del proceso C en el proceso D de destino, el proceso C es el 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 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, direcciones IP adicionales, direcciones MAC y identificadores de activos propietarios, 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 (objetivo) también en la máquina X.
El atributo src
Representa un objeto de origen en el que el participante realiza acciones, junto con el contexto del dispositivo o 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 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 de la UDM.
El atributo intermediario
Representa los detalles de uno o más dispositivos intermedios que procesan la actividad que se describe en el evento. Esto puede incluir detalles sobre dispositivos, como servidores proxy y servidores de retransmisión SMTP.
El atributo observador
Representa un dispositivo de observador que no es un intermediario directo, pero que observa y, luego, informa sobre el evento en cuestión. Esto podría incluir un sniffer de paquetes o un escáner de vulnerabilidades basado en la red.
El atributo about
Esta tienda almacena detalles sobre un objeto al que hace referencia el evento y que no se describe en los campos principal, src, objetivo, intermediario ni observador. Por ejemplo, podría capturar lo siguiente:
- Archivos adjuntos de correo electrónico
- Dominios, URLs o direcciones IP incorporados en el cuerpo de un correo electrónico
- DLL que se cargan durante un evento PROCESS_LAUNCH.
El atributo security_result
Esta sección contiene información sobre los riesgos y las amenazas de seguridad que detecta un sistema de seguridad, y las acciones que se realizan para mitigarlos.
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) y los puso en cuarentena y desinfectó (security_result.action = QUARANTINE o 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 entregó (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 la UDM almacena información sobre cualquier entidad de una organización. Si metadata.entity_type es USUARIO, el registro almacena información sobre el usuario en el atributo entity.user. Si 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 del 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 del atributo 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 general que almacena información en entidades y 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 un metadata.entity_type = ASSET. La información sobre el usuario se almacena como un registro de "entidad" 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 el usuario tiene con la laptop, específicamente que el usuario es el 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 general. 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.