Configurer des plannings personnalisés pour les règles

Compatible avec :

Ce document s'adresse aux administrateurs de plate-forme et aux analystes SOC qui souhaitent configurer et résoudre les problèmes liés aux plannings personnalisables pour les règles multi-événements. Il explique comment définir des plannings de traitement et exécuter des vérifications supplémentaires pour inclure les données tardives.

En suivant la procédure décrite dans ce document, vous pouvez contrôler précisément la latence de détection et l'intégrité des données. Une fois l'ingestion terminée, vos détections sont à la fois rapides et précises, ce qui réduit les faux négatifs causés par les retards d'ingestion et assure des opérations de sécurité cohérentes.

Les plannings personnalisables offrent transparence et contrôle sur la façon dont les règles multi-événements s'exécutent dans Google Security Operations. Les règles multi-événements nécessitent une période tampon pour agréger les données avec précision. Cette méthode vous permet de définir cette période au lieu de vous fier aux paramètres système par défaut.

Cas d'utilisation courants

Utilisez des plannings personnalisables pour adapter la vitesse de détection à la disponibilité et à l'exhaustivité des données.

Surveillance des comptes inactifs basée sur la conformité

Scénario : Vous devez surveiller les comptes qui ne se sont pas connectés depuis 30 jours pour répondre à une exigence d'audit.

  • Objectif : Prioriser l'exhaustivité de l'enrichissement.
  • Valeur : assure une fidélité maximale des données en activant l'option S'assurer que l'enrichissement est complet, qui attend que tous les journaux et métadonnées globaux soient traités avant l'évaluation finale.

Séparation des données MSSP multi-locataires

Scénario : En tant que fournisseur de services de sécurité gérés (MSSP), vous gérez les données de plusieurs clients avec des vitesses d'ingestion de journaux variables.

  • Objectif : gérer les différentes vitesses d'ingestion dans plusieurs environnements client.
  • Valeur : réduire les alertes "faux négatifs". En attendant une à deux heures avant la première exécution, le système réduit le nombre de détections qui n'apparaissent que lors des exécutions de correction, ce qui offre une expérience plus cohérente aux analystes SOC qui surveillent le tableau de bord.

Terminologie clé

  • Première exécution (𝑇 + décalage) : exécution initiale de la logique de la règle. Le décalage représente le délai ajouté pour tenir compte des données tardives.
  • Exécution de la régularisation : réévaluation en arrière-plan de la même période pour capturer les journaux ou les données d'enrichissement reçus après la première exécution.
  • Enrichissement : métadonnées externes (comme des tags d'éléments ou des alias d'utilisateur) ajoutées aux journaux lors du traitement.

Avant de commencer

Avant de tenter de modifier ou d'automatiser vos plannings de règles, assurez-vous que votre environnement et votre compte répondent aux exigences de sécurité et système nécessaires. La validation de ces prérequis permet d'éviter les erreurs de déploiement et de s'assurer que votre logique de détection est conforme aux règles de gestion de l'authentification et des accès de votre organisation.

Autorisations

Obligatoire : Pour modifier les plannings de règles, vous devez disposer d'un rôle IAM qui accorde l'action suivante :

detection:ModifyRuleSchedule

Rôles prédéfinis :

  • roles/detectionEngine.admin

  • roles/detectionEngine.editor

Vérification de l'environnement

  • Type de règle : les plannings personnalisables ne s'appliquent qu'aux règles multi-événements. Les règles d'un seul événement et les règles sélectionnées sont exclues.
  • Période match : les règles dont la période match est supérieure à 48 heures sont limitées à une fréquence d'exécution quotidienne.
  • Migration : la migration d'un ancien planning vers un planning personnalisable est un processus à sens unique et ne peut pas être annulée.

Configurer la programmation d'une règle multi-événements

