Présentation du modèle de données unifié

Ce document présente le modèle de données unifié (UDM). Pour en savoir plus sur les champs UDM, y compris une description de chacun d'eux, consultez la liste des champs UDM. Pour en savoir plus sur le mappage de l'analyseur, consultez la section Champs UDM importants pour le mappage de l'analyseur.

L'UDM est une structure de données standard Google Security Operations qui stocke des informations sur les données reçues de sources. On l'appelle également schéma. Google Security Operations stocke les données d'origine qu'il reçoit sous deux formats : le journal brut d'origine et un enregistrement UDM structuré. L'enregistrement UDM est une représentation structurée du journal d'origine.

Si un analyseur existe pour le type de journal spécifié, le journal brut est utilisé pour créer un enregistrement UDM. Les clients peuvent également convertir les journaux bruts au format UDM structuré avant d'envoyer les données à Google Security Operations à l'aide de l'API Ingestion.

Voici quelques-uns des avantages de la gestion unifiée des données:

• Stocke le même type d'enregistrement de différents fournisseurs à l'aide de la même sémantique.
• Identification plus facile des relations entre les utilisateurs, les hôtes et les adresses IP, car les données sont normalisées dans le schéma UDM standard.
• Écriture de règles plus facile, car elles peuvent être indépendantes de la plate-forme.
• Prise en charge plus facile des types de journaux des nouveaux appareils.

Bien que vous puissiez rechercher des événements à l'aide d'une recherche de journaux brute, une recherche UDM fonctionne plus rapidement et avec plus de précision en raison de sa spécificité.

Google Security Operations utilise le schéma UDM pour tous les événements qu'il collecte. La UDM comprend des milliers de champs utilisés pour décrire et classer les événements. Par exemple, UDM peut gérer les événements de processus de point de terminaison aussi facilement que les événements de communication réseau.

Structure UDM

Les événements UDM sont composés de plusieurs sections. La première section trouvée dans chaque événement UDM est la section des métadonnées. Il fournit une description de base de l'événement, y compris l'horodatage de l'événement et l'horodatage de son ingestion dans Google Security Operations. Il inclut également les informations, la version et la description du produit. L'analyseur d'ingestion classe chaque événement en fonction d'un type d'événement prédéfini, indépendamment du journal du produit spécifique. Les champs de métadonnées seuls vous permettent de commencer rapidement à rechercher des données.

En plus de la section "Métadonnées", d'autres sections décrivent d'autres aspects de l'événement. Si une section n'est pas nécessaire, elle n'est pas incluse, ce qui permet d'économiser de la mémoire.

• principal: entité à l'origine de l'activité dans l'événement. Les sections qui font référence à la source (src) et à la destination (target) sont également incluses.
• intermediary: systèmes que les événements traversent, comme un serveur proxy ou un relais SMTP.
• observer: systèmes tels que les outils d'analyse de paquets qui surveillent passivement le trafic.

Exemples de recherches UDM

Cette section fournit des exemples de recherches UDM qui illustrent certaines des syntaxes, fonctionnalités et capacités de base de la recherche UDM.

Exemple: recherchez les connexions Microsoft Windows 4624 réussies.

La recherche suivante liste les événements de connexion réussis Microsoft Windows 4624, ainsi que la date et l'heure de leur génération, en se basant sur seulement deux champs UDM:

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624"

Exemple: rechercher toutes les connexions réussies

La recherche suivante liste tous les événements de connexion réussis, quel que soit le fournisseur ou l'application:

metadata.event_type = "USER_LOGIN" AND security_result.action = "ALLOW" AND target.user.userid != "SYSTEM" AND target.user.userid != /.*$/

Exemple: rechercher les connexions réussies des utilisateurs

