Problemas conocidos y limitaciones de YARA-L 2.0

En este documento, se describen los problemas y las limitaciones conocidos en YARA-L 2.0.

Agregaciones de resultados con anidación de campos repetidos

Cuando una regla hace referencia a un campo repetido en una variable de evento con varios elementos, cada elemento se divide en una fila de evento independiente.

Por ejemplo, las dos direcciones IP del campo repetido target.ip en el evento $e se dividen en dos instancias de $e, cada una con un valor target.ip diferente.

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
}

Registro de eventos antes de la anulación del anidamiento del campo repetido

En la siguiente tabla, se muestra el registro de eventos antes de anular el anidamiento del campo repetido:

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

Registros de eventos después de anular el anidamiento del campo repetido

En la siguiente tabla, se muestra el registro de eventos después de anular el anidamiento del campo repetido:

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

Cuando una regla hace referencia a un campo repetido anidado dentro de otro, como security_results.action, el desanidamiento se produce tanto en los niveles superior como secundario. Las instancias resultantes de la anidación de un solo evento forman un producto cartesiano de los elementos en los campos principal y secundario. En la siguiente regla de ejemplo, el evento $e con dos valores repetidos en security_results y dos valores repetidos en security_results.actions se anula en cuatro instancias.

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
}

Registro de eventos antes de la anulación del anidamiento del campo repetido

En la siguiente tabla, se muestra el registro de eventos antes de anular el anidamiento del campo repetido:

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

Registros de eventos después de anular la anidación de campos repetidos

En la siguiente tabla, se muestra el registro de eventos después de anular el anidamiento del campo repetido:

metadata.id	principal.application	security_results.actions
`aaaaaaaaa`	`Google SecOps`	PERMITIR
`aaaaaaaaa`	`Google SecOps`	REPROBADA
`aaaaaaaaa`	`Google SecOps`	DESAFÍO
`aaaaaaaaa`	`Google SecOps`	BLOQUEAR

Este comportamiento de anidación en la evaluación de reglas puede producir agregaciones de resultados inesperadas cuando la regla hace referencia a uno o más campos repetidos con un campo principal que también es un campo repetido. Las agregaciones no distintas, como sum(), array() y count(), no pueden tener en cuenta los valores duplicados en otros campos del mismo evento que produce el comportamiento de anidación. En la siguiente regla de ejemplo, el evento $e tiene un solo nombre de host google.com, pero el resultado hostnames se agrega en cuatro instancias no anidadas del mismo evento $e, cada una con un valor principal.hostname duplicado. Este resultado genera cuatro nombres de host en lugar de uno debido a la anulación del anidamiento de los valores repetidos en 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
}

Registro de eventos antes de la anulación del anidamiento del campo repetido

En la siguiente tabla, se muestra el registro de eventos antes de anular el anidamiento del campo repetido:

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

Registro de eventos después de anular la anidación de campos repetidos

En la siguiente tabla, se muestra el registro de eventos después de anular el anidamiento del campo repetido:

metadata.id	principal.application	principal.hostname	security_results.action
`aaaaaaaaa`	`Google SecOps`	`google.com`	PERMITIR
`aaaaaaaaa`	`Google SecOps`	`google.com`	REPROBADA
`aaaaaaaaa`	`Google SecOps`	`google.com`	DESAFÍO
`aaaaaaaaa`	`Google SecOps`	`google.com`	BLOQUEAR

Solución alternativa

Las agregaciones que ignoran o eliminan los valores duplicados no se ven afectadas por este comportamiento de anidación. Usa la versión distinta de una agregación si encuentras valores de resultados inesperados debido a la anidación.

Las siguientes agregaciones no se ven afectadas por el comportamiento de anidación descrito anteriormente.

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

Agregaciones de resultados con múltiples variables de eventos

Si una regla contiene varias variables de evento, hay un elemento separado en la agregación para cada combinación de eventos que se incluye en la detección. Por ejemplo, si la siguiente regla de ejemplo se ejecuta en los eventos enumerados:

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 suma se calcula para cada combinación de eventos, lo que te permite usar ambas variables de eventos en los cálculos del valor del resultado. En el cálculo, se usan los siguientes elementos:

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

Esto genera una suma máxima potencial de 6, aunque $e2 solo puede corresponder a 3 eventos distintos.

Esto afecta la suma, el recuento y el array. En el caso de los recuentos y los arrays, usar count_distinct o array_distinct puede resolver el problema, pero no hay una solución alternativa para la suma.

Paréntesis al comienzo de una expresión

Si usas paréntesis al comienzo de una expresión, se activará el siguiente error:

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

El siguiente ejemplo generaría este tipo de error:

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

Las siguientes variaciones de sintaxis devuelven el mismo resultado, pero con una sintaxis válida:

$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

El array de índice en el resultado requiere agregación para valores únicos en el campo repetido

La indexación de arrays en la sección de resultados aún requiere agregación. Por ejemplo, lo siguiente no funciona:

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

Sin embargo, puedes guardar el resultado del índice del array en una variable de marcador de posición y usar esa variable en la sección de resultados, como se muestra aquí:

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

outcome:
  $principal_user_department = $principal_user_dept

Condición OR con no existencia

Si se aplica una condición OR entre dos variables de eventos separadas y la regla coincide con la no existencia, la regla se compila correctamente, pero puede producir detecciones de falsos positivos. Por ejemplo, la siguiente sintaxis de regla puede coincidir con eventos que tienen $event_a.field = "something", aunque no debería hacerlo.

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

La solución alternativa consiste en separar las condiciones en dos bloques, en los que cada bloque solo aplica el filtro a una sola variable, como se muestra aquí:

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

Operaciones aritméticas con campos de eventos sin signo

Si intentas usar una constante de número entero en una operación aritmética con un campo de UDM cuyo tipo es un número entero sin signo, recibirás un error. Por ejemplo:

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

El campo udm.network.received_bytes es un número entero sin signo. Esto sucede porque las constantes de números enteros se establecen de forma predeterminada como números enteros con signo, que no funcionan con números enteros sin signo en las operaciones aritméticas.

La solución alternativa es forzar la constante de número entero a un número de punto flotante, que luego funcionará con el número entero sin signo. Por ejemplo:

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

Coherencia eventual y falsos positivos en el enriquecimiento de GeoIP

En las etapas iniciales de enriquecimiento (transmisión y sensibles a la latencia), el sistema prioriza la velocidad por sobre la precisión inmediata, lo que puede generar la falta de datos y posibles falsos positivos. El sistema seguirá enriqueciendo los datos en segundo plano, pero es posible que los datos no estén disponibles cuando se ejecute la regla. Esto forma parte del proceso normal de coherencia eventual. Para evitar este tipo de falsos positivos, no confíes en que los campos enriquecidos existan en los eventos para activar las detecciones.

Por ejemplo, considera este evento de regla:

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

La regla se basa en el hecho de que el evento debe tener $e.principal.ip_geo_artifact.network.asn = "16509" Y $e.principal.ip_geo_artifact.location.country_or_region = "United Kingdom", que son campos enriquecidos. Si el enriquecimiento no se completa a tiempo, la regla producirá un falso positivo.

Para evitar esto, una mejor verificación para esta regla sería la siguiente:

$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"

Esta regla elimina la posibilidad de que el evento se active con IPs con el ASN 16509, pero ubicadas fuera del Reino Unido. Esto mejora la precisión general de la regla.

¿Necesitas más ayuda? Obtén respuestas de miembros de la comunidad y profesionales de Google SecOps.