So reichert Google Security Operations Ereignis- und Entitätsdaten an

In diesem Dokument wird beschrieben, wie Google Security Operations Daten und die Felder des Unified Data Model (UDM), in denen die Daten gespeichert sind, anreichert.

Für eine Sicherheitsprüfung nimmt Google Security Operations Kontextdaten aus verschiedenen Quellen auf, analysiert die Daten und stellt zusätzlichen Kontext zu Artefakten in einer Kundenumgebung bereit. Analysten können kontextbezogene Daten in Detection Engine-Regeln, investigativen Suchen oder Berichten verwenden.

Google Security Operations führt die folgenden Arten der Anreicherung durch:

• Erweitert Entitäten mithilfe des Entitätsdiagramms und der Zusammenführung.
• Berechnet und reichert jede Entität mit einer Prävalenzstatistik an, die ihre Beliebtheit in der Umgebung angibt.
• Damit wird berechnet, wann bestimmte Entitätstypen zum ersten Mal oder zuletzt in der Umgebung erkannt wurden.
• Reicht Entitäten mit Informationen aus Safe Browsing-Bedrohungslisten an
• Ereignisse werden mit Daten zur Standortbestimmung angereichert.
• Reicht Entitäten mit WHOIS-Daten an
• Ereignisse werden mit VirusTotal-Dateimetadaten angereichert.
• Reicht Entitäten mit VirusTotal-Beziehungsdaten an.
• Google Cloud Threat Intelligence-Daten aufnehmen und speichern

Angereicherte Daten aus WHOIS, Safe Browsing, GCTI Threat Intelligence, VirusTotal-Metadaten und der VirusTotal-Beziehung werden durch event_type, product_name und vendor_name identifiziert. Wenn Sie eine Regel erstellen, die diese angereicherten Daten verwendet, sollten Sie einen Filter in die Regel aufnehmen, der den gewünschten Anreicherungstyp angibt. Mit diesem Filter wird die Leistung der Regel verbessert. Fügen Sie beispielsweise die folgenden Filterfelder in den Abschnitt events der Regel ein, mit der WHOIS-Daten zusammengeführt werden.

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

Entitäten mit Entitätsdiagramm und Zusammenführen anreichern

Das Entitätsdiagramm zeigt Beziehungen zwischen Entitäten und Ressourcen in Ihrer Umgebung. Wenn Entitäten aus verschiedenen Quellen in Google Security Operations aufgenommen werden, verwaltet die Entitätsgrafik eine Liste der Nachbarschaften, die auf der Beziehung zwischen den Entitäten basiert. Der Entitätsdiagramm führt zur Kontextanreicherung durch Deduplizierung und Zusammenführung.

Während der Deduplizierung werden redundante Daten entfernt und Intervalle gebildet, um eine gemeinsame Entität zu erstellen. Betrachten Sie beispielsweise die beiden Entitäten e1 und e2 mit den Zeitstempeln t1 und t2. Die Entitäten e1 und e2 werden dedupliziert und die unterschiedlichen Zeitstempel werden bei der Deduplizierung nicht verwendet. Die folgenden Felder werden bei der Deduplizierung nicht verwendet:

• collected_timestamp
• creation_timestamp
• interval

Bei der Zusammenführung werden Beziehungen zwischen Entitäten für ein Zeitintervall von einem Tag gebildet. Angenommen, der Entitätseintrag user A hat Zugriff auf einen Cloud Storage-Bucket. Es gibt einen weiteren Entitätseintrag von user A, der ein Gerät besitzt. Nach dem Zusammenführen ergeben diese beiden Entitäten eine einzelne Entität user A mit zwei Beziehungen. Eine Beziehung besteht darin, dass user A Zugriff auf den Cloud Storage-Bucket hat und die andere, dass user A das Gerät besitzt. Google Security Operations führt beim Erstellen von Entitätskontextdaten ein Lookback-Window von fünf Tagen durch. Damit werden spät ankommende Daten verarbeitet und eine implizite Lebensdauer für Entitätskontextdaten geschaffen.

