Comprendre les relectures de règles et le MTTD

Compatible avec :

Ce document explique comment les relectures de règles (également appelées exécutions de nettoyage ou exécutions de mise à jour) gèrent les données et les mises à jour de contexte tardives, et comment ces relectures affectent les métriques de temps moyen de détection (MTTD, Mean Time to Detect).

Relectures des règles

Google Security Operations traite de grands volumes de données de sécurité. Pour garantir des détections précises pour les règles qui dépendent de données contextuelles ou corrélées, le moteur de règles exécute automatiquement un processus de relecture des règles.

Le processus de relecture des règles gère les catégories de règles suivantes :

  • Règles à événement unique : ces règles sont rejouées lorsque le processus d'enrichissement UDM met à jour un événement précédemment évalué. Pour connaître les exceptions concernant les règles avec des tableaux de données, consultez la section Scénarios de données reçues tardivement plus loin dans ce document.

  • Règles à événement unique avec fenêtre (WSE) et règles à événement unique avec tables de données : ces règles disposent d'un mécanisme de programmation distinct pour gérer les données tardives, différent de celui des règles à événement unique et à événements multiples standards.

  • Règles à événements multiples : ces règles s'exécutent selon une programmation et traitent des blocs de temps d'événement. Ils réévaluent plusieurs fois le même bloc temporel à différents intervalles pour capturer les mises à jour tardives de l'enrichissement, telles que les données contextuelles utilisateur ou d'asset correspondantes, ou un indicateur de compromission (IOC). Les horaires exacts dépendent de la configuration de la programmation.

Déclencheurs de relecture des règles

Le système réévalue (réexécute) les règles pour s'assurer de détecter les événements, même si les données arrivent ou sont mises à jour après l'exécution initiale des règles. Ces données reçues tardivement incluent les catégories suivantes :

  • Événements sources arrivant en retard : l'événement de journal brut ou UDM lui-même arrive dans Google SecOps bien après l'horodatage réel de l'événement.
  • Données d'enrichissement reçues tardivement : les données contextuelles (par exemple, utilisateur, asset, renseignements sur les menaces) liées à un événement deviennent disponibles ou sont mises à jour par le système après le premier traitement de l'événement. Cela se produit souvent parce que les pipelines d'enrichissement, tels que le graphique de contexte d'entité (ECG), traitent les données par lots ou dépendent de sources de données externes.
  • Mises à jour rétroactives de l'enrichissement UDM : les données sources tardives (comme les enregistrements DHCP qui mettent à jour les noms d'hôte) déclenchent des modifications des champs d'événement UDM. Les règles utilisant des champs alias (champs enrichis) dans leur logique de détection, comme $udm.event.principal.hostname, peuvent déclencher des relectures lorsque les données sources sont retardées. Cette arrivée tardive met à jour rétroactivement les valeurs de ces champs.

Le système déclenche les relectures de règles différemment selon le type de règle et la nature des données tardives. L'objectif est d'équilibrer la rapidité de détection et l'exhaustivité des données.

Comment le système traite les données tardives par type de règle

