Best Practices für Suchvorgänge

Unterstützt in:

Google SecOps SIEM

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.

Hinweis: Bei der Suche in Rohlogs ist das Feld Suche auf 150 Zeichen begrenzt.

Indexierte UDM-Felder für maximale Geschwindigkeit verwenden

Die effektivste Methode zur Verbesserung der Suchleistung besteht darin, Abfragen mit indexierten Feldern zu erstellen. Diese Felder sind für den schnellen Abruf optimiert. Die bekannten indexierten Felder des Unified Data Model (UDM) sind:

Hauptfelder

• principal.asset.hostname
• principal.asset.ip
• principal.asset.mac
• principal.file.md5
• principal.file.sha1
• principal.file.sha256
• principal.hostname
• principal.ip
• principal.mac
• principal.process.file.md5
• principal.process.file.sha1
• principal.process.file.sha256
• principal.process.parent_process.file.md5
• principal.process.parent_process.file.sha1
• principal.process.parent_process.file.sha256
• principal.user.email_addresses
• principal.user.product_object_id
• principal.user.userid
• principal.user.windows_sids

Quellfelder

• source.user.userid
• src.asset.hostname
• src.hostname
• src.ip

Zielfelder

• target.asset.hostname
• target.file.md5
• target.file.sha1
• target.file.sha256
• target.hostname
• target.ip
• target.process.file.md5
• target.process.file.sha1
• target.process.file.sha256
• target.user.email_addresses
• target.user.product_object_id
• target.user.userid
• target.user.windows_sid

Zusätzliche Felder

• about.file.md5
• about.file.sha1
• about.file.sha256
• intermediary.hostname
• intermediary.ip
• network.dns.questions.name
• network.email.from
• network.email.to
• observer.hostname
• observer.ip

Hinweis: Metadatenfelder werden nicht indexiert. In den folgenden Abschnitten finden Sie weitere Informationen.

Effektive Suchanfragen für die Leistung erstellen

Das Schreiben optimierter Abfragen ist entscheidend, um die Geschwindigkeit zu maximieren und den Ressourcenverbrauch für Ihre Sicherheitsdaten zu minimieren. Alle Abfragebedingungen müssen sich strikt an diese grundlegende Struktur halten:

udm-field operator value

Beispiel: principal.hostname = "win-server"

Hinweis :Je spezifischer und präziser Ihre Anfrage ist, desto schneller wird sie ausgeführt und desto weniger Rechenressourcen sind erforderlich.

Zeitraum für die Suche eingrenzen

Da Google SecOps bei einer Suche eine große Menge an Daten aufnehmen kann, müssen Sie den Zeitraum Ihrer Anfrage minimieren, um den Umfang einzugrenzen und die Suchleistung zu verbessern.

Hinweis :Für jede einzelne Abfrage wird auf der Plattform ein maximaler Suchzeitraum von 90 Tagen erzwungen.

Reguläre Ausdrücke in Suchanfragen verwenden

Sie können Standardoperatoren für Logik und Vergleiche verwenden, um komplexe Ausdrücke für Ihre UDM-Suchanfragen zu erstellen:

• Logische Operatoren:Verwenden Sie AND, OR und NOT, um Bedingungen zu kombinieren. Wenn Sie einen Operator zwischen zwei Bedingungen weglassen, wird AND angenommen.
• Operatorrangfolge: Mit Klammern () können Sie die Standardrangfolge überschreiben. Es gibt ein Limit von maximal 169 logischen Operatoren (OR, AND, NOT), die Sie in Klammern verwenden können.
• Vergleichsoperatoren: Je nach UDM-Feldtyp (String, Ganzzahl, Zeitstempel) können Feldoperatoren Folgendes umfassen: =, !=, >=, >, <, <=

Alternativ können Sie für die effiziente Suche in einer großen Menge von Werten Referenzlisten verwenden.

Hinweis :Die Ausführung von Abfragen mit mehreren regulären Ausdrücken kann länger dauern.

nocase als Suchmodifikator verwenden

Sie können den Modifikator nocase an eine Bedingung für den Stringvergleich anhängen, um die Suche ohne Berücksichtigung der Groß-/Kleinschreibung durchzuführen.

Die folgende Suche ist beispielsweise ungültig:

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

Verwendung regulärer Ausdrücke in Aufzählungsfeldern vermeiden

Bei der Suche in Aufzählungsfeldern (Felder mit einer Reihe vordefinierter Werte) wie metadata.event_type oder network.ip_protocol können Sie keine regulären Ausdrücke verwenden.

Das folgende Beispiel ist eine ungültige Suche: metadata.event_type = /NETWORK_*/

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

Hinweis :Wenn Sie nach einer Gruppe verwandter aufgezählter Werte suchen möchten, müssen Sie jeden Wert explizit mit dem Operator OR auflisten.

Beliebige Operatoren im Feld „Ereignisse“ verwenden

In Search sind einige UDM-Felder (z. B. principal.ip oder target.file.md5) als repeated gekennzeichnet, da sie eine Liste von Werten oder Nachrichtentypen in einem einzelnen Ereignis enthalten können. 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 !=.

Wenn Sie den Operator any verwenden, wird das Prädikat als true ausgewertet, wenn ein beliebiger Wert im wiederholten Feld die Bedingung erfüllt.

Unix-Epochenzeit für Zeitstempel verwenden

Zeitstempelfelder werden anhand der Unix-Epochenzeit abgeglichen (die Gesamtzahl der Sekunden, die seit Donnerstag, 1. Januar 1970, 00:00:00 UTC, vergangen sind).

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

metadata.ingested_timestamp.seconds = 1660784400

Der folgende Zeitstempel ist ungültig:

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

Felder aus Filtern ausschließen

Die folgenden Felder sind absichtlich von Suchfiltern ausgeschlossen. Sie enthalten zwar wichtige Metadaten, aber ihre sehr individuellen Werte können unnötige Suchdetails einführen und die allgemeine Effizienz und Effektivität der Suchmaschine verringern:

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

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