Syntax des Ergebnisabschnitts

Unterstützt in:

Im outcome-Abschnitt einer YARA-L-Abfrage werden Ergebnisvariablen definiert, die die Ausgabe für eine Such- und Dashboard-Abfrage sowie zusätzlichen Kontext und Informationen für eine Erkennung angeben, wenn eine Regel ausgelöst wird. Diese Variablen können für verschiedene Zwecke verwendet werden, z. B. zum Anzeigen relevanter Daten in Dashboards und zum Erstellen von Risikobewertungen.

Ergebnisabschnitt definieren

Verwenden Sie das Zeichen $, gefolgt von einem Variablennamen, um im Bereich outcome einer einzelnen Abfrage eine Ergebnisvariable zu definieren. Sie können bis zu 20 Ergebnisvariablen definieren. Die Variablennamen selbst sind beliebig. Bei Regeln werden Ergebniswerte basierend auf jeder Erkennung berechnet und aggregiert.

Jeder Ergebnisvariablen wird mit einem Ausdruck ein Wert zugewiesen.

Mit dieser Regel wird nach fehlgeschlagenen Anmeldeversuchen von einem neuen Standort gesucht:

rule failed_logins
{
  meta:
   author = "Security Team"
   description = "Detects multiple failed user logins within 10-minute windows."
   severity = "HIGH"

  events:
   $e.metadata.event_type = "USER_LOGIN"
   $e.security_result.action = "FAIL"
   $user = $e.target.user.userid

  match:
   $user over 10m

  outcome:
   $failed_login_count = count($e.metadata.id)
   $first_fail_time = min($e.metadata.event_timestamp.seconds)

  condition:
   #e >= 5
}

Im Abschnitt outcome werden die Ereignis- und Platzhaltervariablen aggregiert: Die fehlgeschlagenen Anmeldungen und die eindeutigen IP-Adressen werden gezählt und die Uhrzeit des Fehlers wird abgerufen.

outcome:
   $failed_login_count = count($e.metadata.id)
   $first_fail_time = min($e.metadata.event_timestamp.seconds)

Wenn Sie die spezielle Ergebnisvariable $risk_score einfügen und mit Werten belegen, wird ihr Wert (Ganzzahl oder Gleitkommazahl) auf der Seite Benachrichtigungen und IoCs für Benachrichtigungen angezeigt, die von der Abfrage generiert werden.

Wenn Sie im Abschnitt outcome einer Abfrage keine Variable $risk_score angeben, wird einer der folgenden Standardwerte festgelegt:

  • Wenn die Abfrage so konfiguriert ist, dass eine Benachrichtigung generiert wird, ist $risk_score auf 40 festgelegt.

  • Wenn die Abfrage nicht so konfiguriert ist, dass eine Benachrichtigung generiert wird, wird $risk_score auf 15 gesetzt.

Der Wert von $risk_score wird im UDM-Feld security_result.risk_score gespeichert.

Ergebnisvariable „risk_score“

In Google SecOps Risk Analytics werden Erkennungen und Warnungen automatisch mit Entitäten verknüpft, die sich auf diese Erkennung oder Warnung beziehen. Mit der Ergebnisvariablen risk_score wird ein Risikobetrag zugewiesen. Wenn dieser Wert nicht festgelegt ist, wird der Standardwert für die Erkennung oder Benachrichtigung verwendet. Sie können Standardwerte in den Einstellungen konfigurieren.

Um die Konsistenz auf der Plattform zu gewährleisten, empfehlen wir, die folgenden Wertebereiche zu verwenden, wenn Sie Ihren benutzerdefinierten Erkennungen eine risk_score zuweisen. Diese Ausrichtung trägt zur Standardisierung der Priorisierung von Benachrichtigungen und der Reaktions-Workflows bei.

