Joins in der Suche und in Dashboards anwenden

Unterstützt in:

Mit Joins können Daten aus mehreren Quellen korreliert werden, um mehr Kontext für eine Untersuchung zu erhalten. Durch das Verknüpfen von zusammengehörigen Ereignissen, Entitäten und anderen Daten können Sie komplexe Angriffsszenarien untersuchen und Trends visualisieren.

In diesem Dokument wird erläutert, wie Sie den Join-Vorgang im Feld Suche von Google SecOps und in Dashboard-Panels verwenden. Es werden die unterstützten Join-Typen, Anwendungsfälle und Best Practices behandelt.

Grundlegende Konzepte von Joins

Sie können einen Join erstellen, indem Sie Datenquellen mit gemeinsamen Platzhaltervariablen oder expliziten Gleichheitsanweisungen verknüpfen (z. B. $e1.hostname = $e2.hostname). Wenn Sie einen Join im Abschnitt match einer statistikbasierten Abfrage definieren, müssen Sie Platzhaltervariablen verwenden.

In den folgenden Beispielen wird gezeigt, wie Sie Datenquellen mit zwei Feldern mit einem Gleichheitszeichen (=) und einer gemeinsamen Platzhaltervariablen verknüpfen.

  • Beispiel 1: Impliziter Join mit Platzhaltervariablen

    events:
  // Assign a value from the first event to the placeholder variable $user
  $user = $e1.principal.user.userid

  // The second assignment creates an implicit join, linking $e2 to $e1
  // where the user ID is the same.
  $user = $e2.principal.user.userid

match:
  $user over 1h

condition:
  $e1 and $e2

  • Beispiel 2: Expliziter Join mit Gleichheit und Platzhaltern

    $e1.principal.ip = $ip
$e1.metadata.event_type = "USER_LOGIN"
$e1.principal.hostname = $host

$e2.target.ip = $ip
$e2.principal.hostname = "altostrat"
$e2.target.hostname = $host

match:
  $ip, $host over 5m

In den Beispielen in diesem Abschnitt wird die Syntax veranschaulicht, die in der Suche verwendet wird.

Bei Abfragen in der Suche wird standardmäßig die Groß- und Kleinschreibung nicht berücksichtigt.

Ereignis-Ereignis-Join

  • Ein Ereignis-Ereignis-Join verbindet zwei verschiedene Universal Data Model (UDM)-Ereignisse. Die folgende Beispielabfrage verknüpft ein USER_LOGIN-Ereignis mit einem anderen Ereignis, um den Hostnamen (altostrat) zu finden, mit dem der Nutzer interagiert hat. Grundlage dafür ist eine gemeinsame IP-Adresse:

    $e1.principal.ip = $ip
$e1.metadata.event_type = "USER_LOGIN"

$e2.target.ip = $ip
$e2.principal.hostname = "altostrat"

match:
  $ip over 5m

Ereignis-ECG-Join

  • Ein Ereignis-ECG-Join verbindet ein UDM-Ereignis mit einer Entität aus dem Entity Context Graph (ECG). Die folgende Beispielabfrage sucht nach einem NETWORK_CONNECTION-Ereignis und einem ASSET aus dem Entitätsdiagramm, die innerhalb einer Stunde denselben Hostnamen haben:

    events:
  $e1.metadata.event_type = "NETWORK_CONNECTION"
  $g1.graph.metadata.entity_type = "ASSET"
  $e1.principal.asset.hostname = $g1.graph.entity.asset.hostname
  $x = $g1.graph.entity.asset.hostname

match:
  $x over 1h

condition:
  $e1 and $g1

Datentabelle-Ereignis-Join

  • Ein Datentabelle-Ereignis-Join verbindet UDM-Ereignisse mit Einträgen in einer benutzerdefinierten Datentabelle. Das ist nützlich, um Live-Ereignisdaten mit einer benutzerdefinierten Liste zu vergleichen, z. B. mit bekannten schädlichen IP-Adressen oder Angreifern. Die folgende Beispielabfrage verknüpft NETWORK_CONNECTION-Ereignisse mit einer Datentabelle, um Verbindungen mit bestimmten IP-Adressen aus dieser Liste zu finden:

    $ip = %DATATABLE_NAME.COLUMN_NAME
$ip = $e1.principal.ip
$e1.metadata.event_type = "NETWORK_CONNECTION"

match:
  $ip over 1h

Die IN-Klausel mit Datentabellen verwenden

Sie können auch die Anweisung in verwenden, um zu prüfen, ob ein Feldwert in einer Datentabellenspalte vorhanden ist. Diese Syntax wird für alle Datenquellen unterstützt (z. B. ioc.type in %abc.type) und bietet eine praktische Möglichkeit, Ereignisse anhand von Referenzlisten zu filtern, ohne explizite Platzhaltervariablen für den Join zu definieren.

