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

Ce document fournit une présentation de l'UDM (Unified Data Model). Pour en savoir plus sur les champs UDM et obtenir 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 des sources. Également appelé schéma. Google Security Operations stocke les données d'origine qu'il reçoit dans deux formats : le journal brut d'origine et l'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 transformer des journaux bruts au format UDM structuré avant d'envoyer les données à Google Security Operations à l'aide de l'API d'ingestion.

Voici quelques-uns des avantages de l'UDM:

• Stocke le même type d'enregistrement provenant de différents fournisseurs en utilisant la même sémantique.
• Les relations entre les utilisateurs, les hôtes et les adresses IP sont faciles à identifier, car les données sont normalisées dans le schéma UDM standard.
• Elles sont plus faciles à écrire, car elles peuvent être indépendantes de la plate-forme.
• Prise en charge simplifiée des types de journaux à partir de nouveaux appareils.

Remarque :Le moteur de règles Google Security Operations utilise les mêmes noms de champs UDM. Vous pouvez utiliser ces mêmes noms de champ lorsque vous créez des règles.

Bien que vous puissiez rechercher des événements à l'aide d'une recherche dans le journal brut, 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. L'UDM comprend des milliers de champs utilisés pour décrire et catégoriser les événements. Par exemple, l'UDM peut gérer les événements de traitement de point de terminaison aussi facilement que les événements de communication réseau.

Structure de l'UDM

Les événements UDM sont composés de plusieurs sections. La première section de chaque événement UDM est la section des métadonnées. Il fournit une description de base de l'événement, y compris le code temporel où il s'est produit et le moment où il a été ingéré dans Google Security Operations. Il comprend é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. Avec les champs de métadonnées seuls, vous pouvez rapidement commencer à rechercher les données.

Outre la section des métadonnées, d'autres sections décrivent des aspects supplémentaires 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 par lesquels passent les événements, comme un serveur proxy ou un relais SMTP.
• observer: systèmes tels que les renifleurs de paquets qui surveillent de manière passive le trafic.

Exemples de recherches UDM

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

Exemple: Rechercher des connexions Microsoft Windows 4624 réussies

La recherche suivante répertorie les événements de connexion réussies Microsoft Windows 4624, ainsi que la date de génération des événements, en fonction de deux champs UDM uniquement:

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

Exemple: Rechercher toutes les connexions réussies

La recherche suivante répertorie tous les événements de connexion réussis, indépendamment du fournisseur ou de l'application:

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

Exemple: Rechercher des connexions utilisateur réussies

L'exemple suivant montre comment rechercher userid "fkolzig" et déterminer quand l'utilisateur possédant cet ID utilisateur a réussi à se connecter. 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 possède un certain nombre d'attributs associés, mais elle peut également être un fichier, un paramètre de registre ou un élément. 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 les données de votre 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, qui indique le sens 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 les instances de la commande net.exe et recherchez ce fichier spécifique dans le chemin d'accès attendu. Le champ que vous recherchez est target.process.file.full_path. Pour cette recherche, vous incluez la commande spécifique émise dans target.process.command_line.

. Vous pouvez également ajouter un champ dans la section "À propos" qui correspond à la description du code d'événement 1 Microsoft Sysmon (ProcessCreate).

Voici la recherche UDM:

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

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

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

Exemple: rechercher des connexions utilisateur réussies 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 connecté aux événements de connexion des utilisateurs, il est toujours présent dans les données LDAP ingérées à propos de 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 par rapport à une entité et selon 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, par exemple le pare-feu et le proxy Web. Voici le modèle de données d'événements UDM.
• Entité d'UDM: représentation contextuelle d'éléments tels que les éléments, les utilisateurs et les ressources de votre environnement. Elles sont obtenues à partir d'une source de référence. Il s'agit du modèle de données de l'entité UDM.

Voici deux représentations visuelles générales des modèles de données "Event" et "Entity".

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

