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

Compatible avec :

Ce document s'adresse aux analystes et ingénieurs en sécurité, ainsi qu'aux administrateurs de plate-forme qui souhaitent comprendre et gérer la façon dont Google Security Operations planifie l'exécution des règles. Il explique comment les configurations de règles déterminent la fréquence de traitement, comment le système équilibre le streaming en temps quasi réel avec le traitement par lot planifié, et comment les exécutions en arrière-plan gèrent les journaux arrivant tardivement et l'enrichissement du contexte.

Cas d'utilisation courants

Le choix ou la compréhension du bon calendrier dépend de la gravité de la menace et de la complexité de la logique :

  • Alertes à priorité élevée : détectez les menaces critiques en quasi-temps réel pour les correspondances d'événements uniques qui ne nécessitent aucune corrélation d'événements supplémentaire, ce qui réduit le temps de latence des pirates informatiques.
  • Corrélation et reporting complexes : utilisez des intervalles planifiés (par exemple, 10 minutes ou 1 heure) pour les règles à événements multiples qui calculent des nombres, des sommes ou des fenêtres de correspondance glissantes. Les intervalles planifiés permettent au système d'ingérer et d'enrichir les journaux associés avant l'exécution, ce qui améliore la précision des alertes pour l'analyse de la conformité et des tendances.

Terminologie clé

  • Fréquence déterministe : intervalle d'exécution de référence que le système attribue automatiquement en fonction de la période de correspondance et du type de règle.
  • Exécution principale (T + décalage) : exécution initiale de la logique de détection par rapport à un bloc de temps d'événement. Le délai de règlement représente le décalage ajouté pour tenir compte des données reçues tardivement.
  • Délai de règlement : période tampon ajoutée à l'exécution principale pour permettre le traitement des journaux tardifs avant le début de l'évaluation des règles.
  • Exécutions de régularisation (relecture des règles) : exécutions automatisées en arrière-plan qui réévaluent les périodes traitées précédemment pour capturer les journaux ou les données d'enrichissement arrivés après l'exécution principale.
  • Enrichissement : processus d'ajout de contexte à un journal (métadonnées de l'élément, identité de l'utilisateur ou indicateurs de renseignement sur les menaces, par exemple) lors du traitement du pipeline.
  • Délai de détection : temps total écoulé entre le code temporel de l'événement et la création d'une détection.

Avant de commencer

Vérifiez que votre environnement répond aux exigences suivantes :

  • Autorisations : vous devez disposer du rôle IAM Administrateur de l'API Chronicle (roles/chronicle.admin) ou Éditeur de l'API Chronicle (roles/chronicle.editor) pour modifier les plannings de règles, ou du rôle Lecteur de l'API Chronicle (roles/chronicle.viewer) pour inspecter les plannings dans le tableau de bord des règles.
  • Vérification de l'environnement : assurez-vous que vos journaux sont mappés au modèle de données unifié (UDM) pour permettre les agrégations à intervalles planifiés.

Fonctionnement de la planification des règles

