Formatear datos de registro como UDM

Todos los eventos del 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: Son los dispositivos, usuarios y procesos involucrados en un evento.
• Metadatos del evento: Indica 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 del protocolo dentro de mensajes secundarios:
  • Metadatos de correo electrónico: Información en los campos Para, De, Cc, Cco y otros.
  • Metadatos 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 pueda representarse de forma adecuada en las secciones formales del modelo de UDM se puede agregar a través de un campo de carga útil JSON.

En las siguientes secciones, se describe cómo codificar y formatear 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

Para 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 formatear un evento de UDM

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

1. Especificación del tipo de evento: El tipo de evento seleccionado determina los campos que también debe incluir con el evento.
2. Especificación de la marca de tiempo del evento: especifique 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 de un participante del evento.
4. Especificación del resultado de seguridad: Especifica los resultados de seguridad mediante detalles sobre los riesgos y las amenazas de seguridad que encontró un sistema de seguridad, así como las medidas que se tomaron para mitigarlos.
5. Complete el resto de la información de evento 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 valores posibles disponibles para Metadata.event_type. Incluyen valores como PROCESS_OPEN, FILE_CREATION, USER_CREATION, NETWORK_DNS, etc. (Para obtener la 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 qué campos incluir en cada tipo de evento. En el siguiente ejemplo, se muestra cómo especificarías PROCESS_OPEN como tipo de evento con la notación de texto 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. La estampilla se debe codificar 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. En este ejemplo, aaaa-mm-ddThh:mm:ss+hh:mm: año, mes, día, hora, minuto, segundo y compensación respecto de la hora UTC. La diferencia respecto 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 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/usuario que es el objetivo de esa actividad descrita en el evento. Los nombres 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 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 de los siguientes 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 la 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 de 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 llevan a cabo en la misma máquina, solo debe describirse en principal. No es necesario describir la máquina en target o 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 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" }
}

En el ejemplo anterior, se describe toda la información conocida sobre el dispositivo y el usuario que actuó como actor principal en el evento. En este ejemplo, se incluyen la dirección IP y el número de puerto del dispositivo, además de su nombre de host. También incluye un identificador de recursos específico del proveedor (de Sophos), que es un identificador único generado por un 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. En el caso de una inserción de procesos en el proceso C, el proceso D se describe como el principal, mientras que el proceso D se describe como el destino.

Diferencias entre el principal y el objetivo de UDM

En el siguiente ejemplo, se ilustra 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 recursos de propiedad, etc., también se deben incluir en el campo target.

Tanto principal como objetivo (al igual que 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 el participante actúa junto con el dispositivo o contexto de proceso para el objeto de origen (la máquina donde reside el objeto de origen). Por ejemplo, si el usuario U copia el archivo A en la máquina X en el archivo B en la máquina Y, tanto el archivo A como la máquina X se especificarían en la parte src del evento de UDM.
• Intermediario: Representa detalles sobre 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.
• observator: Representa un dispositivo observador (por ejemplo, un detector de paquetes o un análisis de vulnerabilidades basado en la red), que no es un intermediario directo, pero observa e informa sobre el evento en cuestión.
• about: Se usa para almacenar detalles en todos los objetos a los que se hace referencia en el evento que no se describen en participante, src, objetivo, intermediario u observador. Por ejemplo, podría usarse para hacer un seguimiento de lo siguiente:
  • Archivos adjuntos de correo electrónico
  • Dominios/URL/IP incorporados en el cuerpo de un correo electrónico
  • DLL que se cargan durante un evento PROCESS_LAUNCH

Las secciones de entidades de los eventos de UDM incluyen información sobre los diversos participantes (dispositivos, usuarios, objetos como URL, archivos, etc.) que se describen en el evento. El CDM de Chronicle tiene requisitos obligatorios cuando se trata de propagar campos de Sustantivo. 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 completar difiere según el tipo de evento.

Especifica el resultado de seguridad

De manera opcional, puede especificar los resultados de seguridad propagando los campos SecurityResult, incluidos los detalles sobre los riesgos y las amenazas de seguridad que encontró el sistema de seguridad, así como las acciones realizadas para mitigarlos. Los siguientes son ejemplos de algunos de los tipos de eventos de seguridad que requerirían completar 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) 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 entregara (ALLOW) al usuario en su carpeta Recibidos.