Guide d'utilisation UDM

Ce document fournit les éléments suivants :

• Descriptions détaillées des champs de schéma du modèle de données unifié (UDM)
• Champs obligatoires et facultatifs pour les types d'entités
• Champs obligatoires et facultatifs pour chaque type d'événement

Pour en savoir plus sur des champs UDM spécifiques (par exemple, les numéros d'énumération), consultez la liste des champs du modèle de données unifié.

Formats de nom de champ UDM :

• Pour l'évaluation du moteur de règles, le préfixe commence par udm.
• Pour le normalisateur basé sur la configuration (CBN), le préfixe commence par event.idm.read_only_udm.

Remplissage des métadonnées d'événement

La section des métadonnées d'événement pour les événements UDM stocke des informations générales sur chaque événement.

Metadata.event_type

• Objectif : spécifie le type d'événement. Si un événement comporte plusieurs types possibles, cette valeur doit spécifier le type le plus spécifique.
• Obligatoire : oui.
• Encodage : doit correspondre à l'un des types énumérés event_type de l'UDM prédéfinis.
• Valeurs possibles : les sections suivantes listent toutes les valeurs possibles pour metadata.event_type dans l'UDM. Pour connaître les champs obligatoires et facultatifs pour chaque catégorie, consultez Champs obligatoires et facultatifs pour chaque type d'événement.

Événements d'analyste

• ANALYST_ADD_COMMENT
• ANALYST_UPDATE_PRIORITY
• ANALYST_UPDATE_REASON
• ANALYST_UPDATE_REPUTATION
• ANALYST_UPDATE_RISK_SCORE
• ANALYST_UPDATE_ROOT_CAUSE
• ANALYST_UPDATE_SEVERITY_SCORE
• ANALYST_UPDATE_STATUS
• ANALYST_UPDATE_VERDICT

Événements de l'appareil

Événements liés aux mises à jour du micrologiciel, de la configuration ou du programme sur un appareil (tel qu'un système de contrôle industriel ou un élément de technologie opérationnelle) :

• DEVICE_CONFIG_UPDATE
• DEVICE_FIRMWARE_UPDATE
• DEVICE_PROGRAM_DOWNLOAD
• DEVICE_PROGRAM_UPLOAD

Événements d'e-mail

Événements liés aux transactions par e-mail et aux inspections de sécurité des e-mails :

• EMAIL_UNCATEGORIZED
• EMAIL_TRANSACTION
• EMAIL_URL_CLICK (obsolète)

Événements non spécifiés

Valeur d'espace réservé pour un type d'événement non initialisé (les événements définis sur EVENTTYPE_UNSPECIFIED échouent à la validation UDM) :

• EVENTTYPE_UNSPECIFIED

Événements de fichier effectués sur un point de terminaison

• FILE_UNCATEGORIZED
• FILE_COPY (par exemple, copier un fichier sur une clé USB)
• FILE_CREATION
• FILE_DELETION
• FILE_MODIFICATION
• FILE_MOVE
• FILE_OPEN (par exemple, l'ouverture d'un fichier peut indiquer une brèche de sécurité)
• FILE_READ (par exemple, lecture d'un fichier de mots de passe)
• FILE_SYNC

Événements qui n'entrent dans aucune autre catégorie

Événements qui n'entrent dans aucune autre catégorie, y compris les événements du système d'exploitation non classés :

• GENERIC_EVENT

Événements d'activité de groupe

Événements liés à la création, à la modification ou à la suppression de groupes d'utilisateurs ou de groupes système :

• GROUP_UNCATEGORIZED
• GROUP_CREATION
• GROUP_DELETION
• GROUP_MODIFICATION

Événements mutex

Événements liés à la création ou à la gestion d'un objet d'exclusion mutuelle (mutex) sur un point de terminaison :

• MUTEX_UNCATEGORIZED
• MUTEX_CREATION

Événements de télémétrie réseau

Événements de télémétrie réseau, qui incluent les charges utiles de protocole brutes, telles que DHCP et DNS, ainsi que les résumés de protocole pour les protocoles tels que HTTP, SMTP et FTP, et les événements de flux et de connexion de NetFlow et des pare-feu :

• NETWORK_UNCATEGORIZED
• NETWORK_CONNECTION (par exemple, les détails de la connexion réseau d'un pare-feu)
• NETWORK_DHCP
• NETWORK_DNS
• NETWORK_FLOW (par exemple, statistiques de flux agrégées de Netflow)
• NETWORK_FTP
• NETWORK_HTTP
• NETWORK_SMTP

Traiter les événements

Tout événement lié à un processus, tel que le lancement d'un processus, un processus créant un élément malveillant, un processus s'injectant dans un autre processus, la modification d'une clé de registre ou la création d'un fichier malveillant sur le disque :

• PROCESS_UNCATEGORIZED
• PROCESS_INJECTION
• PROCESS_LAUNCH
• PROCESS_MODULE_LOAD
• PROCESS_OPEN
• PROCESS_PRIVILEGE_ESCALATION
• PROCESS_TERMINATION

Événements de registre

Utilisez les événements REGISTRY suivants plutôt que les événements SETTING lorsque vous traitez des événements de registre spécifiques à Microsoft Windows :

• REGISTRY_UNCATEGORIZED
• REGISTRY_CREATION
• REGISTRY_MODIFICATION
• REGISTRY_DELETION

Événements liés aux ressources

Événements liés à la création, à la lecture, à l'écriture, à la suppression ou à la modification des autorisations sur une ressource :

• RESOURCE_CREATION
• RESOURCE_DELETION
• RESOURCE_PERMISSIONS_CHANGE
• RESOURCE_READ
• RESOURCE_WRITTEN

Événements liés à l'analyse

Les événements orientés analyse incluent les analyses à la demande et les détections comportementales effectuées par les produits de sécurité des points de terminaison ou de la sécurité réseau (tels que les EDR, les antivirus, les outils d'analyse des failles ou les DLP) :

• SCAN_UNCATEGORIZED
• SCAN_FILE
• SCAN_HOST
• SCAN_NETWORK
• SCAN_PROCESS
• SCAN_PROCESS_BEHAVIORS (obsolète)
• SCAN_VULN_HOST
• SCAN_VULN_NETWORK

Événements de tâches planifiées (Planificateur de tâches Windows, cron, etc.)

• SCHEDULED_TASK_UNCATEGORIZED
• SCHEDULED_TASK_CREATION
• SCHEDULED_TASK_DELETION
• SCHEDULED_TASK_DISABLE
• SCHEDULED_TASK_ENABLE
• SCHEDULED_TASK_MODIFICATION

Événements de service

Événements liés à la création, à la suppression, à la modification, au démarrage ou à l'arrêt d'un service de système d'exploitation ou d'application :

• SERVICE_UNSPECIFIED
• SERVICE_CREATION
• SERVICE_DELETION
• SERVICE_MODIFICATION
• SERVICE_START
• SERVICE_STOP

Événements de paramètre

Pour définir les exigences relatives aux événements, consultez SETTING_UNCATEGORIZED, SETTING_CREATION, SETTING_MODIFICATION, SETTING_DELETION.

Événements de paramètre, y compris lorsqu'un paramètre système est modifié sur un point de terminaison :

• SETTING_UNCATEGORIZED
• SETTING_CREATION
• SETTING_DELETION
• SETTING_MODIFICATION

Messages d'état des produits de sécurité

Messages d'état des produits de sécurité indiquant que les agents sont actifs et envoyant des données de version, d'empreinte ou d'autres types :

• STATUS_UNCATEGORIZED
• STATUS_HEARTBEAT (indique que le produit est actif)
• STATUS_STARTUP
• STATUS_SHUTDOWN
• STATUS_UPDATE (mise à jour du logiciel ou de l'empreinte digitale)

Événements du journal d'audit du système

• SYSTEM_AUDIT_LOG_UNCATEGORIZED
• SYSTEM_AUDIT_LOG_WIPE

Événements d'activité d'authentification des utilisateurs

• USER_UNCATEGORIZED
• USER_BADGE_IN (par exemple, lorsqu'un utilisateur badge physiquement pour entrer sur un site)
• USER_CHANGE_PASSWORD
• USER_CHANGE_PERMISSIONS
• USER_COMMUNICATION
• USER_CREATION
• USER_DELETION
• USER_LOGIN
• USER_LOGOUT
• USER_RESOURCE_ACCESS
• USER_RESOURCE_CREATION
• USER_RESOURCE_DELETION
• USER_RESOURCE_UPDATE_CONTENT
• USER_RESOURCE_UPDATE_PERMISSIONS
• USER_STATS (obsolète)

Metadata.collected_timestamp

• Objectif : encode le code temporel GMT lorsque l'événement a été collecté par l'infrastructure de collecte locale du fournisseur.
• Encodage : RFC 3339, selon le format de code temporel JSON ou Proto3.
• Exemple :
  • RFC 3339 : '2019-09-10T20:32:31-08:00'
  • Format Proto3 : '2012-04-23T18:25:43.511Z'

Metadata.event_timestamp

• Objectif : encode le code temporel GMT lorsque l'événement a été généré.
• Obligatoire : oui
• Encodage : RFC 3339, selon le format de code temporel JSON ou Proto3.
• Exemple :
  • RFC 3339 : 2019-09-10T20:32:31-08:00
  • Format Proto3 : 2012-04-23T18:25:43.511Z

Metadata.description

• Objectif : description lisible par l'humain de l'événement.
• Encodage : chaîne alphanumérique, ponctuation autorisée, 1 024 octets maximum
• Exemple : Le fichier c:\bar\foo.exe n'a pas pu accéder au document sensible c:\documents\earnings.docx.

Metadata.product_event_type

• Objectif : nom ou type d'événement court, descriptif, lisible par l'humain et spécifique au produit.
• Encodage : chaîne alphanumérique, ponctuation autorisée, 64 octets maximum.
• Exemples :
  • Événement de création de registre
  • ProcessRollUp
  • Élévation des privilèges détectée
  • Logiciels malveillants bloqués

Metadata.product_log_id

• Objectif : encode un identifiant d'événement spécifique au fournisseur pour identifier l'événement de manière unique (un GUID). Les utilisateurs peuvent utiliser cet identifiant pour rechercher l'événement en question dans la console propriétaire du fournisseur.
• Encodage : chaîne alphanumérique sensible à la casse, ponctuation autorisée, 256 octets maximum.
• Exemple : ABcd1234-98766

Metadata.product_name

• Objectif : spécifie le nom du produit.
• Encodage : chaîne alphanumérique sensible à la casse, ponctuation autorisée, 256 octets maximum.
• Exemples :
  • Falcon
  • Symantec Endpoint Protection

Metadata.product_version

• Objectif : spécifie la version du produit.
• Encodage : chaîne alphanumérique, points et tirets autorisés, 32 octets maximum
• Exemples :
  • 1.2.3b
  • 10.3:rev1

Metadata.url_back_to_product

• Objectif : URL renvoyant vers un site Web pertinent où vous pouvez consulter plus d'informations sur cet événement spécifique (ou la catégorie d'événement générale).
• Encodage : URL RFC 3986 valide avec des paramètres facultatifs tels que des informations sur le port, etc. Doit comporter un préfixe de protocole avant l'URL (par exemple, https:// ou http://).
• Exemple : https://newco.altostrat.com:8080/event_info?event_id=12345

Metadata.vendor_name

• Objectif : spécifie le nom du fournisseur du produit.
• Encodage : chaîne alphanumérique sensible à la casse, ponctuation autorisée, 256 octets maximum
• Exemples :
  • CrowdStrike
  • Symantec

Remplissage des métadonnées de Noun

Dans cette section, le mot Nom est un terme générique utilisé pour représenter les entités suivantes : principal, src, target, intermediary, observer et about. Ces entités ont des attributs communs, mais représentent des objets différents dans un événement. Pour en savoir plus sur les entités et ce que chacune représente dans un événement, consultez Formater un événement UDM.

Noun.asset_id

• Objectif : identifiant d'appareil unique spécifique au fournisseur (par exemple, un GUID généré lors de l'installation d'un logiciel de sécurité des points de terminaison sur un nouvel appareil, utilisé pour suivre cet appareil unique au fil du temps).
• Encodage : (VendorName ou VendorAbbreviation):ID, où VendorName ou VendorAbbreviation est un nom de fournisseur non sensible à la casse, tel que Carbon Black ou CB, et ID est un identifiant client spécifique au fournisseur, unique au monde dans l'environnement de son client (par exemple, un GUID ou une valeur unique identifiant un appareil unique). VendorName est alphanumérique et ne doit pas dépasser 32 caractères. L'ID peut comporter jusqu'à 128 caractères et inclure des caractères alphanumériques, des tirets et des points.
• Exemple : CrowdStrike:0bce4259-4ada-48f3-a904-9a526b01311f
• Exemple : CS:0bce4259-4ada-48f3-a904-9a526b01311f

Noun.email

• Objectif : adresse e-mail
• Encodage : format d'adresse e-mail standard.
• Exemple : [e-mail]

Noun.file

• Objectif : métadonnées détaillées du fichier.
• Type : objet
• Consultez Remplissage des métadonnées de fichier.

Noun.hostname

• Objectif : champ du nom d'hôte ou du nom de domaine du client. Ne l'incluez pas si une URL est présente.
• Encodage : nom d'hôte RFC 1123 valide.
• Restriction de validation : les chaînes de nom d'hôte ne doivent pas dépasser 255 octets pour respecter les limites d'indexation de recherche.
• Exemples :
  • userwin10
  • www.altostrat.com

Noun.platform

• Objectif : système d'exploitation de la plate-forme.
• Encodage : énumération
• Valeurs possibles :
  • LINUX
  • MAC
  • WINDOWS
  • UNKNOWN_PLATFORM

Noun.platform_patch_level

• Objectif : niveau de correctif du système d'exploitation de la plate-forme.
• Encodage : chaîne alphanumérique avec ponctuation, 64 caractères maximum.
• Exemple : Build 17134.48

Noun.platform_version

• Objectif : version du système d'exploitation de la plate-forme.
• Encodage : chaîne alphanumérique avec ponctuation, 64 caractères maximum.
• Exemple : Microsoft Windows 10 version 1803

Noun.process

• Objectif : métadonnées détaillées du processus.
• Type : objet
• Consultez Remplissage des métadonnées de processus.

Noun.ip

• Objectif :
  • Adresse IP unique associée à une connexion réseau.
  • Une ou plusieurs adresses IP associées à un appareil participant au moment de l'événement (par exemple, si un produit EDR connaît toutes les adresses IP associées à un appareil, il peut toutes les encoder dans les champs d'adresse IP).
• Encodage : chaîne d'adresse IPv4 (4 octets) ou IPv6 (16 octets) valide (RFC 5942) encodée en ASCII.
• Répétabilité :
  • Si un événement décrit une connexion réseau spécifique (par exemple, srcip:srcport > dstip:dstport), vous ne devez fournir qu'une seule adresse IP.
  • Si un événement décrit une activité générale se produisant sur l'appareil d'un participant, mais pas une connexion réseau spécifique, vous pouvez fournir toutes les adresses IP associées à l'appareil au moment de l'événement.
• Exemples :
  • 192.168.1.2
  • 2001:db8:1:3::1

Noun.port

• Objectif : numéro de port réseau source ou de destination lorsqu'une connexion réseau spécifique est décrite dans un événement.
• Encodage : numéro de port TCP/IP valide compris entre 1 et 65 535.

• Exemples :

  • 80
  • 443
  Remarque : Si un numéro de port est spécifié, une seule adresse IP doit être spécifiée dans le même nom.

Noun.mac

• Objectif : une ou plusieurs adresses MAC associées à un appareil.
• Encodage : adresse MAC valide de 6 octets conforme au format EUI-48 (identifiant unique étendu de 48 bits) encodé en ASCII.
• Répétabilité : vous pouvez fournir toutes les adresses MAC associées à l'appareil au moment de l'événement.
• Exemples :
  • 00:24:98:7B:19:02
  • 00:00:5e:00:53:2a

Noun.administrative_domain

• Objectif : domaine auquel l'appareil appartient (par exemple, le domaine Windows).
• Encodage : chaîne de nom de domaine valide (128 caractères maximum).
• Exemple : corp.altostrat.com

Noun.registry

• Objectif : métadonnées détaillées du registre.
• Type : objet
• Consultez Remplissage des métadonnées du registre.

Noun.url

• Objectif : URL standard
• Encodage : URL (RFC 3986). Doit comporter un préfixe de protocole valide (par exemple, https:// ou ftp://). Doit inclure le domaine et le chemin d'accès complets. Peut inclure les paramètres de l'URL.
• Exemple : https://foo.altostrat.com/bletch?a=b;c=d

Noun.user

• Objectif : métadonnées utilisateur détaillées.
• Type : objet
• Consultez Remplissage des métadonnées utilisateur.

Remplissage des métadonnées d'authentification

Authentication.AuthType

• Objectif : type de système auquel un événement d'authentification est associé (UDM Google Security Operations).
• Encoding : type énuméré.
• Valeurs possibles :
  • AUTHTYPE_UNSPECIFIED
  • MACHINE : authentification des machines
  • PHYSICAL : authentification physique (par exemple, un lecteur de badge)
  • SSO
  • TACACS : protocole de la famille TACACS pour l'authentification des systèmes en réseau (par exemple, TACACS ou TACACS+)
  • VPN

Authentication.Authentication_Status

• Objectif : décrit l'état d'authentification d'un utilisateur ou d'un identifiant spécifique.
• Encoding : type énuméré.
• Valeurs possibles :
  • UNKNOWN_AUTHENTICATION_STATUS : état d'authentification par défaut
  • ACTIVE : la méthode d'authentification est active.
  • SUSPENDED : la méthode d'authentification est suspendue ou désactivée.
  • DELETED : la méthode d'authentification a été supprimée.
  • NO_ACTIVE_CREDENTIALS : la méthode d'authentification ne dispose d'aucun identifiant actif.

Authentication.auth_details

• Objectif : informations d'authentification définies par le fournisseur.
• Encoding : chaîne.

Authentication.Mechanism

• Objectif : mécanisme(s) utilisé(s) pour l'authentification.
• Encoding : type énuméré.
• Valeurs possibles :
  • MECHANISM_UNSPECIFIED : mécanisme d'authentification par défaut.
  • BADGE_READER
  • BATCH : authentification par lot.
  • CACHED_INTERACTIVE : authentification interactive à l'aide d'identifiants mis en cache.
  • HARDWARE_KEY
  • LOCALE
  • MECHANISM_OTHER : un autre mécanisme non défini ici.
  • NETWORK : authentification réseau.
  • NETWORK_CLEAR_TEXT : authentification réseau en texte clair.
  • NEW_CREDENTIALS : authentification avec de nouveaux identifiants.
  • OTP
  • REMOTE : authentification à distance
  • REMOTE_INTERACTIVE : RDP, services de terminal, Virtual Network Computing (VNC), etc.
  • SERVICE : authentification du service.
  • UNLOCK : authentification de déverrouillage directe par interaction humaine.
  • USERNAME_PASSWORD

Remplissage des métadonnées DHCP

Les champs de métadonnées DHCP (Dynamic Host Control Protocol) capturent les informations de journal du protocole de gestion de réseau DHCP.

Dhcp.client_hostname

• Objectif : nom d'hôte du client. Pour en savoir plus, consultez la section Options DHCP et extensions de fournisseur BOOTP de la RFC 2132.
• Encoding : chaîne.
• Restriction de validation : les chaînes d'option de nom d'hôte ne doivent pas dépasser 255 octets pour respecter les limites d'indexation de recherche.

Dhcp.client_identifier

• Objectif : identifiant client. Pour en savoir plus, consultez la section Options DHCP et extensions de fournisseur BOOTP de la RFC 2132.
• Encodage : octets.

Dhcp.file

• Objectif : nom de fichier de l'image de démarrage.
• Encoding : chaîne.

Dhcp.flags

• Objectif : valeur du champ d'options DHCP.
• Encodage : entier non signé de 32 bits.

Dhcp.hlen

• Objectif : longueur de l'adresse matérielle.
• Encodage : entier non signé de 32 bits.

Dhcp.hops

• Objectif : nombre de sauts DHCP.
• Encodage : entier non signé de 32 bits.

Dhcp.htype

• Objectif : type d'adresse matérielle.
• Encodage : entier non signé de 32 bits.

Dhcp.lease_time_seconds

• Objectif : durée de bail demandée par le client pour une adresse IP, en secondes. Pour en savoir plus, consultez la section Options DHCP et extensions de fournisseur BOOTP de la RFC 2132.
• Encodage : entier non signé de 32 bits.

Dhcp.opcode

• Objectif : code d'opération BOOTP (voir la section 3 de la RFC 951).
• Encoding : type énuméré.
• Valeurs possibles :
  • UNKNOWN_OPCODE
  • BOOTREQUEST
  • BOOTREPLY

Dhcp.requested_address

• Objectif : identifiant client. Pour en savoir plus, consultez la section Options DHCP et extensions de fournisseur BOOTP de la RFC 2132.
• Encodage : adresse IPv4 ou IPv6 valide (RFC 5942) encodée en ASCII.

Dhcp.seconds

• Objectif : secondes écoulées depuis que le client a commencé le processus d'acquisition ou de renouvellement d'adresse.
• Encodage : entier non signé de 32 bits.

Dhcp.sname

• Objectif : nom du serveur à partir duquel le client a demandé à démarrer.
• Encoding : chaîne.

Dhcp.transaction_id

• Objectif : ID de transaction du client.
• Encodage : entier non signé de 32 bits.

Dhcp.type

• Objectif : type de message DHCP. Pour en savoir plus, consultez la RFC 1533.
• Encoding : type énuméré.
• Valeurs possibles :
  • UNKNOWN_MESSAGE_TYPE
  • DÉCOUVRIR
  • OFFRE
  • DEMANDER
  • REFUSER
  • CONFIRMATION
  • NAK
  • RELEASE
  • INFORMER
  • WIN_DELECTED
  • WIN_EXPIRED

Dhcp.chaddr

• Objectif : adresse matérielle du client.
• Encodage : adresse MAC.

Dhcp.ciaddr

• Objectif : adresse IP du client.
• Encodage : adresse IPv4 ou IPv6 valide (RFC 5942) encodée en ASCII.

Dhcp.giaddr

• Objectif : adresse IP de l'agent de relais.
• Encodage : adresse IPv4 ou IPv6 valide (RFC 5942) encodée en ASCII.

Dhcp.siaddr

• Objectif : adresse IP du serveur d'amorçage suivant.
• Encodage : adresse IPv4 ou IPv6 valide (RFC 5942) encodée en ASCII.

Dhcp.yiaddr

• Objectif : votre adresse IP.
• Encodage : adresse IPv4 ou IPv6 valide (RFC 5942) encodée en ASCII.

Remarque : Lorsque Dhcp.type spécifie ACK, OFFER ou DECLINE, vous devez fournir une adresse IPv4 valide de 4 octets dans Dhcp.yiaddr ou Dhcp.requested_address ET une adresse MAC correspondante. Pour les codes d'opération de message REQUEST, RELEASE, WIN_DELETED ou WIN_EXPIRED, vous devez fournir une adresse IPv4 valide de 4 octets dans Dhcp.ciaddr ou Dhcp.yiaddr.

Remplissage des métadonnées d'option DHCP

Les champs de métadonnées des options DHCP capturent les informations de journal des options DHCP.

Option.code

• Objectif : stocke le code d'option DHCP. Pour en savoir plus, consultez la section Options DHCP et extensions de fournisseur BOOTP de la RFC 1533.
• Encodage : entier non signé de 32 bits.

Option.data

• Objectif : stocke les données de l'option DHCP. Pour en savoir plus, consultez la section Options DHCP et extensions de fournisseur BOOTP de la RFC 1533.
• Encodage : octets.

Remplissage des métadonnées DNS

Les champs de métadonnées DNS capturent les informations liées aux paquets de requêtes et de réponses DNS. Ils correspondent un à un aux données trouvées dans les datagrammes de requête et de réponse DNS.

Dns.authoritative

• Objectif : définissez cette option sur "true" pour les serveurs DNS faisant autorité.
• Encoding : booléen.

Dns.id

• Objectif : stocke l'identifiant de la requête DNS.
• Encodage : entier 32 bits.

Dns.response

• Objectif : définissez cette option sur "true" si l'événement est une réponse DNS.
• Encoding : booléen.

Dns.opcode

• Objectif : stocke l'OpCode DNS utilisé pour spécifier le type de requête DNS (standard, inverse, état du serveur, etc.).
• Encodage : entier 32 bits.

Dns.recursion_available

• Objectif : définissez cette option sur "true" si une résolution DNS récursive est disponible.
• Encoding : booléen.

Dns.recursion_desired

• Objectif : défini sur "true" si une résolution DNS récursive est demandée.
• Encoding : booléen.

Dns.response_code

• Objectif : stocke le code de réponse DNS tel que défini par la RFC 1035, "Domain Names - Implementation and Specification".
• Encodage : entier 32 bits.

Dns.truncated

• Objectif : défini sur "true" s'il s'agit d'une réponse DNS tronquée.
• Encoding : booléen.

Dns.questions

• Objectif : stocke les questions des messages du protocole de domaine. Consultez Remplissage des métadonnées de requête DNS.

Dns.answers

• Objectif : stocke la réponse à la requête de nom de domaine. Consultez Remplissage des métadonnées des enregistrements de ressources DNS.

Dns.authority

• Objectif : stocke les serveurs de noms de domaine qui ont validé la réponse à la requête de nom de domaine. Consultez Remplissage des métadonnées des enregistrements de ressources DNS.

Dns.additional

• Objectif : stocke les serveurs de noms de domaine supplémentaires qui peuvent être utilisés pour vérifier la réponse au domaine. Consultez Remplissage des métadonnées des enregistrements de ressources DNS.

Remplissage des métadonnées de la question DNS

Les champs de métadonnées de la question DNS capturent les informations contenues dans la section de la question d'un message de protocole de domaine.

Question.name

• Objectif : stocke le nom de domaine.
• Encoding : chaîne.
• Restriction de validation : les chaînes de requête de domaine ne peuvent pas rester vides et ne doivent pas dépasser 255 octets, conformément aux réglementations de la RFC 1035 et aux limites d'indexation de recherche.

Question.class

• Objectif : stocke le code spécifiant la classe de la requête.
• Encodage : entier 32 bits.

Question.type

• Objectif : stocke le code spécifiant le type de la requête.
• Encodage : entier 32 bits.

Remplissage des métadonnées des enregistrements de ressources DNS

Les champs de métadonnées d'enregistrement de ressource DNS capturent les informations contenues dans l'enregistrement de ressource d'un message de protocole de domaine.

ResourceRecord.binary_data

• Objectif : stocke les octets bruts de toutes les chaînes non UTF-8 pouvant être incluses dans une réponse DNS. Ce champ ne doit être utilisé que si les données de réponse renvoyées par le serveur DNS contiennent des données non UTF-8. Sinon, placez la réponse DNS dans le champ "data". Ce type d'informations doit être stocké ici plutôt que dans ResourceRecord.data.

• Encodage : octets.

  Remarque : Ce champ n'est pas spécifié dans la RFC 1035 (contrairement aux autres champs d'enregistrement de ressources DNS), mais il a été défini par Google SecOps pour l'UDM.

ResourceRecord.class

• Objectif : stocke le code spécifiant la classe de l'enregistrement de ressource.
• Encodage : entier 32 bits.

ResourceRecord.data

• Objectif : stocke la charge utile ou la réponse à la question DNS pour toutes les réponses encodées au format UTF-8. Par exemple, le champ de données peut renvoyer l'adresse IP de la machine à laquelle le nom de domaine fait référence. Si l'enregistrement de ressource est d'un type ou d'une classe différents, il peut contenir un autre nom de domaine (lorsqu'un nom de domaine est redirigé vers un autre nom de domaine). Les données doivent être stockées telles qu'elles sont dans la réponse DNS.
• Encoding : chaîne.

ResourceRecord.name

• Objectif : stocke le nom du propriétaire de l'enregistrement de ressource.
• Encoding : chaîne.

ResourceRecord.ttl

• Objectif : stocke l'intervalle de temps pendant lequel l'enregistrement de ressource peut être mis en cache avant que la source des informations ne soit à nouveau interrogée.
• Encodage : entier 32 bits.

ResourceRecord.type

• Objectif : stocke le code spécifiant le type de l'enregistrement de ressource.
• Encodage : entier 32 bits.

Remplissage des métadonnées d'e-mail

La plupart des champs de métadonnées d'e-mail capturent les adresses e-mail incluses dans l'en-tête du message et doivent respecter le format d'adresse e-mail standard (boîte-aux-lettres-locale@domaine) défini dans la norme RFC 5322. Par exemple, [e-mail].

Email.from

• Objectif : stocke l'adresse e-mail de l'expéditeur (from).
• Encoding : chaîne.

Email.reply_to

• Objectif : stocke l'adresse e-mail reply_to.
• Encoding : chaîne.

Email.to

• Objectif : stocke les adresses e-mail to.
• Encoding : chaîne.

Email.cc

• Objectif : stocke les adresses e-mail cc.
• Encoding : chaîne.

Email.bcc

• Objectif : stocke les adresses e-mail Cci.
• Encoding : chaîne.

Email.mail_id

• Objectif : stocke l'ID de l'e-mail (ou du message).
• Encoding : chaîne.
• Exemple : [e-mail]

Email.subject

• Objectif : stocke l'objet de l'e-mail.
• Encoding : chaîne.
• Exemple : "Veuillez lire ce message."

Remplissage des métadonnées des extensions

Types d'événements avec des métadonnées intégrées qui ne sont pas déjà classés par l'UDM Google SecOps.

Extensions.auth

• Objectif : extension des métadonnées d'authentification.
• Encoding : chaîne.
• Exemples :
  • Métadonnées de bac à sable (tous les comportements d'un fichier, par exemple FireEye)
  • Données de contrôle de l'accès au réseau (NAC)
  • Informations LDAP sur un utilisateur (par exemple, rôle, organisation, etc.).

Extensions.auth.auth_details

• Objectif : spécifier les détails spécifiques au fournisseur pour le type ou le mécanisme d'authentification. Les fournisseurs d'authentification définissent souvent des types tels que "via_mfa" ou "via_ad" qui fournissent des informations utiles sur le type d'authentification. Ces types peuvent toujours être généralisés dans auth.type ou auth.mechanism pour des raisons de facilité d'utilisation et de compatibilité des règles entre les ensembles de données.
• Encoding : chaîne.
• Exemples : via_mfa, via_ad.

Extensions.vulns

• Objectif : extension des métadonnées de la faille.
• Encoding : chaîne.
• Exemple : Données d'analyse des failles de l'hôte.

Remplissage des métadonnées de fichier

File.file_metadata

• Objectif : métadonnées associées au fichier.
• Encoding : chaîne.
• Exemples :
  • Auteur
  • Numéro de révision
  • Numéro de version
  • Date du dernier enregistrement

File.full_path

• Objectif : chemin d'accès complet identifiant l'emplacement du fichier sur le système.
• Encoding : chaîne.
• Exemple : \Program Files\Custom Utilities\Test.exe

File.md5

• Objectif : valeur de hachage MD5 du fichier.
• Encodage : chaîne, hexadécimal en minuscules.
• Exemple : 35bf623e7db9bf0d68d0dda764fd9e8c

File.mime_type

• Objectif : type MIME (Multipurpose Internet Mail Extensions) du fichier.
• Encoding : chaîne.
• Exemples :
  • PE
  • PDF
  • script powershell

File.sha1

• Objectif : valeur de hachage SHA-1 du fichier.
• Encodage : chaîne, hexadécimal en minuscules.
• Exemple : eb3520d53b45815912f2391b713011453ed8abcf

File.sha256

• Objectif : valeur de hachage SHA-256 du fichier.
• Encodage : chaîne, hexadécimal en minuscules.
• Exemple : d7173c568b8985e61b4050f81b3fd8e75bc922d2a0843d7079c81ca4b6e36417

File.size

• Objectif : taille du fichier.
• Encodage : entier non signé de 64 bits.
• Exemple : 342135

Remplissage des métadonnées FTP

Ftp.command

• Objectif : stocke la commande FTP.
• Encoding : chaîne.
• Exemples :
  • binary
  • supprimer
  • get
  • put

Population des métadonnées de groupe

Informations sur un groupe organisationnel. Pour représenter une identité de groupe organisationnel valide lors de la normalisation, vous devez paramétrer au moins un attribut de groupe principal en spécifiant une adresse e-mail dans Group.email_addresses ou un identifiant de sécurité Windows dans Group.windows_sid.

Group.creation_time

• Objectif : date et heure de création du groupe.
• Encodage : RFC 3339, selon le format de code temporel JSON ou Proto3.

Group.email_addresses

• Objectif : regrouper les coordonnées.
• Encodage : e-mail.

Group.group_display_name

• Objectif : nom à afficher du groupe.
• Encoding : chaîne.
• Exemples :
  • Finance
  • RH
  • Marketing

Group.product_object_id

• Objectif : identifiant d'objet utilisateur unique au niveau mondial pour le produit, tel qu'un identifiant d'objet LDAP.
• Encoding : chaîne.

Group.windows_sid

• Objectif : champ d'attribut de groupe de l'identifiant de sécurité (SID) Microsoft Windows.
• Encoding : chaîne.

Remplissage des métadonnées HTTP

Http.method

• Objectif : stocke la méthode de requête HTTP. Lorsque le trafic transite par les protocoles de transport HTTP ou HTTPS, vous devez spécifier une méthode de requête active. Vous ne pouvez pas laisser la méthode définie sur METHOD_UNSPECIFIED.
• Encoding : chaîne.
• Exemples :
  • GET
  • HEAD
  • POST

Http.referral_url

• Objectif : stocke l'URL de l'HTTP referer.
• Encodage : URL RFC 3986 valide.
• Exemple : https://www.altostrat.com

Http.response_code

• Objectif : stocke le code d'état de la réponse HTTP, qui indique si une requête HTTP spécifique a bien été effectuée.
• Encodage : entier 32 bits.
• Exemples :
  • 400
  • 404

Http.user_agent

• Objectif : stocke l'en-tête de requête User-Agent, qui inclut le type d'application, le système d'exploitation, le fournisseur de logiciels ou la version logicielle du user-agent du logiciel à l'origine de la requête. Les chaînes d'en-tête User-Agent doivent être entièrement composées de tableaux de caractères encodés en UTF-8 valides.
• Encoding : chaîne.
• Exemples :
  • Mozilla/5.0 (X11; Linux x86_64)
  • AppleWebKit/534.26 (KHTML, like Gecko)
  • Chrome/41.0.2217.0
  • Safari/527.33

Remplissage des métadonnées de lieu

Location.city

• Objectif : stocke le nom de la ville.
• Encoding : chaîne.
• Exemples :
  • Sunnyvale
  • Chicago
  • Malaga

Location.country_or_region

• Objectif : stocke le nom du pays ou de la région du monde.
• Encoding : chaîne.
• Exemples :
  • États-Unis
  • Royaume-Uni
  • Espagne

Location.name

• Objectif : stocke le nom spécifique à l'entreprise, tel qu'un bâtiment ou un campus.
• Encoding : chaîne.
• Exemples :
  • Campus 7B
  • Bâtiment A2

Location.state

• Objectif : stocke le nom de l'État, de la province ou du territoire.
• Encoding : chaîne.
• Exemples :
  • Californie
  • Illinois
  • Ontario

Remplissage des métadonnées réseau

Network.application_protocol

• Objectif : indique le protocole d'application réseau.
• Encoding : type énuméré.

• Valeurs possibles :

  • UNKNOWN_APPLICATION_PROTOCOL
  • AFP
  • APPC
  • AMQP
  • ATOM
  • BIP
  • BITCOIN
  • BIT_TORRENT
  • CFDP
  • CIP
  • COAP
  • COTP
  • DCERPC
  • DDS
  • DEVICE_NET
  • DHCP
  • DICOM
  • DNP3
  • DNS
  • E_DONKEY
  • ENRP
  • FAST_TRACK
  • FINGER
  • FREENET
  • FTAM
  • GOOSE
  • GOPHER
  • gRPC
  • HL7
  • H323
  • HTTP
  • HTTPS
  • IEC104
  • IRCP
  • KADEMLIA
  • KRB5
  • LDAP
  • LPD
  • MIME
  • MMS
  • MODBUS
  • MQTT
  • NETCONF
  • NFS
  • NIS
  • NNTP
  • NTCIP
  • NTP
  • OSCAR
  • PNRP
  • PTP
  • QUIC
  • RDP
  • RELP
  • RIP
  • RLOGIN
  • RPC
  • RTMP
  • RTP
  • RTPS
  • RTSP
  • SAP
  • SDP
  • SIP
  • SLP
  • PME
  • SMTP
  • SNMP
  • SNTP
  • SSH
  • SSMS
  • STYX
  • SV
  • TCAP
  • TDS
  • TOR
  • processus de vente technique
  • VTP
  • WHOIS
  • WEB_DAV
  • X400
  • X500
  • XMPP

Network.direction

• Objectif : indique la direction du trafic réseau.
• Encoding : type énuméré.
• Valeurs possibles :
  • UNKNOWN_DIRECTION
  • INBOUND
  • SORTANT
  • BROADCAST

Network.email

• Objectif : spécifie l'adresse e-mail de l'expéditeur/du destinataire.
• Encoding : chaîne.
• Exemple : [e-mail]

Network.ip_protocol

• Objectif : indique le protocole IP.
• Encoding : type énuméré.
• Valeurs possibles :
  • UNKNOWN_IP_PROTOCOL
  • EIGRP (Enhanced Interior Gateway Routing Protocol)
  • ESP (Encapsulating Security Payload)
  • ETHERIP : encapsulation Ethernet dans IP
  • GRE (Generic Routing Encapsulation)
  • ICMP (Internet Control Message Protocol)
  • IGMP : Internet Group Management Protocol
  • IP6IN4 : encapsulation IPv6
  • PIM (Protocol Independent Multicast)
  • TCP (protocole TCP
  • UDP (protocole de datagramme utilisateur)
  • VRRP (Virtual Router Redundancy Protocol)

Network.received_bytes

• Objectif : spécifie le nombre d'octets reçus.
• Encodage : entier non signé de 64 bits.
• Exemple : 12,453,654,768

Network.sent_bytes

• Objectif : spécifie le nombre d'octets envoyés.
• Encodage : entier non signé de 64 bits.
• Exemple : 7 654 876

Network.session_duration

• Objectif : stocke la durée de la session réseau, généralement renvoyée lors d'un événement d'abandon de la session. Pour définir la durée, vous pouvez définir network.session_duration.seconds = 1 (type int64) ou network.session_duration.nanos = 1 (type int32).
• Encodage :
  • Entier 32 bits : pour les secondes (network.session_duration.seconds).
  • Entier 64 bits : pour les nanosecondes (network.session_duration.nanos).

Network.session_id

• Objectif : stocke l'identifiant de la session réseau.
• Encoding : chaîne.
• Exemple : SID:ANON:www.w3.org:j6oAOxCWZh/CD723LGeXlf-01:34

Population des métadonnées de processus

Process.command_line

• Objectif : stocke la chaîne de ligne de commande du processus.
• Encoding : chaîne.
• Exemple : groupe c:\windows\system32\net.exe.

Process.product_specific_process_id

• Objectif : stocke l'ID de processus spécifique au produit.
• Encoding : chaîne.
• Exemples : MySQL:78778 ou CS:90512

Process.parent_process.product_specific_process_id

• Objectif : stocke l'ID de processus spécifique au produit pour le processus parent.
• Encoding : chaîne.
• Exemples : MySQL:78778 ou CS:90512

Process.file

• Objectif : stocke le nom du fichier utilisé par le processus.
• Encoding : chaîne.
• Exemple : report.xls

Process.parent_process

• Objectif : stocke les détails du processus parent.
• Encodage : nom (processus)

Process.pid

• Objectif : stocke l'ID du processus.
• Encoding : chaîne.
• Exemples :
  • 308
  • 2002

Remplissage des métadonnées du registre

Registry.registry_key

• Objectif : stocke la clé de registre associée à une application ou à un composant système.
• Encoding : chaîne.
• Exemple : HKEY_LOCAL_MACHINE/SYSTEM/DriverDatabase

Registry.registry_value_name

• Objectif : stocke le nom de la valeur de registre associée à une application ou à un composant système.
• Encoding : chaîne.
• Exemple : TEMP

Registry.registry_value_data

• Objectif : stocke les données associées à une valeur de registre.
• Encoding : chaîne.
• Exemple : %USERPROFILE%\Local Settings\Temp

Remplissage des métadonnées SecurityResult

Les métadonnées de résultat de sécurité incluent des détails sur les risques et les menaces de sécurité détectés par un système de sécurité, ainsi que sur les mesures prises pour les atténuer.

SecurityResult.about

• Objectif : fournir une description du résultat de sécurité.
• Encodage : nom.

SecurityResult.action

• Objectif : spécifiez une action de sécurité.
• Encoding : type énuméré.
• Valeurs possibles : l'UDM Google SecOps définit les actions de sécurité suivantes :
  • AUTORISER
  • ALLOW_WITH_MODIFICATION : le fichier ou l'e-mail a été désinfecté ou réécrit, puis transféré.
  • BLOQUER
  • QUARANTINE : stocker pour une analyse ultérieure (ne signifie pas bloquer).
  • UNKNOWN_ACTION

SecurityResult.action_details

• Objectif : détails fournis par le fournisseur sur l'action entreprise à la suite de l'incident de sécurité. Les actions de sécurité sont souvent mieux traduites dans le champ UDM plus général Security_Result.action. Toutefois, vous devrez peut-être rédiger des règles pour la description exacte de l'action fournie par le fournisseur.
• Encoding : chaîne.
• Exemples : drop, block, decrypt, encrypt.

SecurityResult.category

• Objectif : spécifier une catégorie de sécurité.
• Encoding : énumération.
• Valeurs possibles : l'UDM Google SecOps définit les catégories de sécurité suivantes :
  • ACL_VIOLATION : tentative d'accès non autorisé, y compris tentative d'accès à des fichiers, des services Web, des processus, des objets Web, etc.
  • AUTH_VIOLATION : échec de l'authentification (par exemple, mot de passe incorrect ou échec de l'authentification à deux facteurs).
  • DATA_AT_REST—DLP : données de capteur trouvées au repos lors d'une analyse.
  • DATA_DESTRUCTION : tentative de destruction ou de suppression de données.
  • DATA_EXFILTRATION—DLP : transmission de données de capteurs, copie sur une clé USB.
  • EXPLOIT : tentatives de dépassement de capacité, mauvais encodages de protocole, ROP, injection SQL, etc., à la fois sur le réseau et sur l'hôte.
  • MAIL_PHISHING : e-mails d'hameçonnage, messages de chat, etc.
  • MAIL_SPAM : e-mail, message, etc. de spam.
  • MAIL_SPOOFING : adresse e-mail source usurpée, etc.
  • NETWORK_CATEGORIZED_CONTENT
  • NETWORK_COMMAND_AND_CONTROL : si le canal de commande et de contrôle est connu.
  • NETWORK_DENIAL_OF_SERVICE
  • NETWORK_MALICIOUS : commande et contrôle, exploitation du réseau, activité suspecte, tunnel inverse potentiel, etc.
  • NETWORK_SUSPICIOUS : non lié à la sécurité, par exemple, l'URL est liée à des jeux d'argent et de hasard, etc.
  • NETWORK_RECON : analyse de port détectée par un IDS, sondage par une application Web.
  • POLICY_VIOLATION : non-respect des règles de sécurité, y compris des règles de pare-feu, de proxy et de HIPS, ou actions de blocage NAC.
  • SOFTWARE_MALICIOUS : logiciels malveillants, logiciels espions, rootkits, etc.
  • SOFTWARE_PUA : application potentiellement indésirable, telle qu'un logiciel publicitaire, etc.
  • SOFTWARE_SUSPICIOUS
  • UNKNOWN_CATEGORY

SecurityResult.confidence

• Objectif : spécifier un niveau de confiance concernant un événement lié à la sécurité, tel qu'estimé par le produit.
• Encoding : énumération.
• Valeurs possibles : l'UDM Google SecOps définit les catégories de confiance de produit suivantes :
  • UNKNOWN_CONFIDENCE
  • LOW_CONFIDENCE
  • MEDIUM_CONFIDENCE
  • HIGH_CONFIDENCE

SecurityResult.confidence_details

• Objectif : informations supplémentaires concernant la fiabilité d'un événement lié à la sécurité, telle qu'estimée par le fournisseur du produit.
• Encoding : chaîne.

SecurityResult.priority

• Objectif : spécifier une priorité concernant un événement de sécurité, telle qu'estimée par le fournisseur du produit.
• Encoding : énumération.
• Valeurs possibles : l'UDM Google SecOps définit les catégories de priorité de produit suivantes :
  • UNKNOWN_PRIORITY
  • LOW_PRIORITY
  • MEDIUM_PRIORITY
  • HIGH_PRIORITY

SecurityResult.priority_details

• Objectif : informations spécifiques au fournisseur sur la priorité du résultat de sécurité.
• Encoding : chaîne.

SecurityResult.rule_id

• Objectif : identifiant de la règle de sécurité.
• Encoding : chaîne.
• Exemples :
  • 08123
  • 5d2b44d0-5ef6-40f5-a704-47d61d3babbe

SecurityResult.rule_name

• Objectif : nom de la règle de sécurité.
• Encoding : chaîne.
• Exemple : BlockInboundToOracle.

SecurityResult.severity

• Objectif : gravité d'un événement lié à la sécurité, estimée par le fournisseur du produit à l'aide des valeurs définies par l'UDM Google SecOps.
• Encoding : énumération.
• Valeurs possibles : l'UDM Google SecOps définit les niveaux de gravité suivants pour les produits :
  • UNKNOWN_SEVERITY : non malveillant
  • INFORMATIONAL—Non-malicious
  • ERREUR : non malveillant
  • LOW—Malicious
  • MOYENNE : malveillant
  • ÉLEVÉ : malveillant

SecurityResult.severity_details

• Objectif : gravité d'un événement lié à la sécurité, telle qu'estimée par le fournisseur du produit.
• Encoding : chaîne.

SecurityResult.threat_name

• Objectif : nom de la menace de sécurité.
• Encoding : chaîne.
• Exemples :
  • W32/File-A
  • Slammer

SecurityResult.url_back_to_product

• Objectif : URL vous redirigeant vers la console du produit source pour cet événement de sécurité.
• Encoding : chaîne.

Remplissage des métadonnées utilisateur

Remarque : Tous les paramètres de compte utilisateur principaux (en particulier User.userid, User.windows_sid, User.employee_id et chaque adresse e-mail individuelle dans User.email_addresses) ont une longueur structurelle maximale obligatoire de 256 caractères. Si vous fournissez une chaîne d'identité de compte de plus de 256 caractères, la validation de l'indexation rejettera la charge utile. De plus, pour effacer les vérifications d'identité de l'utilisateur principal lors de la normalisation, vous devez renseigner au moins l'une de ces quatre propriétés principales.

User.email_addresses

• Objectif : stocke les adresses e-mail de l'utilisateur.
• Encoding : chaîne répétée.
• Exemple : [e-mail]

User.employee_id

• Objectif : stocke l'ID d'employé des ressources humaines pour l'utilisateur.
• Encoding : chaîne.
• Exemple : 11223344.

User.first_name

• Objectif : stocke le prénom de l'utilisateur.
• Encoding : chaîne.
• Exemple : Jean

User.middle_name

• Objectif : stocke le deuxième prénom de l'utilisateur.
• Encoding : chaîne.
• Exemple : Anthony

User.last_name

• Objectif : stocke le nom de l'utilisateur.
• Encoding : chaîne.
• Exemple : Locke.

User.group_identifiers

• Objectif : stocke les ID de groupe (un GUID, un OID LDAP ou similaire) associés à un utilisateur.
• Encoding : chaîne répétée.
• Exemple : admin-users.

User.phone_numbers

• Objectif : stocke les numéros de téléphone de l'utilisateur.
• Encoding : chaîne répétée.
• Exemple : 18005550101

User.title

• Objectif : stocke l'intitulé du poste de l'utilisateur.
• Encoding : chaîne.
• Exemple : gestionnaire de la relation client.

User.user_display_name

• Objectif : stocke le nom à afficher de l'utilisateur.
• Encoding : chaîne.
• Exemple : John Locke.

User.userid

• Objectif : stocke l'ID utilisateur.
• Encoding : chaîne.
• Exemple : jlocke.

User.windows_sid

• Objectif : stocke l'identifiant de sécurité (SID) Microsoft Windows associé à un utilisateur.
• Encoding : chaîne.
• Exemple : S-1-5-21-1180649209-123456789-3582944384-1064

Remplissage des métadonnées de failles

Vulnerability.about

• Objectif : si la faille concerne un nom spécifique (par exemple, un exécutable), ajoutez-le ici.
• Encodage : nom. Consultez Remplissage des métadonnées de nom.
• Exemple : exécutable.

Vulnerability.cvss_base_score

• Objectif : score de base pour le système CVSS (Common Vulnerability Scoring System).
• Encodage : virgule flottante.
• Plage : 0,0 à 10,0
• Exemple : 8,5

Vulnerability.cvss_vector

• Objectif : vecteur des propriétés CVSS de la faille. Un score CVSS est composé des métriques suivantes :

  • Vecteur d'attaque (AV)
  • Complexité d'accès (AC)
  • Authentification (Au)
  • Impact sur la confidentialité (C)
  • Impact sur l'intégrité (I)
  • Impact sur la disponibilité (A)

  Pour en savoir plus, consultez https://nvd.nist.gov/vuln-metrics/cvss/v2-calculator.

• Encoding : chaîne.

• Exemple : AV:L/AC:H/Au:N/C:N/I:P/A:C

Vulnerability.cvss_version

• Objectif : version CVSS du score ou du vecteur de la faille.
• Encoding : chaîne.
• Exemple : 3.1

Vulnerability.description

• Objectif : description de la faille.
• Encoding : chaîne.

Vulnerability.first_found

• Objectif : Les produits qui conservent un historique des analyses de failles doivent renseigner le champ first_found avec l'heure à laquelle la faille de cet élément a été détectée pour la première fois.
• Encoding : chaîne.

Vulnerability.last_found

• Objectif : les produits qui conservent un historique des analyses des failles doivent renseigner le champ "last_found" avec l'heure à laquelle la faille de cet élément a été détectée le plus récemment.
• Encoding : chaîne.

Vulnerability.name

• Objectif : nom de la faille.
• Encoding : chaîne.
• Exemple : Version d'OS non compatible détectée.

Vulnerability.scan_end_time

• Objectif : si la faille a été découverte lors d'une analyse d'éléments, renseignez ce champ avec l'heure de fin de l'analyse. Laissez ce champ vide si l'heure de fin n'est pas disponible ou non applicable.
• Encoding : chaîne.

Vulnerability.scan_start_time

• Objectif : si la faille a été découverte lors d'une analyse d'éléments, renseignez ce champ avec l'heure de début de l'analyse. Laissez ce champ vide si l'heure de début n'est pas disponible ou non applicable.
• Encoding : chaîne.

Vulnerability.severity

• Objectif : gravité de la faille.
• Encoding : type énuméré.
• Valeurs possibles :
  • UNKNOWN_SEVERITY
  • LOW
  • MEDIUM
  • FORT

Vulnerability.severity_details

• Objectif : détails de gravité spécifiques au fournisseur.
• Encoding : chaîne.

Remplissage des métadonnées d'alerte

Attention : Ces champs sont obsolètes. Utilisez les alertes de règle de détection YARA-L pour les métadonnées d'alerte. Pour plus d'informations, consultez la section Abandons de fonctionnalités.

idm.is_significant

• Objectif : indique si l'alerte doit être affichée dans Enterprise Insights.
• Encoding : booléen.

idm.is_alert

• Objectif : indique si l'événement est une alerte.
• Encoding : booléen.

Champs obligatoires et facultatifs pour les types d'entités

Type d'entité	Exigences spécifiques à l'entité
IP_ADDRESS	entity.ip doit contenir au moins une adresse IPv4 ou IPv6 valide.
FILE	entity.file doit être présent et contenir au moins un champ.
DOMAIN_NAME	entity.hostname doit être présent et représenter un nom d'hôte valide d'une longueur maximale de 255 octets. Optional : si entity.domain.whois_server est renseigné, le message entity.domain ne doit pas contenir plus de 50 champs inférés.
URL	entity.url doit être présent et ne pas être vide.
MUTEX	entity.resource doit être présent. entity.resource.resource_type doit être défini sur MUTEX. entity.resource.name doit être présent et ne pas être vide.
USER	entity.user doit être présent. Pour les entités de contexte, entity.user doit spécifier au moins un champ d'identité principal : user.userid, user.windows_sid, user.employee_id ou une adresse e-mail dans user.email_addresses. Chaque identifiant principal ne doit pas dépasser 256 caractères. De plus, vous devez fournir product_object_id dans entity.user ou product_entity_id dans metadata. Pour les entités d'indicateur de compromission (IOC), entity.user doit comporter au moins une adresse e-mail spécifiée dans user.email_addresses.
RESOURCE	entity.resource doit être présent. Pour les entités de contexte, entity.resource.resource_type doit être spécifié et ne doit pas être vide. Vous devez également fournir product_object_id dans entity.resource ou product_entity_id dans metadata. Pour les entités d'indicateur de compromission (IoC), entity.resource.resource_type doit être défini sur MUTEX ou STORAGE_OBJECT. Si resource_type est défini sur MUTEX : suivez les exigences de MUTEX. Si resource_type est STORAGE_OBJECT : entity.resource.resource_subtype doit être présent et ne pas être vide. Au moins l'un des champs suivants de entity.registry doit être présent et non vide : entity.registry.registry_key entity.registry.registry_value_data entity.registry.registry_value_name
CIDR_BLOCK	entity.network.ip_subnet_range doit être présent et inclure une notation CIDR (Classless Inter-Domain Routing) valide au format suivant : ip_address/prefix_length.
ASSET	entity.asset doit être présent. entity.asset doit contenir au moins un champ d'identité principal : asset.hostname, asset.asset_id, une adresse IP dans asset.ip ou une adresse MAC dans asset.mac. Toutes les adresses IP fournies doivent être au format IPv4 ou IPv6 valide. Vous devez indiquer product_object_id dans entity.asset ou product_entity_id dans metadata.
GROUP	entity.group doit être présent. entity.group doit spécifier au moins un champ d'identité principal : une adresse e-mail dans group.email_addresses ou un identifiant de sécurité Windows dans group.windows_sid. Vous devez indiquer product_object_id dans entity.group ou product_entity_id dans metadata.
AI	entity.ai doit être présent.

Champs obligatoires et facultatifs pour chaque type d'événement

Cette section décrit les champs obligatoires et facultatifs à renseigner pour chaque type d'événement UDM.

Pour en savoir plus sur des champs UDM spécifiques (par exemple, les numéros d'énumération), consultez la liste des champs du modèle de données unifié.

DEVICE_CONFIG_UPDATE, DEVICE_FIRMWARE_UPDATE, DEVICE_PROGRAM_DOWNLOAD, DEVICE_PROGRAM_UPLOAD

Champs obligatoires :

• metadata : incluez les champs obligatoires (event_timestamp et event_type).
• principal : incluez au moins un identifiant de machine (principal.hostname, principal.ip, principal.mac ou principal.asset_id).

Champs facultatifs :

• principal.user : à renseigner si des informations utilisateur sont disponibles pour le compte qui a initié la mise à jour de l'appareil.
• target : indiquez des informations sur l'appareil, le micrologiciel, la ressource de configuration ou le fichier de programme cible s'ils sont différents de principal.
• security_result : décrit toute activité malveillante ou anormale détectée.

Exemple d'UDM pour DEVICE_FIRMWARE_UPDATE

L'exemple suivant montre comment mettre en forme un événement DEVICE_FIRMWARE_UPDATE pour l'UDM Google SecOps :

{
  "metadata": {
    "event_timestamp": "2025-03-10T14:22:05.000000Z",
    "event_type": "DEVICE_FIRMWARE_UPDATE"
  },
  "principal": {
    "hostname": "plc-controller-01",
    "ip": [
      "10.20.30.40"
    ]
  }
}

Comme le montre cet exemple, l'événement est divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• principal : informations sur l'appareil sur lequel la mise à jour du micrologiciel a eu lieu.

EMAIL_TRANSACTION, EMAIL_UNCATEGORIZED

Champs obligatoires :

• metadata : incluez les champs obligatoires.
• principal : renseignez les informations sur la machine d'où provient l'e-mail (par exemple, l'adresse IP de l'expéditeur).

Champs facultatifs :

• about : URL, adresses IP, domaines et pièces jointes intégrés au corps de l'e-mail. Notez que about.file.hash n'est pas un champ indexé pour les hachages de fichiers. Les vues de hachage ne seront pas renseignées à partir d'un hachage de pièce jointe normalisé dans ce champ.
• securityResult.about : URL, adresses IP et fichiers malveillants intégrés dans le corps de l'e-mail.
• network.email : informations sur l'expéditeur ou le destinataire de l'e-mail. Notez que network.email n'est pas un champ d'alias. Si vous avez besoin d'aliasing et d'enrichissement pour la recherche ou la détection, vous devez indexer dans le compte principal ou la cible à l'aide d'une extension d'analyseur.
• principal : si des données de la machine cliente indiquent qui a envoyé l'e-mail, renseignez les détails du serveur dans le champ "principal" (par exemple, le processus client, les numéros de port, le nom d'utilisateur, etc.).
• target : si des données sur le serveur de messagerie de destination sont disponibles, renseignez les détails du serveur dans "target" (par exemple, l'adresse IP).
• intermediary : s'il existe des données de serveur de messagerie ou de proxy de messagerie, renseignez les détails du serveur dans "intermediary".

Remarques :

• Ne renseignez jamais principal.email ni target.email.
• Ne renseignez que le champ d'adresse e-mail dans security_result.about ou network.email.
• Les résultats de sécurité de premier niveau ont généralement un ensemble de noms (facultatif pour le spam).
• EMAIL_URL_CLICK est marqué comme obsolète.

Exemple d'UDM pour EMAIL_TRANSACTION

L'exemple suivant illustre comment un événement de type EMAIL_TRANSACTION serait formaté pour l'UDM Google SecOps :

metadata {
  event_timestamp: "2023-07-06T06:26:10.448584Z"
  event_type: EMAIL_TRANSACTION
}
principal {
  ip: "1.2.3.4"
}

Comme le montre cet exemple, l'événement est divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• principal : informations sur l'appareil à l'origine de l'e-mail.

FILE_CREATION, FILE_DELETION, FILE_MODIFICATION, FILE_READ, FILE_OPEN et FILE_UNCATEGORIZED

Champs obligatoires :

• metadata : incluez les champs obligatoires.
• principal :
  • Au moins un identifiant de machine.
  • (Facultatif) Renseignez principal.process avec des informations sur le processus qui accède au fichier.
• target :
  • Si le fichier est distant (par exemple, un partage SMB), la cible doit inclure au moins un identifiant de machine pour la machine cible. Sinon, tous les identifiants de machine doivent être vides.
  • Renseignez target.file avec des informations sur le fichier.

Champs facultatifs :

• security_result : décrit l'activité malveillante détectée.
• principal.user : à renseigner si des informations utilisateur sont disponibles sur le processus.

Exemple d'UDM pour FILE_MODIFICATION

L'exemple suivant illustre comment un événement de type FILE_MODIFICATION serait formaté pour l'UDM Google SecOps :

metadata {
  event_timestamp: "2023-07-03T12:14:38.164507Z"
  event_type: FILE_MODIFICATION
}
principal {
  hostname: "pinguino-01"
}
target {
  file {
    full_path: "foo.bar"
  }
}

Comme le montre cet exemple, l'événement est divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• principal : informations sur l'appareil sur lequel la modification du fichier a eu lieu.
• target : informations sur le fichier modifié.

FILE_COPY

Champs obligatoires :

• metadata : incluez les champs obligatoires comme décrit.
• principal :
  • Au moins un identifiant de machine.
  • (Facultatif) Renseignez principal.process avec des informations sur le processus effectuant l'opération de copie de fichier.
• src :
  • Renseignez src.file avec des informations sur le fichier source.
  • Si le fichier est distant (par exemple, un partage SMB), "src" doit inclure au moins un identifiant de machine pour la machine source stockant le fichier source.
• target :
  • Renseignez target.file avec des informations sur le fichier cible.
  • Si le fichier est distant (par exemple, un partage SMB), le champ target doit inclure au moins un identifiant de machine pour la machine cible qui contient le fichier cible.

Champs facultatifs :

• security_result : décrit l'activité malveillante détectée.
• principal.user : à renseigner si des informations utilisateur sont disponibles sur le processus.

FILE_MOVE, FILE_SYNC

Champs obligatoires :

• metadata : informations générales sur l'événement.
• principal : au moins un identifiant de machine (par exemple, principal.hostname).
• src : indiquez src.file (par exemple, src.file.full_path) pour représenter le fichier d'origine. Ce champ est obligatoire pour FILE_MOVE et FILE_COPY. Pour FILE_SYNC, vous devez renseigner au moins src.file ou target.file (et target ne doit pas être vide).
• target : renseignez target.file (par exemple, target.file.full_path) pour représenter le fichier de destination. Ce champ est obligatoire pour FILE_MOVE et FILE_COPY. Pour FILE_SYNC, vous devez renseigner au moins l'un des champs src.file ou target.file.

Exemple d'UDM pour FILE_MOVE

L'exemple suivant illustre comment un événement de type FILE_MOVE serait formaté pour l'UDM Google SecOps :

{
    "metadata": {
        "event_timestamp": "2023-07-03T12:45:02.557878Z",
        "event_type": "FILE_MOVE"
    },
    "src": {
        "file": {
            "full_path": "foo.bar"
        }
    },
    "principal": {
        "hostname": "pinguino-01"
    },
    "target": {
        "file": {
            "full_path": "foo.bar"
        }
    }
}

Comme le montre cet exemple, l'événement est divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• principal : informations sur l'appareil sur lequel le déplacement du fichier a eu lieu.
• src : informations sur le fichier source.
• target : informations sur le fichier de destination.

GENERIC_EVENT

N'utilisez GENERIC_EVENT que lorsqu'un événement ne correspond à aucune autre catégorie de type d'événement UDM.

Champs obligatoires :

• metadata : incluez les champs obligatoires (event_timestamp et event_type).

Champs facultatifs :

• metadata.product_event_type et metadata.description : incluez le nom de l'événement spécifique au fournisseur et une description lisible par l'humain.
• principal, target, src, intermediary, observer et about : renseignez toutes les entités impliquées dans l'événement. GENERIC_EVENT n'applique pas d'exigences de champ spécifiques à l'entité au-delà de la validation standard du type scalaire (par exemple, des adresses IP et des noms d'hôte valides jusqu'à 255 octets).
• security_result : décrit toute activité malveillante ou anormale détectée.

Exemple d'UDM pour GENERIC_EVENT

L'exemple suivant montre comment mettre en forme un événement GENERIC_EVENT pour l'UDM Google SecOps :

{
  "metadata": {
    "event_timestamp": "2025-03-10T15:00:00.000000Z",
    "event_type": "GENERIC_EVENT",
    "product_event_type": "CustomAuditEvent",
    "description": "Custom audit event recorded on host"
  },
  "principal": {
    "hostname": "workstation-01"
  }
}

Comme le montre cet exemple, l'événement est divisé en plusieurs catégories UDM :

• metadata : informations générales et description de l'événement spécifique au fournisseur.
• principal : informations sur l'appareil associé à l'événement.

GROUP_CREATION, GROUP_DELETION, GROUP_MODIFICATION, GROUP_UNCATEGORIZED

Champs obligatoires :

• metadata : incluez les champs obligatoires (event_timestamp et event_type).
• principal : incluez au moins un identifiant utilisateur dans principal.user (userid, windows_sid, email_addresses ou employee_id).
• target : renseignez target.group avec des informations sur le groupe créé, supprimé ou modifié (et target.user si un utilisateur est ajouté au groupe ou supprimé de celui-ci). Le champ target ne doit pas être vide.

Champs facultatifs :

• principal : inclut les identifiants de l'appareil à l'origine de l'opération de groupe.
• target.group : incluez des identifiants de groupe tels que group_display_name, product_object_id, windows_sid ou email_addresses.
• security_result : décrit toute activité malveillante détectée.

Exemple d'UDM pour GROUP_MODIFICATION

L'exemple suivant montre comment mettre en forme un événement GROUP_MODIFICATION pour l'UDM Google SecOps :

{
  "metadata": {
    "event_timestamp": "2025-03-10T16:10:00.000000Z",
    "event_type": "GROUP_MODIFICATION"
  },
  "principal": {
    "user": {
      "userid": "admin_user"
    }
  },
  "target": {
    "group": {
      "group_display_name": "Domain Admins",
      "windows_sid": "S-1-5-21-3623811015-3361044348-30300820-512"
    },
    "user": {
      "userid": "jdoe"
    }
  }
}

Comme le montre cet exemple, l'événement est divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• principal : informations sur l'utilisateur qui a modifié le groupe.
• target : informations sur le groupe modifié et l'utilisateur concerné.

MUTEX_CREATION, MUTEX_UNCATEGORIZED

Champs obligatoires :

• metadata : incluez les champs obligatoires.
• principal :
  • Au moins un identifiant de machine.
  • Renseignez principal.process avec des informations sur le processus qui crée le mutex. La validation UDM nécessite un objet de processus dans le principal. Vous ne pouvez pas valider l'UDM avec un processus uniquement dans la cible.
• target :
  • Renseignez target.resource.
  • Renseignez target.resource.type avec MUTEX.
  • Renseignez target.resource.name avec le nom du mutex créé.

Champs facultatifs :

• security_result : décrit l'activité malveillante détectée.
• principal.user : à renseigner si des informations utilisateur sont disponibles sur le processus.

Exemple d'UDM pour MUTEX_CREATION

L'exemple suivant illustre comment un événement de type MUTEX_CREATION serait formaté pour l'UDM Google SecOps :

metadata {
  event_timestamp: "2020-01-01T13:27:41+00:00"
  event_type: MUTEX_CREATION
  vendor_name: "Microsoft"
  product_name: "Windows"
}
principal {
  hostname: "test.altostrat.com"
  process {
    pid: "0xc45"
    file {
      full_path: "C:\\Windows\\regedit.exe"
    }
  }
}
target {
  resource {
    type: "MUTEX"
    name: "test-mutex"
  }
}

Comme le montre cet exemple, l'événement a été divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• principal : détails de l'appareil et du processus.
• target : informations sur le mutex.

NETWORK_CONNECTION, NETWORK_FLOW, NETWORK_FTP, NETWORK_SMTP

Champs obligatoires :

• metadata : event_timestamp
• principal : inclut des détails sur la machine qui a initié la connexion réseau (par exemple, la source).
• target : incluez des détails sur la machine cible si elle est différente de la machine principale.
• network : capture des détails sur la connexion réseau (ports, protocole, etc.).

Champs facultatifs :

• principal.process et target.process : incluent les informations sur le processus associées au principal et à la cible de la connexion réseau (si disponibles).
• principal.user et target.user : incluent les informations utilisateur associées au compte principal et à la cible de la connexion réseau (si disponibles).
• network : capture des détails sur la connexion réseau, y compris les ports et le protocole.

Remarque : Pour tous les événements réseau, si un port est spécifié pour le compte principal ou la cible, les champs ip et mac ne doivent inclure qu'une seule valeur chacun (si disponible), c'est-à-dire l'adresse IP et l'adresse MAC associées au port. Sinon, si aucun port n'est spécifié, vous pouvez spécifier n'importe quel nombre d'adresses IP et d'adresses MAC associées à l'appareil au moment de l'événement (aucun ordre particulier n'est requis).

NETWORK_DHCP

Champs obligatoires :

• metadata : informations générales sur l'événement.
• principal : au moins un identifiant de machine (par exemple, principal.ip).
• network : vous devez définir network.application_protocol sur DHCP. Nécessite également que network.dhcp.opcode soit renseigné (par exemple, BOOTREQUEST ou BOOTREPLY).

Remarque : Google SecOps n'évalue que BOOTREQUEST ou BOOTREPLY pour l'attribution d'alias d'éléments.

Exemple d'UDM pour NETWORK_DHCP

L'exemple suivant illustre comment un événement de type NETWORK_DHCP serait formaté pour l'UDM Google SecOps :

{
    "metadata": {
        "event_timestamp": "2023-07-04T18:52:22.142364Z",
        "event_type": "NETWORK_DHCP"
    },
    "principal": {
        "ip": [
            "1.2.3.4"
        ]
    },
    "network": {
        "application_protocol": "DHCP",
        "dhcp": {
            "opcode": "BOOTREPLY"
        }
    }
}

Comme le montre cet exemple, l'événement est divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• principal : informations sur l'appareil demandant ou recevant le bail DHCP.
• network : détails sur la connexion réseau DHCP et le code d'opération.

NETWORK_DNS

Champs obligatoires :

• principal : au moins un identifiant de machine (par exemple, principal.ip).
• network : vous devez spécifier network.application_protocol comme DNS. Nécessite également network.dns.questions.name.
• metadata : informations générales sur l'événement.

Exemple d'UDM pour NETWORK_DNS

L'exemple suivant illustre comment un événement de type NETWORK_DNS serait formaté pour l'UDM Google SecOps :

{
    "metadata": {
        "event_timestamp": "2023-07-04T18:54:15.943301Z",
        "event_type": "NETWORK_DNS"
    },
    "principal": {
        "ip": [
            "1.2.3.4"
        ]
    },
    "network": {
        "application_protocol": "DNS",
        "dns": {
            "questions": {
                "name": "www.acme.com"
            }
        }
    }
}

Comme le montre cet exemple, l'événement est divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• principal : informations sur l'appareil qui effectue la requête DNS.
• network : détails sur la connexion réseau DNS et le nom de domaine interrogé.

NETWORK_HTTP

Le type d'événement NETWORK_HTTP représente une connexion réseau HTTP d'un compte principal à un serveur Web cible.

Champs obligatoires :

• metadata : incluez les champs obligatoires.
• target : représente le serveur Web. Incluez les informations sur l'appareil et un numéro de port facultatif.
  • Si un numéro de port cible est disponible, spécifiez une seule adresse IP en plus du numéro de port associé à cette connexion réseau (bien que plusieurs autres identifiants de machine puissent être fournis pour la cible).
  • Pour target.url, indiquez l'URL consultée.

Champs facultatifs :

• principal : représente le client qui lance la requête Web. Incluez au moins un identifiant de machine (par exemple, un nom d'hôte, une adresse IP, une adresse MAC ou un identifiant d'élément propriétaire) ou un identifiant utilisateur (par exemple, un nom d'utilisateur).
  • Si une connexion réseau spécifique est décrite et qu'un numéro de port client est disponible, spécifiez une seule adresse IP ainsi que le numéro de port associé à cette connexion réseau (bien que d'autres identifiants de machine puissent être fournis pour mieux décrire l'appareil participant).
  • Si aucun port source n'est disponible, vous pouvez spécifier toutes les adresses IP et adresses MAC, les identifiants d'éléments et les valeurs de nom d'hôte décrivant l'appareil principal.
• network et network.http : inclut des détails sur la connexion réseau HTTP. Vous devez renseigner les champs suivants :
  • network.ip_protocol
  • network.application_protocol
  • network.http.method
• about : représente d'autres entités trouvées dans la transaction HTTP (par exemple, un fichier importé ou téléchargé).
• intermediary : représente un serveur proxy (s'il est différent du principal ou de la cible).
• metadata : renseignez les autres champs de métadonnées.
• network : renseignez les autres champs de réseau.
• network.email : si la connexion réseau HTTP provient d'une URL qui figurait dans un e-mail, renseignez network.email avec les détails.
• observer : représente un sniffer passif (le cas échéant).
• security_result : ajoutez un ou plusieurs éléments au champ security_result pour représenter l'activité malveillante détectée.

Exemple d'UDM pour NETWORK_HTTP

L'exemple suivant montre comment un événement antivirus Sophos de type NETWORK_HTTP est converti au format UDM Google SecOps.

Voici l'événement antivirus Sophos d'origine :

date=2013-08-07 time=13:27:41 timezone="GMT" device_name="CC500ia" device_id= C070123456-ABCDE log_id=030906208001 log_type="Anti-Virus" log_component="HTTP" log_subtype="Virus" status="" priority=Critical fw_rule_id=0 user_name="john.smith" iap=7 av_policy_name="" virus="TR/ElderadoB.A.78" url="altostrat.fr/img/logo.gif" domainname="altostrat.fr" src_ip=10.10.2.10 src_port=60671 src_country_code= dst_ip=203.0.113.31 dst_port=80 dst_country_code=FRA

Voici comment formater les mêmes informations dans Proto3 à l'aide de la syntaxe UDM de Google SecOps :

metadata {
  event_timestamp: "2013-08-07T13:27:41+00:00"
  event_type: NETWORK_HTTP
  product_name: "Sophos Antivirus"
  product_log_id: "030906208001"
}

principal {
  hostname: "CC500ia"
  asset_id: "Sophos.AV:C070123456-ABCDE"
  ip: "10.10.2.10"
  port: 60671
  user {  userid: "john.smith" }
}

target {
  hostname: "altostrat.fr"
  ip: "203.0.113.31"
  port: 80
  url: "altostrat.fr/img/logo.gif"
}

network {
  ip_protocol: TCP
 }

security_result {
  about {
    url: "altostrat.fr/img/logo.gif"
    category: SOFTWARE_MALICIOUS
    category_details: "Virus"
    threat_name: "TR/ElderadoB.A.78"
    severity: HIGH                   # Google Security Operations-normalized severity
    severity_details: "Critical"    # Vendor-specific severity string
  }
}

additional { "dst_country_code" : "FRA", "iap" : "7" "fw_rule_id" : "0" }

Comme le montre cet exemple, l'événement a été divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• principal : appareil de sécurité qui a détecté l'événement.
• target : appareil cible qui a reçu le logiciel malveillant.
• network : informations réseau sur l'hôte malveillant.
• security_result : détails de sécurité sur le logiciel malveillant.
• additional : informations sur le fournisseur en dehors du champ d'application de l'UDM.

PROCESS_INJECTION, PROCESS_LAUNCH, PROCESS_OPEN, PROCESS_TERMINATION, PROCESS_UNCATEGORIZED

Champs obligatoires :

• metadata : incluez les champs obligatoires.
• principal :
  • Au moins un identifiant de machine.
  • Pour les événements d'injection et d'arrêt de processus, s'ils sont disponibles, principal.process doit inclure des informations sur le processus qui lance l'action (par exemple, pour un événement de lancement de processus, principal.process doit inclure des détails sur le processus parent, s'ils sont disponibles).
• target :
  • target.process : inclut des informations sur le processus injecté, ouvert, lancé ou arrêté.
  • Si le processus cible est distant, la cible doit inclure au moins un identifiant de machine pour la machine cible (par exemple, une adresse IP, une adresse MAC, un nom d'hôte ou un identifiant d'élément tiers).

Champs facultatifs :

• security_result : décrit l'activité malveillante détectée.
• principal.user et target.user : renseignez le processus d'initialisation (principal) et le processus cible si les informations utilisateur sont disponibles.

Exemple d'UDM pour PROCESS_LAUNCH

L'exemple suivant montre comment formater un événement PROCESS_LAUNCH à l'aide de la syntaxe UDM de Google SecOps :

metadata {
  event_timestamp: "2020-01-01T13:27:41+00:00"
  event_type: PROCESS_LAUNCH
  vendor_name: "Microsoft"
  product_name: "Windows"
}
principal {
  hostname: "altostrat.com"
}
target {
  process {
    pid: "0xc45"
    file {
      full_path: "C:\\Windows\\regedit.exe"
    }
  }
}

Comme le montre cet exemple, l'événement a été divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• principal : détails de l'appareil.
• target : détails du processus.

PROCESS_MODULE_LOAD

Champs obligatoires :

• metadata : incluez les champs obligatoires.
• principal :
  • Incluez au moins un identifiant de machine (dans principal ou target).
  • principal.process : renseignez les informations sur le processus qui charge le module.
• target :
  • target.process : renseignez ce champ avec des informations sur le processus du module chargé, y compris au moins l'un des éléments suivants : target.process.file (par exemple, la DLL ou l'objet partagé) ou target.process.product_specific_process_id.

Champs facultatifs :

• security_result : décrit l'activité malveillante détectée.
• principal.user : à renseigner si des informations utilisateur sont disponibles sur le processus.

Exemple d'UDM pour PROCESS_MODULE_LOAD

L'exemple suivant montre comment formater un événement PROCESS_MODULE_LOAD à l'aide de la syntaxe UDM de Google SecOps :

{
    "metadata": {
        "event_timestamp": "2023-07-03T20:40:29.854097Z",
        "event_type": "PROCESS_MODULE_LOAD"
    },
    "principal": {
        "hostname": "pinguino-01",
        "process": {
            "file": {
                "full_path": "foo.bar"
            }
        }
    },
    "target": {
        "process": {
            "file": {
                "full_path": "foo.bar"
            }
        }
    }
}

Comme le montre cet exemple, l'événement a été divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• principal : détails sur l'appareil et le processus de chargement du module.
• target : détails du processus et du module.

PROCESS_PRIVILEGE_ESCALATION

Champs obligatoires :

• metadata : incluez les champs obligatoires.
• principal :
  • Incluez au moins un identifiant de machine (dans principal ou target).
  • principal.process : renseignez ce champ avec des informations sur le processus à l'origine de l'élévation des privilèges.
  • principal.user : renseignez les informations sur l'utilisateur qui lance l'élévation des privilèges, y compris au moins un identifiant utilisateur.
• target : renseignez les informations sur la cible de l'élévation des privilèges (par exemple, target.process pour le processus avec des privilèges élevés). Le champ target ne doit pas être vide.

Champs facultatifs :

• security_result : décrit l'activité malveillante détectée.

Exemple d'UDM pour PROCESS_PRIVILEGE_ESCALATION

L'exemple suivant illustre comment un événement de type PROCESS_PRIVILEGE_ESCALATION serait formaté pour l'UDM Google SecOps :

{
    "metadata": {
        "event_timestamp": "2023-07-04T19:04:12.573338Z",
        "event_type": "PROCESS_PRIVILEGE_ESCALATION"
    },
    "principal": {
        "user": {
            "userid": "pinguino"
        },
        "hostname": "pinguino-01",
        "process": {
            "file": {
                "full_path": "foo.bar"
            }
        }
    },
    "target": {
        "process": {
            "file": {
                "full_path": "foo.bar"
            }
        }
    }
}

Comme le montre cet exemple, l'événement a été divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• principal : détails sur l'appareil, l'utilisateur et le processus à l'origine de l'escalade.
• target : détails sur le processus faisant l'objet d'une élévation de privilèges.

REGISTRY_CREATION, REGISTRY_MODIFICATION, REGISTRY_DELETION, REGISTRY_UNCATEGORIZED

Champs obligatoires :

• metadata : incluez les champs obligatoires.
• principal :
  • Au moins un identifiant de machine.
  • Si un processus en mode utilisateur effectue la modification du registre, principal.process doit inclure des informations sur le processus modifiant le registre.
  • Si un processus de noyau effectue la modification du registre, le compte principal ne doit pas inclure d'informations sur le processus.
• target :
  • target.registry : si le registre cible est distant, la cible doit inclure au moins un identifiant pour la machine cible (par exemple, une adresse IP, une adresse MAC, un nom d'hôte ou un identifiant d'élément tiers).
  • target.registry.registry_key : tous les événements de registre doivent inclure la clé de registre concernée.

Champs facultatifs :

• security_result : décrit l'activité malveillante détectée. Par exemple, une clé de registre incorrecte.
• principal.user : à renseigner si des informations utilisateur sont disponibles sur le processus.

Exemple d'UDM pour REGISTRY_MODIFICATION

L'exemple suivant montre comment formater un événement REGISTRY_MODIFICATION dans Proto3 à l'aide de la syntaxe UDM de Google SecOps :

metadata {
  event_timestamp: "2020-01-01T13:27:41+00:00"
  event_type: REGISTRY_MODIFICATION
  vendor_name: "Microsoft"
  product_name: "Windows"
}
principal {
  hostname: "test-win"
  user {
    userid: "test"
    windows_sid: "ABCDEFGH-123456789-1111111-1000"
  }
  process {
    pid: "0xc45"
    file {
      full_path: "C:\\Windows\\regedit.exe"
    }
  }
}
target {
  registry {
    registry_key: "\\REGISTRY\\USER\\TEST_USER\\Control Panel\\PowerCfg\\PowerPolicy"
    registry_value_name: "Description"
    registry_value_data: "For extending battery life."
  }
}

Comme le montre cet exemple, l'événement a été divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• principal : détails sur l'appareil, l'utilisateur et le processus.
• target : entrée de registre concernée par la modification.

RESSOURCE

Types d'événements :

• RESOURCE_CREATION
• RESOURCE_DELETION
• RESOURCE_PERMISSIONS_CHANGE
• RESOURCE_READ
• RESOURCE_WRITTEN

Événement UDM minimal :

{
   "metadata": {
       "event_timestamp": "2023-07-04T20:19:53.394745Z",
       "event_type": "RESOURCE_CREATION"
   },
   "principal": {
       "user": {
           "userid": "pinguino"
       }
   },
   "target": {
       "resource": {
           "name": "foo.bar"
       }
   }
}

SCAN_FILE, SCAN_HOST, SCAN_PROCESS, SCAN_VULN_HOST, SCAN_VULN_NETWORK

Pour SCAN_FILE :

{
  "metadata": {
    "event_timestamp": "2023-07-06T06:57:08.443142Z",
    "event_type": "SCAN_FILE"
  },
  "principal": {
    "hostname": "pinguino-01"
  },
  "target": {
    "file": {
      "full_path": "foo.bar"
    }
  }
}

Pour SCAN_PROCESS :

{
  "metadata": {
    "event_timestamp": "2023-07-06T06:59:17.690425Z",
    "event_type": "SCAN_PROCESS"
  },
  "principal": {
    "hostname": "pinguino-01"
  },
  "target": {
    "process": {
      "file": {
        "full_path": "foo.bar"
      }
    }
  }
}

Champs obligatoires :

• metadata : event_timestamp et informations générales sur l'événement.
• observer : capture des informations sur le scanner lui-même. Si le scanner est distant, les détails de la machine doivent être capturés par le champ "observer". Pour un scanner local, laissez ce champ vide.
• target : capture des informations sur la machine qui contient l'objet analysé. Si un fichier est en cours d'analyse, target.file doit capturer des informations sur le fichier analysé. Si un processus est en cours d'analyse, target.process doit capturer des informations sur le processus analysé.
• extensions : pour SCAN_VULN_HOST et SCAN_VULN_NETWORK, définissez la faille à l'aide du champ extensions.vuln.

Champs facultatifs :

• principal : représente l'appareil qui initie la connexion et inclut au moins un identifiant de machine (par exemple, un nom d'hôte, une adresse IP, une adresse MAC, un identifiant d'élément propriétaire) ou un identifiant utilisateur.
• target : les détails de l'utilisateur concernant l'objet cible (par exemple, le créateur du fichier ou le propriétaire du processus) doivent être capturés dans target.user.
• security_result : décrit l'activité malveillante détectée.

Exemple d'UDM pour SCAN_HOST

L'exemple suivant illustre comment un événement de type SCAN_HOST serait formaté pour l'UDM Google SecOps :

metadata: {
  event_timestamp: {
    seconds: 1571386978
  }
  event_type: SCAN_HOST
  vendor_name: "vendor"
  product_name: "product"
  product_version: "1.0"
}
target: {
  hostname: "testHost"
  asset_id: "asset"
  ip: "192.168.200.200"
}
observer: {
  hostname: "testObserver"
  ip: "192.168.100.100"
}
security_result: {
  severity: LOW
  confidence: HIGH_CONFIDENCE
}

Comme le montre cet exemple, l'événement a été divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• target : appareil qui a reçu le logiciel malveillant.
• observer : appareil qui observe et signale l'événement en question.
• security_result : détails de sécurité sur le logiciel malveillant.

Exemple d'UDM pour SCAN_VULN_HOST

L'exemple suivant illustre comment un événement de type SCAN_VULN_HOST serait formaté pour l'UDM Google SecOps :

metadata: {
  event_timestamp: "2025-05-09T12:59:52.45298Z",
  event_type: 18005,
  product_name: "TestProduct",
  vendor_name: "TestVendor"
  },
principal {
  asset_id: "TEST:Mwl8ABcd",
  ip: "127.0.0.3",
  hostname: "TEST-Localhost",
  mac: ["02:00:00:00:00:01"]
  },
extensions: {
  vulns: {
    vulnerabilities: [
      {
      cve_id: "CVE-6l9VxQmz",
      vendor_vulnerability_id: "TEST:7gmCmFWX",
      name: "CVE pA7DzwPU",
      severity: 2,
      vendor: "TestVendor",
      last_found: "2025-05-09T14:59:52.45300Z",
      first_found: "2025-05-09T13:59:52.45300Z"
       }
      ]
    }
  }

Comme le montre cet exemple, l'événement a été divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• principal : appareil ayant reçu le logiciel malveillant.
• extensions : détails de la faille.

SCHEDULED_TASK_CREATION, SCHEDULED_TASK_DELETION, SCHEDULED_TASK_DISABLE, SCHEDULED_TASK_ENABLE, SCHEDULED_TASK_MODIFICATION, SCHEDULED_TASK_UNCATEGORIZED

Champs obligatoires :

• principal : pour tous les événements SCHEDULED_TASK, le principal doit inclure un identifiant de machine et un identifiant utilisateur.
• target : incluez un target.resource valide avec target.resource.resource_type défini sur TASK.

Champs facultatifs :

• security_result : décrit l'activité malveillante détectée.

Exemple d'UDM pour SCHEDULED_TASK_CREATION

L'exemple suivant illustre comment un événement de type SCHEDULED_TASK_CREATION peut être formaté pour l'UDM Google SecOps :

metadata: {
  event_timestamp: {
    seconds: 1577577998
  }
  event_type: SCHEDULED_TASK_CREATION
  vendor_name: "Microsoft"
  product_name: "Windows"
}
principal: {
  hostname: "fake-host.altostrat.com"
  user: {
    userid: "TestUser"
    windows_sid: "AB123CDE"
  }
  process {
    pid: "1234"
  }
}
target: {
  resource: {
    resource_type: TASK
    name: "\\Adobe Acrobat Update Task"
  }
}
intermediary: {
  hostname: "fake-intermediary.altostrat.com"
}
security_result: {
  rule_name: "EventID: 6789"
  summary: "A scheduled task was created."
  severity: INFORMATIONAL
}

Comme le montre cet exemple, l'événement a été divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• principal : appareil qui a planifié la tâche suspecte.
• target : logiciel ciblé par la tâche suspecte.
• intermediary : intermédiaire impliqué dans la tâche suspecte.
• security_result : détails de sécurité sur la tâche suspecte.

SETTING_UNCATEGORIZED, SETTING_CREATION, SETTING_MODIFICATION, SETTING_DELETION

Champs obligatoires :

• principal : doit être présent, non vide et inclure un identifiant de machine.

  Remarque : Le paramètre resource.type est obsolète. Utilisez resource.resource_type.

• target : doit être présent, non vide et inclure une ressource avec target.resource.resource_type spécifié comme SETTING.

Exemple d'UDM pour le type d'événement SETTING_MODIFICATION

L'exemple suivant illustre comment un événement de type SETTING_MODIFICATION serait formaté pour l'UDM Google SecOps :

{
    "metadata": {
        "event_timestamp": "2023-07-05T14:15:27.070909Z",
        "event_type": "SETTING_MODIFICATION"
    },
    "principal": {
        "hostname": "foo.bar"
    },
    "target": {
        "resource": {
            "resource_type": "SETTING",
            "name": "foo.bar"
        }
    }
}

Comme le montre cet exemple, l'événement a été divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• principal : informations sur l'appareil sur lequel la modification du paramètre a eu lieu.
• target : détails sur la ressource de paramètre.

SERVICE_UNSPECIFIED, SERVICE_CREATION, SERVICE_DELETION, SERVICE_MODIFICATION, SERVICE_START, SERVICE_STOP

Champs obligatoires :

• metadata : incluez les champs obligatoires (event_timestamp et event_type).
• principal : incluez au moins un identifiant de machine (principal.hostname, principal.ip, principal.mac ou principal.asset_id).
• target : spécifiez au moins target.process ou target.application.

Champs facultatifs :

• target.user : à renseigner si des informations utilisateur sont disponibles pour le compte de service ou l'utilisateur cible.
• target.resource : renseignez les détails de la ressource de service (par exemple, resource_type: SERVICE).

Exemple d'UDM pour SERVICE_UNSPECIFIED

L'exemple suivant illustre comment un événement de type SERVICE_UNSPECIFIED serait formaté pour l'UDM Google SecOps :

metadata: {
 event_timestamp: {
   seconds: 1595656745
   nanos: 832000000
    }
 event_type: SERVICE_UNSPECIFIED
   vendor_name: "Preempt"
   product_name: "PREEMPT_AUTH"
   product_event_type: "SERVICE_ACCESS"
   description: "Remote Procedures (RPC)"
   }
 principal: {
   hostname: "XXX-YYY-ZZZ"
   ip: "10.10.10.10"
   }
 target: {
   hostname: "TestHost"
   user: {
      userid: "ORG\\User"
      user_display_name: "user name"
   }
 application: "application.name"
   resource: {
      resource_type: SERVICE
      name: "RPC"
   }
 }

Comme le montre cet exemple, l'événement a été divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• principal : informations sur l'appareil et la position.
• target : nom d'hôte et identifiant utilisateur.
• application : nom de l'application et type de ressource.

STATUS_HEARTBEAT, STATUS_STARTUP, STATUS_SHUTDOWN, STATUS_UNCATEGORIZED, STATUS_UPDATE

Champs obligatoires :

• metadata : incluez les champs obligatoires.
• principal : au moins un identifiant de machine (adresse IP ou adresse MAC, nom d'hôte ou identifiant d'élément).

Exemple d'UDM pour STATUS_HEARTBEAT

L'exemple suivant illustre comment un événement de type STATUS_HEARTBEAT serait formaté pour l'UDM Google SecOps :

metadata: {
  event_timestamp: {
    seconds: 1588180305
  }
  event_type: STATUS_HEARTBEAT
  vendor_name: "DMP"
  product_name: "ENTRE"
}
principal: {
  hostname: "testHost"
  location: {
    name: "Building 1"
  }
}
intermediary: {
  ip: "8.8.8.8"
}
security_result: {
  summary: "Event - Locked"
  description: "description"
  severity: LOW
  severity_details: "INFO"
}

Comme le montre cet exemple, l'événement a été divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• principal : informations sur l'appareil et la position.
• intermédiaire : adresse IP de l'appareil.
• security_result : détails du résultat de sécurité.

SYSTEM_AUDIT_LOG_UNCATEGORIZED, SYSTEM_AUDIT_LOG_WIPE

Champs obligatoires :

• principal : incluez un identifiant utilisateur pour l'utilisateur qui a effectué l'opération sur le journal et un identifiant de machine pour la machine sur laquelle le journal est ou était stocké (en cas d'effacement).

Exemple d'UDM pour SYSTEM_AUDIT_LOG_WIPE

L'exemple suivant illustre comment un événement de type SYSTEM_AUDIT_LOG_WIPE serait formaté pour l'UDM Google SecOps :

metadata {
  event_timestamp: "2020-01-01T13:27:41+00:00"
  event_type: SYSTEM_AUDIT_LOG_WIPE
  vendor_name: "Microsoft"
  product_name: "Windows"
}
principal {
  hostname: "altostrat.com"
  user {
    userid: "test"
    windows_sid: "ABCDEFGH-123456789-1111111-1000"
  }
}

Comme le montre cet exemple, l'événement a été divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• principal : informations sur l'appareil et l'utilisateur.

USER_BADGE_IN

Champs obligatoires :

• metadata : incluez les champs obligatoires.
• target : doit inclure au moins un identifiant de machine (par exemple, target.hostname).
• extensions : le mécanisme d'authentification doit être fourni dans extensions.auth.type.

Exemple d'UDM pour USER_BADGE_IN

L'exemple suivant montre comment un événement de type USER_BADGE_IN serait formaté pour l'UDM Google SecOps :

{
    "metadata": {
        "event_timestamp": "2023-07-05T20:31:18.303584Z",
        "event_type": "USER_BADGE_IN"
    },
    "target": {
        "hostname": "jamon-01"
    },
    "extensions": {
        "auth": {
            "type": "MACHINE"
        }
    }
}

Comme le montre cet exemple, l'événement est divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• target : informations sur l'appareil ou l'emplacement où le badge a été utilisé.
• extensions : détails concernant le mécanisme d'authentification utilisé.

USER_CHANGE_PASSWORD, USER_CHANGE_PERMISSIONS

Champs obligatoires :

• metadata : incluez les champs obligatoires.
• target : ne doit pas être vide. Renseignez target avec des informations sur le compte utilisateur modifié (target.user) ou sur la machine, l'application ou la ressource cible où la modification a eu lieu.
• target.user ou principal.user : renseignez au moins l'un des champs target.user (le compte utilisateur qui a été modifié) ou principal.user (l'utilisateur qui a initié la modification) avec un identifiant utilisateur (userid, windows_sid, email_addresses ou employee_id).

Champs facultatifs :

• principal : si vous fournissez l'identifiant utilisateur dans target.user, principal.user est facultatif. Si le compte utilisateur est modifié à partir d'un emplacement distant, renseignez principal avec des informations sur la machine à l'origine de la modification.
• intermediary : pour les connexions SSO, intermediary doit inclure au moins un identifiant de machine pour le serveur SSO, si disponible.

USER_COMMUNICATION

Champs obligatoires :

• principal : renseignez le champ principal.user avec les détails associés à la communication initiée par l'utilisateur (expéditeur), comme un message de chat dans Google Chat ou Slack, une visioconférence ou une conférence vocale dans Zoom ou Google Meet, ou une connexion VoIP.

Champs facultatifs :

• target : (recommandé) renseignez le champ target.user avec des informations sur l'utilisateur cible (destinataire) de la ressource de communication cloud. Renseignez le champ target.application avec des informations sur l'application de communication cloud cible.

USER_CREATION, USER_DELETION

Champs obligatoires :

• metadata : incluez event_timestamp et event_type.
• principal : incluez au moins un identifiant utilisateur valide dans principal.user (userid, windows_sid, email_addresses ou employee_id, jusqu'à 256 caractères) pour le compte qui a initié la création ou la suppression. Si target.application n'est pas défini, principal doit également inclure au moins un identifiant de machine (hostname, ip, mac ou asset_id).
• target : incluez au moins un identifiant utilisateur valide dans target.user (jusqu'à 256 caractères) pour le compte utilisateur en cours de création ou de suppression. Si principal n'inclut pas d'identifiant de machine, renseignez target.application.

Champs facultatifs :

• principal.process : détails du processus pour la machine sur laquelle la demande de création ou de suppression d'utilisateur a été initiée.
• target : informations sur la machine cible (si elle est différente de la machine principale).

USER_LOGIN, USER_LOGOUT

Champs obligatoires :

• metadata : incluez les champs obligatoires.
• principal : pour l'activité de l'utilisateur distant (par exemple, connexion à distance), renseignez le champ "principal" avec des informations sur la machine à l'origine de l'activité de l'utilisateur. Pour l'activité des utilisateurs locaux (par exemple, la connexion locale), ne définissez pas de compte principal.
• target : renseignez target.user avec des informations sur l'utilisateur qui s'est connecté ou déconnecté. Si le compte principal n'est pas défini (par exemple, connexion locale), la cible doit également inclure au moins un identifiant de machine identifiant la machine cible. Pour l'activité des utilisateurs de machine à machine (par exemple, connexion à distance, authentification unique, service cloud, VPN), la cible doit inclure des informations sur l'application cible, la machine cible ou le serveur VPN cible.
• intermediary : pour les connexions SSO, l'intermédiaire doit inclure au moins un identifiant de machine pour le serveur SSO, si disponible.
• network et network.http : si la connexion s'effectue via HTTP, vous devez placer toutes les informations disponibles dans network.ip_protocol, network.application_protocol et network.http.
• Extension d'authentification : doit identifier le type de système d'authentification auquel l'événement est lié (par exemple, machine, SSO ou VPN) et le mécanisme utilisé (nom d'utilisateur et mot de passe, OTP, etc.).
• security_result : ajoutez un champ security_result pour représenter l'état de connexion en cas d'échec. Spécifiez security_result.category avec la valeur AUTH_VIOLATION si l'authentification échoue.

Exemple d'UDM pour USER_LOGIN

L'exemple suivant illustre comment un événement de type USER_LOGIN serait formaté pour l'UDM Google SecOps :

{
    "metadata": {
        "event_timestamp": "2023-07-05T20:48:50.657334Z",
        "event_type": "USER_LOGIN"
    },
    "target": {
        "user": {
            "userid": "jamon"
        }
    },
    "extensions": {
        "auth": {
            "type": "MACHINE"
        }
    }
}

Comme le montre cet exemple, l'événement est divisé en plusieurs catégories UDM :

• metadata : informations générales sur l'événement.
• target : informations sur l'utilisateur qui se connecte.
• extensions : détails concernant le mécanisme d'authentification utilisé.

USER_RESOURCE_ACCESS

Champs obligatoires :

• principal : renseignez le champ principal.user avec des informations sur les tentatives d'accès à une ressource cloud (par exemple, une demande Salesforce, un agenda Office365, un document Google Docs ou un ticket ServiceNow).
• target : renseignez le champ target.resource avec des informations sur la ressource cloud cible.

Champs facultatifs :

• target.application : (recommandé) renseignez le champ target.application avec des informations sur l'application cloud cible.

USER_RESOURCE_CREATION, USER_RESOURCE_DELETION

Champs obligatoires :

• principal : renseignez le champ principal.user avec les détails associés à l'utilisateur créé dans une ressource cloud (par exemple, une demande Salesforce, un agenda Office 365, un document Google Docs ou un ticket ServiceNow).
• target : renseignez le champ target.resource avec des informations sur la ressource cloud cible.

Champs facultatifs :

• target.application : (recommandé) renseignez le champ target.application avec des informations sur l'application cloud cible.

USER_RESOURCE_UPDATE_CONTENT

Champs obligatoires :

• principal : renseignez le champ principal.user avec les détails associés à l'utilisateur dont le contenu a été mis à jour dans une ressource cloud (par exemple, une demande Salesforce, un agenda Office365, un document Google Docs ou un ticket ServiceNow).
• target : renseignez le champ target.resource avec des informations sur la ressource cloud cible.

Champs facultatifs :

• target.application : (recommandé) renseignez le champ target.application avec des informations sur l'application cloud cible.

USER_RESOURCE_UPDATE_PERMISSIONS

Champs obligatoires :

• principal : renseignez le champ principal.user avec les détails associés à l'utilisateur dont les autorisations ont été mises à jour dans une ressource cloud (par exemple, une demande Salesforce, un agenda Office 365, un document Google Docs ou un ticket ServiceNow).
• target : renseignez le champ target.resource avec des informations sur la ressource cloud cible.

Champs facultatifs :

• target.application : (recommandé) renseignez le champ target.application avec des informations sur l'application cloud cible.

USER_UNCATEGORIZED

Champs obligatoires :

• metadata : incluez event_timestamp et event_type.
• principal ou target :
  • Si target n'est pas renseigné, principal doit inclure au moins un identifiant utilisateur valide dans principal.user (userid, windows_sid, email_addresses ou employee_id, jusqu'à 256 caractères) ou au moins un identifiant d'ordinateur (hostname, ip, mac ou asset_id).
  • Si target est renseigné, vous devez renseigner au moins l'un des éléments suivants : un identifiant utilisateur dans target.user, un identifiant de machine dans target ou un identifiant utilisateur valide dans principal.user.

Champs facultatifs :

• principal.process : détails du processus associé à l'activité de l'utilisateur.
• security_result : décrit toute activité malveillante ou anormale détectée.

Remarque : USER_STATS est obsolète.