Gängige Anwendungsfälle

In diesem Abschnitt werden einige gängige Möglichkeiten zur Verwendung von Joins aufgeführt.

Diebstahl und Verwendung von Anmeldedaten erkennen

Ziel: Instanzen finden, in denen sich ein Nutzer erfolgreich anmeldet und dann schnell eine kritische Systemdatei löscht. Das könnte auf eine Kontoübernahme oder böswillige Insideraktivitäten hindeuten.

Join-Typ: Ereignis-Ereignis-Join

Beschreibung: Diese Abfrage verbindet zwei unterschiedliche Ereignisse, die an sich nicht verdächtig sind , aber sehr verdächtig werden, wenn sie zusammen auftreten. Zuerst wird nach einem USER_LOGIN-Ereignis und dann nach einem FILE_DELETION-Ereignis gesucht. Diese werden durch die gemeinsame user.userid mit einem kurzen Zeitfenster verknüpft.

  • Abfrage zur Erkennung von Diebstahl von Anmeldedaten

    // Event 1: A user successfully logs in
$e1.metadata.event_type = "USER_LOGIN"
$e1.security_result.action = "ALLOW"
$e1.principal.user.userid = $user

// Event 2: The same user deletes a critical file
$e2.metadata.event_type = "FILE_DELETION"
$e2.target.file.full_path = /etc\/passwd|C:\\Windows\\System32\\/
$e2.principal.user.userid = $user

match:
  $user over 10m

condition:
  $e1 and $e2

Risikoreiche Verbindungen von kritischen Assets identifizieren

Ziel: Live-Netzwerkdaten mit Asset-Informationen anreichern, um ausgehende Verbindungen von Servern zu finden, die nicht mit externen Domains mit geringer Prävalenz kommunizieren sollten (z. B. ein Produktionsdatenbankserver).

Join-Typ: Ereignis-ECG-Join

Beschreibung: Eine einzelne Netzwerkverbindung zu einer seltenen Domain ist möglicherweise keine hohe Priorität. Mit dieser Abfrage wird die Bedeutung dieses Ereignisses jedoch erhöht, indem es mit dem Entity Context Graph (ECG) verknüpft wird. Es wird speziell nach NETWORK_CONNECTION-Ereignissen gesucht, die von Assets stammen, die im Entitätsdiagramm als „Critical Database Server“ gekennzeichnet sind.

  • Abfrage für risikoreiche Verbindungen

    events:
  $e.metadata.event_type = "NETWORK_CONNECTION"
  $e.target.domain.prevalence.day_count <= 5

  $asset.graph.metadata.entity_type = "ASSET"
  $asset.graph.entity.asset.labels.value = "Critical Database Server"

  $e.principal.asset.hostname = $asset.graph.entity.asset.hostname
  $host = $e.principal.asset.hostname

match:
  $host over 1h

condition:
  $e and $asset

Nach IOCs von Angreifern suchen

Ziel: Aktiv nach Indicators of Compromise (IoCs) suchen, indem alle Live-DNS-Abfragen mit einer Liste von Domains verglichen werden, die bekanntermaßen von einem bestimmten Angreifer verwendet werden.

Join-Typ: Datentabelle-Ereignis-Join

Beschreibung: Ihr Team für Threat Intelligence verwaltet eine Datentabelle mit dem Namen ThreatActor_Domains, in der schädliche Domains aufgeführt sind. Mit dieser Abfrage werden alle NETWORK_DNS_QUERY-Ereignisse in Echtzeit mit dieser Datentabelle verknüpft. So wird sofort jede Instanz angezeigt, in der ein Host in Ihrem Netzwerk versucht, eine Domain aus Ihrer Threat Intelligence-Liste aufzulösen.

  • Abfrage zur Suche nach IOCs von Angreifern

    // Datatable: Get the list of malicious domains
$domain = %DATATABLE_NAME.COLUMN_NAME

// Event: A DNS query is made
$e.metadata.event_type = "NETWORK_DNS"
$e.network.dns.questions.name = $domain

match:
  $domain over 5m

condition:
  $e

Joins in Dashboards

Dashboards unterstützen eine größere Auswahl an Datenquellen und längere Korrelationsfenster als in der Suche. Im Gegensatz zu Standard-SQL-Abfragen werden in YARA-L 2.0 keine expliziten JOIN-Anweisungen verwendet. Stattdessen werden Datenquellen verknüpft, indem gemeinsame Platzhaltervariablen korreliert oder mehrstufige Abfragen verwendet werden.

Berücksichtigung der Groß-/Kleinschreibung