Schweregrad Bewertungsbereich Beschreibung Beispiel
Benachrichtigung – Wichtig 90–100 Aktive Manipulation mit dem Potenzial, sich über ein einzelnes Nutzerkonto oder einen einzelnen Endpunkt hinaus auszuwirken. Sofortige Überprüfung erforderlich. Mimikatz wurde auf dem Domaincontroller ausgeführt.
Benachrichtigungen – Hoch 80–89 Aktiver Angriff auf einen einzelnen Endpunkt oder eine einzelne Entität. Sollte sofort überprüft werden. Der Produktionsserver ruft einen bekannten C2-Server auf.
Benachrichtigungen – Mittel 50–79 Potenzielles Sicherheitsproblem, das untersucht werden muss. Keine bestätigte Manipulation, aber Eskalierung möglich. Ein offengelegtes Anmeldedatenpaar, keine Anzeichen von Missbrauch.
Keine Benachrichtigungen – niedrig 20–49 Sicherheitsereignis mit geringen Auswirkungen, das in Kombination mit anderen Indikatoren oder Beobachtungen zu einem schwerwiegenderen Vorfall führen könnte. In der Regel ist keine Überprüfung erforderlich. Kann mit anderen Erkennungen durch zusammengesetzte Regeln kombiniert werden, um eine Benachrichtigung zu erstellen. Interner Portscan
Beobachtungen ohne Benachrichtigungen 1–19 Im Allgemeinen sind das Informationen, die dazu dienen, ein Situationsbewusstsein für eine Bedrohung zu schaffen. Erfordert in der Regel keine Überprüfung; kann durch zusammengesetzte Regeln mit anderen Erkennungen kombiniert werden, um Benachrichtigungen zu generieren. Ein Anmeldeereignis, keine Anzeichen für Missbrauch.

Da risk_score eine Ergebnisvariable ist, können Ihre Regeln je nach Faktoren wie Threat Intelligence oder anderen gleichzeitigen Bedingungen Nuancen ausdrücken.

Risikobewertungen für Entitäten können verwendet werden, um risikobasierte Benachrichtigungen nahezu in Echtzeit zu generieren. Weitere Informationen finden Sie unter Übersicht über Risk Analytics.

Ergebnisvariable „risk_entity_to_score“

Standardmäßig weist Google SecOps allen Entitäten in den Stichprobenereignissen die Risikobewertung einer Erkennung zu. Außerdem wird die Bewertung allen Entitäten zugewiesen, die in den Abschnitten match und outcome der Regel erfasst werden. Wenn Sie die Risikobewertung stattdessen bestimmten Einheiten zuweisen möchten, geben Sie zusätzlich zu risk_score die Ergebnisvariable risk_entity_to_score an. Die Risikobewertung unterstützt user- und asset-Entitäten. Die Entitätstypen RESOURCE und GROUP werden nicht unterstützt.

Sie können mehrere risk_entity_to_score-Variablen erstellen, indem Sie der Variablen einen eindeutigen String anhängen und die Risikobewertung bestimmten Entitäten zuweisen. Beispiel:

$risk_entity_to_score_source_asset = $e.principal.asset.hostname
$risk_entity_to_score_targeted_user = $e.target.user.userid

Mit diesen Ergebnisvariablen wird der im Abschnitt outcome der Regel angegebene risk_score den Entitäten $e.principal.asset.hostname und $e.target.user.userid zugewiesen.

Beispiel: Regel erkennt Anmeldungen in Administratorkonten

Mit dieser Regel werden erfolgreiche Anmeldungen bei Administratorkonten mit hohen Berechtigungen erkannt. Dabei wird das Keyword risk_entity_to_score verwendet, um die Ausrichtung explizit auf den angemeldeten Nutzer vorzunehmen. Mithilfe dieser Variablen wird sichergestellt, dass die berechnete Risikobewertung nur für diesen Nutzer und nicht für andere am Ereignis beteiligte Entitäten wie die Quell-IP-Adresse gilt.

Weitere Informationen zum Schreiben einer Regel mit mehreren Ereignissen finden Sie unter Regel mit mehreren Ereignissen.

rule suspicious_admin_privilege_escalation {
 // This rule matches single events. Rules can also match multiple events within
 // the same time window.

 meta:
   // Allows for storage of arbitrary key-value pairs of rule details, such as 
   // who wrote it, what it detects on, and version control.
   // The "author" and "severity" fields are special, since they are used as
   // columns on the rules dashboard. To sort based on these fields on the 
   // dashboard, add them here.
   // Severity value should be "Low", "Medium", or "High"
   author = "analyst123"
   description = "Detects suspicious login to critical admin accounts."
   severity = "HIGH"

 events:
   $e.metadata.event_type = "USER_LOGIN"
   $e.target.user.attribute.roles.name = "ADMIN"
   $e.security_result.summary = "Successful login with high-privilege access"

 outcome:
   // Multi-event rules require an aggregation function
   // For example, risk_score = max(0)
   // See https://docs.cloud.google.com/chronicle/docs/yara-l/yara-l-2-0-examples#outcome_conditionals_example_rule
   $risk_score = 80
   $risk_entity_to_score = $e.target.user.userid
   $source_ip = array_distinct($e.principal.ip)

 condition:
   $e
}

