Enrichissement

Compatible avec :

L'enrichissement utilise les méthodes suivantes pour ajouter du contexte à un indicateur ou un événement du modèle de données unifié (UDM) :

  • Identifie les entités alias qui décrivent un indicateur, généralement un champ UDM.
  • Renseigne le message UDM avec des informations supplémentaires provenant des alias ou entités identifiés.
  • Ajoute des données d'enrichissement globales, telles que GeoIP et VirusTotal, aux événements UDM.

Comprendre les schémas de logique d'enrichissement

Google SecOps applique différents schémas logiques aux données en fonction du type d'enrichissement. Utilisez le tableau suivant pour comprendre ces schémas de dépannage et expliquer pourquoi certains champs sont renseignés, fusionnés ou écrasés.

Schéma logique Description Enrichissement applicable
Première correspondance Il suit une liste de priorités stricte. Le pipeline n'interroge que la première valeur disponible trouvée dans la séquence. Artefact (hachages de fichiers)
Fusionné Collecte et combine les données de plusieurs champs simultanément pour créer un enregistrement d'entité "golden" unique. Élément, utilisateur
Remplacement conditionnel Un champ spécifique n'est utilisé pour l'enrichissement que si un identifiant de priorité supérieure est manquant. Composant (adresse ip)
Mappage et remplacement Utilise un ID unique (PSPI) pour résoudre les entités. Les données avec alias de la source d'enrichissement remplacent les données analysées existantes. Processus

Enrichissement des composants

Pour l'enrichissement des composants, le pipeline identifie les composants uniques en évaluant plusieurs champs UDM. Contrairement à l'enrichissement des artefacts (qui en choisit un), l'enrichissement des composants fusionne le contexte de plusieurs ID pour créer un profil de composant complet.

Pour les composants, la logique est cumulative plutôt qu'exclusive, sauf dans certains scénarios de remplacement. Utilisez les informations suivantes pour expliquer :

  • Type de logique : "Fusionnée" ou "Solution de repli". Le pipeline collecte les données de tous les champs disponibles pour créer une vue "Entité" unique, sauf si une condition de secours (comme la vérification asset_id) est remplie.
  • Mappages de champs :
    • Nom d'hôte, adresse MAC et asset_id : traités comme des identifiants principaux. Les résultats d'alias de tous ces champs sont fusionnés pour produire le profil d'asset enrichi final.
    • Adresse IP : incluse dans la requête d'enrichissement uniquement si asset_id n'est pas disponible.

Pour chaque événement d'asset, le pipeline extrait les champs UDM suivants des entités principal, src et target :

Champ UDM Type d'indicateur Logique / Priorité
hostname HOSTNAME Fusionné : les résultats d'alias de ces champs sont combinés pour produire l'enregistrement d'élément enrichi final.
asset_id PRODUCT_SPECIFIC_ID Fusionné : identifiant principal utilisé pour consolider le contexte des composants.
mac MAC "Fusionné" : utilisé avec d'autres identifiants pour résoudre l'actif.
ip IP Remplacement : inclus dans la requête d'enrichissement uniquement si asset_id n'est pas disponible.

Enrichissement des utilisateurs

L'enrichissement des utilisateurs résout les données d'identité en recherchant des identifiants spécifiques. Comme l'enrichissement des artefacts, ce pipeline utilise un ordre de préférence pour déterminer quel identifiant est utilisé comme clé primaire pour la recherche.

Pour chaque événement utilisateur, le pipeline extrait les champs UDM suivants de principal, src et target :

Champ UDM Type d'indicateur Logique ou priorité
user.email_addresses E-MAIL Priorité la plus élevée : le pipeline tente d'abord d'enrichir les données en fonction des adresses e-mail principales ou secondaires de l'utilisateur.
user.windows_sid WINDOWS_SID Deuxième priorité : si aucune adresse e-mail n'est disponible, le pipeline utilise l'identificateur de sécurité (SID) Windows.
user.userid USER_ID Troisième priorité : utilisée uniquement si l'adresse e-mail et le SID sont manquants. Elle correspond généralement aux ID locaux ou spécifiques à l'application.
user.employee_id EMPLOYEE_ID Priorité la plus basse : dernier recours pour résoudre l'identité d'un utilisateur.

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 et principal.userid peuvent être identiques ou différentes.
  • Sélectionne les alias du type d'indicateur de priorité la plus élevée, en utilisant l'ordre de priorité suivant : WINDOWS_SID, EMAIL, USERNAME, EMPLOYEE_ID et PRODUCT_OBJECT_ID.
  • Renseigne noun.user avec l'entité dont l'intervalle de validité croise l'heure de l'événement.

Enrichissement des processus

L'enrichissement des processus vise à fournir de la visibilité sur les événements d'exécution. Le pipeline extrait les détails du processus et les enrichit en croisant les réputations des fichiers et les relations parent-enfant.

