Cómo dar formato a los datos de registro como UDM

Compatible con:

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 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 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 el modelo de datos unificado (UDM).

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 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 determinará qué campos también debes incluir con 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 el dispositivo o usuario del participante que participa en el evento.
  4. Especificar el resultado de seguridad: (Opcional) Especifica los resultados de seguridad con la inclusión de detalles sobre las amenazas y los riesgos 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 del evento obligatoria y opcional con los campos de eventos del UDM.

Cómo 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 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
}

Cómo especificar la marca de tiempo del evento

Debes especificar la marca de tiempo (GMT) de cualquier evento enviado 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 la marca de tiempo con el formato RFC 3339. Para 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 de 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 la AUA, 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 usuario que realiza la actividad que se describe en un evento, o el dispositivo o usuario objetivo de la 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 de la AUA 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, el nombre de usuario) y, de manera opcional, detalles del proceso. NO debe incluir ninguno de los siguientes campos: correo electrónico, archivos, claves de registro o valores.

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 se describa en target ni 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" }
}

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 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 destino. 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 objetivo en udm

Principal vs. objetivo en UDM

En el siguiente ejemplo, se muestra cómo se propagan los campos de un destino:

target {
   ip: "198.51.100.31"
   port: 80
}

Nuevamente, si hay más información disponible, como el nombre de host, las direcciones IP adicionales, las direcciones MAC, los identificadores de activos propietarios, etc., también deben incluirse 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 sobre el que actúa el participante junto con el contexto del dispositivo o proceso del objeto de origen (la máquina donde 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 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 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:
    • 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 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.

Especifica el resultado de seguridad

De manera opcional, puedes especificar 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 medidas que se tomaron para mitigar esos riesgos y amenazas. 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ó 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.