Nous avons réorganisé la structure de navigation de notre documentation pour l'aligner directement sur vos workflows opérationnels. Pour en savoir plus, consultez les notes de version et la vidéo de présentation.

Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Comprendre les quotas de règles

Compatible avec :

Google secops SIEM

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 écrites et gérées par votre équipe.
Détections optimisées : règles écrites et gérées par Google.

Quotas de règles personnalisées par package

Les règles personnalisées sont soumises à des quotas de performances en fonction de votre package Google SecOps.

Le tableau suivant répertorie les quotas de règles pour chaque package :

Package	Quota total de règles	Quota de règles à événements multiples
Standard	1 000	75
Enterprise	2 000	200
Enterprise Plus	3 500	400

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, procédez comme suit :

Dans Google SecOps, accédez à Détection > Règles et détections.
Sélectionnez l'onglet Tableau de bord des règles.
Cliquez sur Capacité des règles. La fenêtre pop-up des détails de la capacité affiche les quotas suivants :
- Quota de règles pour les événements multiples : nombre de règles à événements multiples activées par rapport au nombre maximal autorisé.
- Quota total de règles : nombre total de règles activées par rapport au nombre maximal autorisé.

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

Les règles à événement unique ne sont comptabilisées que dans le quota actif total.
Les règles à événements multiples consomment simultanément de la capacité à partir des quotas actifs totaux et à événements multiples.

Les règles à événements multiples consomment beaucoup plus de ressources que les règles à événement unique. Vous pouvez disposer d'espace disponible dans votre quota total , mais être bloqué et ne pas pouvoir activer une nouvelle règle si vous avez épuisé votre quota à événements multiples.

Capacité des détections optimisées

Les détections optimisées (également appelées "règles Google SecOps") sont des ensembles de règles créés par Google Threat Intelligence (GTI).

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 optimisés. Vous pouvez activer tous les ensembles de règles optimisés simultanément sans risquer de compromettre les performances ni d'atteindre un plafond de capacité.

Bien que le tableau de bord fournisse des métriques de capacité ou de pondération , ces chiffres sont informatifs et ne constituent pas des limites strictes. Si un avertissement de limite se déclenche, vérifiez la configuration de votre package de licence.

Calcul de la capacité optimisée

La capacité optimisée n'est pas basée sur le nombre de règles, mais sur la somme des pondérations attribuées à chaque ensemble de règles activé. La capacité par défaut est de 150.

Pondération : la pondération d'un ensemble de règles est basée sur sa complexité et le volume d'événements qu'il traite. Les ensembles de règles plus complexes ou ceux qui traitent plus d'événements ont une pondération plus élevée.
Consommation : lorsque des règles (précises, générales ou les deux) sont activées pour un ensemble de règles, la pondération de la capacité totale de l'ensemble de règles est comptabilisée dans l'utilisation totale.

Afficher les détails de la capacité optimisée

Pour afficher la capacité et l'utilisation des détections optimisées :

Dans Google SecOps, accédez à Détection > Règles et détections > Détections optimisées.
Sélectionnez l'onglet Ensembles de règles. La colonne Capacité affiche la pondération de chaque ensemble de règles.
Cliquez sur le bouton d'état Capacité des détections optimisées pour afficher l'utilisation totale de la capacité du compte.

Activer les ensembles de règles optimisés

Si votre package le permet, vous pouvez activer des règles dans les ensembles de règles optimisés :

Dans Google SecOps, accédez à Détection > Règles et détections > Détections optimisées.
Dans l'onglet Ensembles de règles, cochez les cases correspondant aux ensembles de règles que vous souhaitez activer.
Dans le menu des actions groupées, sélectionnez Activer tous les éléments sélectionnés.
Confirmez votre utilisation de la capacité en cliquant sur Capacité des détections optimisées, ou accédez à Détection > Règles et détections, sélectionnez l'onglet Tableau de bord des règles, puis cliquez sur Capacité des règles.

Optimisation des performances du système

Cette section présente des stratégies d'optimisation pour maximiser la capacité de vos règles et les performances de votre système.

Modulariser la logique complexe

Créez des règles à événement unique légères pour signaler les comportements atomiques. Autrement dit, évitez d'écrire des règles à événements multiples massives qui tentent de détecter chaque étape d'une attaque à partir de journaux bruts.

Détecter les signaux avec des règles à événement unique
- Créez des règles à événement unique pour les 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.
Mettre en corrélation les alertes avec une règle composite ou à événements multiples
- Écrivez une règle composite qui utilise comme entrée les détections générées à l'étape 1.
- Impact : consomme le quota à événements multiples (coûteux).
- Avantage : vous utilisez le quota à événements multiples une seule fois pour la logique, au lieu de retraiter plusieurs fois les journaux bruts pour différents scénarios.

Créer une conception de règle efficace

Prioriser la logique à é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 comme une règle à événement unique pour enregistrer votre quota à événements multiples pour les corrélations. Évitez d'utiliser une fenêtre de correspondance.
Utiliser des listes de référence : au lieu de N règles pour N indicateurs, 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.
Effectuer des audits réguliers : auditez régulièrement les règles mises en pause ou désactivées. Bien qu'elles ne soient pas comptabilisées dans le quota actif, leur archivage permet de maintenir l'environnement propre.

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

Scénario : détecter un pirate informatique qui tente de forcer l'accès à un serveur 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 à événement unique

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

Règle A (signal de force brute) :
- Logique :
  - Recherchez auth.status = FAILURE.
  - Regroupez les événements de connexion.
  - Déclenchez-les si plus de cinq tentatives infructueuses sont effectuées 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-la 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 : Mettre en corrélation les alertes avec une règle composite

Écrivez 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 Possible_RDP_Brute_Force AND PsExec_Usage 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 à événements multiples), mais ne traite que les quelques alertes générées à l'étape 1.

Cette approche à plusieurs niveaux optimise 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 dans des détections haute fidélité à l'aide de règles à événement unique, vous réduisez le volume de données traité par le moteur à événements multiples.

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