Joins in der Suche und in Dashboards anwenden

Unterstützt in:

Mithilfe von Joins lassen sich Daten aus mehreren Quellen korrelieren, um mehr Kontext für eine Untersuchung zu liefern. 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 Search und in den Dashboard-Bereichen von Google SecOps verwenden. Darin werden die unterstützten Join-Typen, Anwendungsfälle und Best Practices beschrieben.

Wichtige Konzepte für Joins

Sie können einen Join erstellen, indem Sie Datenquellen über gemeinsame Platzhaltervariablen oder explizite Gleichheitsanweisungen (z. B. $e1.hostname = $e2.hostname) verbinden. Wenn Sie einen Join im match-Abschnitt einer statistikbasierten Abfrage definieren, müssen Sie Platzhaltervariablen verwenden.

In den folgenden Beispielen wird gezeigt, wie Sie Datenquellen mit zwei Feldern, 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

Die Beispiele in diesem Abschnitt veranschaulichen die in Search verwendete Syntax.

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

Join zwischen Ereignissen

  • Bei einem Event-Event-Join werden zwei verschiedene UDM-Ereignisse (Unified Data Model) verknüpft. Im folgenden Beispiel wird ein USER_LOGIN-Ereignis mit einem anderen Ereignis verknüpft, um den Hostnamen (altostrat) zu ermitteln, 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-EKG-Join

  • Durch eine Event-ECG-Verknüpfung wird ein UDM-Ereignis mit einer Einheit aus dem Entity Context Graph (ECG) verknüpft. Mit der folgenden Beispielabfrage werden ein NETWORK_CONNECTION-Ereignis und ein ASSET aus dem Entitätsdiagramm gefunden, die innerhalb eines Zeitfensters von 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

Verknüpfung von Datentabellenereignissen

  • Bei einem Datentabellen-Ereignis-Join werden UDM-Ereignisse mit Einträgen in einer benutzerdefinierten Datentabelle verknüpft. Das ist nützlich, um Live-Ereignisdaten mit einer benutzerdefinierten Liste abzugleichen, z. B. mit bekannten schädlichen IP-Adressen oder Bedrohungsakteuren. In der folgenden Beispielabfrage werden NETWORK_CONNECTION-Ereignisse mit einer Datentabelle verknüpft, 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

IN-Klausel mit Datentabellen verwenden

Mit der in-Klausel können Sie auch 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 wichtige Systemdatei löscht. Das könnte auf eine Kontoübernahme oder böswillige Insideraktivitäten hindeuten.

Join-Typ: Event-Event-Join

Beschreibung: Bei dieser Abfrage werden zwei unterschiedliche Ereignisse verknüpft, die für sich genommen nicht verdächtig sind, aber in Kombination sehr verdächtig werden. Zuerst wird nach einem USER_LOGIN-Ereignis und dann nach einem FILE_DELETION-Ereignis gesucht. Diese werden durch das gemeinsame user.userid mit einem kurzen Zeitfenster verbunden.

  • 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

Riskante 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 type: Event-ECG join

Beschreibung: Eine einzelne Netzwerkverbindung zu einer seltenen Domain hat möglicherweise keine hohe Priorität. Durch diese Anfrage wird die Bedeutung dieses Ereignisses jedoch erhöht, da es mit dem Entity Context Graph (ECG) verknüpft wird. Es wird speziell nach NETWORK_CONNECTION-Ereignissen gesucht, die von Assets stammen, die im Entity-Diagramm als „Critical Database Server“ (Kritischer Datenbankserver) gekennzeichnet sind.

  • Abfrage für riskante 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 aktiven DNS-Abfragen mit einer Liste von Domains abgeglichen werden, die bekanntermaßen von einem bestimmten Bedrohungsakteur verwendet werden.

Join type (Verknüpfungstyp): Datatable-Event join (Verknüpfung von Datentabelle und Ereignis)

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

  • Suchanfrage für die 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 Korrelationszeiträume als Search. Im Gegensatz zu Standard-SQL-Abfragen werden in YARA-L 2.0 keine expliziten JOIN-Anweisungen verwendet. Stattdessen werden Datenquellen durch Korrelieren gemeinsamer Platzhaltervariablen oder durch Verwendung von mehrstufigen Abfragen verbunden.

Berücksichtigung der Groß-/Kleinschreibung

Bei Dashboard-Abfragen wird zwischen Groß- und Kleinschreibung unterschieden. Wenn Sie in einem Dashboard einen Join oder eine Suche ohne Berücksichtigung der Groß-/Kleinschreibung durchführen möchten, verwenden Sie den Modifikator nocase.

