Formato de 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. Entre estos campos, se incluyen los siguientes:

• Entidades: Dispositivos, usuarios y procesos involucrados en un evento.
• Metadatos del evento: Cuando ocurrió el evento, el tipo, evento, ubicación de origen, etcétera
• Metadatos de la red: Metadatos de red de alto nivel para eventos orientados a la red y detalles del protocolo dentro de los submensajes:
  • Metadatos de correo electrónico: Contiene información en los campos "para", "formulario", "Cc", "Cco" y otros.
  • Metadatos HTTP: Método, referral_url, useragent, etcétera
• Resultados de seguridad: cualquier clasificación o acción realizada por un producto de seguridad.
• Metadatos adicionales: Todos los datos de eventos importantes específicos de un proveedor que no se puedan representar de forma adecuada dentro de las secciones formales del modelo de UDM se pueden agregar mediante un campo de carga útil JSON sin formato.

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

Codificación UDM

Los eventos de UDM deben enviarse a Chronicle con 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()"

Da formato a un evento de UDM

Para formatear un evento de UDM y prepararlo para enviarlo a Google, debe completar los siguientes pasos:

1. Cómo especificar el tipo de evento: El tipo de evento seleccionado determina qué campos también debe incluir en el evento.
2. Especifica la marca de tiempo del evento-metadata-position="body" }: Especifica la marca de tiempo del evento.
3. Especifica sustantivos (entidades) —Cada evento debe incluir al menos unoSustantivo , en el que se describe un usuario o dispositivo participante en el evento
4. Especificar el resultado de seguridad: Si quieres especificar los resultados de seguridad, incluye detalles sobre los riesgos de seguridad y las amenazas que encontró un sistema de seguridad, así como las medidas que se tomaron para mitigarlos.
5. Llene el resto de la información de eventos obligatoria y opcional mediante los campos de eventos de 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, especificado con uno de los posibles valores disponibles para Metadata.event_type. Estos incluyen valores como Process_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS, etc. (para obtener la lista completa, consulta Metadata.event_type). Cada tipo de evento requiere que también propague 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 UDM a fin de obtener detalles sobre qué campos incluir en cada tipo de evento. En el siguiente ejemplo, se ilustra cómo especificar Process_OPEN como el tipo de evento mediante la notación de texto Proto3:

metadata {
    event_type: PROCESS_OPEN
}

Especifica la marca de tiempo del evento

Debes especificar la marca de tiempo GMT para cualquier evento enviado en formato UDM mediante 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 ilustra cómo especificarías la marca de tiempo con el formato RFC 3339. Para 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 desde UTC es menos 8 horas, lo que indica PST.

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

Especifica 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 podría ser, por ejemplo, el dispositivo o usuario que realiza la actividad descrita en un evento, o el dispositivo o usuario que es el objetivo de esa actividad descrita en el evento. Los sustantivos también pueden ser elementos como archivos adjuntos o URL. 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 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 máquina (nombre de host, MAC, IP, puerto, identificadores específicos del producto, como un GUID de máquina de CrowdStrike) o detalles del usuario (por ejemplo, nombre de usuario), y, de forma 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 se ejecutan 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 destino o en src.

Nota: Un dispositivo de seguridad puede originar un evento, pero no se describiría en el campo principal. se describiría en los campos observador o intermediarios. 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.

En el siguiente ejemplo, se muestra cómo se pueden 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 el ejemplo anterior, se describe todo lo conocido sobre el dispositivo y el usuario que fue el actor principal descrito en el evento. En este ejemplo, se incluyen la dirección IP y el número de puerto del dispositivo, así como el nombre de host. También incluye un identificador de activos específico del proveedor (de Sophos), que es un identificador único generado por el producto de seguridad de terceros.

objetivo: 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 desde el dispositivo A hacia el dispositivo B, A se describe como el principal y B se describe como el destino. En el caso de una inserción de procesos por proceso C en el proceso objetivo D, el proceso C se describe como el principal y el proceso D se describe como el objetivo.

Comparación entre el director y el objetivo en UDM

En el siguiente ejemplo, se ilustra cómo se propagan los campos para un destino:

target {
   ip: "198.51.100.31"
   port: 80
}

Nuevamente, si hay más información disponible, como nombre de host, direcciones IP adicionales, direcciones MAC, identificadores de elementos de propiedad, etc., también se deben incluir en destino.

Tanto principal como objetivo (así como otros sustantivos) pueden hacer referencia a los 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) y también en la máquina X.

• src: Representa un objeto de origen en el que el participante actúa 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án en la parte src del evento de UDM.
• Intermediario: Representa los detalles de una o más de las actividades de procesamiento de dispositivos intermedios que se describen en el evento. Esto incluye detalles del dispositivo sobre un servidor proxy, servidor de retransmisión de SMTP, etc.
• 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 e 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 de otra manera en participant, src, target, intermediario o observador. Por ejemplo, se puede usar para hacer un seguimiento de lo siguiente:
  • Archivos adjuntos de archivos de correo electrónico
  • Dominios, URL o IP incorporados en el cuerpo de un correo electrónico
  • DLL que se cargan durante un evento Process_LAUNCH

Las secciones de la entidad de eventos UDM incluyen información sobre los distintos participantes (dispositivos, usuarios, objetos como URL, archivos, etc.) descritos en el evento. El UDM de Chronicle tiene requisitos obligatorios para propagar los 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 debe rellenar difiere según el tipo de evento.

Especifica el resultado de seguridad

Opcionalmente, puede propagar los resultados de seguridad propagando los campos de SecurityResult, incluidos los detalles sobre los riesgos y las amenazas de seguridad que encontró el sistema de seguridad, así como mediante las acciones que se implementaron para mitigar esos riesgos y amenazas. Los siguientes son ejemplos de algunos de los tipos de eventos de seguridad que requerirían la propagación de los campos SecurityResult:

• Un proxy de seguridad de correo electrónico detectó un intento de suplantación de identidad (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ó el 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 el archivo se entregó al usuario en su carpeta Recibidos.