Übersicht über Alias- und UDM-Anreicherung in Google Security Operations

Unterstützt in:

Dieses Dokument bietet einen Überblick über die Aliasbildung und UDM-Anreicherung in Google Security Operations. Darin werden gängige Anwendungsfälle beschrieben und es wird erläutert, wie Aliasing und Anreicherung auf der Plattform funktionieren.

Aliasing und UDM-Anreicherung sind wichtige Konzepte in Google SecOps. Sie arbeiten zusammen, dienen aber unterschiedlichen Zwecken.

  • Aliasing bezieht sich auf die verschiedenen Namen und zusätzlichen Kontextdaten, die einen Indikator beschreiben.
  • Bei der Anreicherung wird Aliasing verwendet, um einem UDM-Ereignis Kontext hinzuzufügen.

Ein UDM-Ereignis enthält beispielsweise den Hostnamen alex-macbook und gibt an, dass ein Hash einer schädlichen Datei vom Nutzer alex ausgeführt wurde. Durch die Verwendung von Aliasing stellen wir fest, dass dem Hostnamen alex-macbook zum Zeitpunkt des Ereignisses die IP-Adresse 192.0.2.0 zugewiesen wurde und dass alex das Unternehmen in zwei Wochen verlässt. Durch das Einbinden dieser Aliase in das ursprüngliche UDM-Ereignis wird Kontext hinzugefügt.

Unterstützte Aliasing- und Anreicherungsfunktionen

Google SecOps unterstützt Aliasing und Anreicherung für Folgendes:

  • Assets
  • Nutzer
  • Prozesse
  • Metadaten für Datei-Hash
  • Standorte
  • Cloud-Ressourcen

So funktioniert die Aliasierung

Durch Aliasing wird die Anreicherung ermöglicht. Mithilfe von Aliasing können Sie beispielsweise andere IP-Adressen und MAC-Adressen finden, die mit einem Hostnamen verknüpft sind, oder die Stellenbezeichnung und den Beschäftigungsstatus, die mit einer Nutzer-ID verknüpft sind.

Wie bei anderen Funktionen in Google SecOps müssen Daten für die Aliasierung aufgenommen und indexiert werden. Die Alias-Funktion ist in drei Hauptkategorien unterteilt:

  • Kundenspezifische Daten: Daten, die für einen Kunden eindeutig sind. Beispiel: Nur Aristocrat kann Daten für amal@aristocrat.com bereitstellen. Zu den kundenspezifischen Alias-Typen gehören Assets, Nutzer und Prozesse.
  • Globale Daten: Aufgenommene und indexierte Daten, die für alle Kunden gelten. So kann beispielsweise ein weltweit ermittelter Hinweis auf eine schädliche Datei verwendet werden, um zu prüfen, ob diese Datei in Ihrem Unternehmen vorhanden ist.
  • Drittanbieterdienst: Aliasing durch einen Drittanbieterdienst. Google SecOps verwendet geografische Dienste, um den physischen Standort von IP-Adressen zu ermitteln.

Diese Arten von Aliasen werden zusammen verwendet, um Aliasierungsergebnisse für Assets zu generieren.

Asset-Aliasing

Beim Asset-Aliasing werden Hostnamen, IP-Adressen, MAC-Adressen, Asset-IDs und andere Metadaten verknüpft. Dazu sind folgende Schritte erforderlich:

  • EDR-Aliasing: Ordnet Produkt-IDs (Asset-IDs) Hostnamen zu. EDR-Zuordnungsfelder werden ausschließlich aus dem Logtyp CS_EDR abgeleitet.
  • DHCP-Aliasing: Hier werden DHCP-Ereignisse verwendet, um Hostnamen, MAC-Adressen und IP-Adressen zu verknüpfen.
  • Alias für Asset-Kontext: Ordnet einen Asset-Indikator Entitätsdaten zu, z. B. Hostname, IP-Adresse, MAC-Adresse, Softwareversion und Bereitstellungsstatus.

Indexierte Felder für die EDR-Zuordnung