Le type de règle et sa configuration déterminent la période pendant laquelle les données reçues tardivement peuvent déclencher une réévaluation de la règle.

  • Règles à événement unique (sans fenêtres de correspondance ni tables de données) :

    • Événements sources tardifs : en règle générale, ces règles traitent un événement, quel que soit l'ancienneté de son code temporel lorsqu'il arrive dans le système. Le système n'impose pas de fenêtre limite stricte pour le traitement initial des événements sources tardifs.
    • Enrichissement tardif : si des données d'enrichissement pour un événement précédemment évalué arrivent ou si une mise à jour a lieu, le système réévalue ces règles à événement unique par rapport à l'événement avec le nouveau contexte. Cela peut se produire des heures, voire des jours après l'événement initial.

  • Règles à événement unique avec fenêtre et règles à événement unique avec tableaux de données :

    • Ces règles ne suivent pas le même traitement des données tardives que les autres règles à événement unique ou les plannings de régularisation des règles multi-événements.
    • Voici leur comportement :
      • Heure limite : ces règles ne traitent pas les événements ingérés sept jours ou plus après leur code temporel.
      • Données tardives (< 7 jours) : le système traite les événements arrivant avec moins de sept jours de retard, mais avec une latence potentiellement plus élevée.
      • Événements sources reçus tardivement : les règles WSE ne traitent pas les événements si les données arrivent dans Google SecOps sept jours ou plus après le code temporel de l'événement.
      • Mises à jour du contexte : si le contexte d'un événement arrive en retard ou si un événement est enrichi de manière rétroactive, le système réévalue automatiquement les règles par rapport à l'événement enrichi. Cette relecture de règle peut déclencher de nouvelles détections, même si l'évaluation initiale n'en a pas généré.
      • Enrichissement tardif : si un événement UDM est mis à jour en raison d'un enrichissement (qui peut avoir lieu jusqu'à sept jours après l'ingestion), le système réévalue ces règles par rapport à l'événement mis à jour. Toutefois, contrairement aux autres types de règles, les modifications apportées au contenu des tableaux de données ne déclenchent pas une réévaluation automatique des événements passés pour ces règles.
      • Période d'analyse : ces règles utilisent une période d'analyse d'environ sept jours pour réévaluer les événements. Si des données d'enrichissement arrivent pour un événement qui se produit au cours de cette période de 7 jours, la règle sera réévaluée.

  • Règles à événements multiples :

    • Les règles à événements multiples s'exécutent selon une programmation et réévaluent les blocs temporels pour tenir compte des données tardives. La programmation de la règle détermine la période limite effective :
      • Exécution principale : le système exécute la première évaluation à l'heure de l'événement, plus tout délai de règlement configuré (par exemple, T+1 heure).
      • Exécution de la régularisation 1 : le système exécute la première régularisation environ quatre heures après l'exécution principale. Cela permet au système d'inclure les événements arrivés tardivement.
      • Deuxième exécution de correction (conditionnelle) : si vous activez l'option S'assurer que l'enrichissement est complet, le système exécute une dernière correction environ 30 heures après l'exécution principale. Cela permet au système de traiter les données et les enrichissements de contexte reçus tardivement pendant environ 30 heures.
      • Implications de la date limite : la dernière exécution de la régularisation détermine la date limite effective pour inclure les données tardives. Cela se produit généralement environ quatre heures après l'exécution principale (ou environ 30 heures après l'exécution principale si vous activez l'option Garantir l'exhaustivité de l'enrichissement). Les événements ou les enrichissements qui arrivent après la dernière exécution de régularisation pour une période donnée ne seront pas traités par cette règle pour cette période.