Google Security Operations verwendet Aliasing, um die Telemetriedaten anzureichern, und Entitätsdiagramme, um die Entitäten anzureichern. Die Erkennungs-Engine-Regeln verbinden die zusammengeführten Entitäten mit den angereicherten Telemetriedaten, um kontextsensitive Analysen bereitzustellen.

Ein Ereignis, das ein Entitätsnomen enthält, wird als Entität betrachtet. Hier sind einige Ereignistypen und die entsprechenden Entitätstypen:

• ASSET_CONTEXT entspricht ASSET.
• RESOURCE_CONTEXT entspricht RESOURCE.
• USER_CONTEXT entspricht USER.
• GROUP_CONTEXT entspricht GROUP.

Das Entitätsdiagramm unterscheidet anhand der Bedrohungsinformationen zwischen kontextbezogenen Daten und Gefahrenindikatoren.

Berücksichtigen Sie bei der Verwendung von kontextbezogenen Daten das folgende Verhalten von Entitätsdiagrammen:

• Fügen Sie der Entität keine Intervalle hinzu und lassen Sie sie stattdessen vom Entitätsdiagramm Intervalle erstellen. Das liegt daran, dass Intervalle während der Deduplizierung generiert werden, sofern nicht anders angegeben.
• Wenn die Intervalle angegeben sind, werden nur dieselben Ereignisse dedupliziert und die letzte Entität wird beibehalten.
• Damit Live-Regeln und RetroHunts wie erwartet funktionieren, müssen Entitäten mindestens einmal täglich aufgenommen werden.
• Wenn Entitäten nicht täglich und nur einmal in zwei oder mehr Tagen aufgenommen werden, funktionieren Liveregeln möglicherweise wie erwartet. Bei Retrohunts kann jedoch der Kontext des Ereignisses verloren gehen.
• Werden Entitäten mehr als einmal täglich aufgenommen, wird die Entität zu einer einzigen Entität dedupliziert.
• Wenn die Ereignisdaten für einen Tag fehlen, werden vorübergehend die Daten des Vortags verwendet, um sicherzustellen, dass die Live-Regeln reibungslos funktionieren.

Im Entitätsdiagramm werden auch Ereignisse mit ähnlichen Kennungen zusammengeführt, um eine konsolidierte Ansicht der Daten zu erhalten. Diese Zusammenführung erfolgt anhand der folgenden Liste von Kennungen:

• 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

Die Prävalenzstatistiken berechnen

Google Security Operations führt statistische Analysen an vorhandenen und eingehenden Daten durch und reichert Entitätskontexteinträge mit prävalenzbezogenen Messwerten an.

Verbreitung ist ein numerischer Wert, der angibt, wie beliebt eine Entität ist. Die Beliebtheit wird durch die Anzahl der Assets definiert, die auf ein Artefakt zugreifen, z. B. eine Domain, einen Datei-Hash oder eine IP-Adresse. Je größer die Zahl, desto beliebter die Entität. google.com hat beispielsweise hohe Werte für die Verbreitung, da häufig auf die Datei zugegriffen wird. Wenn nur selten auf eine Domain zugegriffen wird, hat sie niedrigere Prävalenzwerte. Bei beliebteren Entitäten ist die Wahrscheinlichkeit geringer, dass sie schädlich sind.

Diese angereicherten Werte werden für Domain, IP-Adresse und Datei (Hash) unterstützt. Die Werte werden in den folgenden Feldern berechnet und gespeichert.

Die Verbreitungsstatistiken für jede Entität werden täglich aktualisiert. Werte werden in einem separaten Entitätskontext gespeichert, der von der Detection Engine verwendet werden kann, aber nicht in den Untersuchungsansichten von Google Security Operations und der UDM-Suche angezeigt wird.

