Utiliser le graphique du contexte d'entité (ECG)

Compatible avec :

Ce document présente le graphique de contexte des entités (ECG, Entity Context Graph), en abordant ses sources de données, son pipeline de traitement et ses applications dans les règles et la recherche. L'ECG est un modèle de données d'entité de base qui fournit un contexte essentiel pour la détection avancée des menaces, les investigations et la traque des menaces dans les règles de détection, la recherche et les tableaux de bord. Le pipeline de traitement ECG fusionne les informations contextuelles de chaque environnement Google SecOps.

L'ECG calcule également des métriques récapitulatives pour les entités. Il s'agit, entre autres, de la prévalence (la fréquence à laquelle une entité spécifique apparaît dans vos données UDM par rapport aux autres entités) et des first-seen-time et last-seen-time d'une entité. Il identifie également les principales sources d'enrichissement et les sources d'indicateurs de compromission (IOC), comme les données Google Threat Intelligence (GTI), la navigation sécurisée, WHOIS et VirusTotal.

L'ECG utilise les événements UDM pour effectuer les opérations suivantes :

  • Créez une vue enrichie, corrélée et complète des entités internes (composants et utilisateurs) et externes (IOC).
  • Identifiez les relations entre ces entités.

Sources de données de l'ECG

Le pipeline ECG combine les données des sources suivantes :

Source du contexte Source Description
Contexte de l'entité Fourni par le client Google SecOps ingère directement les données organisationnelles structurées, telles que les informations faisant autorité sur les utilisateurs et les assets, à partir de systèmes externes. Ces sources incluent les fournisseurs d'identité (IdP), les systèmes de base de données de gestion de configuration (CMDB) (tels que ServiceNow CMDB, Duo User Context) et les systèmes de gestion des failles.
Contexte dérivé Généré par Google SecOps Google SecOps génère des données statistiques basées sur l'analyse de l'activité ingérée. Il enrichit les événements et les entités provenant de diverses sources de votre environnement (par exemple, Windows AD, Azure AD, Okta, Google Cloud, IAM).
Par exemple :
Contexte global Fourni par Google Les sources mondiales fournissent des renseignements sur les menaces internes et externes, ainsi que des données sur la réputation.
Par exemple :

Pipeline de traitement des données ECG

