So reichert Google SecOps Ereignis- und Entitätsdaten an

In diesem Dokument wird beschrieben, wie Google Security Operations Daten anreichert und in welchen Feldern des einheitlichen Datenmodells (Unified Data Model, UDM) Daten gespeichert werden.

Um eine Sicherheitsuntersuchung zu ermöglichen, nimmt Google SecOps Kontextdaten aus verschiedenen Quellen auf, analysiert die Daten und stellt zusätzlichen Kontext zu Artefakten in einer Kundenumgebung bereit. Analysten können kontextbezogen angereicherte Daten in Detection Engine-Regeln, Untersuchungsrecherchen oder Berichten verwenden.

Google SecOps führt die folgenden Arten von Anreicherung durch:

• Entitäten werden mithilfe des Entitätengraphen und durch Zusammenführen angereichert.
• Berechnet für jede Entität eine Statistik zur Häufigkeit, die angibt, wie beliebt sie in der Umgebung ist, und reichert die Entität damit an.
• Berechnet, wann bestimmte Entitätstypen zum ersten oder letzten Mal in der Umgebung gesehen wurden.
• Reichert Entitäten mit Informationen aus den Safe Browsing-Bedrohungslisten an.
• Ereignisse werden mit Daten zur geografischen Position angereichert.
• Reichert Entitäten mit WHOIS-Daten an.
• Reichert Ereignisse mit VirusTotal-Dateimetadaten an.
• Reichert 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 VirusTotal-Beziehungen werden durch entity_type, product_name und vendor_name gekennzeichnet. Wenn Sie eine Regel erstellen, in der diese angereicherten Daten verwendet werden, empfehlen wir, einen Filter in die Regel aufzunehmen, der den einzuschließenden Anreicherungstyp angibt. Dieser Filter trägt dazu bei, die Leistung der Regel zu verbessern. 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 mithilfe des Entitätengraphen und des Zusammenführens anreichern

Im Entitätsdiagramm werden Beziehungen zwischen Entitäten und Ressourcen in Ihrer Umgebung dargestellt. Wenn Entitäten aus verschiedenen Quellen in Google SecOps aufgenommen werden, wird im Entitätendiagramm eine Adjazenzliste basierend auf der Beziehung zwischen den Entitäten geführt. Im Entitätsdiagramm wird der Kontext durch Deduplizierung und Zusammenführung angereichert.

Bei der Deduplizierung werden redundante Daten entfernt und Intervalle gebildet, um eine gemeinsame Einheit zu erstellen. Angenommen, Sie haben zwei Einheiten e1 und e2 mit den Zeitstempeln t1 bzw. t2. Die Entitäten e1 und e2 werden dedupliziert. Die Zeitstempel, die sich unterscheiden, werden bei der Deduplizierung nicht verwendet. Die folgenden Felder werden bei der Deduplizierung nicht verwendet:

• collected_timestamp
• creation_timestamp
• interval

Beim Zusammenführen werden Beziehungen zwischen Entitäten für ein Zeitintervall von einem Tag gebildet. Nehmen wir als Beispiel einen Entitätsdatensatz von user A an, der Zugriff auf einen Cloud Storage-Bucket hat. Es gibt einen weiteren Entitätseintrag für user A, der ein Gerät besitzt. Nach dem Zusammenführen ergibt sich aus diesen beiden Entitäten eine einzelne Entität user A mit zwei Beziehungen. Eine Beziehung ist, dass user A Zugriff auf den Cloud Storage-Bucket hat, und die andere Beziehung ist, dass user A das Gerät besitzt. Google SecOps führt einen fünftägigen Rückblick durch, wenn Kontextdaten für Entitäten erstellt werden. So werden verspätet eingehende Daten verarbeitet und eine implizite Gültigkeitsdauer für Kontextdaten von Entitäten erstellt.

Google SecOps verwendet Aliasing, um die Telemetriedaten anzureichern, und Entity-Diagramme, um die Entitäten anzureichern. Die Regeln der Erkennungs-Engine werden mit den zusammengeführten Einheiten und den angereicherten Telemetriedaten verknüpft, um kontextbezogene Analysen zu ermöglichen.

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

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

Im Entity-Diagramm wird anhand der Bedrohungsdaten zwischen Kontextdaten und Indikatoren für Kompromittierung (Indicators of Compromise, IOC) unterschieden.

