Bekannte Probleme mit YARA-L 2.0

Dieses Dokument richtet sich an Erkennungstechniker, die die Regellogik debuggen und die Ausführung von YARA-L 2.0 optimieren möchten. Es wird erläutert, wie Sie mit nicht standardmäßigen Engine-Verhaltensweisen umgehen, z. B. mit dem Aufheben der Verschachtelung von Feldern, der Erweiterung des kartesisches Produkt in Aggregationen und der Eventual Consistency bei der Anreicherung. Wenn Sie diese Methoden befolgen, können Sie Logikfehler vermeiden, die zu überhöhten Ergebniswerten oder verpassten Erkennungen führen.

YARA-L 2.0 verwendet ein bestimmtes Ausführungsmodell, bei dem wiederkehrende Felder während der Auswertung in einzelne Ereigniszeilen erweitert werden. Da diese Transformation auf Engine-Ebene erfolgt, erfordert das Verweisen auf mehrere wiederkehrende Felder oder das Ausführen arithmetischer Operationen für nicht signierte UDM-Typen bestimmte Syntax-Workarounds, um Compilerfehler oder falsche Ergebnissätze zu vermeiden. In diesem Dokument werden diese technischen Einschränkungen und die erforderlichen Logikmuster zur Behebung dieser Einschränkungen beschrieben.

Hinweis

Prüfen Sie, ob Ihr Konto die folgenden technischen Berechtigungen hat, bevor Sie YARA-L 2.0-Regeln testen oder ändern:

Erforderliche IAM-Rollen

  • roles/chronicle.viewer (Security Operations-Betrachter): Zum Ansehen vorhandener Regeln und Erkennungsmetadaten.
  • roles/chronicle.editor (Security Operations-Editor): Zum Ändern der Regellogik und Speichern von Änderungen.

Erforderliche Berechtigungen

  • chronicle.rules.runTest: Erforderlich, um die Funktion Test ausführen für Verlaufsdaten auszuführen.

  • chronicle.detections.get: Zum Prüfen der Ausgabe von nicht verschachtelten Ereignissen im Erkennungs-Dashboard.

Schlüsselterminologie

  • UDM (Unified Data Model, einheitliches Datenmodell) : Das normalisierte Schema, das zum Strukturieren aller aufgenommenen Sicherheitsdaten auf der Plattform verwendet wird.
  • Aufheben der Verschachtelung:Die Erweiterung eines einzelnen UDM-Ereignisses, das ein wiederkehrendes Feld (Array) enthält, auf Engine-Ebene in mehrere Zeilen. Jede Zeile stellt ein eindeutiges Element aus dem Array dar, was bei der Regelauswertung zu einer Zeilenvervielfachung führen kann.
  • T₀ (erste Ausführung) : Die erste Ausführung einer Regel für eingehende Telemetriedaten. Dies geschieht während der Streaming-Phase, oft bevor Hintergrundprozesse zur Anreicherung (z. B. GeoIP- oder ASN-Korrekturen) abgeschlossen sind.

Ergebnisaggregationen mit Aufhebung der Verschachtelung von wiederkehrenden Feldern

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

Beispielsweise werden die beiden IP-Adressen im wiederkehrenden Feld target.ip für das Ereignis $e in zwei Instanzen von $e aufgeteilt, wobei jede einen anderen target.ip-Wert hat.

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
}

Ereignisdatensätze: Vor und nach dem Aufheben der Verschachtelung

Die Tabellen in diesem Abschnitt zeigen, wie ein einzelnes Ereignis, das ein Array von IP-Adressen enthält, in zwei separate Datensätze umgewandelt wird.

Vor dem Aufheben der Verschachtelung

Die folgende Tabelle zeigt den Ereignisdatensatz vor dem Aufheben der Verschachtelung des wiederkehrenden Felds:

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

Nach dem Aufheben der Verschachtelung

Die folgende Tabelle zeigt den Ereignisdatensatz nach dem Aufheben der Verschachtelung des wiederkehrenden Felds:

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

Verschachtelte wiederkehrende Felder (kartesisches Produkt)

Wenn eine Regel auf ein wiederkehrendes Feld verweist, das in einem anderen verschachtelt ist, z. B. security_results.action, erfolgt das Aufheben der Verschachtelung gleichzeitig auf beiden Ebenen (übergeordnet und untergeordnet). Das Ergebnis ist ein kartesisches Produkt aller Elemente.