Le pipeline de traitement des données ECG crée un profil riche et faisant autorité pour chaque entité. Pour ce faire, il fusionne le contexte provenant de plusieurs origines (telles que les fournisseurs d'identité, les bases de données de gestion de la configuration (CMDB), les flux de renseignement sur les menaces et le contexte dérivé) dans un profil d'entité unique et consolidé. La fusion des ECG permet les opérations suivantes :

  • Ajouter de nouvelles connexions, propriétés et relations à l'ECG.
  • Créer et mettre à jour le contexte dérivé

Le processus global consiste d'abord à normaliser les événements de sécurité bruts dans des structures UDM à l'aide de l'alias et de l'enrichissement UDM, puis à fusionner ces données d'événement avec diverses sources contextuelles pour créer des profils d'entité riches.

Alias UDM et fusion ECG

Tout d'abord, le pipeline d'alias et d'enrichissement UDM ingère les événements de sécurité bruts et les normalise en structures UDM.

Entités temporelles et intemporelles

L'ECG construit des entités temporelles et non temporelles. Les entités temporisées sont évaluées dans les plages de règles et de périodes de recherche spécifiées. Les entités intemporelles sont évaluées sans tenir compte de la période de la recherche ni de la règle.

Clés de fusion ECG

L'ECG fusionne les enregistrements de contexte en faisant correspondre les identifiants clés communs à différentes sources de données. Par exemple, il peut s'agir de hostname, MAC address, user ID ou email address. L'ECG fusionne les enregistrements qui correspondent à l'une de ces valeurs pour créer une vue complète et enrichie d'une entité.

L'aliasing ECG utilise les champs UDM suivants comme merge-keys :

  • Asset
    • entity.asset.product_object_id
    • entity.asset.hostname
    • entity.asset.asset_id
    • entity.asset.mac
  • User
    • entity.user.product_object_id
    • entity.user.userid
    • entity.user.windows_sid
    • entity.user.email_addresses
    • entity.user.employee_id
  • Resource
    • entity.resource.product_object_id
    • entity.resource.name
  • Group
    • entity.group.product_object_id
    • entity.group.email_addresses
    • entity.group.windows_sid

Fusionner des types d'entités spécifiques (fichier, URL, domaine)

En plus de merge-keys, l'ECG fusionne le contexte pour des types d'entités spécifiques (Fichier, URL et Domaine) à l'aide des identifiants uniques suivants :

  • File

    • entity.file.md5
    • entity.file.sha1
    • entity.file.sha256
    • (et entity.file.product_object_id si fourni)

  • URL

    • entity.url.url
    • (et entity.url.product_object_id si fourni)

  • Domain

    • entity.domain.domain
    • (et entity.domain.product_object_id si fourni)

L'ECG ne fusionne un enregistrement de contexte d'entité pour un File, un URL ou un Domain avec un autre enregistrement que si tous les identifiants uniques présents dans les deux enregistrements correspondent.

Par exemple, si l'ECG considère deux contextes d'entité File pour une fusion :

  • Si les deux ont un hachage md5, l'ECG exige qu'ils correspondent.
  • Si l'un a un md5 et l'autre un sha256, l'ECG ne les fusionnera pas en fonction du hachage.
  • Si un product_object_id est fourni, l'ECG doit également correspondre s'il est présent dans les deux enregistrements comparés, en plus des identifiants basés sur le contenu (comme md5, url ou domain).

Cela signifie que pour ces types, les champs tels que entity.file.md5, entity.url.url et entity.domain.domain doivent être présents et correspondre pour le processus de fusion, en plus de tout product_object_id fourni.

Résolution de conflits

Lors du processus de fusion, si les valeurs des champs sont en conflit, l'ECG met à jour l'entité en sélectionnant la valeur avec la date de début la plus récente. Lorsque l'ECG met à jour un attribut d'entité avec une nouvelle valeur, il conserve la valeur précédente dans les résultats de recherche pour l'intervalle de temps pendant lequel cette valeur précédente était valide. Par conséquent, une requête de recherche couvrant une période au cours de laquelle un attribut a changé peut renvoyer plusieurs contextes d'entité pour cette entité.

Déduplication et intervalles de temps

Pour créer une entité combinée commune, l'ECG élimine les données redondantes grâce à la déduplication. Les doublons sont identifiés en faisant correspondre tous les identifiants uniques pertinents d'une entité dans différentes sources de contexte. Il génère des intervalles de temps plutôt que de faire correspondre des codes temporels exacts.

Par exemple, considérons deux entités e1 et e2 avec des codes temporels t1 et t2, respectivement. Si e1 et e2 sont identiques, l'ECG les déduplique en ignorant les différences d'horodatage dans les champs suivants :

  • collected_timestamp
  • creation_timestamp
  • interval

Période d'analyse

L'ECG crée des données de contexte d'entité avec une période d'analyse de cinq jours. Ce processus permet de gérer les données reçues tardivement et d'établir une valeur TTL (Time To Live) implicite pour les données de contexte d'entité.

L'ECG fait la distinction entre les données contextuelles (assets, users, resources, groups) et les indicateurs de compromission (IOC).

Exemple : Fusionner des données utilisateur avec la fusion ECG

Par exemple, Google SecOps ingère les données utilisateur pour jdoe à partir de trois sources : Okta, Azure AD et un outil d'analyse des failles. L'ECG fusionne ces trois enregistrements en fonction des identifiants correspondants (comme jdoe@example.com). Cela crée une entité utilisateur jdoe unifiée dans l'ECG, contenant des attributs provenant des trois sources.

Sources de données ECG critiques sur les entités et le contexte des événements

Google SecOps nécessite plusieurs sources de données spécifiques pour créer et mettre à jour des entités.

Sources de données ECG contextuelles pour les entités critiques

Les sources de données faisant autorité pour les utilisateurs et les composants de votre environnement fournissent les données de journaux les plus importantes pour créer un modèle de données d'entité. Exemple :

Catégorie Sources de données critiques Entités renseignées
Gestion de l'authentification et des accès Active Directory, Azure AD, Okta, Google Cloud Identity user,
group
Inventaire des composants CMDB, JAMF, Microsoft Intune asset
Renseignement sur les menaces Flux personnalisés ou tiers, Google Threat Intelligence (GTI) ip_address,
domain_name,
file

Pour lister les analyseurs qui prennent en charge chaque catégorie :

  1. Accédez à Types de journaux compatibles avec un analyseur par défaut.

  2. Saisissez une catégorie dans la barre de recherche, par exemple :

    • Pour les analyseurs pertinents pour l'inventaire des composants, saisissez inventory ou asset.
    • Pour les analyseurs pertinents pour la gestion de l'authentification et des accès, saisissez identity.
    • Pour les analyseurs pertinents pour les renseignements sur les menaces, saisissez IOC.

Sources de données et champs UDM critiques pour le profilage des entités

Google SecOps améliore les profils d'entités en s'appuyant sur des sources de données contextuelles faisant autorité et sur des champs UDM essentiels :

Type d'entité Sources de données Champs UDM critiques (pour les alias et l'indexation)
Processus Les journaux de points de terminaison fournissent le PSPI (principal.process.product_specific_process_id), un identifiant stable essentiel pour un alias de processus robuste.
 Par exemple, CrowdStrike EDR (CS_EDR) et Windows Sysmon (WINDOWS_SYSMON).		 source.process.product_specific_process_id