Google SecOps équilibre la latence de détection en temps quasi réel avec la stabilité de la plate-forme pour des milliers de règles. La plate-forme utilise deux modèles d'exécution principaux :

  1. Moteur de flux : évalue en continu les règles à événement unique standards et avec fenêtre (même avec des fenêtres de correspondance de plus de 48 heures) en temps quasi réel (généralement dans les cinq minutes suivant l'ingestion). Les événements arrivant tardivement et les enrichissements rétroactifs sont évalués en continu lors de l'exécution standard.
  2. Moteur de requêtes planifiées : évalue les règles complexes à événement unique (avec des listes de référence ou des tableaux de données) en temps quasi réel, et les règles multi-événements par blocs d'heures d'événement (par exemple, par intervalles de 10 minutes ou d'une heure, ou match_window / 10 pour les périodes de plus de 48 heures). Les règles à événements multiples nécessitent une période pour agréger et corréler les événements entre les sources.

Configuration de la programmation par défaut

Lorsque vous activez une règle, Google SecOps détermine automatiquement la fréquence d'exécution par défaut en fonction de la logique et de la fenêtre de correspondance de votre règle :

Type de règle et taille de la fenêtre Fréquence d'exécution Timing de l'évaluation Exécutions de régularisation
Règle à événement unique (standard ou avec fenêtre) Temps réel Peu après l'arrivée (< 5 minutes) Non.Évalue en continu les données tardives et enrichies dans l'exécution standard.
Règle à événement unique (avec des listes de référence ou des tableaux de données) Quasi en temps réel Peu après l'arrivée (< 5 minutes) Non : évalue les données tardives et enrichies en continu lors de l'exécution de requêtes standards.
Règle à événements multiples (window <= 48h) Toutes les heures (ou Toutes les 10 min, personnalisable pour les fenêtres de moins d'une heure) 1 à 2 heures après l'arrivée Oui. Inclut une exécution de régularisation automatique de quatre heures et une exécution de régularisation facultative de 30 heures.
Règle à événements multiples (window > 48h) match_window / 10 (par exemple, tous les jours pour une période de correspondance de 10 jours) Varie en fonction de la période de correspondance (match_window / 10) Non.Évalue les données tardives et enrichies lors des exécutions ultérieures qui se chevauchent.

Exécutions de régularisation automatiques

Pour éviter les détections manquées causées par la latence d'ingestion ou les métadonnées d'enrichissement tardives (telles que les tags d'assets ou les alias d'utilisateur), le système exécute automatiquement des ajustements en arrière-plan pour les règles multi-événements (window <= 48h) :

  1. Exécution initiale : exécutée le plus rapidement possible en fonction de l'intervalle planifié pour exposer les menaces immédiates.
  2. Première exécution de la mise à jour (4 h) : réévalue le bloc temporel environ quatre heures après l'exécution initiale pour capturer les journaux arrivés tardivement. Cette étape n'attend pas l'enrichissement complet des données.
  3. Deuxième exécution de réajustement (30 h) : (facultatif) exécutée environ 30 heures après la première exécution, une fois que tous les pipelines de contexte supplémentaire et d'enrichissement des données sont terminés.

Pour en savoir plus sur le comportement et les scénarios de réconciliation, consultez Comprendre les relectures de règles et le MTTD.

Programmes personnalisables

Pour les règles à événements multiples personnalisées avec une fenêtre de correspondance inférieure ou égale à 48 heures, Google SecOps vous permet de personnaliser les paramètres de planification au lieu de vous fier entièrement aux paramètres système par défaut :

  • Sélection de la fréquence : choisissez des fréquences d'exécution telles que Toutes les 10 min (pour les périodes de correspondance de moins de 60 minutes) ou Toutes les heures.
  • Délai de règlement : ajoutez un délai tampon (T + décalage) pour tenir compte de la latence d'ingestion connue des sources de journaux.
  • Exhaustivité de l'enrichissement : le traitement de la réconciliation est étendu à 30 heures pour s'assurer que toutes les jointures de métadonnées externes sont terminées avant l'évaluation finale.

Pour connaître la procédure de configuration complète, consultez Configurer des plannings personnalisés pour les règles.

Visibilité de la programmation dans le Tableau de bord des règles

Le tableau de bord des règles affiche le calendrier d'exécution attribué à chaque règle active dans la colonne Calendrier des règles. Les règles inactives n'affichent pas de programmation active tant qu'elles ne sont pas activées.

Pour modifier la fréquence d'exécution, ajouter des délais de règlement ou ajuster les temps d'attente pour l'enrichissement d'une règle multi-événements personnalisée, consultez Configurer des plannings personnalisés pour les règles.

Indicateurs de source de détection

Sur la page Alertes et dans le tableau de bord des règles, la colonne Type de détection indique si une détection provient d'une exécution initiale ou d'une exécution en arrière-plan automatisée :

  • Aucune icône : la détection a été générée lors de l'exécution principale (T) ou à l'aide du moteur de flux continu.
  • Icône en forme d'ampoule  : la détection provient de données d'événement arrivées avec plus de 30 minutes de retard, d'exécutions de correction automatisées, de pipelines de retraitement ou de recherches rétroactives.

Latence et dépannage

La fréquence d'exécution des règles a un impact direct sur la rapidité de vos détections. Tenez compte des comportements suivants lorsque vous concevez et surveillez des règles :

  • Programmes horaires : s'exécutent toutes les heures à l'aide des données les plus récentes disponibles. Aucune marge supplémentaire n'est appliquée par défaut.
  • Fenêtres de correspondance de plus de 48 heures : le système exécute ces règles à un taux de match_window / 10 et n'effectue aucune exécution de réconciliation.
  • Écarts entre les exécutions : une détection qui ne se déclenche pas lors de la première exécution peut se déclencher lors d'une exécution de mise à jour si l'ingestion des journaux a été retardée ou si l'enrichissement du contexte (comme la résolution du graphique d'entités) s'est terminé après l'évaluation initiale.
  • Options de personnalisation manquantes : les règles à événement unique sont évaluées en temps quasi réel et ne sont pas compatibles avec la personnalisation des intervalles. Les règles sélectionnées suivent des plannings système fixes. Les règles multi-événements personnalisées dont la période de correspondance est supérieure à 48 heures sont exécutées à une fréquence de match_window / 10 et ne peuvent pas être personnalisées.
  • Intervalles non acceptés : si vous ne pouvez pas sélectionner l'exécution en quasi-temps réel, cela signifie que votre règle est une règle multi-événements nécessitant une corrélation d'événements au fil du temps ou incluant des agrégations (telles que count ou sum), qui nécessitent le moteur de requêtes par lot planifiées.

Pour connaître la procédure de dépannage détaillée, consultez Comprendre les délais de détection des règles.

Étapes suivantes

Pour en savoir plus sur les concepts de planification et les workflows de configuration associés, consultez les documents suivants :

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