Beispiel: Regel überwacht interne Netzwerkverbindungen

Mit dieser Regel wird nach Lateral Movement gesucht, indem Netzwerkverbindungen zwischen internen Netzwerksegmenten identifiziert werden. Mit $risk_entity_to_score prefix wird mehreren Entitäten innerhalb eines einzelnen Erkennungsvorgangs ein Risiko zugewiesen. Die Risikobewertungen für den initiierenden Host ($risk_entity_to_score_source_asset) und den Zielnutzer ($risk_entity_to_score_targeted_user) werden aktualisiert. Die Risiko-Engine erfasst andere Ergebnisvariablen, die dieses spezifische Präfix nicht für den Kontext verwenden, ignoriert sie aber (ihre Risikobewertungen bleiben gleich).

Weitere Informationen zum Schreiben einer Regel mit mehreren Ereignissen finden Sie unter Regel mit mehreren Ereignissen und Beispiel für eine Regel mit bedingten Ergebnissen.

rule lateral_movement_network_connection {
 // This rule matches single events. You can also match multiple events within
 // the same time window.

 meta:
   // Allows for storage of arbitrary key-value pairs of rule details (for 
   // example, who wrote it, what it detects on, and version control).
   // The "author" and "severity" fields are special, since they are used as
   // columns on the rules dashboard. To sort based on these fields on the 
   // dashboard, add them here. Severity value should be "Low", "Medium" or "High"
   author = "analyst123"
   description = "Detects lateral movement attempts between internal segments."
   severity = "MEDIUM"

 events:
   $e.metadata.event_type = "NETWORK_CONNECTION"
   $e.principal.asset.hostname != ""
   $e.target.user.userid != ""
   // Can also use: $e.target.ip = /10\..*/
   net.ip_in_range_cidr($e.target.ip, "10.0.0.0/8")

 outcome:
   // Multi-event rules require an aggregation function
   // for example, risk_score = max(0)
   // See https://docs.cloud.google.com/chronicle/docs/yara-l/yara-l-2-0-examples#outcome-conditionals-example-rule
   $risk_score = 50
   $risk_entity_to_score_source_asset = $e.principal.asset.hostname
   $risk_entity_to_score_targeted_user = $e.target.user.userid
   $target_ip_info = array_distinct($e.target.ip)

 condition:
   $e
}

Datentypen von Ergebnisvariablen

Jede Ergebnisvariablen kann einen anderen Datentyp haben, der durch den Ausdruck bestimmt wird, mit dem sie berechnet wird. Die folgenden Ergebnisdatentypen werden in Google SecOps unterstützt:

  • integer
  • Gleitkommazahlen
  • String
  • Listen mit Ganzzahlen
  • Listen mit Gleitkommazahlen
  • Listen mit Strings

Bedingte Logik

Mit bedingter Logik können Sie den Wert eines Ergebnisses berechnen. Bedingungen werden mit dem folgenden Syntaxmuster angegeben:

if(BOOL_CLAUSE, THEN_CLAUSE)
if(BOOL_CLAUSE, THEN_CLAUSE, ELSE_CLAUSE)

Ein bedingter Ausdruck kann so gelesen werden: „Wenn BOOL_CLAUSE wahr ist, gib THEN_CLAUSE zurück, andernfalls ELSE_CLAUSE.“

BOOL_CLAUSE muss als boolescher Wert ausgewertet werden. Ein BOOL_CLAUSE-Ausdruck hat eine ähnliche Form wie Ausdrücke im Abschnitt events. Er kann beispielsweise Folgendes enthalten:

  • UDM-Feldnamen mit Vergleichsoperator:

    if($context.graph.entity.user.title = "Vendor", 100, 0)

  • Platzhaltervariable, die im Abschnitt events definiert wurde:

    if($severity = "HIGH", 100, 0)

  • Eine weitere Ergebnisvariable, die im Abschnitt outcome definiert ist:

    if($risk_score > 20, "HIGH", "LOW")

  • Funktionen, die einen booleschen Wert zurückgeben:

    if(re.regex($e.network.email.from, `.*altostrat.com`), 100, 0)

  • In einer Referenzliste nachschlagen:

    if($u.principal.hostname in %my_reference_list_name, 100, 0)

  • Vergleich der Aggregation:

    if(count($login.metadata.event_timestamp.seconds) > 5, 100, 0)

