Cómo dar formato a los datos de registro como UDM
Campos de eventos de la AUA comunes
Todos los eventos del modelo de datos unificado (UDM) tienen un conjunto de campos y mensajes comunes que los socios pueden propagar 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 proviene, etcétera.
- Metadatos de la red: Metadatos de red de alto nivel para eventos orientados a la red, así como detalles del protocolo dentro de los submensajes:
- Metadatos de correo electrónico: Información en los campos Para, De, Cc, Cco y otros campos de correo electrónico.
- Metadatos HTTP: método, referral_url, useragent, etcétera
- Resultados de seguridad: Cualquier clasificación o acción que realice un producto de seguridad.
- Metadatos adicionales: Se pueden agregar datos de eventos importantes específicos del proveedor que no se puedan representar de forma adecuada en las secciones formales del modelo de UDM mediante 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 la AUA.
Codificación de UDM
Los eventos de la AUA se deben enviar a 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 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 la AUA
Para dar formato a un evento de la AUA y prepararlo para enviarlo a Google, debes completar los siguientes pasos:
- Especifica el tipo de evento: El tipo de evento que selecciones determinará 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 que esté involucrado en el evento.
- Especifica el resultado de seguridad: (Opcional) Especifica los resultados de seguridad. Para ello, incluye detalles sobre los riesgos y las amenazas de seguridad que encontró un sistema de seguridad, así como las medidas que se tomaron para mitigarlos.
- Completa el resto de la información del evento obligatoria y opcional con los campos de eventos del UDM.
Especifica el tipo de evento
El valor más importante definido para cualquier evento enviado en formato 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 requiere que también propagues 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 de la AUA para obtener detalles sobre los campos que se deben incluir para cada tipo de evento. En el siguiente ejemplo, se muestra cómo especificar 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 (GMT) de cualquier evento que se envíe en formato 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 muestra cómo especificarías la marca de tiempo con el formato RFC 3339. En este ejemplo, aaaa-mm-ddThh:mm:ss+hh:mm: año, mes, día, hora, minuto, 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 la AUA, debes definir uno o más sustantivos. Un sustantivo representa a un participante o una entidad en un evento de la AUA. Un sustantivo puede ser, por ejemplo, el dispositivo o el usuario que realiza la actividad descrita en un evento, o el dispositivo o el usuario que es el objetivo de esa actividad descrita en el evento. Los sustantivos también pueden ser elementos como archivos adjuntos o URLs. Por último, también se puede usar un sustantivo 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 de la AUA debe tener especificado uno o más de los siguientes sustantivos:
principal: Representa la entidad que actúa 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, 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 todos los eventos se producen en la misma máquina, solo se debe describir esa máquina en principal. No es necesario que la máquina también se describa en target o en src.
En el siguiente ejemplo, se muestra cómo se podrían propagar los campos principales:
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 principal actor en el evento. Incluye la dirección IP, el número de puerto y el nombre de host del dispositivo, junto con un identificador de activos específico del proveedor (de Sophos), que es un ID único que genera el producto de seguridad de terceros.
target: 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, A se describe como el principal y B se describe como el objetivo. Para una inserción de proceso por parte del proceso C en el proceso D de destino, el proceso C se describe como el principal y el proceso D se describe como el objetivo.
Principal en comparación con el objetivo en la AUA
En el siguiente ejemplo, se muestra cómo se propagan los campos de un objetivo:
target {
ip: "198.51.100.31"
port: 80
}
Una vez más, si hay más información disponible, como el nombre de host, direcciones IP adicionales, direcciones MAC, identificadores de activos propietarios, etc., también se deben incluir en target.
Tanto principal como target (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 en el proceso B (objetivo) también en la máquina X.
- 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 en la máquina X al archivo B en la máquina Y, tanto el archivo A como la máquina X se especificarían en la parte src del evento de la AUA.
- intermediary: Representa los detalles de 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.
- observador: Representa un dispositivo de observación (por ejemplo, un sniffer de paquetes o un escáner de vulnerabilidades basado en la red), que no es un intermediario directo, pero que observa y informa sobre el evento en cuestión.
- about: Se usa para almacenar detalles sobre todos los objetos a los que hace referencia el evento y que no se describen de otra manera en participant, src, target, intermediary o observer. Por ejemplo, se puede usar para hacer un seguimiento de lo siguiente:
- Archivos adjuntos de correo electrónico
- Dominios, URLs o IPs incorporados en el cuerpo de un correo electrónico
- DLL que se cargan durante un evento PROCESS_LAUNCH
Las secciones de entidades de los eventos de la AUA incluyen información sobre los diversos participantes (dispositivos, usuarios, objetos como URLs, archivos, etcétera) que se describen en el evento. La UDM de Google Security Operations tiene requisitos obligatorios para propagar campos de sustantivos. Estos requisitos se describen en Campos obligatorios y opcionales para cada tipo de evento de 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 mitigarlos. Los siguientes son ejemplos de algunos de los tipos de eventos de seguridad que requerirían la propagación de 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 de proxy de seguridad de correo electrónico detectó dos archivos adjuntos infectados (SOFTWARE_MALICIOUS) y los puso en cuarentena y 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) al usuario en su carpeta Recibidos.
¿Necesitas más ayuda? Obtén respuestas de miembros de la comunidad y profesionales de Google SecOps.