Die folgenden Felder können beim Erstellen von Detection Engine-Regeln verwendet werden.

Entitätstyp	UDM-Felder
Domain	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
Datei (Hash)	entity.file.prevalence.day_count entity.file.prevalence.day_max entity.file.prevalence.rolling_max
IP-Adresse	entity.artifact.prevalence.day_count entity.artifact.prevalence.day_max entity.artifact.prevalence.rolling_max

Die Werte für „day_max“ und „rolling_max“ werden unterschiedlich berechnet. Die Felder werden so berechnet:

• day_max wird als maximaler Prävalenzwert für das Artefakt im Laufe des Tages berechnet. Ein Tag ist von 00:00:00 bis 23:59:59 Uhr UTC definiert.
• rolling_max wird als maximaler Prävalenzwert pro Tag (d.h. day_max) für das Artefakt im vorherigen 10-Tage-Fenster berechnet.
• day_count wird zum Berechnen von rolling_max verwendet und ist immer der Wert 10.

Bei der Berechnung für eine Domain sieht der Unterschied zwischen day_max und day_max_sub_domains (und rolling_max im Vergleich zu rolling_max_sub_domains) so aus:

• rolling_max und day_max stehen für die Anzahl der eindeutigen internen IP-Adressen, die pro Tag auf eine bestimmte Domain zugreifen (ohne Subdomains).
• rolling_max_sub_domains und day_max_sub_domains stehen für die Anzahl der eindeutigen internen IP-Adressen, die auf eine bestimmte Domain (einschließlich Subdomains) zugreifen.

Verbreitungsstatistiken werden für neu aufgenommene Entitätsdaten berechnet. Berechnungen werden nicht rückwirkend für zuvor aufgenommene Daten durchgeführt. Es dauert ungefähr 36 Stunden, bis die Statistiken berechnet und gespeichert sind.

Zeitpunkt der ersten und letzten Erfassung von Entitäten berechnen

Google Security Operations führt eine statistische Analyse eingehender Daten durch und reichert Entitätskontextdatensätze mit den zuerst und zuletzt erfassten Zeiten einer Entität an. Im Feld first_seen_time werden Datum und Uhrzeit des ersten Auftretens der Entität in der Kundenumgebung gespeichert. Im Feld last_seen_time werden das Datum und die Uhrzeit der letzten Beobachtung gespeichert.

Da mehrere Indikatoren (UDM-Felder) ein Asset oder einen Nutzer identifizieren können, ist die Ersterkennung das erste Mal, dass ein Indikator zur Identifizierung des Nutzers oder Assets in der Kundenumgebung erkannt wurde.

Alle UDM-Felder, die ein Asset beschreiben, sind:

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

Alle UDM-Felder, die einen Nutzer beschreiben:

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

Anhand der „Erst-Zeit“- und „Zuletzt gesehen“-Zeit kann ein Analyst bestimmte Aktivitäten korrelieren, die aufgetreten sind, nachdem eine Domain, eine Datei (Hash), ein Asset, ein Nutzer oder eine IP-Adresse zum ersten Mal erkannt wurde oder die nicht mehr aktiv waren, nachdem die Domain, Datei (Hash) oder IP-Adresse das letzte Mal gesehen wurde.

Die Felder first_seen_time und last_seen_time werden mit Entitäten gefüllt, die eine Domain, eine IP-Adresse und eine Datei (Hash) beschreiben. Bei Entitäten, die einen Nutzer oder ein Asset beschreiben, wird nur das Feld first_seen_time ausgefüllt. Diese Werte werden nicht für Entitäten berechnet, die andere Typen beschreiben, z. B. eine Gruppe oder Ressource.

Die Statistiken werden für jede Entität in allen Namespaces berechnet. Google Security Operations berechnet nicht die Statistiken für jede Entität innerhalb einzelner Namespaces. Diese Statistiken werden derzeit nicht in das events-Schema von Google Security Operations in BigQuery exportiert.

