Bekannte Probleme und Einschränkungen bei YARA-L 2.0

Dieses Dokument richtet sich an Detection Engineers, die die Regellogik debuggen und die Ausführung von YARA-L 2.0 optimieren möchten. Darin wird beschrieben, 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 anwenden, 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 wiederholte Felder während der Auswertung in einzelne Ereigniszeilen erweitert werden. Da diese Transformation auf Engine-Ebene erfolgt, sind für den Verweis auf mehrere wiederholte Felder oder für arithmetische Operationen mit UDM-Typen ohne Vorzeichen bestimmte Syntax-Workarounds erforderlich, um Compilerfehler oder falsche Ergebnismengen zu vermeiden. In diesem Dokument werden diese technischen Einschränkungen und die erforderlichen Logikmuster zur Behebung 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 Viewer): 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: Damit Sie die Ausgabe von nicht verschachtelten Ereignissen im Dashboard für die Erkennung prüfen können.

Schlüsselterminologie

  • Einheitliches Datenmodell (Unified Data Model, UDM): Das normalisierte Schema, das zum Strukturieren aller erfassten Sicherheitstelemetriedaten auf der Plattform verwendet wird.
  • Entschachtelung:Die Erweiterung eines einzelnen UDM-Ereignisses mit einem wiederholten Feld (Array) in mehrere Zeilen auf Engine-Ebene. Jede Zeile steht für ein eindeutiges Element aus dem Array, was bei der Regelauswertung zu einer Vervielfachung der Zeilen führen kann.
  • T₀ (Erstdurchlauf): Die erste Ausführung einer Regel für eingehende Telemetriedaten. Dies geschieht während der Streamingphase, oft bevor Hintergrundanreicherungsprozesse wie GeoIP- oder ASN-Abstimmungen abgeschlossen sind.

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
}

Ereignisdatensätze: vor und nach dem Entschachteln

In den Tabellen in diesem Abschnitt wird veranschaulicht, wie ein einzelnes Ereignis mit einem Array von IP-Adressen in zwei separate Datensätze umgewandelt wird.

Vor dem Entnesten

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]

Nach dem Entnesten

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

Verschachtelte wiederkehrende Felder (kartesisches Produkt)

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 gleichzeitig auf beiden Ebenen (übergeordnet und untergeordnet) aufgehoben. Daraus ergibt sich ein kartesisches Produkt aller Elemente.

Im folgenden Beispiel wird ein 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 verschachtelten Unnesting

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

Nach der Erweiterung wird jede einzelne Aktion in einer eigenen Zeile dargestellt. Das kann zu unerwarteten Mengen bei nicht eindeutigen Aggregationen führen.

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

Auswirkungen auf nicht verwandte Felder

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 entstehen, nicht berücksichtigt werden.

Im folgenden Beispiel 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 mit nicht zugehörigen Feldern

Der Hostname ist ein einzelner Wert, wird aber neben den wiederholten Sicherheitsergebnissen angezeigt.

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

Ereignisdatensatz nach dem Entschachteln mit nicht zugehörigen Feldern

Der Hostname wird jetzt in vier Zeilen dupliziert, sodass die array()-Funktion 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 CHALLENGE
aaaaaaaaa Google SecOps google.com BLOCKIEREN

Problemumgehung für das Verhalten beim Entschachteln

Damit Ihre Ergebniswerte bei der Entschachtelung korrekt sind, verwenden Sie die eindeutige Version der ausgewählten Aggregation. Bei den folgenden Funktionen werden die durch das Entschachteln erstellten doppelten Zeilen ignoriert:

  • 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 ein Ausdruck mit Klammern beginnt, wird dies nicht unterstützt und löst einen Parsing-Fehler im Regeleditor 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

Index-Array im Ergebnis erfordert Aggregation

Das direkte Indexieren eines Arrays im outcome-Abschnitt für wiederholte 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 Array-Index 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 Nichtvorhandensein

Wenn Sie eine OR-Bedingung zwischen zwei separaten Ereignisvariablen anwenden und die Regel auf Nichtvorhandensein abgestimmt ist, wird die Regel zwar erfolgreich kompiliert, kann aber Falschmeldungen erzeugen.

Die folgende Regelsyntax kann beispielsweise auch Ereignisse mit $event_a.field = "something" abgleichen, 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

Problemumgehung

Trennen Sie die Prüfungen auf Nichtvorhandensein in einzelne Blöcke für jede Variable, um die Logik zu wahren.

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

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