THEN_CLAUSE und ELSE_CLAUSE müssen denselben Datentyp haben. Wir unterstützen Ganzzahlen, Gleitkommazahlen und Strings.

Sie können die ELSE_CLAUSE weglassen, wenn der Datentyp „integer“ oder „float“ ist. Wird sie weggelassen, wird ELSE_CLAUSE als 0 ausgewertet. Beispiel:

`if($e.field = "a", 5)` is equivalent to `if($e.field = "a", 5, 0)`

Sie müssen die ELSE_CLAUSE angeben, wenn der Datentyp „string“ ist oder wenn die THEN_CLAUSE eine Platzhaltervariable oder eine Ergebnisvariable ist.

Mathematische Operationen

Sie können mathematische Operationen verwenden, um Ganzzahl- oder Gleitkommadatentypen in den Abschnitten outcome und events einer Abfrage zu berechnen. Google Security Operations unterstützt Addition, Subtraktion, Multiplikation, Division und Modulo als Operatoren der obersten Ebene in einer Berechnung.

Das folgende Snippet ist ein Beispiel für eine Berechnung im Abschnitt outcome:

outcome:
  $risk_score = max(100 + if($severity = "HIGH", 10, 5) - if($severity = "LOW", 20, 0))

Mathematische Operationen sind für die folgenden Operandentypen zulässig, sofern jeder Operand und der gesamte arithmetische Ausdruck richtig aggregiert werden (siehe Aggregationen):

  • Numerische Ereignisfelder
  • Numerische Platzhaltervariablen, die im Abschnitt events definiert sind
  • Numerische Ergebnisvariablen, die im Abschnitt outcome definiert sind
  • Funktionen, die Ganzzahlen oder Gleitkommazahlen zurückgeben
  • Aggregationen, die Ganzzahlen oder Gleitkommazahlen zurückgeben

Der Modulo-Operator ist für Gleitkommazahlen nicht zulässig.

Platzhaltervariablen in Ergebnissen

Beim Berechnen von Ergebnisvariablen können Sie Platzhaltervariablen verwenden, die im Ereignisabschnitt Ihrer Abfrage definiert wurden. In diesem Beispiel wird davon ausgegangen, dass $email_sent_bytes im Abschnitt „Ereignisse“ der Regel definiert wurde:

Beispiel: Einzelnes Ereignis ohne Match-Abschnitt

// No match section, so this is a single-event query.

outcome:
  // Use placeholder directly as an outcome value.
  $my_outcome = $email_sent_bytes

  // Use placeholder in a conditional.
  $other_outcome = if($file_size > 1024, "SEVERE", "MODERATE")

condition:
  $e

Beispiel: Regel für mehrere Ereignisse mit Abschnitt „Übereinstimmung“

match:
  // This is a multi event query with a match section.
  $hostname over 5m

outcome:
  // Use placeholder directly in an aggregation function.
  $max_email_size = max($email_sent_bytes)

  // Use placeholder in a mathematical computation.
  $total_bytes_exfiltrated = sum(
    1024
    + $email_sent_bytes
    + $file_event.principal.file.size
  )

condition:
  $email_event and $file_event

Ergebnisvariablen in Ausdrücken für die Ergebniszurordnung

Aus Ergebnisvariablen können andere Ergebnisvariablen abgeleitet werden, ähnlich wie bei Platzhaltervariablen, die im Abschnitt events definiert sind. Sie können in der Zuweisung einer anderen Ergebnisvariablen mit einem $-Token gefolgt vom Variablennamen auf eine Ergebnisvariable verweisen. Ergebnisvariablen müssen definiert werden, bevor in der Abfrage darauf verwiesen werden kann. Wenn sie in einem Zuweisungsausdruck verwendet werden, dürfen Ergebnisvariablen nicht aggregiert werden (siehe Aggregationen).

Im folgenden Beispiel wird der Wert der Ergebnisvariablen $risk_score aus der Ergebnisvariablen $event_count abgeleitet:

Beispiel: Ergebnisvariable, die aus einer anderen Ergebnisvariablen abgeleitet wird