Google SecOps indexiert EDR MAPPING-Felder, um Aliase zu generieren, die Hostnamen und produktspezifische IDs verknüpfen.

In der folgenden Tabelle sind die UDM-Felder und die entsprechenden Indikatortypen aufgeführt:

UDM-Feld Indikatortyp
principal.hostname und principal.asset.hostname HOSTNAME
principal.asset_id und principal.asset.asset_id PRODUCT_SPECIFIC_ID

DHCP-indexierte Felder

Google SecOps indexiert DHCP-Einträge, um Aliase zu generieren, die Hostnamen, IP-Adressen und MAC-Adressen verknüpfen.

In der folgenden Tabelle sind die UDM-Felder und die entsprechenden Indikatortypen aufgeführt, die für die Aliasbildung von Assets verwendet werden:

UDM-Feld Indikatortyp
principal.ip und principal.asset.ip ASSET_IP_ADDRESS
principal.mac und principal.asset.mac MAC
principal.hostname und principal.asset.hostname HOSTNAME
principal.asset_id und principal.asset.asset_id PRODUCT_SPECIFIC_ID
network.dhcp.yiaddr bei ACK, OFFER, WIN_DELETED und WIN_EXPIRED ASSET_IP_ADDRESS
network.dhcp.ciaddr bei INFORM, RELEASE und REQUEST ASSET_IP_ADDRESS
network.dhcp.requested_address bei DECLINE ASSET_IP_ADDRESS
network.dhcp.chaddr MAC
network.dhcp.client_hostname HOSTNAME

Indexierte Felder für Asset-Kontext

In Google SecOps werden ASSET_CONTEXT-Ereignisse als Ereignisse mit Entitätskontext und nicht als UDM-Ereignisse aufgenommen.

In der folgenden Tabelle sind die Entitätsfelder und die entsprechenden Indikatortypen aufgeführt:

Entitätsfeld Indikatortyp
entity.asset.product_object_id PRODUCT_OBJECT_ID
entity.metadata.product_entity_id (wenn die Produktobjekt-ID für den Vermögenswert fehlt) 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

Nutzer-Aliasing

Beim User-Aliasing werden Informationen anhand eines Nutzerindikators ermittelt. Wenn Sie beispielsweise die E‑Mail-Adresse eines Mitarbeiters verwenden, können Sie weitere Details zu diesem Mitarbeiter finden, z. B. seinen Namen, seine Stellenbezeichnung und seinen Beschäftigungsstatus. Beim User-Aliasing wird der Ereignisbatchtyp USER_CONTEXT verwendet.

Indexierte Felder für Nutzerkontext

In Google SecOps werden USER_CONTEXT-Ereignisse als Ereignisse mit Entitätskontext und nicht als UDM-Ereignisse aufgenommen.

In der folgenden Tabelle sind die Entitätsfelder und die entsprechenden Indikatortypen aufgeführt:

Entitätsfeld Indikatortyp
entity.user.product_object_id PRODUCT_OBJECT_ID
entity.metadata.product_entity_id (wenn die ID des Nutzerproduktobjekts fehlt) 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

Prozess-Aliasing

Bei der Prozessaliasierung wird eine produktspezifische Prozess-ID (product_specific_process_id) dem tatsächlichen Prozess zugeordnet und es werden Informationen zum übergeordneten Prozess abgerufen. Beim Alias-Prozess wird der EDR-Ereignisbatchtyp für die Alias-Erstellung verwendet.

EDR-indexierte Felder für die Prozessaliasierung

Wenn ein Prozess gestartet wird, werden Metadaten wie Befehlszeilen, Dateihashes und Details zum übergeordneten Prozess erfasst. Die auf dem Computer ausgeführte EDR-Software weist eine anbieterspezifische Prozess-UUID zu.

In der folgenden Tabelle sind die Felder aufgeführt, die bei einem Prozessstart-Ereignis indexiert werden:

UDM-Feld Indikatortyp
target.product_specific_process_id PROCESS_ID
target.process Gesamter Prozess, nicht nur der Indikator