Wenn Sie kontextbezogen angereicherte Daten verwenden, sollten Sie das folgende Verhalten des Entity-Graphen berücksichtigen:

• Fügen Sie keine Intervalle in das Objekt ein, sondern lassen Sie sie vom Objektgraphen erstellen. Das liegt daran, dass Intervalle während der Deduplizierung generiert werden, sofern nichts anderes angegeben ist.
• Wenn die Intervalle angegeben sind, werden nur dieselben Ereignisse dedupliziert und die letzte Einheit 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, sondern nur alle zwei oder mehr Tage aufgenommen werden, funktionieren Live-Regeln möglicherweise wie erwartet, bei Retro-Suchen geht jedoch möglicherweise der Kontext des Ereignisses verloren.
• Wenn Entitäten mehrmals täglich aufgenommen werden, wird die Entität dedupliziert.
• Wenn die Ereignisdaten für einen Tag fehlen, werden vorübergehend die Daten des Vortags verwendet, damit Live-Regeln ordnungsgemäß funktionieren.

Im Entity-Diagramm werden auch Ereignisse mit ähnlichen Kennungen zusammengeführt, um eine konsolidierte Ansicht der Daten zu erhalten. Die 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

Statistiken zur Prävalenz berechnen

Google SecOps führt statistische Analysen für vorhandene und eingehende Daten durch und reichert Datensätze zum Kontext von Entitäten mit Häufigkeitsmesswerten an.

Die Häufigkeit 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 Dateihash oder eine IP-Adresse. Je größer die Zahl, desto beliebter die Entität. google.com hat beispielsweise hohe Prävalenzwerte, weil häufig darauf zugegriffen wird. Wenn auf eine Domain nur selten zugegriffen wird, sind die Häufigkeitswerte niedriger. Beliebte Entitäten sind in der Regel weniger wahrscheinlich schädlich.

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

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

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

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

• day_max wird als maximale Prävalenzpunktzahl für das Artefakt während des Tages berechnet. Ein Tag wird als 00:00:00 – 23:59:59 Uhr UTC definiert.
• rolling_max wird als maximaler Wert für die Häufigkeit pro Tag (d.h. day_max) für das Artefakt im vorherigen 10‑Tages-Zeitraum berechnet.
• day_count wird zur Berechnung von rolling_max verwendet und hat immer den Wert 10.

Wenn die Werte für eine Domain berechnet werden, ergibt sich folgender Unterschied zwischen day_max und day_max_sub_domains (sowie zwischen rolling_max und rolling_max_sub_domains):

• rolling_max und day_max stehen für die Anzahl der eindeutigen internen IP-Adressen, die täglich auf eine bestimmte Domain (ohne Subdomains) zugreifen.
• 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.

Die Statistiken zur Häufigkeit werden anhand neu aufgenommener Entitätsdaten berechnet. Berechnungen werden nicht rückwirkend für zuvor aufgenommene Daten durchgeführt. Es dauert etwa 36 Stunden, bis die Statistiken berechnet und gespeichert werden.

Zeitpunkt des ersten und letzten Auftretens von Entitäten berechnen

Google SecOps führt statistische Analysen für eingehende Daten durch und reichert Datensätze zum Entitätskontext mit den Zeitpunkten an, zu denen eine Entität zum ersten und letzten Mal gesehen wurde. Im Feld first_seen_time wird das Datum und die Uhrzeit gespeichert, zu der die Einheit zum ersten Mal in der Kundenumgebung gesehen wurde. Im Feld last_seen_time werden Datum und Uhrzeit der letzten Beobachtung gespeichert.

Da ein Asset oder ein Nutzer anhand mehrerer Indikatoren (UDM-Felder) identifiziert werden kann, ist die „First Seen Time“ der Zeitpunkt, zu dem einer der Indikatoren, mit denen der Nutzer oder das Asset identifiziert wird, zum ersten Mal in der Kundenumgebung gesehen 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, sind:

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

Mit der Zeitangabe für das erste und letzte Auftreten kann ein Analyst bestimmte Aktivitäten korrelieren, die nach dem ersten Auftreten einer Domain, Datei (Hash), eines Assets, Nutzers oder einer IP-Adresse stattgefunden haben oder die nach dem letzten Auftreten der Domain, Datei (Hash) oder IP-Adresse nicht mehr stattgefunden haben.

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 Einheiten, 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 wie eine Gruppe oder Ressource beschreiben.

