Comprendre les quotas de règles

Compatible avec :

Google Security Operations applique des limites de capacité aux règles de détection pour garantir des performances système et une vitesse de requête cohérentes.

La capacité des règles est gérée selon les deux catégories suivantes :

  • Règles personnalisées : règles rédigées et gérées par votre équipe.

  • Détections organisées : règles écrites et gérées par Google.

Suivre le quota de règles personnalisées

Les règles personnalisées sont soumises à des quotas de performances stricts en fonction de leur complexité.

Pour suivre le quota de règles personnalisées :

  1. Dans Google SecOps, accédez à Détection > Règles et détections.

  2. Accédez à l'onglet Tableau de bord des règles.

  3. Cliquez sur Capacité des règles pour ouvrir la boîte de dialogue Quota de règles pour plusieurs événements. Il affiche les quotas Règles pour plusieurs événements et Nombre total de règles.

Type de quota Description Éléments comptabilisés dans le quota
Quota total de règles Nombre maximal de règles activées autorisées dans l'environnement. Toutes les règles actives : règles à événement unique et à événements multiples.
Quota de règles pour plusieurs événements Sous-ensemble limité du quota total réservé aux règles multi-événements. Règles multi-événements uniquement : règles qui mettent en corrélation plusieurs événements au fil du temps, utilisent des jointures ou effectuent des agrégations par fenêtre (par exemple, les règles avec une section "Correspondance").

Les règles multi-événements consomment beaucoup plus de ressources que les règles à événement unique. Il est possible que vous disposiez d'espace disponible dans votre quota total, mais que vous ne puissiez pas activer de nouvelle règle si vous avez épuisé votre quota multi-événements.

Suivre le quota de détections optimisées

Les détections organisées sont disponibles pour les clients Enterprise et Enterprise Plus. Les droits d'accès aux licences sont explicitement dimensionnés pour s'adapter à l'ensemble de la bibliothèque d'ensembles de règles sélectionnés. Bien que le tableau de bord fournisse des métriques de capacité ou de poids, ces chiffres sont fournis à titre informatif et ne constituent pas des limites strictes.

Pour les clients Enterprise et Enterprise Plus, les droits d'accès aux licences sont explicitement dimensionnés pour s'adapter à l'ensemble de la bibliothèque de règles organisées. Bien que le tableau de bord fournisse des métriques Capacité ou Poids, ces chiffres sont fournis à titre informatif et ne constituent pas des limites strictes.

Vous pouvez activer simultanément tous les ensembles de règles sélectionnés sans risquer de compromettre les performances ni d'atteindre une limite de capacité. Si un avertissement de limite s'affiche, vérifiez la configuration de votre package de licences.

Optimisation des performances du système

Cette section décrit les stratégies d'optimisation permettant de maximiser la capacité de vos règles et les performances de votre système.

Modulariser la logique complexe

Créez des règles simples et légères pour signaler les comportements atomiques. En d'autres termes, évitez d'écrire des règles multi-événements massives qui tentent de détecter chaque étape d'une attaque à partir de journaux bruts.

  1. Détecter des signaux avec des règles à événement unique

    • Créez des règles à événement unique pour des comportements individuels (par exemple, User Login Failed, Process Launched).

    • Impact : consomme le quota actif total (abondant) et s'exécute en temps quasi réel.

  2. Corréler des alertes avec une règle composite ou multi-événement

    • Écrivez une règle composite qui utilise les détections générées à l'étape 1 comme entrée.

    • Impact : consomme le quota d'événements multiples (coûteux).

    • Avantage : vous utilisez le quota multi-événements une seule fois pour la logique, au lieu de retraiter les journaux bruts plusieurs fois pour différents scénarios.

Créer une conception de règles efficace

  • Priorisez la logique d'événement unique : si une détection peut être effectuée avec une seule ligne de journal (par exemple, "L'utilisateur a visité un domaine malveillant connu"), écrivez-la sous forme de règle d'événement unique pour économiser votre quota multi-événements pour les corrélations. Évitez d'utiliser une fenêtre de correspondance.

  • Utilisez des listes de référence : au lieu d'utiliser des règles N pour les indicateurs N, utilisez une seule règle qui fait référence à une liste de référence (par exemple, target.ip in %suspicious_ips). Cela ne consomme qu'une seule unité de quota de règles.

  • Effectuez des audits réguliers : auditez régulièrement les règles mises en veille ou désactivées. Bien qu'ils ne soient pas comptabilisés dans le quota actif, l'archivage permet de garder l'environnement propre.

Cas d'utilisation : détecter les mouvements latéraux par force brute

Scénario : Détecter un pirate informatique qui tente d'accéder à un serveur par force brute via la plate-forme de données sur les risques (RDP) et exécute immédiatement un outil d'administration suspect (comme PsExec) pour se déplacer latéralement.

Étape 1 : Détecter les signaux avec des règles d'événement unique

Créez deux règles légères qui s'exécutent sur le quota total actif abondant. Ces données génèrent des détections.

  • Règle A (signal de force brute) :

    • Logique :

      • Recherchez auth.status = FAILURE.

      • Événements de connexion de groupe.

      • Déclencheur si plus de cinq tentatives infructueuses en une minute.

    • Entrée : événements UDM bruts.

    • Résultat : alerte de détection nommée Possible_RDP_Brute_Force.

    • Coût : faible (utilise le quota actif total).

  • Règle B (signal d'outil suspect) :

    • Logique : déclenchez l'action si le processus est psexec.exe.

    • Entrée : événements UDM bruts.

    • Résultat : alerte de détection nommée PsExec_Usage.

    • Coût : faible (utilise le quota actif total).

Étape 2 : Corrélez les alertes avec la règle composite

Rédigez une règle composite qui examine les détections générées à l'étape 1, et non les journaux bruts.

  • Règle C :

    • Logique : recherchez les événements Possible_RDP_Brute_Force AND PsExec_Usage qui se produisent sur le même principal.hostname dans un délai de 10 minutes.

    • Entrée : détections des règles A et B.

    • Coût : élevé (utilise le quota multi-événements), mais ne traite que les quelques alertes générées à l'étape 1.

Cette approche par niveaux permet d'optimiser à la fois les performances et la rentabilité en dissociant la génération initiale de signaux de la logique de corrélation complexe. En filtrant des milliards d'événements UDM bruts pour obtenir des détections de haute fidélité à l'aide de règles mono-événement, vous réduisez le volume de données traitées par le moteur multi-événements.

Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.