Bekannte Probleme und Einschränkungen bei YARA-L 2.0

In diesem Dokument werden die bekannten Probleme und Einschränkungen in YARA-L 2.0 beschrieben.

Ergebnisaggregationen mit dem Aufheben der Verschachtelung von wiederkehrenden Feldern

Wenn in einer Regel auf ein wiederholtes Feld in einer Ereignisvariablen mit mehreren Elementen verwiesen wird, wird jedes Element in eine separate Ereigniszeile aufgeteilt.

Die beiden IP-Adressen im wiederkehrenden Feld target.ip für das Ereignis $e werden beispielsweise in zwei Instanzen von $e aufgeteilt, die jeweils einen anderen target.ip-Wert haben.

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
}

Ereignisdatensatz vor dem Entschachteln des wiederholten Felds

In der folgenden Tabelle sehen Sie den Ereignisdatensatz vor dem Aufheben der Verschachtelung des wiederholten Felds:

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

Ereignisdatensätze nach dem Entschachteln des wiederholten Felds

In der folgenden Tabelle sehen Sie den Ereignisdatensatz nach dem Aufheben der Verschachtelung des wiederholten Felds:

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

Wenn in einer Regel auf ein wiederkehrendes Feld verwiesen wird, das in einem anderen Feld verschachtelt ist, z. B. security_results.action, wird die Verschachtelung sowohl auf der übergeordneten als auch auf der untergeordneten Ebene aufgehoben. Die resultierenden Instanzen aus dem Entschachteln eines einzelnen Ereignisses bilden ein kartesisches Produkt der Elemente in den übergeordneten und untergeordneten Feldern. In der folgenden Beispielregel wird das Ereignis $e mit zwei wiederholten Werten für security_results und zwei wiederholten Werten für security_results.actions in vier Instanzen entnestet.

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
}

Ereignisdatensatz vor dem Entschachteln des wiederholten Felds

In der folgenden Tabelle sehen Sie den Ereignisdatensatz vor dem Aufheben der Verschachtelung des wiederholten Felds:

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

Ereignisdatensätze nach dem wiederholten Entnesten von Feldern

In der folgenden Tabelle sehen Sie den Ereignisdatensatz nach dem Aufheben der Verschachtelung des wiederholten Felds:

metadata.id	principal.application	security_results.actions
`aaaaaaaaa`	`Google SecOps`	ZULASSEN
`aaaaaaaaa`	`Google SecOps`	NICHT BESTANDEN
`aaaaaaaaa`	`Google SecOps`	CHALLENGE
`aaaaaaaaa`	`Google SecOps`	BLOCKIEREN

Dieses Verhalten beim Entschachteln bei der Regelauswertung kann zu unerwarteten Ergebnisaggregationen führen, wenn in der Regel auf ein oder mehrere wiederholte Felder mit einem übergeordneten Feld verwiesen wird, das ebenfalls ein wiederholtes Feld ist. Bei nicht eindeutigen Aggregationen wie sum(), array() und count() können doppelte Werte in anderen Feldern desselben Ereignisses, die durch das Unnesting-Verhalten erzeugt werden, nicht berücksichtigt werden. In der folgenden Beispielregel hat das Ereignis $e einen einzelnen Hostnamen google.com, das Ergebnis hostnames wird jedoch über vier nicht verschachtelte Instanzen desselben Ereignisses $e aggregiert, die jeweils einen doppelten principal.hostname-Wert haben. Das Ergebnis sind vier Hostnamen statt einem, da die wiederholten Werte für security_results.actions entnestet werden.

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
}

Ereignisdatensatz vor dem Entschachteln des wiederholten Felds

In der folgenden Tabelle sehen Sie den Ereignisdatensatz vor dem Aufheben der Verschachtelung des wiederholten Felds:

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

Datensatz nach dem Entschachteln eines wiederkehrenden Felds

In der folgenden Tabelle sehen Sie den Ereignisdatensatz nach dem Aufheben der Verschachtelung des wiederholten Felds:

metadata.id	principal.application	principal.hostname	security_results.action
`aaaaaaaaa`	`Google SecOps`	`google.com`	ZULASSEN
`aaaaaaaaa`	`Google SecOps`	`google.com`	NICHT BESTANDEN
`aaaaaaaaa`	`Google SecOps`	`google.com`	CHALLENGE
`aaaaaaaaa`	`Google SecOps`	`google.com`	BLOCKIEREN

Problemumgehung

Aggregationen, bei denen doppelte Werte ignoriert oder entfernt werden, sind von diesem Verhalten nicht betroffen. Verwenden Sie die eindeutige Version einer Aggregation, wenn aufgrund des Aufhebens der Verschachtelung unerwartete Ergebniswerte auftreten.

Die folgenden Aggregationen sind nicht vom oben beschriebenen Unnesting-Verhalten betroffen.

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

Ergebnisaggregationen mit mehreren Ereignisvariablen

Wenn eine Regel mehrere Ereignisvariablen enthält, gibt es in der Aggregation für jede Kombination von Ereignissen, die in der Erkennung enthalten ist, einen separaten Eintrag. Wenn die folgende Beispielregel beispielsweise für die aufgeführten Ereignisse ausgeführt wird:

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"

