Best Practices für die UDM-Suche

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 Aufzählungsfelder.

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. Wird das wiederkehrende Feld in Ereignissen der Suche gefunden, 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 mithilfe der Unix-Epochenzeit (Anzahl der Sekunden, die seit Donnerstag, 1. Januar 1970 um 00:00:00 Uhr vergangen sind, abgeglichen) 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"

Einige Felder sind von Filtern ausgeschlossen, darunter die folgenden:

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

Da diese Felder tendenziell eindeutige Werte haben, erzeugt die Anzeige auf der UDM-Suchoberfläche mehr „Rauschen“ als Wert.

Konjunktive Normalform

Die UDM-Suche verwendet konjunktive Normalform, einen Ansatz für boolesche Logik, die Formeln als Konjunktionen von Klauseln mit einem AND oder OR ausdrückt. Jede Klausel, die durch eine Konjunktion (AND) verbunden ist, muss entweder ein Literal sein oder eine Disjunktion (OR) enthalten.

Beispiel:

  • (A OR B) AND (C OR D)
  • (A OR B) AND (NOT C OR B)

Die Klauseln können auch Literale sein:

  • A OR B
  • A AND B

Sie können A OR (B AND C) nicht in konjunktiver Normalform, aber (A OR B) AND (A OR C) verwenden.

Das folgende Beispiel würde einen Fehler in der UDM-Suche generieren:

principal.hostname = "win-server" nocase OR (principal.hostname = "win-adfs" nocase AND metadata.event_type = "NETWORK_CONNECTION")

Das folgende Beispiel zeigt die konjunktive Normalform in einer UDM-Suche:

(principal.hostname = "win-server" nocase OR principal.hostname = "win-adfs" nocase) AND (principal.hostname = "win-server" nocase OR metadata.event_type = "NETWORK_CONNECTION")

Sie können NOT (A OR B) nicht in konjunktiver Normalform, aber NOT A AND NOT B verwenden.

Folgendes ist ungültig:

principal.hostname = "win-server" nocase AND NOT(metadata.event_type = "PROCESS_TERMINATION" OR metadata.event_type = "USER_RESOURCE_ACCESS")

Folgendes ist gültig:

principal.hostname = "win-server" nocase AND NOT metadata.event_type = "PROCESS_TERMINATION" AND NOT metadata.event_type = "USER_RESOURCE_ACCESS"

Sie können A AND (B OR (C AND D)) nicht in konjunktiver Normalform, aber A AND (B OR C) AND (B OR D) verwenden.

Folgendes ist ungültig:

principal.hostname = "win-server" nocase AND (metadata.event_type = "PROCESS_LAUNCH" OR (metadata.event_type = "NETWORK_CONNECTION" AND target.ip = "10.128.0.21")

Folgendes ist gültig:

principal.hostname = "win-server" nocase AND (metadata.event_type = "PROCESS_LAUNCH" OR metadata.event_type = "NETWORK_CONNECTION") AND (metadata.event_type = "PROCESS_LAUNCH" OR target.ip = "10.128.0.21")