Best Practices für Suchvorgänge

Unterstützt in:

In diesem Dokument werden die von Google empfohlenen Best Practices für die Verwendung der Suchfunktion in Google Security Operations beschrieben. Suchvorgänge können erhebliche Rechenressourcen erfordern, wenn sie nicht sorgfältig erstellt werden. Die Leistung variiert auch je nach Größe und Komplexität der Daten in Ihrer Google SecOps-Instanz.

Verwenden Sie in Abfragen spezifische Filter, um die Geschwindigkeit und Leistung zu maximieren.

Die effektivste Methode, die Suchleistung zu verbessern, besteht darin, Abfragen mit bestimmten, optimierten UDM-Feldern (Unified Data Model) zu erstellen. Diese Felder sind für einen schnellen Abruf optimiert, sodass Ihre Suchanfragen schnell ausgeführt werden und weniger Rechenressourcen verbrauchen.

In den folgenden Abschnitten sind die leistungsstarken UDM-Felder aufgeführt, die Sie als Filter in Ihren Abfragen verwenden können.

Metadaten-Felder

  • metadata.event_timestamp.seconds
  • metadata.event_type
  • metadata.log_type
  • metadata.product_event_type
  • metadata.product_name
  • metadata.vendor_name

Hauptfelder

  • principal.application
  • principal.asset_id
  • principal.file.md5
  • principal.file.sha1
  • principal.file.sha256
  • principal.hostname
  • principal.ip
  • principal.mac
  • principal.process.file.md5
  • principal.process.file.sha1
  • principal.process.file.sha256
  • principal.process.pid
  • principal.user.email_addresses
  • principal.user.userid

Quellfelder

  • src.asset_id
  • src.hostname
  • src.ip
  • src.mac
  • src.user.userid

Zielfelder

  • target.application
  • target.asset_id
  • target.file.md5
  • target.file.sha1
  • target.file.sha256
  • target.hostname
  • target.ip
  • target.mac
  • target.process.file.md5
  • target.process.file.sha1
  • target.process.file.sha256
  • target.user.email_addresses
  • target.user.employee_id
  • target.user.userid
  • target.user.windows_sid

Netzwerkfelder

  • network.dhcp.chaddr
  • network.dhcp.ciaddr
  • network.dhcp.client_hostname
  • network.dhcp.yiaddr
  • network.dns.answers.class
  • network.dns.answers.name
  • network.dns.answers.type
  • network.dns.questions.class
  • network.dns.questions.name
  • network.dns.questions.type
  • network.email.from
  • network.email.to
  • network.http.method

Felder für Sicherheitsergebnisse

  • security_result.action
  • security_result.category
  • security_result.rule_name

Entitäts- und Kontextdaten abfragen

Wenn Sie mit metadata.log_type = "<LOG_TYPE>" nach Entitäts- oder Kontext-Logtypen wie AZURE_AD_CONTEXT oder WORKSPACE_USERS suchen, werden keine Ergebnisse zurückgegeben, auch wenn Rohlogs in der Rohlogsuche sichtbar sind. Das liegt daran, dass bei der UDM-Suche nur UDM-Ereignisdatensätze abgefragt werden.

Verwenden Sie die Syntax graph, um nach Entitäts- und Kontextdaten zu suchen:

  • Wenn Sie nach dem Logtyp „Entität“ oder „Kontext“ suchen möchten, fragen Sie die Metadatenfelder graph ab. Beispiel:

    graph.metadata.event_metadata.log_type = "<LOG_TYPE>"

  • Wenn Sie nach Entitätsfeldern suchen möchten, verwenden Sie das Präfix graph.entity.noun.field. Beispiel:

    graph.entity.user.email_addresses = "foo_email"

Weitere Informationen finden Sie unter Nach Kontextdaten für Entitäten suchen.

Effektive Suchanfragen für die Leistung erstellen

