Limitações e problemas conhecidos do YARA-L 2.0

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

Agregações de resultados com remoção do aninhamento de campos repetidos

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 remoção do aninhamento de campos repetidos

A tabela a seguir mostra o registro de evento antes de remover o aninhamento do 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 remoção do aninhamento do campo repetido

A tabela a seguir mostra o registro de evento após a remoção do aninhamento 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, o desencapsulamento ocorre nos níveis pai e filho. As instâncias resultantes da remoção do aninhamento de um único evento formam um produto cartesiano dos elementos nos campos pai e filho. Na regra de exemplo a seguir, 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
}

Registro de evento antes da remoção do aninhamento de campos repetidos

A tabela a seguir mostra o registro de evento antes de remover o aninhamento do campo repetido:

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

Registros de eventos após a remoção do aninhamento de campos repetidos

A tabela a seguir mostra o registro de evento após a remoção do aninhamento do campo repetido:

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

Esse comportamento de remoção do aninhamento na avaliação de regras pode gerar agregações de resultados inesperadas quando a regra faz referência a um ou mais campos repetidos com um campo principal que também é repetido. Agregações não distintas, como sum(), array() e count(), não podem considerar valores duplicados em outros campos no mesmo evento produzido pelo comportamento de remoção do aninhamento. Na regra de exemplo a seguir, o evento $e tem um único nome do 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 à remoção do aninhamento 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 remoção do aninhamento de campos repetidos

A tabela a seguir mostra o registro de evento antes de remover o aninhamento do 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 remoção do aninhamento de campos repetidos

A tabela a seguir mostra o registro de evento após a remoção do aninhamento do campo repetido:

metadata.id	principal.application	principal.hostname	security_results.action
`aaaaaaaaa`	`Google SecOps`	`google.com`	PERMITIR
`aaaaaaaaa`	`Google SecOps`	`google.com`	REPROVADO
`aaaaaaaaa`	`Google SecOps`	`google.com`	DESAFIO
`aaaaaaaaa`	`Google SecOps`	`google.com`	BLOQUEAR

Alternativa

As agregações que ignoram ou eliminam valores duplicados não são afetadas por esse comportamento de remoção do aninhamento. Use a versão distinta de uma agregação se você estiver encontrando valores de resultado inesperados devido à remoção do aninhamento.

As agregações a seguir não são afetadas pelo comportamento de remoção do aninhamento 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 seguinte regra de exemplo 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 3 eventos distintos.

Isso afeta as funções SUM, COUNT e ARRAY. Para contagem e matriz, usar count_distinct ou array_distinct pode resolver o problema, mas não há uma solução alternativa para a soma.

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

Usar 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 no campo repetido

A indexação de matrizes na seção de resultado ainda exige 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 da matriz em uma variável de marcador de posição e usar essa variável na seção de resultado, como mostrado aqui:

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

outcome:
  $principal_user_department = $principal_user_dept

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

Se uma condição OR for aplicada entre duas variáveis de evento separadas e a regra corresponder à não existência, a regra será compilada, mas poderá produzir detecções de falsos positivos. Por exemplo, a seguinte sintaxe de regra pode corresponder a eventos com $event_a.field = "something", mesmo que 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 é separar as condições em dois blocos, em que cada bloco 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 sem sinal

Se você tentar usar uma constante inteira em uma operação aritmética com um campo de UDM cujo tipo é um número inteiro sem sinal, 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 porque as constantes inteiras usam números inteiros com sinal por padrão, 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 ponto flutuante, que funcionará com o 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 acurácia imediata nas etapas iniciais de enriquecimento (sensíveis a streaming e latência), o que pode levar à perda de dados e a possíveis falsos positivos. O sistema vai continuar enriquecendo os dados em segundo plano, mas eles podem não estar disponíveis quando a regra for executada. Isso faz parte do processo normal de consistência posterior. Para evitar esses tipos de falsos positivos, não confie na existência de campos enriquecidos em eventos para acionar detecçõ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 se baseia no 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 gerar 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 localizados fora do Reino Unido. Isso melhora a precisão geral da regra.

Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.