Die angereicherten Werte werden in den folgenden UDM-Feldern berechnet und gespeichert:

Entitätstyp	UDM-Felder
Domain	entity.domain.first_seen_time entity.domain.last_seen_time
Datei (Hash)	entity.file.first_seen_time entity.file.last_seen_time
IP-Adresse	entity.artifact.first_seen_time entity.artifact.last_seen_time
Asset	entity.asset.first_seen_time
Nutzer	entity.user.first_seen_time

Ereignisse mit Daten zur Standortbestimmung anreichern

Eingehende Logdaten können externe IP-Adressen ohne entsprechende Standortinformationen enthalten. Dies ist häufig der Fall, wenn mit einem Ereignis Informationen zur Geräteaktivität protokolliert werden, die sich nicht in einem Unternehmensnetzwerk befinden. Ein Anmeldeereignis bei einem Cloud-Dienst würde beispielsweise eine Quell- oder Client-IP-Adresse enthalten, die auf der externen IP-Adresse eines Geräts basiert, das von der NAT des Netzbetreibers zurückgegeben wird.

Google Security Operations bietet mit der Standortbestimmung angereicherte Daten für externe IP-Adressen, um eine leistungsstärkere Regelerkennung und mehr Kontext für Untersuchungen zu ermöglichen. Google Security Operations kann beispielsweise eine externe IP-Adresse verwenden, um das Ereignis mit Informationen über das Land (z. B. die USA), einen bestimmten Bundesstaat (z. B. Alaska) und das Netzwerk, in dem sich die IP-Adresse befindet (z. B. ASN und Name des Mobilfunkanbieters), anzureichern.

Google Security Operations verwendet von Google bereitgestellte Standortdaten, um einen ungefähren geografischen Standort und Netzwerkinformationen für eine IP-Adresse bereitzustellen. Sie können Detection Engine-Regeln für diese Felder in den Ereignissen schreiben. Die angereicherten Ereignisdaten werden auch nach BigQuery exportiert, wo sie in Google Security Operations-Dashboards und in der Berichterstellung verwendet werden können.

Die folgenden IP-Adressen werden nicht angereichert:

• Private IP-Adressbereiche nach RFC 1918, da sie sich innerhalb des Unternehmensnetzwerks befinden.
• RFC 5771-Multicast-IP-Adressbereich, da Multicast-Adressen nicht zu einem einzigen Standort gehören.
• Eindeutige lokale IPv6-Adressen.
• IP-Adressen des Google Cloud-Dienstes. Ausnahmen sind externe IP-Adressen von Google Cloud Compute Engine, die angereichert sind.

Google Security Operations reichert die folgenden UDM-Felder mit Daten zur Standortbestimmung an:

• principal
• target
• src
• observer

Datentyp	UDM-Feld
Standort (z. B. Deutschland)	( principal | target | src | observer ).ip_geo_artifact.location.country_or_region
Bundesland (z. B. Hamburg)	( principal | target | src | observer ).ip_geo_artifact.location.state
Längengrad	( principal | target | src | observer ).ip_geo_artifact.location.region_coordinates.longitude
Breitengrad	( principal | target | src | observer ).ip_geo_artifact.location.region_coordinates.latitude
ASN (Nummer des autonomen Systems)	( principal | target | src | observer ).ip_geo_artifact.network.asn
Name des Transportunternehmens	( principal | target | src | observer ).ip_geo_artifact.network.carrier_name
DNS-Domain	( principal | target | src | observer ).ip_geo_artifact.network.dns_domain
Name der Organisation	( principal | target | src | observer ).ip_geo_artifact.network.organization_name

Das folgende Beispiel zeigt den Typ geografischer Informationen, die einem UDM-Ereignis mit einer IP-Adresse mit dem Tag Niederlande hinzugefügt werden:

