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. Suchanfragen können erhebliche Rechenressourcen erfordern, wenn sie nicht sorgfältig formuliert werden. Die Leistung variiert auch je nach Größe und Komplexität der Daten in Ihrer Google SecOps-Instanz.

Effektive Suchanfragen erstellen

Jede Bedingung muss das Format udm-field operator value haben.

Beispiel: principal.hostname = "win-server"

Da Google SecOps bei einer Suche eine große Menge an Daten aufnehmen kann, empfiehlt es sich, den Zeitraum zu minimieren, um den Umfang einzugrenzen und die Suchleistung zu verbessern.

Reguläre Ausdrücke in Suchanfragen verwenden

Sie können reguläre Ausdrücke verwenden, wenn Sie Daten durchsuchen:

  • Verwende AND, OR und NOT.
  • Wenn die anderen Operatoren nicht vorhanden sind, wird AND angenommen.
  • Mit Klammern können Sie die Prioritätsreihenfolge ändern. In den Klammern dürfen maximal 169 logische Operatoren (OR, AND und NOT) verwendet werden.
  • Je nach Feldtyp können Feldoperatoren Folgendes umfassen: = != >= > < <=

Alternativ können Sie Referenzlisten verwenden.

nocase als Suchmodifikator verwenden

nocase kann als Modifikator verwendet werden, um die Groß-/Kleinschreibung zu ignorieren.

Die folgende Suche ist beispielsweise ungültig:

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

Keine regulären Ausdrücke für aufgezählte Felder verwenden

Sie können keine regulären Ausdrücke für aufgezählte Felder (Felder mit einer Reihe vordefinierter Werte) wie metadata.event_type oder network.ip_protocol verwenden.

Das folgende Beispiel ist eine ungültige Suche: metadata.eventtype = /NETWORK*/

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

Verwendung von beliebigen Operatoren im Feld „Ereignisse“

In Search sind einige Felder als repeated (wiederholt) gekennzeichnet. Das bedeutet, dass sie eine Liste von Werten oder Nachrichtentypen enthalten. 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 die 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 und umfasst Ergebnisse, die mit einem der Operatoren übereinstimmen, anstatt mit allen.

Jedes Element im wiederkehrenden 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 !=.

Bei Verwendung des any-Operators wird das Prädikat als „true“ ausgewertet, wenn ein beliebiger Wert im wiederholten Feld die Bedingung erfüllt.

Zeitstempel verwenden die Unix-Epochenzeit

Zeitstempelfelder werden anhand der Unix-Epochenzeit (Anzahl der Sekunden seit Donnerstag, 1. Januar 1970, 00:00:00 Uhr) abgeglichen.

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

metadata.ingested_timestamp.seconds = 1660784400

Der folgende Zeitstempel ist ungültig:

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

Bestimmte Felder sind von Filtern ausgeschlossen, darunter die folgenden:

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

Da diese Felder oft eindeutige Werte enthalten, können sie unnötige Details hinzufügen, was die Effektivität der Suche beeinträchtigen kann.

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