Syntaxe du langage YARA-L 2.0

Cette section décrit les principaux éléments de la syntaxe YARA-L. Consultez également la page Présentation du langage YARA-L 2.0.

Structure des règles

Pour YARA-L 2.0, vous devez spécifier des déclarations, des définitions et des utilisations de variables dans l'ordre suivant:

1. méta
2. événements
3. correspondance (facultatif)
4. résultat (facultatif)
5. condition
6. options (facultatif)

Remarque :Si vous omettez la section facultative match, la règle peut être mise en correspondance avec un seul événement.

Voici la structure générique d'une règle:

rule <rule Name>
{
    meta:
    // Stores arbitrary key-value pairs of rule details, such as who wrote
    // it, what it detects on, version control, etc.

  events:
    // Conditions to filter events and the relationship between events.

  match:
    // Values to return when matches are found.

  outcome:
    // Additional information extracted from each detection.

  condition:
    // Condition to check events and the variables used to find matches.

  options:
    // Options to turn on or off while executing this rule.
}

Syntaxe de la section Meta

La section Meta est composée de plusieurs lignes, chaque ligne définissant une paire clé-valeur. Une partie de clé doit être une chaîne sans guillemets, et une partie de valeur doit être une chaîne entre guillemets:

<key> = "<value>"

Voici un exemple de ligne de section meta valide:

meta:
    author = "Google"
    severity = "HIGH"

Syntaxe de la section "Événements"

Dans la section events, répertoriez les prédicats pour spécifier les éléments suivants:

• Déclarations de variables
• Filtres de variables d'événement
• Jointures de variables d'événement

Déclarations de variables

Pour les déclarations de variables, utilisez la syntaxe suivante:

• <EVENT_FIELD> = <VAR>
• <VAR> = <EVENT_FIELD>

Les deux sont équivalents, comme illustré dans les exemples suivants:

• $e.source.hostname = $hostname
• $userid = $e.principal.user.userid

Cette déclaration indique que cette variable représente le champ spécifié pour la variable d'événement. Lorsque le champ d'événement est un champ répété, la variable de correspondance peut représenter n'importe quelle valeur du tableau. Il est également possible d'attribuer plusieurs champs d'événement à une seule variable de correspondance ou d'espace réservé. Il s'agit d'une condition de jointure transitive.

Par exemple, cette agrégation :

• $e1.source.ip = $ip
• $e2.target.ip = $ip

Équivaut à:

• $e1.source.ip = $ip
• $e1.source.ip = $e2.target.ip

Lorsqu'une variable est utilisée, elle doit être déclarée via une déclaration de variable. Si une variable est utilisée sans aucune déclaration, elle est considérée comme une erreur de compilation.

Filtres de variables d'événement

Une expression booléenne qui agit sur une seule variable d'événement est considérée comme un filtre.

Jointures de variables d'événement

Toutes les variables d'événement utilisées dans la règle doivent être jointes à toutes les autres variables d'événement de l'une des manières suivantes:

• Directement par le biais d'une comparaison d'égalité entre les champs d'événement des deux variables d'événement jointes, par exemple: $e1.field = $e2.field L'expression ne doit pas inclure d'éléments arithmétiques.

