Entitätskontextdiagramm (Entity Context Graph, ECG) verwenden

Unterstützt in:

Dieses Dokument bietet einen Überblick über den Entity Context Graph (ECG) und behandelt seine Datenquellen, die Verarbeitungspipeline und die Anwendungen in Regeln und der Suche. Das ECG ist ein wichtiges Entity-Datenmodell, das wesentlichen Kontext für die erweiterte Bedrohungserkennung, ‑analyse und ‑suche in Erkennungsregeln, Suchvorgängen und Dashboards bietet. Die EKG-Verarbeitungspipeline führt Kontextinformationen aus allen Google SecOps-Umgebungen zusammen.

Im ECG werden auch zusammenfassende Messwerte für Entitäten berechnet. Dazu gehören die Häufigkeit (wie oft eine bestimmte Einheit im Vergleich zu anderen Einheiten in Ihren UDM-Daten vorkommt) sowie first-seen-time und last-seen-time einer Einheit. Außerdem werden wichtige Quellen für die Anreicherung und Quellen für Kompromittierungsindikatoren (Indicators of Compromise, IOC) wie Google Threat Intelligence (GTI), Safe Browsing, WHOIS und VirusTotal-Daten identifiziert.

Das EKG verwendet UDM-Ereignisse für Folgendes:

  • Erstellen Sie eine umfassende Ansicht interner Einheiten (Assets und Nutzer) und externer Einheiten (IOCs) mit zusätzlichen Informationen und Korrelationen.
  • Beziehungen zwischen diesen Entitäten ermitteln

Datenquellen für das EKG

In der EKG-Pipeline werden Daten aus den folgenden Quellen kombiniert:

Kontextquelle Quelle Beschreibung
Entitätskontext Vom Kunden bereitgestellt Google SecOps nimmt strukturierte Organisationsdaten wie autoritative Details zu Nutzern und Assets direkt aus externen Systemen auf. Zu diesen Quellen gehören Identitätsanbieter (IDPs), CMDB-Systeme (Configuration Management Database, z. B. ServiceNow CMDB, Duo User Context) und Systeme zur Verwaltung von Sicherheitslücken.
Abgeleiteter Kontext Von Google SecOps generiert Google SecOps generiert statistische Daten auf Grundlage der Analyse der aufgenommenen Aktivitäten. Es reichert Ereignisse und Entitäten aus verschiedenen Quellen in Ihrer Umgebung an, z. B. Windows AD, Azure AD, Okta, Google Cloudund IAM.
Beispiel:
Globaler Kontext Von Google bezogen Globale Quellen liefern interne und externe Threat Intelligence- und Reputationsdaten.
Beispiel:

Pipeline zur Verarbeitung von EKG-Daten

Die EKG-Datenverarbeitungspipeline erstellt für jede Einheit ein umfassendes, autoritatives Profil. Dazu werden Kontextinformationen aus mehreren Quellen (z. B. Identitätsanbietern, CMDBs, Threat Intelligence-Feeds und abgeleitetem Kontext) in einem einzigen, konsolidierten Entitätsprofil zusammengeführt. Die Zusammenführung von EKGs ermöglicht Folgendes:

  • Dem EKG werden neue Verbindungen, Properties und Beziehungen hinzugefügt.
  • Abgeleiteten Kontext erstellen und aktualisieren

Der Gesamtprozess umfasst zuerst die Normalisierung von Rohsicherheitsereignissen in UDM-Strukturen mithilfe von UDM-Aliasing und -Anreicherung. Anschließend werden diese Ereignisdaten mit verschiedenen Kontextquellen zusammengeführt, um umfassende Entitätsprofile zu erstellen.

UDM-Aliasing und EKG-Zusammenführung

Zuerst werden Rohsicherheitsereignisse in die Pipeline für UDM-Aliasing und ‑Anreicherung aufgenommen und in UDM-Strukturen normalisiert.

Zeitbezogene und zeitlose Entitäten