Utilisateur Ces sources fournissent des attributs utilisateur et des informations sur l'identité.
Par exemple, les données contextuelles de l'entité Duo (DUO_CONTEXT) et Okta (OKTA).		 source.user.userid,
source.user.email_address,
source.user.windows_sid,
source.user.product_object_id
Composant ou point de terminaison Ces sources fournissent des informations fiables sur les composants.
 Par exemple, ServiceNow CMDB (SERVICENOW_CMDB) et Tanium Asset (TANIUM_ASSET).		 source.ip,
source.hostname,
source.asset_id,
principal.asset.hostname
Hachage du fichier Fournit une "empreinte numérique" unique du contenu des données pour vérifier l'intégrité des données. source.file.sha256,
source.file.sha1,
source.file.md5

Champs UDM des données contextuelles des événements critiques

Google SecOps nécessite plusieurs champs UDM de données contextuelles d'événements critiques.

  • Les champs UDM les plus critiques servent d'identifiants et d'indicateurs de relation stables (champs principal.*, target.*, src_* et dst_*).

  • Consultez la liste des champs UDM clés appartenant à la zone de fonctionnalité Entity graph.

  • Pour créer un ECG complet, privilégiez les sources de données qui fournissent des identifiants et des données de relations de grande valeur. Exemple :

    Type d'entité Sources de données critiques Champs UDM essentiels pour la création d'entités
    Asset (hôte) EDR et XDR, DNS et DHCP, pare-feu,journaux d'audit de la console Google Cloud metadata.event_type,
    principal.asset.asset_id,
    principal.asset.hostname,
    principal.ip
    Utilisateur Journaux du fournisseur d'identité (IdP), flux RH (contexte), journaux Cloud Identity, passerelle de messagerie principal.user.userid,
    principal.user.email_addresses,
    target.user.userid,
    principal.ip
    Réseau Pare-feu, VPN, DNS, journaux de flux VPC principal.ip,
    target.ip,
    src_ip,
    dst_ip,
    network.direction
    Fichier et processus EDR et XDR, journaux d'application target.file.full_path,
    target.process.file.full_path,
    target.process.command_line