• Par le biais d'une jointure transitive impliquant uniquement un champ d'événement (consultez la section Déclaration de variable pour connaître la définition d'une jointure transitive) L'expression ne doit pas inclure d'éléments arithmétiques.

Par exemple, en supposant que $e1, $e2 et $e3 sont utilisés dans la règle, les sections events suivantes sont valides.

events:
  $e1.principal.hostname = $e2.src.hostname // $e1 joins with $e2
  $e2.principal.ip = $e3.src.ip // $e2 joins with $e3

events:
  // $e1 joins with $e2 via function to event comparison
  re.capture($e1.src.hostname, ".*") = $e2.target.hostname

events:
  // $e1 joins with $e2 via an `or` expression
  $e1.principal.hostname = $e2.src.hostname
  or $e1.principal.hostname = $e2.target.hostname
  or $e1.principal.hostname = $e2.principal.hostname

events:
  // all of $e1, $e2 and $e3 are transitively joined via the placeholder variable $ip
  $e1.src.ip = $ip
  $e2.target.ip = $ip
  $e3.about.ip = $ip

events:
  // $e1 and $e2 are transitively joined via function to event comparison
  re.capture($e2.principal.application, ".*") = $app
  $e1.principal.hostname = $app

Remarque :Si votre seule condition de jointure est une chaîne or, une fonction pour comparer des événements ou une combinaison des deux, la règle risque de ne pas fonctionner correctement.

Voici toutefois des exemples de sections events non valides.

events:
  // Event to arithmetic comparison is an invalid join condition for $e1 and $e2.
  $e1.principal.port = $e2.src.port + 1

events:
  $e1.src.ip = $ip
  $e2.target.ip = $ip
  $e3.about.ip = "192.1.2.0" //$e3 is not joined with $e1 or $e2.

events:
  $e1.src.port = $port

  // Arithmetic to placeholder comparison is an invalid transitive join condition.
  $e2.principal.port + 800 = $port

Correspondance avec la syntaxe de la section

Dans la section match, répertoriez les variables de correspondance des événements de groupe avant de vérifier les conditions de correspondance. Ces champs sont renvoyés avec chaque correspondance.

• Spécifiez ce que chaque variable de correspondance représente dans la section events.
• Spécifiez la durée à utiliser pour mettre en corrélation les événements après le mot clé over. Les événements en dehors de cette période sont ignorés.

• Utilisez la syntaxe suivante pour spécifier la durée: <number><m/h/d>

  Où m/h/d signifie respectivement les minutes, les heures et les jours.

• La durée minimale que vous pouvez spécifier est d'une minute.

• La durée maximale que vous pouvez spécifier est de 48 heures.

Voici un exemple de match valide:

$var1, $var2 over 5m

Cette instruction renvoie $var1 et $var2 (définis dans la section events) lorsque la règle trouve une correspondance. La durée spécifiée est de 5 minutes. Les événements à plus de cinq minutes d'intervalle ne sont pas corrélés et donc ignorés par la règle.

Voici un autre exemple de section match valide:

$user over 1h

Cette instruction renvoie $user lorsque la règle trouve une correspondance. La période spécifiée est d'une heure. Les événements à plus d'une heure d'intervalle ne sont pas corrélés. La règle ne considère pas qu'il s'agit d'une détection.

Voici un autre exemple de section match valide:

$source_ip, $target_ip, $hostname over 2m

Cette instruction renvoie $source_ip, $target_ip et $hostname lorsque la règle trouve une correspondance. La fenêtre de temps spécifiée est de 2 minutes. Les événements à plus de deux minutes d'intervalle ne sont pas corrélés. La règle ne considère pas qu'il s'agit d'une détection.

Les exemples suivants illustrent des sections match non valides:

• var1, var2 over 5m // invalid variable name
• $user 1h // missing keyword

Traitement de la valeur nulle dans la section de correspondance

Le moteur de règles filtre implicitement les valeurs zéro pour tous les espaces réservés utilisés dans la section de correspondance ("" pour la chaîne, 0 pour les nombres, false pour les valeurs booléennes, la valeur en position 0 pour les types énumérés). L'exemple suivant illustre des règles qui filtrent les valeurs nulles.

rule ZeroValuePlaceholderExample {
  meta:
  events:
    // Because $host is used in the match section, the rule 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 section,
    // 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 règles ne filtrent pas implicitement les valeurs zéro des espaces réservés utilisés dans la section de correspondance. L'exemple suivant illustre des règles qui filtrent les valeurs nulles:

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
}

Pour désactiver le filtrage implicite des valeurs nulles, vous pouvez utiliser l'option allow_zero_values dans la section des options.

Fenêtre saut

Par défaut, les règles YARA-L 2.0 avec une section de correspondance sont évaluées à l'aide de fenêtres de saut. La période d'exécution de la règle est divisée en un ensemble de fenêtres de saut qui se chevauchent, chacune d'une 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 règle exécutée sur la période [1:00, 2:00], avec une section match sur 30m, un ensemble possible de fenêtres sautées qui se chevauchent pouvant ê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.

Fenêtre glissante

L'utilisation de fenêtres de saut n'est pas un moyen efficace de rechercher des événements qui se produisent dans un ordre spécifique (par exemple, e1 se produit jusqu'à deux minutes après e2). Une occurrence de l'événement e1 et une occurrence de l'événement e2 ne sont corrélées que si elles se trouvent dans la même fenêtre de saut générée.

Un moyen plus efficace de rechercher ce type de séquence d'événements consiste à utiliser des fenêtres glissantes. Les fenêtres glissantes de la durée spécifiée dans la section match sont générées lorsqu'elles commencent ou se terminent par une variable d'événement de tableau croisé dynamique spécifiée. 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 l'événement 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 pendant la durée de la fenêtre glissante après l'événement e2.

Spécifiez les fenêtres glissantes dans la section match d'une règle comme suit:

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

La variable d'événement de tableau croisé dynamique est la variable d'événement sur laquelle les fenêtres glissantes sont basées. Si vous utilisez le mot clé before, des fenêtres glissantes sont générées et se terminent par chaque occurrence de l'événement de tableau croisé dynamique. Si le mot clé after est utilisé, des fenêtres glissantes sont générées à partir de chaque occurrence de l'événement de tableau croisé dynamique.

Voici des exemples d'utilisations valides de fenêtres glissantes:

• $var1, $var2 over 5m after $e1
• $user over 1h before $e2

Consultez un exemple de règle de fenêtre glissante.

Remarque :Il est connu que l'utilisation de fenêtres glissantes au lieu de fenêtres sautées ralentit les performances. Google recommande de n'utiliser des fenêtres glissantes que dans des cas spécifiques, par exemple lorsqu'il est absolument nécessaire de définir l'ordre des événements ou lorsque vous recherchez des événements qui n'existent pas.

Google recommande de ne pas utiliser de fenêtres glissantes pour les règles relatives à un seul événement, car elles sont conçues pour détecter plusieurs événements. Si l'une de vos règles appartient à cette catégorie, Google recommande l'une des solutions suivantes:

• Convertissez la règle pour qu'elle utilise plusieurs variables d'événement et mettez à jour la section de la condition si elle nécessite plusieurs occurrences de l'événement.
  • Vous pouvez éventuellement ajouter des filtres de code temporel 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.

Syntaxe de la section de résultat

Dans la section outcome, vous pouvez définir jusqu'à 20 variables de résultat, avec des noms arbitraires. Ces résultats seront stockés dans les détections générées par la règle. Les résultats peuvent varier d'une détection à l'autre.

Le nom du résultat, $risk_score, est spécial. Vous pouvez éventuellement définir un résultat avec ce nom. Si vous le faites, il doit s'agir d'un nombre entier ou d'un type à virgule flottante. Si ce champ est renseigné, le risk_score s'affichera dans la vue Enterprise Insights pour les alertes provenant des détections de règles.

Si vous n'incluez pas de variable $risk_score dans la section de résultat d'une règle, l'une des valeurs par défaut suivantes est définie:

• Si la règle est configurée pour générer une alerte, $risk_score est défini sur 40.
• Si la règle n'est pas configurée pour générer une alerte, $risk_score est défini sur 15.

La valeur de $risk_score est stockée dans le champ UDM security_result.risk_score.

Types de données des variables de résultat

Chaque variable de résultat peut avoir un type de données différent, qui est déterminé par l'expression utilisée pour le calculer. Nous acceptons les types de données de résultat suivants:

• entier
• flottants
• chaîne
• listes d'entiers
• listes de flottants
• des listes de chaînes

Logique conditionnelle

Vous pouvez utiliser une logique conditionnelle pour calculer la valeur d'un résultat. Les conditions sont spécifiées à l'aide du modèle de syntaxe suivant:

if(BOOL_CLAUSE, THEN_CLAUSE)
if(BOOL_CLAUSE, THEN_CLAUSE, ELSE_CLAUSE)

Vous pouvez lire une expression conditionnelle comme suit : "si BOOL_CLAUSE est vrai, alors renvoyez THEN_CLAUSE, sinon renvoie ELSE_CLAUSE".

BOOL_CLAUSE doit renvoyer une valeur booléenne. Une expression BOOL_CLAUSE se présente de la même manière que les expressions de la section events. Par exemple, il peut contenir:

• Noms de champs UDM avec opérateur de comparaison, par exemple:

  if($context.graph.entity.user.title = "Vendor", 100, 0)

• variable d'espace réservé définie dans la section events, par exemple:

  if($severity = "HIGH", 100, 0)

• Une autre variable de résultat définie dans la section outcome, par exemple:

  if($risk_score > 20, "HIGH", "LOW")

• fonctions qui renvoient une valeur booléenne, par exemple:

  if(re.regex($e.network.email.from, `.*altostrat.com`), 100, 0)

• Rechercher dans une liste de référence, par exemple:

  if($u.principal.hostname in %my_reference_list_name, 100, 0)

• comparaison d'agrégations, par exemple:

  if(count($login.metadata.event_timestamp.seconds) > 5, 100, 0)

La clause THEN_CLAUSE et la clause ELSE_CLAUSE doivent être du même type de données. Nous acceptons les nombres entiers, les nombres à virgule flottante et les chaînes.

Vous pouvez omettre ELSE_CLAUSE si le type de données est un entier ou une valeur flottante. En cas d'omission, ELSE_CLAUSE prend la valeur 0. Exemple :

`if($e.field = "a", 5)` is equivalent to `if($e.field = "a", 5, 0)`

Vous devez fournir la clause ELSE_CLAUSE si le type de données est une chaîne, ou si THEN_CLAUSE est une variable d'espace réservé ou une variable de résultat.

Opérations mathématiques

Vous pouvez utiliser des opérations mathématiques pour calculer un type de données "Nombre entier" ou "Flottant" dans les sections outcome et events d'une règle. Google Security Operations prend en charge l'addition, la soustraction, la multiplication, la division et le module en tant qu'opérateurs de niveau supérieur dans un calcul.

L'extrait de code suivant est un exemple de calcul dans la section outcome:

outcome:
  $risk_score = max(100 + if($severity = "HIGH", 10, 5) - if($severity = "LOW", 20, 0))

Les opérations mathématiques sont autorisées sur les types d'opérandes suivants, à condition que chaque opérande et l'expression arithmétique entière soient correctement agrégés (voir Agrégations):

• Champs d'événement numériques
• Variables d'espace réservé numériques définies dans la section events
• Variables de résultat numériques définies dans la section outcome
• Fonctions renvoyant des entiers ou des floats
• Agrégations renvoyant des entiers ou des floats

Le module n'est pas autorisé sur les flottants.

Variables d'espace réservé dans les résultats

Lors du calcul des variables de résultat, vous pouvez utiliser des variables d'espace réservé définies dans la section "Événements" de votre règle. Dans cet exemple, supposons que $email_sent_bytes ait été défini dans la section "Événements" de la règle:

Exemple pour un seul événement:

// No match section, so this is a single-event rule.

outcome:
  // Use placeholder directly as an outcome value.
  $my_outcome = $email_sent_bytes

  // Use placeholder in a conditional.
  $other_outcome = if($file_size > 1024, "SEVERE", "MODERATE")

condition:
  $e

Exemple pour plusieurs événements:

match:
  // This is a multi event rule with a match section.
  $hostname over 5m

outcome:
  // Use placeholder directly in an aggregation function.
  $max_email_size = max($email_sent_bytes)

  // Use placeholder in a mathematical computation.
  $total_bytes_exfiltrated = sum(
    1024
    + $email_sent_bytes
    + $file_event.principal.file.size
  )

condition:
  $email_event and $file_event

Variables de résultat dans les expressions d'attribution de résultat

Les variables de résultat peuvent être utilisées pour dériver d'autres variables de résultat, semblables aux variables d'espace réservé définies dans la section events. Vous pouvez faire référence à une variable de résultat dans l'attribution d'une autre variable de résultat avec un jeton $ suivi du nom de la variable. Les variables de résultat doivent être définies avant de pouvoir être référencées dans le texte de la règle. Lorsqu'elles sont utilisées dans une expression d'attribution, les variables de résultat ne doivent pas être agrégées (voir Agrégations).

Dans l'exemple suivant, la variable de résultat $risk_score tire sa valeur de la variable de résultat $event_count:

Exemple pour plusieurs événements:

match:
  // This is a multi event rule with a match section.
  $hostname over 5m

outcome:
  // Aggregates all timestamp on login events in the 5 minute match window.
  $event_count = count($login.metadata.event_timestamp.seconds)
  
  // $event_count cannot be aggregated again.
  $risk_score = if($event_count > 5, "SEVERE", "MODERATE")

  // This is the equivalent of the 2 outcomes above combined.
  $risk_score2 = if(count($login.metadata.event_timestamp.seconds) > 5, "SEVERE", "MODERATE")

condition:
  $e

Les variables de résultat peuvent être utilisées dans n'importe quel type d'expression à droite d'une attribution de résultat, sauf dans les expressions suivantes:

• Agrégations
• Appels de fonctions Arrays.length()
• Avec les modificateurs any ou all

Agrégations

Les champs d'événements répétés sont des valeurs non scalaires. Autrement dit, une variable unique pointe vers plusieurs valeurs. Par exemple, la variable de champ d'événement $e.target.ip est un champ répété et peut avoir zéro, une ou plusieurs valeurs IP. Il s'agit d'une valeur non scalaire. En revanche, la variable de champ d'événement $e.principal.hostname n'est pas un champ répété et ne comporte qu'une seule valeur (c'est-à-dire une valeur scalaire).

De même, les champs d'événements non répétés et les champs d'événements répétés utilisés dans la section de résultat d'une règle avec une fenêtre de correspondance ne sont pas des valeurs scalaires. Par exemple, la règle suivante regroupe les événements à l'aide d'une section de correspondance et fait référence à un champ d'événement non répété dans la section de résultat:

rule OutcomeAndMatchWindow{
  ...
  match:
    $userid over 5m
  outcome:
    $hostnames = array($e.principal.hostname)
  ...
}

Toute fenêtre de cinq minutes sur laquelle la règle s'exécute peut contenir zéro, un ou plusieurs événements. La section de résultat s'applique à tous les événements d'une fenêtre de correspondance. Toute variable de champ d'événement référencée dans la section de résultat peut pointer vers zéro, une ou plusieurs valeurs du champ pour chaque événement de la fenêtre de correspondance. Dans la règle précédente, si une fenêtre de cinq minutes contient cinq événements $e, $e.principal.hostname dans la section de résultat pointe vers cinq noms d'hôte différents. La variable de champ d'événement $e.principal.hostname est donc une valeur non scalaire dans la section de résultat de cette règle.

Étant donné que les variables de résultat doivent toujours générer une valeur scalaire unique, toute valeur non scalaire dont dépend une attribution de résultat doit être agrégée pour générer une valeur scalaire unique. Dans une section de résultat, les éléments suivants sont des valeurs non scalaires et doivent être agrégées:

• Champs d'événement (répétés ou non) lorsque la règle utilise une section de correspondance
• Espaces réservés pour des événements (répétés ou non) lorsque la règle utilise une section de correspondance
• Champs d'événement répétés lorsque la règle n'utilise pas de section de correspondance
• Espaces réservés aux événements répétés lorsque la règle n'utilise pas de section de correspondance

Les champs d'événements scalaires, les espaces réservés d'événements scalaires et les constantes peuvent être encapsulés dans une agrégation dans une règle qui n'utilise pas de section de correspondance. Cependant, la plupart des agrégations donnent la valeur encapsulée et sont donc inutiles. L'exception est l'agrégation array(), qui peut être utilisée pour convertir une valeur scalaire en tableau.

Les variables de résultat sont traitées comme des agrégations: elles ne doivent pas être réagrégées lorsqu'elles sont mentionnées dans une autre attribution de résultat.

Vous pouvez utiliser les fonctions d'agrégation suivantes:

• max(): renvoie la valeur maximale parmi toutes les valeurs possibles. Ne fonctionne qu'avec des nombres entiers et flottants.
• min(): renvoie la valeur minimale parmi toutes les valeurs possibles. Ne fonctionne qu'avec des nombres entiers et flottants.
• sum(): génère la somme de toutes les valeurs possibles. Ne fonctionne qu'avec des nombres entiers et flottants.
• count_distinct(): collecte toutes les valeurs possibles, puis génère le nombre distinct de valeurs possibles.
• count(): se comporte comme count_distinct(), mais renvoie un nombre non distinct de valeurs possibles.
• array_distinct(): collecte toutes les valeurs distinctes possibles, puis génère une liste de ces valeurs. Elle tronquera la liste des valeurs distinctes à 25 éléments aléatoires. La déduplication permettant d'obtenir une liste distincte est d'abord appliquée, puis la troncation.
• array(): se comporte comme array_distinct(), mais renvoie une liste de valeurs non distincte. Elle tronque également la liste des valeurs à 25 éléments aléatoires.

La fonction d'agrégation est importante lorsqu'une règle inclut une section condition spécifiant que plusieurs événements doivent exister, car la fonction d'agrégation s'exécute sur tous les événements qui ont généré la détection.

Par exemple, si vos sections outcome et condition contiennent:

outcome:
  $asset_id_count = count($event.principal.asset_id)
  $asset_id_distinct_count = count_distinct($event.principal.asset_id)

  $asset_id_list = array($event.principal.asset_id)
  $asset_id_distinct_list = array_distinct($event.principal.asset_id)

condition:
  #event > 1

Étant donné que la section de condition nécessite la présence de plusieurs event pour chaque détection, les fonctions d'agrégation fonctionnent sur plusieurs événements. Supposons que les événements suivants aient généré une détection:

event:
  // UDM event 1
  asset_id="asset-a"

event:
  // UDM event 2
  asset_id="asset-b"

event:
  // UDM event 3
  asset_id="asset-b"

Les valeurs de vos résultats seront les suivantes:

• $asset_id_count = 3
• $asset_id_distinct_count = 2
• $asset_id_list = ["asset-a", "asset-b", "asset-b"]
• $asset_id_distinct_list = ["asset-a", "asset-b"]

Points à retenir concernant l'utilisation de la section "Résultats" :

Autres remarques et restrictions:

• La section outcome ne peut pas faire référence à une nouvelle variable d'espace réservé qui n'a pas déjà été définie dans la section events ni dans la section outcome.
• La section outcome ne peut pas utiliser de variables d'événement qui n'ont pas été définies dans la section events.
• La section outcome peut utiliser un champ d'événement qui n'était pas utilisé dans la section events, étant donné que la variable d'événement à laquelle appartient le champ d'événement était déjà définie dans la section events.
• La section outcome ne peut mettre en corrélation que des variables d'événement déjà corrélées dans la section events. Des corrélations se produisent lorsque deux champs d'événement provenant de différentes variables d'événement sont mis en correspondance.

Vous trouverez un exemple à l'aide de la section de résultat dans la présentation de YARA-L 2.0. Pour en savoir plus sur la détection en double avec la section de résultat, consultez Créer des analyses contextuelles.

Syntaxe de la section de condition

• Spécifiez une condition de correspondance pour les événements et les espaces réservés définis dans la section events. Pour en savoir plus, consultez la section suivante, Conditions d'événements et d'espaces réservés.
• (Facultatif) Utilisez le mot clé and pour spécifier une condition de correspondance à l'aide de variables de résultat définies dans la section outcome. Pour en savoir plus, consultez la section suivante, Conditions de résultat.

Compter le caractère

Le caractère # est un caractère spécial dans la section condition. S'il est utilisé avant tout nom de variable d'événement ou d'espace réservé, il représente le nombre d'événements ou de valeurs distincts qui remplissent toutes les conditions de la section events.

Par exemple, #c > 1 signifie que la variable c doit apparaître plusieurs fois.

Caractère de la valeur

Le caractère $ est un caractère spécial dans la section condition. S'il est utilisé avant un nom de variable de résultat, il représente la valeur de ce résultat.

S'il est utilisé avant tout nom de variable d'événement ou d'espace réservé (par exemple, $event), il représente #event > 0.

Expressions conditionnelles pour les événements et les espaces réservés

Répertoriez ici les prédicats de condition pour les événements et les variables d'espace réservé, joints au mot clé and ou or. Le mot clé and peut être utilisé entre toutes les conditions, mais le mot clé or ne peut être utilisé que lorsque la règle ne comporte qu'une seule variable d'événement.

Voici un exemple valide d'utilisation de or entre deux espaces réservés sur le même événement:

rule ValidConditionOr {
  meta:
  events:
      $e.metadata.event_type = "NETWORK_CONNECTION"

      // Note that all placeholders use the same event variable.
      $ph = $e.principal.user.userid  // Define a placeholder variable to put in match section.
      $ph2 = $e.principal.ip  // Define a second placeholder variable to put in condition section.
      $ph3 = $e.principal.hostname  // Define a third placeholder variable to put in condition section.

  match:
    $ph over 5m

  condition:
    $ph2 or $ph3
}

Exemple non valide d'utilisation de or entre deux conditions sur des événements différents:

rule InvalidConditionOr {
  meta:
  events:
      $e.metadata.event_type = "NETWORK_CONNECTION"
      $e2.graph.metadata.entity_type = "FILE"
      $e2.graph.entity.hostname  = $e.principal.hostname

      $ph = $e.principal.user.userid  // Define a placeholder variable to put in match section.

  match:
    $ph over 5m

  condition:
    $e or $e2 // This line will cause an error because there is an or between events.
}

Remarque :N'utilisez pas le mot clé not dans les conditions d'événement et d'espace réservé.

Conditions limitées et illimitées

Les conditions suivantes sont limitées. Ils forcent l'existence de la variable d'événement associée, ce qui signifie qu'au moins une occurrence de l'événement doit apparaître dans toute détection.

• $var // equivalent to #var > 0
• #var > n // where n >= 0
• #var >= m // where m > 0

Les conditions suivantes sont illimitées. Ils permettent à la variable d'événement associée de ne pas exister, ce qui signifie qu'il est possible qu'aucune occurrence de l'événement n'apparaisse dans une détection. De plus, toute référence à des champs de la variable d'événement donnera une valeur nulle. Les conditions illimitées permettent de détecter l'absence d'événement sur une période donnée. Par exemple, un événement de menace sans événement d'atténuation dans une fenêtre de 10 minutes. Les règles qui utilisent des conditions illimitées sont appelées "règles de non-existence".

• !$var // equivalent to #var = 0
• #var >= 0
• #var < n // where n > 0
• #var <= m // where m >= 0

Remarque :Pour les règles inexistantes, le moteur de détection ajoute un délai d'une heure à la latence attendue (en fonction de la fréquence d'exécution de la règle) pour autoriser les données tardives.