Die Statistiken werden für jede Entität in allen Namespaces berechnet. Google SecOps berechnet die Statistiken nicht für jede Einheit in einzelnen Namespaces. Diese Statistiken werden derzeit nicht in das Google SecOps-Schema events in BigQuery exportiert.

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

Ereignisse mit Standortdaten anreichern

Eingehende Logdaten können externe IP-Adressen ohne entsprechende Standortinformationen enthalten. Das ist häufig der Fall, wenn bei einem Ereignis Informationen zu Geräteaktivitäten protokolliert werden, die nicht in einem Unternehmensnetzwerk stattfinden. Ein Anmeldeereignis bei einem Clouddienst würde beispielsweise eine Quell- oder Client-IP-Adresse enthalten, die auf der externen IP-Adresse eines Geräts basiert, die von Carrier-NAT zurückgegeben wird.

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

Google SecOps verwendet von Google bereitgestellte Standortdaten, um einen ungefähren geografischen Standort und Netzwerkinformationen für eine IP-Adresse anzugeben. 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 SecOps-Dashboards und -Berichten verwendet werden können.

Die folgenden IP-Adressen werden nicht angereichert:

• Private IP-Adressbereiche gemäß RFC 1918, da sie intern im Unternehmensnetzwerk verwendet werden.
• RFC 5771-Multicast-IP-Adressbereich, da Multicast-Adressen nicht zu einem einzelnen Standort gehören.
• Eindeutige lokale IPv6-Adressen.
• Google Cloud Service-IP-Adressen. Ausnahmen sind Google Cloud externe Compute Engine-IP-Adressen, die angereichert werden.

Google SecOps reichert die folgenden UDM-Felder mit Geolocation-Daten an:

• principal
• target
• src
• observer

Im folgenden Beispiel sehen Sie, welche geografischen Informationen einem UDM-Ereignis mit einer IP-Adresse, die den Niederlanden zugeordnet ist, hinzugefügt werden:

Inkonsistenzen

Die proprietäre IP-Standortbestimmungstechnologie von Google verwendet eine Kombination aus Netzwerkdaten und anderen Eingaben und Methoden, um den Standort von IP-Adressen und die Netzwerkauflösung für unsere Nutzer zu ermitteln. Andere Organisationen verwenden möglicherweise andere Signale oder Methoden, was gelegentlich zu unterschiedlichen Ergebnissen führen kann.

Sollten Fälle auftreten, in denen Sie eine Inkonsistenz bei den von Google bereitgestellten IP-Geolokalisierungsergebnissen feststellen, wenden Sie sich bitte an den Kundensupport, damit wir die Angelegenheit untersuchen und unsere Aufzeichnungen gegebenenfalls korrigieren können.

Entitäten mit Informationen aus Safe Browsing-Gefahrenlisten anreichern

Google SecOps erfasst Daten von Safe Browsing in Bezug auf Dateihashes. Die Daten für jede Datei werden als Entität gespeichert und liefern zusätzlichen Kontext zur Datei. Analysten können Detection Engine-Regeln erstellen, mit denen diese Kontextdaten für Entitäten abgefragt werden, um kontextbezogene Analysen zu erstellen.

Die folgenden Informationen werden mit dem Datensatz für den Kontext der Einheit gespeichert.

Entitäten mit WHOIS-Daten anreichern

Google SecOps nimmt täglich WHOIS-Daten auf. Bei der Aufnahme eingehender Kundengerätedaten vergleicht Google SecOps Domains in Kundendaten mit den WHOIS-Daten. Wenn es eine Übereinstimmung gibt, speichert Google SecOps die zugehörigen WHOIS-Daten im Unternehmensdatensatz für die Domain. Für jede Entität, bei der entity.metadata.entity_type = DOMAIN_NAME, reichert Google SecOps die Entität mit Informationen aus WHOIS an.

Google SecOps füllt die folgenden Felder im Datensatz der Identität mit angereicherten WHOIS-Daten:

• 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 Unified Data Model field list (Liste der Felder des einheitlichen Datenmodells).

Google Cloud Threat Intelligence-Daten aufnehmen und speichern

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

• GCTI Tor Exit Nodes: IP-Adressen, die als Tor-Ausgangsknoten bekannt sind.
• GCTI Benign Binaries: Dateien, die entweder Teil der Originaldistribution des Betriebssystems sind oder durch einen offiziellen Betriebssystem-Patch aktualisiert wurden. Einige offizielle Betriebssystembinärdateien, die von einem Angreifer durch Aktivitäten missbraucht wurden, die bei Living-off-the-Land-Angriffen üblich sind, sind von dieser Datenquelle ausgeschlossen, z. B. solche, die sich auf anfängliche Einstiegsvektoren konzentrieren.

