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 délai 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.
Le processus de relecture des règles gère deux catégories de règles différentes :
Règles à événement unique : lorsque le processus d'enrichissement UDM met à jour un événement précédemment évalué, le système relance les règles à événement unique.
Règles multi-événements : les règles multi-événements s'exécutent selon un calendrier que vous avez sélectionné et traitent des blocs de temps d'événement. Ces règles réévaluent à plusieurs reprises le même bloc temporel à différents intervalles pour capturer les mises à jour d'enrichissement tardives, telles que les données de contexte utilisateur ou d'asset correspondantes, ou un indicateur de compromission (IOC).
Par exemple, une règle peut s'exécuter au moins deux ou trois fois (à 5-8 heures, puis à nouveau 24-48 heures plus tard) pour tenir compte des données d'événement et de contexte qui arrivent tardivement.
Déclencheurs de relecture des règles
Le système réévalue (réexécute) les règles lorsque des données de contexte pertinentes arrivent ou lorsque des données de contexte sont traitées plus tard que les données d'événement initiales.
Voici quelques raisons courantes de relecture :
Données d'enrichissement reçues tardivement : les pipelines d'enrichissement de données, tels que le graphique de contexte d'entité (ECG), traitent souvent les données par lots. Lorsqu'un événement UDM arrive avant ses données contextuelles associées (comme les informations sur les composants ou le contexte utilisateur), l'exécution initiale de la règle peut manquer une détection.
Mises à jour rétroactives de l'enrichissement UDM : les règles utilisant des champs alias (champs enrichis) dans leur logique de détection, comme
$udm.event.principal.hostname, peuvent déclencher des relectures lorsque les données sources (par exemple, les enregistrements DHCP) sont retardées. Cette arrivée tardive met à jour rétroactivement les valeurs de ces champs. Les relectures de règles ultérieures utilisent ces valeurs nouvellement enrichies, ce qui peut déclencher une détection qui avait été manquée auparavant.
Impact sur les métriques de timing
Lorsqu'une détection résulte d'une relecture de règle, nous utilisons la terminologie suivante :
- 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 le système a créé la détection, ce qui peut être beaucoup plus tard, parfois des heures ou des jours plus tard.
- La latence de détection correspond à la différence de temps entre le timestamp de l'événement et l'heure de création de la détection.
Le réenrichissement dû à des données tardives ou à une latence lors de la mise à jour d'une source de contexte telle que le graphique de contexte d'entité (ECG) entraîne généralement une latence de détection élevée.
Ce décalage horaire 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 "différé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 les relectures de règles, appliquez les bonnes pratiques suivantes pour conserver des métriques MTTD précises.
Google SecOps fournit plusieurs métriques interrogeables par les utilisateurs pour mesurer précisément le MTTD. Pour en savoir plus sur ces métriques, consultez la page Exemples de requêtes YARA-L 2.0 pour la page "Tableaux de bord".
Une icône dans la colonne Type de détection identifie les détections issues de réanalyses ou de chasses rétroactives. Cette icône s'affiche également sur la page Alertes de Google SecOps.
Prioriser les systèmes de détection en temps réel
Pour des détections plus rapides, utilisez des 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 à partir de règles multi-événements, sachez que les relectures de règles automatisées augmentent la couverture et la précision. Ces relectures permettent souvent de détecter des menaces nécessitant un contexte tardif, ce qui augmente la latence signalée pour ces détections.
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. La réduction de la fenêtre de correspondance n'a pas d'incidence directe sur la latence, mais elle peut améliorer l'efficacité en définissant le délai minimal.
Pour les corrélations complexes et de longue durée (UEBA, attaques en plusieurs étapes) : ces règles s'appuient sur des jointures contextuelles ou des listes de référence étendues, qui peuvent être mises à jour de manière asynchrone. Ils peuvent présenter une latence élevée avec des données contextuelles ou d'événement tardives, mais ils offrent l'avantage d'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 à des pipelines d'enrichissement en aval) dans la logique de vos règles, si possible.
Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.