Da formato a los datos de registro como UDM

Todos los eventos de modelo de datos unificados (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 de evento: Cuando se produjo el evento, el tipo de evento, su origen, etc.
• Metadatos de red: Son metadatos de red de alto nivel para eventos orientados a la red y detalles de protocolo en submensajes:
  • Metadatos de correo electrónico: Información sobre los campos de correo electrónico, formulario, Cc y Cco, entre otros
  • Metadatos de HTTP: Método, URL de referencia, usuario-agente, etcétera
• Resultados de seguridad: Cualquier clasificación o acción que realiza un producto de seguridad.
• Metadatos adicionales: Cualquier dato importante del evento específico del proveedor que no se pueda representar de forma adecuada en las secciones formales del modelo de UDM se puede agregar mediante un campo de carga útil JSON sin formato.

En las siguientes secciones, se describe cómo codificar y dar formato a los eventos para el modelo de datos unificados (UDM).

Codificación de UDM

Los eventos de UDM se deben enviar a Chronicle con uno de los siguientes formatos:

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

A los fines de este documento, los campos se representan con una notación de puntos. Por ejemplo, la siguiente sintaxis de 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

Para dar formato a un evento de UDM a fin de que esté listo para enviarse a Google, debes completar los siguientes pasos:

1. Especificar el tipo de evento: el tipo de evento seleccionado determina los campos que también debes incluir en el evento.
2. Cómo especificar la marca de tiempo del evento-metadata-position="body" }: 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 de los participantes del evento.
4. Especificar el resultado de la seguridad: Especifica los resultados de la seguridad. Para ello, incluye detalles sobre las amenazas de seguridad que se encontraron en un sistema de seguridad y las medidas que se tomaron para mitigarlas.
5. Complete el resto de la información de eventos obligatoria y opcional con 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 valores posibles disponibles para Metadata.event_type. Estos incluyen valores como PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS, etc. (para obtener una lista completa, consulte 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. Consulte Campos obligatorios y opcionales para cada tipo de evento de UDM a fin de obtener detalles sobre los campos que se deben incluir para cada tipo de evento. En el siguiente ejemplo, se ilustra cómo especificarías PROCESS_OPEN como tipo de evento con 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 con Metadata.event_timestamp. El sello debe estar codificado 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, aaaa-mm-ddThh:mm:ss+hh:mm: año, mes, día, hora, minuto, segundo y la compensación desde la hora UTC. El desplazamiento de UTC es de menos 8 horas, lo que indica PST.

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

Cómo especificar 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/usuario que realiza la actividad descrita en un evento, o el dispositivo/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 se puede usar para describir un dispositivo de seguridad que haya observado 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 sustantivos especificados:

principal: Representa la entidad que actúa o el dispositivo que origina la actividad descrita en el evento. La principal debe incluir al menos un detalle de máquina (nombre de host, MAC, IP, puerto, identificadores específicos de productos, como un GUID de máquina de CrowdStrike) o detalles del usuario (por ejemplo, el nombre del usuario) y, de forma 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 realizan en la misma máquina, solo debe describirse en principal. No es necesario describir la máquina también en target o en src.

Nota: Un dispositivo de seguridad puede originar un evento, pero no se describiría en el campo principal; sí en un campo de observador o de 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 en el que 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" }
}

El ejemplo anterior describe todo lo que se conoce del dispositivo y del usuario que fue el actor principal descrito en el evento. Este ejemplo incluye el número de puerto y la dirección IP 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 referencia 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 hasta el dispositivo B, A se describe como el principal y B se describe como el objetivo. En el caso de la inserción de procesos por parte del proceso C en el proceso D de destino, el proceso C se describe como el principal, mientras que el proceso D se describe como el objetivo.

Comparación entre el principal 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 el nombre de host, las direcciones IP adicionales, las direcciones MAC, los identificadores de activos de propiedad, etc., también se deben incluir en el destino.

Tanto principal como target (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) también en la máquina X.

• src: Representa un objeto de origen en el que actúa el participante, junto con el contexto del proceso o del dispositivo para el 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, los archivos A y X se especificarían en la parte src del evento UDM.
• Intermedio: Representa 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, servidor de retransmisión de SMTP, etcétera.
• observer: Representa un dispositivo de observación (por ejemplo, un detector de paquetes o un análisis 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 se hace referencia en el evento que no se describen en participante, src, objetivo, intermediario ni observador. Por ejemplo, podría usarse para hacer un seguimiento de los siguientes elementos:
  • Archivos adjuntos 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 entidad de los eventos de 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 cuando se trata de propagar los campos Noun. Estos requisitos se describen en Campos obligatorios y opcionales para cada tipo de evento de UDM. El conjunto de campos de la entidad que se debe completar difiere según el tipo de evento.

Especifica el resultado de seguridad

De manera opcional, puedes especificar los resultados de seguridad propagando los campos SecurityResult, incluidos los detalles sobre los riesgos y las amenazas de seguridad que detectó el sistema de seguridad, así como las medidas que se tomaron para mitigarlos. 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 (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) y 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 la entrega del archivo (PERMITIR) al usuario en su carpeta Recibidos.