Formatear los datos de registro como UDM

Se admite en los siguientes países:

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: Dispositivos, usuarios y procesos involucrados en un evento.
  • Metadatos del evento: Cuándo ocurrió el evento, su tipo, de dónde proviene, etcétera.
  • Metadatos de red: Metadatos de la red de alto nivel para eventos orientados a la red, así como detalles de protocolo dentro de mensajes secundarios:
    • Metadatos de correo electrónico: Incluye la información en los campos Para, De, Cc, Cco y en 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 realiza un producto de seguridad.
  • Metadatos adicionales: Cualquier dato importante de eventos específicos del proveedor que no se pueda representar de forma adecuada en las secciones formales del modelo de UDM se puede agregar a través de un campo de carga útil JSON de formato libre.

En las siguientes secciones, se describe cómo codificar eventos y darles formato para el modelo de datos unificado (UDM).

Codificación UDM

Los eventos de UDM se deben enviar a Google Security Operations 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 UDM

Si deseas darle formato a un evento de UDM para que esté listo para enviarlo a Google, debes seguir estos pasos:

  1. Especificación del tipo de evento: El tipo de evento que selecciones determina qué campos también debes incluir en el evento.
  2. Especificación de la marca de tiempo del evento: Especifica la marca de tiempo del evento.
  3. Especificación de sustantivos (entidades): Cada evento debe incluir al menos un sustantivo que describa un dispositivo o usuario participante que esté involucrado en el evento.
  4. Especificar el resultado de seguridad: (Opcional) Especifica los resultados de seguridad con la inclusión de detalles sobre los riesgos y las amenazas de seguridad que encontró un sistema de seguridad, así como las medidas que se tomaron para mitigar esos riesgos y amenazas.
  5. Completa el resto de la información obligatoria y opcional del evento con los campos del evento de UDM.

Cómo especificar el tipo de evento

El valor más importante que se define 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 los Campos obligatorios y opcionales para cada tipo de evento de UDM si deseas conocer los detalles de los campos que se deben incluir para cada tipo de evento. El siguiente ejemplo ilustra cómo especificarías PROCESS_OPEN como el tipo de evento con la notación de texto Proto3:

metadata {
    event_type: PROCESS_OPEN
}

Cómo especificar la marca de tiempo del evento

Debe usar Metadata.event_timestamp para especificar la marca de tiempo GMT de cualquier evento enviado en formato UDM. El sello se debe codificar mediante 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 la marca de tiempo con el formato RFC 3339. En este ejemplo, se usa el formato aaaa-mm-ddThh:mm:ss+hh:mm—año, mes, día, hora, minuto, segundo y la compensación con respecto a la hora UTC. La compensación desde UTC es de menos 8 horas, lo que indica PST.

metadata {
  event_timestamp: "2019-09-10T20:32:31-08:00"
}

Especificación de 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 de UDM. 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 archivos adjuntos o URL. Por último, un sustantivo también podría usarse 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 UDM debe tener uno o más de los siguientes sustantivos especificados:

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 de producto, como un GUID de máquina de CrowdStrike) o detalles del usuario (por ejemplo, el nombre de usuario), y, de manera opcional, incluir detalles del proceso. NO debe incluir ninguno de los siguientes campos: correo electrónico, archivos, claves de registro o valores.

Si todos los eventos ocurren en la misma máquina, esa máquina solo debe describirse en las principales. No es necesario que la máquina también se describa en target o en src.

El siguiente ejemplo ilustra cómo se pueden propagar los campos principal:

principal {
  hostname: "jane_win10"
  asset_id: "Sophos.AV:C070123456-ABCDE"
      ip: "10.0.2.10"
      port: 60671
      user {  userid: "john.smith" }
}

El ejemplo anterior describe todo lo que se conoce acerca del dispositivo y el usuario que fue el actor principal descrito en el evento. Este ejemplo incluye la dirección IP y el número de puerto del dispositivo, así como su nombre de host. También incluye un identificador de recursos específico del proveedor (de Sophos), que es un identificador único generado por 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 destino. Para una inyección de proceso C en el proceso D de destino, el proceso C se describe como principal y el D como destino.

principal versus objetivo en udm

Principal frente a objetivo en UDM

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 sobre 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 de la máquina X al archivo B de la máquina Y, tanto el archivo A como la máquina X se especificarán en la parte src del evento de UDM.
  • intermediario: Representa los detalles de uno o más dispositivos intermedios que procesan la actividad descrita en el evento. Esto incluye los detalles del dispositivo sobre un servidor proxy, un servidor de retransmisión de SMTP, etcétera.
  • observador: Representa un dispositivo de observador (por ejemplo, un detector 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 e informa sobre él.
  • about: Se usa para almacenar detalles de todos los objetos a los que hace referencia el evento y que no se describen en participante, src, target, intermediario o observador. Por ejemplo, se podría usar para hacer un seguimiento de lo siguiente:
    • Enviar archivos adjuntos por correo electrónico
    • Dominios, URL o IP incorporados en el cuerpo del correo electrónico
    • DLL que se cargan durante un evento PROCESS_LAUNCH

Las secciones sobre entidades de los eventos de UDM incluyen información sobre los distintos participantes (dispositivos, usuarios, objetos como URLs, archivos, etc.) descritos en el evento. La UDM de Google Security Operations tiene requisitos obligatorios cuando se trata de 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.

Especificación del 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 propagar los campos 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 del proxy de seguridad del correo electrónico detectó dos archivos adjuntos infectados (SOFTWARE_MALICIOUS) y los puso en cuarentena y desinfectó (CUARANTINA, ALLOW_WITH_MODIFICATION) estos archivos adjuntos y luego reenvió el correo electrónico desinfectado.
  • Un sistema de SSO facilitó el acceso (AUTH_VIOLATION), que estaba bloqueado (BLOCK).
  • Una zona de pruebas de software malicioso detectó software espía (SOFTWARE_MALICIOUS) en un archivo adjunto cinco minutos después de la entrega del archivo (ALLOW) al usuario en su bandeja de entrada.