Comprendre les relectures de règles et le MTTD
Ce document explique comment les relectures de règles (également appelées exécutions de nettoyage) gèrent les données et les mises à jour de contexte tardives, et comment cela affecte les métriques de temps moyen de détection (MTTD, Mean Time To Detect).
Lectures en différé des règles
Google SecOps traite de grands volumes de données de sécurité. Pour garantir des détections précises pour les règles qui dépendent de données contextuelles ou corrélées, le moteur de règles exécute automatiquement un processus de relecture des règles. Ce processus évalue plusieurs fois le même bloc de données d'événement à différents intervalles pour gérer les données arrivant tardivement ou les règles nécessitant un contexte mis à jour, comme la mise en correspondance d'un indicateur de compromission (IOC).
Déclencheurs de relecture des règles
Les règles sont réévaluées (réexécutées) lorsque des données de contexte pertinentes arrivent ou sont traitées après les données d'événement initiales.
Voici quelques déclencheurs de relecture de règles courants :
Données d'enrichissement reçues en retard
Les pipelines d'enrichissement des données, tels que l'Entity Context Graph (ECG), peuvent traiter les données par lots. Si un événement UDM arrive avant ses données contextuelles associées (comme les informations sur les composants ou le contexte utilisateur), une détection peut être manquée lors de la première exécution de la règle.
Mises à jour rétroactives de l'enrichissement UDM
Si votre règle utilise des champs alias (champs enrichis) dans votre logique de détection, tels que
$udm.event.principal.hostname, et que les données sources (par exemple, les enregistrements DHCP) arrivent plus d'une heure plus tard, les valeurs de ces champs sont mises à jour rétroactivement pour cette heure d'événement spécifique. Les exécutions de règles ultérieures ("exécutions de nettoyage") utilisent ensuite ces valeurs nouvellement enrichies, ce qui peut déclencher une détection qui avait été manquée auparavant.Règles multi-événements programmées
Les règles multi-événements (ME) s'exécutent selon une programmation (par exemple, toutes les 10 minutes, toutes les heures ou tous les jours) pour évaluer des blocs de temps d'événement. Pour capturer les mises à jour tardives de l'enrichissement des données historiques, ces règles réévaluent le même bloc temporel plus tard, souvent au moins deux ou trois fois (par exemple, avec des vérifications à 5-8 heures et à nouveau 24-48 heures plus tard).
Impact sur les métriques de timing
Lorsqu'une détection résulte d'une relecture de règle, la période de détection ou le code temporel de l'événement de l'alerte font référence à l'heure de l'activité malveillante d'origine. L'heure de création correspond à l'heure à laquelle la détection a été créée, ce qui peut être beaucoup plus tard, parfois des heures ou des jours plus tard.
Une latence de détection élevée (grande différence de temps entre l'événement et la détection) est généralement due au réenrichissement des données tardives ou à la latence dans le pipeline du graphique de contexte d'entité (ECG, Entity Context Graph).
Ce décalage temporel peut donner l'impression qu'une détection est "tardive" ou "retardée", ce qui peut induire les analystes en erreur et fausser les métriques de performances telles que le temps moyen de détection.
| Composant de métrique | Source de l'heure | Impact des rediffusions sur le temps moyen avant détection |
|---|---|---|
| Fenêtre de détection / Code temporel de l'événement | Heure à laquelle l'événement de sécurité d'origine s'est produit. | Cette heure reste précise par rapport à l'heure de l'événement. |
| Date et heure de détection / Date et heure de création | Heure à laquelle la détection a été émise par le moteur. | Cette heure semble "tardive" ou "retardée" par rapport au code temporel de l'événement, car elle repose sur une exécution secondaire (relecture) qui intègre les données d'enrichissement tardives. Ce delta a une incidence négative sur le calcul du MTTD. |
Bonnes pratiques pour mesurer le MTTD
Le MTTD quantifie le temps écoulé entre la compromission initiale et la détection efficace de la menace. Lorsque vous analysez les détections déclenchées par des relectures de règles, appliquez les bonnes pratiques suivantes pour conserver des métriques MTTD précises.
Prioriser les systèmes de détection en temps réel
Pour les détections les plus rapides, utilisez les règles d'événement unique. Ces règles s'exécutent en temps quasi réel, généralement avec un délai de moins de cinq minutes.
Cela permet également une utilisation plus complète des détections composites.
Tenir compte de la relecture des règles dans les règles multi-événements
Les règles multi-événements entraînent intrinsèquement une latence plus élevée en raison de leur fréquence d'exécution planifiée. Lorsque vous mesurez le MTTD pour les détections générées par des règles multi-événements, il est essentiel de comprendre que les détections résultant de la relecture automatique des règles servent à améliorer la couverture et la précision. Bien que ces relectures permettent souvent de détecter les menaces nécessitant un contexte tardif, elles augmentent nécessairement la latence signalée pour cette détection spécifique.
Pour les alertes critiques et urgentes : utilisez des règles à événement unique ou des règles multi-événements avec les fréquences d'exécution pratiques les plus courtes (par exemple, des fenêtres de correspondance plus courtes, inférieures à une heure).
Pour les corrélations complexes et de longue durée (UEBA, attaques en plusieurs étapes) : attendez-vous à une latence plus élevée (jusqu'à 48 heures ou plus) si les règles reposent sur des jointures contextuelles étendues ou des listes de référence qui peuvent être mises à jour de manière asynchrone. L'avantage ici est une détection plus fidèle plutôt qu'une vitesse absolue.
Optimiser les règles pour réduire la dépendance à l'enrichissement tardif
Pour optimiser la vitesse de détection et minimiser l'impact des exécutions d'enrichissement rétroactif, envisagez d'utiliser des champs sans alias (champs qui ne sont pas soumis aux pipelines d'enrichissement en aval) dans la logique de vos règles, dans la mesure du possible.
Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.