Exécuter une règle par rapport aux données en direct
Lorsque vous créez une règle, elle ne recherche pas initialement de détections basées sur les événements reçus dans votre compte Google Security Operations en temps réel. Toutefois, vous devez définir la règle pour rechercher des détections en temps réel en activant l'option Règle en direct.
Pour mettre en service une règle, procédez comme suit:
Accédez au tableau de bord des règles.
Cliquez sur l'icône d'option Règles d'une règle, puis activez l'option Règle en cours.
Règle en direct
Vous pouvez afficher les détections générées par une règle active en sélectionnant Afficher les détections de règles.
Quota de règles
Cliquez sur le bouton "Capacité" pour afficher les limites du nombre de règles pouvant être activées en temps réel. Il se trouve en haut à droite du tableau de bord des règles.
Google Security Operations applique les limites de règles suivantes:
- Nombre de règles d'événements multiples : indique le nombre actuel de règles d'événements multiples activées en tant que règles en direct et le nombre maximal de règles pouvant être activées en tant que règles en direct. Pour en savoir plus sur la différence entre les règles pour un seul événement et les règles pour plusieurs événements, cliquez ici.
- Nombre total de règles : indique le nombre total actuel de règles activées en tant que règles en direct pour tous les types de règles, ainsi que le nombre maximal de règles pouvant être activées en tant que règles en direct.
Pour en savoir plus sur les différents types de règles, cliquez ici.
Exécutions de règles
Les exécutions de règles en direct pour un bucket temporel d'événement donné seront déclenchées de manière de plus en plus espacée. Une dernière exécution de nettoyage est effectuée, après quoi aucune exécution ne sera lancée.
Chaque exécution s'exécute sur les dernières versions des listes de référence utilisées dans les règles, ainsi que sur les derniers enrichissements de données d'événements et d'entités.
Cela signifie que certaines détections peuvent être générées rétrospectivement si elles ne sont détectées que par les exécutions ultérieures. Par exemple, la dernière exécution peut utiliser la dernière version de la liste de référence, qui détecte désormais plus d'événements. Les données d'événements et d'entités peuvent également être réanalysées en raison de nouvelles enrichissements.
Latences de détection
Plusieurs facteurs déterminent le temps nécessaire pour qu'une détection soit générée à partir d'une règle active. La liste suivante inclut les différents facteurs qui contribuent aux retards de détection:
- Types de règle
- Fréquence d'exécution
- Délai d'ingestion
- Jointures contextuelles
- Données UDM enrichies
- Problèmes liés au fuseau horaire
- Listes de référence
Types de règle
- Les règles d'événement unique sont exécutées en quasi-temps réel de manière continue. Dans la mesure du possible, utilisez ces règles pour réduire la latence.
- Les règles multi-événements sont exécutées de manière planifiée, ce qui entraîne une latence plus élevée en raison du temps écoulé entre les exécutions planifiées.
Fréquence d'exécution
Pour obtenir des détections plus rapides, utilisez une fréquence d'exécution plus courte et une période de correspondance plus courte. Utiliser des périodes de correspondance plus courtes (moins d'une heure) permet d'exécuter des campagnes plus fréquemment.
Délai d'ingestion
Assurez-vous que les données sont envoyées à Google Security Operations dès que l'événement se produit. Lorsque vous examinez une détection, soyez particulièrement attentif aux horodatages de l'événement UDM et de l'ingestion.
Jointures contextuelles
Les règles multi-événements avec des données contextuelles, telles que UEBA ou Entity Graph, peuvent entraîner des délais plus longs. Les données contextuelles doivent d'abord être générées par Google SecOps.
Données UDM enrichies
Google SecOps enrichit les événements avec les données d'autres événements. Pour savoir si une règle évalue un champ enrichi, consultez l'Afficheur d'événements. Si la règle évalue un champ enrichi, la détection peut être retardée.
Problèmes liés au fuseau horaire
Les règles s'exécutent plus fréquemment pour les données en temps réel. Les données peuvent arriver en temps réel, mais Google SecOps peut toujours les traiter comme des données en retard si l'heure de l'événement est incorrecte en raison de problèmes de fuseau horaire. Le fuseau horaire par défaut du SIEM Google SecOps est UTC. Si l'horodatage d'un événement des données d'origine est défini sur un autre fuseau horaire que UTC, modifiez le fuseau horaire des données. Si la mise à jour du fuseau horaire à la source de journalisation n'est pas possible, contactez l'assistance pour que le fuseau horaire puisse être ignoré.
Règles d'inexistence
Les règles qui vérifient l'absence d'existence (par exemple, les règles contenant !$e ou #e=0) sont exécutées avec un délai d'au moins une heure pour s'assurer que les données ont le temps d'arriver.
Listes de référence
Les exécutions de règles utilisent toujours la version la plus récente d'une liste de référence. Si la liste de référence a été récemment mise à jour, une nouvelle détection peut apparaître tardivement, car elle peut être incluse avec les nouveaux contenus de la liste mise à jour lors des exécutions ultérieures de la règle planifiée.
Pour réduire les latences de détection, nous vous recommandons de procéder comme suit:
- Envoyez les données de journal à Google Security Operations dès que l'événement se produit.
- Vérifiez si vous devez utiliser des données d'absence ou enrichies de contexte.
- Configurez une fréquence d'exécution plus faible.
État de la règle
Les règles en vigueur peuvent avoir l'un des états suivants:
Activée:la règle est active et fonctionne normalement en tant que règle active.
Désactivé:la règle est désactivée.
Limité:cet état peut être attribué aux règles en direct lorsqu'elles présentent une utilisation inhabituellement élevée des ressources. Les règles limitées sont isolées des autres règles actives du système afin de maintenir la stabilité de Google Security Operations.
Pour les règles en direct limitées, l'exécution des règles n'est pas garantie. Toutefois, si l'exécution de la règle aboutit, les détections sont conservées et disponibles pour examen. Les règles en direct limitées génèrent toujours un message d'erreur, qui contient des informations sur la façon d'améliorer les performances de la règle.
Si les performances d'une règle Limitée ne s'améliorent pas dans les trois jours, son état passe à Suspendu.
En veille:les règles actives passent à cet état lorsqu'elles ont été définies sur Limitée pendant trois jours et qu'elles n'ont pas amélioré les performances. Les exécutions de cette règle ont été suspendues, et des messages d'erreur contenant des informations sur l'amélioration des performances de la règle sont renvoyés.
Pour rétablir l'état Activé pour une règle active, suivez les bonnes pratiques YARA-L pour améliorer les performances de votre règle et l'enregistrer. Une fois la règle enregistrée, elle sera réinitialisée à l'état Activée. Il faudra au moins une heure pour qu'elle retrouve l'état Limitée.
Vous pouvez potentiellement résoudre les problèmes de performances avec une règle en la configurant pour qu'elle s'exécute moins fréquemment. Par exemple, vous pouvez reconfigurer une règle pour qu'elle s'exécute une fois par heure ou une fois toutes les 24 heures au lieu de toutes les 10 minutes. Toutefois, modifier la fréquence d'exécution d'une règle ne rétablit pas son état sur Activé. Si vous apportez une petite modification à la règle et l'enregistrez, vous pouvez réinitialiser automatiquement son état sur Activé.
Les états des règles sont affichés dans le tableau de bord des règles et sont également accessibles via l'API Detection Engine. Les erreurs générées par des règles avec l'état Limité ou Suspendu sont disponibles à l'aide de la méthode API ListErrors. L'erreur indique que la règle est à l'état Limitée ou Suspendue et vous redirige vers la documentation expliquant comment résoudre le problème.