Best Practices für die UDM-Suche

Unterstützt in:

In diesem Dokument werden die von Google empfohlenen Best Practices für Suchanfragen mit der UDM-Suche beschrieben. Wenn UDM-Suchanfragen nicht sorgfältig erstellt werden, 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.

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 Security Operations kann eine enorme Menge an Daten aufnehmen. Wenn Sie die Breite dieser Daten bei einer Suche einschränken, lässt sich die Suchleistung erheblich verbessern.

Sie können reguläre Ausdrücke bei UDM-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 UDM-Suche sind einige Felder als wiederholt gekennzeichnet. Das bedeutet, dass es sich um Listen von Werten oder anderen Arten von Nachrichten handelt. Im Gegensatz zu YARA-L werden wiederholte Felder in der UDM-Suche standardmäßig immer mit dem Operator any behandelt. Es gibt keine Möglichkeit, all in der Suche 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 Ü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 in der Regel eindeutige Werte haben, ist die Anzeige dieser Felder in der UDM-Suche eher verwirrend.