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 dans les pipelines d'ingestion et de traitement, décrit les approches de dépannage structurées et fournit des techniques pour réduire la latence de détection.

Présentation des règles de détection

Les règles de détection examinent les journaux bruts normalisés (événements UDM (Universal Data Model) standards et d'entité) pour générer des détections de sécurité conformément aux spécifications des règles. Les événements UDM d'entité contiennent généralement des informations contextuelles telles que des métadonnées d'utilisateur ou d'élément. Les règles de détection peuvent également évaluer les détections générées précédemment pour produire des alertes composites.

Retards prévus et imprévus

La latence de détection varie en fonction de la logique des règles, des dépendances aux données et des cycles de traitement du système. Les retards sont classés en deux types :

  • Retards attendus : retards résultant de facteurs structurels, tels que le processus d'ingestion, le type de règle, la fréquence d'exécution, la méthode de génération de détection, la durée de la fenêtre de correspondance et les limites connues du système. Vous pouvez minimiser les retards attendus en ajustant les configurations des règles de détection et les paramètres de planification.
  • Retards imprévus : retards causés par des conditions de pipeline externes ou dynamiques, y compris les goulots d'étranglement de diffusion des journaux à partir des sources de données, la latence de traitement temporaire dans les services Google SecOps, la disponibilité retardée du contexte et les cycles de réenrichissement UDM.

Méthodes de génération de détections

Google SecOps génère des détections de règles via les pipelines d'exécution suivants :

  • Moteur de streaming : pipeline à grande vitesse qui évalue en continu les règles à événement unique standards et fenêtrées en temps quasi réel (généralement dans les cinq minutes suivant l'ingestion). Les événements arrivant en retard et les enrichissements rétroactifs sont évalués en continu pendant l'exécution standard.
  • Moteur de requête : évalue les règles qui nécessitent une corrélation d'événements basée sur le temps entre plusieurs événements ou des associations de données externes :
    • Règles complexes à événement unique : inclut les règles à événement unique qui interrogent des listes de référence ou des tables de données.
    • Règles à événements multiples : interroge les données par blocs d'événements (par exemple, des intervalles de 10 minutes ou d'une heure, ou match_window / 10 pour les périodes de plus de 48 heures) en fonction des planifications configurées.
  • Règles exécutées sur les données historiques : évalue les règles de manière rétroactive sur les journaux historiques via des recherches rétroactives. Les détections s'affichent une fois l'analyse de l'historique terminée.
  • Réenrichissement des événements UDM : réévalue les blocs de temps précédemment traités lorsque de nouvelles données de contexte ou d'entité mises à jour sont ajoutées aux événements historiques.

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

La vitesse à laquelle les détections apparaissent dépend de la complexité des règles, des intervalles de planification, de la latence d'ingestion des données et des pipelines d'enrichissement du contexte.

Types et complexité des règles

Les règles de détection se répartissent en plusieurs catégories avec des profils de latence différents :

Règles à événement unique

Les règles à événement unique s'exécutent en temps quasi réel sur le moteur de streaming continu et offrent la latence de détection la plus faible. Ces règles évaluent les événements individuels sans joindre d'ensembles de données externes, de tables de données ni de fenêtres de correspondance multi-événements.

Règles complexes à événement unique

Ces règles évaluent des événements uniques, mais intègrent des dépendances de données supplémentaires :

  • Règles à événement unique fenêtrées : règles à événement unique qui incluent une section match (par exemple, évaluer si un événement unique correspond à une condition sur une période donnée). Ces règles sont évaluées en temps quasi réel sur le moteur de streaming continu à mesure que les données sont ingérées.
  • Règles à événement unique de référence : règles à événement unique qui comparent les attributs d'événement à des listes de référence ou à des tables de données.

Règles à événements multiples

Les règles à événements multiples corrèlent au moins deux conditions d'événement UDM sur une période de correspondance spécifiée et s'exécutent à des intervalles de traitement par lot planifiés.

  • Règles multi-événements standards : agrègent plusieurs événements sur des périodes et s'exécutent à des intervalles de 10 minutes ou d'une heure (ou match_window / 10 pour les périodes de plus de 48 heures).
  • Règles contextuelles : corrélez les données d'événement avec les événements d'entité UDM (comme user_context ou asset_context) à l'aide de l'analyse contextuelle. Comme les règles contextuelles s'appuient sur plusieurs flux de données, elles sont plus sensibles au moment de l'ingestion. Pour en savoir plus, consultez Utiliser des données enrichies de contexte dans les règles.

Fréquence d'exécution de la règle

La fréquence d'exécution configurée détermine la fréquence à laquelle le moteur de requête évalue les blocs de temps d'événement :

  • En temps quasi réel : évaluation continue des règles à événement unique (standards et fenêtrées).
  • Fréquence de 10 minutes : disponible pour les règles à événements multiples avec des fenêtres de correspondance de moins de 60 minutes.
  • Fréquence d'une heure : intervalle par défaut pour les règles multi-événements avec des périodes de correspondance de 48 heures ou moins.
  • Fréquence match_window / 10 : attribuée automatiquement pour les règles multi-événements dont la période de correspondance est supérieure à 48 heures (par exemple, exécution toutes les 10 heures pour une période de correspondance de 100 heures ou toutes les 24 heures pour une période de 10 jours).

Durée de la période de correspondance

Pour les règles à événements multiples, la durée de la période de correspondance définit la période d'observation requise pour agréger les événements. Les détections ne peuvent pas s'afficher tant que la période complète n'est pas écoulée.

Délai d'ingestion des journaux

Le délai d'ingestion correspond au temps écoulé entre le moment où un événement se produit au niveau de la source et celui où Google SecOps reçoit et analyse le journal.

Si un événement arrive après l'évaluation initialement planifiée pour ce bloc de temps, il n'est pas pris en compte lors de la première exécution. Le système capture les données arrivant en retard lors des exécutions automatiques en arrière-plan ultérieures (exécutions de régularisation), qui se produisent environ quatre heures (et éventuellement 30 heures avec l'exhaustivité de l'enrichissement) après l'exécution principale.

  • Exemple : une règle met en corrélation l'événement A (heure de l'événement : 9h03) et l'événement B (heure de l'événement : 9h05) dans une fenêtre de 30 minutes. Si l'événement A arrive à 10h05 (avec une heure de retard), il manque l'exécution initiale pour le bloc de 9h00 à 9h30. Le système réévalue le bloc lors d'une exécution de régularisation ultérieure environ quatre heures après l'exécution principale (vers 14h), ce qui génère la détection environ cinq heures après l'événement.

