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.
Construction de base d'une recherche UDM
Chaque condition doit se présenter au format udm-field operator value
.
Par exemple : principal.hostname = "win-server"
Optimisez la période de recherche UDM
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.
Utiliser des expressions régulières avec UDM Search
Vous pouvez utiliser des expressions régulières lorsque vous effectuez des recherches UDM:
- Utilisez
AND
,OR
etNOT
. 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")