Gérer le calendrier d'exécution de vos règles

Compatible avec :

Google SecOps SIEM

Ce document est destiné aux analystes et ingénieurs en sécurité qui souhaitent gérer les plannings d'exécution des règles dans Google Security Operations. Il explique comment configurer les paramètres de fréquence (de l'analyse en temps réel aux intervalles programmés de 24 heures) et comment interpréter les exécutions en arrière-plan qui traitent les données reçues tardivement.

Cas d'utilisation courants

Le choix de la bonne programmation dépend de la gravité de la menace et de la complexité de votre logique. La plupart des équipes hiérarchisent leurs plannings en fonction des objectifs suivants.

Alertes à priorité élevée

Objectif : détecter les menaces critiques dès qu'elles touchent la plate-forme.
Valeur : réduit le temps de présence de l'auteur de l'attaque pour les correspondances à événement unique qui ne nécessitent aucun contexte supplémentaire.

Corrélation et reporting complexes

Objectif : Exécuter des règles qui nécessitent des nombres, des sommes ou des fenêtres multi-événements.
Valeur : permet au système d'ingérer et d'enrichir tous les journaux associés avant l'exécution, ce qui fournit des alertes plus précises pour l'analyse de la conformité et des tendances.

Avant de commencer

Avant de modifier des plannings, assurez-vous que votre environnement répond aux exigences suivantes pour éviter les erreurs de configuration.

Autorisations : vous devez disposer du rôle Administrateur de l'API Chronicle (roles/chronicle.admin) ou Éditeur de l'API Chronicle (roles/chronicle.editor) pour modifier les plannings des règles.
Vérification de l'environnement : assurez-vous que vos journaux sont correctement mappés au modèle de données unifié (UDM) pour prendre en charge les agrégations d'intervalles planifiées.

Terminologie clé

Pour mieux comprendre comment le système gère le timing, familiarisez-vous avec ces termes spécifiques à la plate-forme.

Exécutions de régularisation : exécutions automatiques en arrière-plan qui réévaluent les règles pour capturer les données arrivées en retard ou nécessitant un temps d'enrichissement supplémentaire.
Enrichissement : processus consistant à ajouter du contexte à un journal, comme des métadonnées d'assets ou l'identité d'un utilisateur, qui peut avoir lieu peu de temps après l'ingestion initiale.

Comprendre la planification de l'exécution des règles

Google SecOps détermine automatiquement les options de planification disponibles en fonction de la logique de votre règle. Le menu Exécuter la planification n'affiche que les options compatibles avec votre type de règle spécifique (par exemple, événement unique ou multi-événements).

Configuration de la programmation par défaut

Le système évalue les événements après leur arrivée, selon le calendrier suivant. Ce délai permet de s'assurer que les données sont complètes et de tenir compte de la latence d'ingestion ou d'enrichissement.

Planification	Critères d'attribution	Timing de l'évaluation	Cycles de régularisation
Temps réel (10 min)	Période d'un seul événement ou match < 1 h	Peu de temps après votre arrivée	Non.Évalue les données tardives/enrichies dans l'exécution standard.
Toutes les heures (1 h)	Période de correspondance comprise entre 1 heure et 48 heures	1 à 2 heures après l'arrivée	Oui. Inclut des étapes de 5 heures et de 24 heures.
Tous les jours (24 h)	Période de correspondance > 48 h	24 à 25 heures après l'arrivée	Oui. Inclut des étapes de 5 heures et de 24 heures.

Découvrez comment configurer des plannings personnalisés pour les règles.

Étapes de régularisation automatique

Pour éviter de manquer des détections en raison de retards d'ingestion ou d'enrichissement tardif, le système effectue automatiquement des exécutions de "mise à jour" pour les règles multi-événements :

Exécution initiale : exécutée le plus rapidement possible pour exposer les menaces immédiates.
Exécution intermédiaire (environ 5 h) : une exécution supplémentaire a lieu environ cinq heures après l'événement. Remarque : Cette étape n'attend pas l'enrichissement complet des données.
Ajustement final (~24 h) : exécuté une fois que toutes les données supplémentaires et l'enrichissement sont confirmés (visibilité à 100 %).

Remarque : Les règles à événement unique traitent les données enrichies et celles arrivant tardivement lors de l'exécution standard. Elles n'utilisent pas les cycles de réconciliation de cinq et 24 heures.

Modifier la programmation d'exécution

Pour modifier la fréquence à laquelle le système évalue votre logique de détection personnalisée :

Dans Google SecOps, accédez à Détection > Règles et détections.
Cliquez sur Tableau de bord des règles.
Ouvrez le menu Plus more_vert de votre règle.
Sélectionnez une valeur Run Schedule (Planification de l'exécution) dans le menu (par exemple, 10 minutes).
Cliquez sur Enregistrer. Le système enregistre automatiquement vos modifications.

Identifier les détections

Une fois une règle active, vous pouvez faire la distinction entre les alertes initiales et celles générées par les réexécutions automatiques du système.

Accédez à la page Alertes ou au tableau de bord des règles.
Dans la colonne Type de détection, cliquez sur Ampoule pour voir si la détection provient d'une exécution initiale, d'une exécution de mise à jour ou d'une recherche rétroactive.

Dépannage

Examinez les dimensions de vos données pour comprendre pourquoi certaines détections spécifiques apparaissent ou changent au fil du temps. Bien que le système identifie la plupart des menaces immédiatement, certaines nuances de données nécessitent un traitement en arrière-plan pour une précision totale. Comprendre ces exécutions en arrière-plan vous aide à mesurer précisément votre temps moyen de détection (MTTD) et à vérifier l'intégrité de vos alertes.

Latence et limites

La fréquence d'exécution des règles a un impact direct sur la rapidité de vos détections. Les plannings moins fréquents augmentent le délai entre le moment où un événement se produit et celui où le système traite une détection.

Programmes horaires : ils s'exécutent toutes les heures à l'aide des données les plus récentes disponibles. Aucune marge n'est appliquée.
Programmes quotidiens : le système introduit un délai de 24 heures pour s'assurer que les données sont entièrement ingérées avant d'être traitées.

Écarts entre les exécutions

Il est possible que l'exécution initiale d'une règle n'identifie pas une détection qui apparaît ultérieurement lors d'une exécution de correction. Ce comportement garantit que le système identifie la plupart des menaces immédiatement, tout en permettant une confirmation de haute fidélité ultérieurement. Les causes les plus courantes sont les suivantes :

Latence d'ingestion des données : données de journaux arrivant après la première exécution.
Exhaustivité de l'enrichissement : le contexte provenant de sources externes (métadonnées ou identités des composants) est toujours en cours de traitement lors de la première exécution.
Ajustements de timing : les ajustements attendent le jeu de données le plus complet avant de s'exécuter. Les détections de la première exécution peuvent arriver plus tard que prévu.

Correction des erreurs

Utilisez ce tableau pour résoudre les problèmes courants liés aux options de personnalisation manquantes ou aux plannings restreints.

Problème	Cause et solution
Options de programmation personnalisée manquantes	Les règles à événement unique utilisent le moteur en temps réel et ne sont pas compatibles avec les intervalles planifiés. De plus, les règles sélectionnées suivent des plannings système fixes que vous ne pouvez pas modifier.
Intervalles non acceptés	Si vous ne pouvez pas sélectionner Quasi temps réel, il est probable que votre règle utilise une section `match` ou des agrégations (telles que `count` ou `sum`). Ces fonctions nécessitent des intervalles planifiés pour traiter les données au fil du temps.

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