Best Practices für Suchvorgänge

Unterstützt in:

In diesem Dokument werden die von Google empfohlenen Best Practices für die Verwendung der Funktion Suche 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.

Spezifische Filter in Abfragen verwenden, um Geschwindigkeit und Leistung zu maximieren

Die effektivste Möglichkeit, die Suchleistung zu verbessern, besteht darin, Abfragen mit spezifischen, optimierten Feldern des einheitlichen Datenmodells (Unified Data Model, UDM) zu erstellen. Diese Felder sind für den schnellen Abruf optimiert, sodass Ihre Suchvorgänge 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.

Hauptfelder

  • principal.asset.hostname
  • principal.asset.ip
  • principal.asset.mac
  • 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.parent_process.file.md5
  • principal.process.parent_process.file.sha1
  • principal.process.parent_process.file.sha256
  • principal.user.email_addresses
  • principal.user.product_object_id
  • principal.user.userid
  • principal.user.windows_sid

Quellfelder

  • source.user.userid
  • src.asset.hostname
  • src.hostname
  • src.ip

Zielfelder

  • target.asset.hostname
  • target.file.md5
  • target.file.sha1
  • target.file.sha256
  • target.hostname
  • target.ip
  • target.process.file.md5
  • target.process.file.sha1
  • target.process.file.sha256
  • target.user.email_addresses
  • target.user.product_object_id
  • target.user.userid
  • target.user.windows_sid

Zusätzliche Felder

  • about.file.md5
  • about.file.sha1
  • about.file.sha256
  • intermediary.hostname
  • intermediary.ip
  • network.dns.questions.name
  • network.email.from
  • network.email.to
  • observer.hostname
  • observer.ip

Entitäts- und Kontextdaten abfragen

Wenn Sie mit metadata.log_type = "<LOG_TYPE>" nach Entitäts- oder Kontextprotokolltypen suchen (z. B. AZURE_AD_CONTEXT oder WORKSPACE_USERS), werden keine Ergebnisse zurückgegeben, auch wenn Rohprotokolle in der Rohprotokollsuche sichtbar sind. Das liegt daran, dass bei der UDM-Suche nur UDM-Ereignisdatensätze abgefragt werden.

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

  • Wenn Sie nach einem Entitäts- oder Kontextprotokolltyp suchen möchten, fragen Sie die graph-Metadatenfelder ab. Beispiel:

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

  • Verwenden Sie das Präfix graph.entity.noun.field, um nach Entitätsfeldern zu suchen. Beispiel:

    graph.entity.user.email_addresses = "foo_email"

Weitere Informationen finden Sie unter Nach Entitätskontextdaten suchen.

Effektive Suchabfragen für die Leistung erstellen

Optimierte Abfragen sind entscheidend, um die Geschwindigkeit zu maximieren und den Ressourcenverbrauch für Ihre Sicherheitsdaten zu minimieren. Alle Abfragebedingungen müssen dieser grundlegenden Struktur entsprechen:

udm-field operator value

Beispiel: principal.hostname = "win-server"

Da Google SecOps bei einer Suche eine große Menge an Daten aufnehmen kann, kann die Suchleistung verbessert werden, indem Sie den Zeitbereich minimieren und den Umfang Ihrer Abfrage eingrenzen.

Reguläre Ausdrücke in Suchabfragen verwenden

Sie können beim Erstellen Ihrer UDM-Suchabfragen standardmäßige logische Operatoren und Vergleichsoperatoren verwenden, um komplexe Ausdrücke zu erstellen:

  • Logische Operatoren: Verwenden Sie AND, OR und NOT, um Bedingungen zu kombinieren. AND wird angenommen, wenn Sie zwischen zwei Bedingungen keinen Operator angeben.
  • Operatorpriorität: Verwenden Sie Klammern (), um die Standardreihenfolge der Priorität zu überschreiben. Es gibt ein Limit von 169 logischen Operatoren (OR, AND, NOT), die Sie in Klammern verwenden können.
  • 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 die Referenzlisten verwenden, um effizient in einer großen Menge von Werten zu suchen.

nocase als Suchmodifikator verwenden

Sie können den Modifikator nocase an eine Stringvergleichsbedingung anhängen, um die Suche ohne Beachtung der Groß-/Kleinschreibung durchzuführen.

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

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

Keine regulären Ausdrücke in Aufzählungsfeldern verwenden

Sie können keine regulären Ausdrücke verwenden, wenn Sie in Aufzählungsfeldern (Feldern mit einer Reihe 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 eine gültige Suche: (metadata.event_type = "NETWORK_CONNECTION" or metadata.event_type = "NETWORK_DHCP")

Operatoren „any“ und „all“ im Feld „Events“ verwenden

In Suche sind 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. Wiederholte 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 beliebiger 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 erweitert, um Ergebnisse einzubeziehen, die mit einem der Operatoren übereinstimmen, anstatt mit allen.

Jedes Element im wiederholten Feld wird einzeln behandelt. Wenn das wiederholte 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 der Operator any verwendet wird, wird das Prädikat als true ausgewertet, wenn ein beliebiger Wert im wiederholten Feld die Bedingung erfüllt.

Unix-Epoch-Zeit für Zeitstempel oder YARA-L-Funktionen für die Datumskonvertierung verwenden

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

Bei der Suche nach einem bestimmten Zeitstempel ist Folgendes (in der Epoch-Zeit) gültig:

metadata.ingested_timestamp.seconds = 1660784400

Der folgende Zeitstempel ist ungültig:

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

Bei der Suche nach einem bestimmten Zeitstempel ist Folgendes (mit einer YARA-L-Funktion für die Datumskonvertierung) gültig:

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 Zeitbereichen 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 abzufragenden Ereigniszeitbereich an. Das liegt daran, dass der Zeitbereich auf dem Zeitstempel des geparsten Ereignisses basiert und nicht auf dem Zeitstempel der Aufnahme des Rohprotokollereignisses.

Wenn Sie in UDM-Ereignissen nach aufgenommenen Protokollen 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.

Aus Filtern ausgeschlossene Felder

Die folgenden Felder sind absichtlich von Suchfiltern ausgeschlossen:

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

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

Fehlerbehebung

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

  • Stellen Sie von einem anderen Netzwerk aus 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-, Proxykonfiguration oder Richtlinie Ihrer Organisation zugelassen werden.
  • Prüfen Sie, ob für Search API-Aufrufe kein Datenlimit konfiguriert ist, da bei Suchvorgängen große Datensätze zurückgegeben werden können.
  • Suchabfragen können asynchron ausgeführt werden und es kann länger dauern, bis Daten zurückgegeben werden. Sie können zuvor ausgeführte Suchvorgänge im Suchverlauf ansehen und sie auswählen, um die Ergebnisse später aufzurufen.

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