Problemumgehung

Sie können diesen Fehler umgehen, indem Sie die Ganzzahlkonstante durch eine Divisionsoperation als Gleitkommazahl erzwingen.

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

GeoIP-Anreicherung und Eventual Consistency

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

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

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 IPs mit der ASN 16509 ausgelöst wird, die sich 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 der Live-Erkennung von den Testergebnissen unterscheidet.

Zukünftige Termine

Regeln mit mehreren Ereignissen sind so konzipiert, dass Ereignisse in chronologischer Reihenfolge in Bezug auf die Aufnahme verarbeitet werden. 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

Bei Google SecOps wird die Erfassungsgeschwindigkeit priorisiert, um erste Benachrichtigungen so schnell wie möglich zu erhalten. Hintergrundprozesse zur Anreicherung, z. B. zum 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 (Erkennungsverzögerung): Das 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, wird die Regel beim ersten Ausführen nicht abgeglichen.

  • Falsch positive Ergebnisse (Ausschluss nicht berücksichtigt): Wenn in Ihrer Regel angereicherte Felder verwendet werden, um bekannte gute Aktivitäten herauszufiltern (z. B. NOT target.ip_geo_country == "US"), kann es zu einem falsch positiven Ergebnis kommen, da die Ausschlussdaten noch nicht angewendet wurden.

Abstimmungsläufe

Bei diesen Hintergrundläufen werden die Daten nach einer Verzögerung (z. B. 45 Minuten oder 30 Stunden) neu ausgewertet. Dadurch werden die Erkennungsstatus so angepasst:

  • Späte Erkennungen: Ereignisse, die bei T₀ „falsch negativ“ waren, führen nach Abschluss der Anreicherung zu einer Erkennung.

  • Korrektur: Alle T₀-Falschmeldungen verbleiben im System, die vollständig angereicherten Daten sind jedoch in der UDM-Anzeige für die manuelle Priorisierung sichtbar.

Testabweichung ausführen

Das Tool Test ausführen basiert auf Verlaufsdaten, die bereits abgeglichen wurden. Da die Daten vollständig angereichert sind, wenn Sie einen manuellen Test ausführen, können Sie die Ergebnisse sofort sehen. Das bedeutet, dass die falsch negativen Ergebnisse bei T₀ oder die auf Ausschlüssen basierenden falsch positiven Ergebnisse, die während des ersten Live-Laufs aufgetreten sind, nicht angezeigt werden.

Fehlerbehebung

In der folgenden Tabelle finden Sie Informationen dazu, wie Sie Abweichungen zwischen Live-Benachrichtigungen und Testergebnissen beheben können.

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

$e.principal.ip_geo_artifact.network.asn != ""
Live-Übereinstimmung im Vergleich zur Testübereinstimmung Live-Regeln lösen Benachrichtigungen aus, aber bei „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 so das Live- und das bisherige Verhalten zu synchronisieren.
Fehlende Metadaten Erkennungen werden im Dashboard mit leeren Feldern GeoIP oder File Path angezeigt. Das ist bei T0-Läufen normal. Um das Problem zu beheben, fügen Sie eine field != ""-Prüfung ein oder erhöhen Sie den Offset für den ersten Lauf in Ihrem Laufplan, damit mehr Zeit für die Aufnahme zur Verfügung steht.

Validierung und Tests

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

  1. Verzögerung identifizieren:Suchen Sie nach einer Erkennung, die Ihrer Meinung nach ein falsch positives Ergebnis ist. Suchen Sie in der Spalte Erkennungstyp nach dem Symbol <span class="material-icons">lightbulb</span>. Benachrichtigungen ohne dieses Symbol stammen aus dem ersten Lauf, bei dem es am häufigsten zu Verzögerungen bei der Anreicherung kommt.

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

  3. Testen und überprüfen:

    • Mit der Funktion Test ausführen können Sie prüfen, ob Ihre Logik weiterhin den beabsichtigten Verlaufsdaten entspricht.
    • Prüfen Sie, ob die Regel nach dem Auffüllen der Anreicherungsfelder nur bei den True-up-Läufen ausgelöst wird (oder korrekt ausgeschlossen wird).

Weitere Informationen finden Sie unter Zeitplan für die Ausführung von Regeln verwalten und Benutzerdefinierte Zeitpläne für Regeln konfigurieren.

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