Diese Seite wurde von der Cloud Translation API übersetzt.

Bekannte Probleme und Einschränkungen bei YARA-L

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

Ergebnisaggregationen mit Aufheben der Verschachtelung von wiederkehrenden Feldern

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

Angenommen, die beiden IP-Adressen im wiederkehrenden Feld target.ip des Ereignisses $e werden 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 Aufheben der Verschachtelung eines wiederkehrenden Felds

In der folgenden Tabelle ist der Ereigniseintrag zu sehen, bevor das wiederholte Feld entschachtelt wurde:

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

Ereignisdatensätze nach dem Aufheben der Verschachtelung des wiederholten Felds

In der folgenden Tabelle ist der Ereignisdatensatz zu sehen, nachdem das verschachtelte Feld entschachtelt wurde:

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

Wenn eine Regel auf ein wiederkehrendes Feld verweist, das in einem anderen verschachtelt ist, z. B. security_results.action, wird die Verschachtelung sowohl auf der übergeordneten als auch auf der untergeordneten Ebene aufgehoben. Die Instanzen, die durch das Aufheben des Verschachtelungsverhältnisses eines einzelnen Ereignisses entstehen, bilden ein kartesisches Produkt der Elemente in den übergeordneten und untergeordneten Feldern. In der folgenden Beispielregel werden die verschachtelten Instanzen des Ereignisses $e mit zwei sich wiederholenden Werten für security_results und zwei sich wiederholenden Werten für security_results.actions in vier Instanzen aufgelöst.

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 Aufheben der Verschachtelung eines wiederkehrenden Felds

In der folgenden Tabelle ist der Ereigniseintrag zu sehen, bevor das wiederholte Feld entschachtelt wurde:

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

Ereignisaufnahmen nach dem Aufheben des Verschachtelungsstatus von wiederholten Feldern

In der folgenden Tabelle ist der Ereignisdatensatz zu sehen, nachdem das verschachtelte Feld entschachtelt wurde:

metadata.id	principal.application	security_results.actions
`aaaaaaaaa`	`Google SecOps`	ZULASSEN
`aaaaaaaaa`	`Google SecOps`	FEHLER
`aaaaaaaaa`	`Google SecOps`	HERAUSFORDERUNG
`aaaaaaaaa`	`Google SecOps`	BLOCKIEREN

Dieses Entschachtelungsverhalten bei der Regelauswertung kann zu unerwarteten Ergebnisaggregationen führen, wenn die Regel auf ein oder mehrere wiederholte Felder mit einem übergeordneten Feld verweist, das ebenfalls ein wiederholtes Feld ist. Bei nicht eindeutigen Aggregationen wie sum(), array() und count() können keine doppelten Werte in anderen Feldern desselben Ereignisses berücksichtigt werden, die durch das Aufheben des Verschachtelungsstatus entstehen. In der folgenden Beispielregel hat Ereignis $e einen einzelnen Hostnamen google.com, das Ergebnis hostnames wird jedoch über vier nicht verschachtelte Instanzen desselben Ereignisses $e aggregiert, die jeweils einen duplizierten Wert für principal.hostname haben. Da wiederholte Werte in security_results.actions entschachtelt werden, werden vier statt eines Hostnamens zurückgegeben.

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 Aufheben der Verschachtelung eines wiederkehrenden Felds

In der folgenden Tabelle ist der Ereigniseintrag zu sehen, bevor das wiederholte Feld entschachtelt wurde:

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

Ereignisdatensatz nach dem Aufheben der Verschachtelung eines wiederkehrenden Felds

In der folgenden Tabelle ist der Ereignisdatensatz zu sehen, nachdem das verschachtelte Feld entschachtelt wurde:

metadata.id	principal.application	principal.hostname	security_results.action
`aaaaaaaaa`	`Google SecOps`	`google.com`	ZULASSEN
`aaaaaaaaa`	`Google SecOps`	`google.com`	FEHLER
`aaaaaaaaa`	`Google SecOps`	`google.com`	HERAUSFORDERUNG
`aaaaaaaaa`	`Google SecOps`	`google.com`	BLOCKIEREN

Problemumgehung

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

Die folgenden Aggregationen sind von dem oben beschriebenen Entschachtelungsverhalten nicht 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. Beispiel: Die folgende Beispielregel wird auf die aufgeführten Ereignisse angewendet:

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 bei der Berechnung des Ergebniswerts verwenden. Bei der Berechnung werden die folgenden Elemente 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 ergibt eine potenzielle maximale Summe von 6, obwohl $e2 nur drei verschiedenen Ereignissen entsprechen kann.

Das wirkt sich auf die Funktionen „Summe“, „Anzahl“ und „Array“ aus. Bei „Anzahl“ und „Array“ kann das Problem durch die Verwendung von count_distinct oder array_distinct behoben werden. Für „Summe“ gibt es jedoch keine Problemumgehung.

Klammern am Anfang eines Ausdrucks

Wenn Sie Klammern am Anfang eines Ausdrucks verwenden, wird der folgende Fehler ausgegeben:

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

Im folgenden Beispiel würde dieser Fehler ausgegeben:

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

Indexarray im Ergebnis erfordert Aggregation für einzelne Werte im wiederholten Feld

Für die Array-Indexierung im Bereich „Ergebnis“ ist weiterhin eine Aggregation erforderlich. Folgendes funktioniert beispielsweise nicht:

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

Sie können die Ausgabe des Arrayindexes jedoch in einer Platzhaltervariablen speichern und diese Variable im Ergebnisbereich verwenden, wie hier gezeigt:

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

outcome:
  $principal_user_department = $principal_user_dept

ODER-Bedingung mit Nichtvorhandensein

Wenn zwischen zwei separaten Ereignisvariablen eine OR-Bedingung angewendet wird und die Regel mit dem Nichtvorhandensein übereinstimmt, wird sie erfolgreich kompiliert, kann aber zu falsch positiven Erkennungen führen. Mit der folgenden Regelsyntax können beispielsweise Ereignisse 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

Eine Lösung besteht darin, die Bedingungen in zwei Blöcke zu unterteilen, in denen der Filter jeweils 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 einem arithmetischen Vorgang mit einem UDM-Feld zu verwenden, dessen Typ eine Ganzzahl ohne Vorzeichen ist, wird ein Fehler ausgegeben. 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 Ganzzahlen ohne Vorzeichen funktionieren.

Als Problemumgehung können Sie die Ganzzahlkonstante zu einer Gleitkommazahl erzwingen, 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 Anreicherungsphasen (Streaming und latenzempfindlich) priorisiert das System die Geschwindigkeit vor der sofortigen Genauigkeit. Dies kann zu fehlenden Daten und potenziellen Falschmeldungen führen. Das System reichert die Daten weiterhin im Hintergrund an, sie sind aber möglicherweise nicht verfügbar, wenn die Regel ausgeführt wird. Dies ist Teil des normalen Prozesses der Eventual Consistency. Um diese Art von Falschmeldungen zu vermeiden, sollten Sie nicht darauf vertrauen, dass in Ereignissen angereicherte Felder 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, die beide angereicherte Felder sind. Wenn die Datenaufbereitung nicht rechtzeitig abgeschlossen ist, führt die Regel zu einem False Positive.

Um dies zu vermeiden, wäre eine bessere Prüfung für diese Regel:

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

Durch diese Regel wird verhindert, dass das Ereignis von IP-Adressen mit der ASN 16509 ausgelöst wird, die sich jedoch außerhalb des Vereinigten Königreichs befinden. Dadurch wird die Gesamtgenauigkeit der Regel verbessert.