Exemples de scénarios de données tardives

  • Scénario 1 : Événement source tardif – Règle à événement unique

    • Google SecOps ingère un événement avec un code temporel datant de trois jours. Une règle standard à événement unique traite cet événement comme de nouvelles données.

  • Scénario 2 : Enrichissement tardif – Règle à événement unique

    • Le système a traité un événement de connexion hier. Aujourd'hui, il ingère et enrichit de nouvelles informations pour l'utilisateur concerné (par exemple, un changement de service). Le système réévalue la règle d'événement unique par rapport à l'événement de connexion avec le contexte utilisateur mis à jour.

  • Scénario 3 : Événement source tardif – Règle à événements multiples (ajustement par défaut de quatre heures)

    • Un événement arrive trois heures après son code temporel pour une règle à événements multiples programmée avec les paramètres par défaut. L'événement a manqué l'exécution principale initiale (T+1h), mais le système le traite lors de l'exécution de réconciliation de quatre heures.

  • Scénario 4 : Événement source tardif – Règle à événements multiples (sans exhaustivité de l'enrichissement)

    • Vous configurez une règle multi-événements avec un décalage d'exécution principal d'une heure sans activer l'option S'assurer que l'enrichissement est complet. Un événement arrive six heures après son code temporel.
    • Cet événement manque l'exécution principale (T+1h) et la première exécution de correction (T+4h). Le système ne traitera pas cet événement pour cette période, car il est arrivé après la dernière exécution de la régularisation.

  • Scénario 5 : Enrichissement tardif – Règle multi-événements (avec exhaustivité de l'enrichissement)

    • Une règle à événements multiples a un décalage d'une heure et vous activez l'option Garantir l'exhaustivité de l'enrichissement. Les données d'enrichissement d'un événement arrivent 28 heures après le code temporel de l'événement.
    • Le système réévalue la règle à l'aide de cet enrichissement tardif lors de la deuxième exécution de la mise à jour, environ 31 heures après l'événement.

  • Scénario 6 : Événement source tardif – Règle à événements multiples avec fenêtre de correspondance

    • Une règle à événements multiples dispose d'une fenêtre match de 48 heures et d'une programmation avec l'option Garantir l'exhaustivité de l'enrichissement activée (ajustement final vers T+30 h). Un événement arrive 36 heures après son code temporel. Cet événement ne sera pas traité, car il est arrivé après la dernière exécution de la mise à jour, même si l'heure de l'événement se trouve dans la fenêtre de correspondance de la règle par rapport aux autres événements. La date limite est basée sur l'heure d'arrivée par rapport au calendrier de régularisation, et pas seulement sur la période de correspondance.

  • Scénario 7 : Événement source tardif – Règle à événement unique avec fenêtre

    • Si un événement source avec un code temporel datant de huit jours arrive en retard, il peut se trouver en dehors de la période d'analyse de 7 jours pour les règles WSE et ne pas être traité.

Impact sur les métriques de timing

Lorsqu'une détection résulte d'une relecture de règle, le système utilise la terminologie suivante :

  • La période de détection ou le code temporel de l'événement de l'alerte font référence à l'heure de l'activité malveillante d'origine.
  • L'heure de création correspond à l'heure à laquelle le système a créé la détection, ce qui peut être beaucoup plus tard, parfois des heures ou des jours plus tard.
  • La latence de détection correspond à la différence de temps entre le code temporel de l'événement et l'heure de création de la détection.

Delta de la chronologie et MTTD

Le temps écoulé entre le code temporel de l'événement initial et la création d'une détection a un impact direct sur le calcul de votre MTTD.

Étape du pipeline / de la planification Timing de l'évaluation Impact sur la mesure du MTTD
Règle à événement unique (streaming) Continue (< 5 minutes après l'arrivée) Les détections en temps réel représentent la véritable vitesse de la plate-forme avec un impact minimal sur le délai moyen de détection.
Règle à événements multiples (exécution principale) 1 à 2 heures après l'arrivée (plus le délai de règlement configuré) Inclut la fenêtre de mise en mémoire tampon par lot inévitable requise pour agréger les états de corrélation multi-événements.
Règle à événements multiples (exécutions de régularisation) 4 heures ou 30 heures après l'exécution principale Une exécution secondaire (relecture) qui intègre des données d'enrichissement tardives fait que cette heure apparaît tardive ou différée par rapport au code temporel de l'événement. Ce delta a une incidence négative sur le calcul du MTTD.

Bonnes pratiques pour mesurer le temps moyen avant défaillance

Le MTTD quantifie le temps écoulé entre la compromission initiale et la détection efficace de la menace. Lorsque vous analysez les détections déclenchées par les relectures de règles, appliquez les bonnes pratiques suivantes pour conserver des métriques MTTD précises.

Google SecOps fournit plusieurs métriques interrogeables par les utilisateurs pour mesurer précisément le délai moyen de détection. Pour en savoir plus sur ces métriques, consultez la page Exemples de requêtes YARA-L 2.0 pour les tableaux de bord.

Une icône  dans la colonne Type de détection identifie les détections générées à partir de données d'événements 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. Cette icône s'affiche également sur la page Alertes de Google SecOps.

Prioriser les systèmes de détection en temps réel

Pour une détection plus rapide, utilisez des règles à événement unique. Ces règles s'exécutent en temps quasi réel, généralement avec un délai de moins de cinq minutes. Cela permet également une utilisation plus complète des détections composites.

Tenir compte de la relecture des règles dans les règles à événements multiples

Les règles à événements multiples entraînent intrinsèquement une latence plus élevée en raison de leur fréquence d'exécution planifiée. Lorsque vous mesurez le MTTD pour les détections à partir de règles multi-événements, sachez que les relectures automatiques des règles augmentent la couverture et la précision. Ces relectures permettent souvent de détecter des menaces nécessitant un contexte tardif, ce qui augmente la latence signalée pour ces détections.

  • Pour les alertes critiques et urgentes : utilisez des règles à événement unique ou des règles à événements multiples avec les fréquences d'exécution pratiques les plus courtes. La réduction de la fenêtre de correspondance n'a pas d'incidence directe sur la latence, mais elle peut améliorer l'efficacité en définissant le délai minimal.

  • Pour les corrélations complexes et de longue durée (UEBA, attaques en plusieurs étapes) : ces règles s'appuient sur des jointures contextuelles ou des listes de référence étendues, qui peuvent être mises à jour de manière asynchrone. Ils peuvent présenter une latence élevée avec des données contextuelles ou des données d'événement arrivant tardivement, mais ils offrent l'avantage d'une détection de haute fidélité plutôt qu'une vitesse absolue.

Optimiser les règles pour réduire la dépendance à l'enrichissement tardif

Pour optimiser la vitesse de détection et minimiser l'impact des exécutions d'enrichissement rétroactif, envisagez d'utiliser des champs non aliasés (champs que les pipelines d'enrichissement en aval ne traitent pas) dans la logique de vos règles, si possible.

É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.