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. Il identifie les facteurs contribuant aux pipelines d'ingestion et de traitement, décrit des approches structurées de dépannage 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 réguliers 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, comme des métadonnées utilisateur ou d'assets. 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 des données et des cycles de traitement du système. Les retards sont classés en deux catégories :

  • 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 des détections, 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 la diffusion des journaux à partir des sources de données, la latence de traitement transitoire 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 des détections

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

  • Moteur de flux : pipeline à haut débit qui évalue en continu les règles à événement unique standard et fenêtrées en temps quasi réel (généralement dans les cinq minutes suivant l'ingestion). Les événements arrivant tardivement et les enrichissements rétroactifs sont évalués en continu lors de 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 pour 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 multi-événements : interrogent les données par blocs d'heure d'événement (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 plannings configurés.
  • Les règles s'exécutent sur les données historiques : les règles sont évaluées de manière rétroactive par rapport aux journaux historiques grâce aux analyses rétroactives. Les détections s'affichent une fois l'analyse historique terminée.
  • Réenrichissement des événements UDM : réévalue les blocs temporels précédemment traités lorsque de nouveaux contextes ou des données d'entité mises à jour sont ajoutés 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 flux continu et offrent la latence de détection la plus faible. Ces règles évaluent des événements individuels sans joindre de 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 avec fenêtre : 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 flux 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 tableaux de données.

Règles à événements multiples

Les règles à événements multiples corrèlent 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 lot planifiés.

  • Règles standards multi-événements : 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 supérieures à 48 heures).
  • Règles contextuelles : mettez 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 de l'analyse contextuelle. Étant donné que les règles contextuelles s'appuient sur plusieurs flux de données, elles sont plus sensibles au calendrier 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ête évalue les blocs de période d'événement :

  • Quasi temps réel : évaluation continue pour les règles à événement unique (standard et avec fenêtre).
  • 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 dont la période de correspondance est de 48 heures ou moins.
  • match_window / 10 fréquence : attribuée automatiquement aux règles multi-événements dont la période de correspondance est supérieure à 48 heures (par exemple, 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 apparaître 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 initiale planifiée pour ce bloc temporel, il ne sera pas pris en compte lors de la première exécution. Le système capture les données tardives lors des exécutions en arrière-plan automatisées ultérieures (exécutions de correction), qui ont lieu 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 9h à 9h30. Le système réévalue le blocage lors d'une exécution de mise à jour 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.

Incohérences de fuseau horaire

Par défaut, Google SecOps interprète les codes temporels des journaux comme étant 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 faire apparaître le journal comme tardif, même s'il a été 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 rééquilibrage en arrière-plan.

Solutions : pour résoudre les problèmes de fuseau horaire :

  • Configurez la source du journal 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 du fuseau horaire pour le flux d'ingestion spécifique.
  • Utilisez un processeur BindPlane pour normaliser les codes temporels du corps du journal au format UTC avant l'ingestion. Pour en savoir plus, consultez Modifier les codes temporels 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'éléments et de menaces 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

L'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 les 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, remplit $udm.event.principal.hostname lorsqu'une adresse IP est présente dans l'événement brut).

Les types d'enrichissement acceptés incluent les composants, 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

Le système met à jour en permanence 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éconciliation ou du retraitement planifiés) pour générer des détections avec un contexte actualisé.
  • Données contextuelles différées : si des 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 ajustements ultérieurs é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 à Canada), les règles qui correspondent à la valeur mise à jour déclenchent des détections lors des réévaluations ultérieures.

Traitement des graphiques contextuels d'entités (ECG)

Le graphique de contexte des entités (ECG) met en corrélation les indicateurs de compromission (IOC) et les données du graphique des ressources de l'entreprise. Étant donné que le pipeline ECG repose sur le 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 graphiques sont entièrement calculées.

Exécutions de règles et Retrohunts 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étrochasse terminée pour 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'alias met à jour l'événement historique de 13h avec principal.hostname = workstation-123.
    4. Les relectures de règles ultérieures évaluent le nom d'hôte enrichi et font apparaître les détections qui n'ont pas été déclenchées lors de la première exécution.

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 détection rétroactive de journaux précédemment ingérés par les règles planifiées.

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 (telles que !$e ou #e=0), ce qui permet à tous les journaux associés d'arriver à temps.

Limites de traitement et de régularisation des données

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éconciliation : les règles multi-événements sont réexécutées automatiquement 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 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 retard de détection des règles

Pour comprendre pourquoi une règle a généré une détection différée, examinez les heuristiques et les étapes du pipeline suivantes dans la console Google SecOps :

  • Examiner les métadonnées et le calendrier d'une règle : dans le Tableau de bord des règles, consultez les colonnes Nom de la règle, Type de règle et Calendrier de la règle pour identifier le moteur d'exécution et la fréquence d'évaluation de référence de la règle.
  • Comparer la date et l'heure de l'événement à la date et l'heure d'ingestion : recherchez la détection dans l'onglet Détections et comparez le code temporel de l'événement à celui de l'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 transmission des journaux à la source ou lors de la collecte. Les détections générées à partir de données d'événements arrivant avec plus de 30 minutes de retard, d'exécutions de correction automatique, de pipelines de retraitement ou de recherches rétroactives affichent une icône  dans la colonne Type de détection.
  • Examiner les dépendances des sources 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 contextuels traitent les données de manière asynchrone et peuvent générer des détections lors des exécutions de réconciliation ultérieures.
  • Vérifiez la fréquence et la compatibilité 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, vérifiez qu'une règle avec une période de correspondance de 15 minutes est planifiée pour 10 minutes ou 1 heure).
  • Vérifiez si le flux de données a été interrompu : consultez les journaux d'ingestion et les tableaux de bord de gestion des flux pour détecter d'éventuels retards d'ingestion ou des indisponibilités temporaires des sources.

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 :

  • Optimiser la fréquence d'exécution des règles :
    • Utilisez Temps quasi réel pour les règles à événement unique (standards et avec fenêtre).
    • 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 avec des périodes de correspondance comprises entre 1 et 48 heures, pour lesquelles des alertes rapides sont nécessaires.
  • Ajustez la durée des fenêtres de correspondance : définissez la durée des fenêtres de correspondance sur la durée minimale nécessaire pour capturer le comportement de menace corrélé.
  • Éliminez les goulots d'étranglement dans 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.
  • Validez les configurations de fuseau horaire : assurez-vous que les sources de journaux fournissent des décalages UTC explicites pour éviter les retards d'ingestion perçus de plus de cinq heures.
  • Conditions de contexte et de non-existence pour l'audit : 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 en savoir plus sur 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.