L'exemple suivant montre comment rechercher userid "fkolzig" et déterminer quand l'utilisateur associé à cet ID utilisateur s'est connecté. Vous pouvez effectuer cette recherche à l'aide de la section "Cible". La section "Cible" comprend des sous-sections et des champs décrivant la cible. Par exemple, dans ce cas, la cible est un utilisateur et comporte un certain nombre d'attributs associés, mais elle peut également être un fichier, un paramètre de Registre ou un composant. Cet exemple recherche "fkolzig" à l'aide du champ target.user.userid.

metadata.event_type = "USER_LOGIN" AND metadata.product_event_type = "4624" AND target.user.userid = "fkolzig"

Exemple: rechercher dans vos données réseau

L'exemple suivant recherche dans les données réseau des événements RDP avec un target.port de 3389 et un principal.ip de 35.235.240.5. Il inclut également un champ UDM de la section réseau, la direction des données (network.direction).

metadata.product_event_type = "3" AND target.port = 3389 AND network.direction = "OUTBOUND" and principal.ip = "35.235.240.5"

Exemple: rechercher un processus spécifique

Pour examiner les processus créés sur vos serveurs, recherchez des instances de la commande net.exe et recherchez ce fichier spécifique dans son chemin d'accès prévu. Le champ que vous recherchez est target.process.file.full_path. Pour cette recherche, vous devez inclure la commande spécifique émise dans le champ target.process.command_line. Vous pouvez également ajouter un champ dans la section "À propos", qui correspond à la description du code d'événement Microsoft Sysmon 1 (ProcessCreate).

Voici la recherche UDM:

metadata.product_event_type = "1" AND target.process.file.full_path = "C:\Windows\System32\net.exe"

Vous pouvez également ajouter les champs de recherche UDM suivants:

• principal.user.userid: identifie l'utilisateur qui émet la commande.
• principal.process.file.md5: identifiez le hachage MD5.
• principal.process.command_line: ligne de commande.

Exemple: rechercher les connexions réussies d'un utilisateur associées à un service spécifique

L'exemple suivant recherche les connexions des utilisateurs (metadata.event_type est USER_LOGIN) associés au service marketing (target.user.department est marketing) de votre entreprise. Bien que target.user.department ne soit pas directement associé aux événements de connexion des utilisateurs, il est toujours présent dans les données LDAP ingérées sur vos utilisateurs.

metadata.event_type = "USER_LOGIN" AND target.user.department = "Marketing"

Objets logiques: événement et entité

Le schéma UDM décrit tous les attributs disponibles qui stockent des données. Chaque enregistrement UDM indique s'il décrit un événement ou une entité. Les données sont stockées dans différents champs selon que l'enregistrement décrit un événement ou une entité, ainsi que la valeur définie dans le champ metadata.event_type ou metadata.entity_type.

• Événement UDM: stocke les données d'une action qui s'est produite dans l'environnement. Le journal des événements d'origine décrit l'action telle qu'elle a été enregistrée par l'appareil, comme le pare-feu et le proxy Web. Il s'agit du modèle de données d'événement UDM.
• Entité UDM: représentation contextuelle d'éléments tels que les composants, les utilisateurs et les ressources de votre environnement. Il est obtenu à partir d'une source de données véridique. Il s'agit du modèle de données d'entité UDM.

Voici deux représentations visuelles générales du modèle de données d'événement et du modèle de données d'entité.

Figure: Modèle de données d'événement

Figure: Modèle de données des entités

Structure d'un événement UDM

L'événement UDM contient plusieurs sections, chacune stockant un sous-ensemble des données d'un seul enregistrement. Les sections sont les suivantes:

• métadonnées
• compte principal
• cible
• src
• observateur
• intermédiaire
• about
• network
• security_result

• extensions

  

  Figure: Modèle de données d'événement

La section metadata stocke le code temporel, définit le event_type et décrit l'appareil.

Les sections principal, target, src, observer et intermediary stockent des informations sur les objets impliqués dans l'événement. Un objet peut être un appareil, un utilisateur ou un processus. La plupart du temps, seul un sous-ensemble de ces sections est utilisé. Les champs qui stockent des données sont déterminés par le type d'événement et le rôle de chaque objet dans l'événement.

