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

Limites et problèmes connus de YARA-L

Ce document décrit les problèmes et les limites connus de YARA-L.

Agrégations de résultats avec désimbrication de champs répétés

Lorsqu'une règle fait référence à un champ répété sur une variable d'événement et que ce champ répété contient plusieurs éléments, chaque élément est dénoyé dans une ligne d'événement distincte.

Par exemple, les deux chaînes d'adresse IP dans le champ répété target.ip sur l'événement $e dans la règle suivante sont désimbriquées dans deux instances de l'événement $e, chacun avec un élément target.ip différent.

rule outbound_ip_per_app {
  meta:
  events:
    $e.principal.application = $app
  match:
    $app over 10m
  outcome:
    $outbound_ip_count = count($e.target.ip) // yields 2.
  condition:
    $e
}

Enregistrement d'événement avant le désimbrication du champ répété

Le tableau suivant présente l'enregistrement de l'événement avant la désimbrication répétée des champs:

metadata.id	principal.application	target.ip
`aaaaaaaaa`	`Google SecOps`	`[192.0.2.20`, `192.0.2.28]`

Enregistrements d'événements après la désimbrication répétée d'un champ

Le tableau suivant présente l'enregistrement d'événement après plusieurs annulations de imbrication de champs :

metadata.id	principal.application	target.ip
`aaaaaaaaa`	`Google SecOps`	`192.0.2.20`
`aaaaaaaaa`	`Google SecOps`	`192.0.2.28`

Lorsqu'une règle fait référence à un champ répété qui est un enfant d'un autre champ répété tel que security_results.action, le désimbriquement se produit à la fois au niveau du champ parent et du champ enfant. L'ensemble d'instances résultant de l'extraction d'un seul événement est le produit cartésien des éléments du champ parent et des éléments du champ enfant. Dans l'exemple de règle suivant, l'événement $e avec deux valeurs répétées sur security_results et deux valeurs répétées sur security_results.actions sont déimbriqués en quatre instances.

rule security_action_per_app {
  meta:
  events:
    $e.principal.application = $app
  match:
    $app over 10m
  outcome:
    $security_action_count = count($e.security_results.actions) // yields 4.
  condition:
    $e
}

Enregistrement d'événement avant la désimbrication répétée des champs

Le tableau suivant présente l'enregistrement de l'événement avant la désimbrication répétée des champs:

metadata.id	principal.application	security_results
`aaaaaaaaa`	`Google SecOps`	`[ { actions: [ ALLOW, FAIL ] }`, `{ actions: [ CHALLENGE, BLOCK ] } ]`

Enregistrements d'événements après la désimbrication répétée d'un champ

Le tableau suivant présente l'enregistrement d'événement après plusieurs annulations de imbrication de champs :

metadata.id	principal.application	security_results.actions
`aaaaaaaaa`	`Google SecOps`	AUTORISER
`aaaaaaaaa`	`Google SecOps`	FAIL
`aaaaaaaaa`	`Google SecOps`	DÉFI
`aaaaaaaaa`	`Google SecOps`	BLOQUER

Ce comportement de désimbrication lors de l'évaluation des règles peut générer des agrégations de résultats inattendues lorsque la règle fait référence à un ou plusieurs champs répétés avec un champ parent qui est également un champ répété. Les agrégations non distinctes telles que sum(), array() et count() ne peuvent pas tenir compte des valeurs en double dans d'autres champs du même événement générés par le comportement de désimbrication. Dans l'exemple suivant, règle, l'événement $e comporte un seul nom d'hôte google.com, mais le résultat est hostnames regroupe quatre instances non imbriquées du même événement $e, chacune avec un doublon principal.hostname. Ce résultat donne quatre noms d'hôte au lieu d'un seul en raison de la désimbrication de valeurs répétées sur security_results.actions.

rule security_action_per_app {
  meta:
  events:
    $e.principal.application = $app
  match:
    $app over 10m
  outcome:
    $hostnames = array($e.principal.hostname) // yields 4.
    $security_action_count = count($e.security_results.action) // yields 4.
  condition:
    $e
}

Enregistrement d'événement avant la désimbrication répétée des champs

Le tableau suivant présente l'enregistrement de l'événement avant la désimbrication répétée des champs:

metadata.id	principal.application	principal.hostname	security_results
`aaaaaaaaa`	`Google SecOps`	`google.com`	`[ { action: [ ALLOW, FAIL ] }`, `{ action: [ CHALLENGE, BLOCK ] } ]`

Enregistrement d'événement après la désimbrication répétée d'un champ

Le tableau suivant présente l'enregistrement d'événement après plusieurs annulations de imbrication de champs :

metadata.id	principal.application	principal.hostname	security_results.action
`aaaaaaaaa`	`Google SecOps`	`google.com`	AUTORISER
`aaaaaaaaa`	`Google SecOps`	`google.com`	FAIL
`aaaaaaaaa`	`Google SecOps`	`google.com`	DÉFI
`aaaaaaaaa`	`Google SecOps`	`google.com`	BLOQUER

