Aplicar formato a los datos de registro como UDM
Campos de evento de UDM comunes
Todos los eventos del modelo de datos unificado (UDM) tienen un conjunto de campos y mensajes comunes que los partners pueden rellenar independientemente del tipo de evento. Estos campos incluyen lo siguiente:
- Entidades: dispositivos, usuarios y procesos implicados en un evento.
- Metadatos del evento: cuándo se produjo el evento, el tipo de evento, de dónde procede, etc.
- Metadatos de red: metadatos de red de alto nivel para eventos orientados a la red, así como detalles del protocolo en los submensajes:
- Metadatos de correo electrónico: información de los campos Para, De, Cc, Cco y otros campos de correo.
- Metadatos HTTP: método, referral_url, useragent, etc.
- Resultados de seguridad: cualquier clasificación o acción realizada por un producto de seguridad.
- Metadatos adicionales: cualquier dato de evento importante específico de un proveedor que no se pueda representar adecuadamente en las secciones formales del modelo de UDM se puede añadir 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 gestión de datos unificada.
Codificación de UDM
Los eventos de UDM deben enviarse a Google Security Operations en uno de los siguientes formatos:
En este documento, los campos se representan mediante 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()"
Formato de un evento de UDM
Para dar formato a un evento de UDM de forma que esté listo para enviarse a Google, debe completar los siguientes pasos:
- Especifica el tipo de evento: el tipo de evento que selecciones determinará los campos que también debes incluir en el evento.
- Especificar la marca de tiempo del evento: especifique la marca de tiempo del evento.
- Especificar sustantivos (entidades): cada evento debe incluir al menos un sustantivo que describa un dispositivo o un usuario participante 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 ha encontrado un sistema de seguridad, así como las medidas que se han tomado para mitigar esos riesgos y amenazas.
- Rellene el resto de la información de eventos obligatoria y opcional mediante los campos de eventos de UDM.
Especificar 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 mediante uno de los valores posibles disponibles para Metadata.event_type. Entre ellos, se incluyen valores como PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS, etc. (para ver la lista completa, consulta Metadata.event_type). En cada tipo de evento, también debe rellenar un conjunto de campos y valores con la información vinculada al evento original. Consulta Campos obligatorios y opcionales de cada tipo de evento de UDM para obtener información detallada sobre los campos que debes incluir en cada tipo de evento. En el siguiente ejemplo se muestra cómo especificar PROCESS_OPEN como tipo de evento mediante la notación de texto Proto3:
metadata {
event_type: PROCESS_OPEN
}
Especificar la marca de tiempo del evento
Debe especificar la marca de tiempo GMT de cualquier evento enviado en formato UDM mediante Metadata.event_timestamp. El sello debe codificarse con uno de los siguientes estándares:
- En el caso de JSON, usa RFC 3339.
- Marca de tiempo de Proto3
En el siguiente ejemplo se muestra cómo especificar 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 el desfase con respecto a la hora UTC. La diferencia con respecto a UTC es de -8 horas, lo que indica que se trata de la zona horaria PST.
metadata {
event_timestamp: "2019-09-10T20:32:31-08:00"
}
Especificar sustantivos (entidades)
En cada evento de UDM, debe definir uno o varios sustantivos. Un sustantivo representa a un participante o una entidad en un evento de 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 haya observado la actividad descrita en el evento (por ejemplo, un proxy de correo o un router de red).
Un evento de UDM debe tener especificado uno o varios de los siguientes sustantivos:
Principal: representa la entidad o el dispositivo que inicia la actividad descrita en el evento. El principal debe incluir al menos un detalle de la máquina (nombre de host, MACs, IPs, 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, opcionalmente, detalles del proceso. NO debe incluir ninguno de los siguientes campos: correo electrónico, archivos, claves o valores del 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 o en src.
En el siguiente ejemplo se muestra cómo se podrían rellenar los campos 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, así como 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 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 dispositivo B, A se describe como la entidad principal y B se describe como el destino. En el caso de una inyección de proceso por parte del proceso C en el proceso de destino D, el proceso C se describe como el principal y el proceso D se describe como el de destino.
Principal y objetivo en la gestión de datos unificada
En el siguiente ejemplo se muestra cómo se rellenan los campos de un destino:
target {
ip: "198.51.100.31"
port: 80
}
De nuevo, 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 sobre el proceso B (de destino), que también se encuentra en la máquina X.
- src: representa un objeto de origen sobre el que actúa el participante, junto con el contexto del dispositivo o del 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 del ordenador X en el archivo B del ordenador Y, tanto el archivo A como el ordenador X se especificarían en la parte src del evento de UDM.
- Intermediario: representa los detalles de uno o varios dispositivos intermediarios que procesan la actividad descrita en el evento. Esto incluye detalles del dispositivo sobre un servidor proxy, un servidor de relay SMTP, etc.
- 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 genera informes sobre él.
- 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 u observer. Por ejemplo, se podría usar para monitorizar lo siguiente:
- Archivos adjuntos de correo electrónico
- Dominios, URLs o IPs insertados en el cuerpo de un correo
- DLLs que se cargan durante un evento PROCESS_LAUNCH
Las secciones de entidades de los eventos de UDM incluyen información sobre los distintos participantes (dispositivos, usuarios, objetos como URLs, archivos, etc.) descritos en el evento. El UDM de Google Security Operations tiene requisitos obligatorios a la hora de rellenar los campos de sustantivo. Estos requisitos se describen en el artículo Campos obligatorios y opcionales de cada tipo de evento de UDM. El conjunto de campos de entidad que se deben rellenar varía en función del tipo de evento.
Especifica el resultado de seguridad
También puedes especificar los resultados de seguridad rellenando los campos SecurityResult, incluidos los detalles sobre los riesgos y las amenazas de seguridad que ha detectado el sistema de seguridad, así como las medidas que se han tomado para mitigar esos riesgos y amenazas. A continuación se muestran algunos ejemplos de los tipos de eventos de seguridad que requerirían rellenar los campos de SecurityResult:
- Un proxy de seguridad de correo electrónico ha detectado un intento de phishing (MAIL_PHISHING) y ha bloqueado (BLOCK) el correo.
- Un cortafuegos proxy de seguridad de correo electrónico ha detectado dos archivos adjuntos infectados (SOFTWARE_MALICIOUS) y los ha puesto en cuarentena y desinfectado (QUARANTINE, ALLOW_WITH_MODIFICATION). Después, ha reenviado el correo desinfectado.
- Un sistema de SSO ha facilitado un inicio de sesión (AUTH_VIOLATION) que se ha bloqueado (BLOCK).
- Un entorno aislado de malware ha detectado spyware (SOFTWARE_MALICIOUS) en un archivo adjunto cinco minutos después de que se enviara (ALLOW) a la bandeja de entrada del usuario.
¿Necesitas más ayuda? Recibe respuestas de los miembros de la comunidad y de los profesionales de Google SecOps.