Cette page a été traduite par l'API Cloud Translation.

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

Compatible avec :

Google SecOps SIEM

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étections de règles ont toujours un certain délai, qui peut aller du temps quasi réel à quelques minutes ou plusieurs 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 la détection ont une incidence sur ces délais. Ce document explore ces facteurs de latence et d'autres.

Nous classons les retards comme attendus ou imprévus.

Retards prévus : ces retards sont dus au processus d'ingestion et aux choix de configuration que vous effectuez lorsque vous configurez la règle de détection.
Par exemple, la création d'une détection prend du temps. 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 retards de détection des règles, recherchez des informations sur la règle et les facteurs qui l'entourent :

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.
Dans le tableau de bord des règles, utilisez la recherche pour identifier les règles qui entraînent de longs délais de détection.
Pour toute exécution de règle spécifique, 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 pu être retardée.
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 des 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 :

Streaming Engine

Le moteur de flux est un pipeline rapide qui fonctionne généralement avec un délai de moins de cinq minutes. Il traite les règles à événement unique sans section "Aucune correspondance" et sans ensembles de données externes tels que les listes de référence ou les tableaux de données.
Moteur de requêtes

Le moteur de requêtes traite les règles comme suit :
- Règles à événement unique complexes :
  - Les règles à événement unique qui font référence à des listes de référence ou à des tables de données.
  - Règles d'événement unique avec fenêtre qui utilisent une fenêtre de correspondance avec une condition simple. Par exemple, "un événement où notre nombre d'événements est supérieur à 0". Ces règles s'exécutent à une fréquence de requête élevée (en temps réel) à mesure que de nouvelles données sont ingérées et mises à disposition pour le traitement des règles.
- Règles multi-événements : ces règles interrogent les données sur des blocs de heure de l'événement (10 minutes, heure, jour), selon une programmation que vous définissez.
  Par exemple, pour une programmation de 10 minutes, la règle interroge à nouveau les blocs d'heure de l'événement après 5 à 8 heures et 24 à 48 heures, en fonction des délais de traitement en amont.
Règles exécutées par rapport aux données historiques