Die Summe wird für jede Kombination von Ereignissen berechnet. So können Sie beide Ereignisvariablen in den Berechnungen des Ergebniswerts verwenden. Die folgenden Elemente werden bei der Berechnung verwendet:

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

Das führt zu einer potenziellen maximalen Summe von 6, obwohl $e2 nur drei verschiedenen Ereignissen entsprechen kann.

Das wirkt sich auf Summe, Anzahl und Array aus. Bei „count“ und „array“ kann das Problem mit count_distinct oder array_distinct behoben werden. Für „sum“ gibt es jedoch keine Problemumgehung.

Klammern am Anfang eines Ausdrucks

Wenn Sie am Anfang eines Ausdrucks Klammern verwenden, wird der folgende Fehler ausgelöst:

parsing: error with token: ")"
invalid operator in events predicate

Das folgende Beispiel würde diesen Fehlertyp generieren:

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

Die folgenden Syntaxvarianten geben dasselbe Ergebnis zurück, aber mit gültiger Syntax:

$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

Für einzelne Werte im wiederholten Feld ist eine Aggregation des Index-Arrays im Ergebnis erforderlich

Für die Array-Indexierung im Ergebnisbereich ist weiterhin eine Aggregation erforderlich. Das folgende Beispiel funktioniert beispielsweise nicht:

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

Sie können die Ausgabe des Array-Index jedoch in einer Platzhaltervariablen speichern und diese Variable im Ergebnisabschnitt verwenden, wie hier gezeigt:

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

outcome:
  $principal_user_department = $principal_user_dept

OR-Bedingung mit Nichtvorhandensein

Wenn eine ODER-Bedingung zwischen zwei separaten Ereignisvariablen angewendet wird und die Regel auf Nichtvorhandensein abgestimmt ist, wird die Regel zwar erfolgreich kompiliert, kann aber Falsch-Positiv-Ergebnisse liefern. Die folgende Regelsyntax kann beispielsweise mit Ereignissen mit $event_a.field = "something" übereinstimmen, obwohl das nicht der Fall sein sollte.

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

Die Problemumgehung besteht darin, die Bedingungen in zwei Blöcke aufzuteilen, wobei in jedem Block der Filter nur auf eine einzelne Variable angewendet wird, wie hier gezeigt:

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

Arithmetik mit nicht signierten Ereignisfeldern

Wenn Sie versuchen, eine Ganzzahlkonstante in einer arithmetischen Operation mit einem UDM-Feld zu verwenden, dessen Typ eine vorzeichenlose Ganzzahl ist, erhalten Sie eine Fehlermeldung. Beispiel:

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

Das Feld udm.network.received_bytes ist eine vorzeichenlose Ganzzahl. Das liegt daran, dass Ganzzahlkonstanten standardmäßig vorzeichenbehaftete Ganzzahlen sind, die bei arithmetischen Operationen nicht mit vorzeichenlosen Ganzzahlen funktionieren.

Die Problemumgehung besteht darin, die Ganzzahlkonstante in eine Gleitkommazahl umzuwandeln, die dann mit der vorzeichenlosen Ganzzahl funktioniert. Beispiel:

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

Eventual Consistency und falsch positive Ergebnisse bei der GeoIP-Anreicherung

In den ersten Phasen der Anreicherung (Streaming und latenzempfindlich) wird Geschwindigkeit gegenüber sofortiger Genauigkeit priorisiert. Das kann zu fehlenden Daten und potenziellen Falschmeldungen führen. Die Daten werden weiterhin im Hintergrund angereichert, sind aber möglicherweise nicht verfügbar, wenn die Regel ausgeführt wird. Das ist Teil des normalen Prozesses der eventuellen Konsistenz. Um diese Art von falsch positiven Ergebnissen zu vermeiden, sollten Sie sich nicht darauf verlassen, dass angereicherte Felder in Ereignissen vorhanden sind, um Erkennungen auszulösen.

Sehen wir uns beispielsweise dieses Regelereignis an:

$e.principal.ip_geo_artifact.network.asn = "16509" AND
$e.principal.ip_geo_artifact.location.country_or_region = "United Kingdom"

Die Regel basiert darauf, dass das Ereignis $e.principal.ip_geo_artifact.network.asn = "16509" UND $e.principal.ip_geo_artifact.location.country_or_region = "United Kingdom" enthalten muss. Beide sind angereicherte Felder. Wenn die Anreicherung nicht rechtzeitig abgeschlossen wird, wird durch die Regel ein Fehlalarm ausgelöst.

Um dies zu vermeiden, sollte die Regel so formuliert werden:

$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"

Diese Regel schließt die Möglichkeit aus, dass das Ereignis durch IP-Adressen mit der ASN 16509 ausgelöst wird, die sich außerhalb des Vereinigten Königreichs befinden. Dadurch wird die Gesamtgenauigkeit der Regel verbessert.

Benötigen Sie weitere Hilfe? Antworten von Community-Mitgliedern und Google SecOps-Experten erhalten