Das ECG erstellt sowohl zeitbezogene (temporale) als auch zeitlose (nicht temporale) Einheiten. Zeitlich begrenzte Einheiten werden innerhalb der angegebenen Regel- und Suchzeiträume ausgewertet. Zeitlose Entitäten werden ohne Berücksichtigung des Zeitraums der Suche oder Regel ausgewertet.

EKG-Zusammenführungsschlüssel

Im ECG werden Kontextdatensätze zusammengeführt, indem gemeinsame Schlüsselkennungen aus verschiedenen Datenquellen abgeglichen werden. Beispiele für diese Kennungen sind hostname, MAC address, user ID oder email address. Im ECG werden Datensätze zusammengeführt, die in einem dieser Werte übereinstimmen, um eine umfassende und angereicherte Ansicht einer Entität zu erstellen.

Für das Aliasing von EKG-Daten werden die folgenden UDM-Felder als Zusammenführungsschlüssel verwendet:

  • 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

Bestimmte Entitätstypen zusammenführen (Datei, URL, Domain)

Zusätzlich zu merge-keys führt die ECG Kontext für bestimmte Entitätstypen (Datei, URL und Domain) mithilfe der folgenden eindeutigen Kennungen zusammen:

  • File

    • entity.file.md5
    • entity.file.sha1
    • entity.file.sha256
    • (und entity.file.product_object_id, falls angegeben)

  • URL

    • entity.url.url
    • (und entity.url.product_object_id, falls angegeben)

  • Domain

    • entity.domain.domain
    • (und entity.domain.product_object_id, falls angegeben)

Das ECG führt einen Datensatz mit Elementkontext für File, URL oder Domain nur dann mit einem anderen Datensatz zusammen, wenn alle eindeutigen Kennungen in beiden Datensätzen übereinstimmen.

Wenn das ECG beispielsweise zwei File-Entitätskontexte für einen Merge berücksichtigt:

  • Wenn beide einen md5-Hash haben, müssen sie übereinstimmen.
  • Wenn eine Option ein md5 und die andere ein sha256 hat, werden sie im EKG nicht anhand des Hashwerts zusammengeführt.
  • Wenn ein product_object_id angegeben wird, muss das EKG auch damit übereinstimmen, wenn es in beiden verglichenen Datensätzen vorhanden ist. Das gilt zusätzlich zu den inhaltsbasierten Kennungen (z. B. md5, url oder domain).

Das bedeutet, dass für diese Typen Felder wie entity.file.md5, entity.url.url und entity.domain.domain zusätzlich zu allen angegebenen product_object_id vorhanden sein und für den Zusammenführungsprozess übereinstimmen müssen.

Konfliktlösung

Wenn während des Zusammenführungsvorgangs Felder mit widersprüchlichen Werten vorhanden sind, wird die Einheit durch das EKG aktualisiert, indem der Wert mit dem neuesten Startzeitpunkt ausgewählt wird. Wenn das ECG ein Attribut einer Rechtspersönlichkeit mit einem neuen Wert aktualisiert, wird der vorherige Wert in den Suchergebnissen für das Zeitintervall beibehalten, in dem dieser vorherige Wert gültig war. Daher kann eine Suchanfrage, die einen Zeitraum abdeckt, in dem sich ein Attribut geändert hat, mehrere Entitätskontexte für diese Entität zurückgeben.

Deduplizierung und Zeitintervalle

Um eine gemeinsame kombinierte Einheit zu erstellen, werden durch die EKG redundante Daten durch Deduplizierung entfernt. Duplikate werden identifiziert, indem alle relevanten eindeutigen Kennungen für eine Entität in verschiedenen Kontextquellen abgeglichen werden. Es werden Zeitintervalle generiert, anstatt exakte Zeitstempel abzugleichen.

Angenommen, Sie haben zwei Einheiten e1 und e2 mit den Zeitstempeln t1 bzw. t2. Wenn e1 und e2 ansonsten identisch sind, werden sie im EKG dedupliziert, indem Zeitstempelunterschiede in den folgenden Feldern ignoriert werden:

  • collected_timestamp
  • creation_timestamp
  • interval

Lookback-Window