match:
  // This is a multi event query with a match section.
  $hostname over 5m

outcome:
  // Aggregates all timestamp on login events in the 5 minute match window.
  $event_count = count($login.metadata.event_timestamp.seconds)

  // $event_count cannot be aggregated again.
  $risk_score = if($event_count > 5, "SEVERE", "MODERATE")

  // This is the equivalent of the 2 outcomes combined.
  $risk_score2 = if(count($login.metadata.event_timestamp.seconds) > 5, "SEVERE", "MODERATE")

condition:
  $e

Ergebnisvariablen können in jeder Art von Ausdruck auf der rechten Seite einer Ergebniszuweisung verwendet werden, mit Ausnahme der folgenden Ausdrücke:

  • Zusammenfassungen
  • Arrays.length()-Funktionsaufrufe
  • Mit den Modifikatoren any oder all

Zusammenfassungen

Wiederholte Ereignisfelder sind nicht skalare Werte. Das bedeutet, dass eine einzelne Variable auf mehrere Werte verweist. Die Ereignisfeldvariable $e.target.ip ist beispielsweise ein wiederkehrendes Feld und kann null, einen oder mehrere IP-Werte haben. Es handelt sich um einen nicht skalaren Wert. Die Ereignisfeldvariable $e.principal.hostname ist kein wiederkehrendes Feld und hat nur einen Wert (einen Skalarwert).

Sowohl nicht wiederholte als auch wiederholte Ereignisfelder, die im Abschnitt outcome einer Abfrage mit einem Abgleichszeitraum verwendet werden, sind nicht skalare Werte.

Beispiel: Ereignisse mit dem Abschnitt „match“ und einem nicht wiederkehrenden Feld gruppieren

In der folgenden Abfrage werden Ereignisse mit einem `match`-Abschnitt gruppiert und im `outcome`-Abschnitt wird auf ein nicht wiederholtes Ereignisfeld verwiesen:

rule OutcomeAndMatchWindow{
  ...
  match:
    $userid over 5m
  outcome:
    $hostnames = array($e.principal.hostname)
  ...
}

Ein beliebiges 5‑Minuten-Fenster, in dem die Abfrage ausgeführt wird, kann null, ein oder mehrere Ereignisse enthalten. Der Ergebnisbereich wird für alle Ereignisse in einem Match-Zeitraum ausgeführt. Jede Ereignisfeldvariable, auf die im Ergebnisabschnitt verwiesen wird, kann für jedes Ereignis im Abgleichszeitraum auf null, einen oder mehrere Werte des Felds verweisen. Wenn beispielsweise ein 5-Minuten-Zeitraum 5 $e-Ereignisse enthält, verweist $e.principal.hostname im Ergebnisbereich auf fünf verschiedene Hostnamen. Die Ereignisfeldvariable $e.principal.hostname wird im Abschnitt outcome dieser Abfrage als nicht skalarer Wert behandelt.

Da Ergebnisvariablen immer einen einzelnen Skalarwert ergeben müssen, muss jeder nicht skalare Wert, von dem eine Ergebniszuweisung abhängt, aggregiert werden, um einen einzelnen Skalarwert zu erhalten. Im Ergebnisbereich sind die folgenden Werte nicht skalar und müssen aggregiert werden:

  • Ereignisfelder (wiederholt oder nicht wiederholt), wenn in der Abfrage ein match-Abschnitt verwendet wird
  • Platzhalter für Ereignisse (wiederholt oder nicht wiederholt), wenn in der Abfrage ein match-Abschnitt verwendet wird
  • Wiederholte Ereignisfelder, wenn in der Abfrage kein match-Abschnitt verwendet wird
  • Platzhalter für wiederkehrende Termine, wenn in der Anfrage kein match-Abschnitt verwendet wird

Skalare Ereignisfelder, skalare Ereignisplatzhalter und Konstanten können in Abfragen, die keinen match-Abschnitt enthalten, in Aggregationsfunktionen eingeschlossen werden. In den meisten Fällen geben diese Aggregationen jedoch den umschlossenen Wert zurück, sodass sie nicht erforderlich sind. Eine Ausnahme ist die Aggregation array(), mit der Sie einen skalaren Wert explizit in ein Array umwandeln können.

Ergebnisvariablen werden wie Aggregationen behandelt: Sie dürfen nicht neu aggregiert werden, wenn in einer anderen Ergebniszuweisung auf sie verwiesen wird.