UDM-Feld	Wert
principal.ip_geo_artifact.location.country_or_region	Netherlands
principal.ip_geo_artifact.location.region_coordinates.latitude	52.132633
principal.ip_geo_artifact.location.region_coordinates.longitude	5.291266
principal.ip_geo_artifact.network.asn	8455
principal.ip_geo_artifact.network.carrier_name	schuberg philis

Unstimmigkeiten

Die proprietäre Technologie von Google zur Standortbestimmung verwendet eine Kombination aus Netzwerkdaten und anderen Eingaben und Methoden, um unseren Nutzern den Standort der IP-Adresse und die Netzwerkauflösung bereitzustellen. Andere Organisationen verwenden möglicherweise andere Signale oder Methoden, was gelegentlich zu unterschiedlichen Ergebnissen führen kann.

Wenn die von Google bereitgestellten Ergebnisse zur Standortbestimmung für IP-Adressen inkonsistent sind, eröffnen Sie bitte eine Kundensupportanfrage, damit wir die Angelegenheit untersuchen und gegebenenfalls unsere Datensätze korrigieren können.

Entitäten mit Informationen aus Safe Browsing-Bedrohungslisten anreichern

Google Security Operations nimmt Daten aus Safe Browsing auf, die mit Datei-Hashes zusammenhängen. Die Daten für jede Datei werden als Entität gespeichert und bieten zusätzlichen Kontext zu der Datei. Analysten können Detection Engine-Regeln erstellen, die diese Entitätskontextdaten abfragen, um kontextsensitive Analysen zu erstellen.

Die folgenden Informationen werden mit dem Entitätskontextdatensatz gespeichert.

UDM-Feld	Beschreibung
entity.metadata.product_entity_id	Eine eindeutige Kennung für die Entität.
entity.metadata.entity_type	Dieser Wert ist FILE. Dies bedeutet, dass die Entität eine Datei beschreibt.
entity.metadata.collected_timestamp	Datum und Uhrzeit, zu der die Entität beobachtet wurde oder das Ereignis aufgetreten ist.
entity.metadata.interval	Speichert die Start- und Endzeit für diese Daten. Da sich der Inhalt der Bedrohungsliste im Laufe der Zeit ändert, geben start_time und end_time das Zeitintervall an, in dem die Daten zur Entität gültig sind. So wurde beispielsweise festgestellt, dass ein Datei-Hash zwischen start_time and end_time. schädlich oder verdächtig war
entity.metadata.threat.category	Dies ist Google Security Operations SecurityCategory. Hierfür ist einer oder mehrere der folgenden Werte festgelegt: SOFTWARE_MALICIOUS: Gibt an, dass die Bedrohung mit Malware zusammenhängt. SOFTWARE_PUA: Gibt an, dass die Bedrohung mit unerwünschter Software zusammenhängt.
entity.metadata.threat.severity	Dies ist Google Security Operations ProductSeverity. Wenn der Wert CRITICAL ist, weist dies darauf hin, dass das Artefakt schädlich zu sein scheint. Wenn kein Wert angegeben ist, ist die Wahrscheinlichkeit nicht hoch genug, um darauf hinzuweisen, dass das Artefakt schädlich ist.
entity.metadata.product_name	Speichert den Wert Google Safe Browsing.
entity.file.sha256	SHA-256-Hashwert für die Datei.

Entitäten mit WHOIS-Daten anreichern

Google Security Operations nimmt WHOIS-Daten täglich auf. Bei der Aufnahme eingehender Kundengerätedaten wertet Google Security Operations Domains in Kundendaten anhand der WHOIS-Daten aus. Bei einer Übereinstimmung speichert Google Security Operations die zugehörigen WHOIS-Daten im Entitätseintrag für die Domain. Für jede Entität mit entity.metadata.entity_type = DOMAIN_NAME reichert Google Security Operations die Entität mit Informationen aus WHOIS an.

Google Security Operations fügt angereicherte WHOIS-Daten in die folgenden Felder des Entitätseintrags ein:

• 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

Eine Beschreibung dieser Felder finden Sie im Dokument mit Liste der Felder vom einheitlichen Datenmodell.

Google Cloud Threat Intelligence-Daten aufnehmen und speichern

Google Security Operations nimmt Daten aus Google Cloud Threat Intelligence-Datenquellen (GCTI) auf. Diese liefern Ihnen Kontextinformationen, die Sie bei der Untersuchung von Aktivitäten in Ihrer Umgebung verwenden können. Sie können die folgenden Datenquellen abfragen:

• GCTI Tor-Exit-Knoten: IP-Adressen, die als Tor-Exit-Knoten bezeichnet werden.
• Benign Binaries (GCTI): Dateien, die entweder Teil der ursprünglichen Distribution des Betriebssystems sind oder durch einen offiziellen Betriebssystempatch aktualisiert wurden. Einige offizielle Binärprogramme des Betriebssystems, die von einem Angreifer durch Aktivitäten missbraucht wurden, die bei Living-off-the-Land-Angriffen üblich sind, sind von dieser Datenquelle ausgeschlossen. Dazu gehören z. B. die Angriffsvektoren.

• GCTI Remote Access Tools: Dateien, die häufig von böswilligen Akteuren verwendet werden Diese Tools sind in der Regel legitime Anwendungen, die manchmal missbraucht werden, um eine Remote-Verbindung zu manipulierten Systemen herzustellen.

  Diese kontextbezogenen Daten werden global als Entitäten gespeichert. Sie können die Daten mithilfe von Erkennungsmodulregeln abfragen. Nehmen Sie die folgenden UDM-Felder und -Werte in die Regel auf, um diese globalen Entitäten abzufragen:

• graph.metadata.vendor_name = Google Cloud Threat Intelligence

• graph.metadata.product_name = GCTI Feed

In diesem Dokument steht der Platzhalter <variable_name> für den eindeutigen Variablennamen, der in einer Regel zur Identifizierung eines UDM-Eintrags verwendet wird.

Zeitgesteuerte vs. zeitlose Google Cloud Threat Intelligence-Datenquellen

Google Cloud Threat Intelligence-Datenquellen sind entweder zeitlich festgelegt oder zeitlos.

Bei zeitgesteuerten Datenquellen ist jedem Eintrag ein Zeitraum zugeordnet. Wenn also an Tag 1 eine Erkennung generiert wird, wird voraussichtlich an einem beliebigen Tag in der Zukunft dieselbe Erkennung für Tag 1 während einer Retro-Jagd ausgeführt.

Zeitlosen Datenquellen ist kein Zeitraum zugeordnet. Dies liegt daran, dass nur der neueste Datensatz berücksichtigt werden sollte. Zeitlose Datenquellen werden häufig für Daten wie Datei-Hashes verwendet, die sich in der Regel nicht ändern. Wenn an Tag 1 keine Erkennung erfolgt, wird an Tag 2 während einer Retro-Hunt eine Erkennung für Tag 1 generiert, da ein neuer Eintrag hinzugefügt wurde.

Daten zu IP-Adressen des Tor-Exit-Knotens

Google Security Operations nimmt IP-Adressen auf, die bekannte Tor-Exit-Knoten sind, und speichert sie. Tor-Ausstiegsknoten sind Punkte, an denen der Traffic das Tor-Netzwerk verlässt. Aus dieser Datenquelle aufgenommene Informationen werden in den folgenden UDM-Feldern gespeichert. Daten in dieser Quelle sind zeitlich festgelegt.

UDM-Feld	Beschreibung
<variable_name>.graph.metadata.vendor_name	Speichert den Wert Google Cloud Threat Intelligence.
<variable_name>.graph.metadata.product_name	Speichert den Wert GCTI Feed.
<variable_name>.graph.metadata.threat.threat_feed_name	Speichert den Wert Tor Exit Nodes.
<variable_name>.graph.entity.artifact.ip	Speichert die aus der GCTI-Datenquelle aufgenommene IP-Adresse.