Das EKG erstellt kontextbezogene Daten für Entitäten mit einem Lookback-Window von fünf Tagen. So können verspätet eingehende Daten verarbeitet werden. Außerdem wird eine implizite Gültigkeitsdauer für Daten zum Kontext von Entitäten festgelegt.

Das ECG unterscheidet zwischen Kontextdaten (assets, users, resources, groups) und Indikatoren für Sicherheitsrisiken (Indicators of Compromise, IOCs).

Beispiel: Nutzerdaten mit EKG-Daten zusammenführen

Google SecOps erfasst beispielsweise Nutzerdaten für jdoe aus drei Quellen: Okta, Azure AD und einem Scanner für Sicherheitslücken. Im ECG werden diese drei Datensätze anhand übereinstimmender Kennungen (z. B. jdoe@example.com) zusammengeführt. So entsteht eine einheitliche jdoe-Nutzerentität im ECG, die Attribute aus allen drei Quellen enthält.

EKG-Datenquellen für kritische Entitäten und Ereignisse

Für Google SecOps sind mehrere bestimmte Datenquellen erforderlich, um Entitäten zu erstellen und zu aktualisieren.

Kritische Entitätskontext-ECG-Datenquellen

Autoritative Datenquellen für die Nutzer und Assets Ihrer Umgebung liefern die wichtigsten Logdaten für die Erstellung eines Entitätsdatenmodells. Beispiel:

Kategorie Wichtige Datenquellen Entitäten werden eingefügt
Identitäts- und Zugriffsverwaltung Active Directory, Azure AD, Okta, Google Cloud Identity user,
group
Asset-Inventar CMDBs, JAMF, Microsoft Intune asset
Threat Intelligence Benutzerdefinierte oder Drittanbieter-Feeds, Google Threat Intelligence (GTI) ip_address,
domain_name,
file

So listen Sie Parser auf, die die einzelnen Kategorien unterstützen:

  1. Unterstützte Logtypen mit Standardparser

  2. Geben Sie eine Kategorie in die Suchleiste ein, z. B.:

    • Geben Sie für Parser, die für das Asset-Inventar relevant sind, inventory oder asset ein.
    • Geben Sie identity ein, um Parser für die Identitäts- und Zugriffsverwaltung aufzurufen.
    • Geben Sie für Parser, die für Threat Intelligence relevant sind, IOC ein.

Datenquellen und wichtige UDM-Felder für die Profilerstellung von Einheiten

Google SecOps optimiert Entitätsprofile anhand von autoritativen Kontextdatenquellen für Entitäten und wichtigen UDM-Feldern:

Entitätstyp Datenquellen Wichtige UDM-Felder (für Aliasing und Indexierung)
Prozess Endpoint-Logs enthalten die PSPI („principal.process.product_specific_process_id“), eine stabile Kennung, die für ein robustes Prozess-Aliasing unerlässlich ist.
Beispiele: CrowdStrike EDR (CS_EDR) und Windows Sysmon (WINDOWS_SYSMON).		 source.process.product_specific_process_id
Nutzer Diese Quellen liefern Nutzerattribute und Identitätsinformationen.
Beispiele: Duo-Entitätskontextdaten (DUO_CONTEXT) und Okta (OKTA).		 source.user.userid,
source.user.email_address,
source.user.windows_sid,
source.user.product_object_id
Asset oder Endpunkt Diese Quellen liefern maßgebliche Asset-Informationen.
Beispiele: ServiceNow CMDB (SERVICENOW_CMDB) und Tanium Asset (TANIUM_ASSET).		 source.ip,
source.hostname,
source.asset_id,
principal.asset.hostname
Datei-Hash Stellt einen eindeutigen „digitalen Fingerabdruck“ des Dateninhalts bereit, um die Datenintegrität zu überprüfen. source.file.sha256,
source.file.sha1,
source.file.md5

UDM-Felder für Kontextdaten zu kritischen Ereignissen