Conditions requises pour l'inexistence

Pour qu'une règle inexistante puisse être compilée, elle doit répondre aux exigences suivantes:

1. Au moins un événement UDM doit avoir une condition limitée (c'est-à-dire qu'au moins un événement UDM doit exister).
2. Si un espace réservé a une condition illimitée, il doit être associé à au moins un événement UDM limité.
3. Si une entité présente une condition illimitée, elle doit être associée à au moins un événement UDM limité.

Prenons l'exemple de la règle suivante, dans laquelle la section "condition" est omise:

rule NonexistenceExample {
  meta:
  events:
      $u1.metadata.event_type = "NETWORK_CONNECTION" // $u1 is a UDM event.
      $u2.metadata.event_type = "NETWORK_CONNECTION" // $u2 is a UDM event.
      $e1.graph.metadata.entity_type = "FILE"        // $e1 is an Entity.
      $e2.graph.metadata.entity_type = "FILE"        // $e2 is an Entity.

      $user = $u1.principal.user.userid // Match variable is required for Multi-Event Rule.

      // Placeholder Associations:
      //   u1        u2 
      //   |  \    /
      // port   ip
      //   |       \
      //   e1        e2
      $u1.target.port = $port
      $e1.graph.entity.port = $port
      $u1.principal.ip = $ip
      $u2.target.ip = $ip
      $e2.graph.entity.ip = $ip

      // UDM-Entity Associations:
      // u1 - u2
      // |  \  |
      // e1   e2
      $u1.metadata.event_type = $u2.metadata.event_type
      $e1.graph.entity.hostname = $u1.principal.hostname
      $e2.graph.entity.hostname = $u1.target.hostname
      $e2.graph.entity.hostname = $u2.principal.hostname

  match:
    $user over 5m

  condition:
      <condition_section>
}

Voici des exemples valides pour <condition_section>:

• $u1 and !$u2 and $e1 and $e2
  • Tous les événements et entités UDM sont présents dans la section "Condition".
  • Au moins un événement UDM est limité.
• $u1 and !$u2 and $e1 and !$e2
  • $e2 est illimité, ce qui est autorisé, car il est associé à $u1, qui est limité. Si $e2 n'était pas associé à $u1, ce serait non valide.
• #port > 50 and #ip = 0
  • La section "Condition" ne contient aucun événement ni aucune entité UDM. Toutefois, les espaces réservés présents couvrent l'ensemble des événements et entités UDM.
  • $ip est attribué à la fois à $u1 et à $u2, et #ip = 0 est une condition illimitée. Cependant, les conditions limitées sont plus solides que les conditions illimitées. Étant donné que $port est attribué à $u1 et que #port > 50 est une condition limitée, $u1 l'est toujours.

Voici des exemples non valides pour <condition_section>:

• $u1 and $e1
  • Chaque événement et entité UDM apparaissant dans la section "Events" (Événements) doit apparaître dans la section "Condition" (ou disposer d'un espace réservé qui s'affiche dans la section "Condition").
• $u1, $u2, $e1, $u2, #port > 50
  • Les virgules ne sont pas autorisées en tant que séparateurs de conditions.
• !$u1 and !$u2 and $e1 and $e2
  • Cette règle ne respecte pas la première condition selon laquelle au moins un événement UDM doit être limité.
