Übersicht über das Entitätskontextdiagramm

Unterstützt in:

Google SecOps SIEM

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, Untersuchung und das Aufspüren von Bedrohungen in Erkennungsregeln, Suchvorgängen und Dashboards bietet. Die EKG-Verarbeitungspipeline führt Kontextinformationen aus allen Google SecOps-Umgebungen zusammen.

Das ECG berechnet auch zusammenfassende Messwerte für Entitäten. 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:

• Eine umfassende, korrelierte und erweiterte Ansicht interner Einheiten (Assets und Nutzer) und externer Einheiten (IOCs) erstellen.
• Beziehungen zwischen diesen Einheiten identifizieren

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: Berechnet und erweitert jede Entität mit einer Häufigkeitsstatistik, die ihre Beliebtheit in der Umgebung angibt. Berechnet und erweitert die Zeit des ersten und letzten Auftretens der Einheit.
Globaler Kontext	Von Google bezogen	Globale Quellen liefern interne und externe Threat Intelligence- und Reputationsdaten. Beispiel: Nimmt Google Threat Intelligence-Daten auf und speichert sie. Reichert Entitäten mit Informationen aus Safe Browsing-Bedrohungslisten an. Reichert Entitäten mit WHOIS-Daten an.

Pipeline zur Verarbeitung von EKG-Daten

Die Pipeline zur Verarbeitung von EKG-Daten erstellt für jede Einheit ein umfassendes, autoritatives Profil. Dazu werden Kontextinformationen aus verschiedenen Quellen (z. B. Identitätsanbietern, CMDBs, Threat Intelligence-Feeds und abgeleitetem Kontext) in einem einzigen, konsolidierten Entitätsprofil zusammengeführt. Das Zusammenführen 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 umfangreiche 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.

Hinweis : „ECG merging“ (Zusammenführen von EKG-Daten) ist nicht dasselbe wie „UDM aliasing“ (UDM-Alias). Beim UDM-Aliasing werden Ereignisse durch Hinzufügen von Kennungen angereichert (z. B. durch Zuordnung einer IP-Adresse zu einem Hostnamen innerhalb eines Ereignisses). Bei ECG wird Kontext aus mehreren Quellen (z. B. IdPs, CMDBs und Threat Intelligence) zusammengeführt, um ein einzelnes Profil für eine Entität zu erstellen.

Zeitbezogene und zeitlose Entitäten

Das ECG erstellt sowohl zeitbasierte (temporale) als auch zeitlose (nicht temporale) Einheiten. Zeitbezogene 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 IDs sind hostname, MAC address, user ID oder email address. Im ECG werden Datensätze, die in Bezug auf einen dieser Werte übereinstimmen, zusammengeführt, um eine umfassende und angereicherte Ansicht einer Entität zu erstellen.

Für das EKG-Aliasing 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 IDs 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 Kennzeichnungen in beiden Datensätzen übereinstimmen.

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

• Wenn beide einen md5-Hash haben, müssen sie gemäß dem EKG übereinstimmen.
• Wenn ein Gerät ein md5 und das andere ein sha256 hat, werden die EKG-Daten 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 Kennzeichnungen (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 bereitgestellten 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 das Rechtssubjekt durch das EKG aktualisiert, indem der Wert mit dem neuesten Startzeitpunkt ausgewählt wird. Wenn das ECG ein Entitätsattribut 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 im ECG redundante Daten durch Deduplizierung entfernt. Duplikate werden erkannt, indem alle relevanten eindeutigen Kennungen für eine Entität in verschiedenen Kontextquellen verglichen 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

Hinweis :Wenn Konflikte bei nicht wiederkehrenden Feldern auftreten, werden die Daten aus der letzten Einheit verwendet.

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 und es wird eine implizite Gültigkeitsdauer für Daten zum Kontext von Entitäten festgelegt.

Das ECG unterscheidet zwischen Kontextdaten (assets, users, resources, groups) und Kompromittierungsindikatoren (Indicators of Compromise, IOCs).

Beispiel: Nutzerdaten mit EKG-Zusammenführung 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. [e-mail]) zusammengeführt. So entsteht im ECG eine einheitliche jdoe-Nutzerentität, 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ätenkontext-EKG-Datenquellen

Autoritative Datenquellen für die Nutzer und Assets Ihrer Umgebung liefern die wichtigsten Protokolldaten 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 Drittanbieterfeeds, Google Threat Intelligence (GTI)	ip_address, domain_name, file

Beispiel für eine Suche

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 Rechtssubjekten

Google SecOps erweitert Entitätsprofile basierend auf autoritativen Kontextdatenquellen für Entitäten und wichtigen UDM-Feldern:

Entitätstyp	Datenquellen	Kritische UDM-Felder (für Aliasse und Indexierung)
Prozess	Endpunktlogs enthalten die PSPI („principal.process.product_specific_process_id“), eine stabile Kennung, die für ein robustes Prozess-Aliasing unerlässlich ist. Beispiele sind CrowdStrike EDR (CS_EDR) und Windows Sysmon (WINDOWS_SYSMON).	source.process.product_specific_process_id
Nutzer	Diese Quellen liefern Nutzerattribute und Identitätsinformationen. Zum Beispiel 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	Bietet einen eindeutigen „digitalen Fingerabdruck“ des Dateninhalts, 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 Ereigniskontextdaten erforderlich.

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

• Hier finden Sie eine Liste der wichtigsten UDM-Felder, die zum Funktionsbereich Entity graph gehören.