Für Google SecOps sind mehrere wichtige UDM-Felder für den Ereigniskontext erforderlich.

  • Die wichtigsten UDM-Felder dienen als stabile Kennungen und Beziehungsindikatoren (principal.*-, target.*-, src_*- und dst_*-Felder).

  • Liste der wichtigsten UDM-Felder für den Funktionsbereich Entity graph

  • Um ein umfassendes EKG zu erstellen, sollten Sie Datenquellen mit hochwertigen Kennungen und Beziehungsdaten priorisieren. Beispiel:

    Entitätstyp Wichtige Datenquellen Wichtige UDM-Felder für die Erstellung von Entitäten
    Asset (Host) EDR und XDR, DNS und DHCP, Firewall, Google Cloud Console-Audit-Logs metadata.event_type,
    principal.asset.asset_id,
    principal.asset.hostname,
    principal.ip
    Nutzer IdP-Logs (Identitätsanbieter), HR-Feed (Kontext), Cloud Identity-Logs, E-Mail-Gateway principal.user.userid,
    principal.user.email_addresses,
    target.user.userid,
    principal.ip
    Netzwerk Firewall, VPN, DNS, VPC-Flusslogs principal.ip,
    target.ip,
    src_ip,
    dst_ip,
    network.direction
    Einreichen und bearbeiten EDR und XDR, Anwendungslogs target.file.full_path,
    target.process.file.full_path,
    target.process.command_line

Beispiel

Das ECG verwendet diese UDM-Felder, um Kontextdaten von Entitäten und UDM-Ereignisdaten in Regeln, Suchvorgängen und Dashboards zu verknüpfen.

Sie können beispielsweise Nutzerkontextdaten in einer Monitoring-Regel für Brute-Force-Angriffe zusammenführen, um nur dann eine Benachrichtigung zu senden, wenn der betroffene Nutzer auch Mitglied der Gruppe „Domänenadministratoren“ ist und das betroffene Asset ein Domaincontroller ist:

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

Abgeleitete Kontextanreicherungen

Google SecOps generiert dynamische, ereignisgesteuerte Inferenzdaten für jede Entität in allen Namespaces aus den Ereignisdaten Ihrer Organisation. Dabei werden Aliasinformationen, Daten aus internen Anreicherungsprozessen und Sicherheitsereignisdaten verwendet, um Beziehungen herzustellen (z. B. die Zuordnung eines asset zu einem IP address).

Durch diesen Prozess wird wertvoller Kontext hinzugefügt, um Unternehmensprofile zu optimieren. Beispiele:

  • entity.file.sha256 bis file (hash) Entitäten
  • (principal or target).ip_geo_artifact.location.country_or_region bis network (geolocation) Objekte

Google SecOps analysiert mehrere Indikatoren in aufgenommenen Aktivitäten, um Ereignisse mit Kontextinformationen anzureichern. Sie führt wichtige Anreicherungsfunktionen aus, um beispielsweise Messwerte für die Seltenheit von Einheiten wie Prävalenzstatistiken und temporale Messwerte wie first-seen-time und last-seen-time zu generieren.

Statistiken zur Prävalenz

In der EKG-Pipeline werden vorhandene und eingehende Daten analysiert, um Prävalenzmesswerte als abgeleitetes Kontextfeld zu berechnen und zu speichern. Diese Messwerte stellen einen numerischen „Beliebtheitswert“ für Entitäten wie domain, file hash oder IP address in Ihrer Umgebung dar. So können Sie seltene oder ungewöhnliche Aktivitäten erkennen, da beliebtere Einheiten in der Regel ein geringeres Risiko darstellen.

Google SecOps aktualisiert diese Statistiken regelmäßig und speichert sie in einem separaten Entitätskontext. Die Erkennungs-Engine kann diese Werte verwenden und Sie können mit der UDM-Abfragesyntax danach suchen. In der Console werden diese Werte jedoch nicht zusammen mit anderen Entitätsdetails angezeigt.

Sie können die folgenden Felder verwenden, wenn Sie Regeln für die Erkennungs-Engine erstellen.

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