Im folgenden Beispiel wird ein Ereignis $e mit zwei wiederkehrenden Werten für security_results und zwei wiederkehrende Werte für security_results.actions in vier Instanzen aufgehoben.

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 verschachtelten Verschachtelung

Im ursprünglichen Datensatz werden die Aktionen in einer verschachtelten Arraystruktur gespeichert.

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

Ereignisdatensätze nach dem Aufheben der verschachtelten Verschachtelung

Nach der Erweiterung wird jede eindeutige Aktion zu einer eigenen Zeile, was zu unerwarteten Zählungen bei nicht eindeutigen Aggregationen führen kann.

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

Auswirkungen auf nicht verwandte Felder

Dieses Verhalten beim Aufheben der Verschachtelung bei der Regelauswertung kann zu unerwarteten Ergebnisaggregationen führen, wenn die Regel auf ein oder mehrere wiederkehrende Felder mit einem übergeordneten Feld verweist, das ebenfalls ein wiederkehrendes Feld ist. Nicht eindeutige Aggregationen wie sum(), array() und count() können doppelte Werte in anderen Feldern desselben Ereignisses, die durch das Verhalten beim Aufheben der Verschachtelung erzeugt werden, nicht berücksichtigen.

Im folgenden Beispiel hat das Ereignis $e einen einzelnen Hostnamen (google.com), aber das Ergebnis (hostnames) wird über vier nicht verschachtelte Instanzen desselben Ereignisses $e aggregiert, die jeweils einen doppelten principal.hostname-Wert haben. Dieses Ergebnis liefert aufgrund des Aufhebens der Verschachtelung von wiederkehrenden Werten für security_results.actions vier Hostnamen (statt einem).

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 mit nicht verwandten Feldern

Der Hostname ist ein einzelner Wert, befindet sich aber neben den wiederkehrenden Sicherheitsergebnissen.

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 mit nicht verwandten Feldern

Der Hostname wird jetzt in vier Zeilen dupliziert, sodass die Funktion array() ihn viermal erfasst.

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 HERAUSFORDERUNG
aaaaaaaaa Google SecOps google.com BLOCKIEREN

Problemumgehung für das Verhalten beim Aufheben der Verschachtelung

Damit Ihre Ergebniswerte beim Aufheben der Verschachtelung korrekt sind, verwenden Sie die eindeutige Version der ausgewählten Aggregation. Die folgenden Funktionen ignorieren die doppelten Zeilen, die durch das Aufheben der Verschachtelung erstellt wurden:

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

Ergebnisaggregationen mit mehreren Ereignisvariablen

Wenn eine Regel mehrere Ereignisvariablen enthält, gibt es in der Aggregation ein separates Element für jede Kombination von Ereignissen, die in der Erkennung enthalten ist. Wenn beispielsweise die folgende Beispielregel 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, sodass Sie beide Ereignisvariablen in den Berechnungen der Ergebniswerte verwenden können. Die folgenden Elemente werden in 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 Ergebnis ist eine potenzielle maximale Summe von 6, obwohl $e2 nur 3 verschiedenen Ereignissen entsprechen kann.

Dies wirkt sich auf Summe, Anzahl und Array aus. Bei Anzahl und Array kann das Problem mit count_distinct oder array_distinct behoben werden, aber es gibt keine Problemumgehung für die Summe.

Klammern am Anfang eines Ausdrucks

Das Beginnen eines Ausdrucks mit Klammern wird nicht unterstützt und löst einen Parsingfehler im Regel-Editor aus.

Ungültige Syntax

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

Das folgende Beispiel erzeugt diesen Fehlertyp:

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

Gültige Syntaxvarianten

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 das Index-Array im Ergebnis ist eine Aggregation erforderlich

Das direkte Indexieren eines Arrays im Abschnitt outcome für wiederkehrende Felder ist nicht zulässig. Dazu ist eine temporäre Platzhaltervariable erforderlich.

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

Problemumgehung

Erfassen Sie den spezifischen Arrayindex in einer Platzhaltervariablen im Abschnitt events und verweisen Sie dann in Ihrem Ergebnis auf diesen Platzhalter.

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

outcome:
  $principal_user_department = $principal_user_dept

OR-Bedingung mit Nichtexistenz

