Bonnes pratiques concernant la recherche UDM

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 bien conçues. Les performances varient également en fonction de la taille et de la complexité des données de votre instance Chronicle.

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

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

Essayez toujours de réduire au minimum la période sélectionnée. Chronicle peut ingérer d'énormes quantités 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 la 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 l'utilisation des 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 (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 celle que vous avez tenté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 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ère des correspondances. Cela permet d'étendre votre recherche pour inclure les résultats qui correspondent à l'un des opérateurs au lieu de tous les résultats.

Chaque élément du champ répété est traité individuellement. Si le champ répété figure dans les événements de la recherche, ces é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 à 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 à l'aide de l'heure de l'epoch Unix (le nombre de secondes écoulées depuis le jeudi 1er janvier 1970 00:00:00).

Lorsque vous recherchez un code temporel spécifique, les éléments suivants (dans l'heure epoch) sont valides:

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, 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 davantage de "bruit" que la valeur dans l'interface UDM Search.

Forme normale conjonctive

La recherche UDM utilise une forme normale conjonctive, une approche de la logique booléenne qui exprime des formules sous la forme de conjonctions de clauses avec un opérateur ET/OU. 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 une forme normale conjonctive, mais vous pouvez utiliser (A OR B) AND (A OR C).

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

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

Voici un exemple valide utilisant une 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 une 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 éléments suivants 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 une 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 éléments suivants 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")