Présentation de l'alias et de l'enrichissement UDM dans Google Security Operations
Ce document présente l'alias et l'enrichissement UDM dans Google Security Operations. Il décrit les cas d'utilisation courants et explique comment fonctionnent les alias et l'enrichissement sur la plate-forme.
L'alias et l'enrichissement UDM sont des concepts clés dans Google SecOps. Elles fonctionnent ensemble, mais servent des objectifs différents.
- L'alias identifie les différents noms et les données de contexte supplémentaires qui décrivent un indicateur.
- L'enrichissement utilise les alias pour ajouter du contexte à un événement UDM.
Par exemple, un événement UDM inclut le nom d'hôte alex-macbook
et indique qu'un hachage de fichier malveillant a été exécuté par l'utilisateur alex
. Grâce à l'alias, nous constatons que le nom d'hôte alex-macbook
s'est vu attribuer l'adresse IP 192.0.2.0
au moment de l'événement et que alex
quittera l'entreprise dans deux semaines. L'association de ces alias à l'événement UDM d'origine ajoute du contexte.
Fonctionnalités d'alias et d'enrichissement compatibles
Les équipes SecOps de Google acceptent les alias et l'enrichissement pour les éléments suivants :
- Éléments
- Utilisateurs
- Processus
- Métadonnées de hachage de fichier
- Emplacements géographiques
- Ressources cloud
Fonctionnement des alias
L'alias permet l'enrichissement. Par exemple, à l'aide de l'aliasing, vous pouvez trouver d'autres adresses IP et adresses MAC associées à un nom d'hôte, ou le titre et le statut professionnel associés à un ID utilisateur.
Comme les autres fonctionnalités de Google SecOps, l'alias nécessite l'ingestion et l'indexation des données. L'aliasing est classé dans trois catégories principales :
- Données spécifiques au client : données propres à un client. Par exemple, seul
Aristocrat
peut fournir des données pouramal@aristocrat.com
. Les types d'alias spécifiques aux clients incluent les composants, les utilisateurs et les processus. - Données globales : données ingérées et indexées qui s'appliquent à tous les clients. Par exemple, une indication provenant d'une source mondiale concernant un fichier malveillant peut être utilisée pour vérifier la présence de ce fichier dans votre entreprise.
- Service tiers : alias créé par un fournisseur de services tiers. Google SecOps utilise des services géographiques pour trouver l'emplacement physique des adresses IP.
Ces types d'alias sont utilisés ensemble pour générer des résultats d'alias d'éléments.
Alias d'éléments
L'alias d'asset associe les noms d'hôte, les adresses IP, les adresses MAC, les ID d'asset et d'autres métadonnées. Voici les étapes à suivre :
- Alias EDR : mappe les ID de produit (ID d'asset) aux noms d'hôte.
Les champs de mappage EDR sont dérivés exclusivement du type de journal
CS_EDR
. - Alias DHCP : utilise les événements DHCP pour associer les noms d'hôte, les adresses MAC et les adresses IP.
- Alias de contexte d'asset : associe un indicateur d'asset à des données d'entité, telles que le nom d'hôte, l'adresse IP, l'adresse MAC, la version du logiciel et l'état du déploiement.
Champs indexés de mappage EDR
Google SecOps indexe les champs EDR MAPPING pour générer des alias qui associent les noms d'hôte et les ID spécifiques aux produits.
Le tableau suivant liste les champs UDM et les types d'indicateurs correspondants :
Champ UDM | Type d'indicateur |
---|---|
principal.hostname et principal.asset.hostname | HOSTNAME |
principal.asset_id et principal.asset.asset_id | PRODUCT_SPECIFIC_ID |
Champs indexés DHCP
Google SecOps indexe les enregistrements DHCP pour générer des alias qui associent les noms d'hôte, les adresses IP et les adresses MAC.
Le tableau suivant répertorie les champs UDM et les types d'indicateurs correspondants utilisés pour l'alias d'assets :
Champ UDM | Type d'indicateur |
---|---|
principal.ip et principal.asset.ip | ASSET_IP_ADDRESS |
principal.mac et principal.asset.mac | MAC |
principal.hostname et principal.asset.hostname | HOSTNAME |
principal.asset_id et principal.asset.asset_id | PRODUCT_SPECIFIC_ID |
network.dhcp.yiaddr sur ACK, OFFER, WIN_DELETED et WIN_EXPIRED | ASSET_IP_ADDRESS |
network.dhcp.ciaddr sur INFORM, RELEASE et REQUEST | ASSET_IP_ADDRESS |
network.dhcp.requested_address sur DECLINE | ASSET_IP_ADDRESS |
network.dhcp.chaddr | MAC |
network.dhcp.client_hostname | HOSTNAME |
Champs indexés du contexte des composants
Google SecOps ingère les événements ASSET_CONTEXT
en tant qu'événements de contexte d'entité, plutôt qu'en tant qu'événements UDM.
Le tableau suivant répertorie les champs d'entité et les types d'indicateurs correspondants :
Champ d'entité | Type d'indicateur |
---|---|
entity.asset.product_object_id | PRODUCT_OBJECT_ID |
entity.metadata.product_entity_id (si l'ID de l'objet produit pour le composant est manquant) | PRODUCT_OBJECT_ID |
entity.asset.asset_id | PRODUCT_SPECIFIC_ID |
entity.asset.hostname | HOSTNAME |
entity.asset.ip | ASSET_IP_ADDRESS |
entity.asset.mac | MAC |
entity.namespace | NAMESPACE |
Alias d'utilisateur
L'alias d'utilisateur permet de trouver des informations à l'aide d'un indicateur utilisateur. Par exemple, en utilisant l'adresse e-mail d'un employé, vous pouvez trouver plus d'informations sur cet employé, comme son nom, son titre et son statut professionnel.
L'alias d'utilisateur utilise le type de lot d'événements USER_CONTEXT
pour l'alias.
Champs indexés du contexte utilisateur
Google SecOps ingère les événements USER_CONTEXT
en tant qu'événements de contexte d'entité, et non en tant qu'événements UDM.
Le tableau suivant répertorie les champs d'entité et les types d'indicateurs correspondants :
Champ d'entité | Type d'indicateur |
---|---|
entity.user.product_object_id | PRODUCT_OBJECT_ID |
entity.metadata.product_entity_id (si l'ID de l'objet produit de l'utilisateur est manquant) | PRODUCT_OBJECT_ID |
entity.user.userid | USERNAME |
entity.user.email_addresses | EMAIL |
entity.user.windows_sid | WINDOWS_SID |
entity.user.employee_id | EMPLOYEE_ID |
entity.namespace | NAMESPACE |
Alias de processus
L'alias de processus mappe un ID de processus spécifique à un produit (product_specific_process_id
) au processus réel et récupère des informations sur le processus parent.
L'alias de processus utilise le type de lot d'événements EDR pour l'alias.
Champs indexés EDR pour l'alias de processus
Lorsqu'un processus est lancé, des métadonnées telles que les lignes de commande, les hachages de fichiers et les détails du processus parent sont collectées. Le logiciel EDR exécuté sur la machine attribue un UUID de processus spécifique au fournisseur.
Le tableau suivant liste les champs indexés lors d'un événement de lancement de processus :
Champ UDM | Type d'indicateur |
---|---|
target.product_specific_process_id | PROCESS_ID |
target.process | L'ensemble du processus, et pas seulement l'indicateur |
En plus du champ target.process
de l'événement normalisé, Google SecOps collecte et indexe également les informations sur le processus parent.
Alias de métadonnées de hachage de fichier
L'alias de métadonnées de hachage de fichier identifie les métadonnées de fichier, telles que d'autres hachages de fichier ou tailles de fichier, en fonction d'un hachage de fichier donné (sha256, sha1 ou md5).
L'alias des métadonnées du hachage de fichier utilise le type de lot d'événements FILE_CONTEXT
pour l'alias.
Champs indexés du contexte de fichier
Google SecOps ingère les événements FILE_CONTEXT
de VirusTotal en tant qu'événements de contexte d'entité. Ces événements sont mondiaux et ne sont pas spécifiques à un client.
Le tableau suivant répertorie les champs d'entité indexés et les types d'indicateurs correspondants :
Champ d'entité | Type d'indicateur |
---|---|
entity.file.sha256 | PRODUCT_OBJECT_ID |
entity.metadata.product_entity_id (si le fichier sha256 est manquant) |
PRODUCT_OBJECT_ID |
entity.file.md5 | HASH_MD5 |
entity.file.sha1 | HASH_SHA1 |
entity.file.sha256 | HASH_SHA256 |
entity.namespace | NAMESPACE |
Alias de géolocalisation d'adresse IP
L'alias géographique fournit des données enrichies en géolocalisation pour les adresses IP externes.
Pour chaque adresse IP dans le champ principal
, target
ou src
d'un événement UDM, si l'adresse n'est pas un alias, un sous-protocole ip_geo_artifact
est créé avec les informations de localisation et de numéro de système autonome associées.
L'alias géographique n'utilise pas de période d'analyse ni de mise en cache. En raison du grand nombre d'événements, Google SecOps conserve un index en mémoire. L'index provient du MPM du serveur simple IPGeo et est mis à jour toutes les deux semaines.
Alias de ressources
L'alias de ressource renvoie des informations sur les ressources cloud pour un ID de ressource donné. Par exemple, il peut renvoyer des informations sur une instance Bigtable à l'aide de son URI Google Cloud . Elle n'utilise pas de lookback ni de mise en cache.
L'alias de ressources n'enrichit pas les événements UDM. Toutefois, certains produits, tels qu'Alert Graph, utilisent l'alias de ressources. L'alias de ressources cloud utilise le type de lot d'événements RESOURCE_CONTEXT
.
Champs indexés du contexte de ressource
Les événements de contexte de métadonnées de ressources cloud sont ingérés en tant qu'événements RESOURCE_CONTEXT
.
Le tableau suivant répertorie les champs d'entité et les types d'entité correspondants :
Champ d'entité | Type d'indicateur |
---|---|
entity.resource.product_object_id | PRODUCT_OBJECT_ID |
entity.metadata.product_entity_id (si l'ID d'objet produit de la ressource est manquant) | PRODUCT_OBJECT_ID |
entity.resource.name | CLOUD_RESOURCE_NAME |
entity.namespace | NAMESPACE |
Enrichissement
L'enrichissement utilise les alias pour ajouter du contexte à un indicateur ou un événement UDM de différentes manières :
- Identifie les entités alias qui décrivent un indicateur, généralement un champ UDM.
- Remplit les parties associées du message UDM avec des valeurs enrichies liées aux alias ou entités renvoyés.
Enrichissement des composants
Pour chaque événement UDM, le pipeline extrait les champs UDM suivants des entités principal
, src
et target
:
Champ UDM | Type d'indicateur |
---|---|
hostname | HOSTNAME |
asset_id | PRODUCT_SPECIFIC_ID |
mac | MAC |
ip(IFF asset_id est vide) | IP |
Chaque indicateur d'asset est associé à un espace de noms. L'espace de noms vide est considéré comme valide. Pour chaque indicateur d'éléments, le pipeline effectue les actions suivantes :
- Récupère les alias pour la journée complète de l'heure de l'événement.
- Crée un message
backstory.Asset
à partir de la réponse d'alias. - Mappe chaque type de nom et chaque indicateur à une backstory.Message d'asset et fusionne tous les protos associés.
- Définit les champs de composants de premier niveau et le message proto
asset
à l'aide de l'historique fusionné.
Enrichissement des utilisateurs
Pour chaque événement UDM, le pipeline extrait les champs UDM suivants de principal
, src
et target
:
Champ UDM | Type d'indicateur |
---|---|
email_addresses | EMAIL |
userid | USERNAME |
windows_sid | WINDOWS_SID |
employee_id | EMPLOYEE_ID |
product_object_id | PRODUCT_OBJECT_ID |
Pour chaque indicateur, le pipeline effectue les actions suivantes :
- Récupère une liste d'entités utilisateur. Par exemple, les entités de
principal.email_address
etprincipal.userid
peuvent être identiques ou différentes. - Choisit les alias du meilleur type d'indicateur, en utilisant l'ordre de priorité suivant :
WINDOWS_SID
,EMAIL
,USERNAME
,EMPLOYEE_ID
etPRODUCT_OBJECT_ID
. - Remplit
noun.user
avec l'entité dont l'intervalle de validité croise l'heure de l'événement.
Enrichissement des processus
Pour chaque événement UDM, le pipeline extrait process.product_specific_process_id (PSPI)
des champs suivants :
principal
src
target
principal.process.parent_process
src.process.parent_process
target.process.parent_process
Le pipeline trouve ensuite le processus réel à partir du PSPI à l'aide de l'alias de processus, qui renvoie également des informations sur le processus parent. Ces données sont fusionnées dans le champ noun.process
correspondant du message enrichi.
Enrichissement des artefacts
L'enrichissement des artefacts ajoute des métadonnées de hachage de fichier provenant de VirusTotal et des emplacements d'adresses IP provenant de données de géolocalisation. Pour chaque événement UDM, le pipeline extrait et interroge les données de contexte pour ces indicateurs d'artefact à partir des entités principal
, src
et target
:
- Adresse IP : interroge les données uniquement si elles sont publiques ou routables.
- Hachages de fichiers : les hachages de requêtes sont dans l'ordre suivant :
file.sha256
file.sha1
file.md5
process.file.sha256
process.file.sha1
process.file.md5
Le pipeline utilise l'epoch UNIX et l'heure de l'événement pour définir la plage de dates des requêtes d'artefacts de fichier. Si les données de géolocalisation sont disponibles, le pipeline remplace les champs UDM suivants pour les principal
, src
et target
respectifs, en fonction de l'origine des données de géolocalisation :
artifact.ip
artifact.location
artifact.network
(uniquement si les données incluent le contexte du réseau IP)location
(uniquement si les données d'origine n'incluent pas ce champ)
Si le pipeline trouve des métadonnées de hachage de fichier, il les ajoute aux champs de fichier ou process.file
, selon l'origine de l'indicateur. Le pipeline conserve toutes les valeurs existantes qui ne chevauchent pas les nouvelles données.
Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.