Entitätskontextdiagramm (Entity Context Graph, ECG) verwenden

Unterstützt in:

Dieses Dokument bietet einen umfassenden Überblick über den Entity Context Graph (ECG), seine Datenquellen, die Verarbeitungspipeline und Anwendungen in Regeln und der Suche. Das ECG ist ein wichtiges Entity-Datenmodell, das wesentlichen Kontext für die erweiterte Erkennung, 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.

Außerdem werden im ECG zusammenfassende Messwerte für Entitäten wie die Häufigkeit (wie oft eine bestimmte Entität im Vergleich zu anderen Entitäten in Ihren UDM-Daten vorkommt), die first-seen-time und last-seen-time einer Entität sowie wichtige Anreicherungsquellen und Quellen für Indikatoren für Sicherheitsrisiken (Indicators of Compromise, IOC) wie Google Threat Intelligence (GTI), Safe Browsing, WHOIS und VirusTotal-Daten berechnet.

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

Das EKG kombiniert Daten aus den folgenden Quellen:

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 Informationen zu Bedrohungen sowie Reputationsdaten.
Beispiel:

EKG-Datenverarbeitungspipeline

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

Beim Zusammenführen von ECGs wird dann ein umfassendes, autoritatives Profil für jede Einheit erstellt, indem Kontext aus mehreren Quellen (z. B. Identitätsanbieter, CMDBs, Threat Intelligence-Feeds und abgeleiteter Kontext) in einem einzigen, konsolidierten Einheitsprofil zusammengeführt wird. Durch das Zusammenführen von EKG werden dem EKG neue Verbindungen, Eigenschaften und Beziehungen hinzugefügt sowie abgeleiteter Kontext erstellt und aktualisiert.

Das ECG erstellt sowohl zeitbezogene (temporale) als auch zeitlose (nicht temporale) Einheiten. Bei der Ereignis- und Kontextgenerierung werden zeitbezogene Entitäten innerhalb der angegebenen Regel- und Suchzeiträume ausgewertet, während zeitlose Entitäten ohne Berücksichtigung des Zeitraums der Suche oder Regel ausgewertet werden.

Das ECG führt Kontextdatensätze zusammen, indem es gemeinsame Schlüsselkennungen wie hostname, MAC address, user ID oder email address in den verschiedenen Datenquellen abgleicht. Dabei 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 EKGs 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

Wenn während des Zusammenführungsprozesses widersprüchliche Werte für eines der oben genannten Felder vorhanden sind, wird in der EKG-Pipeline der Wert mit der neuesten Startzeit für die Aktualisierung der Einheit ausgewählt.

Das EKG erstellt kontextbezogene Daten für Entitäten mit einem Lookback-Window von fünf Tagen. Bei diesem Prozess werden Daten, die zu spät eintreffen, verarbeitet und eine implizite Gültigkeitsdauer für Daten zum Kontext von Entitäten erstellt.

Das ECG unterscheidet zwischen Kontextdaten (Assets, Nutzer, Ressourcen, Gruppen) und Indikatoren für Sicherheitsrisiken (Indicators of Compromise, IOCs).

Beispiel: Nutzerdaten mit EKG-Daten zusammenführen

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

Beispiel: Redundante Daten entfernen, um eine gemeinsame Einheit zu erstellen

Um eine gemeinsame kombinierte Einheit zu erstellen, werden durch die ECG redundante Daten durch Deduplizierung entfernt. Dazu werden Zeitintervalle generiert, anstatt nach genauen Zeitstempeln zu suchen.

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

  • collected_timestamp
  • creation_timestamp
  • interval

Kritische Datenquellen für Entitäts- und Ereigniskontext-EKG-Daten

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 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 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 Datenquellen für den Entitätskontext und wichtigen UDM-Feldern:

Entitätstyp Datenquellen Wichtige UDM-Felder (für Alias 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 sind diejenigen, die als stabile Kennungen und Beziehungsindikatoren dienen (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 Einheiten
    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

EKG-Daten sind auf diese UDM-Felder angewiesen, um EKG-Daten 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 „Domain Admins“ 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 aus den Ereignisdaten Ihrer Organisation für jede Einheit in allen Namespaces. Dabei werden Aliasinformationen, Daten aus internen Anreicherungsprozessen und Sicherheitsereignisdaten verwendet, um Beziehungen herzustellen (z. B. eine asset, die eine IP address verwendet). Durch diesen Prozess wird wertvoller Kontext hinzugefügt, um Entitätsprofile zu optimieren.

Beispiel: entity.file.sha256 wird zu file (hash)-Entitäten und (principal or target).ip_geo_artifact.location.country_or_region zu network (geolocation)-Entitäten hinzugefügt.

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 Verbreitungsstatistiken und temporale Messwerte wie first-seen-time und last-seen-time zu generieren.

Statistiken zur Prävalenz

Die ECG ist auch für die Analyse vorhandener und eingehender Daten verantwortlich, 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 weniger wahrscheinlich schädlich sind.

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 so:

  • day_max ist der maximale Wert 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 ist der maximale tägliche Prävalenzwert (d. h. day_max) für das Artefakt im vorherigen 10‑Tages-Zeitraum.
  • Das System verwendet day_count, um rolling_max zu berechnen. Der Wert ist immer 10.

Wenn das System diese Werte für ein domain berechnet, ist der Unterschied zwischen day_max und day_max_sub_domains (und rolling_max und rolling_max_sub_domains) folgender:

  • rolling_max und day_max stehen für die Anzahl der eindeutigen internen IP-Adressen, die täglich 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 ECG 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 Einheiten

Google SecOps analysiert eingehende Daten, um Datensätze mit Entitätskontext 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.

Das System speichert diese Werte in den folgenden UDM-Feldern:

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 „first-seen-time“ und „last-seen-time“:

  • Für 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 Informationen zu Bedrohungen 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 zur 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 von 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.

Das System speichert diese Kontextdaten global als Entitäten. 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 können zeitbezogen oder zeitlos sein.

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

Zeitlose Datenquellen haben keinen zugehörigen Zeitraum. Das liegt daran, dass Sie nur den neuesten Datensatz berücksichtigen müssen. Das System verwendet in der Regel zeitlose Datenquellen für Daten, die sich voraussichtlich nicht ändern, z. B. Datei-Hashes. 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, weil 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. Daten zu Tor-Exit-Knoten sind zeitlich begrenzt.

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

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-Gefahrenlisten anreichern

Google SecOps erfasst Daten von Safe Browsing, 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.

Google SecOps speichert die folgenden Informationen im Datensatz zum Kontext der Identität.

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: Der Hash einer Datei wurde zwischen dem start_time und dem end_time als schädlich oder verdächtig eingestuft.
entity.metadata.threat.category Die Google SecOps-SecurityCategory. Das System legt diesen Parameter auf einen oder mehrere der folgenden Werte fest:
  • 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 dies 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

Das System führt täglich die WHOIS-Datenanreicherung als wichtige Funktion aus. WHOIS-Daten sind sowohl zeitlich als auch zeitlos.

Beim Erfassen Ihrer Gerätedaten vergleicht Google SecOps Domains mit WHOIS-Daten. Wenn Domains übereinstimmen, speichert Google SecOps die zugehörigen WHOIS-Daten im Unternehmensdatensatz der Domain. Für jede Einheit mit entity.metadata.entity_type = DOMAIN_NAME werden die WHOIS-Informationen in Google SecOps ergänzt.

Google SecOps füllt die folgenden Felder im Datensatz der Einheit 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

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, die Daten aus Global context enrichment sources (Quellen zur Anreicherung des globalen Kontexts) verwenden, um den spezifischen Anreicherungstyp oder die Quelle zu identifizieren.

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"

Einschränkungen und Vorschläge für das Kontextdiagramm für Entitäten

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

  • Fügen Sie keine Intervalle zu Entitätsdaten hinzu. Die Intervalle werden vom EKG erstellt. Das liegt daran, dass Google SecOps während der Deduplizierung Intervalle generiert, sofern nichts anderes angegeben ist.
  • Wenn Sie die Intervalle angeben, werden in Google SecOps nur dieselben 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 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