Best Practices für Suchvorgänge

Unterstützt in:

In diesem Dokument werden die von Google empfohlenen Best Practices für Suchanfragen mit der Google Suche beschrieben. Wenn Suchanfragen nicht sorgfältig formuliert sind, können sie erhebliche Rechenressourcen erfordern. Die Leistung hängt auch von der Größe und Komplexität der Daten in Ihrer Google Security Operations-Instanz ab.

Effektive Suchanfragen erstellen

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

Beispiel: principal.hostname = "win-server"

Versuchen Sie immer, den Zeitraum auf das Notwendige zu begrenzen. Google SecOps kann eine enorme Datenmenge aufnehmen. Wenn Sie die Bandbreite dieser Daten bei einer Suche einschränken, lässt sich die Suchleistung erheblich verbessern.

Sie können reguläre Ausdrücke bei Suchanfragen verwenden:

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

Alternativ können Sie auch die Referenzlisten verwenden.

nocase als Suchmodifikator verwenden

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

Die folgende Suche ist beispielsweise ungültig:

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

Reguläre Ausdrücke funktionieren nicht für Felder mit Aufzählungen

Reguläre Ausdrücke können nicht für Felder mit einer Reihe vordefinierter Werte wie metadata.event_type oder network.ip_protocol verwendet werden.

Die folgende Suche ist beispielsweise ungültig:

metadata.eventtype = /NETWORK*/

Die folgende Suche ist jedoch gültig und entspricht ungefähr dem, was oben versucht wurde:

(metadata.event_type = "NETWORK_CONNECTION" or metadata.event_type = "NETWORK_DHCP")

Alle Operatoren im Feld „Ereignisse“ verwenden

In der Suche sind einige Felder als wiederholt gekennzeichnet. Das bedeutet, dass sie eine Liste von Werten oder Nachrichtentypen enthalten. Anders als bei Regeln werden wiederkehrende Felder in der Suche standardmäßig immer mit dem Operator any behandelt. Es gibt keine Möglichkeit, all anzugeben.

Wenn der Operator any verwendet wird, wird das Prädikat als wahr ausgewertet, wenn ein 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, werden in der Suche Übereinstimmungen generiert. Dadurch wird die Suche auf Ergebnisse erweitert, die mit mindestens 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. Das kann zu unerwartetem Verhalten führen, insbesondere bei der Suche mit dem Operator !=.

Wenn der Operator any verwendet wird, wird das Prädikat als „wahr“ ausgewertet, wenn ein Wert im wiederholten Feld die Bedingung erfüllt.

Zeitstempel verwenden die Unix-Epochenzeit

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

Bei der Suche nach einem bestimmten Zeitstempel ist Folgendes (in Epochenzeit) zulässig:

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:

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

Da diese Felder oft eindeutige Werte enthalten, werden oft unnötige Details hinzugefügt, was die Effektivität der Suche verringert.

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