Pour en savoir plus, consultez Chasses rétroactives.
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 effectue plusieurs enrichissements, le dernier ayant lieu trois jours après l'heure de l'événement.
Les règles multi-événements associent souvent des données contextuelles qui arrivent plusieurs heures après l'heure de l'événement principal. Une latence élevée dans ces données contextuelles peut entraîner une interaction entre le traitement du réenrichissement et les relectures de règles, ce qui retarde la détection. Bien que Google SecOps utilise cette fonctionnalité pour gérer les données arrivant très tard, elle apparaît comme une longue période entre la fenêtre de détection (bloc de temps de l'événement) et l'heure de création de l'alerte.
Les règles contextuelles sont des règles qui s'appuient sur des sources d'enrichissement telles que l'alias d'identité et d'assets, ou le graphique de contexte d'entité. Étant donné que ces règles reposent sur plusieurs sources d'événements, elles sont plus sujettes à la latence.
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 ont lieu en fonction des temps d'exécution du pipeline de retraitement.

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 :

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 Event time à 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.
Vérifiez 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 de contexte, 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.
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 comporte une période de correspondance, le délai minimal correspond à la durée de cette période.
- Relation entre la fréquence et la fenêtre de correspondance : assurez-vous que la fréquence d'exécution est compatible avec la fenêtre de correspondance. Par exemple, si la fenêtre de correspondance est de cinq minutes, une fréquence d'exécution de 10 minutes est acceptable. Toutefois, si la fenêtre de correspondance est supérieure à 10 minutes, utilisez la fréquence d'exécution disponible suivante, à savoir 1 heure.
Vérifiez si des incidents récents ont eu lieu :

Recherchez les incidents récents qui ont 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 :
- Augmentez la fréquence 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 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 10 minutes.
  - Pour les règles avec des fenêtres de correspondance de 60 minutes ou plus : utilisez 1 heure ou 24 heures, 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 :
  
  Les fenêtres de correspondance plus petites sont plus efficaces. Remplacez une fenêtre de match de 60 minutes par une fenêtre de 59 minutes pour activer le traitement de 10 minutes.
É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

Règles d'événement unique :

Étant donné que les règles à événement unique sont exécutées quasiment en temps réel à l'aide d'une approche de streaming, utilisez-les pour minimiser les délais, dans la mesure du possible.
- Règles simples à un seul événement
  
  Ces règles détectent des événements uniques et n'utilisent pas de listes de référence, de tableaux de données, de fenêtres de correspondance ni d'analyse du comportement des utilisateurs et des entités (UEBA). Ces règles s'exécutent en temps quasi réel, de manière continue, et présentent les délais de détection les plus courts.
  
  Remarque : Vous pouvez appliquer la suppression des alertes aux règles à événement unique à l'aide de l'option suppression_window.
- Règles complexes à un seul événement
  - Règles d'événement unique de fenêtre
    
    Il s'agit de règles à événement unique qui incluent une période de correspondance et qui ont généralement un délai légèrement plus long que les autres règles à événement unique. Une fenêtre de correspondance est généralement une période pendant laquelle une règle examine un ou plusieurs événements.
  - Consulter les règles d'événement unique
    
    Il s'agit de règles à événement unique qui incluent des listes de référence ou des tableaux de données.
Règles pour plusieurs événements :

Les règles multi-événements 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 plusieurs événements
  
  Ces règles examinent deux conditions d'événement UDM ou plus. Elles comportent généralement une fenêtre de correspondance et plusieurs conditions.
- Règles contextuelles
  
  Les règles contextuelles vous aident à comprendre à la fois les schémas de comportement dans la télémétrie et le contexte des entités concernées par ces schémas.
  - Ces règles se composent d'au moins deux conditions, dont au moins une est un événement d'entité UDM (où l'événement UDM est de type context, tel que user_context).
  - Ces types de règles ont des délais plus longs. Il n'est pas rare que les détections prennent quelques jours.
  - 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 de contexte nécessaires.

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.

Quasi en temps réel : les règles s'exécutent plus fréquemment pour les données en temps réel et sont constamment en cours d'exécution. Cela ne s'applique qu'aux règles à événement unique.
Autres fréquences : pour les autres types de règles, vous pouvez définir les fréquences suivantes :
- La fréquence de 10 minutes est valable pour les fenêtres de correspondance de moins de 60 minutes.
- Les fréquences d'une heure et de 24 heures sont valides pour les périodes de correspondance de moins de 48 heures.
- La fréquence de 24 heures est valable pour toutes les périodes de correspondance supérieures ou égales à 48 heures.

Solution possible : Pour obtenir des détections plus rapides, utilisez une fréquence d'exécution plus courte et une fenêtre de correspondance plus petite. L'utilisation de périodes de correspondance plus courtes (moins d'une heure) permet d'effectuer des exécutions plus fréquentes.

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 en retard, 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 délais 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 manque les 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 arrivés 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 10h EST (15h 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 délais 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 de journaux, 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 UEBA ou Entity Graph, 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 Gestionnaire 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 de contexte supplémentaires qui décrivent un indicateur. Par exemple, l'aliasing peut associer un seul hostname (comme alex-macbook) à d'autres indicateurs associés, tels que son IP addresses, son MAC addresses (à partir des journaux DHCP) ou un user ID (comme alex) à son job title et son employment status (à partir des données de contexte 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 aliasées 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 éléments (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 UDM.

Réenrichissement des événements UDM

Modifications des données sous-jacentes : si les données sous-jacentes changent après l'ingestion d'un événement par le système, celui-ci traite à nouveau les données historiques et met à jour les événements pendant une durée maximale de 24 heures.
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 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, mais 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, trois jours 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. Cette fonctionnalité permet au système de créer des détections même lorsque le contexte est retardé.
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 remplace par "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 graphique de contexte d'entité (ECG) aux données de journaux pour fournir du contexte, par exemple des indicateurs de compromission (IOC) ou des données de contexte d'actifs. É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 l'exécution d'une règle qui crée une détection.

Chasses au trésor rétro

Lorsque vous exécutez une règle par rapport aux données de l'historique à 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 délai de détection.

Exemple de procédure de mise à jour rétroactive :

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

Remarque : Vous ne pouvez pas distinguer les métriques de surveillance de la latence pour les règles de détection en direct de celles pour les règles de détection rétroactive. Pour éviter de fausser vos métriques de surveillance de la latence de détection, n'utilisez pas de règle en direct pour simuler une règle Retrohunt. Nous vous recommandons de créer une règle de détection dédiée et de l'exécuter en tant que règle de rétrochasse.

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

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 effectué une première détection, 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 de membres de la communauté et de professionnels Google SecOps.