Comprendre les délais de détection des règles

Compatible avec :

Ce document explique les retards de détection des règles dans Google Security Operations, identifie les facteurs contributifs, décrit les approches de dépannage et suggère des techniques pour réduire les retards dans la mesure du possible.

Règles de détection

Les règles de détection examinent les événements UDM (Universal Data Model) réguliers et d'entité, qui sont des journaux bruts normalisés, pour générer des détections en fonction des spécifications de la règle. Les événements UDM d'entité contiennent généralement des informations contextuelles, comme des détails sur l'utilisateur ou l'asset. Les règles génèrent également des détections en fonction de celles générées précédemment.

Retards prévus et imprévus

Les délais de détection peuvent être soumis à des retards de traitement. Si certaines règles se déclenchent en temps quasi réel, d'autres peuvent prendre plusieurs minutes ou heures. Des facteurs tels que le type de règle, la fréquence d'exécution et la méthode de génération de détections ont une incidence sur ces délais. Ce document explore ces facteurs de retard et d'autres.

Nous classons les retards dans deux catégories : prévus ou imprévus.

  • Retards prévus : ces retards résultent du processus d'ingestion et des choix de configuration que vous effectuez lorsque vous configurez la règle de détection. Par exemple, le temps nécessaire pour créer une détection est un facteur. Ces délais dépendent de facteurs structurels connus, tels que le type de règle, la fréquence d'exécution, la méthode de génération de la détection, les limites connues et d'autres facteurs prévisibles.
     Vous pouvez réduire ces délais en modifiant ou en ajustant les configurations des règles de détection, comme décrit dans ce document.
     Pour en savoir plus, consultez Conseils pour réduire les délais.

  • Retards imprévus : il s'agit de retards spécifiques à une règle ou à un événement, causés par de nombreux facteurs, y compris des retards dans la réception des données d'événement par Google SecOps, une lenteur temporaire dans le traitement des pipelines au sein des services Google SecOps, le réenrichissement et d'autres retards de traitement des données.

Analyser les délais de détection des règles

Pour analyser les délais de détection des règles, recherchez des informations sur la règle et les facteurs qui l'entourent :

  1. Dans la console Google SecOps, accédez à Détection > Règles et détections.

    Le tableau de bord des règles affiche les métadonnées des règles, telles que Rule name, Rule type et Run frequency.

    Pour en savoir plus, consultez Afficher les règles dans le tableau de bord des règles.

  2. Dans le tableau de bord des règles, cliquez sur le nom d'une règle pour afficher l'historique des détections et d'autres détails concernant cette règle.

  3. Pour toute exécution de règle particulière, plusieurs facteurs peuvent avoir un impact sur la latence de détection. Les dimensions telles que Rule type, Run frequency, Event type, Event time et Ingested time sont de bonnes heuristiques pour comprendre pourquoi une détection particulière a été retardée.

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 retardées de plus de 30 minutes, 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.

  1. Familiarisez-vous avec les sujets suivants pour comprendre comment ces facteurs influencent les délais de détection des règles :

Méthodes de génération de la détection

Découvrez comment le système crée des détections de règles pour comprendre comment la méthode de génération de détections affecte les délais de détection.

