Comprendre les relectures de règles et le délai moyen de détection

Compatible avec :

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

Relectures de 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 de règles.

Le processus de relecture de 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 les exceptions concernant les règles avec des tables de données, consultez la section Scénarios de données tardives 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 planification distinct pour gérer les données tardives, différent des règles à événement unique et à événements multiples standards.

  • **Règles à événements multiples** :ces règles s'exécutent selon une planification, en traitant des blocs de temps d'événement. Elles réévaluent de manière répétée 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'actif correspondantes, ou un indicateur de compromission. Les délais exacts dépendent de la configuration de la planification.

Déclencheurs de relecture de règles

Le système réévalue (réexécute) les règles pour s'assurer qu'il détecte les détections, même si les données arrivent ou sont mises à jour après l'exécution initiale de la règle. Ces données tardives incluent les catégories suivantes :

  • Événements sources tardifs : 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 tardives : les données contextuelles (par exemple, utilisateur, actif, renseignements sur les menaces) liées à un événement deviennent disponibles, ou le système les met à jour, après le premier traitement de l'événement. Cela se produit souvent, car les pipelines d'enrichissement, tels que le graphique de contexte d'entité, traitent les données par lot ou dépendent de sources de données externes.
  • Mises à jour d'enrichissement UDM rétroactives : les données sources tardives (comme les enregistrements DHCP qui mettent à jour les noms d'hôte) déclenchent des modifications dans les champs d'événement UDM. Les règles qui utilisent des champs avec 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 ces valeurs de champ.

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 gère les données tardives par type de règle

Le type de règle et sa configuration déterminent la fenêtre temporelle dans laquelle les données tardives 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 horodatage 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 les données d'enrichissement d'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 (WSE) et règles à événement unique avec tables de données :

    • Ces règles ne suivent pas la même gestion des données tardives que les autres règles à événement unique ou les planifications de mise à niveau des règles à événements multiples.
    • Voici leur comportement :
      • Limite : ces règles ne traitent pas les événements ingérés sept jours ou plus après l'horodatage de l'événement.
      • Données tardives (< 7 jours) : le système traite les événements qui arrivent moins de sept jours en retard, mais avec une latence potentiellement plus élevée.
      • Événements sources tardifs : les règles WSE ne traitent pas les événements si les données arrivent dans Google SecOps sept jours ou plus après l'horodatage de l'événement.
      • Mises à jour de contexte : si le contexte d'un événement arrive en retard ou si un événement est enrichi rétroactivement, le système réévalue automatiquement les règles par rapport à l'événement enrichi. Cette relecture de règles 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 à d'autres types de règles, les mises à jour du contenu des tables de données ne déclenchent pas de 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 dans cette fenêtre de 7 jours, la règle est réévaluée.

  • Règles à événements multiples :

    • Les règles à événements multiples s'exécutent selon une planification et réévaluent les blocs temporels pour tenir compte des données tardives. La planification de la règle détermine la fenêtre 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 mise à niveau 1 : le système exécute la première exécution de mise à niveau environ quatre heures après l'exécution principale. Cela permet au système d'inclure les événements tardifs.
      • Exécution de mise à niveau 2 (conditionnelle) : si vous activez l'option S'assurer que l'enrichissement est complet, le système exécute une dernière exécution de mise à niveau environ 30 heures après l'exécution principale. Cela étend la fenêtre permettant au système de traiter les données tardives et les enrichissements de contexte jusqu'à environ 30 heures.
      • Implications de la limite : l'exécution finale de mise à niveau dicte la 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 S'assurer que l'enrichissement est complet). Les événements ou enrichissements qui arrivent après l'exécution finale de mise à niveau pour une fenêtre temporelle donnée ne seront pas traités par cette règle pour cette fenêtre.

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 horodatage datant de trois jours. Une règle à événement unique standard 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 à é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 (mise à niveau par défaut de quatre heures)

    • Un événement arrive trois heures après son horodatage pour une règle à événements multiples planifiée avec les paramètres par défaut. L'événement a manqué l'exécution principale initiale (T + 1 heure), mais le système le traite lors de l'exécution de mise à niveau 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 à événements multiples 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 horodatage.
    • Cet événement manque l'exécution principale (T + 1 heure) et la première exécution de mise à niveau (T + 4 heures). Le système ne traitera pas cet événement pour cette fenêtre temporelle, car il est arrivé après l'exécution finale de mise à niveau.

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

    • Une règle à événements multiples 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.
    • Le système réévalue la règle à l'aide de cet enrichissement tardif lors de la deuxième exécution de mise à niveau, environ à T + 31 heures.

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

    • Une règle à événements multiples comporte une fenêtre match de 48 heures et une planification avec l'option S'assurer que l'enrichissement est complet activée (mise à niveau finale vers T + 30 heures). Un événement arrive 36 heures après son horodatage. Cet événement ne sera pas traité, car il est arrivé après l'exécution finale de mise à niveau, même si l'heure de l'événement se situe dans la fenêtre de correspondance de la règle par rapport aux autres événements. La limite est basée sur l'heure d'arrivée par rapport à la planification de mise à niveau, et pas seulement sur la fenêtre de correspondance.

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

    • Si un événement source avec un horodatage datant de huit jours arrive en retard, il peut se trouver en dehors de la fenêtre de rétrospection de sept 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ègles, le système utilise la terminologie suivante :

  • La fenêtre de détection ou l'horodatage de l'événement de l'alerte fait référence à l'heure de l'activité malveillante d'origine.
  • L'heure de création correspond à l'heure à laquelle le système crée 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 l'horodatage de l'événement et l'heure de création de la détection.

Delta de chronologie et délai moyen de détection

Le temps écoulé entre l'horodatage initial de l'événement et la création d'une détection a un impact direct sur le calcul du délai moyen de détection.

Étape du pipeline / de la planification Timing de l'évaluation Impact sur la mesure du délai moyen de détection
Règle à événement unique (streaming) Continu (< 5 minutes après l'arrivée) Les détections en temps réel représentent la vitesse réelle 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 à événements multiples.
Règle à événements multiples (exécutions de mise à niveau) 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 ce délai apparaît tardif ou retardé par rapport à l'horodatage de l'événement. Ce delta affecte négativement le calcul du délai moyen de détection.

Bonnes pratiques pour mesurer le délai moyen de détection

Le délai moyen de détection quantifie le temps écoulé entre la compromission initiale et la détection effective 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 de délai moyen de détection précises.

Google SecOps fournit plusieurs métriques interrogeables par l'utilisateur pour mesurer précisément le délai moyen de détection. Pour en savoir plus sur ces métriques, consultez 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 à partir de données d'événement arrivant plus de 30 minutes en retard, d'exécutions de mise à niveau 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 les détections les plus rapides, 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 de 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 délai moyen de détection pour les détections à partir de règles à événements multiples, reconnaissez que les relectures de règles automatisées augmentent la couverture et la précision. Ces relectures détectent souvent les 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'affecte pas directement la latence, mais elle peut augmenter l'efficacité en définissant le délai minimal.

  • Pour la corrélation complexe 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. Elles peuvent présenter une latence élevée avec des données contextuelles ou d'événement tardives, mais elles offrent l'avantage d' une détection plus fidèle plutôt que d'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étroactives, envisagez d'utiliser des champs sans alias (champs que les pipelines d'enrichissement en aval ne traitent pas) dans la logique de votre règle, si possible.

Étape suivante

Pour explorer 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 auprès des membres de la communauté et des professionnels de Google SecOps.