Google SecOps berechnet die Werte für day_max und rolling_max unterschiedlich:

  • day_max steht für die maximale Punktzahl für die Häufigkeit des Artefakts während des Tages (ein Tag wird als 00:00:00 UCT bis 23:59:59 UTC definiert).
  • rolling_max steht für den maximalen täglichen Prävalenzwert (d. h. day_max) für das Artefakt im vorherigen 10-Tages-Zeitraum.
  • day_count wird zur Berechnung von rolling_max verwendet und hat immer den Wert 10.

Wenn diese Werte für ein domain berechnet werden, ergibt sich der folgende Unterschied zwischen day_max und day_max_sub_domains (und rolling_max und rolling_max_sub_domains):

  • rolling_max und day_max stehen für die Anzahl der täglichen eindeutigen internen IP-Adressen, die auf eine bestimmte Domain zugreifen (Unterdomains ausgenommen).
  • rolling_max_sub_domains und day_max_sub_domains stehen für die Anzahl der eindeutigen internen IP-Adressen, die auf eine bestimmte Domain zugreifen (einschließlich Subdomains).

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

Beispiel

Für die EKG-Pipeline sind diese UDM-Felder erforderlich, um die relevanten Kontextdaten in eine Regel oder Suche einzufügen. Sie müssen alle EKG-bezogenen Daten explizit mit UDM-Ereignisdaten verknüpfen.

Sie können beispielsweise prevalence-Daten im EKG verwenden, um Verbindungen zu „seltenen“ Domains in Ihren Sicherheitslogs zu ermitteln:

    $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

Zeitpunkt des ersten und letzten Auftretens von Entitäten

Google SecOps analysiert eingehende Daten, um Datensätze zum Kontext von Entitäten mit den folgenden wichtigen Feldern anzureichern:

  • first-seen-time:Das Datum und die Uhrzeit, zu der die Entität zum ersten Mal in Ihrer Umgebung erkannt wurde.
  • last-seen-time:Datum und Uhrzeit der letzten Beobachtung.

Mit diesen abgeleiteten Feldern können Sie Aktivitäten für domain-, file hash-, asset-, user- oder IP address-Einheiten in Beziehung setzen.

Diese Werte werden in den folgenden UDM-Feldern 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

Ausnahmen für die Berechnung von „Erster Zugriff“ und „Letzter Zugriff“:

  • Bei asset- und user-Entitäten füllt Google SecOps nur das Feld first_seen_time, nicht aber das Feld last_seen_time aus.
  • Google SecOps berechnet die Statistiken nicht für jede Entität in einzelnen Namespaces.
  • Google SecOps exportiert diese Statistiken nicht in das Google SecOps-Schema events in BigQuery.
  • Google SecOps berechnet diese Werte nicht für andere Entitätstypen wie group oder resource.

Globale Kontextanreicherungen

Dazu gehören externe Threat Intelligence- und Reputationsdaten aus internen und globalen Drittanbieterquellen.

Google Threat Intelligence-Daten aufnehmen

Google SecOps nimmt Daten aus Google Threat Intelligence-Datenquellen (GTI) auf und stellt Kontextinformationen für die Untersuchung von Aktivitäten in Ihrer Umgebung bereit.

Fragen Sie die folgenden Datenquellen ab:

  • GTI-Tor-Ausgangsknoten:IP-Adressen, die als Tor-Ausgangsknoten bekannt sind.
  • GTI Benign Binaries:Dateien, die entweder Teil der ursprünglichen Betriebssystemdistribution 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 in dieser Datenquelle ausgeschlossen, z. B. solche, die sich auf anfängliche Einstiegsvektoren konzentrieren.
  • GTI-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 gehackten Systemen herzustellen.

Kontextbezogene Daten werden global als Entitäten gespeichert. Sie können die Daten mit Regeln für die 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 Threat Intelligence
  • graph.metadata.product_name = GTI Feed

Zeitbezogene und zeitlose Google Threat Intelligence-Datenquellen

Google Threat Intelligence-Datenquellen sind entweder zeitabhängig oder zeitunabhängig.