La section Réseau stocke des informations sur l'activité réseau, telles que les e-mails et les communications liées au réseau.

• Données d'e-mail: informations contenues dans les champs to, from, cc, bcc et autres champs d'e-mail.
• Données HTTP, telles que method, referral_url et useragent

La section security_result stocke une action ou une classification enregistrée par un produit de sécurité, tel qu'un produit antivirus.

Les sections À propos et Extensions stockent des informations d'événement spécifiques au fournisseur qui ne sont pas capturées par les autres sections. La section extensions est un ensemble de paires clé-valeur au format libre.

Chaque événement UDM stocke les valeurs d'un événement de journal brut d'origine. En fonction du type d'événement, certains attributs sont obligatoires, tandis que d'autres sont facultatifs. Les attributs obligatoires et facultatifs sont déterminés par la valeur metadata.event_type. Google Security Operations lit metadata.event_type et effectue une validation de champ spécifique à ce type d'événement après réception des journaux.

Si aucune donnée n'est stockée dans une section de l'enregistrement UDM, par exemple la section "extensions", cette section n'apparaît pas dans l'enregistrement UDM.

Les champs de métadonnées

Cette section décrit les champs obligatoires dans un événement UDM.

Champ event_timestamp

Les événements UDM doivent inclure des données pour le metadata.event_timestamp, qui correspond au code temporel GMT au moment de l'événement. La valeur doit être encodée à l'aide de l'une des normes suivantes: code temporel RFC 3339 ou Proto3.

Les exemples suivants montrent comment spécifier l'horodatage au format RFC 3339, yyyy-mm-ddThh:mm:ss+hh:mm (année, mois, jour, heure, minute, seconde et décalage par rapport à l'heure UTC). Le décalage par rapport à l'UTC est de moins huit heures, ce qui indique l'heure normale du Pacifique.

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

metadata {
  event_timestamp: "2021-02-23T04:00:00.000Z"
}

Vous pouvez également spécifier la valeur au format epoch.

metadata {
event_timestamp: {
  "seconds": 1588180305
 }
}

Champ "event_type"

Le champ le plus important de l'événement UDM est metadata.event_type. Cette valeur identifie le type d'action effectuée et est indépendante du fournisseur, du produit ou de la plate-forme. Par exemple, il peut s'agir de PROCESS_OPEN, FILE_CREATION, USER_CREATION et NETWORK_DNS. Pour obtenir la liste complète, consultez le document Liste des champs UDM.

La valeur metadata.event_type détermine les champs obligatoires et facultatifs supplémentaires à inclure dans l'enregistrement UDM. Pour savoir quels champs inclure pour chaque type d'événement, consultez le guide d'utilisation de l'UDM.

Les attributs principal, cible, src, intermédiaire, observateur et à propos

Les attributs principal, target, src, intermediary et observer décrivent les composants impliqués dans l'événement. Chacune d'elles stocke des informations sur les objets impliqués dans l'activité, telles qu'elles sont enregistrées par le journal brut d'origine. Il peut s'agir de l'appareil ou de l'utilisateur qui a effectué l'activité, ou de l'appareil ou de l'utilisateur qui est la cible de l'activité. Il peut également décrire un dispositif de sécurité qui a observé l'activité, comme un proxy de messagerie ou un routeur réseau.

Voici les attributs les plus couramment utilisés:

• principal: objet ayant effectué l'activité.
• src: objet qui lance l'activité, s'il est différent du principal.
• target: objet sur lequel une action est effectuée.

Pour chaque type d'événement, au moins l'un de ces champs doit contenir des données.

Les champs auxiliaires sont les suivants:

• intermediary: tout objet ayant servi d'intermédiaire lors de l'événement. Il peut s'agir d'objets tels que des serveurs proxy et des serveurs de messagerie.
• observer: tout objet qui n'interagit pas directement avec le trafic en question. Il peut s'agir d'un outil d'analyse des failles ou d'un appareil d'analyse des paquets.
• about: tout autre objet ayant joué un rôle dans l'événement (facultatif).