Pour configurer la programmation d'une règle multi-événements, procédez comme suit :

  1. Dans Google SecOps, accédez à Détection > Règles et détections.
  2. Cliquez sur Tableau de bord des règles.
  3. Recherchez votre règle, puis cliquez sur Plus more_vert et sélectionnez Exécuter la programmation.
  4. Dans l'onglet Programmation de la règle, sélectionnez une valeur pour le champ Programmation de la première exécution, puis indiquez la fréquence d'exécution de la règle.
  5. Activez le bouton Ajuster la première exécution pour les données tardives.
    • Échec prévu : il est possible que la première exécution ne récupère pas tous les journaux si le décalage est plus court que la latence d'ingestion réelle de votre source.
    • Mesure corrective : augmentez le décalage ou utilisez les exécutions de régularisation pour la validation finale.
  6. Activez l'option Garantir l'exhaustivité de l'enrichissement.
    • Échec prévu : les alertes peuvent s'afficher bien après le code temporel de l'événement.
    • Étape de correction : n'utilisez cette option que pour les règles de conformité non critiques, où l'exactitude est plus importante que la rapidité.
  7. Consultez l'aperçu du calendrier des règles pour comprendre le calendrier d'exécution :
    • Première exécution (𝑇 + décalage) : le système exécute la logique de la règle après le délai que vous spécifiez pour les données reçues en retard.
    • Première exécution de la régularisation (T+4 heures) : le système analyse à nouveau la période quatre heures après la première exécution pour capturer les données manquantes ou tardives. Si vous activez le bouton S'assurer que l'enrichissement est complet, cette exécution attend également le traitement de toutes les données d'enrichissement associées.
    • Exécution de la régularisation 2 (T+30 heures) : cette exécution n'apparaît que si vous activez l'option Garantir l'exhaustivité de l'enrichissement. Le système effectue une dernière analyse 30 heures après la première exécution pour garantir une fidélité maximale des données.
  8. Cliquez sur Enregistrer.

Comprendre l'aperçu du planning

L'aperçu du calendrier identifie les étapes spécifiques de votre logique de détection. Utilisez ces exécutions en arrière-plan pour mesurer précisément le temps moyen de détection (MTTD) et vérifier l'intégrité des alertes.

Première exécution (T + décalage)

La première exécution identifie les menaces le plus rapidement possible. Étant donné que certaines données peuvent être encore en transit ou en cours d'enrichissement, les détections de la première exécution peuvent arriver plus tard que prévu.

Exécutions de régularisation

Les ajustements proactifs réévaluent la période. Ces exécutions permettent à la plate-forme de capturer les éléments suivants :

  • Journaux arrivés tardivement : données qui sont arrivées sur la plate-forme après la première exécution.
  • Contexte d'enrichissement : métadonnées, telles que les identités des composants ou les alias des utilisateurs, qui nécessitent un traitement en arrière-plan supplémentaire.

Dépannage

Examinez les problèmes de planification en vérifiant le calendrier d'évaluation et la configuration des règles. Bien que la plate-forme automatise la plupart des tâches de planification, certains paramètres ou retards de données peuvent avoir un impact sur le moment où les détections apparaissent.

Limites

  • Règles multi-événements uniquement : cette fonctionnalité n'est pas disponible pour les règles mono-événement.
  • Règles personnalisées uniquement : les règles sélectionnées utilisent des plannings fixes que vous ne pouvez pas modifier. Si vous consultez une règle sélectionnée, le système affiche le message Curated rules use a legacy schedule.

Correction des erreurs

Erreur Problème Corriger
Options manquantes L'onglet "Programmation des règles" est grisé ou des options sont manquantes. Vérifiez que la règle est une règle personnalisée multi-événements et que la période de correspondance est inférieure à 48 heures.
Alertes différées Les détections arrivent plus tard que l'intervalle prévu. Vérifiez si le bouton S'assurer que l'enrichissement est complet est activé. Il est possible que le système attende le traitement des métadonnées.
Alertes de régularisation uniquement Les détections n'apparaissent jamais lors de la première exécution (𝑇). Cliquez sur Latence d'ingestion pour vérifier. Si les journaux arrivent avec 15 minutes de retard, mais que votre décalage est de 10 minutes, augmentez le décalage de la première exécution.

Les détections n'apparaissent que lors des exécutions de régularisation

