Bonnes pratiques concernant UDM Search

Ce document décrit les bonnes pratiques recommandées par Google pour effectuer des recherches à l'aide de la recherche UDM. Les recherches UDM peuvent nécessiter des ressources de calcul importantes 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 de votre instance Opérations de sécurité Google.

Chaque condition doit se présenter au format udm-field operator value.

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

Essayez toujours de réduire la période au minimum nécessaire. L'équipe Opérations de sécurité de Google peut ingérer une quantité colossale de données. Par conséquent, limiter l'étendue de ces données lors d'une recherche peut considérablement améliorer 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 utilisé en l'absence des autres opérateurs.
  • Utilisez des parenthèses pour modifier l'ordre de priorité.
  • Selon le type de champ, les opérateurs de champ peuvent inclure les éléments suivants : = != >= > < <=

Utiliser nocase comme modificateur de recherche

nocase peut être utilisé comme modificateur pour ignorer la casse.

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 (champs avec une plage de valeurs prédéfinies) comme metadata.event_type ou network.ip_protocol.

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

metadata.eventtype = /NETWORK*/

Cependant, la recherche suivante est correcte (et se rapproche de la tentative précédente):

(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 libellés comme répétés, ce qui signifie qu'il s'agit de listes de valeurs ou d'autres types de messages. Contrairement à YARA-L, les champs répétés dans la recherche UDM sont toujours traités avec l'opérateur any par défaut, sans possibilité de spécifier 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 que des événements incluent à la fois principal.ip = "1.2.3.4" et principal.ip = "5.6.7.8", la recherche génèrera des correspondances. Cela permet d'étendre votre recherche pour inclure les résultats qui correspondent à n'importe lequel des opérateurs, et non à tous.

Chaque élément du champ répété est traité individuellement. Si le champ répété figure dans des événements de la recherche, ceux-ci sont évalués pour chaque élément du 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 vrai si une valeur du champ répété remplit la condition.

Les codes temporels utilisent l'epoch Unix

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

Lorsque vous recherchez un code temporel spécifique, les valeurs suivantes (au niveau de l'epoch) sont valides:

metadata.ingested_timestamp.seconds = 1660784400

Le code temporel 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 généralement des valeurs uniques, leur affichage crée plus de "bruit" que la valeur dans l'interface UDM Search.

Forme normale conjonctive

UDM Search utilise la forme normale conjonctive, une approche de la logique booléenne qui exprime les formules sous la forme de conjonctions de clauses avec un opérateur AND ou OR. Chaque clause reliée par une conjonction (AND) doit être littérale ou contenir une disjonction (OR).

Exemple :

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

Les clauses peuvent également être des littéraux:

  • A OR B
  • A AND B

Vous ne pouvez pas utiliser A OR (B AND C) sous forme normale conjonctive, mais vous pouvez utiliser (A OR B) AND (A OR C).

L'exemple suivant génère une erreur dans la recherche UDM:

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

Voici un exemple valide utilisant la forme normale conjonctive dans une recherche UDM:

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

Vous ne pouvez pas utiliser NOT (A OR B) sous forme normale conjonctive, mais vous pouvez utiliser NOT A AND NOT B.

Les éléments suivants ne sont pas valides:

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

Les valeurs suivantes sont valides:

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

Vous ne pouvez pas utiliser A AND (B OR (C AND D)) sous forme normale conjonctive, mais vous pouvez utiliser A AND (B OR C) AND (B OR D).

Les éléments suivants ne sont pas valides:

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

Les valeurs suivantes sont valides:

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")