Attributs principaux

Représente l'entité agissante ou l'appareil à l'origine de l'activité. Le principal doit inclure au moins un détail de machine (nom d'hôte, adresse MAC, adresse IP, identifiants spécifiques au produit tels qu'un GUID de machine CrowdStrike) ou un détail utilisateur (par exemple, le nom d'utilisateur), et peut inclure des détails de processus. Il ne doit pas inclure les champs suivants: adresse e-mail, fichiers, clés de registre ou valeurs.

Si l'événement se produit sur une seule machine, cette machine est décrite uniquement dans l'attribut principal. La machine n'a pas besoin d'être décrite dans les attributs "target" ou "src".

L'extrait JSON suivant montre comment l'attribut principal peut être renseigné.

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

Cet attribut décrit tout ce que l'on sait sur l'appareil et l'utilisateur qui ont été les principaux acteurs de l'événement. Cet exemple inclut l'adresse IP, le numéro de port et le nom d'hôte de l'appareil. Il inclut également un identifiant d'asset spécifique au fournisseur, de Sophos, qui est un identifiant unique généré par le produit de sécurité tiers.

Attributs cibles

Représente un appareil cible référencé par l'événement ou un objet sur l'appareil cible. Par exemple, dans une connexion de pare-feu de l'appareil A à l'appareil B, l'appareil A est capturé en tant que principal et l'appareil B en tant que cible.

Pour une injection de processus par le processus C dans le processus cible D, le processus C est le principal et le processus D est la cible.

Figure: Principal par rapport à la cible

L'exemple suivant montre comment le champ cible peut être renseigné.

target {
   ip: "192.0.2.31"
   port: 80
}

Si d'autres informations sont disponibles dans le journal brut d'origine, telles que le nom d'hôte, des adresses IP supplémentaires, des adresses MAC et des identifiants d'éléments propriétaires, elles doivent également être incluses dans les champs "target" et "principal".

Le principal et la cible peuvent représenter des acteurs sur la même machine. Par exemple, le processus A (principal) exécuté sur la machine X peut agir sur le processus B (cible) également sur la machine X.

Attribut "src"

Représente un objet source sur lequel le participant agit, ainsi que le contexte de l'appareil ou du processus pour l'objet source (la machine sur laquelle l'objet source réside). Par exemple, si l'utilisateur U copie le fichier A sur la machine X vers le fichier B sur la machine Y, le fichier A et la machine X sont tous deux spécifiés dans la partie "src" de l'événement UDM.

Attribut intermédiaire

Représente les détails d'un ou de plusieurs appareils intermédiaires qui traitent l'activité décrite dans l'événement. Cela peut inclure des informations sur les appareils, comme les serveurs proxy et les serveurs de relais SMTP.

Attribut "observer"

Représente un appareil d'observation qui n'est pas un intermédiaire direct, mais qui observe et signale l'événement en question. Il peut s'agir d'un analyseur de paquets ou d'un analyseur de failles basé sur le réseau.

Attribut "about"

Ce magasin stocke des informations sur un objet référencé par l'événement qui n'est pas décrit dans les champs principal, src, target, intermediary ou observer. Par exemple, il peut capturer les éléments suivants:

• Pièces jointes de fichiers par e-mail
• Domaines, URL ou adresses IP intégrés au corps d'un e-mail
• DLL chargées lors d'un événement PROCESS_LAUNCH.

Attribut "security_result"

Cette section contient des informations sur les risques et menaces de sécurité détectés par un système de sécurité, ainsi que sur les mesures prises pour atténuer ces risques et menaces.

Voici les types d'informations qui seront stockés dans l'attribut security_result:

• Un proxy de sécurité des e-mails a détecté une tentative d'hameçonnage (security_result.category = MAIL_PHISHING) et a bloqué (security_result.action = BLOCK) l'e-mail.
• Un pare-feu proxy de sécurité des e-mails a détecté deux pièces jointes infectées (security_result.category = SOFTWARE_MALICIOUS) et a mis en quarantaine et désinfecté (security_result.action = QUARANTINE ou security_result.action = ALLOW_WITH_MODIFICATION) ces pièces jointes, puis a transféré l'e-mail désinfecté.
• Un système SSO autorise une connexion (security_result.category = AUTH_VIOLATION) qui était bloquée (security_result.action = BLOCK).
• Un bac à sable de logiciels malveillants a détecté un logiciel espion (security_result.category = SOFTWARE_MALICIOUS) dans une pièce jointe cinq minutes après que le fichier a été distribué (security_result.action = ALLOW) à l'utilisateur dans sa boîte de réception.

Attribut réseau

Les attributs réseau stockent des données sur les événements liés au réseau et des informations sur les protocoles dans les sous-messages. Cela inclut l'activité, comme les e-mails envoyés et reçus, et les requêtes HTTP.

Attribut extensions

Les champs de cet attribut stockent des métadonnées supplémentaires sur l'événement capturé dans le journal brut d'origine. Il peut contenir des informations sur les failles ou des informations supplémentaires liées à l'authentification.

Structure d'une entité UDM

Un enregistrement d'entité UDM stocke des informations sur n'importe quelle entité d'une organisation. Si metadata.entity_type est "USER", l'enregistrement stocke des informations sur l'utilisateur sous l'attribut entity.user. Si metadata.entity_type est ASSET, l'enregistrement stocke des informations sur un composant, comme une station de travail, un ordinateur portable, un téléphone et une machine virtuelle.

Figure: Modèle de données d'événement

Les champs de métadonnées

Cette section contient les champs obligatoires d'une entité UDM, par exemple:

• collection_timestamp: date et heure de collecte de l'enregistrement.
• entity_type: type d'entité, par exemple "composant", "utilisateur" et "ressource".

Attribut de l'entité

Les champs de l'attribut d'entité stockent des informations sur l'entité spécifique, telles que le nom d'hôte et l'adresse IP s'il s'agit d'un composant, ou windows_sid et l'adresse e-mail s'il s'agit d'un utilisateur. Notez que le nom du champ est "entité", mais que le type de champ est un nom. Un nom est une structure de données couramment utilisée qui stocke des informations à la fois dans des entités et des événements.

• Si metadata.entity_type est USER, les données sont stockées sous l'attribut entity.user.
• Si metadata.entity_type est ASSET, les données sont stockées sous l'attribut entity.asset.

Attribut relation

Les champs de l'attribut de relation stockent des informations sur les autres entités auxquelles l'entité principale est associée. Par exemple, si l'entité principale est un utilisateur et que celui-ci a reçu un ordinateur portable. L'ordinateur portable est une entité associée. Les informations sur l'ordinateur portable sont stockées sous la forme d'un enregistrement "entité" avec metadata.entity_type = ASSET. Les informations sur l'utilisateur sont stockées en tant qu'enregistrement "entité" avec metadata.entity_type = USER.

L'enregistrement de l'entité utilisateur capture également la relation entre l'utilisateur et l'ordinateur portable, à l'aide des champs de l'attribut "relation". Le champ relation.relationship stocke la relation de l'utilisateur avec l'ordinateur portable, en particulier le fait que l'utilisateur est propriétaire de l'ordinateur portable. Le champ relation.entity_type stocke la valeur ASSET, car l'ordinateur portable est un appareil.

Les champs de l'attribut relations.entity stockent des informations sur l'ordinateur portable, telles que l'hôte et l'adresse MAC. Notez à nouveau que le nom du champ est "entity" et que le type de champ est un nom. Un nom est une structure de données couramment utilisée. Les champs de l'attribut relation.entité stockent des informations sur l'ordinateur portable.

Le champ relation.direction stocke la directionnalité de la relation entre l'utilisateur et l'ordinateur portable, en particulier si la relation est bidirectionnelle ou unidirectionnelle.