Remarque :Le terme Noun décrit le type d'attribut. Les termes principal, cible, src, intermédiaire, observateur et à propos sont les noms des champs où les données sont stockées.

Figure: Modèle de données de l'entité

Remarque :Le terme Noun décrit le type d'attribut. Les termes "élément", "utilisateur" et "ressource" sont les noms des champs dans lesquels les données sont stockées.

Structure d'un événement UDM

L'événement UDM contient plusieurs sections qui stockent chacune un sous-ensemble de données pour un seul enregistrement. Les sections sont les suivantes:

• métadonnées
• compte principal
• cible
• src
• observateur
• intermédiaire
• about
• votre réseau sur site.
• security_result

• extensions

  

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

La section metadata contient le code temporel, définit l'élément 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 network stocke des informations liées à l'activité réseau, telles que les e-mails et les communications réseau.

• Données d'e-mail: informations des champs to, from, cc, bcc et d'autres champs d'adresse e-mail.
• Données HTTP: par exemple 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 antivirus.

Les sections about (À propos) et extensions (Extensions) stockent des informations supplémentaires sur les événements spécifiques aux fournisseurs, qui n'ont pas été capturées dans les autres sections. La section extensions est un ensemble de paires clé/valeur de forme libre.

Chaque événement UDM stocke les valeurs d'un événement de journal brut d'origine. Selon le 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 une fois les journaux reçus.

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

Champs de métadonnées

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

Le champ event_timestamp

Les événements UDM doivent inclure des données pour metadata.event_timestamp, qui correspond à l'horodatage GMT lorsque l'événement s'est produit. La valeur doit être encodée selon l'une des normes suivantes: 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'heure UTC est de moins 8 heures, indiquant PST.

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 en utilisant le format epoch.

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

Le 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. Exemples de valeurs : PROCESS_OPEN, FILE_CREATION, USER_CREATION et NETWORK_DNS. Pour obtenir la liste complète, consultez le document Liste des champs de l'UDM.

La valeur metadata.event_type détermine les champs supplémentaires obligatoires et facultatifs à inclure dans l'enregistrement UDM. Pour en savoir plus sur les 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 éléments impliqués dans l'événement. Chacun 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 appareil de sécurité ayant observé l'activité, tel qu'un proxy de messagerie ou un routeur réseau.

Les attributs les plus couramment utilisés sont les suivants:

• principal: objet qui a réalisé l'activité.
• src: objet qui lance l'activité, s'il est différent du compte principal.
• target: objet sur lequel s'applique l'action.

Chaque type d'événement nécessite qu'au moins l'un de ces champs contienne des données.

Les champs auxiliaires sont les suivants:

• intermediary: tout objet ayant servi d'intermédiaire dans 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 de détection de paquets.
• about: tous les autres objets ayant joué un rôle dans l'événement et qui sont facultatifs.

Les attributs principaux