Utilisez l'enrichissement de processus pour mapper un ID de processus spécifique à un produit (product_specific_process_id), ou PSPI, au processus réel et récupérer des informations sur le processus parent. Ce processus repose sur le type de lot d'événements EDR.

Entité UDM Source du champ Logique ou priorité
Entités principales principal, src, target Extraction : le pipeline extrait les informations permettant d'identifier personnellement l'utilisateur à partir de ces entités de premier niveau pour lancer la recherche.
Processus parents principal.process.parent_process,
src.process.parent_process,
target.process.parent_process 		Mappage : le PSPI récupère des informations sur le processus parent grâce à l'alias de processus.
Fusion de données noun.process (par exemple, principal.process) Règle de remplacement : les champs avec alias sont prioritaires. Si des données analysées et des données avec alias existent pour le même champ, le pipeline remplace les données analysées par les données avec alias.

Le pipeline utilise l'alias de processus pour identifier le processus réel à partir du PSPI et récupérer des informations sur le processus parent. Il fusionne ensuite ces données dans le champ noun.process correspondant du message enrichi.

Champs indexés EDR pour l'alias de processus

Lorsqu'un processus est lancé, le système collecte des métadonnées (par exemple, les lignes de commande, les hachages de fichiers et les détails du processus parent). 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 les informations sur le processus parent.

Enrichissement des artefacts

L'enrichissement des artefacts ajoute des métadonnées de hachage de fichier provenant de VirusTotal et des données de géolocalisation pour les adresses IP. Pour les hachages de fichiers, le pipeline s'arrête à la première valeur trouvée dans une liste prioritaire. Toutefois, pour les adresses IP, il traite toutes les entrées en parallèle. Pour chaque événement UDM, le pipeline extrait et interroge les données de contexte pour les indicateurs d'artefact suivants des entités principal, src et target, où le comportement d'enrichissement diffère selon le type d'indicateur :

Type d'indicateur Logique d'extraction Priorité / ordre des opérations
Hachages de fichiers Première correspondance Le pipeline recherche les hachages dans l'ordre suivant et ne sélectionne que le premier disponible pour interroger VirusTotal :
  1. file.sha256
  2. file.sha1
  3. file.md5
  4. process.file.sha256
  5. process.file.sha1
  6. process.file.md5
Adresse IP Parallèle (répétition) Chaque adresse IP publique ou routable est traitée comme une entrée indépendante. Il n'y a pas d'ordre de préférence : chaque adresse IP reçoit ses propres résultats d'enrichissement.

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 des données de géolocalisation sont disponibles, le pipeline remplace les champs UDM suivants pour les entités principal, src et target, 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.

Enrichissement de la géolocalisation par adresse IP

L'alias géographique fournit des données de géolocalisation pour les adresses IP externes. Pour chaque adresse IP non aliasée dans le champ principal, target ou src d'un événement UDM, un tampon de sous-protocole ip_geo_artifact est créé avec les informations de localisation et d'ASN associées.

L'alias géographique n'utilise pas de période d'analyse ni de mise en cache. En raison du volume élevé d'événements, Google SecOps conserve un index en mémoire.

Enrichir les événements avec les métadonnées de fichiers VirusTotal

Google SecOps enrichit les hachages de fichiers dans les événements UDM et fournit un contexte supplémentaire lors d'une investigation. L'alias de hachage enrichit les événements UDM en combinant tous les types de hachages de fichiers et en fournissant des informations sur un hachage de fichier lors d'une recherche.

Google SecOps intègre les métadonnées et l'enrichissement des relations des fichiers VirusTotal pour identifier les schémas d'activité malveillante et suivre les mouvements de logiciels malveillants sur un réseau.

Un journal brut fournit des informations limitées sur le fichier. VirusTotal enrichit l'événement avec des métadonnées de fichier, y compris des informations sur les hachages et les fichiers malveillants. Les métadonnées incluent des informations telles que les noms de fichiers, les types, les fonctions importées et les tags. Vous pouvez utiliser ces informations dans le moteur de recherche et de détection UDM avec YARA-L pour comprendre les événements de fichiers malveillants et lors de la chasse aux menaces. Par exemple, vous pouvez détecter les modifications apportées au fichier d'origine qui utilisent les métadonnées du fichier pour la détection des menaces.

Les informations suivantes sont stockées avec l'enregistrement. Pour obtenir la liste de tous les champs UDM, consultez Liste des champs UDM (Unified Data Model).

