Dar formato a los datos de registro como UDM
Campos de eventos de UDM comunes
Todos los eventos del Modelo de datos unificado (UDM) tienen un conjunto de campos y mensajes comunes que los socios pueden completar independientemente del tipo de evento. Estos campos incluyen lo siguiente:
- Entidades: Son los dispositivos, los usuarios y los procesos involucrados en un evento.
- Metadatos del evento: Cuándo ocurrió el evento, su tipo, de dónde provino, etcétera
- Metadatos de la red: Son metadatos de alto nivel de la red para eventos orientados a la red, así como detalles del protocolo dentro de los submensajes:
- Metadatos del correo electrónico: Información en los campos Para, De, Cc, Cco y otros campos de correo electrónico
- Metadatos de HTTP: Método, referral_url, useragent, etcétera
- Resultados de seguridad: Cualquier clasificación o acción realizada por un producto de seguridad.
- Metadatos adicionales: Cualquier dato de evento importante específico del proveedor que no se pueda representar de forma adecuada en las secciones formales del modelo de UDM se puede agregar con un campo de carga útil JSON de formato libre.
En las siguientes secciones, se describe cómo codificar y dar formato a los eventos para el UDM.
Codificación de UDM
Los eventos del UDM se deben enviar a las Operaciones de seguridad de Google en uno de los siguientes formatos:
Para los fines de este documento, los campos se representan con una notación de puntos. Por ejemplo, la siguiente sintaxis de JSON:
{"menu":
{
"id": "file",
"value": "File",
"popup": {
"menuitem": [
{"value": "New", "onclick": "CreateNewDoc()"}
]
}
}
}
Se documenta de la siguiente manera:
menu.id = "file"
menu.value = "File"
menu.popup.menuitem.value = "New"
menu.popup.menuitem.onclick = "CreateNewDoc()"
Cómo dar formato a un evento de UDM
Para darle formato a un evento del UDM y prepararlo para enviarlo a Google, debes completar los siguientes pasos:
- Especifica el tipo de evento: El tipo de evento que selecciones determina qué campos también debes incluir con el evento.
- Especifica la marca de tiempo del evento: Especifica la marca de tiempo del evento.
- Especifica sustantivos (entidades): Cada evento debe incluir al menos un sustantivo que describa un dispositivo o usuario participante involucrado en el evento.
- Especifica el resultado de seguridad (opcional): Especifica los resultados de seguridad incluyendo detalles sobre los riesgos y las amenazas de seguridad que encontró un sistema de seguridad, así como las acciones que se tomaron para mitigar esos riesgos y amenazas.
- Completa el resto de la información del evento obligatoria y opcional con los campos del evento del UDM.
Especifica el tipo de evento
El valor más importante definido para cualquier evento enviado en formato de UDM es el tipo de evento, que se especifica con uno de los valores posibles disponibles para Metadata.event_type. Estos incluyen valores como PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS, etc. (para ver la lista completa, consulta Metadata.event_type). Cada tipo de evento también requiere que completes un conjunto de otros campos y valores con la información vinculada al evento original. Consulta Campos obligatorios y opcionales para cada tipo de evento del UDM para obtener detalles sobre qué campos incluir para cada tipo de evento. En el siguiente ejemplo, se ilustra cómo especificarías 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 en 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 ilustra cómo especificarías la marca de tiempo con el formato RFC 3339. En este ejemplo, aaaa-mm-ddThh:mm:ss+hh:mm representa el año, el mes, el día, la hora, el minuto, el segundo y la compensació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"
}
Especifica sustantivos (entidades)
Para cada evento de UDM, debes definir uno o más sustantivos. Un sustantivo representa a un participante o una entidad en un evento del UDM. Por ejemplo, un sustantivo podría ser el dispositivo o el usuario que realiza la actividad descrita en un evento, o el dispositivo o el usuario que es el objetivo de dicha actividad descrita en el evento. Los sustantivos también pueden ser elementos como archivos adjuntos o URLs. Por último, un sustantivo también se puede usar para describir un dispositivo de seguridad que observó la actividad descrita en el evento (por ejemplo, un proxy de correo electrónico o un router de red).
Un evento del UDM debe tener especificado uno o más de los siguientes sustantivos:
principal: Representa la entidad actuante o el dispositivo que origina la actividad descrita en el evento. El 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, nombre de usuario) y, de manera opcional, puede incluir detalles del proceso. NO debe incluir ninguno de los siguientes campos: correo electrónico, archivos, claves o valores de registro.
Si todos los eventos tienen lugar en la misma máquina, solo es necesario describir esa máquina en principal. No es necesario que la máquina también se describa en target ni en src.
En el siguiente ejemplo, se muestra cómo se podrían completar los campos de 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. Incluye la dirección IP, el número de puerto y el nombre de host del dispositivo, junto con un identificador de activo específico del proveedor (de Sophos), que es un ID único generado por el producto de seguridad de terceros.
target: Representa un dispositivo objetivo al que hace referencia el evento o un objeto en el dispositivo objetivo. Por ejemplo, en una conexión de firewall del dispositivo A al dispositivo B, A se describe como el principal y B se describe como el destino. En el caso de una inyección de proceso del proceso C en el proceso objetivo D, el proceso C se describe como principal y el proceso D se describe como objetivo.
Principal en comparación con el objetivo en UDM
En el siguiente ejemplo, se ilustra cómo se completan los campos de un objetivo:
target {
ip: "198.51.100.31"
port: 80
}
Nuevamente, si hay más información disponible, como el nombre de host, direcciones IP adicionales, direcciones MAC, identificadores de activos propios, etc., también se deben incluir en target.
Tanto el principal como el destino (así como otros sustantivos) pueden hacer referencia a actores en la misma máquina. Por ejemplo, el proceso A (principal) que se ejecuta en la máquina X actúa sobre el proceso B (objetivo) también en la máquina X.
- src: Representa un objeto fuente sobre el que el participante realiza una acción, 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.
- intermediary: Representa detalles sobre uno o más dispositivos intermedios que procesan la actividad descrita en el evento. Esto incluye detalles del dispositivo sobre un servidor proxy, un servidor de retransmisión de SMTP, etcétera.
- observer: Representa un dispositivo observador (por ejemplo, un analizador de paquetes o un escáner de vulnerabilidades basado en la red), que no es un intermediario directo, pero que observa el evento en cuestión y lo informa.
- about: Se usa para almacenar detalles sobre todos los objetos a los que hace referencia el evento y que no se describen en participant, src, target, intermediary o observer. Por ejemplo, se podría usar para hacer un seguimiento de lo siguiente:
- Archivos adjuntos de correos electrónicos
- Dominios, URLs o IPs integrados en el cuerpo de un correo electrónico
- DLLs que se cargan durante un evento PROCESS_LAUNCH
Las secciones de entidades de los eventos del 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 los campos de sustantivo. Estos requisitos se describen en Campos obligatorios y opcionales para cada tipo de evento del UDM. El conjunto de campos de entidad que se deben completar difiere según el tipo de evento.
Especifica el resultado de seguridad
De manera opcional, puedes especificar los resultados de seguridad completando los campos SecurityResult, incluidos los detalles sobre los riesgos y las amenazas de seguridad que encontró el sistema de seguridad, así como las acciones que se tomaron para mitigar esos riesgos y amenazas. A continuación, se muestran ejemplos de algunos tipos de eventos de seguridad que requerirían completar los campos de SecurityResult:
- Un proxy de seguridad de correo electrónico detectó un intento de phishing (MAIL_PHISHING) y bloqueó (BLOCK) el correo electrónico.
- Un firewall proxy de seguridad de correo electrónico detectó dos archivos adjuntos infectados (SOFTWARE_MALICIOUS), los puso en cuarentena y los desinfectó (QUARANTINE, ALLOW_WITH_MODIFICATION), y, luego, reenvió el correo electrónico desinfectado.
- Un sistema de SSO facilitó un acceso (AUTH_VIOLATION) que 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 se entregó (ALLOW) el archivo al usuario en su carpeta Recibidos.
¿Necesitas más ayuda? Obtén respuestas de miembros de la comunidad y profesionales de Google SecOps.