Si une détection n'apparaît pas lors de la première exécution (𝑇), mais apparaît lors d'une exécution de correction (𝑇+4$ ou 𝑇+30$), vérifiez les points suivants :

  • Latence d'ingestion : vérifiez si la source de journaux présente un délai. Si les journaux arrivent 15 minutes après l'événement, un programme de première exécution de 10 minutes ne les prendra pas en compte. Les ajustements permettent de prendre en compte ces données tardives.
  • Enrichissement du contexte : vérifiez si la règle repose sur des métadonnées externes, telles que des tags d'assets ou des alias d'utilisateur. Si le processus d'enrichissement prend plus de temps que la fenêtre de première exécution, la détection n'apparaît qu'une fois que le système a terminé l'enrichissement lors d'une exécution ultérieure.

Options de personnalisation manquantes

Si l'onglet Programmation des règles n'affiche pas d'options de personnalisation ou si le menu est grisé :

  • Vérifiez le type de règle : les plannings personnalisables ne s'appliquent qu'aux règles multi-événements. Les règles à événement unique utilisent le moteur continu (en temps réel) et ne sont pas compatibles avec les plannings personnalisés.
  • Vérifiez la fenêtre match : les règles dont la fenêtre match est supérieure à 48 heures sont limitées à une fréquence d'exécution quotidienne et ne peuvent pas être personnalisées.
  • Identifier les règles sélectionnées : vous ne pouvez pas modifier la programmation des règles sélectionnées. Recherchez le message Curated rules uses a legacy schedule pour confirmer si la règle est une règle système protégée.

Retard inattendu dans les alertes de première exécution

Si une détection arrive après l'intervalle planifié :

  • Période d'initialisation : les règles nouvelles ou récemment modifiées nécessitent une période d'initialisation d'une heure. Les détections ne s'affichent que lorsque la plate-forme a terminé cette configuration initiale et a commencé le premier cycle planifié.
  • Temps d'attente pour l'enrichissement : si vous activez l'option S'assurer que l'enrichissement est complet, le système peut ajuster dynamiquement le timing pour attendre la fin des processus d'enrichissement des données. Bien que ce processus permette d'éviter les détections manquées, il peut entraîner un retard de la détection initiale par rapport au code temporel 𝑇 exact.

Les mesures MTTD semblent élevées

Les mesures MTTD incluent la période de stabilisation requise pour l'exhaustivité des données.

  • Examiner le tampon : pour un programme d'une heure, le système évalue les événements une à deux heures après leur arrivée.
  • Optimiser pour la vitesse : si vous avez besoin d'une latence plus faible, passez la règle à un calendrier en temps réel. Remarque : Cela peut augmenter le nombre de détections qui s'appuient sur des exécutions de correction pour une précision totale.

Identifier les sources de détection

Google SecOps utilise des indicateurs visuels pour vous aider à distinguer les détections initiales de celles qui apparaissent lors des réexécutions en arrière-plan.

Indicateurs de détection

Dans la colonne Type de détection, identifie les détections provenant d'exécutions de régularisation, de retraitement ou de recherche rétroactive.

  • Si cette icône s'affiche, cela signifie que la détection a eu lieu lors d'une exécution de mise à jour (𝑇+4$ ou 𝑇+30$) plutôt que lors de l'exécution initiale (𝑇).
  • Les détections associées à cette icône indiquent souvent que la plate-forme a détecté la menace après l'ingestion initiale, généralement en raison de journaux arrivés tardivement ou de retards d'enrichissement.

Vérifier l'intégrité des alertes sur la page "Alertes"

L'icône  sur la page Alertes indique la source d'une alerte. Utilisez cet indicateur pour vérifier la source d'une alerte lorsque vous examinez une chronologie.

  • Les alertes sans icône proviennent du moteur de première exécution (𝑇) ou du moteur continu.
  • Les alertes avec le signal  indiquent que le système a identifié la menace lors d'une analyse ultérieure des données pour une précision maximale.

Validation et test

Pour vérifier que votre programmation fonctionne comme prévu, procédez comme suit :

  1. Accédez au tableau de bord des règles.
  2. Sélectionnez votre règle et affichez l'onglet Détections.
  3. Filtrez par pour voir si vos exécutions True-up capturent des données qui ont échappé à la première exécution, puis ajustez vos décalages en conséquence.

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