Bonnes pratiques pour la recherche UDM

Compatible avec :

Ce document décrit les bonnes pratiques recommandées par Google à l'aide de l'UDM Search. Les recherches UDM peuvent nécessiter des ressources de calcul importantes pour être effectuées si elles ne sont pas conçues avec soin. Les performances varient également en fonction de la taille et de la complexité des données dans votre Instance Google Security Operations.

Chaque condition doit être au format udm-field operator value.

Par exemple : principal.hostname = "win-server"

Essayez toujours de réduire la période au minimum nécessaire. Google Security Operations peut ingérer une quantité énorme de données. Limiter la portée de ces données lors d'une recherche peut donc améliorer considérablement les performances de recherche.

Vous pouvez utiliser des expressions régulières lorsque vous effectuez des recherches UDM:

  • Utilisez AND, OR et NOT.
  • AND est supposé en l'absence des autres opérateurs.
  • Utilisez des parenthèses pour modifier l'ordre de priorité. Vous pouvez utiliser un maximum de 169 opérateurs logiques (OR, AND et NOT) entre parenthèses.
  • Selon le type de champ, les opérateurs de champ peuvent inclure les éléments suivants : = != >= > < <=

Vous pouvez également utiliser les listes de référence.

Utiliser "nocase" comme modificateur de recherche

nocase peut être utilisé comme modificateur pour ignorer les majuscules.

Par exemple, la recherche suivante n'est pas valide :

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

Les expressions régulières ne fonctionnent pas pour les champs énumérés

Vous ne pouvez pas utiliser d'expressions régulières pour les champs énumérés (c'est-à-dire les champs comportant une plage de des valeurs prédéfinies), comme metadata.event_type ou network.ip_protocol

Par exemple, la recherche suivante est incorrecte:

metadata.eventtype = /NETWORK*/

Toutefois, la recherche suivante est valide (et correspond à peu près à ce qui a été tenté ci-dessus) :

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

Utiliser tous les opérateurs dans le champ "Événements"

Dans la recherche UDM, certains champs sont marqués comme répétés, ce qui signifie qu'ils sont des listes de valeurs ou d'autres types de messages. Contrairement à YARA-L, les champs répétés dans l'UDM sont toujours traités avec l'opérateur any par défaut, et aucune option spécifiez all dans votre recherche.

Lorsque l'opérateur any est utilisé, le prédicat est évalué comme vrai si une valeur du champ répété remplit la condition. Par exemple, si vous recherchez "principal.ip != "1.2.3.4"" et les événements que vous recherchez incluent à la fois principal.ip = "1.2.3.4" et principal.ip = "5.6.7.8", la recherche générer des correspondances. Cette opération élargit votre recherche pour inclure les résultats correspondant à l'un des opérateurs au lieu de tous.

Chaque élément du champ répété est traité individuellement. Si la fonction est trouvé dans les événements de la recherche, les événements sont évalués pour chaque dans le champ. Cela peut entraîner un comportement inattendu, en particulier lors d'une recherche à l'aide de l'opérateur !=.

Lorsque vous utilisez l'opérateur any, le prédicat est évalué comme "true" si une valeur dans le champ répété satisfasse à la condition.

Les horodatages utilisent l'heure de l'epoch Unix

Les champs d'horodatage sont mis en correspondance en fonction de l'epoch Unix (nombre de secondes ayant depuis le jeudi 1er janvier 1970 à 00:00:00).

Lorsque vous recherchez un code temporel spécifique, la valeur suivante (en temps Unix) est valide :

metadata.ingested_timestamp.seconds = 1660784400

L'horodatage suivant n'est pas valide:

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

Certains champs sont exclus des filtres, y compris les suivants :

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

Étant donné que ces champs ont tendance à avoir des valeurs uniques, leur affichage crée davantage "bruit" que la valeur dans l'interface de recherche UDM.