Bonnes pratiques pour la recherche UDM

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

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. Google Security Operations peut ingérer d'énormes quantités de données. Limiter l'étendue de ces données lors d'une recherche peut donc 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 supposé 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 : = != >= > < <=

Utiliser nocase comme modificateur de recherche

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

Par exemple, la recherche suivante est incorrecte:

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 est incorrecte:

metadata.eventtype = /NETWORK*/

Cependant, la recherche suivante est correcte (et correspond approximativement à la tentative effectuée ci-dessus):

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

Utiliser tout ou partie des 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'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 "true" si l'une des valeurs du champ répété répond à la condition. Par exemple, si vous recherchez principal.ip != "1.2.3.4" et que les événements de votre recherche incluent à la fois principal.ip = "1.2.3.4" et principal.ip = "5.6.7.8", la recherche générera des correspondances. Cette option permet d'étendre votre recherche aux résultats qui correspondent à l'un des opérateurs, et non à l'ensemble d'entre eux.

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

Lorsque vous utilisez l'opérateur any, le prédicat est évalué comme "true" si l'une des valeurs du champ répété répond à 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, le code suivant (en heure de l'epoch) est valide:

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, dont les suivants:

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

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

Forme normale conjonctive

La recherche UDM utilise la forme normale conjonctive, une approche de la logique booléenne qui exprime des formules en tant que conjonctions de clauses avec un opérateur AND ou OR. Chaque clause connecté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 conjonctive normale, 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 d'utilisation d'une forme conjonctive normale 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 conjonctive normale, mais vous pouvez utiliser NOT A AND NOT B.

La valeur suivante n'est pas valide:

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 conjonctive normale, mais vous pouvez utiliser A AND (B OR C) AND (B OR D).

La valeur suivante n'est pas valide:

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