Daten zu harmlosen Betriebssystemdateien

Google Security Operations nimmt Datei-Hashes aus der GCTI Benign Binaries-Datenquelle auf und speichert sie. Aus dieser Datenquelle aufgenommene Informationen werden in den folgenden UDM-Feldern gespeichert. Die Daten in dieser Quelle sind zeitlos.

UDM-Feld	Beschreibung
<variable_name>.graph.metadata.vendor_name	Speichert den Wert Google Cloud Threat Intelligence.
<variable_name>.graph.metadata.product_name	Speichert den Wert GCTI Feed.
<variable_name>.graph.metadata.threat.threat_feed_name	Speichert den Wert Benign Binaries.
<variable_name>.graph.entity.file.sha256	Speichert den SHA256-Hashwert der Datei.
<variable_name>.graph.entity.file.sha1	Speichert den SHA1-Hash-Wert der Datei.
<variable_name>.graph.entity.file.md5	Speichert den MD5-Hashwert der Datei.

Daten zu Tools für den Remotezugriff

Dazu gehören Datei-Hashes für bekannte Tools für den Remotezugriff, z. B. VNC-Clients, die häufig von böswilligen Akteuren verwendet werden. Diese Tools sind in der Regel seriöse Anwendungen, die manchmal missbraucht werden, um eine Remote-Verbindung zu manipulierten Systemen herzustellen. Aus dieser Datenquelle aufgenommene Informationen werden in den folgenden UDM-Feldern gespeichert. Die Daten in dieser Quelle sind zeitlos.

UDM-Feld	Beschreibung
.graph.metadata.vendor_name	Speichert den Wert Google Cloud Threat Intelligence.
.graph.metadata.product_name	Speichert den Wert GCTI Feed.
.graph.metadata.threat.threat_feed_name	Speichert den Wert Remote Access Tools.
.graph.entity.file.sha256	Speichert den SHA256-Hashwert der Datei.
.graph.entity.file.sha1	Speichert den SHA1-Hash-Wert der Datei.
graph.entity.file.md5	Speichert den MD5-Hashwert der Datei.

Ereignisse mit VirusTotal-Dateimetadaten anreichern

Google Security Operations reichert Datei-Hashes in UDM-Ereignisse an und bietet während einer Prüfung zusätzlichen Kontext. UDM-Ereignisse werden durch Hash-Aliasing in einer Kundenumgebung angereichert. Beim Hash-Aliasing werden alle Arten von Datei-Hashes kombiniert und Informationen zu einem Datei-Hash bei einer Suche bereitgestellt.

Durch die Einbindung der VirusTotal-Dateimetadaten und zur Anreicherung von Beziehungen in Google SecOps können Muster schädlicher Aktivitätsmuster identifiziert und Malwarebewegungen in einem Netzwerk verfolgt werden.

Ein Rohprotokoll liefert begrenzte Informationen über die Datei. VirusTotal reichert das Ereignis mit Dateimetadaten an, um einen Dump fehlerhafter Hashes zusammen mit Metadaten zur fehlerhaften Datei bereitzustellen. Die Metadaten enthalten Informationen wie Dateinamen, Typen, importierte Funktionen und Tags. Sie können diese Informationen in der UDM-Such- und Erkennungs-Engine mit YARA-L verwenden, um ungültige Dateiereignisse und im Allgemeinen während der Spurensuche zu verstehen. Ein Anwendungsbeispiel besteht darin, Änderungen an der Originaldatei zu erkennen, die wiederum die Dateimetadaten zur Bedrohungserkennung importieren würden.

Die folgenden Informationen werden mit dem Eintrag gespeichert. Eine Liste aller UDM-Felder finden Sie in der Liste der Felder des einheitlichen Datenmodells.