Das Schreiben optimierter Abfragen ist entscheidend, um die Geschwindigkeit zu maximieren und den Ressourcenverbrauch für Ihre Sicherheitsdaten zu minimieren. Alle Abfragebedingungen müssen sich strikt an diese grundlegende Struktur halten:

udm-field operator value

Beispiel: principal.hostname = "win-server"

Da Google SecOps während einer Suche eine große Datenmenge aufnehmen kann, können Sie die Suchleistung verbessern, indem Sie den Zeitraum minimieren und den Umfang Ihrer Abfrage eingrenzen.

Reguläre Ausdrücke in Suchanfragen verwenden

Sie können beim Erstellen Ihrer UDM-Suchanfragen logische und Vergleichsoperatoren verwenden, um komplexe Ausdrücke zu erstellen:

  • Logische Operatoren: Verwenden Sie AND, OR und NOT, um Bedingungen zu kombinieren. Wenn Sie zwischen zwei Bedingungen keinen Operator angeben, wird AND angenommen.
  • Operatorrangfolge: Verwenden Sie Klammern (), um die Standardrangfolge zu überschreiben. Sie können maximal 169 logische Operatoren (OR, AND, NOT) innerhalb von Klammern verwenden.
  • Vergleichsoperatoren: Je nach UDM-Feldtyp (String, Ganzzahl, Zeitstempel) können Feldoperatoren Folgendes umfassen: =, !=, >=, >, <, <=

Google SecOps verwendet die RE2-Engine für reguläre Ausdrücke.

Alternativ können Sie für die effiziente Suche in einer großen Anzahl von Werten die Referenzlisten verwenden.

nocase als Suchmodifikator verwenden

Sie können den Modifikator nocase an eine Bedingung für den Stringvergleich anhängen, um die Suche unabhängig von der Groß- und Kleinschreibung zu machen.

Bei der folgenden Suche wird beispielsweise die Groß-/Kleinschreibung ignoriert und alle Kombinationen, die tim.smith enthalten, werden unabhängig von der Groß-/Kleinschreibung berücksichtigt:

target.user.userid = "TIM.SMITH" nocase

Verwendung regulärer Ausdrücke in Aufzählungsfeldern vermeiden

Sie können keine regulären Ausdrücke verwenden, wenn Sie in Aufzählungsfeldern (Feldern mit einem Bereich vordefinierter Werte) wie metadata.event_type oder network.ip_protocol suchen.

Das folgende Beispiel ist eine ungültige Suche: metadata.event_type = /NETWORK_*/

Das folgende Beispiel ist dagegen eine gültige Suche: (metadata.event_type = "NETWORK_CONNECTION" oder metadata.event_type = "NETWORK_DHCP")

Verwenden Sie beliebige Operatoren im Feld „Ereignisse“.

In der Suche werden einige UDM-Felder (z. B. principal.ip oder target.file.md5) als wiederholt gekennzeichnet, da sie eine Liste von Werten oder Nachrichtentypen innerhalb eines einzelnen Ereignisses enthalten können. Wiederkehrende Felder werden standardmäßig immer mit dem Operator any behandelt (es gibt keine Option, all anzugeben).

Wenn der Operator any verwendet wird, wird das Prädikat als true ausgewertet, wenn ein Wert im wiederholten Feld die Bedingung erfüllt. Wenn Sie beispielsweise nach principal.ip != "1.2.3.4" suchen und Ereignisse in Ihrer Suche sowohl principal.ip = "1.2.3.4" als auch principal.ip = "5.6.7.8" enthalten, wird eine Übereinstimmung generiert. Dadurch wird Ihre Suche auf Ergebnisse ausgeweitet, die mit einem der Operatoren übereinstimmen, anstatt mit allen.

Jedes Element im wiederkehrenden Feld wird einzeln behandelt. Wenn das wiederkehrende Feld in Ereignissen in der Suche gefunden wird, werden die Ereignisse für jedes Element im Feld ausgewertet. Dies kann zu unerwartetem Verhalten führen, insbesondere bei der Suche mit dem Operator !=.

