Planifier l'exécution des règles

Compatible avec :

Ce document est destiné aux analystes et aux ingénieurs en sécurité qui souhaitent gérer les programmations 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 arrivées en retard.

Cas d'utilisation courants

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

Alertes à priorité élevée

  • Objectif : détecter les menaces critiques dès qu'elles atteignent la plate-forme.
  • Avantage : réduit le temps d'attente des pirates pour les correspondances à événement unique qui ne nécessitent aucun contexte supplémentaire.

Corrélation et création de rapports complexes

  • Objectif : exécuter des règles qui nécessitent des décomptes, des sommes ou des fenêtres multi-événements.
  • Avantage : s'assure que le système ingère et enrichit tous les journaux associés avant l'exécution, ce qui fournit des alertes plus précises pour la conformité et l'analyse des tendances.

Avant de commencer

Avant de modifier une programmation, 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 programmations des règles.
  • Vérification de l'environnement : assurez-vous que vos journaux sont correctement mappés au Unified Data Model (UDM) pour prendre en charge les agrégations d'intervalles programmés.

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 qui ont nécessité plus de temps pour l'enrichissement.
  • Enrichissement : processus d'ajout de contexte à un journal, tel que des métadonnées d'éléments ou une identité 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 Run Schedule (Programmation d'exécution) 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 en fonction de la programmation suivante. Ce délai garantit l'exhaustivité des données et tient compte de la latence d'ingestion ou d'enrichissement.

Programmation Critères d'attribution Timing de l'évaluation Cycles de régularisation
Temps réel (10 min) Événement unique ou fenêtre de correspondance < 1 h Peu de temps après l'arrivée Non. Évalue les données tardives/enrichies lors de l'exécution standard.
Toutes les heures (1 h) Fenêtre de correspondance entre 1 h et 48 h 1 à 2 heures après l'arrivée Oui. Inclut les étapes de 5 heures et de 24 heures.
Tous les jours (24 h) Fenêtre de correspondance > 48 h 24 à 25 heures après l'arrivée Oui. Inclut les étapes de 5 heures et de 24 heures.

Découvrez comment configurer des programmations personnalisées pour les règles.

Étapes de régularisation automatiques

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

  1. Exécution initiale : exécutée le plus rapidement possible pour exposer les menaces immédiates.
  2. Exécution intermédiaire (~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.
  3. Régularisation finale (~24 h) : exécutée une fois que toutes les données et l'enrichissement supplémentaires sont confirmés (visibilité à 100 %).

Remarque : Les règles à événement unique traitent les données arrivées en retard et enrichies lors de l'exécution standard, et n'utilisent pas les cycles de régularisation de 5 heures et de 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, procédez comme suit :

  1. Dans Google SecOps, accédez à Detection > Rules & Detections (Détection > Règles et détections).
  2. Cliquez sur Rules Dashboard (Tableau de bord des règles).
  3. Ouvrez le menu More more_vert pour votre règle.
  4. Sélectionnez une valeur Run Schedule (Programmation d'exécution) dans le menu (par exemple, 10 minutes).
  5. Cliquez sur Save (Enregistrer). Le système enregistre automatiquement vos modifications.

Identifier les détections

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

  1. Accédez à la page Alerts (Alertes) ou au Rules Dashboard (Tableau de bord des règles).
  2. Dans la colonne Detection Type (Type de détection), cliquez sur Lightbulb (Ampoule) pour voir si la détection provient d'une exécution initiale, d'une exécution de régularisation ou d'une recherche rétroactive.

Dépannage

Examinez les dimensions de vos données pour comprendre pourquoi des 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 fournir 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 vitesse de vos détections. Les programmations moins fréquentes augmentent le délai entre la survenue d'un événement et le moment où le système traite une détection.

  • Programmations toutes les heures : elles s'exécutent toutes les heures à l'aide des données les plus récentes disponibles. Aucun tampon n'est appliqué.

  • Programmations quotidiennes : le système introduit un tampon de 24 heures pour garantir l'ingestion complète des données avant le traitement.

Écarts entre les exécutions

L'exécution initiale d'une règle peut ne pas identifier une détection qui apparaît ensuite lors d'une exécution de régularisation. Ce comportement garantit que le système identifie la plupart des menaces immédiatement tout en permettant une confirmation haute fidélité ultérieure. Les causes les plus courantes sont les suivantes :

  • Latence d'ingestion des données : données de journal arrivant après la fin de la première exécution.
  • Exhaustivité de l'enrichissement : contexte provenant de sources externes (métadonnées ou identités d'éléments) toujours en cours de traitement lors de l'exécution initiale.
  • Ajustements de timing : les exécutions de régularisation attendent l'ensemble 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 programmations limitées.

Problème Cause et correction
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 programmés. De plus, les règles organisées suivent des programmations système fixes que vous ne pouvez pas modifier.
Intervalles non compatibles Si vous ne pouvez pas sélectionner Near Real-time (en temps quasi réel), votre règle utilise probablement une section match ou des agrégations (telles que count ou sum). Ces fonctions nécessitent des intervalles programmés pour traiter les données au fil du temps.

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