• ($u1 or #port < 50) and $u2 and $e1 and $e2
  • Le mot clé or n'est pas compatible avec les conditions illimitées.
• ($u1 or $u2) and $e1 and $e2
  • Le mot clé or n'est pas accepté entre différentes variables d'événement.
• not $u1 and $u2 and $e1 and $e2
  • Le mot clé not n'est pas autorisé pour les conditions d'événement et d'espace réservé.
• #port < 50 and #ip = 0
  • Les espaces réservés présents couvrent l'ensemble des événements et entités UDM. Cependant, toutes les conditions sont illimitées. Cela signifie qu'aucun des événements UDM n'est limité, ce qui entraîne l'échec de la compilation de la règle.

Remarque :N'utilisez pas de variable match dans la section condition. Il s'agit d'une erreur sémantique, car les événements sont regroupés en fonction de la valeur de la variable match.

Remarque :Ne spécifiez pas uniquement des conditions illimitées sur toutes les variables event auxquelles une variable match est attribuée. Il s'agit d'une erreur sémantique. Pour qu'une valeur de variable match soit renvoyée, au moins un événement doit exister qui la contient.

Remarque :Si vous utilisez une fenêtre glissante, la variable d'événement de tableau croisé dynamique doit être impliquée dans au moins une condition limitée.

Conditions de résultat

Répertoriez ici les prédicats de condition pour les variables de résultat, associés au mot clé and ou or, ou précédés du mot clé not.

Spécifiez les conditions de résultat différemment en fonction du type de variable de résultat:

• integer: la comparaison avec un littéral entier avec les opérateurs =, >, >=, <, <=, !=. Exemple:

  $risk_score > 10

• float: compare avec un littéral à virgule flottante avec les opérateurs =, >, >=, <, <=, !=, par exemple:

  $risk_score <= 5.5

• string: comparaison avec un littéral de chaîne avec = ou !=, par exemple:

  $severity = "HIGH"

• liste d'entiers ou de tableaux: spécifiez la condition à l'aide de la fonction arrays.contains. Par exemple:

  arrays.contains($event_ids, "id_1234")

Remarque :Si vous utilisez le mot clé or dans la sous-section <event/placeholder conditions>, vous devez placer l'intégralité de la sous-section entre parenthèses. L'exemple suivant est valide: ($e1 or $e2) and $outcome > 0.

Classification des règles

Si vous spécifiez un résultat sous condition dans une règle comportant une section de correspondance, la règle sera classée en tant que règle multi-événements pour le quota de règles. Pour en savoir plus sur la classification d'un seul et de plusieurs événements, consultez Règle pour un seul événement et Règle pour plusieurs événements.

Syntaxe de la section "Options"

Dans la section options, vous pouvez spécifier les options de la règle. Voici un exemple de spécification de la section des options:

rule RuleOptionsExample {
  // Other rule sections

  options:
    allow_zero_values = true
}

Vous pouvez spécifier les options à l'aide de la syntaxe key = value, où key doit être un nom d'option prédéfini et value une valeur valide pour l'option, comme indiqué pour les options suivantes:

allow_zero_values

Les valeurs valides pour cette option sont true et false, qui déterminent si cette option est activée ou non. La valeur par défaut est false. Cette option est désactivée si elle n'est pas spécifiée dans la règle.

Pour activer ce paramètre, ajoutez le code suivant à la section des options de votre règle: allow_zero_values = true. Cela empêcherait la règle de filtrer implicitement les valeurs nulles des espaces réservés utilisés dans la section de correspondance, comme décrit dans la section Gérer une valeur nulle dans la section de correspondance.

Expressions booléennes

Les expressions booléennes sont des expressions de type booléen.

Comparaisons

Pour qu'une expression binaire soit utilisée comme condition, utilisez la syntaxe suivante:

• <EXPR> <OP> <EXPR>

L'expression peut être un champ d'événement, une variable, un littéral ou une expression de fonction.

Exemple :

• $e.source.hostname = "host1234"
• $e.source.port < 1024
• 1024 < $e.source.port
• $e1.source.hostname != $e2.target.hostname
• $e1.metadata.collected_timestamp.seconds > $e2.metadata.collected_timestamp.seconds
• $port >= 25
• $host = $e2.target.hostname
• "google-test" = strings.concat($e.principal.hostname, "-test")
• "[e-mail]" = re.replace($e.network.email.from, "com", "org")

Si les deux côtés sont des littéraux, cela est considéré comme une erreur de compilation.

Fonctions

Certaines expressions de fonction renvoient une valeur booléenne, qui peut être utilisée comme prédicat individuel dans la section events. Il s'agit des fonctions suivantes:

• re.regex()
• net.ip_in_range_cidr()

Exemple :

• re.regex($e.principal.hostname, `.*\.google\.com`)
• net.ip_in_range_cidr($e.principal.ip, "192.0.2.0/24")

Expressions de liste de référence

Vous pouvez utiliser des listes de référence dans la section "Événements". Pour en savoir plus, consultez la section Listes de référence.

Expressions logiques

Vous pouvez utiliser les opérateurs logiques and et or dans la section events, comme indiqué dans les exemples suivants:

• $e.metadata.event_type = "NETWORK_DNS" or $e.metadata.event_type = "NETWORK_DHCP"
• ($e.metadata.event_type = "NETWORK_DNS" and $e.principal.ip = "192.0.2.12") or ($e.metadata.event_type = "NETWORK_DHCP" and $e.principal.mac = "AB:CD:01:10:EF:22")
• not $e.metadata.event_type = "NETWORK_DNS"

Par défaut, l'ordre de priorité, du plus élevé au plus bas, est not, and, or.

Par exemple, "a, b et c" est évalué comme "a ou (b et c)" lorsque les opérateurs or et and sont définis explicitement dans l'expression.

Dans la section events, les prédicats sont joints à l'aide de l'opérateur and si aucun opérateur n'est explicitement défini.

L'ordre d'évaluation peut être différent si l'opérateur and est implicite dans l'expression.

Prenons l'exemple des expressions de comparaison suivantes, dans lesquelles or est défini explicitement. L'opérateur and est implicite.

$e1.field = "bat"
or $e1.field = "baz"
$e2.field = "bar"

Cet exemple est interprété comme suit:

($e1.field = "bat" or $e1.field = "baz")
and ($e2.field = "bar")

Comme or est défini explicitement, les prédicats qui entourent or sont regroupés et évalués en premier. Le dernier prédicat, $e2.field = "bar", est joint implicitement à l'aide de and. Résultat : l'ordre de l'évaluation change.

Remarque :Le nombre de valeurs and et or que vous pouvez spécifier pour une seule règle est limité. Cette limite varie en fonction de la complexité de la règle et des données de votre compte Google Security Operations. Contactez votre représentant Google Security Operations pour en savoir plus sur les alternatives à ce type de règles.

Types énumérés

Vous pouvez utiliser les opérateurs avec des types énumérés. Il peut être appliqué aux règles pour simplifier et optimiser les performances (en utilisant un opérateur plutôt que des listes de référence).

Dans l'exemple suivant, "USER_UNCATEGORIZED" et "USER_RESOURCE_DELETION" correspondent à 15000 et 15014, la règle recherche donc tous les événements répertoriés:

$e.metadata.event_type >= "USER_CATEGORIZED" and $e.metadata.event_type <= "USER_RESOURCE_DELETION"

Liste des événements:

• USER_RESOURCE_DELETION
• USER_RESOURCE_UPDATE_CONTENT
• USER_RESOURCE_UPDATE_PERMISSIONS
• USER_STATS
• USER_UNCATEGORIZED

Modificateur Nocase

Lorsque vous utilisez une expression de comparaison entre des valeurs de chaîne ou une expression régulière, vous pouvez ajouter "nocase" à la fin de l'expression pour ignorer les majuscules.

• $e.principal.hostname != "http-server" nocase
• $e1.principal.hostname = $e2.target.hostname nocase
• $e.principal.hostname = /dns-server-[0-9]+/ nocase
• re.regex($e.target.hostname, `client-[0-9]+`) nocase

Il ne peut pas être utilisé lorsqu'un type de champ est une valeur énumérée. Les exemples suivants ne sont pas valides et généreront des erreurs de compilation:

• $e.metadata.event_type = "NETWORK_DNS" nocase
• $e.network.ip_protocol = "TCP" nocase

Champs répétés

Dans le modèle de données unifié (UDM), certains champs sont étiquetés comme répétés, ce qui indique qu'il s'agit de listes de valeurs ou d'autres types de messages.

Champs répétés et expressions booléennes

Il existe deux types d'expressions booléennes qui agissent sur des champs répétés:

1. Modifié
2. Non modifié

Considérez l'événement suivant:

event_original {
  principal {
    // ip is a repeated field
    ip: [ "192.0.2.1", "192.0.2.2", "192.0.2.3" ]

    hostname: "host"
  }
}

Expressions modifiées

Les sections suivantes décrivent l'objectif et l'utilisation des modificateurs any et all dans les expressions.

toutes

Si n'importe quel élément du champ répété remplit la condition, l'événement dans son ensemble satisfait à la condition.

• event_original est conforme à any $e.principal.ip = "192.0.2.1".
• Échec de event_original : any $e.repeated_field.field_a = "9.9.9.9.

tous

Si tous les éléments du champ répété satisfont à la condition, l'événement dans son ensemble y répond.

• event_original est conforme à net.ip_in_range_cidr(all $e.principal.ip, "192.0.2.0/8").
• Échec de event_original : all $e.principal.ip = "192.0.2.2".

Remarque :Pour utiliser any ou all avec une fonction, le modificateur doit précéder le champ répété et non la fonction. Par exemple, re.regex(any $e.about.hostname, `server-[0-9]+`) est valide, mais pas any re.regex($e.about.hostname, `server-[0-9]+`).

Lorsque vous écrivez une condition avec any ou all, sachez que l'annulation de la condition avec not peut ne pas avoir la même signification que l'utilisation de l'opérateur inversé.

Exemple :

• not all $e.principal.ip = "192.168.12.16" vérifie si toutes les adresses IP ne correspondent pas à 192.168.12.16, ce qui signifie que la règle vérifie si au moins une adresse IP ne correspond pas à 192.168.12.16.
• all $e.principal.ip != "192.168.12.16" vérifie si toutes les adresses IP ne correspondent pas à 192.168.12.16, ce qui signifie que la règle vérifie qu'aucune adresse IP ne correspond à 192.168.12.16.

Contraintes:

• Les opérateurs any et all ne sont compatibles qu'avec les champs répétés (et non avec les champs scalaires).
• any et all ne peuvent pas être utilisés pour joindre deux champs répétés. Par exemple, any $e1.principal.ip = $e2.principal.ip n'est pas valide.
• Les opérateurs any et all ne sont pas compatibles avec l'expression de la liste de référence.

Expressions non modifiées

Avec les expressions non modifiées, chaque élément du champ répété est traité individuellement. Si le champ répété d'un événement contient n éléments, la règle est appliquée sur n copies de l'événement, chaque copie contenant l'un des éléments du champ répété. Ces copies sont temporaires et ne sont pas stockées.

La règle est appliquée aux copies suivantes:

copie d'événement	principal.ip	principal.hostname
event_copy_1	"192.0.2.1"	"hôte"
event_copy_2	"192.0.2.2"	"hôte"
event_copy_3	"192.0.2.3"	"hôte"

Si n'importe quelle copie d'événement remplit toutes les conditions non modifiées du champ répété, l'événement dans son ensemble remplit toutes les conditions. Cela signifie que si un champ répété comporte plusieurs conditions, la copie de l'événement doit remplir toutes ces conditions. Les exemples de règles suivants utilisent l'exemple d'ensemble de données précédent pour illustrer ce comportement.

La règle suivante renvoie une correspondance lorsqu'elle est exécutée sur l'exemple d'ensemble de données event_original, car event_copy_1 remplit tous les prédicats d'événements:

rule repeated_field_1 {
  meta:
  events:
    net.ip_in_range_cidr($e.principal.ip, "192.0.2.0/8") // Checks if IP address matches 192.x.x.x
    $e.principal.ip = "192.0.2.1"
  condition:
    $e
}

La règle suivante ne renvoie pas de correspondance lorsqu'elle est exécutée sur l'exemple d'ensemble de données event_original, car il n'existe aucune copie d'événement dans $e.principal.ip satisfaisant à tous les prédicats d'événement.

rule repeated_field_2 {
  meta:
  events:
    $e.principal.ip = "192.0.2.1"
    $e.principal.ip = "192.0.2.2"
  condition:
    $e
}

Les expressions modifiées sur des champs répétés sont compatibles avec les expressions non modifiées sur ces champs, car la liste des éléments est identique pour chaque copie d'événement. Prenons la règle suivante:

rule repeated_field_3 {
  meta:
  events:
    any $e.principal.ip = "192.0.2.1" 
    $e.principal.ip = "192.0.2.3"
  condition:
    $e
}

La règle est appliquée aux copies suivantes:

copie d'événement	principal.ip	tout $e.principal.ip
event_copy_1	"192.0.2.1"	["192.0.2.1", "192.0.2.2", "192.0.2.3"]
event_copy_2	"192.0.2.2"	["192.0.2.1", "192.0.2.2", "192.0.2.3"]
event_copy_3	"192.0.2.3"	["192.0.2.1", "192.0.2.2", "192.0.2.3"]

Dans ce cas, toutes les copies répondent à any $e.principal.ip = "192.0.2.1", mais seule event_copy_3 satisfait à $e.principal.ip = "192.0.2.3". Par conséquent, l'événement dans son ensemble correspond.

Voici une autre façon d'envisager ces types d'expressions:

• Les expressions sur des champs répétés qui utilisent any ou all opèrent sur la liste dans event_original.
• Les expressions sur des champs répétés qui n'utilisent pas any ni all fonctionnent sur des événements event_copy_n individuels.

Champs et espaces réservés répétés

Les champs répétés fonctionnent avec les attributions d'espaces réservés. Comme pour les expressions non modifiées sur des champs répétés, une copie de l'événement est créée pour chaque élément. Pour reprendre l'exemple de event_copy, l'espace réservé prend la valeur de la valeur du champ répété de event_copy_n, pour chacune des copies d'événements où n correspond au numéro de copie de l'événement. Si l'espace réservé est utilisé dans la section des correspondances, plusieurs correspondances peuvent être trouvées.

L'exemple suivant génère une correspondance. L'espace réservé $ip est égal à 192.0.2.1 pour event_copy_1, ce qui satisfait les prédicats de la règle. Les exemples d'événements de la correspondance contiennent un seul élément, event_original.

// Generates 1 match.
rule repeated_field_placeholder1 {
  meta:
  events:
    $ip = $e.principal.ip
    $ip = "192.0.2.1"
    $host = $e.principal.hostname

  match:
    $host over 5m

  condition:
    $e
}

L'exemple suivant génère trois correspondances. L'espace réservé $ip correspond à différentes valeurs pour chacune des copies event_copy_n. Le regroupement est effectué sur $ip, car il se trouve dans la section des correspondances. Par conséquent, vous obtenez trois correspondances, chacune ayant une valeur différente pour la variable de correspondance $ip. Chaque correspondance dispose du même exemple d'événement: un seul élément, event_original.

// Generates 3 matches.
rule repeated_field_placeholder2 {
  meta:
  events:
    $ip = $e.principal.ip
    net.ip_in_range_cidr($ip, "192.0.2.0/8") // Checks if IP matches 192.x.x.x

  match:
    $ip over 5m

  condition:
    $e
}

Remarque :any et all ne peuvent pas être utilisés lors de l'attribution d'un champ répété à une variable d'espace réservé ou lors d'une jointure avec un champ d'un autre événement. Par exemple, any $e.principal.ip = $ip n'est pas valide.

Résultats utilisant des espaces réservés attribués à des champs répétés

Les espaces réservés sont attribués à chaque élément de chaque champ répété, et non à la liste entière. Ainsi, lorsqu'ils sont utilisés dans la section des résultats, le résultat est calculé en n'utilisant que les éléments qui ont satisfait aux sections précédentes.

Prenons la règle suivante:

rule outcome_repeated_field_placeholder {
  meta:
  events:
    $ip = $e.principal.ip
    $ip = "192.0.2.1" or $ip = "192.0.2.2"
    $host = $e.principal.hostname

  match:
    $host over 5m

  outcome:
    $o = array_distinct($ip)

  condition:
    $e
}

Cette règle comporte quatre étapes d'exécution. La première étape est la copie des événements:

copie d'événement	$ip	$host	$e
event_copy_1	"192.0.2.1"	"hôte"	event_id
event_copy_2	"192.0.2.2"	"hôte"	event_id
event_copy_3	"192.0.2.3"	"hôte"	event_id

La section "Events" (Événements) exclut alors les lignes qui ne correspondent pas aux filtres:

copie d'événement	$ip	$host	$e
event_copy_1	"192.0.2.1"	"hôte"	event_id
event_copy_2	"192.0.2.2"	"hôte"	event_id

event_copy_3 est exclu, car "192.0.2.3" ne répond pas aux exigences de $ip = "192.0.2.1" or $ip = "192.0.2.2".

La section de correspondance regroupe ensuite par variables de correspondance et la section de résultat effectue une agrégation sur chaque groupe:

$host	o $	$e
"hôte"	["192.0.2.1", "192.0.2.2"]	event_id

Le calcul de $o = array_distinct($ip) utilise les $ip de l'étape précédente et non l'étape de copie de l'événement.

Enfin, la section des conditions filtrera chaque groupe. Étant donné que cette règle ne vérifie que l'existence de $e, la ligne précédente produira une seule détection.

$o ne contient pas tous les éléments de $e.principal.ip, car certains éléments ne remplissent pas toutes les conditions de la section des événements. Cependant, tous les éléments de e.principal.ip apparaîtront dans l'exemple d'événement, car celui-ci utilise event_original.

Indexation de tableau

Vous pouvez effectuer une indexation de tableau sur des champs répétés. Pour accéder au n-ième élément de champ répété, utilisez la syntaxe de liste standard (les éléments sont indexés par le zéro). Un élément hors limites renvoie la valeur par défaut.

• $e.principal.ip[0] = "192.168.12.16"
• $e.principal.ip[999] = "" : si le nombre d'éléments est inférieur à 1 000, la valeur est true.

Contraintes:

• Un index doit être un littéral entier non négatif. Par exemple, $e.principal.ip[-1] n'est pas valide.
• Les valeurs de type int (par exemple, un espace réservé défini sur int) ne comptent pas.
• L'indexation de tableau ne peut pas être combinée avec any ou all. Par exemple, any $e.intermediary.ip[0] n'est pas valide.
• L'indexation de tableau ne peut pas être combinée à la syntaxe de mappage. Par exemple, $e.additional.fields[0]["key"] n'est pas valide.
• Si le chemin d'accès du champ contient plusieurs champs répétés, ils doivent tous utiliser l'indexation de tableau. Par exemple, $e.intermediary.ip[0] n'est pas valide, car intermediary et ip sont des champs répétés, alors qu'il n'existe qu'un index pour ip.

Messages répétés

Lorsqu'un champ message est répété, l'effet imprévu est de réduire la probabilité d'une correspondance. Ce processus est illustré dans les exemples suivants.

Considérez l'événement suivant:

event_repeated_message {
  // about is a repeated message field.
  about {
    // ip is a repeated string field.
    ip: [ "192.0.2.1", "192.0.2.2", "192.0.2.3" ]

    hostname: "alice"
  }
  about {
    hostname: "bob"
  }
}

Comme indiqué pour les expressions non modifiées sur des champs répétés, une copie temporaire de l'événement est créée pour chaque élément du champ répété. Prenons la règle suivante:

rule repeated_message_1 {
  meta:
  events:
    $e.about.ip = "192.0.2.1" 
    $e.about.hostname = "bob"
  condition:
    $e
}

La règle est appliquée aux copies suivantes:

copie d'événement	about.ip	about.hostname
event_copy_1	"192.0.2.1"	"alice"
event_copy_2	"192.0.2.2"	"alice"
event_copy_3	"192.0.2.3"	"alice"
event_copy_4	""	"bob"

L'événement ne correspond pas à la règle, car il n'existe aucune copie d'événement répondant à toutes les expressions.

Messages répétés et indexation de tableaux

Un autre comportement inattendu peut se produire lors de l'utilisation de l'indexation de tableau avec des expressions non modifiées sur des champs de message répétés. Prenons l'exemple de règle suivant qui utilise l'indexation de tableau:

rule repeated_message_2 {
  meta:
  events:
    $e.about.ip = "192.0.2.1" 
    $e.about[1].hostname = "bob"
  condition:
    $e
}

La règle s'applique aux copies suivantes:

copie d'événement	about.ip	about[1].nom d'hôte
event_copy_1	"192.0.2.1"	"bob"
event_copy_2	"192.0.2.2"	"bob"
event_copy_3	"192.0.2.3"	"bob"
event_copy_4	""	"bob"

Étant donné que event_copy_1 remplit toutes les expressions de repeated_message_2, l'événement correspond à la règle.

Cela peut entraîner un comportement inattendu, car la règle repeated_message_1 manquait d'indexation de tableau et n'a généré aucune correspondance, tandis que la règle repeated_message_2 utilisait l'indexation de tableau et générait une correspondance.

Commentaires

Pour spécifier des commentaires à l'aide de deux barres obliques (// comment) ou de commentaires sur plusieurs lignes, utilisez des barres obliques astérisques (/* comment */), comme vous le feriez dans C.

Littéraux

Les nombres entiers et flottants non négatifs, les littéraux de chaîne, booléens et les expressions régulières sont acceptés.

Littéraux de chaîne et d'expression régulière

Vous pouvez utiliser l'un des guillemets suivants pour délimiter les chaînes dans YARA-L 2.0. Cependant, le texte des messages précédents est interprété différemment selon celui que vous utilisez.

1. Guillemets doubles (") : pour les chaînes normales. Doit inclure des caractères d'échappement.
   Exemple: "hello\tworld" —\t est interprété comme une tabulation

2. Guillemets arrière (`) : permet d'interpréter tous les caractères littéralement.
   Exemple : "hello\tworld" —\t n'est pas interprété comme une tabulation

Pour les expressions régulières, deux options s'offrent à vous.

Si vous souhaitez utiliser des expressions régulières directement sans la fonction re.regex(), utilisez /regex/ pour les littéraux d'expression régulière.

Vous pouvez également utiliser des littéraux de chaîne en tant que littéraux d'expression régulière lorsque vous utilisez la fonction re.regex(). Notez que pour les littéraux de chaîne entre guillemets doubles, vous devez échapper les barres obliques inverses par des barres obliques inverses, ce qui peut sembler gênant.

Par exemple, les expressions régulières suivantes sont équivalentes:

• re.regex($e.network.email.from, `.*altostrat\.com`)
• re.regex($e.network.email.from, ".*altostrat\\.com")
• $e.network.email.from = /.*altostrat\.com/

Google recommande d'utiliser des guillemets pour les chaînes des expressions régulières afin d'améliorer la lisibilité.

Opérateurs

Vous pouvez utiliser les opérateurs suivants dans YARA-L:

Opérateur	Description
=	égal/déclaration
!=	différent
<	inférieur à
<=	inférieur ou égal à
>	supérieur à
>=	supérieur(e) ou égal(e) à

Variables

Dans YARA-L 2.0, toutes les variables sont représentées par $<variable name>.

Vous pouvez définir les types de variables suivants:

• Variables d'événements : représentent des groupes d'événements sous forme normalisée (UDM) ou des événements d'entité. Spécifiez les conditions des variables d'événements dans la section events. Vous identifiez les variables d'événements à l'aide d'un nom, d'une source d'événement et de champs d'événement. Les sources autorisées sont udm (pour les événements normalisés) et graph (pour les événements d'entité). Si la source est omise, udm est défini comme source par défaut. Les champs d'événement sont représentés par une chaîne .<nom du champ> (par exemple, $e.field1.field2). Les chaînes de champs d'événement commencent toujours à partir de la source de premier niveau (UDM ou entité).

• Faites correspondre les variables : déclarez-les dans la section match. Les variables de correspondance deviennent des champs de regroupement pour la requête, car une ligne est renvoyée pour chaque ensemble unique de variables de correspondance (et pour chaque fenêtre temporelle). Lorsque la règle trouve une correspondance, les valeurs des variables correspondantes sont renvoyées. Spécifiez ce que chaque variable de correspondance représente dans la section events.

• Variables d'espace réservé : déclarez et définissez-les dans la section events. Les variables d'espace réservé sont semblables aux variables de correspondance. Toutefois, vous pouvez utiliser des variables d'espace réservé dans la section condition pour spécifier des conditions de correspondance.

Remarque :Chaque variable d'espace réservé doit être mappée à un champ d'événement. Par exemple, si vous n'avez référencé que l'espace réservé suivant dans cette seule ligne d'une règle, la compilation échouerait, car $var n'est pas lié à une variable d'événement: $e.field != $var

Utilisez les variables de correspondance et les variables d'espace réservé pour déclarer des relations entre les champs d'événement via des conditions de jointure transitive (pour en savoir plus, consultez la section Syntaxe de la section des événements).

Mots clés

Dans YARA-L 2.0, les mots clés ne sont pas sensibles à la casse. Par exemple, and ou AND sont équivalents. Les noms des variables ne doivent pas entrer en conflit avec les mots clés. Par exemple, $AND ou $outcome n'est pas valide.

Voici les mots clés associés aux règles de moteur de détection: rule, meta, match, over, events, condition, outcome, options, and, or, not, nocase, in, regex, cidr, before, after, all, any, if, match, match, match, match, match, matchmaxminsumarrayarray_distinctcountcount_distinctisnull

Maps

YARA-L prend en charge l'accès aux cartes pour les objets Struct et les Libellés.

Structures et étiquettes

Certains champs UDM utilisent le type de données Struct ou Label.

Pour rechercher une paire clé-valeur spécifique dans Struct et Label, utilisez la syntaxe de mappage standard:

// A Struct field.
$e.udm.additional.fields["pod_name"] = "kube-scheduler"
// A Label field.
$e.metadata.ingestion_labels["MetadataKeyDeletion"] = "startup-script"

L'accès à la carte renvoie toujours une chaîne.

Cas acceptés

Section Événements et résultats

// Using a Struct field in the events section
events:
  $e.udm.additional.fields["pod_name"] = "kube-scheduler"

// Using a Label field in the outcome section
outcome:
  $value = array_distinct($e.metadata.ingestion_labels["MetadataKeyDeletion"])

Attribuer une valeur de carte à un espace réservé

$placeholder = $u1.metadata.ingestion_labels["MetadataKeyDeletion"]

Utiliser un champ de mappage dans une condition de jointure

// using a Struct field in a join condition between two udm events $u1 and $u2
$u1.metadata.event_type = $u2.udm.additional.fields["pod_name"]

Demandes non prises en charge

Les cartes ne sont pas acceptées dans les cas suivants.

Combiner les mots clés any ou all avec une carte

Par exemple, les éléments suivants ne sont pas acceptés:

all $e.udm.additional.fields["pod_name"] = "kube-scheduler"

Autres types de valeurs

La syntaxe de la carte ne peut renvoyer qu'une valeur de chaîne. Dans le cas des types de données Struct, la syntaxe de mappage ne peut accéder qu'aux clés dont les valeurs sont des chaînes. Il est impossible d'accéder à des clés dont les valeurs sont d'autres types primitifs, tels que des entiers.

Traitement des valeurs en double

Les accès à la carte renvoient toujours une valeur unique. Dans le cas inhabituel où l'accès à la carte pourrait faire référence à plusieurs valeurs, l'accès à la carte renvoie de manière déterministe la première valeur.

Cela peut se produire dans les cas suivants:

• Une étiquette comporte une clé en double.

  La structure des étiquettes représente un mappage, mais n'impose pas l'unicité des clés. Par convention, un mappage doit posséder des clés uniques. Google Security Operations ne recommande donc pas de renseigner des clés en double dans un libellé.

  Le texte de règle $e.metadata.ingestion_labels["dupe-key"] renvoie la première valeur possible, val1, s'il est exécuté sur l'exemple de données suivant:

  // Disrecommended usage of label with a duplicate key:
  event {
    metadata{
      ingestion_labels{
        key: "dupe-key"
        value: "val1" // This is the first possible value for "dupe-key"
      }
      ingestion_labels{
        key: "dupe-key"
        value: "val2"
      }
    }
  }
  

• Un libellé possède un champ répété ancêtre.

  Un champ répété peut contenir un libellé en tant que champ enfant. Deux entrées différentes dans le champ répété de premier niveau peuvent contenir des libellés ayant la même clé. Le texte de règle $e.security_result.rule_labels["key"] renverrait la première valeur possible, val3, s'il est exécuté sur l'exemple de données suivant:

  event {
    // security_result is a repeated field.
    security_result {
      threat_name: "threat1"
      rule_labels {
        key: "key"
        value: "val3" // This is the first possible value for "key"
      }
    }
    security_result {
      threat_name: "threat2"
      rule_labels {
        key: "key"
        value: "val4"
      }
    }
  }
  

Fonctions

Cette section décrit les fonctions YARA-L 2.0 que vous pouvez utiliser dans les règles de moteur de détection et la recherche.

Remarque :L'utilisation de la variable d'événement $e est facultative lorsque YARA-L est utilisé dans la recherche. principal.hostname et $e.principal.hostname sont tous deux acceptés dans la recherche.

Ces fonctions peuvent être utilisées dans les parties suivantes d'une règle YARA-L:

• Section events.
• BOOL_CLAUSE d'une condition dans la section des résultats.

arrays.length

Compatible avec:

Règles Rechercher

arrays.length(repeatedField)

Description

Renvoie le nombre d'éléments de champ répétés.

Types de données des paramètres

LIST

Type renvoyé

NUMBER

Exemples de code

Exemple 1

Renvoie le nombre d'éléments de champ répétés.

arrays.length($e.principal.ip) = 2

Exemple 2

Si plusieurs champs répétés se trouvent le long du chemin, renvoie le nombre total d'éléments de champs répétés.

arrays.length($e.intermediary.ip) = 3

fingerprint

Compatible avec:

Règles

hash.fingerprint2011(byteOrString)

Description

Cette fonction calcule le hachage fingerprint2011 d'une séquence d'octets ou d'une chaîne d'entrée. Cette fonction renvoie une valeur INT non signée comprise dans la plage [2, 0xFFFFFFFFFFFFFFFF].

Remarque :Cette fonction ne doit pas être utilisée comme hachage cryptographique sécurisé.

Types de données des paramètres

BTYE, STRING

Type renvoyé

INT

Exemple de code

id_fingerprint = hash.fingerprint2011("user123")

groupe

Compatible avec:

Rechercher

group(field1, field2, field3, ...)

Description

Regroupez les champs d'un type similaire dans une variable d'espace réservé.

Dans la recherche UDM, les champs groupés permettent d'effectuer une recherche dans plusieurs champs du même type. La fonction de groupe est semblable aux champs groupés, sauf qu'elle vous permet de sélectionner les champs que vous souhaitez regrouper pour déclencher une détection. Vous pouvez utiliser la fonction de groupe pour recueillir des informations sur une entité spécifique (par exemple, un nom d'hôte, une adresse IP ou un ID utilisateur) dans différents types de noms.

Remarque :Pour la recherche, vous pouvez utiliser des champs groupés dans la section des événements, mais pas dans les sections de correspondance et de résultat.

Exemples de code

Exemple 1

Regroupez toutes les adresses IP et indiquez le nombre décroissant d'adresses IP les plus courantes dans la période analysée.

$ip = group(principal.ip, about.ip, target.ip)
$ip != ""
match:
  $ip
outcome:
  $count = count_distinct(metadata.id)
order:
  $count desc

math.abs

Compatible avec:

Règles Rechercher

math.abs(numericExpression)

Description

Renvoie la valeur absolue d'une expression entière ou flottante.

Types de données des paramètres

NUMBER

Type renvoyé

NUMBER

Exemples de code

Exemple 1

Cet exemple renvoie la valeur "True" si l'événement s'est produit plus de cinq minutes après l'heure spécifiée (en secondes depuis l'époque Unix), que l'événement ait eu lieu avant ou après l'heure spécifiée. Un appel à math.abs ne peut pas dépendre de plusieurs variables ou espaces réservés. Par exemple, vous ne pouvez pas remplacer la valeur temporelle 1643687343 codée en dur dans l'exemple suivant par $e2.metadata.event_timestamp.seconds.

300 < math.abs($e1.metadata.event_timestamp.seconds - 1643687343)

math.log

Compatible avec:

Règles Rechercher

math.log(numericExpression)

Description

Renvoie la valeur du journal naturel d'une expression entière ou flottante.

Types de données des paramètres

NUMBER

Type renvoyé

NUMBER

Exemples de code

Exemple 1

math.log($e1.network.sent_bytes) > 20

math.round

Compatible avec:

Rechercher

math.round(numericExpression, decimalPlaces)

Description

Renvoie une valeur arrondie à l'entier le plus proche ou au nombre de décimales spécifié.

Types de données des paramètres

NUMBER

Type renvoyé

NUMBER

Exemples de code

math.round(10.7) // returns 11
math.round(1.2567, 2) // returns 1.25
math.round(-10.7) // returns -11
math.round(-1.2) // returns -1
math.round(4) // returns 4, math.round(integer) returns the integer

metrics

Compatible avec:

Règles

Les fonctions de métriques peuvent agréger de grandes quantités de données historiques. Vous pouvez l'utiliser dans votre règle en utilisant metrics.functionName() dans la section des résultats.

Pour en savoir plus, consultez la section Métriques YARA-L.

net.ip_in_range_cidr

Compatible avec:

Règles Rechercher

net.ip_in_range_cidr(ipAddress, subnetworkRange)

Description

Renvoie true lorsque l'adresse IP donnée se trouve dans le sous-réseau spécifié.

Vous pouvez utiliser YARA-L pour rechercher des événements UDM sur toutes les adresses IP d'un sous-réseau à l'aide de l'instruction net.ip_in_range_cidr(). Les adresses IPv4 et IPv6 sont toutes les deux compatibles.

Pour effectuer une recherche dans une plage d'adresses IP, spécifiez un champ IP UDM et une plage CIDR. YARA-L peut gérer à la fois des champs d'adresses IP uniques et répétés.

Pour effectuer une recherche sur une plage d'adresses IP, spécifiez un champ UDM ip et une plage CIDR (Classless Inter-Domain Routing). YARA-L peut gérer à la fois des champs d'adresses IP uniques et répétés.

Types de données des paramètres

STRING – STRING

Type renvoyé

BOOL

Exemples de code

Exemple 1

Exemple avec IPv4:

net.ip_in_range_cidr($e.principal.ip, "192.0.2.0/24")

Exemple 2

Exemple avec IPv6:

net.ip_in_range_cidr($e.network.dhcp.yiaddr, "2001:db8::/32")

Pour obtenir un exemple de règle utilisant l'instruction net.ip_in_range_cidr(), consultez l'exemple de règle dans la section Événement unique dans une plage d'adresses IP.)

re.regex

Compatible avec:

Règles Rechercher

Vous pouvez définir la correspondance d'expression régulière dans YARA-L 2.0 à l'aide de l'une des syntaxes suivantes:

• Utiliser la syntaxe YARA-L – En lien avec des événements. Voici une représentation générique de cette syntaxe:

  $e.field = /regex/
  

• En utilisant la syntaxe YARA-L : en tant que fonction acceptant les paramètres suivants :

  • Champ auquel l'expression régulière est appliquée.
  • Expression régulière spécifiée en tant que chaîne.

  Voici une représentation générique de cette syntaxe:

  re.regex($e.field, `regex`)
  

Description

Cette fonction renvoie true si la chaîne contient une sous-chaîne qui correspond à l'expression régulière fournie. Il n'est pas nécessaire d'ajouter .* au début ou à la fin de l'expression régulière.

Remarques

• Pour correspondre à la chaîne exacte, ou uniquement à un préfixe ou à un suffixe, incluez les caractères d'ancrage ^ (de départ) et $ (fin) dans l'expression régulière. Par exemple, /^full$/ correspond exactement à "full", tandis que /full/ peut correspondre à "fullest", "lawfull" et "joyfully".
• Si le champ UDM inclut des caractères de retour à la ligne, regexp ne correspond qu'à la première ligne du champ UDM. Pour appliquer une correspondance complète des champs UDM, ajoutez un (?s) à l'expression régulière. Par exemple, remplacez /.*allUDM.*/ par /(?s).*allUDM.*/.
• Vous pouvez utiliser le modificateur nocase après les chaînes pour indiquer que la recherche doit ignorer les majuscules.

Types de données des paramètres

STRING – STRING

Types d'expressions de paramètres

ANY – ANY

Type renvoyé

BOOL

Exemples de code

Exemple 1

// Equivalent to $e.principal.hostname = /google/
re.regex($e.principal.hostname, "google")

re.capture

Compatible avec:

Règles Rechercher

re.capture(stringText, regex)

Description

Capture (extrait) les données d'une chaîne à l'aide du modèle d'expression régulière fourni dans l'argument.

Cette fonction nécessite deux arguments:

• stringText: chaîne d'origine à rechercher.
• regex: expression régulière indiquant le modèle à rechercher.

L'expression régulière peut contenir 0 ou 1 groupe de capture entre parenthèses. Si l'expression régulière ne contient aucun groupe de capture, la fonction renvoie la première sous-chaîne entièrement correspondante. Si l'expression régulière contient un groupe de capture, elle renvoie la première sous-chaîne correspondante du groupe de capture. La définition de deux ou plusieurs groupes de capture renvoie une erreur de compilation.

Types de données des paramètres

STRING – STRING

Type renvoyé

STRING

Exemples de code

Exemple 1

Dans cet exemple, si $e.principal.hostname contient "aaa1bbaa2", la valeur suivante est "true", car la fonction renvoie la première instance. Cet exemple ne comporte aucun groupe de capture.

"aaa1" = re.capture($e.principal.hostname, "a+[1-9]")

Exemple 2

Cet exemple capture tout ce qui se trouve après le symbole @ dans un e-mail. Si la valeur du champ $e.network.email.from est [e-mail], l'exemple renvoie google.com. L'exemple suivant contient un groupe de capture.

"google.com" = re.capture($e.network.email.from , "@(.*)")

Exemple 3

Si l'expression régulière ne correspond à aucune sous-chaîne du texte, la fonction renvoie une chaîne vide. Vous pouvez omettre les événements où aucune correspondance n'est trouvée en excluant la chaîne vide, ce qui est particulièrement important lorsque vous utilisez re.capture() avec une inégalité:

// Exclude the empty string to omit events where no match occurs.
"" != re.capture($e.network.email.from , "@(.*)")

// Exclude a specific string with an inequality.
"google.com" != re.capture($e.network.email.from , "@(.*)")

re.replace

Compatible avec:

Règles Rechercher

re.replace(stringText, replaceRegex, replacementText)

Description

Effectue le remplacement d'une expression régulière.

Cette fonction nécessite trois arguments:

• stringText: chaîne d'origine.
• replaceRegex: expression régulière indiquant le modèle à rechercher.
• replacementText: texte à insérer dans chaque correspondance.

Renvoie une nouvelle chaîne dérivée de la fonction stringText d'origine, où toutes les sous-chaînes correspondant au modèle de replaceRegex sont remplacées par la valeur de replacementText. Vous pouvez utiliser des chiffres échappés par une barre oblique inverse (\1 à \9) dans replacementText pour insérer du texte correspondant au groupe entre parenthèses correspondant dans le format replaceRegex. Utilisez \0 pour faire référence à l'intégralité du texte correspondant.

La fonction remplace les correspondances qui ne se chevauchent pas et privilégie le remplacement de la première occurrence trouvée. Par exemple, re.replace("banana", "ana", "111") renvoie la chaîne "b111na".

Types de données des paramètres

STRING, STRING et STRING

Type renvoyé

STRING

Exemples de code

Exemple 1

Cet exemple capture tout ce qui se trouve après le symbole @ dans un e-mail, remplace com par org, puis renvoie le résultat. Notez l'utilisation de fonctions imbriquées.

"[e-mail]" = re.replace($e.network.email.from, "com", "org")

Exemple 2

Cet exemple utilise des chiffres échappés par une barre oblique inverse dans l'argument replacementText pour faire référence aux correspondances avec le modèle replaceRegex.

"test1.com.google" = re.replace(
                       $e.principal.hostname, // holds "test1.test2.google.com"
                       "test2\.([a-z]*)\.([a-z]*)",
                       "\\2.\\1"  // \\1 holds "google", \\2 holds "com"
                     )

Exemple 3

Notez les cas suivants lorsque vous traitez des chaînes vides et des re.replace():

Utiliser une chaîne vide en tant que replaceRegex:

// In the function call below, if $e.principal.hostname contains "name",
// the result is: 1n1a1m1e1, because an empty string is found next to
// every character in `stringText`.
re.replace($e.principal.hostname, "", "1")

Pour remplacer une chaîne vide, vous pouvez utiliser "^$" comme replaceRegex:

// In the function call below, if $e.principal.hostname contains the empty
// string, "", the result is: "none".
re.replace($e.principal.hostname, "^$", "none")

sample_rate

Compatible avec:

Règles

optimization.sample_rate(byteOrString, rateNumerator, rateDenominator)

Description

Cette fonction détermine si un événement doit être inclus en fonction d'une stratégie d'échantillonnage déterministe. Cette fonction renvoie:

• true pour une fraction des valeurs d'entrée, équivalente à (rateNumerator / rateDenominator), indiquant que l'événement doit être inclus dans l'échantillon.
• false, qui indique que l'événement ne doit pas être inclus dans l'exemple.

Cette fonction est utile pour les scénarios d'optimisation dans lesquels vous ne souhaitez traiter qu'un sous-ensemble d'événements. Équivalent à:

hash.fingerprint2011(byteOrString) % rateDenominator < rateNumerator

Types de données des paramètres

• byteOrString: expression qui renvoie une valeur BYTE ou STRING.
• rateNumerator: "INT"
• rateDenominator: 'INT'

Type renvoyé

BOOL

Exemple de code

events:
    $e.metadata.event_type = "NETWORK_CONNECTION"
    $asset_id = $e.principal.asset.asset_id
    optimization.sample_rate($e.metadata.id, 1, 5) // Only 1 out of every 5 events

  match:
    $asset_id over 1h

  outcome:
    $event_count = count_distinct($e.metadata.id)
  // estimate the usage by multiplying by the inverse of the sample rate
    $usage_past_hour = sum(5.0 * $e.network.sent_bytes)

 condition:
  // Requiring a certain number of events after sampling avoids bias (e.g. a
  // device with just 1 connection will still show up 20% of the time and
  // if we multiply that traffic by 5, we'll get an incorrect estimate)
  $e and ($usage_past_hour > 1000000000) and $event_count >= 100

strings.base64_decode

Compatible avec:

Règles Rechercher

strings.base64_decode(encodedString)

Description

Renvoie une chaîne contenant la version décodée en base64 de la chaîne encodée.

Cette fonction utilise une chaîne encodée en base64 comme argument. Si encodedString n'est pas une chaîne encodée en base64 valide, la fonction renvoie encodedString inchangée.

Types de données des paramètres

STRING

Type renvoyé

STRING

Exemples de code

Exemple 1

"test" = strings.base64_decode($e.principal.domain.name)

strings.coalesce

Compatible avec:

Règles Rechercher

strings.coalesce(a, b, c, ...)

Description

Cette fonction accepte un nombre illimité d'arguments et renvoie la valeur de la première expression qui n'équivaut pas à une chaîne vide (par exemple, "valeur non nulle"). Si tous les arguments renvoient une chaîne vide, l'appel de fonction renvoie une chaîne vide.

Les arguments peuvent être des littéraux, des champs d'événement ou des appels de fonction. Tous les arguments doivent être de type STRING. Si des arguments sont des champs d'événement, ils doivent provenir du même événement.

Types de données des paramètres

STRING

Type renvoyé

STRING

Exemples de code

Exemple 1

L'exemple suivant inclut des variables de chaîne en tant qu'arguments. La condition renvoie la valeur "true" lorsque (1) $e.network.email.from est [e-mail] ou (2) $e.network.email.from est vide et $e.network.email.to est [e-mail].

"[e-mail]" = strings.coalesce($e.network.email.from, $e.network.email.to)

Exemple 2

L'exemple suivant appelle la fonction coalesce avec plus de deux arguments. Cette condition compare la première adresse IP non nulle de l'événement $e aux valeurs de la liste de référence ip_watchlist. L'ordre de fusion des arguments dans cet appel est le même que celui énuméré dans la condition de la règle:

1. $e.principal.ip est évalué en premier.
2. $e.src.ip est ensuite évalué.
3. $e.target.ip est ensuite évalué.
4. Enfin, la chaîne "Aucune adresse IP" est renvoyée en tant que valeur par défaut si les champs ip précédents ne sont pas définis.

strings.coalesce($e.principal.ip, $e.src.ip, $e.target.ip, "No IP") in %ip_watchlist

Exemple 3

L'exemple suivant tente de fusionner principal.hostname de l'événement $e1 et de l'événement $e2. Elle renvoie une erreur de compilation, car les arguments sont des variables d'événements différentes.

// returns a compiler error
"test" = strings.coalesce($e1.principal.hostname, $e2.principal.hostname)

strings.concat

Compatible avec:

Règles Rechercher

strings.concat(a, b, c, ...)

Description

Renvoie la concaténation d'un nombre illimité d'éléments, chacun pouvant être une chaîne, un entier ou un nombre à virgule flottante.

Si des arguments sont des champs d'événement, ils doivent provenir du même événement.

Types de données des paramètres

STRING, FLOAT et INT

Type renvoyé

STRING

Exemples de code

Exemple 1

L'exemple suivant inclut une variable de chaîne et une variable entière comme arguments. principal.hostname et principal.port proviennent du même événement, $e, et sont concaténés pour renvoyer une chaîne.

"google:80" = strings.concat($e.principal.hostname, ":", $e.principal.port)

Exemple 2

L'exemple suivant inclut une variable de chaîne et un littéral de chaîne en tant qu'arguments.

"google-test" = strings.concat($e.principal.hostname, "-test") // Matches the event when $e.principal.hostname = "google"

Exemple 3

L'exemple suivant inclut une variable de chaîne et un littéral à virgule flottante en tant qu'arguments. Lorsqu'ils sont représentés sous forme de chaînes, les nombres à virgule flottante qui sont des nombres entiers sont mis en forme sans le séparateur décimal (par exemple, 1,0 correspond à "1"). De plus, les nombres à virgule flottante qui dépassent 16 chiffres décimaux sont tronqués au seizième.

"google2.5" = strings.concat($e.principal.hostname, 2.5)

Exemple 4

L'exemple suivant inclut une variable de chaîne, un littéral de chaîne, une variable entière et un littéral à virgule flottante en tant qu'arguments. Toutes les variables proviennent du même événement ($e) et sont concaténées avec les littéraux pour renvoyer une chaîne.

"google-test802.5" = strings.concat($e.principal.hostname, "-test", $e.principal.port, 2.5)

Exemple 5

L'exemple suivant tente de concaténer principal.port à partir de l'événement $e1, avec principal.hostname de l'événement $e2. Elle renverra une erreur de compilation, car les arguments sont des variables d'événements différentes.

// Will not compile
"test" = strings.concat($e1.principal.port, $e2.principal.hostname)

strings.to_lower

Compatible avec:

Règles Rechercher

strings.to_lower(stringText)

Description

Cette fonction prend une chaîne d'entrée et renvoie une chaîne après avoir remplacé tous les caractères en minuscules

Types de données des paramètres

STRING

Type renvoyé

STRING

Exemples de code

Exemple 1

L'exemple suivant renvoie true.

"[e-mail]" = strings.to_lower($e.network.email.to)

strings.to_upper

Compatible avec:

Règles Rechercher

strings.to_upper(stringText)

Description

Cette fonction prend une chaîne d'entrée et renvoie une chaîne après avoir remplacé tous les caractères en majuscules

Types de données des paramètres

STRING

Type renvoyé

STRING

Exemples de code

Exemple 1

L'exemple suivant renvoie true.

"[e-mail]" = strings.to_upper($e.network.email.to)

timestamp.current_seconds

Compatible avec:

Règles Rechercher

timestamp.current_seconds()

Description

Renvoie un nombre entier représentant l'heure actuelle en secondes Unix. Cette valeur est à peu près égale au code temporel de détection et dépend du moment où la règle est exécutée.

Types de données des paramètres

NONE

Type renvoyé

INT

Exemples de code

Exemple 1

L'exemple suivant renvoie true si le certificat a expiré depuis plus de 24 heures. Elle calcule la différence de temps en soustrayant les secondes Unix actuelles, puis en effectuant une comparaison à l'aide d'un opérateur supérieur à.

86400 < timestamp.current_seconds() - $e.network.tls.certificate.not_after

timestamp.get_date

Compatible avec:

Règles Rechercher

timestamp.get_date(unix_seconds [, time_zone])

Description

Cette fonction renvoie une chaîne au format YYYY-MM-DD représentant le jour où se trouve un horodatage.

• unix_seconds est un entier représentant le nombre de secondes après l'epoch Unix, tel que $e.metadata.event_timestamp.seconds, ou un espace réservé contenant cette valeur.
• time_zone est une chaîne facultative (time_zone). En cas d'omission, la valeur par défaut est "GMT". Vous pouvez spécifier les fuseaux horaires à l'aide de littéraux de chaîne. Les options sont les suivantes :
  • Nom de la base de données TZ. Par exemple : "America/Los_Angeles". Pour en savoir plus, consultez la colonne"Nom de la base de données TZ" de cette page.
  • Décalage de fuseau horaire par rapport à UTC, au format (+|-)H[H][:M[M]]. Par exemple: "-08:00".

Voici des exemples de spécificateurs de fuseau horaire valides, que vous pouvez transmettre comme deuxième argument aux fonctions d'extraction de l'heure:

"America/Los_Angeles", or "-08:00". ("PST" is not supported)
"America/New_York", or "-05:00". ("EST" is not supported)
"Europe/London"
"UTC"
"GMT"

Types de données des paramètres

INT, STRING

Type renvoyé

STRING

Exemples de code

Exemple 1

Dans cet exemple, l'argument time_zone est omis. La valeur "GMT" est donc définie par défaut.

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_date($ts) = "2024-02-19"

Exemple 2

Cet exemple utilise un littéral de chaîne pour définir time_zone.

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_date($ts, "America/Los_Angeles") = "2024-02-20"

timestamp.get_minute

Compatible avec:

Règles Rechercher

timestamp.get_minute(unix_seconds [, time_zone])

Description

Cette fonction renvoie un entier compris dans la plage [0, 59] représentant la minute.

• unix_seconds est un entier représentant le nombre de secondes après l'epoch Unix, tel que $e.metadata.event_timestamp.seconds, ou un espace réservé contenant cette valeur.
• time_zone est facultatif et correspond à une chaîne représentant un fuseau horaire. En cas d'omission, la valeur par défaut est "GMT". Vous pouvez spécifier les fuseaux horaires à l'aide de littéraux de chaîne. Les options sont les suivantes :
  • Nom de la base de données TZ. Par exemple : "America/Los_Angeles". Pour en savoir plus, consultez la colonne"Nom de la base de données TZ" de cette page.
  • Décalage de fuseau horaire par rapport à UTC, au format (+|-)H[H][:M[M]]. Par exemple: "-08:00".

Voici des exemples de spécificateurs time_zone valides, que vous pouvez transmettre comme deuxième argument aux fonctions d'extraction de temps:

"America/Los_Angeles", or "-08:00". ("PST" is not supported)
"America/New_York", or "-05:00". ("EST" is not supported)
"Europe/London"
"UTC"
"GMT"

Types de données des paramètres

INT, STRING

Type renvoyé

INT

Exemples de code

Exemple 1

Dans cet exemple, l'argument time_zone est omis. La valeur "GMT" est donc définie par défaut.

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_hour($ts) = 15

Exemple 2

Cet exemple utilise un littéral de chaîne pour définir time_zone.

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_hour($ts, "America/Los_Angeles") = 15

timestamp.get_hour

Compatible avec:

Règles Rechercher

timestamp.get_hour(unix_seconds [, time_zone])

Description

Cette fonction renvoie un entier compris dans la plage [0, 23], qui représente l'heure.

• unix_seconds est un entier représentant le nombre de secondes après l'epoch Unix, tel que $e.metadata.event_timestamp.seconds, ou un espace réservé contenant cette valeur.
• time_zone est facultatif et correspond à une chaîne représentant un fuseau horaire. En cas d'omission, la valeur par défaut est "GMT". Vous pouvez spécifier les fuseaux horaires à l'aide de littéraux de chaîne. Les options sont les suivantes :
  • Nom de la base de données TZ. Par exemple : "America/Los_Angeles". Pour en savoir plus, consultez la colonne"Nom de la base de données TZ" de cette page.
  • Décalage de fuseau horaire par rapport à UTC, au format (+|-)H[H][:M[M]]. Par exemple: "-08:00".

Voici des exemples de spécificateurs time_zone valides, que vous pouvez transmettre comme deuxième argument aux fonctions d'extraction de temps:

"America/Los_Angeles", or "-08:00". ("PST" is not supported)
"America/New_York", or "-05:00". ("EST" is not supported)
"Europe/London"
"UTC"
"GMT"

Types de données des paramètres

INT, STRING

Type renvoyé

INT

Exemples de code

Exemple 1

Dans cet exemple, l'argument time_zone est omis. La valeur "GMT" est donc définie par défaut.

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_hour($ts) = 15

Exemple 2

Cet exemple utilise un littéral de chaîne pour définir time_zone.

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_hour($ts, "America/Los_Angeles") = 15

timestamp.get_day_of_week

Compatible avec:

Règles Rechercher

timestamp.get_day_of_week(unix_seconds [, time_zone])

Description

Cette fonction renvoie un entier compris dans la plage [1, 7], qui représente le jour de la semaine commençant par dimanche. Par exemple, 1 = dimanche et 2 = lundi.

• unix_seconds est un entier représentant le nombre de secondes après l'epoch Unix, tel que $e.metadata.event_timestamp.seconds, ou un espace réservé contenant cette valeur.
• time_zone est une chaîne facultative (time_zone). En cas d'omission, la valeur par défaut est "GMT". Vous pouvez spécifier les fuseaux horaires à l'aide de littéraux de chaîne. Les options sont les suivantes :
  • Nom de la base de données TZ. Par exemple : "America/Los_Angeles". Pour en savoir plus, consultez la colonne"Nom de la base de données TZ" de cette page.
  • Décalage de fuseau horaire par rapport à UTC, au format (+|-)H[H][:M[M]]. Par exemple: "-08:00".

Voici des exemples de spécificateurs de fuseau horaire valides, que vous pouvez transmettre comme deuxième argument aux fonctions d'extraction de l'heure:

"America/Los_Angeles", or "-08:00". ("PST" is not supported)
"America/New_York", or "-05:00". ("EST" is not supported)
"Europe/London"
"UTC"
"GMT"

Types de données des paramètres

INT, STRING

Type renvoyé

INT

Exemples de code

Exemple 1

Dans cet exemple, l'argument time_zone est omis. La valeur "GMT" est donc définie par défaut.

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_day_of_week($ts) = 6

Exemple 2

Cet exemple utilise un littéral de chaîne pour définir time_zone.

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_day_of_week($ts, "America/Los_Angeles") = 6

timestamp.get_timestamp

Compatible avec:

Règles Rechercher

timestamp.get_timestamp(unix_seconds, optional timestamp_format, optional timezone)

Description

Cette fonction renvoie une chaîne au format YYYY-MM-DD représentant le jour où se trouve un horodatage.

• unix_seconds est un entier représentant le nombre de secondes après l'epoch Unix, tel que $e.metadata.event_timestamp.seconds, ou un espace réservé contenant cette valeur.
• timestamp_format est facultatif et correspond à une chaîne représentant le format de l'horodatage. Si aucune valeur n'est spécifiée, la valeur par défaut est %F %T. Vous pouvez spécifier le format à l'aide de littéraux de chaîne. Pour connaître les options, consultez Mettre en forme des éléments pour les parties de date et d'heure.
• time_zone est facultatif et correspond à une chaîne représentant un fuseau horaire. En cas d'omission, la valeur par défaut est GMT. Vous pouvez spécifier les fuseaux horaires à l'aide de littéraux de chaîne. Les options sont les suivantes :
  • Nom de la base de données du fuseau horaire de l'IANA (par exemple, America/Los_Angeles). Pour en savoir plus, consultez la liste des fuseaux horaires de la base de données tz sur Wikipédia.
  • Décalage de fuseau horaire par rapport à l'heure UTC, au format (+|-)H[H][:M[M]], par exemple: "-08:00".

Voici des exemples de spécificateurs time_zone valides, que vous pouvez transmettre comme deuxième argument aux fonctions d'extraction de temps:

"America/Los_Angeles", or "-08:00". ("PST" is not supported)
"America/New_York", or "-05:00". ("EST" is not supported)
"Europe/London"
"UTC"
"GMT"

Types de données des paramètres

INT, STRING et STRING

Type renvoyé

STRING

Exemples de code

Exemple 1

Dans cet exemple, l'argument time_zone est omis. La valeur par défaut est GMT.

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_timestamp($ts) = "2024-02-22 10:43:51"

Exemple 2

Cet exemple utilise un littéral de chaîne pour définir time_zone.

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_timestamp($ts, "%F %T", "America/Los_Angeles") = "2024-02-22 10:43:51"

Exemple 3

Cet exemple utilise un littéral de chaîne pour définir timestamp_format.

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_timestamp($ts, "%Y-%m", "GMT") = "2024-02"

timestamp.get_week

Compatible avec:

Règles Rechercher

timestamp.get_week(unix_seconds [, time_zone])

Description

Cette fonction renvoie un entier compris dans la plage [0, 53] représentant la semaine de l'année. Les semaines commencent le dimanche. Les dates antérieures au premier dimanche de l'année correspondent à la semaine 0.

• unix_seconds est un entier représentant le nombre de secondes après l'epoch Unix, tel que $e.metadata.event_timestamp.seconds, ou un espace réservé contenant cette valeur.
• time_zone est facultatif et correspond à une chaîne représentant un fuseau horaire. En cas d'omission, la valeur par défaut est "GMT". Vous pouvez spécifier les fuseaux horaires à l'aide de littéraux de chaîne. Les options sont les suivantes :
  • Nom de la base de données TZ. Par exemple : "America/Los_Angeles". Pour en savoir plus, consultez la colonne"Nom de la base de données TZ" de cette page.
  • Décalage de fuseau horaire par rapport à UTC, au format (+|-)H[H][:M[M]]. Par exemple: "-08:00".

Voici des exemples de spécificateurs time_zone valides, que vous pouvez transmettre comme deuxième argument aux fonctions d'extraction de temps:

"America/Los_Angeles", or "-08:00". ("PST" is not supported)
"America/New_York", or "-05:00". ("EST" is not supported)
"Europe/London"
"UTC"
"GMT"

Types de données des paramètres

INT, STRING

Type renvoyé

INT

Exemples de code

Exemple 1

Dans cet exemple, l'argument time_zone est omis. La valeur "GMT" est donc définie par défaut.

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_week($ts) = 0

Exemple 2

Cet exemple utilise un littéral de chaîne pour définir time_zone.

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_week($ts, "America/Los_Angeles") = 0

Attribution d'une fonction à un espace réservé

Vous pouvez attribuer le résultat d'un appel de fonction à un espace réservé dans la section events. Exemple :

$placeholder = strings.concat($e.principal.hostname, "my-string").

Vous pouvez ensuite utiliser les variables d'espace réservé dans les sections match, condition et outcome. Toutefois, l'attribution d'un espace réservé à une fonction présente deux limites:

1. Dans une fonction, chaque espace réservé doit être affecté à une expression contenant un champ d'événement. Les exemples suivants sont valides:

   $ph1 = $e.principal.hostname
   $ph2 = $e.src.hostname
   
   // Both $ph1 and $ph2 have been assigned to an expression containing an event field.
   $ph1 = strings.concat($ph2, ".com")
   

   $ph1 = $e.network.email.from
   $ph2 = strings.concat($e.principal.hostname, "@gmail.com")
   
   // Both $ph1 and $ph2 have been assigned to an expression containing an event field.
   $ph1 = strings.to_lower($ph2)
   

   Toutefois, l'exemple suivant n'est pas valide:

   $ph1 = strings.concat($e.principal.hostname, "foo")
   $ph2 = strings.concat($ph1, "bar") // $ph2 has NOT been assigned to an expression containing an event field.
   

2. L'appel de fonction doit dépendre d'un seul événement. Cependant, plusieurs champs du même événement peuvent être utilisés dans les arguments d'appel de fonction. Par exemple, l'exemple suivant est valide:

   $ph = strings.concat($event.principal.hostname, "string2")

   $ph = strings.concat($event.principal.hostname, $event.src.hostname)

   Toutefois, le texte suivant n'est pas valide:

   $ph = strings.concat("string1", "string2")

   $ph = strings.concat($event.principal.hostname, $anotherEvent.src.hostname)

Syntaxe des listes de référence

Consultez la page Listes de référence pour en savoir plus sur leur comportement et leur syntaxe.

Vous pouvez utiliser des listes de référence dans les sections events ou outcome. Voici la syntaxe à respecter pour utiliser différents types de listes de référence dans une règle:

// STRING reference list
$e.principal.hostname in %string_reference_list

// REGEX reference list
$e.principal.hostname in regex %regex_reference_list

// CIDR reference list
$e.principal.ip in cidr %cidr_reference_list

Vous pouvez également utiliser les opérateurs not et nocase avec des listes de référence, comme illustré dans l'exemple suivant:

// Exclude events whose hostnames match substrings in my_regex_list.
not $e.principal.hostname in regex %my_regex_list

// Event hostnames must match at least 1 string in my_string_list (case insensitive).
$e.principal.hostname in %my_string_list nocase

L'opérateur nocase est compatible avec les listes STRING et REGEX.

Pour des raisons de performances, le moteur de détection limite l'utilisation des listes de référence.

• Nombre maximal d'instructions in par règle, avec ou sans opérateurs spéciaux: 7
• Nombre maximal d'instructions in avec l'opérateur regex: 4
• Nombre maximal d'instructions in avec l'opérateur cidr: 2

Vérification du type

Google Security Operations effectue une vérification du type par rapport à votre syntaxe YARA-L lorsque vous créez des règles dans l'interface. Les erreurs de vérification du type affichées vous aident à réviser la règle de manière à vous assurer qu'elle fonctionnera comme prévu.

Voici des exemples de prédicats non valides:

// $e.target.port is of type integer which cannot be compared to a string.
$e.target.port = "80"

// "LOGIN" is not a valid event_type enum value.
$e.metadata.event_type = "LOGIN"

Échantillonnage d'événements de détection

Les détections provenant de règles multi-événements contiennent des exemples d'événements qui fournissent du contexte sur les événements à l'origine de la détection. Le nombre d'exemples d'événements est limité à 10 pour chaque variable d'événement définie dans la règle. Par exemple, si une règle définit deux variables d'événement, chaque détection peut comporter jusqu'à 20 échantillons d'événements. Cette limite s'applique à chaque variable d'événement séparément. Si une variable d'événement comporte deux événements applicables dans cette détection et que l'autre variable comporte 15 événements applicables, la détection obtenue contient 12 échantillons d'événements (2 + 10).

Tous les échantillons d'événements dépassant la limite sont omis de la détection.

Si vous souhaitez en savoir plus sur les événements qui ont déclenché votre détection, vous pouvez utiliser les agrégations de la section sur les résultats.

Si vous consultez les détections dans l'interface utilisateur, vous pouvez télécharger tous les exemples d'événements pour une détection. Pour en savoir plus, consultez Télécharger des événements.