Bekannte Probleme 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.

In YARA-L 2.0 wird ein bestimmtes Ausführungsmodell verwendet, 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 aufgenommenen 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 Entschachteln

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 Unnesting

Nach der Erweiterung wird jede eindeutige Aktion in einer eigenen Zeile dargestellt. Das kann zu unerwarteten Anzahlen 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 keine doppelten Werte für andere Felder im selben Ereignis berücksichtigt werden, die durch das Unnesting-Verhalten entstehen.

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 ergibt eine potenzielle maximale 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 ein Parsing-Fehler im Regeleditor ausgelöst.

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

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 fälschlicherweise positive Ergebnisse liefern.

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 vorzeichenbehaftete Ganzzahlen, die mit UDM-Feldern, die als vorzeichenlose 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 behandeln.

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 latenzsensitiv) die Geschwindigkeit gegenüber der sofortigen Genauigkeit. Dies kann zu fehlenden Daten und potenziellen Falschmeldungen führen. Das System reichert die Daten weiterhin im Hintergrund 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.

Termine in der Zukunft

Regeln für mehrere Ereignisse 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.

Korrekturausführungen

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₀-Falsch-Positiv-Ergebnisse verbleiben im System, die vollständig angereicherten Daten sind jedoch in der UDM-Ansicht für die manuelle Priorisierung sichtbar.

Testabweichung ausführen

Das Tool Test ausführen verwendet historische Daten, 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 ausgelöst, obwohl ein Ausschluss (z. B. != "ASN_123") vorhanden ist, 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. Beispiel:

$e.principal.ip_geo_artifact.network.asn != ""
Live- und Testspiel Live-Regeln lösen Benachrichtigungen aus, aber beim Ausführen des Tests 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. Fügen Sie zur Behebung des Problems eine field != ""-Prüfung ein oder erhöhen Sie den Offset für den ersten Lauf in Ihrem Laufplan, um mehr Zeit für die Aufnahme zu haben.

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 Testlauf 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 Abgleichslä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