Exemple

L'ECG s'appuie sur ces champs UDM pour joindre les données contextuelles d'entité et les données d'événement UDM dans les règles, les recherches et les tableaux de bord.

Par exemple, vous pouvez joindre des données contextuelles utilisateur dans une règle de surveillance "brute force" pour n'envoyer une alerte que si l'utilisateur concerné fait également partie du groupe "Administrateurs du domaine" et que l'asset concerné est un contrôleur de domaine :

events:
  $fail.metadata.event_type = "USER_LOGIN"
  $fail.metadata.vendor_name = "Microsoft"
  $fail.principal.hostname = $hostname
  $fail.target.user.userid = $target_user
  $fail.security_result.action = "BLOCK"
  $fail.metadata.product_event_type = "4625"
 
  $fail.metadata.event_timestamp.seconds < $success.metadata.event_timestamp.seconds
 
  $success.metadata.event_type = "USER_LOGIN"
  $success.metadata.vendor_name = "Microsoft"
  $success.target.user.userid = $target_user
  $success.principal.hostname = $hostname
  $success.security_result.action = "ALLOW"
  $success.metadata.product_event_type = "4624"
  $user.graph.entity.user.userid = $target_user
  $user.graph.metadata.entity_type = "USER"
  $user.graph.metadata.source_type = "ENTITY_CONTEXT"
  any $user.graph.relations.entity.group.group_display_name = "Domain Admins"

  $asset.graph.entity.asset.hostname = $hostname
  $asset.graph.metadata.entity_type = "ASSET"
  $asset.graph.metadata.source_type = "ENTITY_CONTEXT"
  any $asset.graph.relations.entity.group.group_display_name = "Domain Controllers"
 
match:
  $target_user, $hostname over 15m
condition:
  #fail > 4 and $success and $user and $asset

Enrichissements de contexte dérivés

Google SecOps génère des données d'inférence dynamiques basées sur les événements pour chaque entité dans tous les espaces de noms à partir des données d'événement de votre organisation. Il utilise des informations sur les alias, des données issues de processus d'enrichissement internes et des données d'événements de sécurité pour établir des relations (par exemple, un asset associé à un IP address).

Ce processus ajoute un contexte précieux pour améliorer les profils d'entité. Voici quelques exemples :

  • entity.file.sha256 à file (hash) entités
  • (principal or target).ip_geo_artifact.location.country_or_region à network (geolocation) entités

Google SecOps analyse plusieurs indicateurs dans l'activité ingérée pour enrichir les événements avec des informations contextuelles. Il exécute des fonctions d'enrichissement critiques pour générer, par exemple, des métriques de rareté des entités telles que les statistiques de prévalence et des métriques temporelles telles que first-seen-time et last-seen-time.

Statistiques de prévalence

Le pipeline ECG analyse les données existantes et entrantes pour calculer et stocker les métriques de prévalence en tant que champ de contexte dérivé. Ces métriques représentent une valeur numérique de "popularité" pour les entités telles que domain, file hash ou IP address dans votre environnement. Cela vous aide à repérer les activités rares ou inhabituelles, car les entités les plus populaires présentent généralement moins de risques.

Google SecOps met régulièrement à jour ces statistiques et les stocke dans un contexte d'entité distinct. Le moteur de détection peut utiliser ces valeurs, et vous pouvez les rechercher à l'aide de la syntaxe de requête UDM. Toutefois, la console n'affiche pas ces valeurs avec les autres détails de l'entité.

Vous pouvez utiliser les champs suivants lorsque vous créez des règles de moteur de détection.

Type d'entité Champs UDM
Domaine entity.domain.prevalence.day_count
entity.domain.prevalence.day_max
entity.domain.prevalence.day_max_sub_domains
entity.domain.prevalence.rolling_max
entity.domain.prevalence.rolling_max_sub_domains
Fichier (hachage) entity.file.prevalence.day_count
entity.file.prevalence.day_max
entity.file.prevalence.rolling_max
Adresse IP entity.artifact.prevalence.day_count
entity.artifact.prevalence.day_max
entity.artifact.prevalence.rolling_max

