Se usó la API de Cloud Translation para traducir esta página.

Problemas y limitaciones conocidos de YARA-L

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

Agregaciones de resultados con desanidado de campos repetidos

Cuando una regla hace referencia a un campo repetido en una variable de evento y ese campo repetido contiene más de un elemento, cada elemento se desanida en una fila de evento independiente.

Por ejemplo, las dos cadenas de direcciones IP en el campo repetido target.ip del evento $e en la siguiente regla se desanidan en dos instancias del evento $e, cada una con un elemento 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 evento antes de desenredar el campo repetido

En la siguiente tabla, se muestra el registro del evento antes de desenredar el 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 anidar campos repetidos

En la siguiente tabla, se muestra el registro del evento después de anidar campos de forma repetida:

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 que es un elemento secundario de otro campo repetido, como security_results.action, el desanidado ocurre en ambos. el nivel del campo superior y el nivel del campo secundario. El conjunto resultante de instancias UNNEST a partir de un solo evento es el producto cartesiano de los elementos en el campo superior y los elementos en el campo 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 anidan 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 evento antes de desanidar campos repetidos

En la siguiente tabla, se muestra el registro del evento antes de desenredar el campo repetido:

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

Registros de eventos después de desanidar campos repetidos

En la siguiente tabla, se muestra el registro del evento después de anidar campos de forma repetida:

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

Este comportamiento de desanidado en la evaluación de reglas puede producir agregaciones de resultado cuando la regla hace referencia a uno o más campos repetidos con un campo superior que también es un campo repetido. Agregaciones no distintivas como sum(), array() y count(), no pueden dar cuenta de valores duplicados en otros campos en el mismo evento producidos por el comportamiento de desanidar. En la siguiente regla de ejemplo, el evento $e tiene un solo nombre de host google.com, pero el resultado hostnames agrega 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 al anidamiento de 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 evento antes de desenredar el campo repetido

En la siguiente tabla, se muestra el registro del evento antes de desenredar el campo repetido:

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

Registro de evento después de desanidar campos repetidos

En la siguiente tabla, se muestra el registro del evento después de anidar campos de forma repetida:

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

Solución alternativa

Las agregaciones que ignoran los valores duplicados o eliminan los valores duplicados no se afectadas por este comportamiento de desanidar. Usa la versión distintiva de un si encuentras valores de resultado inesperados debido al desanidado.

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 evento

Si una regla contiene varias variables de evento, hay un elemento independiente 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 en la lista:

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 sobre cada combinación de eventos, lo que te permite usar ambos variables de evento en los cálculos del valor del resultado. Los siguientes elementos son en el cálculo:

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 da como resultado una suma máxima potencial de 6, aunque $e2 solo puede corresponden a 3 eventos distintos.

Esto afecta a la suma, el recuento y el array. Para conteo y array, usa count_distinct. o array_distinct pueden resolver el problema, pero actualmente no hay una solución alternativa .

Paréntesis al comienzo de una expresión

El uso de paréntesis al comienzo de una expresión activa 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 muestran 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 la agregación de valores únicos en un campo repetido.

El indexado 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 de 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 O con no existencia

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

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

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

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

Aritmética con campos de evento sin firmar

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, se mostrará un error. Por ejemplo:

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

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

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

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