Jedem Eintrag in zeitbezogenen Datenquellen ist ein Zeitraum zugeordnet. Wenn Google SecOps beispielsweise am ersten Tag eine Erkennung generiert, wird erwartet, dass bei einer Retrohunt an einem beliebigen zukünftigen Tag dieselbe Erkennung für den ersten Tag generiert wird.

Zeitlose Datenquellen haben keinen zugehörigen Zeitraum, da nur der letzte Datensatz berücksichtigt werden muss. Diese Datenquellen werden in der Regel für Daten verwendet, die sich voraussichtlich nicht ändern, z. B. Dateihashes. Wenn Google SecOps am ersten Tag keine Erkennung generiert, kann am zweiten Tag bei einer Retrohunt eine Erkennung für den ersten Tag generiert werden, wenn der zeitlosen Datenquelle 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. Diese Daten sind zeitbezogen.

In Google SecOps werden Informationen, die aus dieser Datenquelle aufgenommen werden, in den folgenden UDM-Feldern gespeichert:

UDM-Feld Beschreibung
<variable_name>.graph.metadata.vendor_name Speichert den Wert Google Threat Intelligence.
<variable_name>.graph.metadata.product_name Speichert den Wert GTI Feed.
<variable_name>.graph.metadata.threat.threat_feed_name Speichert den Wert Tor Exit Nodes.
<variable_name>.graph.entity.artifact.ip Speichert die IP-Adresse, die aus der GTI-Datenquelle aufgenommen wurde.
Beispiel für eine Suche
graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Tor Exit Nodes"

Daten zu harmlosen Betriebssystemdateien

Google SecOps erfasst und speichert Dateihashes aus der Datenquelle „GTI Benign Binaries“. In Google SecOps werden Informationen, die aus dieser Datenquelle aufgenommen werden, in den folgenden UDM-Feldern gespeichert. Daten zu harmlosen Binärdateien sind zeitlos.

UDM-Feld Beschreibung
<variable_name>.graph.metadata.vendor_name Speichert den Wert Google Threat Intelligence.
<variable_name>.graph.metadata.product_name Speichert den Wert GTI 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 SHA‑1-Hashwert der Datei.
<variable_name>.graph.entity.file.md5 Speichert den MD5-Hashwert der Datei.
Beispiel für eine Suche
graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Benign Binaries"

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. Google SecOps speichert Informationen, die aus dieser Datenquelle aufgenommen wurden, in den folgenden UDM-Feldern. Daten zu Tools für den Remote-Zugriff sind zeitlos.

UDM-Feld Beschreibung
<variable_name>.graph.metadata.vendor_name Speichert den Wert Google Threat Intelligence.
<variable_name>.graph.metadata.product_name Speichert den Wert GTI Feed.
<variable_name>.graph.metadata.threat.threat_feed_name Speichert den Wert Remote Access Tools.
<variable_name>.graph.entity.file.sha256 Speichert den SHA256-Hashwert der Datei.
<variable_name>.graph.entity.file.sha1 Speichert den SHA‑1-Hashwert der Datei.
<variable_name>.graph.entity.file.md5 Speichert den MD5-Hashwert der Datei.
Beispiel für eine Suche
graph.metadata.source_type ="GLOBAL_CONTEXT"
graph.metadata.product_name = "GTI Feed"
graph.metadata.threat.threat_feed_name = "Remote Access Tools"

Entitäten mit Informationen aus Safe Browsing-Bedrohungslisten anreichern

Google SecOps nimmt Daten von Safe Browsing auf, die sich auf Dateihashes beziehen. In Google SecOps werden die Daten für jede Datei als Entität gespeichert und es wird zusätzlicher Kontext zur Datei bereitgestellt. Sie können Regeln für die Erkennungs-Engine erstellen, mit denen diese Daten zum Entitätskontext abgefragt werden, um kontextbezogene Analysen zu erstellen.