Bei Dashboard-Abfragen wird die Groß- und Kleinschreibung berücksichtigt. Wenn Sie in einem Dashboard einen Join oder eine Suche durchführen möchten, bei der die Groß- und Kleinschreibung nicht berücksichtigt wird, verwenden Sie den Modifikator nocase.

Unterstützte Datenquellen

In Dashboards können Sie Daten aus unterstützten Join-Kombinationen von Datenquellen verknüpfen. Nicht alle Kombinationen von Datenquellen können in einer einzigen Abfrage verknüpft werden.

Jede Datenreferenz in einer Dashboard-Abfrage mit mehreren Quellen muss das YARA-L-Präfixqualifizierer enthalten (z. B. $u1) und nicht nur die verknüpften Felder. So kann das System die Feldinhaberschaft überlappender Datenquellen hinweg korrekt identifizieren.

Unterstützte Join-Kombinationen

Mit Joins können Sie UDM-Ereignisse, Entitätskontext und Datentabellen in integrierten Dashboards korrelieren. Um die Systemleistung aufrechtzuerhalten, sollten Sie sich vor dem Erstellen Ihrer Abfragen die unterstützten Kombinationen und technischen Limits in diesem Abschnitt ansehen.

  • UDM-Ereignis zu UDM-Ereignis (mehrere Ereignisse)
  • UDM-Ereignis zu Entitätskontext
  • UDM-Ereignis zu Datentabelle

  • Fall zu Fallverlauf: Diese Kombination ist auf genau eine case Quelle und eine case_history Quelle beschränkt. Sie können keine anderen Datenquellen in diesen Join einbeziehen.

Informationen zu Limits und Schutzmaßnahmen finden Sie unter Technische Limits und Einschränkungen.

Beispiel: Fall und Fallverlauf verknüpfen

Sie können Fallmetadaten mit dem zugehörigen Aktivitätsverlauf korrelieren, indem Sie einen Join mit der eindeutigen Fall-ID durchführen.

  • Im folgenden Beispiel werden die Datenquellen case und case_history verknüpft, um die Gesamtzahl der bisherigen Aktionen für jeden Fall mit hoher Priorität zu zählen.

      // 1. Establish the Join using a shared placeholder variable ($case_id)
  $h.case_history.case_response_platform_info.case_id = $case_id
  $c.case.response_platform_info.response_platform_id = $case_id

  // 2. Apply Filters
  $c.case.priority = "PRIORITY_HIGH"

  // 3. Group the correlated data by the Case ID
  match:
    $case_id

  // 4. Calculate the selected metrics to display on the dashboard
  outcome:
    $case_name = array_distinct($c.case.display_name)
    $total_historical_actions = count($h.case_history.case_activity)

Erweiterter Anwendungsfall: MTTR berechnen

Für komplexere Messwerte wie die durchschnittliche Zeit bis zur Lösung (Mean Time to Resolve, MTTR) oder die durchschnittliche Zeit bis zum Abschluss (Mean Time to Close, MTTC) können Sie eine mehrstufige Abfrage verwenden. So können Sie die Dauer für jeden einzelnen Fall in der ersten Phase berechnen und diese Dauern dann im letzten Ergebnisblock global mitteln.

  • Mit der folgenden Abfrage wird die durchschnittliche Zeit bis zum Schließen von Fällen (in Minuten) für alle Fälle in der Standardumgebung berechnet.

    stage stage1 {
  // 1. Establish the Join
  $h.case_history.case_response_platform_info.case_id = $case_id
  $c.case.response_platform_info.response_platform_id = $case_id

  // 2. Filter by specific environment
  $c.case.environment = "Default Environment"

  // 3. Group by Case ID to process per case
  match:
    $case_id

  // 4. Calculate the Time to Close (TTC) for each case individually
  outcome:
    $case_close_time = max(if($h.case_history.case_activity = "CLOSE_CASE", $h.case_history.event_time.seconds, 0))
    $status = array_distinct($h.case_history.case_activity)

    // Subtract the very first event time (creation) from the close time
    $TTC = $case_close_time - min($h.case_history.event_time.seconds)

  // 5. Filter to ensure the case has a complete lifecycle
  condition:
    arrays.contains($status, "CREATE_CASE") and
    arrays.contains($status, "CLOSE_CASE")
}

// 6. Global Aggregation: Calculate the Mean (Average) across all processed cases
outcome:
  $case_count = count($stage1.case_id)
  $MTTC = (math.round(avg($stage1.TTC) / 60))

Best Practices

Um die Leistung Ihrer Join-Abfragen zu optimieren und sicherzustellen, dass sie effizient verarbeitet werden, sollten Sie diese Best Practices zum Filtern von Ereignissen und Verwalten des Suchbereichs befolgen.

