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) gèrent les données et les mises à jour de contexte reçues tardivement, et comment ces relectures affectent les métriques de délai moyen de détection (MTTD, Mean Time To Detect).

Lectures en différé des règles

Google SecOps 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 : lorsque le processus d'enrichissement UDM met à jour un événement précédemment évalué, le système rejoue les règles à événement unique. (Consultez les exceptions pour les règles avec des tableaux de données ci-dessous.)

  • 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 planification distinct pour gérer les données reçues en retard, différent de celui des règles à événement unique et à événements multiples standards.

  • Règles multi-événements : les règles multi-événements s'exécutent selon une programmation et traitent des blocs de temps d'événement. Ces règles réévaluent à plusieurs reprises le même bloc temporel à différents intervalles pour capturer les mises à jour d'enrichissement tardives, 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 du programme.

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 tardivement : l'événement de journal brut ou UDM lui-même arrive dans Google SecOps bien après le code temporel réel de l'événement.
  • Données d'enrichissement reçues tardivement : les données contextuelles (par exemple, les informations sur l'utilisateur, l'asset ou le renseignement 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 des 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, quelle que soit l'ancienneté de son code temporel lorsqu'il arrive dans le système. Le système n'impose pas de délai strict 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 d'é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 d'événement unique avec fenêtre (WSE) et règles d'é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 calendriers de réconciliation 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 reçues en retard (< 7 jours) : le système traite les événements reçus avec moins de sept jours de retard, mais avec une latence potentiellement plus élevée.
      • Événements sources arrivant 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'a pas abouti à une détection.
      • 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 multi-événements :

    • Les règles multi-événements s'exécutent selon une programmation et réévaluent les blocs temporels pour tenir compte des données tardives. La façon dont vous configurez la programmation de la règle détermine la période limite effective :
      • Calendrier par défaut : le système exécute généralement des ajustements automatiques environ 5 heures et 24 heures après l'heure de l'événement. Si les données arrivent après la fin de l'exécution de 24 heures, elles ne seront pas évaluées par cette règle pour cette période.
      • Plannings personnalisables activés : cette fonctionnalité vous permet de mieux contrôler les heures d'exécution grâce aux paramètres de "Fréquence d'exécution". Consultez Configurer des plannings personnalisés pour les règles. Voici les dates clés :
        • Première exécution : le système exécute la première exécution à l'heure de l'événement, plus le décalage configuré (par exemple, T+1 heure).
        • Première exécution de la régularisation : le système exécute la première régularisation environ quatre heures après la première exécution. Cela signifie que le système peut inclure des événements arrivant jusqu'à environ T+4 à 5 heures.
        • Deuxième exécution de correction (conditionnelle) : si vous activez l'option Garantir l'exhaustivité de l'enrichissement, le système exécute une dernière correction environ 30 heures après la première exécution. Cela étend la période pendant laquelle le système peut traiter les données tardives à environ T+30 à 31 heures.
      • Implications du seuil : avec les plannings personnalisables, la dernière exécution de la régularisation détermine le seuil effectif pour inclure les données tardives. Cela se produit généralement environ quatre heures après la première exécution ou environ 30 heures après la première exécution si vous activez l'option Garantir l'exhaustivité de l'enrichissement. Les événements ou les enrichissements arrivant après l'exécution finale de la réconciliation 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 arrivant tardivement

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

    • 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 d'é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 multi-événements (planning par défaut)

    • Si un événement arrive 10 heures après son code temporel, le système le manque lors de l'exécution de la mise à jour de 5 heures, mais le traite lors de l'exécution de la mise à jour de 24 heures. Un événement qui arrive avec 25 heures de retard ne sera pas traité.

  • Scénario 4 : Événement source tardif – Règle multi-événements (planning personnalisable)

    • Vous configurez une règle multi-événements avec un décalage de première exécution d'une heure. Un événement arrive six heures après son code temporel.
    • Cet événement manque la première exécution (T+1h) et la première exécution de correction (T+4h). Le système ne traitera PAS cet événement avec cette règle, sauf si vous activez l'option Garantir l'exhaustivité de l'enrichissement.

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

    • Une règle multi-événements a un décalage d'une heure et vous activez l'option S'assurer que l'enrichissement est complet. Les données d'enrichissement d'un événement arrivent 28 heures après l'horodatage de l'événement.
    • Certaines de ces données d'enrichissement tardif peuvent être disponibles pour la deuxième exécution de la mise à jour, qui a lieu environ 30 heures après l'heure T (car vous avez activé l'option Garantir l'exhaustivité de l'enrichissement). Si les données d'enrichissement sont disponibles, le système réévalue la règle à l'aide de cet enrichissement tardif.

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

    • Une règle multi-événements comporte une période match de 48 heures et un calendrier personnalisé 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 réconciliation, même si l'heure de l'événement se trouve dans la période 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 d'é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.

Le réenrichissement dû à des données tardives ou à une latence lors de la mise à jour d'une source de contexte telle que le graphique de contexte d'entité (ECG) entraîne généralement une latence de détection élevée.

Ce décalage horaire peut donner l'impression qu'une détection est "tardive" ou "retardée", ce qui peut induire les analystes en erreur et fausser les métriques de performances telles que le temps moyen de détection.

Composant de métrique Source de l'heure Impact des rediffusions sur le temps moyen avant détection
Période de détection / Horodatage de l'événement Heure à laquelle l'événement de sécurité d'origine s'est produit. Les rediffusions conservent cette précision par rapport à l'heure de l'événement.
Date et heure de détection / de création Heure à laquelle le moteur a réellement émis la détection. 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 MTTD

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 MTTD. Pour en savoir plus sur ces métriques, consultez la page Exemples de requêtes YARA-L 2.0 pour la page "Tableaux de bord".

Une icône  dans la colonne Type de détection identifie les détections générées par le système à partir de données d'événements arrivées avec plus de 30 minutes de retard, d'exécutions de retraitement des règles 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 des détections plus rapides, utilisez des règles d'é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 multi-événements

Les règles multi-événements 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 de règles automatisées 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 multi-événements 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 à 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.

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