Wenn Sie eine OR-Bedingung zwischen zwei separaten Ereignisvariablen anwenden und die Regel mit Nichtexistenz übereinstimmt, wird die Regel erfolgreich kompiliert, kann aber falsch positive Erkennungen erzeugen.

Beispielsweise kann die folgende Regelsyntax mit Ereignissen übereinstimmen, bei denen $event_a.field = "something" ist, obwohl dies nicht der Fall sein sollte:

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

Problemumgehung

Trennen Sie die Nichtexistenzprüfungen in separate Blöcke für jede Variable auf, um die Logikintegrität zu wahren.

events:
  not ($event_a.field = "something")
  not ($event_b.field = "something")

condition:
  $event_a and #event_b >= 0

Arithmetische Operationen mit nicht signierten Ereignisfeldern

Wenn Sie versuchen, eine ganzzahlige Konstante in einer arithmetischen Operation mit einem UDM-Feld zu verwenden, dessen Typ eine nicht signierte Ganzzahl ist, erhalten Sie einen Fehler. Beispiel:

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

Standardmäßige ganzzahlige Konstanten sind standardmäßig signierte Ganzzahlen, die mit UDM-Feldern, die als nicht signierte Ganzzahlen definiert sind, wie z. B. network.received_bytes, nicht kompatibel sind.

Problemumgehung

Sie können diesen Fehler umgehen, indem Sie die ganzzahlige Konstante durch eine Divisionsoperation als Gleitkommazahl behandeln.

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

GeoIP-Anreicherung und Eventual Consistency

Das System priorisiert in den ersten Anreicherungsphasen (Streaming und latenzempfindlich) die Geschwindigkeit gegenüber der sofortigen Genauigkeit, was zu fehlenden Daten und potenziellen falsch positiven Ergebnissen führen kann. Das System reichert die Daten im Hintergrund weiter an, aber die Daten sind möglicherweise nicht verfügbar, wenn die Regel ausgeführt wird. Dies ist Teil des normalen Prozesses der Eventual Consistency.

Um falsch positive Ergebnisse aufgrund von Verzögerungen bei der Anreicherung zu vermeiden, prüfen Sie explizit, ob das Feld nicht leer ist, bevor Sie seinen Wert auswerten.

Betrachten Sie beispielsweise dieses Regelereignis:

$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" haben muss. Beide sind angereicherte Felder. Wenn die Anreicherung nicht rechtzeitig abgeschlossen ist, erzeugt die Regel ein falsch positives Ergebnis.

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"

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

Informationen zur Fehlerbehebung bei Verzögerungen bei der Anreicherung

Fehlerbehebung

In diesem Abschnitt werden die Leistungserwartungen beschrieben und Self-Service-Lösungen für häufige Probleme bereitgestellt, bei denen sich das Verhalten bei der Live-Erkennung von den Testergebnissen unterscheidet.

Ereignisse mit zukünftigem Datum

Regeln für mehrere Ereignisse sind so konzipiert, dass sie Ereignisse in chronologischer Reihenfolge in Bezug auf die Aufnahme verarbeiten. Wenn Sie eine Regel für mehrere Ereignisse angeben und aktivieren, werden keine Erkennungen für Ereignisse mit zukünftigen Zeitstempeln erstellt, z. B. wenn für event.timestamp ein Datum und eine Uhrzeit nach ingest.timestamp festgelegt sind.

Verzögerung bei der Anreicherung

Google SecOps priorisiert die Aufnahmegeschwindigkeit, um erste Benachrichtigungen so schnell wie möglich zu senden. Hintergrundprozesse zur Anreicherung, z. B. das Auflösen von GeoIP-, ASN- oder UDM-Metadaten, folgen jedoch einem Modell der Eventual Consistency.

Erste Ausführung (T₀)

Die Live-Engine kann eine Regel auswerten, bevor die Hintergrundanreicherung abgeschlossen ist. Je nachdem, ob Ihre Logik auf angereicherten Feldern für Erkennungen oder Ausschlüsse basiert, kann dies zu den folgenden vorübergehenden Abweichungen führen:

  • Falsch negative Ergebnisse (Verzögerung bei der Erkennung): Dies ist ein häufiges Ergebnis. Wenn eine Regel von einem angereicherten Feld abhängt, um ausgelöst zu werden (z. B. target.user.department == "Finance"), und dieses Feld null ist, stimmt die Regel bei der ersten Ausführung nicht überein.

  • Falsch positive Ergebnisse (Ausschluss nicht gefunden): Wenn Ihre Regel angereicherte Felder verwendet, um bekannte gute Aktivitäten herauszufiltern (z. B. NOT target.ip_geo_country == "US"), kann die Regel ein falsch positives Ergebnis auslösen, da die "Ausschlussdaten" noch nicht angewendet wurden.