Représente l'entité à l'origine de l'activité ou l'appareil à l'origine de l'activité. Le compte principal doit inclure au moins un détail sur la machine (nom d'hôte, adresse MAC, adresse IP, identifiants spécifiques au produit, comme le GUID de la machine CrowdStrike) ou des informations détaillées sur l'utilisateur (par exemple, son nom d'utilisateur). Il peut également inclure des détails sur le processus. Il ne doit inclure aucun des champs suivants: adresse e-mail, fichiers, clés ou valeurs de registre.

Si l'événement se produit sur une seule machine, celle-ci n'est décrite que dans l'attribut principal. Il n'est pas nécessaire de décrire la machine dans les attributs "target" ou "src".

Remarque :Un appareil de sécurité peut enregistrer un événement, mais il ne sera pas décrit dans l'attribut principal. Elle serait décrite dans l'attribut observateur ou intermédiaire. Si le logiciel de sécurité (Carbon Black, par exemple) s'exécute sur le même appareil à l'origine de l'activité (par exemple, un point de terminaison Windows sur lequel un logiciel malveillant a été détecté), l'appareil Windows est l'appareil Windows principal.

L'extrait de code JSON suivant montre comment renseigner l'attribut principal.

"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 toutes les informations connues sur l'appareil et l'utilisateur qui ont été l'acteur principal 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'élément spécifique au fournisseur, fourni par Sophos, qui est un identifiant unique généré par le produit de sécurité tiers.

Les 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 entre l'appareil A et l'appareil B, l'appareil A est capturé en tant que compte principal et l'appareil B en tant que cible.

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

Figure: Compte principal et cible

L'exemple suivant montre comment renseigner le champ cible.

target {
   ip: "192.0.2.31"
   port: 80
}

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

Le compte principal et la cible peuvent tous deux 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.

L'attribut src

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

L'attribut intermédiaire

Représente les détails de l'activité de traitement d'un ou plusieurs appareils intermédiaires décrite dans l'événement. Il peut s'agir d'informations sur les appareils, tels que les serveurs proxy et les serveurs de relais SMTP.

L'attribut observateur

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 outil de détection de paquets ou d'un outil d'analyse des failles basé sur le réseau.

L'attribut "À propos"

Ce magasin fournit des détails sur un objet référencé par l'événement qui n'est pas décrit dans les champs "principal", "src", "cible", "intermédiaire" ou "observateur". Par exemple, il peut capturer les éléments suivants:

• Des pièces jointes aux e-mails.
• Domaines, URL ou adresses IP intégrées dans le 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 les 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 ces menaces.

Voici les types d'informations qui seraient stockées dans l'attribut security_result:

• Un proxy de sécurité de messagerie 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 de proxy de sécurité des e-mails a détecté deux pièces jointes infectées (security_result.category = SOFTWARE_MALICIOUS) et les a mises en quarantaine et désinfectées (security_result.action = QUARANTINE ou security_result.action = ALLOW_WITH_MODIFICATION), puis a transféré l'e-mail désinfecté.
• Un système SSO autorise une connexion (security_result.category = AUTH_VIOLATION) qui a été bloquée (security_result.action = BLOCK).
• Un bac à sable a détecté un logiciel espion (security_result.category = SOFTWARE_MALICIOUS) dans une pièce jointe cinq minutes après la distribution du fichier (security_result.action = ALLOW) à l'utilisateur dans sa boîte de réception.

L'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 sous 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 toute entité d'une organisation. Si le champ metadata.entity_type est défini sur USER, l'enregistrement stocke les informations relatives à l'utilisateur sous l'attribut entity.user. Si le champ metadata.entity_type est défini sur ASSET, l'enregistrement stocke les informations sur un élément, comme la station de travail, l'ordinateur portable, le téléphone et la machine virtuelle.

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

Champs de métadonnées

Cette section contient les champs obligatoires pour une entité UDM, tels que:

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

L'attribut d'entité

Les champs situés sous 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 élément, ou windows_sid et l'adresse e-mail s'il s'agit d'un utilisateur. Notez que le nom du champ est "entity", mais que le type de champ est un nom. Un nom est une structure de données couramment utilisée qui stocke des informations dans des entités et des événements.

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

L'attribut relation

Les champs situés sous l'attribut relation stockent des informations sur d'autres entités auxquelles l'entité principale est associée. C'est le cas, par exemple, si l'entité principale est un utilisateur et qu'un ordinateur portable lui a été fourni. L'ordinateur portable est une entité associée. Les informations sur l'ordinateur portable sont stockées sous la forme d'un enregistrement "entity" avec le paramètre metadata.entity_type = ASSET. Les informations sur l'utilisateur sont stockées sous la forme d'un enregistrement "entity" avec le paramètre metadata.entity_type = USER.

L'enregistrement d'entité utilisateur capture également la relation entre l'utilisateur et l'ordinateur portable, à l'aide des champs situés sous l'attribut "relation". Le champ relation.relation enregistre la relation entre l'utilisateur et l'ordinateur portable, en particulier le fait qu'il possè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 le nom d'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 situés sous l'attribut relation.entity stockent des informations relatives à l'ordinateur portable.

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