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

Syntaxe de la section "Match"

Compatible avec :

Google SecOps SIEM

La section match fournit les paramètres nécessaires pour corréler plusieurs événements associés en une seule détection. Il n'est obligatoire que pour les règles qui associent deux événements distincts ou plus. Utilisez-le pour définir les critères de cette corrélation en spécifiant les éléments suivants :

Champs de regroupement (clés) : champs spécifiques des événements (définis dans la section events) qui doivent partager la même valeur pour que les événements soient associés de manière logique.
Contrainte de temps : période continue au cours de laquelle les événements associés doivent se produire pour constituer une seule correspondance complète. Cette information n'est requise que pour les règles. Elle n'est pas nécessaire pour la recherche ni les tableaux de bord.

Définir la section "Correspondance"

Les règles exigent que les variables de correspondance soient des espaces réservés définis dans la section event. Vous pouvez également spécifier des champs event dans la recherche et les tableaux de bord.

Utilisez les variables d'espace réservé définies dans la section events pour spécifier la période pendant laquelle les événements doivent se produire. Tous les événements correspondants qui se produisent en dehors de la période spécifiée sont ignorés pour ce groupe de détection particulier.

Utilisez le mot clé over et la syntaxe <number><m/h/d> (où m/h/d correspond à des minutes, des heures et des jours) pour spécifier la période. Vous pouvez spécifier une durée minimale d'une minute et une durée maximale de 48 heures.

Cette règle détecte les échecs de connexion qui se produisent dans un intervalle de 10 minutes. La corrélation de plusieurs échecs de connexion sur une courte période indique souvent une tentative d'accès par force brute ou non autorisée.

rule failed_logins
{
  meta:
   author = "Security Team"
   description = "Detects multiple failed user logins within 10-minute windows."
   severity = "HIGH"

  events:
   $e.metadata.event_type = "USER_LOGIN"
   $e.security_result.action = "FAIL"
   $user = $e.target.user.userid

  match:
   $user over 10m

  condition:
    #e >= 5
}

La section match permet de trouver les utilisateurs dont la connexion a échoué dans un nouveau lieu au cours d'un intervalle de 10 minutes :

match:
   $user over 10m

Valeurs nulles dans la section "Correspondances"

Google SecOps filtre implicitement les valeurs nulles pour tous les espaces réservés utilisés dans la section match ("" pour les chaînes, 0 pour les nombres, false pour les valeurs booléennes et la valeur à la position 0 pour les types énumérés).

Exemple : filtrer les valeurs nulles

L'exemple suivant illustre les requêtes qui filtrent les valeurs nulles.

rule ZeroValuePlaceholderExample {
  meta:
  events:
    // Because $host is used in the match section, the query behaves
    // as if the following predicate was added to the events section:
    // $host != ""
    $host = $e.principal.hostname

    // Because $otherPlaceholder was not used in the match,
    // there is no implicit filtering of zero values for $otherPlaceholder.
    $otherPlaceholder = $e.principal.ip

  match:
    $host over 5m

  condition:
    $e
}

Toutefois, si un espace réservé est attribué à une fonction, les requêtes ne filtrent pas implicitement les valeurs nulles des espaces réservés utilisés dans la section match.

Pour désactiver le filtrage implicite des valeurs nulles, vous pouvez utiliser l'option allow_zero_values dans la section des options. L'option allow_zero_values n'est disponible que dans les règles.

Exemple : autoriser les valeurs nulles

L'exemple suivant illustre les requêtes qui ne filtrent pas implicitement les valeurs nulles des espaces réservés utilisés dans la section match :

rule ZeroValueFunctionPlaceholder {
  meta:
  events:
    // Even though $ph is used in the match section, there is no
    // implicit filtering of zero values for $ph, because $ph is assigned to a function.
    $ph = re.capture($e.principal.hostname, "some-regex")

  match:
    $ph over 5m

  condition:
    $e
}

Périodes acceptées

Vous pouvez regrouper les champs et les espaces réservés d'événement dans la section match par une précision temporelle spécifiée à l'aide de l'une des fenêtres acceptées suivantes.

Fenêtres récurrentes (fenêtres qui se chevauchent)
Fenêtres bascules (fenêtres non chevauchantes)
Fenêtres glissantes (fenêtres générées par les pivots)

