Formatear los datos de registro como UDM

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, 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 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:

• JSON (https://developers.google.com/protocol-buffers/docs/proto3#json)
• Proto3

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 dar formato a un evento de UDM para que esté listo para enviarse 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 al 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 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 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 archivos adjuntos o URL. Por último, un sustantivo también puede 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 activa o el dispositivo que origina la actividad que se describe 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 se describa en target ni en src.

Nota: Un dispositivo de seguridad podría originar un evento, pero no se describiría en el campo principal; se describiría en los campos observador o intermediario. Si el software de seguridad (por ejemplo, Carbon Black) se ejecuta en el mismo dispositivo que originó la actividad (por ejemplo, un extremo de Windows donde se detectó software malicioso), ese dispositivo también será el principal.

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 frente a 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á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 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ó 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.