Bonnes pratiques de recherche

Compatible avec :

Ce document décrit les bonnes pratiques recommandées par Google pour utiliser la fonctionnalité Recherche dans Google Security Operations. Les recherches peuvent nécessiter des ressources de calcul importantes si elles ne sont pas soigneusement construites. Les performances varient également en fonction de la taille et de la complexité des données dans votre instance Google SecOps.

Utiliser des champs UDM indexés pour une vitesse maximale

Le moyen le plus efficace d'améliorer les performances de recherche consiste à créer des requêtes à l'aide de champs indexés. Ces champs sont optimisés pour une récupération rapide. Voici les champs UDM (Unified Data Model) connus qui sont indexés :

Champs principaux

  • principal.asset.hostname
  • principal.asset.ip
  • principal.asset.mac
  • principal.file.md5
  • principal.file.sha1
  • principal.file.sha256
  • principal.hostname
  • principal.ip
  • principal.mac
  • principal.process.file.md5
  • principal.process.file.sha1
  • principal.process.file.sha256
  • principal.process.parent_process.file.md5
  • principal.process.parent_process.file.sha1
  • principal.process.parent_process.file.sha256
  • principal.user.email_addresses
  • principal.user.product_object_id
  • principal.user.userid
  • principal.user.windows_sids

Champs source

  • source.user.userid
  • src.asset.hostname
  • src.hostname
  • src.ip

Champs cible

  • target.asset.hostname
  • target.file.md5
  • target.file.sha1
  • target.file.sha256
  • target.hostname
  • target.ip
  • target.process.file.md5
  • target.process.file.sha1
  • target.process.file.sha256
  • target.user.email_addresses
  • target.user.product_object_id
  • target.user.userid
  • target.user.windows_sid

Champs supplémentaires

  • about.file.md5
  • about.file.sha1
  • about.file.sha256
  • intermediary.hostname
  • intermediary.ip
  • network.dns.questions.name
  • network.email.from
  • network.email.to
  • observer.hostname
  • observer.ip

Créer des requêtes de recherche efficaces pour améliorer les performances

Il est essentiel d'écrire des requêtes optimisées pour maximiser la vitesse et minimiser la consommation de ressources dans vos données de sécurité. Toutes les conditions de requête doivent respecter strictement cette structure fondamentale :

udm-field operator value

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

Étant donné que Google SecOps peut ingérer une grande quantité de données lors d'une recherche, vous devez réduire la plage de dates de votre requête pour en limiter le champ d'application et améliorer les performances de recherche.

Utiliser des expressions régulières dans une requête de recherche

Vous pouvez utiliser des opérateurs logiques et de comparaison standards lorsque vous créez vos requêtes de recherche UDM pour élaborer des expressions complexes :

  • Opérateurs logiques : utilisez AND, OR et NOT pour combiner des conditions. Si vous omettez un opérateur entre deux conditions, AND est supposé.
  • Priorité des opérateurs : utilisez des parenthèses () pour remplacer l'ordre de priorité par défaut. Vous ne pouvez pas utiliser plus de 169 opérateurs logiques (OR, AND, NOT) entre parenthèses.
  • Opérateurs de comparaison : selon le type de champ UDM (chaîne, entier, code temporel), les opérateurs de champ peuvent inclure : =, !=, >=, >, <, <=

Vous pouvez également utiliser les listes de référence pour rechercher efficacement un grand ensemble de valeurs.

Utiliser nocase comme modificateur de recherche

Vous pouvez ajouter le modificateur nocase à une condition de comparaison de chaînes pour rendre la recherche non sensible à la casse, ce qui ignore les majuscules.

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

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

Éviter d'utiliser des expressions régulières dans les champs énumérés

Vous ne pouvez pas utiliser d'expressions régulières lorsque vous recherchez des champs énumérés (champs avec une plage de valeurs prédéfinies) tels que metadata.event_type ou network.ip_protocol.

L'exemple suivant est une recherche non valide : metadata.event_type = /NETWORK_*/

En revanche, l'exemple suivant est une recherche valide : (metadata.event_type = "NETWORK_CONNECTION" ou metadata.event_type = "NETWORK_DHCP")

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

Dans Search, certains champs UDM (comme principal.ip ou target.file.md5) sont marqués comme répétés, car ils peuvent contenir une liste de valeurs ou de types de messages dans un même événement. Les champs répétés sont toujours traités avec l'opérateur any par défaut (il n'est pas possible de spécifier all).

Lorsque l'opérateur any est utilisé, le prédicat est évalué comme true si une valeur du champ répété remplit 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", une correspondance est générée. Votre recherche est alors élargie pour inclure les résultats correspondant à l'un des opérateurs, et non à tous.

Chaque élément du champ répété est traité individuellement. Si le champ répété est trouvé dans les é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 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 du champ répété remplit la condition.

Utiliser le temps d'epoch Unix pour les codes temporels

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

Lorsque vous recherchez un code temporel spécifique, les éléments suivants (en temps Unix) sont valides :

metadata.ingested_timestamp.seconds = 1660784400

Le code temporel suivant n'est pas valide :

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

Exclure des champs des filtres

Les champs suivants sont intentionnellement exclus des filtres de recherche. Bien qu'elles contiennent des métadonnées essentielles, leurs valeurs très spécifiques peuvent introduire des détails de recherche inutiles et réduire l'efficacité globale du moteur de requête :

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

Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.