Google SecOps calcule les valeurs day_max et rolling_max différemment, comme suit :

  • day_max représente le score de prévalence maximal de l'artefact au cours de la journée (une journée est définie comme allant de 00h00 à 23h59 UTC).
  • rolling_max représente le score de prévalence maximal par jour (c'est-à-dire day_max) pour l'artefact au cours des 10 jours précédents.
  • day_count est utilisé pour calculer rolling_max, et sa valeur est toujours de 10.

Lorsque ces valeurs sont calculées pour un domain, la différence entre day_max et day_max_sub_domains (et entre rolling_max et rolling_max_sub_domains) est la suivante :

  • rolling_max et day_max représentent le nombre d'adresses IP internes uniques quotidiennes accédant à un domaine donné (sous-domaines exclus).
  • rolling_max_sub_domains et day_max_sub_domains représentent le nombre d'adresses IP internes uniques accédant à un domaine donné (sous-domaines inclus).

Google SecOps calcule les statistiques de prévalence à l'aide des données d'entité nouvellement ingérées. Google SecOps n'effectue pas de calculs rétroactifs sur les données ingérées précédemment. Google SecOps met environ 36 heures à calculer et à stocker les statistiques.

Exemple

Le pipeline ECG nécessite ces champs UDM pour joindre les données contextuelles pertinentes à une règle ou à une recherche. Vous devez associer explicitement toutes les données liées à l'ECG aux données d'événement UDM.

Par exemple, vous pouvez utiliser les données prevalence dans ECG pour déterminer les connexions à des domaines "rares" dans vos journaux de sécurité :

    $dns.metadata.event_type = "NETWORK_DNS"
    $dns.network.dns.questions.name != ""
    $dns.network.dns.questions.name = $domain
    $prevalence.graph.metadata.entity_type = "DOMAIN_NAME"
    $prevalence.graph.metadata.source_type = "DERIVED_CONTEXT"
    $prevalence.graph.entity.hostname = $domain
    $prevalence.graph.entity.domain.prevalence.day_count = 10
    $prevalence.graph.entity.domain.prevalence.rolling_max > 0
    $prevalence.graph.entity.domain.prevalence.rolling_max <= 3

  match:
    $domain over 5m
  condition:
    $dns and $prevalence

Heures de la première et de la dernière activité des entités

Google SecOps analyse les données entrantes pour enrichir les enregistrements de contexte d'entité avec les champs critiques suivants :

  • first-seen-time : date et heure auxquelles l'entité a été détectée pour la première fois dans votre environnement.
  • last-seen-time : date et heure de la dernière observation.

Ces champs dérivés vous permettent de corréler l'activité entre les entités domain, file hash, asset, user ou IP address.

Ces valeurs sont stockées dans les champs UDM suivants :

Type d'entité Champs UDM
Domaine entity.domain.first_seen_time
entity.domain.last_seen_time
Fichier (hachage) entity.file.first_seen_time
entity.file.last_seen_time
Adresse IP entity.artifact.first_seen_time
entity.artifact.last_seen_time
Élément entity.asset.first_seen_time
Utilisateur entity.user.first_seen_time

Exceptions pour les calculs de la première et de la dernière date d'observation :

  • Pour les entités asset et user, Google SecOps ne renseigne que le champ first_seen_time, et non le champ last_seen_time.
  • Google SecOps ne calcule pas les statistiques pour chaque entité dans les espaces de noms individuels.
  • Google SecOps n'exporte pas ces statistiques vers le schéma events Google SecOps dans BigQuery.
  • Google SecOps ne calcule pas ces valeurs pour les autres types d'entités, comme group ou resource.

Enrichissements du contexte global

Ces sources incluent des renseignements sur les menaces externes et des données de réputation provenant de sources mondiales internes et tierces.

Ingérer des données Google Threat Intelligence

Google SecOps ingère les données des sources de données Google Threat Intelligence (GTI), ce qui fournit des informations contextuelles pour examiner l'activité dans votre environnement.

Interrogez les sources de données suivantes :

  • Nœuds de sortie Tor GTI : adresses IP connues des nœuds de sortie Tor.
  • Binaires bénins GTI : fichiers qui font partie de la distribution d'origine du système d'exploitation ou qui ont été mis à jour par un correctif officiel du système d'exploitation. Certains binaires de systèmes d'exploitation officiels qui ont été utilisés de manière abusive par un adversaire par le biais d'une activité courante dans les attaques "living-off-the-land" sont exclus de cette source de données, comme ceux axés sur les vecteurs d'entrée initiale.
  • Outils d'accès à distance GTI : fichiers fréquemment utilisés par des personnes malveillantes. Ces outils sont généralement des applications légitimes qui sont parfois utilisées de manière abusive pour se connecter à distance à des systèmes piratés.

Les données contextuelles sont stockées à l'échelle mondiale sous forme d'entités. Vous pouvez interroger les données à l'aide de règles du moteur de détection. Incluez les champs et valeurs UDM suivants dans la règle pour interroger ces entités globales :

  • graph.metadata.vendor_name = Google Threat Intelligence
  • graph.metadata.product_name = GTI Feed

Sources de données Google Threat Intelligence avec ou sans limite de temps

Les sources de données Google Threat Intelligence incluent les types avec ou sans limite de temps.

Chaque entrée des sources de données timed est associée à une plage de temps. Par exemple, si Google SecOps génère une détection le jour 1, il est censé générer la même détection pour le jour 1 lors d'une recherche rétroactive n'importe quel jour ultérieur.

Les sources de données intemporelles n'ont pas de plage de dates associée, car seul le dernier ensemble de données doit être pris en compte. Ces sources de données sont généralement utilisées pour les données qui ne sont pas censées changer, comme les hachages de fichiers. Si Google SecOps ne génère pas de détection le premier jour, il est possible qu'une détection soit générée pour le premier jour lors d'une recherche rétroactive le deuxième jour si une nouvelle entrée a été ajoutée à la source de données intemporelle.

Données sur les adresses IP des nœuds de sortie Tor

Google SecOps ingère et stocke les adresses IP qui sont des nœuds de sortie Tor connus. Les nœuds de sortie Tor sont les points où le trafic quitte le réseau Tor. Ces données sont temporisées.

Google SecOps stocke les informations ingérées à partir de cette source de données dans les champs UDM suivants :

Champ UDM Description
<variable_name>.graph.metadata.vendor_name Stocke la valeur Google Threat Intelligence.
<variable_name>.graph.metadata.product_name Stocke la valeur GTI Feed.
<variable_name>.graph.metadata.threat.threat_feed_name Stocke la valeur Tor Exit Nodes.
<variable_name>.graph.entity.artifact.ip Stocke l'adresse IP ingérée à partir de la source de données GTI.
Exemple de recherche
graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Tor Exit Nodes"

Données sur les fichiers de système d'exploitation bénins

Google SecOps ingère et stocke les hachages de fichiers à partir de la source de données GTI Benign Binaries. Google SecOps stocke les informations ingérées à partir de cette source de données dans les champs UDM suivants. Les données binaires bénignes sont intemporelles.

Champ UDM Description
<variable_name>.graph.metadata.vendor_name Stocke la valeur Google Threat Intelligence.
<variable_name>.graph.metadata.product_name Stocke la valeur GTI Feed.
<variable_name>.graph.metadata.threat.threat_feed_name Stocke la valeur Benign Binaries.
<variable_name>.graph.entity.file.sha256 Stocke la valeur de hachage SHA256 du fichier.
<variable_name>.graph.entity.file.sha1 Stocke la valeur de hachage SHA-1 du fichier.
<variable_name>.graph.entity.file.md5 Stocke la valeur de hachage MD5 du fichier.
Exemple de recherche
graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Benign Binaries"

Données sur les outils d'accès à distance

Les outils d'accès à distance incluent les hachages de fichiers pour les outils d'accès à distance connus, tels que les clients VNC, que les acteurs malveillants ont fréquemment utilisés. Ces outils sont généralement des applications légitimes qui sont parfois utilisées de manière abusive pour se connecter à distance à des systèmes compromis. Google SecOps stocke les informations ingérées à partir de cette source de données dans les champs UDM suivants. Les données des outils d'accès à distance sont intemporelles.

Champ UDM Description
<variable_name>.graph.metadata.vendor_name Stocke la valeur Google Threat Intelligence.
<variable_name>.graph.metadata.product_name Stocke la valeur GTI Feed.
<variable_name>.graph.metadata.threat.threat_feed_name Stocke la valeur Remote Access Tools.
<variable_name>.graph.entity.file.sha256 Stocke la valeur de hachage SHA256 du fichier.
<variable_name>.graph.entity.file.sha1 Stocke la valeur de hachage SHA-1 du fichier.
<variable_name>.graph.entity.file.md5 Stocke la valeur de hachage MD5 du fichier.
Exemple de recherche
graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Remote Access Tools"

Enrichir les entités avec des informations provenant des listes de menaces de la navigation sécurisée

Google SecOps ingère les données de navigation sécurisée liées aux hachages de fichiers. Google SecOps stocke les données de chaque fichier en tant qu'entité et fournit un contexte supplémentaire sur le fichier. Vous pouvez créer des règles de moteur de détection qui interrogent ces données de contexte d'entité pour créer des analyses contextuelles.

Google SecOps stocke les informations suivantes dans l'enregistrement du contexte d'entité.

Champ UDM Description
entity.metadata.product_entity_id Identifiant unique de l'entité.
entity.metadata.entity_type Cette valeur est FILE, ce qui indique que l'entité décrit un fichier.
entity.metadata.collected_timestamp Date et heure auxquelles l'entité a été observée ou l'événement s'est produit.
entity.metadata.interval Stocke les heures de début et de fin de validité de ces données. Étant donné que le contenu des listes de menaces change au fil du temps, start_time et end_time reflètent l'intervalle de temps pendant lequel les données sur l'entité sont valides. Par exemple, un hachage de fichier a été identifié comme malveillant ou suspect entre le start_time et le end_time.
entity.metadata.threat.category Le SecurityCategory Google SecOps est défini sur une ou plusieurs des valeurs suivantes :
  • SOFTWARE_MALICIOUS : indique que la menace est liée à un logiciel malveillant.
  • SOFTWARE_PUA : indique que la menace est liée à un logiciel indésirable.
entity.metadata.threat.severity Il s'agit de la ProductSeverity Google SecOps. Si la valeur est CRITICAL, cela signifie que l'artefact semble malveillant. Si la valeur n'est pas spécifiée, la confiance n'est pas suffisante pour indiquer que l'artefact est malveillant.
entity.metadata.product_name Stocke la valeur Google Safe Browsing.
entity.file.sha256 Valeur de hachage SHA256 du fichier.

Exemple de règle

events:
    // find a process launch event, match on hostname
    $execution.metadata.event_type = "PROCESS_LAUNCH"
    $execution.target.process.file.sha256 != ""
    $execution.principal.hostname = $hostname

    // join execution event with Safe Browsing graph
    $sb.graph.entity.file.sha256 = $execution.target.process.file.sha256

    // look for files deemed malicious
    $sb.graph.metadata.entity_type = "FILE"
    $sb.graph.metadata.threat.severity = "CRITICAL"
    $sb.graph.metadata.product_name = "Google Safe Browsing"

  match:
    $hostname over 5m

  condition:
    $execution and $sb

Enrichir les entités avec des données WHOIS

Google SecOps effectue un enrichissement quotidien des données WHOIS, une fonction essentielle, à l'aide de données temporelles et intemporelles.

Lors de l'ingestion des données de l'appareil, Google SecOps évalue les domaines par rapport aux données WHOIS. Lorsque les domaines correspondent, Google SecOps stocke les données WHOIS associées dans l'enregistrement d'entité du domaine. Pour chaque entité avec entity.metadata.entity_type = DOMAIN_NAME, Google SecOps enrichit l'enregistrement avec des informations WHOIS.

Google SecOps renseigne l'enregistrement d'entité avec des données WHOIS enrichies dans les champs suivants :

  • entity.domain.admin.attribute.labels
  • entity.domain.audit_update_time
  • entity.domain.billing.attribute.labels
  • entity.domain.billing.office_address.country_or_region
  • entity.domain.contact_email
  • entity.domain.creation_time
  • entity.domain.expiration_time
  • entity.domain.iana_registrar_id
  • entity.domain.name_server
  • entity.domain.private_registration
  • entity.domain.registrant.company_name
  • entity.domain.registrant.office_address.state
  • entity.domain.registrant.office_address.country_or_region
  • entity.domain.registrant.email_addresses
  • entity.domain.registrant.user_display_name
  • entity.domain.registrar
  • entity.domain.registry_data_raw_text
  • entity.domain.status
  • entity.domain.tech.attribute.labels
  • entity.domain.update_time
  • entity.domain.whois_record_raw_text
  • entity.domain.whois_server
  • entity.domain.zone

Google SecOps enrichit les entités domain (entity.metadata.entity_type = "DOMAIN_NAME") avec des données registrant, creation et expiration time provenant des enregistrements WHOIS global context.

Pour obtenir la description de ces champs, consultez le document sur la liste des champs du modèle de données unifié.

Exemple de recherche

graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "WHOISXMLAPI Simple Whois"
graph.entity.domain.registry_data_raw_text != b""

Bonnes pratiques : identifier les sources de données enrichies par le contexte global

Pour améliorer les performances des règles, incluez un filtre dans les règles qui utilise les données des sources d'enrichissement du contexte global. Ce filtre doit identifier le type ou la source d'enrichissement spécifique.

Les paramètres de filtre suivants identifient le type ou la source d'enrichissement : entity_type, product_name et vendor_name.

Par exemple, incluez les champs de filtre suivants dans la section events de la règle qui joint les données WHOIS :

$enrichment.graph.metadata.entity_type = "DOMAIN_NAME"
$enrichment.graph.metadata.product_name = "WHOISXMLAPI Simple Whois"
$enrichment.graph.metadata.vendor_name = "WHOIS"

Bonnes pratiques concernant les ECG

Lorsque vous utilisez des données enrichies contextuellement, tenez compte des bonnes pratiques suivantes concernant les ECG :

  • N'ajoutez pas d'intervalles aux données d'entité. Laissez plutôt le pipeline ECG les créer. Google SecOps génère des intervalles lors de la déduplication, sauf indication contraire.
  • Si vous spécifiez les intervalles, Google SecOps ne déduplique que les événements identiques et conserve l'entité la plus récente.
  • Pour vous assurer que les règles en direct et les recherches rétroactives fonctionnent comme prévu, vous devez ingérer des entités au moins une fois par jour.
  • Si vous n'ingérez pas les entités tous les jours, mais seulement une fois tous les deux jours ou plus, les règles en direct peuvent toujours fonctionner comme prévu. Toutefois, les recherches rétroactives peuvent perdre certains contextes d'événements.
  • Si vous ingérez des entités identiques plusieurs fois par jour, Google SecOps les déduplique en une seule entité.
  • Si des données d'événement manquent pour un jour donné, Google SecOps utilise temporairement les données du jour précédent pour s'assurer que les règles en direct fonctionnent correctement.

Pour en savoir plus sur les limites générales des services Google SecOps, consultez Limites de service.

Contenu externe associé

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