Solution

Les agrégations qui ignorent ou éliminent les valeurs en double ne sont pas affectées par ce comportement de désimbrication. Utilisez la version distincte d'une agrégation si vous rencontrez des valeurs de résultat inattendues en raison d'un désimbriquement.

Les agrégations suivantes ne sont pas affectées par le comportement de désimbrication décrit précédemment.

max()
min()
array_distinct()
count_distinct()

Agrégations de résultats avec plusieurs variables d'événements

Si une règle contient plusieurs variables d'événement, il y a un élément distinct dans pour chaque combinaison d'événements inclus dans la détection. Par exemple, si l'exemple de règle suivant est exécuté pour les événements répertoriés:

events:
  $e1.field = $e2.field
  $e2.somefield = $ph

match:
  $ph over 1h

outcome:
   $some_outcome = sum(if($e1.otherfield = "value", 1, 0))

condition:
  $e1 and $e2

event1:
  // UDM event 1
  field="a"
  somefield="d"

event2:
  // UDM event 2
  field="b"
  somefield="d"

event3:
  // UDM event 3
  field="c"
  somefield="d"

La somme est calculée pour chaque combinaison d'événements, ce qui vous permet d'utiliser les deux variables d'événement dans les calculs de la valeur du résultat. Les éléments suivants sont utilisés dans le calcul :

1: $e1 = event1, $e2 = event2
2: $e1 = event1, $e2 = event3
3: $e1 = event2, $e2 = event1
4: $e1 = event2, $e2 = event3
5: $e1 = event3, $e2 = event1
5: $e1 = event3, $e2 = event2

La somme maximale potentielle est donc de 6, même si $e2 ne peut correspondre qu'à trois événements distincts.

Cela affecte la somme, le nombre et le tableau. Pour le nombre et le tableau, l'utilisation de count_distinct ou array_distinct peut résoudre le problème, mais il n'existe actuellement aucune solution de contournement pour la somme.

Parenthèses au début d'une expression

L'utilisation de parenthèses au début d'une expression déclenche l'erreur suivante :

parsing: error with token: ")"
invalid operator in events predicate

L'exemple suivant génère ce type d'erreur:

($event.metadata.ingested_timestamp.seconds -
$event.metadata.event_timestamp.seconds) / 3600 > 1

Les variantes de syntaxe suivantes renvoient le même résultat, mais avec une syntaxe valide:

$event.metadata.ingested_timestamp.seconds / 3600 -
$event.metadata.event_timestamp.seconds / 3600 > 1
    1 / 3600 * ($event.metadata.ingested_timestamp.seconds -
$event.metadata.event_timestamp.seconds) > 1
    1 < ($event.metadata.ingested_timestamp.seconds -
$event.metadata.event_timestamp.seconds) / 3600

Le tableau d'index dans le résultat nécessite une agrégation pour les valeurs uniques dans un champ répété

L'indexation en tableau dans la section des résultats nécessite toujours une agrégation. Par exemple : ce qui suit ne fonctionne pas:

outcome:
  $principal_user_dept = $suspicious.principal.user.department[0]

Toutefois, vous pouvez enregistrer la sortie de l'index du tableau dans une variable d'espace réservé et utilisez cette variable dans la section de résultat, comme indiqué ci-dessous:

events:
  $principal_user_dept = $suspicious.principal.user.department[0]

outcome:
  $principal_user_department = $principal_user_dept

Condition OR avec inexistence

Si une condition OR est appliquée entre deux variables d'événement distinctes et si la règle correspond à une non-existence, la règle se compile correctement, mais peut générer des détections faussement positives. Par exemple, la syntaxe de règle suivante peut correspondre événements comportant $event_a.field = "something" alors que cela ne devrait pas être le cas.

events:
     not ($event_a.field = "something" **or** $event_b.field = "something")
condition:
     $event_a and #event_b >= 0

La solution consiste à séparer les conditions en deux blocs, où chaque bloc le filtre n'est appliqué qu'à une seule variable, comme indiqué ci-dessous:

events:
     not ($event_a.field = "something")
     not ($event_b.field = "something")
condition:
     $event_a and #event_b >= 0

Arithmétique avec des champs d'événement non signés

Si vous essayez d'utiliser une constante entière dans une opération arithmétique avec un champ UDM dont le type est un entier non signé, une erreur s'affiche. Exemple :

events:
  $total_bytes = $e.network.received_bytes * 2

Le champ udm.network.received_bytes est un entier non signé. Cela est dû au à des constantes entières utilisant par défaut des entiers signés, qui ne sont pas compatibles avec entiers non signés dans les opérations arithmétiques.

Le moyen de contourner le problème consiste à forcer la constante entière à un nombre à virgule flottante, qui fonctionnera ensuite avec l'entier sans signature. Exemple :

events:
  $total_bytes = $e.network.received_bytes * (2/1)