Zusätzlich zum Feld target.process aus dem normalisierten Ereignis erfasst und indexiert Google SecOps auch Informationen zum übergeordneten Prozess.

Alias für Dateihash-Metadaten

Beim Aliasing von Datei-Hash-Metadaten werden Dateimetadaten wie andere Datei-Hashes oder Dateigrößen anhand eines bestimmten Datei-Hashs (SHA256, SHA1 oder MD5) identifiziert. Für das Aliasing von Metadaten für Dateihashes wird der Ereignisbatchtyp FILE_CONTEXT verwendet.

Indexierte Felder für Dateikontext

Google SecOps erfasst FILE_CONTEXT-Ereignisse von VirusTotal als Entitätskontext-Ereignisse. Diese Ereignisse sind global und nicht kundenspezifisch.

In der folgenden Tabelle sind die indexierten Entitätsfelder und die entsprechenden Indikatortypen aufgeführt:

Entitätsfeld Indikatortyp
entity.file.sha256 PRODUCT_OBJECT_ID
entity.metadata.product_entity_id (wenn die Datei sha256 fehlt) PRODUCT_OBJECT_ID
entity.file.md5 HASH_MD5
entity.file.sha1 HASH_SHA1
entity.file.sha256 HASH_SHA256
entity.namespace NAMESPACE

IP-Standortbestimmung mit Alias

Durch geografisches Aliasing werden Daten mit Geolocation-Informationen für externe IP-Adressen bereitgestellt. Für jede IP-Adresse im Feld principal, target oder src für ein UDM-Ereignis wird, sofern die Adresse nicht aliasiert ist, ein ip_geo_artifact-Unterprotokoll mit den zugehörigen Standort- und ASN-Informationen erstellt.

Beim geografischen Aliasing werden keine Lookback- oder Caching-Methoden verwendet. Aufgrund der großen Anzahl von Ereignissen führt Google SecOps einen Index im Arbeitsspeicher. Der Index basiert auf dem IPGeo simple server MPM und wird alle zwei Wochen aktualisiert.

Alias-Ressourcen

Beim Resource Aliasing werden Informationen zu Cloud-Ressourcen für eine bestimmte Ressourcen-ID zurückgegeben. Beispielsweise können Informationen für eine Bigtable-Instanz mithilfe ihres Google Cloud -URI zurückgegeben werden. Es werden weder Lookback noch Caching verwendet.

Durch die Aliasbildung von Ressourcen werden UDM-Ereignisse nicht angereichert. Bei einigen Produkten, z. B. Alert Graph, wird jedoch Resource Aliasing verwendet. Für Cloud-Ressourcen-Aliasing wird der Ereignisbatchtyp RESOURCE_CONTEXT verwendet.

Indexierte Felder für Ressourcenkontext

Kontext-Ereignisse für Metadaten von Cloud-Ressourcen werden als RESOURCE_CONTEXT-Ereignisse erfasst.

In der folgenden Tabelle sind die Entitätsfelder und die entsprechenden Entitätstypen aufgeführt:

Entitätsfeld Indikatortyp
entity.resource.product_object_id PRODUCT_OBJECT_ID
entity.metadata.product_entity_id (wenn die Produktobjekt-ID für die Ressource fehlt) PRODUCT_OBJECT_ID
entity.resource.name CLOUD_RESOURCE_NAME
entity.namespace NAMESPACE

Anreichern

Beim Anreichern werden Aliase verwendet, um einem UDM-Indikator oder ‑Ereignis auf folgende Weise Kontext hinzuzufügen:

  • Kennzeichnet Alias-Entitäten, die einen Indikator beschreiben, in der Regel ein UDM-Feld.
  • Füllt die zugehörigen Teile der UDM-Nachricht mit angereicherten Werten aus, die mit den zurückgegebenen Aliasen oder Entitäten verknüpft sind.

Asset-Anreicherung

Für jedes UDM-Ereignis werden von der Pipeline die folgenden UDM-Felder aus den Entitäten principal, src und target extrahiert:

UDM-Feld Indikatortyp
hostname HOSTNAME
asset_id PRODUCT_SPECIFIC_ID
Mac MAC
ip (IFF asset_id ist leer) IP

Jeder Asset-Indikator hat einen Namespace. Der leere Namespace wird als gültig behandelt. Für jeden Asset-Indikator führt die Pipeline die folgenden Aktionen aus:

  • Ruft die Aliase für den gesamten Tag der Ereigniszeit ab.
  • Erstellt eine backstory.Asset-Nachricht aus der Aliasierungsantwort.
  • Ordnet jedem Substantivtyp und Indikator eine backstory.Asset-Nachricht zu und führt alle zugehörigen Protos zusammen.
  • Legt die Asset-Felder der obersten Ebene und die asset-Protonachricht mit der zusammengeführten backstory.Asset-Nachricht fest.

Nutzeranreicherung

Für jedes UDM-Ereignis werden mit der Pipeline die folgenden UDM-Felder aus principal, src und target extrahiert:

UDM-Feld Indikatortyp
email_addresses EMAIL
userid USERNAME
windows_sid WINDOWS_SID
employee_id EMPLOYEE_ID
product_object_id PRODUCT_OBJECT_ID

Für jeden Indikator führt die Pipeline die folgenden Aktionen aus:

  • Ruft eine Liste von Nutzerentitäten ab. Beispiel: Die Entitäten von principal.email_address und principal.userid können identisch oder unterschiedlich sein.
  • Wählt die Aliase aus dem besten Indikatortyp aus. Die Priorität ist dabei: WINDOWS_SID, EMAIL, USERNAME, EMPLOYEE_ID und PRODUCT_OBJECT_ID.
  • Füllt noun.user mit der Entität aus, deren Gültigkeitszeitraum sich mit der Ereigniszeit überschneidet.

Prozessanreicherung

Für jedes UDM-Ereignis werden process.product_specific_process_id (PSPI) aus den folgenden Feldern extrahiert:

  • principal
  • src
  • target
  • principal.process.parent_process
  • src.process.parent_process
  • target.process.parent_process

Die Pipeline ermittelt dann den tatsächlichen Prozess aus dem PSPI mithilfe von Prozessaliasen. Dabei werden auch Informationen zum übergeordneten Prozess zurückgegeben. Diese Daten werden in das zugehörige Feld noun.process in der angereicherten Nachricht eingefügt.

Artefaktanreicherung

Bei der Artefaktanreicherung werden Metadaten für Dateihashes von VirusTotal und IP-Standorte aus Geolocation-Daten hinzugefügt. Für jedes UDM-Ereignis werden mit der Pipeline Kontextdaten für diese Artefaktindikatoren aus den Entitäten principal, src und target extrahiert und abgefragt:

  • IP-Adresse: Es werden nur Daten abgefragt, wenn sie öffentlich oder routingfähig sind.
  • Datei-Hashes: Hashes werden in der folgenden Reihenfolge abgefragt:
    • file.sha256
    • file.sha1
    • file.md5
    • process.file.sha256
    • process.file.sha1
    • process.file.md5

In der Pipeline werden die UNIX-Epoche und die Ereigniszeit verwendet, um den Zeitraum für die Dateiartefakt-Abfragen zu definieren. Wenn die Daten zur geografischen Position verfügbar sind, werden die folgenden UDM-Felder für die entsprechenden principal, src und target überschrieben, je nachdem, woher die Daten zur geografischen Position stammen:

  • artifact.ip
  • artifact.location
  • artifact.network (nur, wenn die Daten den IP-Netzwerkkontext enthalten)
  • location (nur, wenn die Originaldaten dieses Feld nicht enthalten)

Wenn in der Pipeline Metadaten zum Dateihash gefunden werden, werden diese Metadaten der Datei oder den Feldern process.file hinzugefügt, je nachdem, woher der Indikator stammt. In der Pipeline werden alle vorhandenen Werte beibehalten, die sich nicht mit den neuen Daten überschneiden.

Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten