Da formato a 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 sin importar el tipo de evento. Estos campos incluyen lo siguiente:

• Entidades: Dispositivos, usuarios y procesos que participan en un evento.
• Metadatos del evento: Indica cuándo ocurrió el evento, el tipo de evento, de dónde provino, etcétera.
• Metadatos de red: Son metadatos de red de alto nivel para eventos orientados a la red, así como detalles de protocolos dentro de mensajes secundarios:
  • Metadatos de correo electrónico: Muestra la información de los campos Para, De, Cc, Cco y otros campos de correo electrónico.
  • Metadatos de HTTP: Method, referral_url, useragent, etcétera
• Resultados de seguridad: Cualquier clasificación o acción realizada por 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 mediante un campo de carga útil JSON de formato libre.

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

Si deseas dar formato a un evento de UDM de modo que esté listo para enviarse a Google, debes seguir estos pasos:

1. Especificación del tipo de evento: El tipo de evento seleccionado determina los campos que también debes incluir con el evento.
2. Especificar 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 participante que participa en el evento.
4. Especificación del resultado de seguridad: Especifica los resultados de seguridad. Para ello, incluye detalles sobre los riesgos y amenazas de seguridad que encontró un sistema de seguridad, así como las acciones que se realizaron para mitigar esos riesgos y amenazas.
5. Completa el resto de la información obligatoria y opcional del evento 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. 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 UDM 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 usando la notación de texto Proto3:

metadata {
    event_type: PROCESS_OPEN
}

Especifica la marca de tiempo del evento

Debe especificar la marca de tiempo de GMT para cualquier evento enviado en formato UDM con el archivo Metadata.event_timestamp. El sello debe codificarse con uno de los siguientes estándares:

• Para JSON, usa el 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 diferencia respecto de 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"
}

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 o usuario que realiza la actividad descrita en un evento, o el dispositivo o usuario objetivo de la actividad descrita en el evento. Los sustantivos también pueden ser archivos como archivos adjuntos o URLs. Por último, un sustantivo también podría 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 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, opcionalmente, incluir detalles del proceso. NO debe incluir ninguno de los siguientes campos: correo electrónico, archivos, claves o valores de registro.

Si todos los eventos ocurren en la misma máquina, esa máquina solo se debe describir en principal. No es necesario que la máquina se describa 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 intermediary. 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ía el principal.

En el siguiente ejemplo, se muestra cómo se podrían 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" }
}

En el ejemplo anterior, se describe todo lo que se conoce sobre el dispositivo y el usuario que fue el actor principal descrito en el evento. En este ejemplo, se 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 objetivo. Para una inserción de un proceso C en el proceso de destino D, el proceso C se describe como el principal y el proceso D se describe como el objetivo.

Comparación entre la principal y la Target de UDM

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

target {
   ip: "198.51.100.31"
   port: 80
}

Recuerda que, si hay más información disponible, como nombre de host, direcciones IP adicionales, direcciones MAC, identificadores de recursos propietarios, etc., también se deben incluir en el atributo target.

Tanto principal como objetivo (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 en 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 dispositivo o el contexto del 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 al archivo B en la máquina Y, el archivo A y 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, el servidor de retransmisión 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 y, además, informa sobre el evento en cuestión.
• about: Se usa para almacenar detalles sobre todos los objetos a los que hace referencia el evento y que no se describen en participant, src, target, intermediary ni observar. Por ejemplo, se podría usar 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 distintos participantes (dispositivos, usuarios, objetos como URLs, archivos, etc.) descritos en el evento. El UDM de Chronicle 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 en función del tipo de evento.

Cómo especificar 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 acciones que se realizaron para mitigar esos riesgos y amenazas. Los siguientes son ejemplos de algunos de los tipos de eventos de seguridad que requerirían que se propaguen los campos de SecurityResult:

• Un proxy de seguridad de correo electrónico detectó un intento de phishing (POST_PHISHING) y bloqueó (BLOQUEAR) el correo electrónico.
• Un firewall de proxy de seguridad de correo electrónico detectó dos archivos adjuntos infectados (SOFTWARE_MALICIOUS), los puso en cuarentena y los desinfectó (QUARANTINE, ALLOW_WITH_MODIFICATION) y, luego, reenvió el correo electrónico desinfectado.
• Un sistema de SSO permitió el acceso (AUTH_VIOLATION), que se bloqueó (BLOCK).
• Una zona de pruebas de software malicioso detectó un software espía (SOFTWARE_MALICIOUS) en un archivo adjunto cinco minutos después de que el archivo se haya entregado (ALLOW) al usuario en la bandeja de entrada.