Limites et problèmes connus de YARA-L 2.0

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

Agrégations de résultats avec suppression de l'imbrication des champs répétés

Lorsqu'une règle fait référence à un champ répété dans une variable d'événement comportant plusieurs éléments, chaque élément est divisé en une ligne d'événement distincte.

Par exemple, les deux adresses IP du champ répété target.ip de l'événement $e sont divisées en deux instances de $e, chacune avec une valeur target.ip différente.

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 l'annulation de l'imbrication du champ répété

Le tableau suivant montre l'enregistrement d'événement avant l'annulation de l'imbrication du champ répété :

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

Enregistrements d'événements après avoir supprimé l'imbrication du champ répété

Le tableau suivant montre l'enregistrement d'événement après l'annulation de l'imbrication du champ répété :

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é imbriqué dans un autre, comme security_results.action, la désimbrication se produit aux niveaux parent et enfant. Les instances résultant de l'annulation de l'imbrication d'un seul événement forment un produit cartésien des éléments dans les champs parents et enfants. 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 est supprimé et remplacé par 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 l'annulation de l'imbrication du champ répété

Le tableau suivant montre l'enregistrement d'événement avant l'annulation de l'imbrication du champ répété :

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

Enregistrements d'événements après l'annulation de l'imbrication des champs répétés

Le tableau suivant montre l'enregistrement d'événement après l'annulation de l'imbrication du champ répété :

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

Ce comportement de suppression de l'imbrication lors de l'évaluation des règles peut produire 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 produit par le comportement de désimbrication. Dans l'exemple de règle suivant, l'événement $e comporte un seul nom d'hôte google.com, mais le résultat hostnames agrège quatre instances non imbriquées du même événement $e, chacune avec une valeur principal.hostname en double. Ce résultat génère quatre noms d'hôte au lieu d'un en raison de l'annulation de l'imbrication des 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 l'annulation de l'imbrication du champ répété

Le tableau suivant montre l'enregistrement d'événement avant l'annulation de l'imbrication du champ répété :

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 l'annulation de l'imbrication d'un champ répété

Le tableau suivant montre l'enregistrement d'événement après l'annulation de l'imbrication du champ répété :

metadata.id	principal.application	principal.hostname	security_results.action
`aaaaaaaaa`	`Google SecOps`	`google.com`	AUTORISER
`aaaaaaaaa`	`Google SecOps`	`google.com`	ÉCHEC
`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 suppression de l'imbrication. Utilisez la version distincte d'une agrégation si vous rencontrez des valeurs de résultat inattendues en raison de la suppression de l'imbrication.

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

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

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

Si une règle contient plusieurs variables d'événement, il existe un élément distinct dans l'agrégation pour chaque combinaison d'événements incluse dans la détection. Par exemple, si la règle suivante est exécutée sur les événements listé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

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

Cela affecte la somme, le nombre et le tableau. Pour les types "count" et "array", vous pouvez résoudre le problème en utilisant count_distinct ou array_distinct, mais il n'existe aucune solution de contournement pour le type "sum".

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érerait ce type d'erreur :

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

Les variations 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 le champ répété.

L'indexation de tableaux dans la section "Résultat" nécessite toujours une agrégation. Par exemple, le code suivant 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 utiliser cette variable dans la section "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 non-existence

Si une condition OR est appliquée entre deux variables d'événement distinctes et que la règle correspond à une non-existence, la règle est compilée avec succès, mais peut générer des faux positifs. Par exemple, la syntaxe de règle suivante peut correspondre à des événements ayant $event_a.field = "something", même si ce n'est pas le cas.

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

La solution de contournement consiste à séparer les conditions en deux blocs, où chaque bloc n'applique le filtre 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 se produit parce que les constantes entières sont définies par défaut sur des entiers signés, qui ne fonctionnent pas avec les entiers non signés dans les opérations arithmétiques.

La solution de contournement consiste à forcer la constante entière à devenir un float, qui fonctionnera ensuite avec l'entier non signé. Exemple :

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

Cohérence à terme et faux positifs dans l'enrichissement GeoIP

Le système privilégie la vitesse par rapport à la précision immédiate lors des étapes d'enrichissement initiales (Streaming et Sensible à la latence), ce qui peut entraîner des données manquantes et de potentiels faux positifs. Le système continuera d'enrichir les données en arrière-plan, mais il est possible qu'elles ne soient pas disponibles lorsque la règle est exécutée. Cela fait partie du processus normal de cohérence finale. Pour éviter ces types de faux positifs, ne vous fiez pas à l'existence de champs enrichis dans les événements pour déclencher des détections.

Prenons l'exemple de l'événement de règle suivant :

$e.principal.ip_geo_artifact.network.asn = "16509" AND
$e.principal.ip_geo_artifact.location.country_or_region = "United Kingdom"

La règle repose sur le fait que l'événement doit comporter $e.principal.ip_geo_artifact.network.asn = "16509" ET $e.principal.ip_geo_artifact.location.country_or_region = "United Kingdom", qui sont tous deux des champs enrichis. Si l'enrichissement n'est pas terminé à temps, la règle génère un faux positif.

Pour éviter cela, une meilleure vérification de cette règle serait :

$e.principal.ip_geo_artifact.network.asn != "" AND
$e.principal.ip_geo_artifact.network.asn = "16509" AND
$e.principal.ip_geo_artifact.location.country_or_region != "" AND
$e.principal.ip_geo_artifact.location.country_or_region = "United Kingdom"

Cette règle élimine la possibilité que l'événement soit déclenché par des adresses IP avec l'ASN 16509, mais situées en dehors du Royaume-Uni. Cela améliore la précision globale de la règle.

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