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

Compatible avec :

Ce document explique les délais 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 permettant de 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 standards et d'entité) pour générer des détections de sécurité en fonction des spécifications des règles. Les événements UDM d'entité contiennent généralement des informations contextuelles telles que les métadonnées de l'utilisateur ou de l'actif. Les règles de détection peuvent également évaluer les détections générées précédemment pour produire des alertes composites.

Délais prévus et imprévus

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

  • Délais prévus : délais 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 la détection, la durée de la période de correspondance et les limites connues du système. Vous pouvez réduire les délais prévus en ajustant les configurations des règles de détection et les paramètres de planification.
  • Délais imprévus : délais causés par des conditions de pipeline externes ou dynamiques, y compris les goulots d'étranglement de la diffusion des journaux à partir de sources de données, la latence de traitement temporaire dans les services Google SecOps, la disponibilité différée du contexte et les cycles de ré-enrichissement UDM.

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

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

  • Moteur de streaming : pipeline à haute 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 tardifs et les enrichissements rétroactifs sont évalués en continu lors de l'exécution standard.
  • Moteur de requêtes : évalue les règles qui nécessitent une corrélation d'événements basée sur le temps sur plusieurs événements ou des jointures de données externes :
    • Règles complexes à événement unique : incluent 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 : interrogent les données dans des blocs d'événements par lots (par exemple, des intervalles de 10 minutes ou d'une heure, ou match_window / 10 pour les fenêtres de plus de 48 heures) en fonction des programmations configurées.
  • Règles exécutées par rapport aux données historiques : évalue les règles de manière rétroactive par rapport aux journaux historiques via des recherches rétroactives. Les détections s'affichent une fois l'analyse historique terminée.
  • Ré-enrichissement des événements UDM : réévalue les blocs de temps traités précédemment lorsque de nouvelles données de contexte ou d'entité mises à jour sont ajoutées aux événements historiques.

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

La vitesse à laquelle les détections s'affichent 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 sont réparties 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 des événements individuels sans joindre d'ensembles de données externes, de tables de données ni de périodes de correspondance à événements multiples.

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 fenêtrées à événement unique : règles à événement unique qui incluent une section match (par exemple, pour é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 lors de l'ingestion des données.
  • Règles de référence à événement unique : 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 mettent en corrélation deux conditions d'événement UDM ou plus sur une période de correspondance spécifiée et s'exécutent à des intervalles de traitement par lots planifiés.

  • Règles standards à événements multiples : 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 fenêtres de plus de 48 heures).
  • Règles contextuelles : mettent en corrélation les données d'événement avec les événements d'entité UDM (tels que user_context ou asset_context) à l'aide d'analyses contextuelles. Étant donné que les règles contextuelles reposent sur plusieurs flux de données, elles sont plus sensibles au timing d'ingestion. Pour en savoir plus, consultez Utiliser des données enrichies par le contexte dans les règles.

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

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

  • Temps quasi réel : évaluation continue pour les 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 périodes de correspondance de moins de 60 minutes.
  • Fréquence d'une heure : intervalle par défaut pour les règles à événements multiples avec des périodes de correspondance de 48 heures ou moins.
  • Fréquence match_window / 10 : attribuée automatiquement aux règles à événements multiples avec des périodes de correspondance de plus de 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 à la source et le moment où Google SecOps reçoit et analyse le journal.

Si un événement arrive après l'évaluation planifiée initiale pour ce bloc de temps, il manque la première exécution. Le système capture les données tardives lors des exécutions en arrière-plan automatisées suivantes (exécutions de mise à jour), 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 mise à jour ultérieure environ quatre heures après l'exécution principale (vers 14h00), générant la détection environ cinq heures après l'événement.

Écarts de fuseau horaire

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

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

Solutions de contournement : Pour résoudre les écarts de fuseau horaire :

  • Configurez la source du journal pour inclure des décalages de fuseau horaire UTC explicites dans les horodatages 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 horodatages du corps du journal au format UTC avant l'ingestion. Pour en savoir plus, consultez Modifier les horodatages du corps du journal à 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'actif 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'alias et d'enrichissement

Les alias et l'enrichissement mettent en corrélation les indicateurs bruts avec le contexte organisationnel :

  • Alias : identifie et associe différents identifiants pour la 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 : remplit les champs d'événement UDM normalisés avec le contexte aliasé (par exemple, en remplissant $udm.event.principal.hostname lorsqu'une seule adresse IP est présente dans l'événement brut).

Les types d'enrichissement compatibles incluent les actifs, les utilisateurs, les processus, les métadonnées de hachage de fichiers, les zones géographiques et les ressources cloud. Pour en savoir plus, consultez Présentation de l'enrichissement et des alias UDM.

Ré-enrichissement des événements UDM

Le système met à jour en continu 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 mise à jour ou du retraitement planifiés) pour générer des détections avec un contexte mis à jour.
  • Données contextuelles différées : si les données contextuelles (telles qu'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 mise à jour suivantes évaluent l'enregistrement enrichi.
  • Modifications du contexte : si une mise à jour de l'enrichissement modifie un attribut d'événement (par exemple, en mettant à jour une géolocalisation IP de USA vers Canada), les règles qui correspondent à la valeur mise à jour déclenchent des détections lors des réévaluations suivantes.

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 actifs de l'entreprise. Étant donné que le pipeline ECG repose sur le traitement par lots (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 les relations du graphique entièrement calculées.

Exécutions de règles historiques et recherches rétroactives

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

  • Workflow d'enrichissement rétroactif:
    1. Un événement arrive à 13h00 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'alias 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 affichent 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 entraîner la production rétroactive de détections par les règles planifiées par rapport aux journaux ingérés précédemment.

Règles de non-existence

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

Limites de traitement des données et de mise à jour

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 mise à jour : les règles à événements multiples sont automatiquement réexécutées environ quatre heures (et éventuellement 30 heures) après l'exécution principale pour capturer les données tardives. Pour en savoir plus, consultez Comprendre les relectures de règles et le délai moyen de détection.
  • 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 liés aux 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 programmation des règles : dans le tableau de bord des règles, consultez les colonnes Nom de la règle, Type de règle et Programmation 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.
  • Comparer 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 à 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, d'exécutions de mise à jour automatisées, de pipelines de retraitement ou de 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'alias 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 mise à jour suivantes.
  • Vérifier la compatibilité de la fréquence et de la période de correspondance : assurez-vous que la fréquence d'exécution configurée correspond à la taille de la période de correspondance (par exemple, en vous assurant qu'une règle avec une période de correspondance de 15 minutes est programmée pour 10 minutes ou une heure).
  • Rechercher les interruptions de flux de données : examinez les journaux d'ingestion et les tableaux de bord de gestion des flux pour détecter les retards d'ingestion ou les pannes de source temporaires.

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

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

  • Optimiser la fréquence d'exécution des règles:
    • Utilisez 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 périodes de correspondance de moins de 60 minutes.
    • Utilisez 1 heure pour les règles avec des périodes de correspondance comprises entre 1 et 48 heures lorsque des alertes rapides sont nécessaires.
  • Ajuster les durées des périodes de correspondance : définissez les périodes de correspondance sur la durée minimale nécessaire pour capturer le comportement de menace corrélé.
  • Éliminer les goulots d'étranglement de la diffusion des journaux : assurez-vous que les transmetteurs 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.
  • Valider les configurations de fuseau horaire : assurez-vous que les sources de journaux fournissent des décalages UTC explicites pour éviter les délais d'ingestion perçus de plus de cinq heures.
  • Auditer les conditions de contexte et 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.

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