Spezifische Filter verwenden, um die Anzahl der Ereignisse zu reduzieren

Join-Abfragen können ressourcenintensiv sein, da sie viele Ergebnisse kombinieren.

  • Breite, allgemeine Filter können dazu führen, dass Abfragen fehlschlagen, manchmal nach langer Verzögerung, z. B.:

    • target.ip != ""

    • metadata.event_type = "NETWORK_CONNECTION" (wenn dieser Ereignistyp in Ihrer Umgebung sehr häufig vorkommt)

  • Wir empfehlen, allgemeine Filter mit spezifischeren zu kombinieren, um die Gesamtzahl der Ereignisse zu reduzieren, die von der Abfrage verarbeitet werden müssen. Ein breiter Filter wie target.ip != "" sollte mit spezifischeren Filtern kombiniert werden, um die Leistung der Abfrage zu verbessern, z. B.:

    $e1.metadata.log_type = $log
$e1.metadata.event_type = "USER_LOGIN"
$e1.target.ip != ""

$e2.metadata.log_type = $log
$e2.principal.ip = "10.0.0.76"
$e2.target.hostname != "altostrat"

match:
$log over 5m

Wenn Ihre Abfrage immer noch langsam ist, können Sie auch den Gesamtzeitraum der Abfrage verkürzen (z. B. von 30 Tagen auf eine Woche).

Weitere Informationen finden Sie unter Best Practices für YARA-L.

Technische Limits und Einschränkungen

Die folgenden Einschränkungen und Limits gelten, wenn Sie Joins in der Suche und in Dashboards verwenden.

Fenster- und Abfragelimits

Das Fenster definiert den spezifischen Zeitraum, in dem Ereignisse korreliert werden sollen. Das unterscheidet sich vom Suchzeitraum , den Sie in der Benutzeroberfläche auswählen.

Die Suche ist für Live- oder schnelle Untersuchungen in kürzeren Zeiträumen optimiert.

Abfragelimit Nutzung
Bis zu 48 Stunden (einige Abfragen unterstützen möglicherweise längere Zeiträume). Ereignisse bei schnellen Untersuchungen korrelieren.

Limits in Dashboards

Dashboards unterstützen langfristige historische Analysen.

Join-Typ Abfragelimit Nutzung
UDM zu UDM und UDM zu Entität 31 Tage Telemetrieabfragen mit hohem Volumen.
Fall zu Fallverlauf 90 Tage Abfragen zur Lebenszyklusverfolgung.
Andere unterstützte Konfigurationen Bis zu 365 Tage Fallback für nicht UDM- oder messwertbasierte Quellen (z. B. Aufnahmemesswerte).

Limits für Datenquellen und Tabellen

Die maximale Anzahl von Datenquellen und Tabellen, die Sie in einer einzigen Abfrage verknüpfen können, hängt davon ab, ob Sie die Suche oder Dashboards verwenden.

Einschränkungen für die Suche

  • Sie können maximal zwei UDM-Ereignisse pro Abfrage verwenden.
  • Sie können maximal ein ECG-Ereignis pro Abfrage verwenden.
  • Sie können maximal zwei Datentabellen pro Abfrage verwenden.
  • Sie können eine Datentabelle nicht direkt mit einer Entitätskontexttabelle verknüpfen. Sie müssen ein UDM-Ereignis als Zwischenbrücke verwenden (z. B. $event.target.hostname mit $datatable.hostname und $asset.graph.entity.asset.hostname korrelieren).

Einschränkungen für Dashboards

Join-Typ Maximale Anzahl von Ereignistabellen (UDM oder Datentabelle) Maximale Anzahl von Entitätstabellen
Mehrere Ereignisse (UDM zu UDM) 2 –
UDM zu Entität 2 1
UDM zu Datentabelle 2 –
Mehrstufige Abfragen 2 1

Leistung und Schutzmaßnahmen

Das System überwacht komplexe Join-Abfragen auf übermäßigen Ressourcenverbrauch. Um die Gesamtleistung der Umgebung zu schützen, werden Abfragen, die die Grenzwerte für die Ressourcensicherheit überschreiten, möglicherweise automatisch pausiert oder in Quarantäne verschoben.

Wenn eine Abfrage fehlschlägt oder Fehler zurückgibt, die darauf hindeuten, dass die Ressourcengrenzwerte überschritten wurden, versuchen Sie Folgendes:

  • Verkürzen Sie das Zeitfenster der Abfrage.
  • Fügen Sie spezifischere Filter hinzu, um die Dataset-Größe zu reduzieren, bevor der Join ausgeführt wird.
  • Vereinfachen Sie Ihre Aggregationen.

Einschränkungen für API- und Abfragetypen

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