Le système génère des détections de règles de différentes manières :

  1. Streaming Engine

    Streaming Engine est un pipeline de streaming dédié qui fonctionne avec une faible latence (généralement moins de cinq minutes de délai). Elle évalue les règles à événement unique standards qui ne contiennent aucune section "Aucune correspondance", aucun ensemble de données externes (comme des listes de référence ou des tableaux de données) et aucune fonction UEBA.

  2. Moteur de requêtes

    Le moteur de requête évalue les règles complexes à événement unique et à événements multiples :

    • Règles à événement unique complexes :

      • Règles à événement unique avec des listes de référence ou des tableaux de données : règles qui évaluent un seul événement et effectuent des recherches dans des listes de référence ou des tableaux de données.
      • Règles d'événement unique avec fenêtre : règles qui évaluent un seul événement avec une fenêtre de correspondance et une simple condition d'existence (par exemple, $e, #e > 0 ou #e >= 1).
      • Bien que les règles complexes à événement unique utilisent le moteur de requête plutôt que le moteur de flux, elles sont planifiées selon une programmation en temps quasi réel à haute fréquence à mesure que de nouvelles données sont ingérées. Cela permet d'obtenir une latence plus faible, proche de celle habituelle du moteur de streaming. Les données enrichies et celles arrivant tardivement sont réévaluées lors de l'exécution standard des requêtes, sans nécessiter d'intervalles de correction multi-événements.

    • Règles à événements multiples : ces règles interrogent les données par blocs de heure de l'événement (10 minutes, heure, jour), selon une programmation que vous définissez. Les délais de nouvelle requête pour les données reçues tardivement dépendent du type de programmation.

      • Pour la programmation par défaut, les nouvelles requêtes sont envoyées environ 5 et 24 heures après l'heure de l'événement.
      • Les plannings personnalisables proposent différents délais de régularisation. Pour en savoir plus, consultez Comprendre les relectures de règles et le MTTD.

  3. Règles exécutées par rapport aux données historiques

    Pour en savoir plus, consultez Chasses rétroactives.

  4. Réenrichissement des événements UDM

    Pour en savoir plus, consultez Réenrichissement des événements UDM et Traitement du graphique du contexte des entités.

Limitations connues

Voici quelques limites standards qui contribuent aux retards de détection des règles :

  • Les délais d'enrichissement peuvent parfois être plus longs que prévu. Le retraitement de l'enrichissement entraîne une réévaluation des données lors des exécutions ultérieures des règles. Le système exécute plusieurs enrichissements. Il peut mettre à jour les événements UDM jusqu'à 24 heures après leur ingestion.

  • Règles à événements multiples :

    • Pour les règles à événements multiples avec la programmation par défaut, le système réexécute les règles environ 5 heures et 24 heures après l'heure de l'événement.

    • Les règles à événements multiples avec des programmes personnalisables ont des heures de régularisation différentes.

    Ces relectures de règles sont déclenchées pour traiter les données tardives.

  • Les règles contextuelles sont des règles qui s'appuient sur des sources d'enrichissement telles que l'alias d'identité et d'asset, ou le graphique de contexte d'entité. Comme ces règles reposent sur plusieurs sources d'événements, elles sont plus susceptibles d'être affectées par une latence élevée.

  • Le système réexécute les règles entre 5 et 8 heures, puis entre 24 et 48 heures après l'exécution initiale des règles. Ces deux relectures de règles distinctes sont déclenchées en fonction des temps d'exécution du pipeline de retraitement.

  • Pour connaître les autres limites de détection, consultez Comprendre les limites de détection.

Résoudre les problèmes de retard de détection des règles

Résolvez les problèmes de retard de détection des règles en procédant par élimination.

Suivez cette approche suggérée pour examiner et résoudre les problèmes de retard de détection des règles :

  1. Vérifiez s'il y a des retards évidents :

    Déterminez s'il existe un délai d'ingestion :

    1. Dans la console Google SecOps, accédez à Détection > Règles et détections.

    2. Recherchez la règle à analyser dans le tableau de bord des règles.

    3. Comparez le Event time au Ingested time.

      Par exemple, pour une détection de règle spécifique, s'il existe un grand écart entre Event time et Ingested time, vous pouvez probablement attribuer le délai de détection à un délai prévu. Une icône  est appliquée dans la colonne Type de détection lorsque la Ingestion time est plus de 30 minutes après la Event time.

  2. Vérifiez la date et l'heure de collecte de la source de contexte :

    Vérifiez l'heure de collecte de la source de contexte.

    Les règles contextuelles peuvent inclure les sources de contexte suivantes. Vérifiez les heures de collecte :

    • Champs dérivés de l'enrichissement UDM.
    • Événements incluant un champ principal.

    • Règles faisant référence à un champ graph.entity.

      Les règles faisant référence au graphique du contexte d'entité (ECG) avec la syntaxe graph.entity peuvent entraîner une latence particulièrement élevée. Par exemple, le pipeline ECG génère des données contextuelles, un processus qui peut prendre 30 heures ou, dans certains cas, jusqu'à 8 jours, selon le type de données.

    Pour en savoir plus, consultez Retards dans le traitement des données.

  3. Examinez la fréquence d'exécution de la règle et la configuration de la période de correspondance :

    • Fréquence : vérifiez la fréquence d'exécution de la règle. Une règle configurée pour s'exécuter moins fréquemment entraîne naturellement des délais de détection plus longs.
    • Période de correspondance : si une règle a une période de correspondance, le délai minimal correspond à la durée de cette période.
    • Relation entre la fréquence et la période de correspondance : assurez-vous que la fréquence d'exécution est compatible avec la période de correspondance. Par exemple, pour les fenêtres de correspondance de moins de 60 minutes, une fréquence d'exécution de 10 minutes (quasi temps réel) est acceptée. Pour les périodes de correspondance de 60 minutes ou plus (jusqu'à 48 heures), utilisez 1 heure. Pour les fenêtres de correspondance de plus de 48 heures, utilisez "Tous les jours".

  4. Vérifiez si des incidents récents ont eu lieu :

    Recherchez les incidents récents qui auraient pu entraîner des retards ou des problèmes avec les flux de données.

Conseils pour réduire les délais

Pour mettre à jour les configurations des règles de détection, consultez Gérer les règles à l'aide de l'éditeur de règles.

Utilisez les techniques suivantes pour réduire les délais dans la mesure du possible :

  • Pour les règles sensibles à la latence, utilisez les options d'exécution les plus fréquentes :

    • Augmenter la fréquence d'exécution de la règle :

      Pour réduire les délais, configurez la fréquence la plus élevée possible en fonction du type de règle et de la période de correspondance :

      • Pour toutes les règles à événement unique : utilisez Temps quasi réel.
      • Pour les règles multi-événements avec des fenêtres de correspondance de moins de 60 minutes : utilisez Pratiquement en temps réel (10 minutes).
      • Pour les règles multi-événements dont la période de correspondance est de 60 minutes ou plus : utilisez 1 heure ou Tous les jours, selon le cas.

      Pour en savoir plus, consultez Définir la fréquence d'exécution.

    • Réduire la durée de la fenêtre de correspondance :

      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.

  • Évitez les données tardives :

    Les données qui arrivent en retard ne sont pas incluses dans la requête initiale. Le système ne les traite que lorsqu'il interroge à nouveau le bloc d'heure de l'événement cinq à huit heures plus tard, ce qui entraîne des retards importants. Les données sur la ponctualité sont généralement différées d'environ 20 minutes.

Facteurs contribuant aux retards de détection des règles

Le type de règle, la fréquence d'exécution et la vitesse d'ingestion de Google SecOps sont des facteurs clés dans les délais de détection des règles.

Les facteurs suivants contribuent aux retards de détection des règles.

Types de règle

Les règles se répartissent en deux catégories principales :

Règles à événement unique

Les règles standards à événement unique détectent les événements individuels sans recherche de données externes, fenêtres de correspondance ni analyse du comportement des utilisateurs et des entités (UEBA). Ces règles s'exécutent en temps quasi réel à l'aide d'un moteur de flux dédié et permettent d'obtenir la latence de détection la plus faible (généralement inférieure à cinq minutes).

Règles complexes à événement unique

Les règles complexes à événement unique évaluent des événements individuels, mais intègrent des listes de référence, des tables de données ou des fenêtres de correspondance simples. Elles s'exécutent à l'aide du moteur de requête plutôt que du moteur de flux, mais sont planifiées selon un calendrier quasi en temps réel avec une faible latence proche de celle du moteur de flux :

  • Règles d'événement unique pour les listes de référence et les tableaux de données :

    Ces règles mono-événement effectuent des recherches dans des listes de référence ou des tables de données sans nécessiter de fenêtre de correspondance multi-événement.

  • Règles à événement unique avec fenêtre :

    Ces règles à événement unique incluent une période de correspondance avec une condition de nombre d'événements simple (telle que $e, #e > 0 ou #e >= 1).

Règles à événements multiples

Les règles à événements multiples s'exécutent de manière planifiée, ce qui entraîne des délais plus longs en raison du temps écoulé entre les exécutions planifiées.

  • Règles pour les événements multiples

    Ces règles examinent deux conditions d'événement UDM ou plus. Elles disposent généralement d'une fenêtre de correspondance et de plusieurs conditions.

  • Règles contextuelles

    Les règles contextuelles vous aident à associer des données contextuelles d'entité et de détection supplémentaires à vos événements.

    • Ces règles se composent d'au moins deux sources de données, dont au moins une condition est un événement d'entité UDM (où l'événement UDM est de type contexte, tel que user_context).
    • Les règles contextuelles sont les plus sensibles aux données tardives.
    • Les règles contextuelles sont généralement celles qui entraînent les délais les plus longs, car le système doit d'abord générer les données contextuelles nécessaires, comme les données du graphique de contexte des entités .
    • Pour en savoir plus, consultez Utiliser des données enrichies par le contexte dans les règles.

En savoir plus sur la différence entre les règles Événement unique et Événements multiples

Fréquence d'exécution des règles

La fréquence d'exécution des règles a un impact direct sur le délai de détection.

  • Temps quasi réel : les règles s'exécutent avec une latence minimale lorsque les événements sont ingérés. Cela s'applique aux éléments suivants :
    • Toutes les règles à événement unique (règles à événement unique standards, règles avec des listes de référence ou des tableaux de données, et règles à événement unique avec fenêtre).
    • Règles multi-événements avec des périodes de correspondance inférieures à 60 minutes.
  • Autres fréquences : pour les autres configurations de règles, vous pouvez définir les fréquences suivantes :
    • La fréquence de 10 minutes est valable pour les périodes de couverture inférieures à 60 minutes.
    • Les fréquences d'une heure et quotidiennes sont valables pour les périodes de correspondance allant jusqu'à 48 heures.
    • La fréquence quotidienne est valable pour toutes les périodes de correspondance supérieures à 48 heures.

Solution possible : Pour obtenir des détections plus rapides, utilisez une fréquence d'exécution plus courte. 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.

Période de correspondance

Si une règle comporte une période de correspondance, la durée de cette période détermine le délai de détection minimal, car le système doit attendre que la période entière se soit écoulée.

Délai d'ingestion

Le délai d'ingestion correspond au temps nécessaire à Google SecOps pour ingérer les données après l'événement.

Si les données arrivent tardivement, elles ne sont pas incluses dans la fenêtre de requête initiale. Une requête de traitement historique ultérieure le récupère, mais cela peut entraîner des retards de 5 à 8 heures.

Par exemple, l'événement A (heure de l'événement : 9h03) et l'événement B (heure de l'événement : 9h05) font partie d'une règle qui recherche deux événements dans un délai de 30 minutes. Si l'événement A arrive à 10h05 (avec une heure de retard), il ne correspond pas aux requêtes initiales du bloc de 9h00 à 9h30. Une requête de suivi pour ce bloc entre 14h et 17h génère ensuite la détection, ce qui entraîne des délais de 5 à 8 heures.

Dépannage : vérifiez que vous envoyez les données à Google SecOps dès que l'événement se produit. Lorsque vous examinez une détection, vérifiez attentivement l'événement UDM et les codes temporels d'ingestion.

Problèmes de fuseau horaire

Le fuseau horaire par défaut de Google SecOps SIEM est UTC. Si les journaux n'incluent pas de définition explicite du fuseau horaire, le système les interprète comme étant au format UTC. Une interprétation incorrecte peut entraîner le traitement des journaux comme s'ils étaient reçus en retard, ce qui entraîne des délais de détection, même si le système les reçoit en temps réel.

Par exemple, un journal dont l'heure de l'événement est 10h00, heure de l'Est (15h00 UTC) arrive à 15h05 UTC, mais il ne comporte pas de fuseau horaire. Si le journal ne comporte pas de fuseau horaire, le système interprète l'heure de l'événement comme 10h00 UTC. Le système calcule ensuite un délai de cinq heures entre l'heure de l'événement interprétée (10h00 UTC) et l'heure d'ingestion réelle (15h05 UTC). Ce délai calculé déclenche des retards de détection, car les règles donnent la priorité au traitement en fonction de l'ingestion en temps réel.

Solutions de contournement : si le code temporel de l'événement des données d'origine se trouve dans un fuseau horaire autre qu'UTC, essayez l'une des solutions suivantes :

  • Mettez à jour le fuseau horaire de l'événement des données d'origine.
  • Si vous ne parvenez pas à modifier le fuseau horaire au niveau de la source du journal, contactez l'assistance pour le remplacer.
  • Vous pouvez également utiliser un processeur BindPlane pour corriger le code temporel et le mettre au format UTC, ou ajouter l'indicateur de fuseau horaire approprié. Pour en savoir plus, consultez Modifier les codes temporels du corps du journal à l'aide de BindPlane.

Jointures contextuelles

Les règles multi-événements qui utilisent des données contextuelles, telles que les champs UEBA ou de graphique de contexte d'entité, peuvent entraîner des délais plus longs. Google SecOps doit d'abord générer les données contextuelles.

Système d'enrichissement

Google SecOps enrichit les événements UDM en ajoutant des données contextuelles provenant d'autres sources. Ce processus prend généralement 30 minutes. Les retards dans l'ajout de ces données enrichies aux événements UDM peuvent augmenter les délais de détection.

Pour vérifier si une règle évalue un champ enrichi, consultez le visualiseur d'événements. Si la règle évalue un champ enrichi, la détection peut être retardée.

Pour en savoir plus, consultez Enrichissement des données.

Alias et enrichissement

L'alias et l'enrichissement sont deux étapes du processus d'enrichissement des données de sécurité Google SecOps qui corrèlent et ajoutent des données contextuelles aux enregistrements d'événements. L'alias trouve les connexions et l'enrichissement remplit les champs UDM avec ces données connectées. Les champs renseignés par ce processus sont appelés champs alias ou champs enrichis.

  • Alias : processus d'identification et d'association de différents noms ou identifiants pour une même entité. Il recherche des données contextuelles supplémentaires qui décrivent un indicateur. Par exemple, l'alias peut associer un seul hostname (comme alex-macbook) à d'autres indicateurs associés, tels que son IP addresses et son MAC addresses (à partir des journaux DHCP). L'alias peut également associer un user ID (comme alex) au job title et au employment status de l'utilisateur (à partir des données contextuelles utilisateur).
  • Enrichissement : processus qui utilise les informations recueillies à partir de l'alias pour ajouter du contexte à un événement UDM. Par exemple, lorsqu'un nouvel événement arrive avec uniquement un IP address, le processus d'enrichissement utilise les données avec alias pour trouver le hostname associé (par exemple, alex-macbook) et renseigne le champ $udm.event.principal.hostname.

Google SecOps est compatible avec les alias et l'enrichissement pour plusieurs types d'entités, y compris les composants (par exemple, les noms d'hôte, les adresses IP, les adresses MAC), les utilisateurs, les processus, les métadonnées de hachage de fichier, les zones géographiques et les ressources cloud. Pour en savoir plus, consultez Présentation de l'enrichissement et de l'aliasage de l'UDM.

Réenrichissement des événements UDM

  • Modification des données sous-jacentes : si les données sous-jacentes changent après l'ingestion d'un événement, le système retraite les données historiques et met à jour les événements jusqu'à 24 heures après l'ingestion.

  • Mises à jour du système d'enrichissement : si le système d'enrichissement met à jour les métadonnées d'entité ou de processus, la géolocalisation de l'adresse IP ou les indicateurs VirusTotal, le moteur de règles réévalue ces blocs 24 à 48 heures plus tard pour tenir compte de ces mises à jour.
     Par exemple, un événement à 9h03 a entity.asset.hostname = hostnameA, mais pas d'adresse IP. Un journal DHCP de 8h55 indique hostnameA = IP 1.2.3.4. Le moteur de règles s'exécute à 9h10 et la règle ne correspond pas. Le pipeline de traitement de l'enrichissement met en corrélation hostnameA et 1.2.3.4 pour cette période, ce qui met à jour l'événement UDM. La règle correspond désormais et le système crée une détection.

  • Données de contexte différées : si vous envoyez des données de contexte, comme un hostname, un jour après le journal initial, le système réenrichit l'événement UDM. Les règles qui recherchent ces données réenrichies s'exécutent à nouveau et créent une détection.

  • Modifications des données d'enrichissement : les modifications apportées aux données d'enrichissement peuvent entraîner une correspondance ultérieure d'une règle, même si ce n'était pas le cas au départ.
     Par exemple, un événement à 9h03 a entity.ip_geo_artifact.country_or_region = USA. Le moteur de règles s'exécute à 9h10, interroge les données de 9h à 10h et la règle ne correspond pas. Plus tard, le retraitement de l'enrichissement met à jour la géolocalisation et la définit sur le Canada. Lorsque la règle s'exécute à nouveau, elle correspond désormais et le système crée une détection.

Traitement du graphique de contexte d'entité

Le système génère et ajoute des informations sur le graphe de contexte d'entité (ECG) aux données de journal pour fournir du contexte, par exemple des indicateurs de compromission (IOC) ou des données contextuelles d'assets. Étant donné que le pipeline ECG repose principalement sur le traitement par lot, les informations sur le contexte des entités ne sont souvent mises à jour qu'après qu'une exécution de règle a créé une détection.

Chasses rétro

Lorsque vous exécutez une règle par rapport aux données historiques à l'aide d'une recherche rétroactive, le système ne crée la détection qu'une fois le processus de recherche rétroactive terminé. Ce processus peut prendre un certain temps, ce qui entraîne un retard dans la détection.

Exemple de processus de mise à jour rétroactive :

  1. Événement initial : un événement arrive à 13h avec ip_address = 10.0.0.5. Pour le moment, la hostname est inconnue.
  2. Arrivée de l'alias de la source : à 14h30 (plus d'une heure plus tard), un journal DHCP arrive pour 13h00, associant 10.0.0.5 à workstation-123.
  3. Enrichissement rétroactif : le système d'alias traite ce nouveau lien. Il met à jour rétroactivement l'événement UDM de 13h, en enrichissant le champ $udm.event.principal.hostname, qui était vide, avec la valeur workstation-123.
  4. Détection : les relectures de règles ultérieures voient la valeur enrichie (workstation-123) et peuvent déclencher des détections qui avaient été manquées auparavant.

Listes de référence

Les exécutions de règles utilisent toujours la dernière version d'une liste de référence. Lorsque les règles programmées s'exécutent à nouveau, le système peut créer de nouvelles détections en fonction du contenu mis à jour des listes de référence. Ces détections peuvent apparaître tardivement, car elles sont basées sur des données ingérées avant la mise à jour de la liste de référence.

Pour réduire les délais de détection :

  • Envoyez les données de journaux à Google SecOps dès que l'événement se produit.
  • Examinez les règles d'audit pour déterminer si vous devez utiliser des données enrichies par le contexte ou d'inexistence.
  • Configurez une fréquence d'exécution plus faible.

Règles de non-existence

Le système attend au moins une heure avant d'exécuter les règles qui vérifient l'inexistence (par exemple, les règles qui contiennent !$e ou #e=0), ce qui permet aux données d'arriver à temps.

Retards de traitement des données

Le système peut continuer à traiter les données même après avoir créé une détection initiale, ce qui peut entraîner de nouvelles détections ou des détections mises à jour. Pour en savoir plus, consultez Quand les relectures de règles sont-elles déclenchées ?.

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