Limitações e problemas conhecidos da YARA-L
Este documento descreve os problemas e as limitações conhecidos do YARA-L.
Agregações de resultados com campos repetidos desaninhados
Quando uma regra faz referência a um campo repetido em uma variável de evento com vários elementos, cada elemento é dividido em uma linha de evento separada.
Por exemplo, os dois endereços IP no campo repetido target.ip no evento $e são divididos em duas instâncias de $e, cada uma com um 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 evento antes da eliminação de aninhamento de campo repetido
A tabela a seguir mostra o registro de evento antes de desaninhar o campo repetido:
| metadata.id | principal.application | target.ip |
|---|---|---|
aaaaaaaaa |
Google SecOps |
[192.0.2.20, 192.0.2.28] |
Registros de eventos após a eliminação do campo repetido
A tabela a seguir mostra o registro de evento após a eliminação do campo repetido:
| metadata.id | principal.application | target.ip |
|---|---|---|
aaaaaaaaa |
Google SecOps |
192.0.2.20 |
aaaaaaaaa |
Google SecOps |
192.0.2.28 |
Quando uma regra faz referência a um campo repetido aninhado em outro, como security_results.action, a desaninhação ocorre nos níveis pai e filho. As instâncias resultantes de desaninhamento de um único evento formam um produto cartesiano dos elementos nos campos pai e filho.
No exemplo de regra abaixo, o evento $e com dois valores repetidos em security_results e dois valores
repetidos em security_results.actions são desencapsulados em quatro instâncias.
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 da eliminação de aninhamento de campo repetido
A tabela a seguir mostra o registro de evento antes de desaninhar o campo repetido:
| metadata.id | principal.application | security_results |
|---|---|---|
aaaaaaaaa |
Google SecOps |
[ { actions: [ ALLOW, FAIL ] }, { actions: [ CHALLENGE, BLOCK ] } ] |
Registros de eventos após a eliminação de aninhamento de campo repetido
A tabela a seguir mostra o registro de evento após a eliminação do campo repetido:
| metadata.id | principal.application | security_results.actions |
|---|---|---|
aaaaaaaaa |
Google SecOps |
PERMITIR |
aaaaaaaaa |
Google SecOps |
FALHA |
aaaaaaaaa |
Google SecOps |
DESAFIO |
aaaaaaaaa |
Google SecOps |
BLOQUEIO |
Esse comportamento de desaninhamento na avaliação de regras pode produzir agregações de resultados inesperados quando a regra faz referência a um ou mais campos repetidos com um campo pai que também é repetido. Agregações não distintas, como sum(), array() e count(), não podem representar valores duplicados em outros campos no mesmo evento produzido pelo comportamento de desaninhamento. Na regra de exemplo a seguir, o evento $e tem um único nome de host google.com, mas o resultado hostnames agrega quatro instâncias não aninhadas do mesmo evento $e, cada uma com um valor principal.hostname duplicado. Esse resultado gera quatro nomes de host em vez de um,
devido à eliminação de valores repetidos em 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 da eliminação de aninhamento de campo repetido
A tabela a seguir mostra o registro de evento antes de desaninhar o campo repetido:
| metadata.id | principal.application | principal.hostname | security_results |
|---|---|---|---|
aaaaaaaaa |
Google SecOps |
google.com |
[ { action: [ ALLOW, FAIL ] }, { action: [ CHALLENGE, BLOCK ] } ] |
Registro de evento após a eliminação de aninhamento de campo repetido
A tabela a seguir mostra o registro de evento após a eliminação do campo repetido:
| metadata.id | principal.application | principal.hostname | security_results.action |
|---|---|---|---|
aaaaaaaaa |
Google SecOps |
google.com |
PERMITIR |
aaaaaaaaa |
Google SecOps |
google.com |
FALHA |
aaaaaaaaa |
Google SecOps |
google.com |
DESAFIO |
aaaaaaaaa |
Google SecOps |
google.com |
BLOQUEIO |
Alternativa
As agregações que ignoram ou eliminam valores duplicados não são afetadas por esse comportamento de desaninhamento. Use a versão distinta de uma agregação se você encontrar valores de resultado inesperados devido à desaninhação.
As agregações a seguir não são afetadas pelo comportamento de desencapsulamento descrito anteriormente.
max()min()array_distinct()count_distinct()
Agregações de resultados com várias variáveis de evento
Se uma regra tiver várias variáveis de evento, haverá um item separado na agregação para cada combinação de eventos incluída na detecção. Por exemplo, se a regra de exemplo a seguir for executada nos eventos listados:
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"
A soma é calculada em todas as combinações de eventos, permitindo que você use as duas variáveis de evento nos cálculos de valor do resultado. Os seguintes elementos são usados no 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
Isso resulta em uma soma máxima potencial de 6, mesmo que $e2 só possa corresponder a três eventos distintos.
Isso afeta a soma, a contagem e a matriz. Para contagem e matriz, o uso de count_distinct
ou array_distinct pode resolver o problema, mas não há solução alternativa
para a soma.
Parênteses no início de uma expressão
O uso de parênteses no início de uma expressão aciona o seguinte erro:
parsing: error with token: ")"
invalid operator in events predicate
O exemplo a seguir geraria esse tipo de erro:
($event.metadata.ingested_timestamp.seconds -
$event.metadata.event_timestamp.seconds) / 3600 > 1
As variações de sintaxe a seguir retornam o mesmo resultado, mas com sintaxe 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
A matriz de índice no resultado exige agregação para valores únicos em um campo repetido
A indexação de matrizes na seção de resultados ainda requer agregação. Por exemplo, o seguinte não funciona:
outcome:
$principal_user_dept = $suspicious.principal.user.department[0]
No entanto, é possível salvar a saída do índice de matriz em uma variável de marcador de posição e usar essa variável na seção de resultados, conforme mostrado aqui:
events:
$principal_user_dept = $suspicious.principal.user.department[0]
outcome:
$principal_user_department = $principal_user_dept
Condição OR com inexistência
Se uma condição OR for aplicada entre duas variáveis de evento separadas e se a
regra corresponder à não existência, a regra será compilada, mas poderá produzir
detecções de falso positivo. Por exemplo, a sintaxe de regra a seguir pode corresponder
a eventos com $event_a.field = "something", mesmo que não deva.
events:
not ($event_a.field = "something" **or** $event_b.field = "something")
condition:
$event_a and #event_b >= 0
A solução alternativa é separar as condições em dois blocos, em que cada bloco apenas aplica o filtro a uma única variável, conforme mostrado aqui:
events:
not ($event_a.field = "something")
not ($event_b.field = "something")
condition:
$event_a and #event_b >= 0
Aritmética com campos de eventos não assinados
Se você tentar usar uma constante de número inteiro em uma operação aritmética com um campo de UDM cujo tipo é um número inteiro não assinado, vai receber um erro. Exemplo:
events:
$total_bytes = $e.network.received_bytes * 2
O campo udm.network.received_bytes é um número inteiro sem sinal. Isso acontece devido
às constantes inteiras que são definidas como números inteiros com sinal, que não funcionam com
números inteiros sem sinal em operações aritméticas.
A solução alternativa é forçar a constante inteira para um float que vai funcionar com o número inteiro sem sinal. Exemplo:
events:
$total_bytes = $e.network.received_bytes * (2/1)
Consistência posterior e falsos positivos no enriquecimento de GeoIP
O sistema prioriza a velocidade em vez da precisão imediata nos estágios iniciais de enriquecimento (streaming e sensível à latência), o que pode levar à falta de dados e possíveis falsos positivos. O sistema continua enriquecendo os dados em segundo plano, mas eles podem não estar disponíveis quando a regra é executada. Isso faz parte do processo normal de consistência eventual. Para evitar esses tipos de falsos positivos, não confie em campos enriquecidos para acionar detecções em eventos.
Por exemplo, considere este evento de regra:
$e.principal.ip_geo_artifact.network.asn = "16509" AND
$e.principal.ip_geo_artifact.location.country_or_region = "United Kingdom"
A regra depende do fato de que o evento precisa ter $e.principal.ip_geo_artifact.network.asn = "16509" E $e.principal.ip_geo_artifact.location.country_or_region = "United Kingdom", que são campos enriquecidos. Se o enriquecimento não for concluído a tempo, a regra vai produzir um falso positivo.
Para evitar isso, uma verificação melhor para essa regra seria:
$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"
Essa regra elimina a possibilidade de o evento ser acionado por IPs com o ASN 16509, mas localizado fora do Reino Unido. Isso melhora a precisão geral da regra.