Esta página foi traduzida pela API Cloud Translation.

Problemas conhecidos e limitações da YARA-L

Este documento descreve os problemas conhecidos e as limitações no YARA-L.

Agregações de resultados com a anulação da aninhagem de campos repetidos

Quando uma regra faz referência a um campo repetido numa variável de evento com vários elementos, cada elemento é dividido numa 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
}

Registo de eventos antes da anulação da aninhagem do campo repetido

A tabela seguinte mostra o registo de eventos antes de desagrupar o campo repetido:

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

Registos de eventos após desagrupar o campo repetido

A tabela seguinte mostra o registo de eventos após a anulação da aninhagem 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 noutro, como security_results.action, a anulação do aninhamento ocorre ao nível principal e secundário. As instâncias resultantes da anulação da aninhagem de um único evento formam um produto cartesiano dos elementos nos campos principal e secundário. Na regra de exemplo seguinte, o evento $e com dois valores repetidos em security_results e dois valores repetidos em security_results.actions são desagrupados 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
}

Registo de eventos antes da anulação da aninhagem do campo repetido

A tabela seguinte mostra o registo de eventos antes de desagrupar o campo repetido:

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

Registos de eventos após a anulação da aninhagem de campos repetidos

A tabela seguinte mostra o registo de eventos após a anulação da aninhagem do campo repetido:

metadata.id	principal.application	security_results.actions
`aaaaaaaaa`	`Google SecOps`	PERMITIR
`aaaaaaaaa`	`Google SecOps`	FAIL
`aaaaaaaaa`	`Google SecOps`	DESAFIO
`aaaaaaaaa`	`Google SecOps`	BLOQUEAR

Este comportamento de anulação da aninhagem na avaliação de regras pode produzir agregações de resultados inesperadas quando a regra faz referência a um ou mais campos repetidos com um campo principal que também é um campo repetido. As agregações não distintas, como sum(), array() e count(), não podem ter em conta os valores duplicados noutros campos no mesmo evento produzido pelo comportamento de desagrupação. Na regra do exemplo seguinte, o evento $e tem um único nome de anfitrião google.com, mas o resultado hostnames agrega-se em quatro instâncias não aninhadas do mesmo evento $e, cada uma com um valor principal.hostname duplicado. Este resultado gera quatro nomes de anfitriões em vez de um devido à anulação da aninhagem 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
}

Registo de eventos antes da anulação da aninhagem do campo repetido

A tabela seguinte mostra o registo de eventos antes de desagrupar o campo repetido:

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

Registo de eventos após a anulação da aninhagem de campos repetidos

A tabela seguinte mostra o registo de eventos após a anulação da aninhagem do 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`	DESAFIO
`aaaaaaaaa`	`Google SecOps`	`google.com`	BLOQUEAR

Solução alternativa

As agregações que ignoram valores duplicados ou eliminam valores duplicados não são afetadas por este comportamento de desagrupamento. Use a versão distinta de uma agregação se estiver a encontrar valores de resultados inesperados devido à anulação da aninhagem.

As agregações seguintes não são afetadas pelo comportamento de anulação da aninhagem descrito anteriormente.

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

Agregações de resultados com várias variáveis de eventos

Se uma regra contiver várias variáveis de eventos, existe um item separado na agregação para cada combinação de eventos incluída na deteção. Por exemplo, se a seguinte regra de exemplo for executada em relação aos eventos indicados:

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, o que lhe permite usar variáveis de eventos nos cálculos do 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

Isto resulta numa soma máxima potencial de 6, embora $e2 só possa corresponder a 3 eventos distintos.

Isto afeta a soma, a contagem e a matriz. Para a contagem e a matriz, a utilização de count_distinct ou array_distinct pode resolver o problema, mas não existe uma solução alternativa para a soma.

Parênteses no início de uma expressão

A utilização 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 seguinte geraria este tipo de erro:

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

As seguintes variações de sintaxe devolvem o mesmo resultado, mas com uma 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 requer agregação para valores únicos no campo repetido

A indexação de matrizes na secção de resultados continua a exigir agregação. Por exemplo, o seguinte não funciona:

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

No entanto, pode guardar a saída do índice da matriz numa variável de marcador de posição e usar essa variável na secção de resultados, conforme mostrado aqui:

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

outcome:
  $principal_user_department = $principal_user_dept

Condição OU com não existência

Se for aplicada uma condição OR entre duas variáveis de eventos separadas e se a regra corresponder à não existência, a regra é compilada com êxito, mas pode produzir deteções de falsos positivos. Por exemplo, a seguinte sintaxe de regra pode corresponder a eventos com $event_a.field = "something", embora não devesse.

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

A solução alternativa consiste em separar as condições em dois blocos em que cada bloco aplica o filtro apenas 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 tentar usar uma constante inteira numa operação aritmética com um campo UDM cujo tipo seja um inteiro não assinado, recebe um erro. Por exemplo:

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

O campo udm.network.received_bytes é um número inteiro não assinado. Isto acontece porque as constantes inteiras são, por predefinição, 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 a um número de ponto flutuante, que funciona com o número inteiro não assinado. Por exemplo:

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

Consistência eventual e falsos positivos no enriquecimento de GeoIP

O sistema dá prioridade à velocidade em detrimento da precisão imediata nas fases de enriquecimento iniciais (streaming e sensíveis à latência), o que pode levar à falta de dados e a potenciais falsos positivos. O sistema continua a enriquecer os dados em segundo plano, mas os dados podem não estar disponíveis quando a regra é executada. Isto faz parte do processo normal de consistência eventual. Para evitar estes tipos de falsos positivos, não confie na existência de campos enriquecidos em eventos para acionar deteções.

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 baseia-se no facto de o evento ter de 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 produz um falso positivo.

Para evitar esta situação, uma melhor verificação desta 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"

Esta regra elimina a possibilidade de o evento ser acionado por IPs com o ASN 16509, mas localizados fora do Reino Unido. Isto melhora a precisão geral da regra.