Sie können die folgenden Aggregatfunktionen verwenden:

Aggregatfunktion Beschreibung
max() Gibt den Höchstwert für alle möglichen Werte aus. Funktioniert nur mit Ganzzahlen und Gleitkommazahlen.
min() Gibt das Minimum aller möglichen Werte aus. Funktioniert nur mit Ganzzahlen und Gleitkommazahlen.
sum() Gibt die Summe aller möglichen Werte aus. Funktioniert nur mit Ganzzahlen und Gleitkommazahlen.
count_distinct() Erfasst alle möglichen Werte und gibt dann die Anzahl der eindeutigen möglichen Werte aus.
count() Verhält sich wie `count_distinct()`, gibt aber eine nicht eindeutige Anzahl möglicher Werte zurück.
array_distinct() Erfasst alle möglichen eindeutigen Werte und gibt dann eine Liste dieser Werte aus. Zuerst wird die Deduplizierung angewendet, um eine Liste mit eindeutigen Werten zu erstellen. Danach erfolgt die Kürzung. In der Suche wird die Liste auf maximal 1.000 zufällige Elemente gekürzt. In Dashboards und Regeln wird die Liste auf maximal 25 zufällige Elemente gekürzt.
array() Verhält sich wie array_distinct(), gibt aber eine nicht eindeutige Liste von Werten zurück. In der Suche wird die Liste auf maximal 1.000 zufällige Elemente gekürzt. In Dashboards und Regeln wird die Liste auf maximal 25 zufällige Elemente gekürzt.

Die Aggregatfunktion ist wichtig, wenn eine Regel einen condition-Abschnitt enthält, in dem angegeben wird, dass mehrere Ereignisse vorhanden sein müssen. Die Aggregatfunktion wird dann auf alle Ereignisse angewendet, die die Erkennung ausgelöst haben.

Beispiel: Bedingung für mehrere Ereignisse

Im Folgenden finden Sie ein Beispiel für eine Bedingung für mehrere Ereignisse. Wenn Ihr Abschnitt zu Ergebnis und Bedingung Folgendes enthält:

outcome:
  $asset_id_count = count($event.principal.asset_id)
  $asset_id_distinct_count = count_distinct($event.principal.asset_id)

  $asset_id_list = array($event.principal.asset_id)
  $asset_id_distinct_list = array_distinct($event.principal.asset_id)

condition:
  #event > 1

Da im Abschnitt „condition“ mehr als ein „event“ für jede Erkennung erforderlich ist, werden die Aggregatfunktionen auf mehrere Ereignisse angewendet. Angenommen, die folgenden Ereignisse haben eine Erkennung ausgelöst:

event:
  // UDM event 1
  asset_id="asset-a"

event:
  // UDM event 2
  asset_id="asset-b"

event:
  // UDM event 3
  asset_id="asset-b"

Die Werte Ihrer Ergebnisse sind dann:

    $asset_id_count = 3
    $asset_id_distinct_count = 2
    $asset_id_list = `["asset-a", "asset-b", "asset-b"]
    $asset_id_distinct_list = `["asset-a", "asset-b"]

Beschränkungen

  • Im Abschnitt outcome kann nicht auf eine neue Platzhaltervariable verwiesen werden, die nicht bereits im Abschnitt events oder im Abschnitt outcome definiert wurde.

  • Im Abschnitt outcome können keine Ereignisvariablen verwendet werden, die nicht im Abschnitt events definiert wurden.

  • Im Abschnitt outcome kann ein Ereignisfeld verwendet werden, das nicht im Abschnitt events verwendet wurde, sofern die Ereignisvariable, zu der das Ereignisfeld gehört, bereits im Abschnitt events definiert wurde.

  • Im Abschnitt outcome können nur Ereignisvariablen in Beziehung gesetzt werden, die bereits im Abschnitt events in Beziehung gesetzt wurden. Korrelationen treten auf, wenn zwei Ereignisfelder aus unterschiedlichen Ereignisvariablen gleichgesetzt werden.

Beispiele für den outcome-Abschnitt finden Sie unter Übersicht über YARA-L 2.0.

Weitere Informationen zum Deduplizieren von Erkennungen mit dem Abschnitt outcome finden Sie unter Kontextsensitive Analysen erstellen.

Nächste Schritte

Weitere Informationen

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