Wenn Sie den Operator any verwenden, wird das Prädikat als true ausgewertet, wenn ein Wert im wiederkehrenden Feld die Bedingung erfüllt.

Verwenden Sie die Unix-Epochenzeit für Zeitstempel oder YARA-L-Funktionen für die Datumskonvertierung.

Zeitstempelfelder werden mithilfe der Unix-Epochenzeit (die Gesamtzahl der Sekunden, die seit Donnerstag, dem 1. Januar 1970, 00:00:00 Uhr UTC vergangen sind) abgeglichen. Alternativ können Sie YARA-L-Funktionen für die Datumskonvertierung verwenden.

Wenn Sie nach einem bestimmten Zeitstempel suchen, ist Folgendes (in Epochenzeit) gültig:

metadata.ingested_timestamp.seconds = 1660784400

Der folgende Zeitstempel ist ungültig:

metadata.ingested_timestamp = "2022-08-18T01:00:00Z"

Wenn Sie nach einem bestimmten Zeitstempel suchen, ist Folgendes gültig (mit einer YARA-L-Funktion für die Datumskonvertierung):

metadata.event_type = "NETWORK_CONNECTION"
timestamp.get_date(metadata.ingested_timestamp.seconds) = "2026-03-15"

Im folgenden YARA-L-Beispiel werden timestamp-Funktionen verwendet, um nach Zeiträumen für die Aufnahme zu suchen:

metadata.event_type = "NETWORK_CONNECTION"
$date = timestamp.get_date(metadata.ingested_timestamp.seconds)
$date > "2026-03-15" AND $date < "2026-03-17"

Neu aufgenommene Daten mit älteren Zeitstempeln abfragen

Sie können nicht nach neu aufgenommenen Ereignissen mit einem älteren Zeitstempel suchen, es sei denn, Sie geben den Zeitraum für die Abfrage an. Das liegt daran, dass der Zeitraum auf dem Zeitstempel des geparsten Ereignisses basiert und nicht auf dem Zeitstempel der Aufnahme des Rohprotokollereignisses.

Wenn Sie in UDM-Ereignissen nach aufgenommenen Logs mit älteren Ereigniszeitstempeln suchen möchten, können Sie die Option Gesamte Zeit verwenden, um in metadata.ingested_timestamp zu suchen und Abfragen auszuführen.

Ausgeschlossene Felder aus Filtern

Die folgenden Felder werden absichtlich aus den Suchfiltern ausgeschlossen:

  • metadata.id
  • metadata.product_log_id
  • *.timestamp

Diese Felder enthalten zwar wichtige Metadaten, aber ihre eindeutigen Werte führen zu einer hohen Kardinalität und Varianz in den Statistiken, was sich negativ auf die Suchleistung auswirkt.

Fehlerbehebung

Wenn Sie eine allgemeine Fehlermeldung wie „Fehler: Bei der Suche ist ein Fehler aufgetreten und die Daten konnten nicht geladen werden“ erhalten, führen Sie die folgenden Schritte aus, um das Problem zu beheben. Wenn der Fehler weiterhin auftritt, wende dich an den Kundensupport.

  • Stellen Sie über ein anderes Netzwerk eine Verbindung zu Google SecOps her. Verwenden Sie beispielsweise eine Cloud-VM, um Netzwerkprobleme zu identifizieren.
  • Achten Sie darauf, dass Chronicle API-Aufrufe durch die Firewall- oder Proxy-Konfiguration oder die Richtlinie Ihrer Organisation zugelassen werden.
  • Achten Sie darauf, dass für Search API-Aufrufe kein Datenlimit konfiguriert ist, da Suchanfragen große Datasets zurückgeben können.
  • Suchanfragen können asynchron ausgeführt werden und es kann länger dauern, bis Daten zurückgegeben werden. Sie können sich zuvor ausgeführte Suchanfragen im Verlauf in der Google Suche ansehen und auswählen, um die Ergebnisse später aufzurufen.

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