• GCTI-Tools für den Remotezugriff: Dateien, die häufig von böswilligen Akteuren verwendet wurden. Diese Tools sind in der Regel legitime Anwendungen, die manchmal missbraucht werden, um eine Remote-Verbindung zu kompromittierten Systemen herzustellen.

  Diese Kontextdaten werden global als Entitäten gespeichert. Sie können die Daten mit Regeln der Erkennungs-Engine abfragen. Fügen Sie der Regel die folgenden UDM-Felder und ‑Werte hinzu, 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 verwendet wird, um einen UDM-Datensatz zu identifizieren.

Zeitbezogene und zeitlose Google Cloud Threat Intelligence-Datenquellen

Google Cloud Datenquellen für Threat Intelligence sind entweder zeitbasiert oder zeitlos.

Zeitbezogene Datenquellen haben für jeden Eintrag einen zugehörigen Zeitraum. Wenn also am Tag 1 eine Erkennung generiert wird, wird erwartet, dass bei einer nachträglichen Suche an einem beliebigen Tag in der Zukunft dieselbe Erkennung für Tag 1 generiert wird.

Zeitlose Datenquellen haben keinen zugehörigen Zeitraum. Das liegt daran, dass nur der jeweils letzte Datensatz berücksichtigt werden sollte. Zeitlose Datenquellen werden häufig für Daten wie Dateihashes verwendet, die sich voraussichtlich nicht ändern. Wenn am ersten Tag keine Erkennung erfolgt, kann am zweiten Tag bei einer Retro-Suche eine Erkennung für den ersten Tag generiert werden, weil ein neuer Eintrag hinzugefügt wurde.

Daten zu IP-Adressen von Tor-Exit-Knoten

Google SecOps erfasst und speichert IP-Adressen, die als Tor-Ausgangsknoten bekannt sind. Tor-Ausgangsknoten sind Punkte, an denen der Traffic das Tor-Netzwerk verlässt. Informationen, die aus dieser Datenquelle aufgenommen werden, werden in den folgenden UDM-Feldern gespeichert. Die Daten in dieser Quelle sind zeitbezogen.

Daten zu harmlosen Betriebssystemdateien

Google SecOps erfasst und speichert Dateihashes aus der Datenquelle „GCTI Benign Binaries“. Informationen, die aus dieser Datenquelle aufgenommen werden, werden in den folgenden UDM-Feldern gespeichert. Die Daten in dieser Quelle sind zeitlos.

Daten zu Tools für den Remotezugriff

Zu den Remotezugriffstools gehören Dateihashes für bekannte Remotezugriffstools wie VNC-Clients, die häufig von böswilligen Akteuren verwendet wurden. Diese Tools sind in der Regel legitime Anwendungen, die manchmal missbraucht werden, um eine Remote-Verbindung zu gehackten Systemen herzustellen. Informationen, die aus dieser Datenquelle aufgenommen werden, werden in den folgenden UDM-Feldern gespeichert. Die Daten in dieser Quelle sind zeitlos.

Ereignisse mit VirusTotal-Dateimetadaten anreichern

Google SecOps reichert Dateihashes in UDM-Ereignissen an und bietet zusätzlichen Kontext bei der Untersuchung. 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 während einer Suche bereitgestellt.

Durch die Integration von VirusTotal-Dateimetadaten und der Anreicherung von Beziehungen mit Google SecOps lassen sich Muster schädlicher Aktivitäten erkennen und Malwarebewegungen in einem Netzwerk nachverfolgen.

Ein Rohlog enthält nur begrenzte Informationen zur Datei. VirusTotal ergänzt das Ereignis mit Dateimetadaten, um einen Dump mit fehlerhaften 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 Ereignisse mit schädlichen Dateien und allgemein bei der Suche nach Bedrohungen zu analysieren. Ein Anwendungsbeispiel ist das Erkennen von Änderungen an der Originaldatei, wodurch wiederum die Dateimetadaten für die Bedrohungserkennung importiert werden.

Die folgenden Informationen werden mit dem Datensatz gespeichert. Eine Liste aller UDM-Felder finden Sie unter Liste der Felder für einheitliche Datenmodelle (Unified Data Model, UDM).