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

Compatible avec:

Google SecOps <ph type="x-smartling-placeholder"></ph> SIEM

Ce document fournit une présentation de l'UDM (Unified Data Model). 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 dans deux formats : journal brut d'origine et sous forme d'enregistrement UDM structuré. L'enregistrement UDM est un bloc 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 en un 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'enregistrements auprès de différents fournisseurs à l'aide du même la sémantique.
• Identification plus simple 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.
• 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 utilisez ces mêmes noms de champs lorsque vous créez des règles.

Bien que vous puissiez rechercher des événements avec une recherche dans le journal brut, une recherche UDM fonctionne plus rapide 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. UDM comprend des milliers de champs qui sont utilisés pour décrire et catégoriser les événements. Par exemple, l'UDM peut gérer les événements de traitement des points de terminaison aussi facilement que les événements de communication.

Structure de l'UDM

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

Outre la section "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. Sections faisant référence à la source (src) et à la destination (target) sont également inclus.
• intermediary: systèmes par lesquels passent les événements, comme un proxy ou d'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 répertorie tous les événements de connexion réussis, quel que soit le fournisseur ou 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 avec cet ID utilisateur a réussi à se connecter. Vous pouvez effectuez cette recherche à l'aide de la section cible. La section cible comprend sous-sections et 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 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 une principal.ip de 35.235.240.5 Il inclut également un champ UDM de la section "Network" (Réseau), la direction de 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 net.exe et recherchez ce fichier spécifique dans son chemin d'accès attendu. La le champ que vous recherchez est target.process.file.full_path. Pour cette recherche, vous devez inclure 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 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 éventuellement ajouter les champs de recherche UDM suivants:

• principal.user.userid: identifie l'utilisateur ayant émis le .
• 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 d'utilisateurs (metadata.event_type). est USER_LOGIN) associé au service marketing (target.user.department) est marketing) de votre entreprise. Bien que target.user.department ne soit pas directement associée aux événements de connexion utilisateur, elle est toujours présente 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 un pare-feu et un proxy Web. Voici les données d'événements UDM du modèle de ML.
• Entité "UDM": représentation contextuelle d'éléments tels que des éléments les utilisateurs et les ressources de votre environnement. Il est obtenu à partir d'une source de données véritable. 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 "Événements" et du Modèle de données d'entité.

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

Remarque :Le terme Noun décrit le type d'attribut. Le principal des termes, "target", "src", "intermediary", "observateur" et "about" sont les noms des champs dans lesquels les données sont stockées.

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

Remarque :Le terme Noun décrit le type d'attribut. Les termes "élément", "utilisateur" et "resource" correspondent aux 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
• 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 principal, target et src Magasins des sections observer et intermediary 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 les données sont déterminés par le type d'événement et le rôle que joue 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 de messagerie: informations dans les to, from, cc, bcc et d'autres champs de messagerie.
• Données HTTP: par exemple method, referral_url et useragent

La section security_result stocke une action ou une classification enregistrée par un de sécurité, comme un antivirus.

Les sections about (À propos) et extensions (Extensions) contiennent des événements supplémentaires spécifiques au fournisseur. des informations qui ne sont pas capturées par les autres sections. La section extensions est une de paires clé-valeur à forme 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 alors que d'autres sont facultatifs. La Les attributs obligatoires et facultatifs sont déterminés par la propriété metadata.event_type . Google Security Operations lit le paramètre "metadata.event_type" et exécute de validation 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, les extensions elle 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 metadata.event_timestamp, est le code temporel GMT correspondant au moment où l'événement s'est produit. La valeur doit être encodée au format l'une des normes suivantes: RFC 3339 ou Proto3.

