Bekannte Probleme mit YARA-L 2.0

Unterstützt in:

Dieses Dokument richtet sich an Detection Engineers, die die Regellogik debuggen und die YARA-L 2.0-Ausführung optimieren möchten. Es wird erläutert, wie Sie mit nicht standardmäßigen Engine-Verhaltensweisen umgehen, z. B. mit dem Entschachteln 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 fehlenden Erkennungen führen.

YARA-L 2.0 verwendet ein Ausführungsmodell, das wiederkehrende Felder während der Auswertung in einzelne Ereigniszeilen erweitert. Da diese Transformation auf Engine-Ebene erfolgt, sind für das Verweisen auf mehrere wiederkehrende Felder oder das Ausführen von Berechnungen mit vorzeichenlosen UDM-Typen (Unified Data Model) Syntax-Workarounds erforderlich, um Compilerfehler, Laufzeitfehler oder falsche Ergebnismengen zu vermeiden. In diesem Dokument werden diese technischen Einschränkungen und die Logikmuster beschrieben, mit denen sie behoben werden können.

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 Aufrufen 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): Das normalisierte Schema, das verwendet wird, um alle aufgenommenen Sicherheitstelemetriedaten auf der Plattform zu strukturieren.
  • Entschachtelung: Die Erweiterung eines einzelnen UDM-Ereignisses mit einem wiederkehrenden 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 Zeilenmultiplikation führen kann.
  • T₀ (Erstausführung): Die erste Ausführung einer Regel für eingehende Telemetriedaten. Dies geschieht während der „Streaming“-Phase, oft bevor Hintergrundprozesse zur Anreicherung (wie GeoIP- oder ASN-True-ups) abgeschlossen sind.

Ergebnisaggregationen mit Entschachtelung wiederkehrender Felder

Wenn eine Regel auf ein wiederkehrendes Feld in einer Ereignisvariable 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, 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 Aufheben der Verschachtelung

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

Vor dem Unnesting

In der folgenden Tabelle sehen Sie 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 Unnesting

In der folgenden Tabelle sehen Sie 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 Feld verschachtelt ist, z. B. security_results.action, wird die Verschachtelung auf beiden Ebenen (übergeordnet und untergeordnet) gleichzeitig aufgehoben. Dies führt zu einem 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 entpackt.

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 der verschachtelten Entschachtelung

Im ursprünglichen Datensatz werden die Aktionen in einer verschachtelten Array-Struktur gespeichert.

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

Ereignisdatensätze nach verschachtelter Unnesting-Operation

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

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 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 Unnesting-Verhalten entstehen, 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, jeweils mit einem doppelten principal.hostname-Wert. Dieses Ergebnis liefert vier Hostnamen (anstatt einem), da die wiederholten Werte für security_results.actions entpackt 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 Unnesting mit nicht zusammenhängenden Feldern

Der Hostname ist ein einzelner Wert, der neben den wiederholten Sicherheitsergebnissen steht.

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 zusammenhängenden Feldern

Der Hostname ist jetzt in vier Zeilen dupliziert, sodass er von der Funktion array() viermal erfasst wird.

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 Unnesting-Verhalten

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

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

Ergebnisaggregationen mit mehreren Ereignisvariablen

Wenn eine Regel mehrere Ereignisvariablen enthält, gibt es in der Zusammenfassung für jede Kombination von Ereignissen, die in der Erkennung enthalten sind, einen separaten Eintrag. Wenn 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 des Ergebniswerts verwenden können. Die folgenden Elemente werden für die 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

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

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

Klammern am Anfang eines Ausdrucks

Der Beginn eines Ausdrucks mit Klammern wird nicht unterstützt und löst im Regeleditor einen Parsing-Fehler aus.

Ungültige Syntax

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

Im folgenden Beispiel wird diese Art von Fehler generiert:

($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 Abschnitt outcome für wiederkehrende Felder ist nicht zulässig. Dafür 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 übereinstimmt, wird die Regel erfolgreich kompiliert, kann aber zu falsch positiven Erkennungen führen.

Die folgende Regelsyntax kann beispielsweise Ereignisse mit $event_a.field = "something" abgleichen, 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 Prüfungen auf Nichtvorhandensein in einzelne Blöcke für jede Variable, um die logische Integrität zu wahren.

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

condition:
  $event_a and #event_b >= 0

Arithmetische Operationen mit vorzeichenlosen Ereignisfeldern

Wenn Sie ein Ganzzahlliteral in einer arithmetischen (+, -, *) oder Modulo-Operation (%) mit einem vorzeichenlosen Ganzzahl-UDM-Feld verwenden, erhalten Sie einen Fehler. Standardmäßige Ganzzahlliterale sind standardmäßig vorzeichenbehaftete 64-Bit-Ganzzahlen (INT64), die nicht mit UDM-Feldern kompatibel sind, die als vorzeichenlose 64-Bit-Ganzzahlen (UINT64) definiert sind, z. B. network.received_bytes, network.sent_bytes und principal.file.size.

Diese strenge Typisierungseinschränkung gilt sowohl für die Abschnitte events als auch outcome, einschließlich innerhalb von sum()- oder max()-Aggregationen und Divisorausdrücken. Die YARA-L-Syntaxprüfung behandelt sowohl vorzeichenbehaftete als auch vorzeichenlose Ganzzahlen als generischen int-Typ. Daher kann eine Regel, die UINT64-UDM-Felder und INT64-Ganzzahlliterale kombiniert, die Syntaxprüfung beim Speichern bestehen, aber bei der Regelausführung oder beim Klicken auf Test ausführen fehlschlagen. Wenn die Regel fehlschlägt, wird ein allgemeiner „Regelfehler“ (cannot complete [arithmetic/mod] operation between unsigned and signed integer) generiert.

Der folgende events-Vergleich besteht beispielsweise die Syntaxprüfung beim Speichern, schlägt aber bei der Ausführung fehl, weil $e.network.received_bytes (UINT64) mit dem signierten Ganzzahlliteral 2 (INT64) multipliziert wird:

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

Problemumgehungen

Sie können diesen Typkonflikt mit einer der folgenden Methoden beheben:

  • Explizite Ganzzahlumwandlung (cast.as_int() oder cast.as_uint()): Konvertieren Sie das vorzeichenlose UDM-Feld mit cast.as_int() in eine vorzeichenbehaftete Ganzzahl oder konvertieren Sie das Ganzzahlliteral mit cast.as_uint() in eine vorzeichenlose Ganzzahl. Verwenden Sie diese Methode, wenn Sie ein ganzzahliges Ergebnis benötigen oder wenn Sie den Modulo-Operator (%) verwenden, der nur ganzzahlige Operanden akzeptiert.
  • Gleitkomma-Umwandlung: Erzwingen Sie, dass sich die Ganzzahlkonstante wie ein float verhält, indem Sie ein Gleitkommaliteral wie 2.0 oder 100.0 verwenden. In einfachen Ausdrücken ohne andere Divisionsoperatoren in derselben Zeile können Sie auch eine Division verwenden, z. B. (2/1). Verwenden Sie in Ausdrücken, die bereits Divisionsoperatoren (/) enthalten, Gleitkommaliterale oder cast.as_int() anstelle der impliziten Umwandlung von (N/1)-Divisionen. Mehrere /-Zeichen in derselben Zeile können als regulärer Ausdruck interpretiert werden, was zu einem Parsing-Fehler während der Kompilierung führt oder die Syntaxhervorhebung im Regeleditor beeinträchtigt.

Problemumgehung im Abschnitt events

Verwenden Sie cast.as_int(), ein Gleitkommaliteral oder eine implizite Umwandlung der Division, um den Fehler im Abschnitt events zu beheben:

  • Verwenden Sie cast.as_int():

    events:
  $total_bytes = $e.network.total_bytes
  $total_bytes = cast.as_int($e.network.received_bytes) * 2

  • Verwenden Sie ein Gleitkommaliteral:

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

  • Verwenden Sie die implizite Umwandlung für die Division:

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

Problemumgehung im Abschnitt outcome

Der folgende outcome-Ausdruck wird ohne Syntaxfehler gespeichert, schlägt aber zur Laufzeit fehl, da sum($e.network.sent_bytes) und sum($e.network.received_bytes) UINT64-Werte zurückgeben, die mit den signierten INT64-Literalen 100 und 1 kombiniert werden:

outcome:
  // Saves, but fails at runtime:
  $upload_ratio_pct = sum($e.network.sent_bytes) * 100 / (sum($e.network.received_bytes) + 1)

Schreiben Sie den Ausdruck mit Gleitkommaliteralen oder cast.as_int() um, damit er ohne Fehler gespeichert und ausgeführt wird:

  • Verwenden Sie Gleitkommaliterale:

    outcome:
  $upload_ratio_pct = sum($e.network.sent_bytes) * 100.0 / (sum($e.network.received_bytes) + 1.0)

  • Verwenden Sie cast.as_int():

    outcome:
  $upload_ratio_pct = sum(cast.as_int($e.network.sent_bytes)) * 100 / (sum(cast.as_int($e.network.received_bytes)) + 1)

GeoIP-Anreicherung und Eventual Consistency

In den ersten Anreicherungsphasen (Streaming und latenzempfindlich) priorisiert das System Geschwindigkeit gegenüber sofortiger Genauigkeit. Das kann zu fehlenden Daten und potenziellen falsch positiven Ergebnissen 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. Dies ist Teil des normalen Prozesses der Eventual Consistency.

Um falsch positive Ergebnisse aufgrund von Verzögerungen bei der Anreicherung zu vermeiden, sollten Sie explizit prüfen, ob das Feld 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" enthalten muss. Beides sind angereicherte Felder. Wenn die Anreicherung nicht rechtzeitig abgeschlossen wird, erzeugt die Regel einen Fehlalarm.

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 außerhalb des Vereinigten Königreichs befinden. Dadurch wird die Gesamtgenauigkeit der Regel verbessert.

Informationen zur Fehlerbehebung bei der Anreicherungsverzögerung

Fehlerbehebung

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

Zukünftige Ereignisse

Regeln für mehrere Ereignisse sind so konzipiert, dass Ereignisse in chronologischer Reihenfolge relativ zur 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.

Anreicherungsverzögerung

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

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): 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, wird die Regel beim ersten Durchlauf nicht ausgelöst.

  • Falsch positiv (Ausschlussfehler): 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 bewertet. Dadurch werden die Erkennungsstatus wie folgt „abgeglichen“:

  • Späte Erkennungen: Ereignisse, die zum Zeitpunkt T₀ „falsch negativ“ waren, werden jetzt erkannt, nachdem die Anreicherung abgeschlossen ist.

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