Pour en savoir plus sur la latence d'indexation en amont dans les flux d'interrogation d'API tierces, consultez Événements arrivant en retard dans les flux d'interrogation.

Écarts de fuseau horaire

Par défaut, Google SecOps interprète les codes temporels des journaux au format UTC. Si une source de journaux omet un décalage de fuseau horaire explicite, le système traite le code temporel comme UTC, ce qui peut entraîner l'affichage du journal comme arrivant en retard, même s'il est reçu immédiatement.

  • Exemple : Un événement se produit à 10h00, heure de l'Est (15h00 UTC), et arrive dans Google SecOps à 15h05 UTC sans métadonnées de fuseau horaire. Le système interprète le code temporel comme étant 10:00 UTC, ce qui crée un délai d'ingestion perçu de cinq heures qui reporte l'évaluation de la règle à une exécution de régularisation en arrière-plan.

Solutions : pour résoudre les écarts de fuseau horaire :

  • Configurez la source de journaux pour inclure des décalages de fuseau horaire UTC explicites dans les codes temporels des événements.
  • Contactez l'assistance pour définir un remplacement de fuseau horaire pour le flux d'ingestion spécifique.
  • Utilisez un processeur BindPlane pour normaliser les codes temporels du corps des journaux au format UTC avant l'ingestion. Pour en savoir plus, consultez Modifier les codes temporels du corps des journaux à l'aide de BindPlane.

Jointures contextuelles et enrichissement des données

