Cette page a été traduite par l'API Cloud Translation.

Exécuter une règle concernant des données actives

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 et activez l'option Règle en ligne.

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.

Les limites de règles suivantes s'appliquent à Google Security Operations:

Quota de règles d'événements multiples : indique le nombre actuel de règles d'événements multiples activées comme actives et le nombre maximal de règles pouvant être activées. Pour en savoir plus sur la différence entre les règles relatives à un événement unique et les règles d'événements multiples, cliquez ici.
Quota total de règles : affiche le nombre total actuel de règles activées comme actives dans tous les types de règles et le nombre maximal de règles pouvant être actives.

Pour en savoir plus sur les différents types de règles, consultez cette page.

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. Après une dernière exécution de nettoyage, aucune autre 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 la dernière enrichissement des données d'événements et d'entités.

Certaines détections peuvent donc être générées de manière rétroactive 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, et les événements et les données d'entité peuvent être traités à nouveau en raison de nouveaux enrichissements.

Latences de détection

Le délai nécessaire pour qu'une détection soit générée à partir d'une règle active est déterminé par différents facteurs. Exemple :

Date et heure d'ingestion des données de journaux d'origine.
Indique si la règle utilise des données enrichies en contexte. Les détections peuvent être retardées en raison de l'enrichissement.
Indique si la règle est inexistante. Pour les règles inexistantes (règles contenant !$e ou #e = 0 dans la section des conditions), le moteur de détection ajoute un délai d'au moins une heure à la latence prévue (en fonction de la fréquence d'exécution de la règle) pour autoriser les données tardives.

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ée:cet état peut être attribué aux règles actives lorsqu'elles s'affichent. une utilisation anormalement élevée des ressources. Les règles Limited 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 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 un délai de trois jours, ses est remplacé par Mis en veille.
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 améliorer les performances de votre règle, puis l'enregistrer. Une fois la règle enregistrée, l'état Enabled (Activé) sera rétabli et l'opération prendra au moins une heure. avant qu'elle ne revienne à l'état Limitée.

Vous pouvez éventuellement résoudre les problèmes de performances liés à une règle en la configurant de s'exécuter moins fréquemment. Par exemple, vous pouvez reconfigurer une règle toutes les 10 minutes pour une exécution une fois par heure ou une fois toutes les 24 heures. Toutefois, la modification de la fréquence d'exécution d'une règle ne rétablit pas l'état Activée : Si vous apportez une légère modification à la règle et que vous l'enregistrez, réinitialiser automatiquement son état 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 les règles de la propriété Limited ou Mis en veille sont disponibles Méthode API ListErrors. Celle-ci 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.