Comment Google Security Operations enrichit les données sur les événements et les entités

Ce document décrit comment Google Security Operations enrichit les données et les champs du modèle de données unifié (UDM) dans lesquels elles sont stockées.

Pour permettre une investigation de sécurité, Google Security Operations ingère des données contextuelles provenant de différentes sources, effectue une analyse des données et fournit un contexte supplémentaire sur les artefacts dans un environnement client. Les analystes peuvent utiliser des données enrichies contextuellement dans les règles du moteur de détection, les recherches d'investigation ou les rapports.

Google Security Operations effectue les types d'enrichissement suivants:

• Enrichit les entités à l'aide du graphe des entités et de la fusion.
• Calcule et enrichit chaque entité d'une statistique de prévalence qui indique sa popularité dans l'environnement.
• Calcule la première fois que certains types d'entités ont été détectés dans l'environnement ou la dernière fois.
• Enrichit les entités avec des informations issues des listes de menaces de la navigation sécurisée.
• Enrichit les événements avec des données de géolocalisation.
• Enrichit les entités avec des données WHOIS.
• Enrichit les événements avec les métadonnées de fichier VirusTotal.
• Enrichit les entités avec des données de relation VirusTotal.
• Ingérer et stocker des données Google Cloud Threat Intelligence

Les données enrichies de WHOIS, de la navigation sécurisée, de la plate-forme de renseignement sur les menaces GCTI, des métadonnées VirusTotal et de la relation VirusTotal sont identifiées par entity_type, product_name et vendor_name. Lorsque vous créez une règle qui utilise ces données enrichies, nous vous recommandons d'inclure un filtre dans la règle qui identifie le type d'enrichissement spécifique à inclure. Ce filtre permet d'améliorer les performances de la règle. 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"

Enrichir les entités à l'aide du graphe des entités et de la fusion

Le graphique des entités identifie les relations entre les entités et les ressources de votre environnement. Lorsque des entités provenant de différentes sources sont ingérées dans Google Security Operations, le graphique des entités gère une liste d'adjacence en fonction de la relation entre les entités. Le graphique des entités effectue l'enrichissement du contexte en effectuant une déduplication et une fusion.

Lors de la déduplication, les données redondantes sont éliminées et des intervalles sont créés pour former une entité commune. Par exemple, considérons deux entités e1 et e2 avec les codes temporels t1 et t2, respectivement. Les entités e1 et e2 sont dédupliquées, et les codes temporels différents ne sont pas utilisés lors de la déduplication. Les champs suivants ne sont pas utilisés lors de la déduplication:

• collected_timestamp
• creation_timestamp
• interval

Lors de la fusion, des relations entre les entités sont établies pour une période d'une journée. Prenons l'exemple d'un enregistrement d'entité user A qui a accès à un bucket Cloud Storage. Il existe un autre enregistrement d'entité pour user A, qui est propriétaire d'un appareil. Après la fusion, ces deux entités donnent lieu à une entité user A unique qui possède deux relations. La première relation indique que user A a accès au bucket Cloud Storage, et la seconde indique que user A est le propriétaire de l'appareil. Google Security Operations effectue un examen rétrospectif de cinq jours lorsqu'il crée des données de contexte d'entité. Cela gère les données arrivant tardivement et crée une durée de vie implicite sur les données de contexte de l'entité.

Google Security Operations utilise l'aliasing pour enrichir les données de télémétrie et les graphes d'entités pour enrichir les entités. Les règles du moteur de détection associent les entités fusionnées aux données de télémétrie enrichies pour fournir des analyses contextuelles.

Un événement contenant un nom d'entité est considéré comme une entité. Voici quelques types d'événements et les types d'entités correspondants:

• ASSET_CONTEXT correspond à ASSET.
• RESOURCE_CONTEXT correspond à RESOURCE.
• USER_CONTEXT correspond à USER.
• GROUP_CONTEXT correspond à GROUP.

Le graphique des entités distingue les données contextuelles des indicateurs de compromission (IOC) à l'aide des informations sur les menaces.

Lorsque vous utilisez des données enrichies contextuellement, tenez compte du comportement suivant du graphique des entités:

• N'ajoutez pas d'intervalles dans l'entité, mais laissez le graphique de l'entité créer des intervalles. En effet, des intervalles sont générés lors de la déduplication, sauf indication contraire.
• Si des intervalles sont spécifiés, seuls les mêmes événements sont dédupliqués et l'entité la plus récente est conservée.
• Pour vous assurer que les règles en ligne et les rétro-recherches fonctionnent comme prévu, les entités doivent être ingérées au moins une fois par jour.
• Si les entités ne sont pas ingérées quotidiennement, mais seulement une fois tous les deux jours ou plus, les règles en temps réel peuvent fonctionner comme prévu. Toutefois, les recherches rétroactives peuvent perdre le contexte de l'événement.
• Si des entités sont ingérées plus d'une fois par jour, elles sont dédupliquées en une seule entité.
• Si les données d'événement sont manquantes pour une journée, les données de la journée précédente sont utilisées temporairement pour s'assurer que les règles en direct fonctionnent correctement.

Le graphique des entités fusionne également les événements ayant des identifiants similaires pour obtenir une vue consolidée des données. Cette fusion se produit en fonction de la liste d'identifiants suivante:

• 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

Calculer des statistiques de prévalence

Google Security Operations effectue une analyse statistique sur les données existantes et entrantes, et enrichit les enregistrements de contexte des entités avec des métriques liées à la prévalence.

La prévalence est une valeur numérique qui indique la popularité d'une entité. La popularité est définie par le nombre d'éléments accédant à un artefact, tel qu'un domaine, un hachage de fichier ou une adresse IP. Plus le nombre est élevé, plus l'entité est populaire. Par exemple, google.com affiche des valeurs de prévalence élevées, car il est consulté fréquemment. Si un domaine est consulté rarement, ses valeurs de prévalence seront plus faibles. Les entités les plus populaires sont généralement moins susceptibles d'être malveillantes.

Ces valeurs enrichies sont acceptées pour le domaine, l'adresse IP et le fichier (hachage). Les valeurs sont calculées et stockées dans les champs suivants.

Les statistiques de prévalence pour chaque entité sont mises à jour chaque jour. Les valeurs sont stockées dans un contexte d'entité distinct qui peut être utilisé par le moteur de détection, mais qui n'est pas affiché dans les vues d'investigation Google Security Operations et la recherche UDM.

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

Les valeurs "day_max" et "rolling_max" sont calculées différemment. Les champs sont calculés comme suit:

• day_max est calculé comme le score de prévalence maximal de l'artefact au cours de la journée, où une journée est définie de 00h00 à 23h59 UTC.
• rolling_max est calculé comme le score de prévalence maximal par jour (c'est-à-dire day_max) de l'artefact au cours de la période de 10 jours précédente.
• day_count est utilisé pour calculer rolling_max et a toujours la valeur 10.

Lorsque calculée pour un domaine, la différence entre day_max et day_max_sub_domains (et 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 qui accèdent à un domaine donné (à l'exception des sous-domaines).
• rolling_max_sub_domains et day_max_sub_domains représentent le nombre d'adresses IP internes uniques accédant à un domaine donné (y compris les sous-domaines).

Les statistiques de prévalence sont calculées sur les données d'entité nouvellement ingérées. Les calculs ne sont pas effectués rétroactivement sur les données précédemment ingérées. Il faut environ 36 heures pour que les statistiques soient calculées et stockées.

Calculer la date et l'heure de la première et de la dernière apparition des entités

Google Security Operations effectue une analyse statistique des données entrantes et enrichit les enregistrements de contexte d'entité avec les dates de première et dernière apparition d'une entité. Le champ first_seen_time stocke la date et l'heure auxquelles l'entité a été vue pour la première fois dans l'environnement client. Le champ last_seen_time stocke la date et l'heure de l'observation la plus récente.

Étant donné que plusieurs indicateurs (champs UDM) peuvent identifier un composant ou un utilisateur, la date de première apparition correspond à la première fois qu'un des indicateurs permettant d'identifier l'utilisateur ou le composant a été détecté dans l'environnement client.

Tous les champs UDM qui décrivent un composant sont les suivants:

• entity.asset.hostname
• entity.asset.ip
• entity.asset.mac
• entity.asset.asset_id
• entity.asset.product_object_id

Tous les champs UDM qui décrivent un utilisateur sont les suivants:

• entity.user.windows_sid
• entity.user.product_object_id
• entity.user.userid
• entity.user.employee_id
• entity.user.email_addresses

La date et l'heure de la première et de la dernière apparition permettent à un analyste de mettre en corrélation certaines activités qui se sont produites après la première apparition d'un domaine, d'un fichier (hachage), d'un composant, d'un utilisateur ou d'une adresse IP, ou qui ont cessé de se produire après la dernière apparition du domaine, du fichier (hachage) ou de l'adresse IP.

Les champs first_seen_time et last_seen_time sont renseignés avec des entités qui décrivent un domaine, une adresse IP et un fichier (hachage). Pour les entités qui décrivent un utilisateur ou un composant, seul le champ first_seen_time est renseigné. Ces valeurs ne sont pas calculées pour les entités qui décrivent d'autres types, tels qu'un groupe ou une ressource.

Les statistiques sont calculées pour chaque entité dans tous les espaces de noms. Google Security Operations ne calcule pas les statistiques pour chaque entité dans des espaces de noms individuels. Ces statistiques ne sont actuellement pas exportées vers le schéma events Google Security Operations dans BigQuery.

Les valeurs enrichies sont calculées et stockées dans les champs UDM suivants:

Enrichir les événements avec des données de géolocalisation

Les données de journal entrantes peuvent inclure des adresses IP externes sans informations de localisation correspondantes. Cela se produit souvent lorsqu'un événement enregistre des informations sur l'activité d'un appareil qui ne se trouve pas sur un réseau d'entreprise. Par exemple, un événement de connexion à un service cloud contiendrait une adresse IP source ou client basée sur l'adresse IP externe d'un appareil renvoyée par le NAT du transporteur.

Google Security Operations fournit des données enrichies de géolocalisation pour les adresses IP externes afin de permettre une détection plus efficace des règles et un contexte plus détaillé pour les investigations. Par exemple, Google Security Operations peut utiliser une adresse IP externe pour enrichir l'événement d'informations sur le pays (par exemple, les États-Unis), un état spécifique (par exemple, l'Alaska) et le réseau auquel l'adresse IP appartient (par exemple, l'ASN et le nom du transporteur).

Google Security Operations utilise les données de localisation fournies par Google pour fournir une position géographique approximative et des informations sur le réseau pour une adresse IP. Vous pouvez écrire des règles du moteur de détection pour ces champs dans les événements. Les données d'événement enrichies sont également exportées vers BigQuery, où elles peuvent être utilisées dans les tableaux de bord et les rapports Google Security Operations.

Les adresses IP suivantes ne sont pas enrichies:

• Les espaces d'adressage IP privés RFC 1918, car ils sont internes au réseau de l'entreprise.
• Espace d'adresses IP multicast RFC 5771, car les adresses multicast n'appartiennent pas à un seul emplacement.
• Adresses locales uniques IPv6
• Adresses IP des services Google Cloud. Les exceptions sont les adresses IP externes Google Cloud Compute Engine, qui sont enrichies.

Google Security Operations enrichit les champs UDM suivants avec des données de géolocalisation:

• principal
• target
• src
• observer

L'exemple suivant montre le type d'informations géographiques qui serait ajouté à un événement UDM avec une adresse IP taguée aux Pays-Bas:

Incohérences

La technologie de géolocalisation IP propriétaire de Google combine des données réseau et d'autres entrées et méthodes pour fournir la position de l'adresse IP et la résolution du réseau à nos utilisateurs. D'autres organisations peuvent utiliser des signaux ou des méthodes différents, ce qui peut parfois entraîner des résultats différents.

Si vous constatez une incohérence dans les résultats de géolocalisation par adresse IP fournis par Google, veuillez ouvrir une demande auprès du service client afin que nous puissions examiner le problème et, le cas échéant, corriger nos enregistrements.

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

Google Security Operations ingère les données de la navigation sécurisée liées aux hachages de fichiers. Les données de chaque fichier sont stockées en tant qu'entité et fournissent un contexte supplémentaire sur le fichier. Les analystes peuvent créer des règles de moteur de détection qui interrogent ces données de contexte d'entité pour créer des analyses sensibles au contexte.

Les informations suivantes sont stockées avec l'enregistrement de contexte de l'entité.

Enrichir des entités avec des données WHOIS

Google Security Operations ingère quotidiennement des données WHOIS. Lors de l'ingestion des données entrantes sur les appareils des clients, Google Security Operations compare les domaines des données client aux données WHOIS. En cas de correspondance, Google Security Operations stocke les données WHOIS associées avec l'enregistrement d'entité du domaine. Pour chaque entité, où entity.metadata.entity_type = DOMAIN_NAME, Google Security Operations enrichit l'entité avec des informations provenant de WHOIS.

Google Security Operations renseigne les données WHOIS enrichies dans les champs suivants de l'enregistrement de l'entité:

• 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

Pour en savoir plus sur ces champs, consultez le document de liste des champs du modèle de données unifié.

Ingérer et stocker des données Google Cloud Threat Intelligence

Google Security Operations ingère des données provenant de sources de données Google Cloud Threat Intelligence (GCTI) qui vous fournissent des informations contextuelles que vous pouvez utiliser pour examiner l'activité dans votre environnement. Vous pouvez interroger les sources de données suivantes:

• Nœuds de sortie Tor GCTI: adresses IP connues comme étant des nœuds de sortie Tor.
• Binaires bénins GCTI: 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ème d'exploitation officiels qui ont été utilisés de manière abusive par un pirate informatique via une activité courante dans les attaques de type "living-off-the-land" sont exclus de cette source de données, comme ceux axés sur les vecteurs d'entrée initiaux.

• Outils d'accès à distance GCTI: fichiers fréquemment utilisés par des acteurs malveillants. Il s'agit généralement d'applications légitimes qui sont parfois utilisées de manière abusive pour se connecter à distance à des systèmes compromis.

  Ces données contextuelles sont stockées globalement en tant qu'entités. Vous pouvez interroger les données à l'aide des 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 Cloud Threat Intelligence

• graph.metadata.product_name = GCTI Feed

Dans ce document, l'espace réservé <variable_name> représente le nom de variable unique utilisé dans une règle pour identifier un enregistrement UDM.

Sources de données Google Cloud Threat Intelligence limitées dans le temps et intemporelles

Les sources de données Google Cloud Threat Intelligence sont temporelles ou intemporelles.

Les sources de données temporelles ont une plage temporelle associée à chaque entrée. Cela signifie que si une détection est générée le jour 1, la même détection doit être générée pour le jour 1 lors d'une recherche rétrospective, quel que soit le jour.

Aucune période n'est associée aux sources de données intemporelles. En effet, seul le dernier ensemble de données doit être pris en compte. Les sources de données intemporelles sont fréquemment utilisées pour les données telles que les hachages de fichiers qui ne devraient pas changer. Si aucune détection n'est générée le jour 1, une détection peut être générée pour le jour 1 lors d'une recherche rétrospective, car une nouvelle entrée a été ajoutée.

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

Google Security Operations ingère et stocke les adresses IP connues comme étant des nœuds de sortie Tor. Les nœuds de sortie Tor sont les points au niveau desquels le trafic quitte le réseau Tor. Les informations ingérées à partir de cette source de données sont stockées dans les champs UDM suivants. Les données de cette source sont chronométrées.

Données sur les fichiers du système d'exploitation inoffensifs

Google Security Operations ingère et stocke les hachages de fichiers de la source de données de binaires bénins GCTI. Les informations ingérées à partir de cette source de données sont stockées dans les champs UDM suivants. Les données de cette source sont intemporelles.

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

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

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

Google Security Operations enrichit les hachages de fichiers dans les événements UDM et fournit un contexte supplémentaire lors d'une enquête. Les événements UDM sont enrichis par l'aliasing de hachage dans un environnement client. L'aliasing de hachage combine tous les types de hachage de fichiers et fournit des informations sur un hachage de fichier lors d'une recherche.

L'intégration des métadonnées de fichier VirusTotal et l'enrichissement des relations avec Google SecOps peuvent être utilisés pour identifier les tendances d'activité malveillante et pour suivre les mouvements des 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 pour fournir un vidage des hachages incorrects, ainsi que des métadonnées sur le fichier incorrect. Les métadonnées incluent des informations telles que les noms de fichiers, les types, les fonctions importées et les balises. 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 incorrects et, en général, lors de la recherche de menaces. Un exemple de cas d'utilisation consiste à détecter toute modification apportée au fichier d'origine, qui importerait ensuite 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 du modèle de données unifié, consultez la section Liste des champs du modèle de données unifié.