Korrekturausführungen

Bei diesen Hintergrundausführungen werden die Daten nach einer Verzögerung (z. B. 4 Stunden oder 30 Stunden) neu ausgewertet. Dadurch werden die Erkennungsstatus wie folgt korrigiert:

  • Späte Erkennungen: Ereignisse, die bei T₀ falsch negativ waren, führen jetzt zu einer Erkennung, sobald die Anreicherung abgeschlossen ist.

  • Korrektur: Alle falsch positiven Ergebnisse von T₀ bleiben im System, aber die vollständig angereicherten Daten sind im UDM-Viewer für die manuelle Triage sichtbar.

Abweichung beim Testlauf

Das Tool Test ausführen wird für Verlaufsdaten verwendet, die bereits abgeglichen wurden. Da die Daten vollständig angereichert sind, wenn Sie einen manuellen Test ausführen, können Sie die Ergebnisse der Korrektur sofort sehen. Das bedeutet, dass die falsch negativen Ergebnisse von T₀ oder die auf Ausschlüssen basierenden falsch positiven Ergebnisse, die bei der ersten Live-Ausführung aufgetreten sind, nicht angezeigt werden.

Fehlerbehebung

Verwenden Sie die folgende Tabelle, um Abweichungen zwischen Live-Benachrichtigungen und Testergebnissen zu beheben.

Problem Beschreibung Umsetzbare Lösung
Fehler beim Ausschluss Eine Regel wird trotz eines Ausschlusses ausgelöst (z. B. != "ASN_123"), weil das Feld bei der ersten Ausführung null war. Fügen Sie dem Abschnitt „Ereignisse“ eine Prüfung auf „nicht null“ hinzu, um sicherzustellen, dass die Daten vor der Auswertung angereichert werden, z. B.:

$e.principal.ip_geo_artifact.network.asn != ""
Übereinstimmung zwischen Live- und Testdaten Live-Regeln lösen Benachrichtigungen aus, aber bei der Ausführung von „Test ausführen“ für dieselben Daten wird "No Results" angezeigt. Fügen Sie $e.field != "" hinzu, um alle angereicherten Felder (GeoIP, ASN, File Path) zu prüfen und das Live- und Verhaltensverlauf zu synchronisieren.
Fehlende Metadaten Im Dashboard werden Erkennungen mit leeren Feldern für GeoIP oder File Path angezeigt. Dies ist bei T₀-Ausführungen zu erwarten. Fügen Sie zur Behebung eine Prüfung auf field != "" hinzu oder konfigurieren Sie eine Verzögerung bei der Abrechnung in Ihrem Regelzeitplan, um mehr Zeit für die Aufnahme zu haben.

Überprüfung und Tests

So prüfen Sie, ob eine Regel verzögerte Anreicherungen korrekt verarbeitet:

  1. Verzögerung identifizieren:Suchen Sie eine Erkennung, die Ihrer Meinung nach ein falsch positives Ergebnis ist. Prüfen Sie in der Spalte Erkennungstyp, ob das Symbol <span class="material-icons">lightbulb</span> vorhanden ist. Benachrichtigungen ohne dieses Symbol stammen aus der ersten Ausführung, bei der Verzögerungen bei der Anreicherung am häufigsten auftreten.

  2. Regellogik aktualisieren:Fügen Sie für alle angereicherten Datenpunkte, die in Ihrer Logik verwendet werden, eine field != "" hinzu.
    Beispiel (Dateipfad):
    $e.target.process.parent_process.file.full_path != ""

  3. Testen und überprüfen :

    • Prüfen Sie mit der Funktion Test ausführen , ob Ihre Logik weiterhin mit den beabsichtigten Verlaufsdaten übereinstimmt.
    • Prüfen Sie, ob die Regel jetzt nur bei den Korrekturausführungen ausgelöst wird (oder korrekt ausgeschlossen wird), sobald die Anreicherungsfelder ausgefüllt sind.

Weitere Informationen finden Sie unter Zeitplanung für Regelausführungen und Benutzerdefinierte Zeitpläne für Regeln konfigurieren.

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