• 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
  Datei und Prozess	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 eine Monitoring-Regel für Brute-Force-Angriffe einfügen, um nur dann eine Benachrichtigung zu erhalten, wenn der betroffene Nutzer auch Mitglied der Gruppe „Domänenadministratoren“ ist und das betroffene Asset ein Domänencontroller 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 Einheit in allen Namespaces aus den Ereignisdaten Ihrer Organisation. Dabei werden Aliasinformationen, Daten aus internen Anreicherungsprozessen und Sicherheitsereignisdaten verwendet, um Beziehungen herzustellen (z. B. eine asset, die mit einer IP address verknüpft ist).

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

• entity.file.sha256 bis file (hash) Objekte
• (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. Es werden wichtige Anreicherungsfunktionen ausgeführt, um beispielsweise Messwerte für die Seltenheit von Einheiten wie Statistiken zur Häufigkeit und Zeitmesswerte 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 Entitäten 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 Uhr bis 23:59:59 Uhr 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 eine 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 (einschließlich Subdomains) zugreifen.

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.

Achtung :Wenn Sie das Argument prevalence einfügen, kann sich die Menge der abgefragten Daten erheblich erhöhen, was möglicherweise zu einem Regel-Fehler führt. Wenn ein Regel-Fehler auftritt, passen Sie die Regelparameter an. Fügen Sie beispielsweise weitere Filter hinzu oder verringern Sie den im Abschnitt match angegebenen Zeitraum.

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 zusammenführen.

Sie können beispielsweise prevalence-Daten in ECG 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

Hinweis:Suche und Dashboards unterstützen maximal einen Join, Regeln maximal zwei.

Hinweis:Wenn Sie das Argument prevalence einfügen, kann es sein, dass bei der Suche deutlich mehr Daten abgefragt werden.

Zeitpunkt des ersten und letzten Zugriffs auf Objekte

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

• first-seen-time:Datum und 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 für die einzelnen Einheiten in den einzelnen Namespaces nicht.
• Google SecOps exportiert diese Statistiken nicht in das Google SecOps events-Schema 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 aus 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 der Detection 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

Hinweis :Ersetzen Sie in den folgenden Abschnitten den Platzhalter <variable_name> durch den eindeutigen Variablennamen, den Sie in einer Regel zum Identifizieren eines UDM-Datensatzes verwenden.

Zeitbezogene und zeitlose Google Threat Intelligence-Datenquellen

Google Threat Intelligence-Datenquellen können zeitabhängige oder zeitunabhängige Typen sein.

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. für Datei-Hashes. Wenn Google SecOps am ersten Tag keine Erkennung generiert, kann am zweiten Tag bei einer Retrohunt für den ersten Tag eine Erkennung generiert werden, wenn der zeitlosen Datenquelle ein neuer Eintrag hinzugefügt wurde.

Daten zu IP-Adressen von Tor-Exit-Knoten

Google SecOps nimmt IP-Adressen auf, die als Tor-Ausgangsknoten bekannt sind, und speichert sie. Tor-Ausgangsknoten sind Punkte, an denen der Traffic das Tor-Netzwerk verlässt. Diese Daten sind zeitlich begrenzt.

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"

Beispiele für das Abfragen dieser Daten in YARA-L-Regeln finden Sie unter Tor-Ausgangsknoten erkennen.

Daten zu harmlosen Betriebssystemdateien

Google SecOps erfasst und speichert Dateihashes aus der Datenquelle „GTI Benign Binaries“. Google SecOps speichert Informationen, die aus dieser Datenquelle aufgenommen wurden, in den folgenden UDM-Feldern. 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 von böswilligen Akteuren häufig verwendet wurden. Diese Tools sind in der Regel legitime Anwendungen, die manchmal missbraucht werden, um eine Remoteverbindung zu gehackten Systemen herzustellen. Google SecOps speichert Informationen, die aus dieser Datenquelle aufgenommen wurden, in den folgenden UDM-Feldern. Daten von 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.

Hinweis :Sie können Safe Browsing nur in Regeln verwenden und die Daten gelten als zeitlos.

In Google SecOps werden die folgenden Informationen mit dem Datensatz zum 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 stattgefunden hat.
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: Ein Dateihash wurde zwischen dem start_time und dem end_time als schädlich oder verdächtig eingestuft.
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, um dies anzugeben.
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 aus:

• 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 identifiziert werden.

Die folgenden Filterparameter geben den Anreicherungstyp oder die Quelle an: entity_type, product_name und vendor_name.

Nehmen Sie beispielsweise die folgenden Filterfelder in den Abschnitt events der Regel auf, 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"

Hinweis :Die Quelle der Anreicherung kann genauso wertvoll sein wie die Daten selbst. Ein einzelnes UDM-Feld kann mehrere Anreicherungsquellen haben. Sie können diese Informationen in der Ereignisanzeige oder über eine UDM-Ereignissuche (z. B. principal.hostname="john.doe.desktop" metadata.event_type="NETWORK_CONNECTION") aufrufen.

Best Practices für EKG

Beachten Sie bei der Verwendung von kontextbezogen angereicherten Daten die folgenden EKG-Best Practices:

• 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, dedupliziert Google SecOps nur identische Ereignisse und behält die letzte Entität bei.
• 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 können jedoch einige Ereigniskontexte verloren gehen.
• 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 allgemeinen Dienstlimits für Google SecOps finden Sie unter Dienstlimits.

Zugehörige externe Inhalte

• Entitätsdiagramm als mehrdimensionale Liste verwenden
• Aliasing in Chronicle SIEM
• Abgelaufene IOCs im Entitätsdiagramm
• Google Safe Browsing in Chronicle SIEM

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