Les exemples suivants montrent comment spécifier l'horodatage à l'aide de la norme RFC 3339 format, yyyy-mm-ddThh:mm:ss+hh:mm (année, mois, jour, heure, minute, seconde et le décalage par rapport à l'heure UTC). Le décalage par rapport à l'UTC est de moins 8 heures, indiquant 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 en utilisant le 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. Exemples de valeurs : 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 en savoir plus sur les champs à inclure pour chaque type d'événement, consultez la section Utilisation de l'UDM guide de démarrage.

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. Chacun stocke des informations sur les objets impliqués dans l'activité, telle qu'elle est enregistrée par le journal brut d'origine. Il peut s’agir de l’appareil ou l'utilisateur qui a réalisé l'activité, l'appareil ou l'utilisateur ciblé par 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.

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 de le compte principal.
• target: objet sur lequel s'applique l'action.

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 joué un rôle d'intermédiaire dans la . 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 du trafic en question. Il peut s’agir d’un outil d’analyse des failles ou d’un paquet de détection.
• about: tout autre objet qui a joué un rôle dans l'événement et qui est (facultatif).

Les attributs principaux

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

Si l'événement se produit sur une seule machine, cette machine est décrite uniquement dans l'attribut principal. Il n'est pas nécessaire de décrire la machine "target" ou "src".

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

L'extrait de code 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 toutes les informations connues sur l'appareil et l'utilisateur est l'acteur principal de l'événement. Cet exemple inclut l'adresse IP de l'appareil, numéro de port et nom d'hôte. Il comprend également un identifiant d'élément spécifique au fournisseur, de Sophos, un identifiant unique généré par le service produit.

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 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: 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, des adresses IP, des adresses MAC et des identifiants d'éléments propriétaires supplémentaires, doit également être inclus 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 pourrait également agir sur le processus B (cible) sur la machine X.

L'attribut src

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

L'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. Il peut s'agir d'informations sur les appareils, telles que serveurs proxy et 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. Cela peut inclure un paquet ou d’un outil d’analyse des vulnérabilités basé sur le réseau.

L'attribut "À propos"

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, 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 menaces de sécurité trouvées par un système de sécurité et les mesures prises pour atténuer ces risques et contre les menaces.

Voici les types d'informations qui sont stockés 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 bloqué(e) (security_result.action = BLOQUER) 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 mis en quarantaine et désinfecté (security_result.action = QUARANTINE ou security_result.action = ALLOW_WITH_MODIFICATION) sur ces pièces jointes, puis a transféré les des e-mails désinfectés.
• 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 un fichier en pièce jointe cinq minutes après que le fichier a été (security_result.action = AUTORISER) à l'utilisateur dans sa boîte de réception.

Attribut réseau

Les attributs réseau stockent les données sur les événements liés au réseau et les détails dans les sous-messages. Cela inclut l'activité, comme les e-mails envoyés et reçues et HTTP.

Attribut extensions

Les champs sous cet attribut stockent des métadonnées supplémentaires concernant 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 à sous l'attribut "entity.user". Si le champ metadata.entity_type est défini sur ASSET, stocke des informations sur un actif, 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

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'objet (nom d'hôte et adresse IP s'il s'agit d'un élément, par exemple), ou windows_sid et 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 à la fois dans des entités et des événements.

• Si le champ metadata.entity_type est défini sur USER, les données sont stockées entité.user.
• Si metadata.entity_type est ASSET, les données sont stockées sous l'attribut entity.asset.

L'attribut relation

Les champs sous l'attribut relation stockent des informations sur d'autres entités qui l'entité principale est liée. Par exemple, si l'entité principale est un utilisateur et l'utilisateur a reçu un ordinateur portable. L'ordinateur portable est une entité associée. Les informations concernant l'ordinateur portable sont stockées en tant qu'entité enregistrer avec une metadata.entity_type = ASSET. Les informations sur l'utilisateur sont stockées "entity" avec le paramètre metadata.entity_type = USER.

L'enregistrement de l'entité utilisateur capture également la relation entre l'utilisateur et ordinateur portable, à l'aide de champs situés sous le libellé "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 sous l'attribut relations.entity stockent des informations sur l'ordinateur portable, comme le nom d'hôte et l'adresse MAC. Notez à nouveau que le nom du champ est "entity" et 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 le sens de la relation entre l'utilisateur et l'ordinateur portable, en particulier si la relation est bidirectionnelle et unidirectionnelle.