Testdiskrepanz ausführen

Das Tool Test ausführen verwendet Verlaufsdaten, die bereits abgeglichen wurden. Da die Daten zum Zeitpunkt der manuellen Tests bereits vollständig angereichert sind, sehen Sie die „True-up“-Ergebnisse sofort. Das bedeutet, dass Sie die falsch negativen Ergebnisse von T₀ oder die ausschlussbasierten falsch positiven Ergebnisse, die während des ersten Live-Durchlaufs aufgetreten sind, nicht sehen.

Fehlerbehebung

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

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

$e.principal.ip_geo_artifact.network.asn != ""
Live- im Vergleich zu Testübereinstimmung Live-Regeln lösen Benachrichtigungen aus, aber „Test ausführen“ für dieselben Daten zeigt "No Results an. Fügen Sie $e.field != "" hinzu, um alle angereicherten Felder (GeoIP, ASN, File Path) zu prüfen und das Live- und Verlaufsverhalten zu synchronisieren.
Fehlende Metadaten Erkennungen werden im Dashboard mit leeren GeoIP- oder File Path-Feldern angezeigt. Dies ist für T0-Ausführungen zu erwarten. Fügen Sie zur Behebung des Problems eine field != ""-Prüfung hinzu oder konfigurieren Sie eine Abrechnungsverzögerung in Ihrem Regelzeitplan, um mehr Zeit für die Aufnahme zu ermöglichen.

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 Sie für ein falsch positives Ergebnis halten. Suchen Sie in der Spalte Erkennungstyp nach dem Symbol <span class="material-icons">lightbulb</span>. Benachrichtigungen ohne dieses Symbol stammen aus der primären Ausführung, bei der die Anreicherungsverzögerung am häufigsten auftritt.

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

  3. Testen und prüfen:

    • Mit der Funktion Test ausführen können Sie prüfen, ob Ihre Logik noch mit den gewünschten Verlaufsdaten übereinstimmt.
    • Prüfen Sie, ob die Regel jetzt nur während der True-up-Ausführungen ausgelöst wird (oder korrekt ausgeschlossen wird), sobald die Anreicherungsfelder ausgefüllt sind.

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

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