Appliquer une règle aux données en direct

Compatible avec:

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:

  1. Cliquez sur Détection > Règles et détections.

  2. Cliquez sur l'onglet Panneau de contrôle des règles.

  3. Cliquez sur l'icône d'option more_vert Règles pour une règle, puis activez l'option Règle active.

    Règle en direct

    Règle en direct

  4. Sélectionnez Afficher les détections de règles pour afficher les détections d'une règle active.

Quota de règles d'affichage

En haut à droite du tableau de bord "Règles", cliquez sur Capacité des règles pour afficher les limites du nombre de règles pouvant être activées.

Google Security Operations applique les limites de règles suivantes:

  • Quota de règles pour les événements multiples: affiche le nombre actuel de règles pour les événements multiples activées et le nombre maximal autorisé. Découvrez la différence entre les règles Événement unique et Événements multiples.
  • Quota total de règles: affiche le nombre total actuel de règles activées en tant que règles en ligne pour tous les types de règles et le nombre maximal de règles pouvant être activées en tant que règles en ligne.

Exécutions de règles

Les exécutions de règles en direct pour un bucket d'heures d'événement donné sont 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 autre exécution ne démarre.

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.

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 nouveaux enrichissements.

Déduplication

Le moteur de règles identifie et supprime automatiquement les détections en double des règles. Ce processus ne s'applique qu'aux règles avec des variables de correspondance, car elles reposent sur des périodes basées sur le temps. Les détections avec des valeurs de variable de correspondance identiques, dans des périodes temporelles qui se chevauchent, sont supprimées en tant que doublons.

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

  • Les règles d'événement unique sont exécutées en temps quasi 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. L'utilisation de 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 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 des règles n'est pas garantie. Toutefois, si l'exécution de la règle réussit, 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.

    Remarque: Si aucune modification récente n'a été apportée à cette règle, ces erreurs peuvent être intermittentes et être résolues automatiquement.

  • Mise 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 est réinitialisée à l'état Activée. Il faut 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 en état limité ou suspendu, et vous redirige vers la documentation expliquant comment résoudre le problème.