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: Dispositivos, usuarios y procesos involucrados en un evento.
- Metadatos del evento: Cuándo ocurrió, el tipo del evento, su origen, etcétera.
- Metadatos de la red: metadatos de red de alto nivel para eventos orientados a la red y detalles de protocolo dentro de los submensajes:
- Metadatos de correo electrónico: Información en los campos de correo electrónico, 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: Se pueden agregar datos de eventos importantes específicos de cada proveedor que no se puedan representar de forma adecuada dentro de las secciones formales del modelo de UDM 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 unificados (UDM).
Codificación de UDM
Los eventos de UDM deben enviarse a Chronicle con uno de los siguientes formatos:
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 quieres formatear un evento de UDM a fin de enviarlo a Google, debes completar los siguientes pasos:
- Cómo especificar el tipo de evento: El tipo de evento seleccionado determina qué campos también debe incluir con el evento.
- Especifica la marca de tiempo del evento-metadata-position="body" }: Especifica la marca de tiempo del evento.
- Especificación de sustantivos: cada evento debe incluir al menos un sustantivo que describa a un participante participante o usuario que participa en el evento.
- Especificar el resultado de seguridad: Para especificar los resultados de seguridad, incluye detalles sobre los riesgos y las amenazas de seguridad que se encontraron en un sistema de seguridad, así como las medidas que se tomaron para mitigarlos.
- Completa el resto de la información de evento obligatoria y opcional con los campos de evento de UDM.
Especifica 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 ver 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. Si deseas obtener más detalles sobre qué campos incluir para cada tipo de evento, consulta Campos obligatorios y opcionales para cada tipo de evento de UDM. En el siguiente ejemplo, se muestra cómo especificar 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 de cualquier evento que se envíe en formato UDM con Metadata.event_timestamp. La marca debe estar codificada en función de 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 una 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. La compensación desde UTC es menos de 8 horas, lo que indica PST.
metadata {
event_timestamp: "2019-09-10T20:32:31-08:00"
}
Especificar sustantivos (entidades)
Para cada evento 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 archivos adjuntos o URL. Por último, también podría usarse un sustantivo 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 originó 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 de productos, como un GUID de máquina de CrowdStrike) o un detalle de usuario (por ejemplo, nombre de usuario), y, de forma opcional, puede 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 producen en la misma máquina, esa máquina solo debe describirse en principal. No es necesario que la máquina también se describa en target o en src.
El siguiente ejemplo 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 que se conoce 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 activo 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 la principal y B se describe como el destino. Para una inyección de proceso C en el proceso D de destino, el proceso C es 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
}
Una vez más, si hay más información disponible, como nombre de host, direcciones IP adicionales, direcciones MAC, identificadores de elementos de propiedad, etc., también deben incluirse en destino.
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 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 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, los archivos A y X se especificarán en la parte src del evento de UDM.
- intermediario: Representa los detalles de una o más 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 observador (por ejemplo, un detector de paquetes o un escáner de vulnerabilidades basado en la red), que no es un intermediario directo, sino 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 ni target, intermediario o observador. Por ejemplo, se puede usar para realizar un seguimiento de lo siguiente:
- Enviar archivos adjuntos por correo electrónico
- Dominios, URL o direcciones 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 URL, archivos, etc.) que se describen en el evento. El UDM de Chronicle tiene requisitos obligatorios para la propagación de los campos 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 completar difiere según el tipo de evento.
Especifica el resultado de seguridad
Opcionalmente, puedes 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, además de las medidas que se tomaron para mitigarlos. A continuación, se muestran ejemplos de algunos tipos de eventos de seguridad que pueden completar los campos SecurityResult:
- Un proxy de seguridad de correo electrónico detectó un intento de suplantación de identidad (phishing) (Mail_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) y los puso en cuarentena y desinfectó (QUARANTINE, ALLOW_WITH_MODIFICATION) y, luego, reenvió ese correo electrónico.
- 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 envió (ALLOW) al usuario en su carpeta Recibidos.