Google SecOps enrichit les événements UDM en ajoutant des métadonnées d'identité, d'élément et de menace provenant de sources secondaires. Les retards dans la disponibilité du contexte peuvent prolonger le délai de détection.

Mécanismes d'aliasing et d'enrichissement

L'aliasing et l'enrichissement mettent en corrélation les indicateurs bruts avec le contexte de l'organisation :

  • Aliasing : identifie et associe différents identifiants pour une même entité dans différentes sources de données (par exemple, en mappant une adresse IP des journaux DHCP à une adresse MAC et à un nom d'hôte comme alex-macbook, ou en mappant un ID utilisateur à un poste d'employé).
  • Enrichissement : renseigne les champs d'événement UDM normalisés avec le contexte d'alias (par exemple, en renseignant $udm.event.principal.hostname lorsqu'une seule adresse IP est présente dans l'événement brut).

Les types d'enrichissement acceptés incluent les éléments, les utilisateurs, les processus, les métadonnées de hachage de fichiers, les emplacements géographiques et les ressources cloud. Pour en savoir plus, consultez Présentation de l'enrichissement et de l'aliasing de l'UDM.

Réenrichissement des événements UDM

Le système met continuellement à jour les événements historiques à mesure que les sources de contexte évoluent :

  • Modifications des données sous-jacentes : les événements historiques peuvent être mis à jour jusqu'à 24 heures après l'ingestion, à mesure que de nouvelles données contextuelles arrivent.
  • Mises à jour du système d'enrichissement : lorsque les métadonnées d'entité, la géolocalisation IP ou les renseignements sur les menaces VirusTotal sont mis à jour, le moteur de règles réévalue les blocs historiques (généralement lors des exécutions de régularisation planifiées ou du retraitement) pour générer des détections avec un contexte mis à jour.
  • Données contextuelles différées : si les données contextuelles (comme un nom d'hôte) arrivent un jour après le journal des événements, le système réenrichit l'événement UDM, et les exécutions de régularisation ultérieures évaluent l'enregistrement enrichi.
  • Modifications de contexte : si une mise à jour d'enrichissement modifie un attribut d'événement (par exemple, en mettant à jour une géolocalisation IP de USA à Canada), les règles qui correspondent à la valeur mise à jour déclenchent des détections lors des réévaluations ultérieures.

Traitement du graphique de contexte d'entité (ECG)

Le graphique de contexte d'entité (ECG) met en corrélation les indicateurs de compromission (IoC) et les données du graphique des éléments d'entreprise. Étant donné que le pipeline ECG repose sur un traitement par lot (qui peut prendre 30 heures ou plusieurs jours selon le volume de données), les règles faisant référence aux champs graph.entity génèrent des détections une fois que les relations du graphique sont entièrement calculées.

Exécutions de règles et recherches RetroHunt historiques

L'exécution d'une règle sur des données historiques ne génère des détections qu'une fois l'analyse rétroactive terminée sur la période sélectionnée.

  • Workflow d'enrichissement rétroactif :
    1. Un événement arrive à 13h avec ip_address = 10.0.0.5 (nom d'hôte inconnu).
    2. À 14h30, un journal DHCP arrive, associant 10.0.0.5 à workstation-123.
    3. Le pipeline d'aliasing met à jour l'événement historique de 13h00 avec principal.hostname = workstation-123.
    4. Les relectures de règles suivantes évaluent le nom d'hôte enrichi et font apparaître les détections qui n'ont pas été déclenchées lors de l'exécution initiale.

Listes de référence

Les règles qui interrogent des listes de référence sont évaluées par rapport à la dernière version de la liste au moment de l'exécution. La mise à jour d'une liste de référence peut amener les règles planifiées à produire des détections de manière rétroactive sur les journaux précédemment ingérés.

Règles de non-existence

Pour éviter les faux positifs, le système introduit un délai tampon d'au moins une heure avant d'évaluer les règles qui vérifient les conditions de non-existence (comme !$e ou #e=0), ce qui permet de s'assurer que tous les journaux associés ont le temps d'arriver.

Limites relatives au traitement des données et à la régularisation

Tenez compte des comportements système suivants lorsque vous évaluez la latence de détection :

  • Traitement de l'enrichissement : l'enrichissement du contexte peut mettre à jour les événements UDM historiques jusqu'à 24 heures après l'ingestion initiale.
  • Cycles de régularisation : les règles multi-événements sont automatiquement réexécutées environ quatre heures (et éventuellement 30 heures) après l'exécution principale pour capturer les données arrivant tardivement. Pour en savoir plus, consultez Comprendre les relectures de règles et le MTTD.
  • Limites de détection : pour connaître les limites de capacité et de limitation de la plate-forme, consultez Comprendre les limites de détection.

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

Pour diagnostiquer la raison pour laquelle une règle a généré une détection différée, examinez les heuristiques et les étapes de pipeline suivantes dans la console Google SecOps :

  • Examiner les métadonnées et la planification de la règle : dans le tableau de bord des règles, vérifiez les colonnes Nom de la règle, Type de règle et Planification de la règle pour identifier le moteur d'exécution de la règle et la fréquence d'évaluation de référence.
  • Comparez l'heure de l'événement à l'heure d'ingestion : recherchez la détection dans l'onglet Détections et comparez l'horodatage de l'événement à l'horodatage d'ingestion. Si l'écart entre l'heure de l'événement et l'heure d'ingestion dépasse 30 minutes, la latence est due à des retards de diffusion des journaux au niveau de la source ou lors de la collecte. Les détections générées à partir de données d'événement arrivant avec plus de 30 minutes de retard, les exécutions de régularisation automatisées, les pipelines de retraitement ou les recherches rétroactives affichent une icône dans la colonne Type de détection.
  • Examiner les dépendances de la source de contexte : vérifiez si la règle fait référence à l'enrichissement principal, à l'aliasing UDM ou aux champs graph.entity. Les pipelines de contexte sont traités de manière asynchrone et peuvent afficher des détections lors des exécutions de régularisation ultérieures.
  • Vérifiez la compatibilité de la fréquence et de la fenêtre de correspondance : assurez-vous que la fréquence d'exécution configurée correspond à la taille de la fenêtre de correspondance (par exemple, qu'une règle avec une fenêtre de correspondance de 15 minutes est planifiée pour 10 minutes ou 1 heure).
  • Vérifiez s'il y a des interruptions du flux de données : examinez les journaux d'ingestion et les tableaux de bord de gestion des flux pour détecter d'éventuels retards d'ingestion ou des pannes temporaires de la source.

Conseils pour réduire les délais de détection

Pour minimiser les délais de détection dans votre environnement, appliquez les techniques d'optimisation suivantes :

  • Optimisez la fréquence d'exécution des règles :
    • Utilisez En temps quasi réel pour les règles à événement unique (standards et fenêtrées).
    • Configurez une programmation de 10 minutes pour les règles à événements multiples avec des fenêtres de correspondance de moins de 60 minutes.
    • Utilisez 1 heure pour les règles dont la fenêtre de correspondance est comprise entre 1 et 48 heures, et pour lesquelles une alerte rapide est nécessaire.
  • Ajuster la durée des fenêtres de correspondance : définissez les fenêtres de correspondance sur la durée minimale nécessaire pour capturer le comportement de menace corrélé.
  • Éliminez les goulots d'étranglement lors de la diffusion des journaux : assurez-vous que les redirecteurs et les collecteurs envoient immédiatement les données d'événement pour éviter que les journaux ne manquent la fenêtre d'exécution initiale.
  • Validez les configurations de fuseau horaire : assurez-vous que les sources de journaux fournissent des décalages UTC explicites pour éviter des retards d'ingestion perçus de plus de cinq heures.
  • Auditer le contexte et les conditions de non-existence : n'utilisez les champs enrichis par le contexte et les conditions de non-existence (!$e) que lorsque la logique de détection l'exige, car ils introduisent des périodes de mise en mémoire tampon intentionnelles.

Étapes suivantes

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 de membres de la communauté et de professionnels Google SecOps.