In Google SecOps werden die folgenden Informationen mit dem Datensatz für den Entitätskontext 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, was darauf hinweist, dass die Entität eine Datei beschreibt.
entity.metadata.collected_timestamp Das Datum und die Uhrzeit, zu der die Entität beobachtet wurde oder das Ereignis eingetreten ist.
entity.metadata.interval Speichert die Start- und Endzeit, für die diese Daten gültig sind. Da sich der Inhalt der Bedrohungsliste im Laufe der Zeit ändert, geben start_time und end_time das Zeitintervall an, in dem die Daten zum Rechtssubjekt gültig sind. Beispiel: Zwischen dem start_time und dem end_time wurde festgestellt, dass ein Dateihash schädlich oder verdächtig ist.
entity.metadata.threat.category Der Google SecOps-SecurityCategory ist auf einen 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 die Google SecOps-ProductSeverity. Wenn der Wert CRITICAL ist, deutet das darauf hin, dass das Artefakt schädlich ist. Wenn der Wert nicht angegeben ist, ist die Wahrscheinlichkeit, dass das Artefakt schädlich ist, nicht hoch genug.
entity.metadata.product_name Speichert den Wert Google Safe Browsing.
entity.file.sha256 Der SHA256-Hashwert für die Datei.

Beispielregel

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

Entitäten mit WHOIS-Daten anreichern

Google SecOps führt täglich eine WHOIS-Datenanreicherung durch, eine wichtige Funktion, bei der sowohl zeitbezogene als auch zeitlose Daten verwendet werden.

Während der Datenaufnahme von Gerätedaten vergleicht Google SecOps Domains mit WHOIS-Daten. Wenn Domains übereinstimmen, speichert Google SecOps die zugehörigen WHOIS-Daten im Entitätsdatensatz der Domain. Für jede Einheit mit entity.metadata.entity_type = DOMAIN_NAME reichert Google SecOps den Datensatz mit WHOIS-Informationen an.

Google SecOps füllt den Entitätsdatensatz mit angereicherten WHOIS-Daten in den folgenden Feldern:

  • 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 reichert domain-Entitäten (entity.metadata.entity_type = "DOMAIN_NAME") mit registrant-, creation- und expiration time-Daten aus global context-WHOIS-Einträgen an.

Beschreibungen dieser Felder finden Sie im Dokument Feldliste für das einheitliche Datenmodell.

Beispiel für eine Suche

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

Best Practices: Datenquellen mit globalem Kontext identifizieren

Um die Leistung von Regeln zu verbessern, sollten Sie einen Filter in Regeln einfügen, der Daten aus Quellen für die globale Kontextanreicherung verwendet. Mit diesem Filter sollte der spezifische Anreicherungstyp oder die spezifische Anreicherungsquelle angegeben werden.

Mit den folgenden Filterparametern wird der Anreicherungstyp oder die Anreicherungsquelle angegeben: entity_type, product_name und vendor_name.

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"

Best Practices für EKG

Beachten Sie bei der Verwendung von kontextbezogen angereicherten Daten die folgenden Best Practices für EKG:

  • Fügen Sie den Entitätsdaten keine Intervalle hinzu. Lassen Sie sie stattdessen von der EKG-Pipeline erstellen. Google SecOps generiert Intervalle während der Deduplizierung, sofern nicht anders angegeben.
  • Wenn Sie die Intervalle angeben, werden in Google SecOps nur identische Ereignisse dedupliziert und die letzte Entität wird beibehalten.
  • Damit Live-Regeln und Retrohunts wie erwartet funktionieren, müssen Sie Entitäten mindestens einmal täglich erfassen.
  • Wenn Sie Entitäten nicht täglich, sondern nur alle zwei oder mehr Tage erfassen, funktionieren Live-Regeln möglicherweise trotzdem wie erwartet. Bei Retrohunts gehen jedoch möglicherweise einige Ereigniskontexte verloren.
  • Wenn Sie identische Elemente mehrmals täglich erfassen, werden sie in Google SecOps dedupliziert und als ein einzelnes Element dargestellt.
  • Wenn Ereignisdaten für einen Tag fehlen, verwendet Google SecOps vorübergehend Daten vom Vortag, damit Live-Regeln richtig funktionieren.

Weitere Informationen zu den allgemeinen Dienstlimits für Google SecOps finden Sie unter Dienstlimits.

Ähnliche externe Inhalte

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