Fenêtres récurrentes

Une fenêtre de saut est un type de requête multi-événements qui regroupe les événements correspondant aux critères d'une requête dans un délai spécifié, quel que soit l'ordre dans lequel ils se produisent. Par défaut, les requêtes YARA-L avec une section match utilisent des fenêtres de saut pour corréler plusieurs événements au fil du temps. La plage de temps d'exécution de la requête est divisée en un ensemble de fenêtres de saut qui se chevauchent, chacune ayant la durée spécifiée dans la section match. Les événements sont ensuite corrélés dans chaque fenêtre de saut.

Par exemple, pour une requête exécutée sur la plage horaire [1:00, 2:00], avec une section match sur 30m, un ensemble possible de fenêtres de saut qui pourraient être générées est [1:00, 1:30], [1:03, 1:33] et [1:06, 1:36]. Ces fenêtres permettent de corréler plusieurs événements.

Tumbling windows

Une fenêtre bascule segmente un flux de données en intervalles de temps continus, de taille fixe et sans chevauchement. Chaque événement de données n'est attribué qu'à une seule fenêtre. Cela contraste avec une fenêtre glissante ou récurrente, qui peut avoir des intervalles de temps qui se chevauchent.

Par exemple, avec une fenêtre glissante de 30 minutes, les événements qui se produisent entre 1:00:00 et 1:29:59 sont traités ensemble. Ensuite, l'ensemble d'événements suivant, de 1:30:00 à 1:59:59, est traité séparément.

Fenêtres glissantes

Lorsque vous devez rechercher des événements qui se produisent dans un ordre relatif spécifique (par exemple, e1 se produit jusqu'à deux minutes après e2), les fenêtres glissantes sont très efficaces. Les fenêtres glissantes sont générées lorsqu'une contrainte temporelle commence ou se termine par une variable d'événement pivot spécifiée. Cela permet de suivre de manière dynamique la séquence et le timing des événements par rapport à cette variable d'événement pivot spécifique.

Les événements sont ensuite corrélés dans chaque fenêtre glissante. Cela permet de rechercher des événements qui se produisent dans un ordre spécifique (par exemple, e1 se produit dans les deux minutes suivant e2). Une occurrence de l'événement e1 et une occurrence de l'événement e2 sont corrélées si l'événement e1 se produit dans la durée de la fenêtre glissante après l'événement e2.

Les fenêtres glissantes sont basées sur la variable d'événement pivot (pivot-event-var).
Utilisez le mot clé before pour générer des fenêtres glissantes qui se terminent à chaque occurrence de l'événement pivot.
Utilisez le mot clé after pour générer des fenêtres glissantes qui commencent à chaque occurrence de l'événement pivot.

Spécifiez des fenêtres glissantes dans la section match d'une requête comme suit :

<match-var-1>, <match-var-2>, ... over <duration> before|after <pivot-event-var>

Les exemples suivants montrent des fenêtres glissantes valides :

$var1, $var2 over 5m after $e1

$user over 1h before $e2

Remarques :

Exemple de fenêtre glissante supplémentaire.
L'utilisation de fenêtres glissantes au lieu de fenêtres avec chevauchement peut entraîner des performances plus lentes. Nous vous recommandons d'utiliser des fenêtres glissantes uniquement dans des cas spécifiques, par exemple lorsque l'ordre des événements est absolument nécessaire ou lorsque vous recherchez l'absence d'événements.
Étant donné que les fenêtres glissantes sont conçues pour détecter plusieurs événements, nous vous recommandons de ne pas les utiliser pour les requêtes à événement unique. Utilisez plutôt l'une des solutions de contournement suivantes :
- Convertissez la requête pour utiliser plusieurs variables d'événement et mettez à jour la section des conditions si la requête nécessite plusieurs occurrences de l'événement.
- Vous pouvez également ajouter des filtres d'horodatage au lieu d'utiliser une fenêtre glissante. Par exemple : $permission_change.metadata.event_timestamp.seconds < $file_creation.metadata.event_timestamp.seconds
- Retirez la fenêtre coulissante.

Étapes suivantes

Informations supplémentaires

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