Type de données Champ UDM
sha-256 ( principal | target | src | observer ).file.sha256
md5 ( principal | target | src | observer ).file.md5
sha-1 ( principal | target | src | observer ).file.sha1
taille ( principal | target | src | observer ).file.size
ssdeep ( principal | target | src | observer ).file.ssdeep
vhash ( principal | target | src | observer ).file.vhash
authentihash ( principal | target | src | observer ).file.authentihash
Imphash des métadonnées du fichier PE ( principal | target | src | observer ).file.pe_file.imphash
security_result.threat_verdict ( principal | target | src | observer ).(process | file).security_result.threat_verdict
security_result.severity ( principal | target | src | observer ).(process | file).security_result.severity
last_modification_time ( principal | target | src | observer ).file.last_modification_time
first_seen_time ( principal | target | src | observer ).file.first_seen_time
last_seen_time ( principal | target | src | observer ).file.last_seen_time
last_analysis_time ( principal | target | src | observer ).file.last_analysis_time
exif_info.original_file ( principal | target | src | observer ).file.exif_info.original_file
exif_info.product ( principal | target | src | observer ).file.exif_info.product
exif_info.company ( principal | target | src | observer ).file.exif_info.company
exif_info.file_description ( principal | target | src | observer ).file.exif_info.file_description
signature_info.codesign.id ( principal | target | src | observer ).file.signature_info.codesign.id
signature_info.sigcheck.verfied ( principal | target | src | observer ).file.signature_info.sigcheck.verified
signature_info.sigcheck.verification_message ( principal | target | src | observer ).file.signature_info.sigcheck.verification_message
signature_info.sigcheck.signers.name ( principal | target | src | observer ).file.signature_info.sigcheck.signers.name
signature_info.sigcheck.status ( principal | target | src | observer ).file.signature_info.sigcheck.signers.status
signature_info.sigcheck.valid_usage ( principal | target | src | observer ).file.signature_info.sigcheck.signers.valid_usage
signature_info.sigcheck.cert_issuer ( principal | target | src | observer ).file.signature_info.sigcheck.signers.cert_issuer
file_type ( principal | target | src | observer ).file.file_type

Résoudre les problèmes d'enrichissement

Si vous constatez qu'un événement UDM ne contient pas les données d'enrichissement attendues, suivez les suggestions ci-dessous pour résoudre le problème.

Enrichissement général

Si certains de vos événements ne sont pas enrichis du tout, cela peut être dû au fait que Google SecOps privilégie la vitesse de diffusion. Un petit pourcentage d'événements (< 1 %) peut être ignoré lors de l'enrichissement au premier passage. Pour résoudre ce problème, réessayez dans quelques minutes. Le système retraité automatiquement ces événements. Si l'enrichissement est toujours manquant au bout d'une heure, vérifiez que la source de journaux est correctement analysée dans UDM.

Enrichissement des artefacts (logique de première correspondance)

Si votre événement comporte un hachage MD5 et un hachage SHA256, mais que vous ne pouvez voir les métadonnées VirusTotal que pour le hachage SHA256, il s'agit d'une logique de première correspondance. Le pipeline s'arrête dès qu'il trouve le hachage de priorité la plus élevée (sha256). Il n'interroge pas VirusTotal pour le MD5 si un SHA256 est présent.

Si vous voyez la géolocalisation pour principal.ip, mais pas pour target.ip, la logique parallèle traite chaque adresse IP indépendamment. Si l'une des adresses IP est interne ou privée (non routable) et l'autre est publique, seule l'adresse IP publique reçoit l'enrichissement de géolocalisation.

Enrichissement des composants (logique de fusion et de remplacement)

Si le champ d'adresse IP n'affiche pas de données d'enrichissement sur votre composant, cela signifie qu'il s'agit d'une logique de secours conditionnelle. L'adresse IP n'est utilisée pour une requête d'enrichissement que si le asset_id (PSID) est manquant. Si un asset_id existe, le système s'appuie dessus et ignore l'adresse IP pour cette requête spécifique afin d'éviter les données redondantes ou conflictuelles.

Enrichissement des utilisateurs (ordre de préférence)

Si le champ Department affiche "IT" alors que mes journaux locaux indiquent "Security", cela signifie que l'enrichissement des utilisateurs préfère les champs analysés aux champs aliasés. Si votre journal brut a été analysé avec "IT", le pipeline d'enrichissement ne le remplace pas par la valeur "Security" de votre source d'identité (par exemple, Okta ou AD).

Enrichissement des processus (mapping et remplacement)

Si vous voyez un nom de processus dans votre journal brut, mais qu'il est remplacé par un autre nom dans la recherche UDM, cela signifie qu'il s'agit d'une logique d'écrasement. L'enrichissement des processus donne la priorité aux champs avec alias. Si la recherche PSPI renvoie un nom de processus plus précis à partir du contexte EDR, elle remplace complètement la valeur analysée d'origine.

Étapes suivantes

Pour savoir comment utiliser les données enrichies avec d'autres fonctionnalités Google SecOps, consultez les pages suivantes :

Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.