Bonnes pratiques de recherche

Compatible avec :

Ce document décrit les bonnes pratiques recommandées par Google pour utiliser la fonctionnalité Search (Recherche) dans Google Security Operations. Les recherches 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 Google SecOps.

Utiliser des filtres spécifiques dans les requêtes pour optimiser la vitesse et les performances

Le moyen le plus efficace d'améliorer les performances de recherche consiste à créer des requêtes à l'aide de champs UDM (Unified Data Model) spécifiques et optimisés. Ces champs sont optimisés pour une récupération rapide, ce qui garantit que vos recherches s'exécutent rapidement et utilisent moins de ressources de calcul.

Les sections suivantes listent les champs UDM hautes performances à utiliser comme filtres dans vos requêtes.

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_sid

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

Interroger des données d'entité et des données contextuelles

Si vous recherchez des types de journaux d'entité ou de contexte (tels que AZURE_AD_CONTEXT ou WORKSPACE_USERS) à l'aide de metadata.log_type = "<LOG_TYPE>", la recherche ne renvoie aucun résultat, même si les journaux bruts sont visibles dans Raw Log Search. En effet, la recherche UDM n'interroge que les enregistrements d'événements UDM.

Pour rechercher des données d'entité et de contexte, utilisez la syntaxe graph :

  • Pour rechercher un type de journal d'entité ou de contexte, interrogez les champs de métadonnées graph. Exemple :

    graph.metadata.event_metadata.log_type = "<LOG_TYPE>"

  • Pour rechercher des champs d'entité, utilisez le préfixe graph.entity.noun.field. Exemple :

    graph.entity.user.email_addresses = "foo_email"

Pour en savoir plus, consultez Effectuer une recherche de données contextuelles d'entité.

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

La création de requêtes optimisées est essentielle 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

Exemple : principal.hostname = "win-server"

Étant donné que Google SecOps peut ingérer une grande quantité de données lors d'une recherche, réduire la période et limiter la portée de votre requête peut 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 créer des expressions complexes :

  • Opérateurs logiques : utilisez AND, OR et NOT pour combiner des conditions. AND est utilisé par défaut si vous omettez un opérateur entre deux conditions.
  • Priorité des opérateurs : utilisez des parenthèses () pour remplacer l'ordre de priorité par défaut. Vous pouvez utiliser au maximum 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 : =, !=, >=, >, <, <=

Google SecOps utilise le moteur d'expressions régulières RE2.

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 insensible à la casse, ce qui ignore la mise en majuscules.

Par exemple, la recherche suivante ignore la casse et correspond à toutes les combinaisons contenant tim.smith, quelle que soit la casse :

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

Éviter d'utiliser des expressions régulières dans des 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 "Events" (Événements)

Dans Search (Recherche), certains champs UDM (tels que principal.ip ou target.file.md5) sont libellés repeated (répétés), car ils peuvent contenir une liste de valeurs ou de types de messages dans un seul é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 ainsi étendue pour inclure les résultats qui correspondent à l'un des opérateurs au lieu de 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 l'heure epoch Unix pour les codes temporels ou des fonctions YARA-L pour la conversion de dates

Les champs de code temporel sont mis en correspondance à l'aide de l'heure epoch Unix (le nombre total de secondes écoulées depuis le jeudi 1er janvier 1970 à 00:00:00 UTC). Vous pouvez également utiliser des fonctions YARA-L pour la conversion de dates.

Lorsque vous recherchez un code temporel spécifique, le code suivant (en heure epoch) est valide :

metadata.ingested_timestamp.seconds = 1660784400

Le code temporel suivant n'est pas valide :

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

Lorsque vous recherchez un code temporel spécifique, le code suivant (à l'aide d'une fonction YARA-L pour la conversion de dates) est valide :

metadata.event_type = "NETWORK_CONNECTION"
timestamp.get_date(metadata.ingested_timestamp.seconds) = "2026-03-15"

L'exemple YARA-L suivant utilise des fonctions timestamp pour vérifier les plages de temps d'ingestion :

metadata.event_type = "NETWORK_CONNECTION"
$date = timestamp.get_date(metadata.ingested_timestamp.seconds)
$date > "2026-03-15" AND $date < "2026-03-17"

Interroger des données nouvellement ingérées avec des codes temporels plus anciens

Vous ne pouvez pas rechercher des événements nouvellement ingérés qui ont un code temporel plus ancien, sauf si vous spécifiez la période d'événement à interroger. En effet, la période est basée sur le code temporel de l'événement analysé, et non sur le code temporel d'ingestion de l'événement de journal brut.

Pour rechercher des événements UDM dans les journaux ingérés avec des codes temporels d'événement plus anciens, vous pouvez utiliser l'option All time (Toute la période) pour effectuer une recherche et une requête sur metadata.ingested_timestamp.

Champs exclus des filtres

Les champs suivants sont intentionnellement exclus des filtres de recherche :

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

Bien que ces champs contiennent des métadonnées importantes, leurs valeurs uniques introduisent une cardinalité et une variance élevées dans les statistiques, ce qui a un impact négatif sur les performances de recherche.

Dépannage

Si vous recevez un message d'erreur générique, tel que "Error: Search has encountered an error and couldn't load data" (Erreur : la recherche a rencontré une erreur et n'a pas pu charger les données), procédez comme suit pour résoudre le problème. Si l'erreur persiste, contactez l'assistance client.

  • Connectez-vous à Google SecOps à partir d'un autre réseau. Par exemple, utilisez une VM cloud pour identifier les problèmes de réseau.
  • Assurez-vous que les appels d'API Chronicle sont autorisés par la configuration ou la règle de pare-feu ou de proxy de votre organisation.
  • Vérifiez qu'aucune limite de données n'est configurée pour les appels d'API Search, car les recherches peuvent renvoyer de grands ensembles de données.
  • Les requêtes de recherche peuvent s'exécuter de manière asynchrone et peuvent nécessiter plus de temps pour renvoyer des données. Vous pouvez afficher les recherches précédemment exécutées dans l'historique des recherches et les sélectionner pour afficher les résultats ultérieurement.

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