Best Practices für die UDM-Suche

Unterstützt in:

In diesem Dokument werden die von Google empfohlenen Best Practices für die Durchführung von Suchen mit der UDM-Suche beschrieben. UDM-Suchanfragen können beträchtliche Rechenressourcen erfordern, wenn sie nicht sorgfältig erstellt werden. 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 erforderliche Minimum zu beschränken. Google Security Operations kann eine enorme Datenmenge aufnehmen, sodass die Suchleistung erheblich verbessert werden kann, wenn Sie die Datenmenge bei der Durchführung einer Suche einschränken.

Für UDM-Suchen können Sie reguläre Ausdrücke verwenden:

  • Verwende AND, OR und NOT.
  • AND wird angenommen, wenn keine anderen Operatoren vorhanden sind.
  • Verwenden Sie Klammern, um die Rangfolge zu ändern.
  • Je nach Feldtyp können die folgenden Feldoperatoren verwendet werden: = != >= > < <=

nocase als Suchmodifikator verwenden

nocase kann als Modifikator verwendet werden, um die Großschreibung 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

Für Aufzählungsfelder (Felder mit einem Bereich vordefinierter Werte) wie metadata.event_type oder network.ip_protocol können Sie keine regulären Ausdrücke verwenden.

Die folgende Suche ist beispielsweise ungültig:

metadata.eventtype = /NETWORK*/

Die folgende Suche ist jedoch gültig (und entspricht ungefähr dem obigen Versuch):

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

Beliebige Operatoren im Feld „Ereignisse“ verwenden

In der UDM-Suche sind einige Felder als wiederholt gekennzeichnet. Das bedeutet, dass es sich um Listen mit Werten oder anderen Arten von Nachrichten handelt. Im Gegensatz zu YARA-L werden wiederkehrende Felder in der UDM-Suche standardmäßig immer mit dem any-Operator behandelt. Es gibt keine Option, all in der Suche anzugeben.

Bei Verwendung des Operators any 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, werden bei der Suche Übereinstimmungen generiert. Dadurch wird Ihre Suche auf Ergebnisse erweitert, 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. Das kann zu unerwartetem Verhalten führen, insbesondere bei Suchen mit dem Operator !=.

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

Für Zeitstempel wird die Unix-Epochen-Zeit verwendet

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 häufig eindeutige Werte haben, führt dies zu mehr „Rauschen“, wenn sie angezeigt werden. als der Wert in der UDM-Suchoberfläche.