Analyser l'efficacité et l'efficience des règles

Compatible avec :

Google SecOps SIEM

Ce guide s'adresse aux ingénieurs en sécurité qui créent, déploient et surveillent des règles dans Google Security Operations. Il explique comment surveiller les règles pour s'assurer qu'elles fonctionnent comme prévu et ne consomment pas de ressources de manière excessive à l'aide des données disponibles dans votre instance Google SecOps. Ces données vous aident à déboguer les détections différées, à comprendre l'impact des données d'enrichissement tardives sur les règles et à identifier les règles dont le temps moyen de détection (MTTD) est le plus élevé.

Ce guide fournit de la documentation sur les tâches suivantes :

Découvrez comment évaluer une règle lors de sa publication initiale, recevoir des alertes et consulter le tableau de bord des règles pour surveiller son état.
Identifier la cause des éventuels retards de détection (par exemple, s'ils sont dus à une ingestion tardive ou à une logique inefficace), puis ajuster le reporting sur le temps moyen de détection (MTTD) ou affiner la règle avec des exclusions de règles supplémentaires.

Avant de commencer

Pour afficher et modifier les règles comme décrit dans ce document, vous devez être un éditeur de l'API Chronicle. Pour en savoir plus, consultez Rôles et autorisations Google Security Operations.

Avant d'analyser l'efficacité des règles dans Google SecOps, vous devez bien comprendre le langage YARA-L, les requêtes YARA-L, comment créer et gérer des règles, et comment créer des tableaux de bord :

Terminologie clé

Règles : identifiez automatiquement les menaces à mesure que les données de journaux sont ingérées dans votre compte Google SecOps.
Quotas : limites concernant le volume d'ingestion de données, le nombre et la complexité des requêtes que vous pouvez exécuter sur vos données, ainsi que le nombre et la complexité des règles actives dans votre compte Google SecOps.
Alertes et détections : problèmes de sécurité identifiés par les équipes Google SecOps et votre propre infrastructure de sécurité qui nécessitent votre attention.
Ingestion : processus d'importation de vos données de sécurité dans Google SecOps et de conversion au format UDM.
Relecture des règles : réexécution automatique des règles sur les données existantes au cas où des données contextuelles pertinentes arrivent ou sont traitées après les données d'événement initiales.
Retrohunt : appliquez de nouvelles règles aux données existantes pour identifier les menaces qui n'avaient pas été détectées auparavant.

Analyser les règles

Les sections suivantes décrivent comment analyser les performances de vos règles.

Tester et évaluer les règles après le déploiement

Lorsque vous déployez une règle en production pour la première fois, surveillez-la dans le tableau de bord Rule Observability pendant 24 à 48 heures :

Accédez à Tableaux de bord.
Recherchez Rule Observability.
Recherchez la nouvelle règle dans la colonne Règle. Le tableau de bord Observabilité des règles inclut des statistiques telles que le nombre de détections, la latence d'ingestion et le temps écoulé entre l'ingestion et la détection.

Pour vous assurer que la logique de la règle n'introduit pas de délais artificiels avant de commencer à générer des alertes de haute priorité, vous pouvez utiliser la référence du schéma pour les détections. Le schéma définit le format structuré utilisé pour surveiller les alertes de sécurité. Il est optimisé pour le suivi de la fréquence de détection, de la répartition des risques et des performances des règles. Pour mieux comprendre comment utiliser le schéma, examinez de près les exemples de requêtes.

Identifier la raison du retard des résultats des règles

Pour déterminer si les résultats des règles sont retardés et, le cas échéant, pourquoi, procédez comme suit :

Accédez à Détections > Alertes et IOC.
Dans l'onglet Alertes, recherchez la colonne Type de détection.
Recherchez les alertes avec une icône d'ampoule jaune.
Pointez sur l'icône pour voir si la détection a été déclenchée par l'un des éléments suivants :
- Retraitement des règles : déclenché manuellement par un utilisateur.
- Retrohunt : déclenchée manuellement par un utilisateur.
- Données d'événement différées : indique si un délai de détection est prévu.

Filtrer les alertes en fonction de l'heure de détection

Accédez à Détections > Alertes et IOC.
Dans l'onglet Alertes, utilisez l'élément de filtre de la colonne Heure de détection pour trier les détections en fonction de leur heure d'arrivée.
Cliquez sur l'icône Actualiser en haut du tableau, puis sur Actualiser maintenant. Vous pouvez consulter les dernières alertes reçues dans votre compte Google SecOps et la règle associée à chaque alerte (consultez la colonne Nom de la règle).

Examiner les métadonnées

Pour mieux comprendre les performances de vos règles, vous pouvez inspecter le JSON de détection brut à l'aide de latencyMetrics afin de trouver la différence entre oldestEventTime et oldestIngestionTime.

Valeurs de timing de la détection

Le tableau suivant répertorie les valeurs énumérées associées à DetectionTimingDetails :

Valeur	Description	Impact du MTTD
`UNSPECIFIED`	Détection créée dans la période de planification standard.	Vérité terrain pour le MTTD.
`REPROCESSING`	Généré en raison d'une relecture de règle (par exemple, des données reçues tardivement).	Représente le risque opérationnel. Doit être pris en compte dans les rapports.
`RETROHUNT`	Généré lors d'une recherche rétroactive historique.	Généralement filtré des rapports standards sur le temps moyen avant détection.

Exemple : métadonnées `latencyMetrics`

L'exemple latencyMetrics suivant montre la différence de temps entre le moment où un événement s'est produit (oldestEventTime par rapport à newestEventTime) et le moment où il a été ingéré (oldestIngestionTime par rapport à newestIngestionTime). La latence entre l'événement et l'ingestion dans le compte Google SecOps est d'environ 53 minutes.

"detectionTimingDetails": ["DETECTION_TIMING_DETAILS_REPROCESSING"],
"latencyMetrics": {
  "oldestIngestionTime": "2025-12-09T16:54:14Z",
  "newestIngestionTime": "2025-12-09T16:54:14Z",
  "oldestEventTime": "2025-12-09T16:01:06Z",
  "newestEventTime": "2025-12-09T16:01:06Z"
}

Dépannage

Le tableau suivant répertorie certains des problèmes que vous pouvez rencontrer avec vos règles et vous indique comment les résoudre :

Problème	Solution
L'icône en forme d'ampoule s'affiche, mais l'énumération est `UNSPECIFIED.`	Ce comportement est normal lorsque le delta entre l'heure de l'événement et l'heure d'ingestion dépasse 30 minutes. Utilisez les métriques du Centre d'intégrité des données pour identifier la source du retard d'ingestion.
La détection apparaît tardivement par rapport à l'heure de l'événement.	Vérifiez `detectionTimingDetails`. Si la valeur d'énumération est `REPROCESSING`, le retard est probablement dû à des données d'enrichissement tardives plutôt qu'à la latence d'exécution des règles. Si la valeur est `UNSPECIFIED`, examinez l'efficacité de la logique de la règle.
Calcul excédentaire.	La règle analyse probablement trop de données ou sa logique est inefficace. Accédez à Exclusions de règles ou utilisez Déchargement de filtres pour ajuster la règle et affiner la recherche de données.

Limitations connues

Rigidité du seuil : l'indicateur visuel pour les données tardives est fixé à un seuil de 30 minutes et ne tient pas compte des fenêtres de latence définies par l'utilisateur.
Intégrité des données : l'observabilité des règles permet de connaître l'état des règles, mais la surveillance de l'intégrité des données (plus près de l'ingestion) est plus efficace pour détecter les problèmes généraux de données tardives.
Application des quotas : le tableau de bord affiche l'utilisation des ressources, mais ne fournit pas de notifications en temps réel lorsque les règles approchent d'une limite de quota.

Étapes suivantes

Pour en savoir plus sur les relectures de règles et les délais de détection des règles, consultez les pages suivantes :

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