Exécuter une règle par rapport aux données en direct
Lorsque vous créez une règle, elle ne recherche pas initialement les détections en fonction les événements reçus dans votre compte Google Security Operations en temps réel. Cependant, vous définissez pour rechercher les détections en temps réel en activant l'option Règle en temps réel est activée.
Pour activer 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 active.
Règle en temps réel
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 le nombre maximal de règles pouvant être actives. Il se trouve dans l'angle supérieur droit 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 et le nombre maximal de règles pouvant être activées. 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.
- Quota total de règles : indique le nombre total actuel de règles activées en tant que règles en ligne 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 ligne.
Pour en savoir plus sur les différents types de règles, cliquez ici.
Exécution des règles
Les exécutions de règles actives pour un segment d'heure d'événement donné seront déclenchées avec une fréquence décroissante. 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 davantage d'événements. Les événements et les données d'entité peuvent être traités à nouveau en raison de nouveaux 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 répertorie les différents facteurs qui contribuent aux délais 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. Utilisez ces règles, lorsque cela est possible, afin de minimiser la latence.
- Les règles multi-événements sont exécutées de manière programmée, ce qui entraîne une latence plus élevée en raison du temps entre les exécutions planifiées.
Fréquence d'exécution
Pour accélérer la détection, limitez la fréquence d'exécution et la fenêtre de correspondance. L'utilisation de fenêtres de correspondance plus courtes (moins d'une heure) permet des exécutions plus fréquentes.
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 à l'événement UDM et aux codes temporels d'ingestion.
Jointures contextuelles
Les règles multi-événements peuvent avoir des délais plus longs avec des données contextuelles, telles que l'UEBA ou le graphique des entités. 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 de 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 tardives 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 la non-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 des journaux à Google Security Operations dès que l'événement se produit.
- Contrôlez les règles pour déterminer s'il est nécessaire d'utiliser des données inexistantes ou enrichies en contexte.
- Configurez une fréquence d'exécution plus faible.
État de la règle
Les règles actives peuvent être associées à l'un des états suivants:
Activée:la règle est active et fonctionne normalement comme une règle active.
Désactivée:la règle est désactivée.
Limité : cet état peut être attribué aux règles en direct lorsqu'elles présentent une utilisation anormalement élevée des ressources. Les règles limitées sont isolées des autres règles en vigueur du système afin de maintenir la stabilité de Google Security Operations.
Pour les règles en direct limitées, l'exécution de la règle n'est pas garantie. Toutefois, si l'exécution de la règle aboutit, les détections sont conservées et disponibles pour que vous puissiez les consulter. Les règles en direct limitées génèrent toujours un message d'erreur, qui inclut 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.
Mise en veille:les règles actives sont associées à cet état lorsqu'elles sont associées à l'état Limitée. depuis trois jours et n'ont constaté aucune amélioration des performances. Exécutions pour cette règle ont été mises en veille et des messages d'erreur contenant des informations et améliorer les performances de la règle.
Pour faire revenir une règle active à l'état Activée, suivez Bonnes pratiques YARA-L pour d'améliorer les performances de votre règle, puis de l'enregistrer. Une fois la règle enregistrée, l'état Enabled (Activé) sera rétabli et l'opération dure au moins une heure. avant qu'elle ne revienne à l'état Limitée.
Vous pouvez potentiellement résoudre les problèmes de performances d'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é.
L'état des règles s'affiche dans le tableau de bord des règles. Vous pouvez également y accéder 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 l'état de la règle est Limitée ou Mis en veille. et vous redirige vers la documentation sur la façon de résoudre le problème.