Unterstützte Datenquellen

In Dashboards können Sie Daten aus unterstützten Join-Kombinationen von Datenquellen zusammenführen. Nicht alle Kombinationen von Datenquellen können in einer einzigen Abfrage zusammengeführt werden.

Jeder Datenverweis in einer Multi-Source-Dashboard-Abfrage muss den YARA-L-Präfixqualifizierer (z. B. $u1) enthalten, nicht nur die verknüpften Felder. So kann das System die Inhaberschaft von Feldern bei sich überschneidenden Datenquellen richtig identifizieren.

Unterstützte Join-Kombinationen

Mit Joins können Sie UDM-Ereignisse, Entitätskontext und Datentabellen in integrierten Dashboards in Beziehung setzen. Damit die Systemleistung nicht beeinträchtigt wird, sollten Sie sich vor dem Erstellen von Abfragen die unterstützten Kombinationen und technischen Einschränkungen in diesem Abschnitt ansehen.

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

  • Fall- und Fallverlauf: Diese Kombination ist auf genau eine case-Quelle und eine case_history-Quelle beschränkt. Sie können keine anderen Datenquellen in diese Zusammenführung einbeziehen.

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

Beispiel: Join von „case“ und „case_history“

Sie können Fallmetadaten mit dem zugehörigen Aktivitätsverlauf in Beziehung setzen, indem Sie die eindeutige Fall-ID verwenden.

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

      // 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 Lösungszeit (Mean Time to Resolve, MTTR) oder die durchschnittliche Schließzeit (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 endgültigen Ergebnisblock global mitteln.

  • Mit der folgenden Abfrage wird die durchschnittliche Zeit zum Schließen von Anfragen (in Minuten) für alle Anfragen 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

Wenn Sie die Leistung Ihrer Join-Abfragen optimieren und dafür sorgen möchten, dass sie effizient verarbeitet werden, sollten Sie diese Best Practices zum Filtern von Ereignissen und Verwalten des Suchbereichs befolgen.

Mit bestimmten Filtern können Sie die Anzahl der Ereignisse reduzieren.

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

  • Bei allgemeinen Filtern kann es zu Fehlern bei Abfragen kommen, manchmal erst nach langer Verzögerung. Beispiele:

    • 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 allgemeiner 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 die 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 YARA-L-Best Practices.

Technische Limits und Einschränkungen

Für Joins in Search und Dashboards gelten die folgenden Einschränkungen und Limits.

Abgleichszeitraum und Abfragelimits

Das Abgleichszeitfenster definiert den spezifischen Zeitraum, in dem Ereignisse abgeglichen werden. Das ist etwas anderes als der Suchzeitraum, den Sie in der Benutzeroberfläche auswählen.

Die Suche ist für Live- oder schnelle Untersuchungen über kürzere Zeiträume optimiert.

Abfragelimit Nutzung
Bis zu 48 Stunden (bei einigen Anfragen sind möglicherweise längere Zeiträume möglich). 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.
Case-to-CaseHistory 90 Tage Anfragen zum Lebenszyklus-Tracking.
Weitere unterstützte Konfigurationen Bis zu 365 Tage Fallback für nicht UDM- oder messwertbasierte Quellen (z. B. Aufnahmemesswerte).

Datenquellen- und Tabellengrenzwerte

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

Suchbeschränkungen

  • Pro Abfrage können Sie maximal zwei UDM-Ereignisse verwenden.
  • Pro Anfrage können Sie maximal ein EKG-Ereignis verwenden.
  • Pro Abfrage können Sie maximal zwei Datatables verwenden.
  • Sie können eine Datentabelle nicht direkt mit einer Tabelle mit dem Kontext einer Einheit 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.

Dashboard-Einschränkungen

Join-Typ Maximale Anzahl von Ereignistabellen (UDM oder Datentabelle) Maximale Anzahl von Entitätstabellen
Multi-Event (UDM zu UDM) 2 –
UDM-Entität 2 1
UDM in 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 Ressourcensicherheitsschwellen überschreiten, möglicherweise automatisch pausiert oder unter Quarantäne gestellt.

Wenn eine Abfrage fehlschlägt oder Fehler zurückgibt, die darauf hinweisen, dass Ressourcenlimits überschritten wurden, versuchen Sie die folgenden Optimierungen:

  • Verkleinern Sie den Zeitraum der Abfrage.
  • Fügen Sie spezifischere Filter hinzu, um die Dataset-Größe vor dem Join zu reduzieren.
  • 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