Limitaciones y problemas conocidos de YARA-L
En este documento se describen los problemas conocidos y las limitaciones de YARA-L.
Agregaciones de resultados con desanidació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 del evento $e se dividen en dos instancias de $e, cada una con un valor de 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 anidar campos repetidos
En la tabla siguiente se muestra el registro de eventos antes de anidar 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 anular el anidamiento del campo repetido
En la tabla siguiente 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 en otro, como security_results.action, el desanidamiento se produce tanto en el nivel superior como en el secundario. Las instancias resultantes de la desanidación de un solo evento forman un producto cartesiano de los elementos de los campos superior 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 desanida 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 anidar campos repetidos
En la tabla siguiente se muestra el registro de eventos antes de anidar 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 tabla siguiente 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 |
FAIL |
aaaaaaaaa |
Google SecOps |
CHALLENGE |
aaaaaaaaa |
Google SecOps |
BLOQUEAR |
Este comportamiento de desanidación en la evaluación de reglas puede producir agregaciones de resultados inesperadas cuando la regla hace referencia a uno o varios 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 de otros campos del mismo evento producidos por el comportamiento de desanidación. En la siguiente regla de ejemplo, el evento $e tiene un solo nombre de host google.com, pero el resultado hostnames agrega cuatro instancias sin anidar del mismo evento $e, cada una con un valor principal.hostname duplicado. Como resultado, se obtienen cuatro nombres de host en lugar de uno debido a la desanidación 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 anidar campos repetidos
En la tabla siguiente se muestra el registro de eventos antes de anidar el 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 desanidar un campo repetido
En la tabla siguiente 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 |
FAIL |
aaaaaaaaa |
Google SecOps |
google.com |
CHALLENGE |
aaaaaaaaa |
Google SecOps |
google.com |
BLOQUEAR |
Solución
Las agregaciones que ignoran o eliminan los valores duplicados no se ven afectadas por este comportamiento de desanidación. Usa la versión distinta de una agregación si obtienes valores inesperados debido a la anidación.
Las siguientes agregaciones no se ven afectadas por el comportamiento de desanidación descrito anteriormente.
max()min()array_distinct()count_distinct()
Agregaciones de resultados con varias variables de evento
Si una regla contiene varias variables de evento, habrá un elemento independiente en la agregación para cada combinación de eventos que se incluya en la detección. Por ejemplo, si se ejecuta la siguiente regla de ejemplo 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 en todas las combinaciones de eventos, lo que le permite usar ambas variables de evento en los cálculos del valor del resultado. En el cálculo se utilizan 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 da como resultado una suma máxima potencial de 6, aunque $e2 solo puede corresponder a 3 eventos distintos.
Esto afecta a la suma, el recuento y la matriz. En el caso de los recuentos y las matrices, se puede solucionar el problema usando count_distinct
o array_distinct, pero no hay ninguna solución alternativa
para las sumas.
Paréntesis al principio de una expresión
Si se usan paréntesis al principio de una expresión, se produce el siguiente error:
parsing: error with token: ")"
invalid operator in events predicate
En el siguiente ejemplo se 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
La matriz de índice del resultado requiere una agregación para los valores únicos de un campo repetido
La indexación de arrays en la sección de resultados sigue requiriendo agregación. Por ejemplo, no funciona lo siguiente:
outcome:
$principal_user_dept = $suspicious.principal.user.department[0]
Sin embargo, puedes guardar la salida del índice de la matriz en una variable de marcador de posición y usarla en la sección de resultados, como se muestra a continuación:
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 evento independientes y la regla coincide con la no existencia, la regla se compila correctamente, pero puede producir detecciones falsas positivas. Por ejemplo, la siguiente sintaxis de regla puede coincidir con eventos que tengan $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 consiste en separar las condiciones en dos bloques, de forma que cada bloque solo aplique el filtro a una 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 eventos sin signo
Si intentas usar una constante entera en una operación aritmética con un campo de UDM cuyo tipo sea un entero sin signo, se producirá 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 ocurre porque las constantes enteras se definen de forma predeterminada como números enteros con signo, que no funcionan con números enteros sin signo en operaciones aritméticas.
La solución alternativa es forzar la constante entera a un valor flotante, que funcionará con el entero sin signo. Por ejemplo:
events:
$total_bytes = $e.network.received_bytes * (2/1)
Coherencia retardada y falsos positivos en el enriquecimiento de GeoIP
El sistema prioriza la velocidad sobre la precisión inmediata en las fases iniciales de enriquecimiento (Streaming y Latency-Sensitive), lo que puede provocar que falten datos y que se produzcan 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 consistencia final. Para evitar este tipo de falsos positivos, no confíe en que los campos enriquecidos estén presentes en los eventos para activar las detecciones.
Por ejemplo, supongamos que se da el siguiente 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 generará un falso positivo.
Para evitarlo, una mejor comprobación de 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 por IPs con el ASN 16509, pero que se encuentren fuera del Reino Unido. De esta forma, se mejora la precisión general de la regla.