Syntax des Abschnitts „Bedingungen“

Unterstützt in:

Google SecOps SIEM

In diesem Dokument wird beschrieben, wie Sie den condition-Abschnitt einer YARA-L 2.0-Abfrage verwenden können.

Die Auswirkungen des Abschnitts condition hängen davon ab, ob Sie eine Ad-hoc-Abfrage ausführen oder eine dauerhafte Regel bereitstellen:

• Für Suche und Dashboards: Fungiert als Post-Filter. Es werden nur Datensätze zurückgegeben und gerendert, die den angegebenen Ausdrücken entsprechen.
• Erkennungsregeln (erforderlich): Dienen als Triggerlogik. Eine Benachrichtigung wird nur ausgelöst, wenn die Bedingungen für ein bestimmtes match-Fenster true ergeben.

Im Bereich condition können Sie Ausdrücke definieren, mit denen Ereignisse und Platzhaltervariablen gefiltert werden. Bei Verwendung in einer Such- oder Dashboardabfrage werden nur Ergebnisse angezeigt, die den Bedingungen entsprechen. Wenn sie in einer Erkennungsregel verwendet werden, müssen die Bedingungen erfüllt sein, um eine Benachrichtigung auszulösen.

Im Bereich condition können Sie boolesche Operatoren, Vergleichsoperatoren und Ergebnisse von outcome-Variablen verwenden, um festzulegen, ob die Abfrage ausgelöst werden soll.

condition-Abschnitt definieren

Definieren Sie die Bedingungsausdrücke für Ereignisse und Platzhaltervariablen im Abschnitt condition. Sie können match-Bedingungen für Variablen aus dem Abschnitt events angeben und optional das Schlüsselwort and verwenden, um Logik basierend auf dem Abschnitt outcome einzuschließen. Weitere Informationen finden Sie unter Syntax für Ergebnisabschnitte.

Sie können die Ausdrücke mit den Schlüsselwörtern and oder or verknüpfen:

• Verwenden Sie and zwischen den Bedingungen.

• Verwenden Sie or nur, wenn die Abfrage eine einzelne Ereignisvariable enthält.

Verwenden Sie das Zeichen # im Abschnitt condition vor einem beliebigen Ereignis- oder Platzhaltervariablennamen, um die Anzahl der unterschiedlichen Ereignisse oder Werte darzustellen, die alle Bedingungen im Abschnitt events erfüllen. Beispiel:

#c > 1 bedeutet, dass die Variable c mehr als einmal vorkommen muss.

Verwenden Sie das Zeichen $ im Abschnitt condition vor dem Namen einer Ergebnisvariablen, um den Wert dieses Ergebnisses darzustellen. Wenn es vor einem Ereignis- oder Platzhaltervariablennamen verwendet wird (z. B. $event), steht es für #event > 0.

Bei dieser Beispielregel wird ein Ergebnis zurückgegeben, wenn es innerhalb eines 10‑Minuten-Zeitraums (wie im Abschnitt match definiert) mehr als fünf (wie im Abschnitt condition definiert) fehlgeschlagene Anmeldungen für jeden Nutzer gibt:

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
}

Begrenzte und unbegrenzte Bedingungen

Sie können in einer Abfrage begrenzte oder unbegrenzte Bedingungen verwenden:

• Durch begrenzte Bedingungen wird erzwungen, dass die zugehörige Ereignisvariable vorhanden ist. Das bedeutet, dass mindestens ein Auftreten des Ereignisses in der Erkennung enthalten sein muss. Die folgenden Bedingungen sind begrenzt:

  $var // equivalent to #var > 0

  #var > n // where n >= 0

  #var >= m // where m > 0

• Mit unbegrenzten Bedingungen kann das Fehlen eines Ereignisses über einen bestimmten Zeitraum hinweg erkannt werden, z. B. ein Bedrohungsereignis ohne ein Ereignis zur Risikominderung innerhalb eines Zeitfensters von 10 Minuten. Bei ungebundenen Bedingungen kann die zugehörige Ereignisvariable nicht vorhanden sein (Abfragen ohne Existenz). Das bedeutet, dass das Ereignis in einem erkannten Vorfall nicht vorkommen muss und jeder Verweis auf Felder in der Ereignisvariablen den Wert „0“ ergibt.

  Die folgenden Bedingungen sind unbegrenzt:

  !$var // equivalent to #var = 0

  #var >= 0

  #var < n // where n > 0

  #var <= m // where m >= 0

Hinweis :Bei Abfragen, die das Nichtvorhandensein von Daten betreffen, fügt die Erkennungs-Engine der erwarteten Latenz (basierend auf der Ausführungshäufigkeit der Abfrage) eine Verzögerung von einer Stunde hinzu, um spät eintreffende Daten zu berücksichtigen.

Anforderungen an Anfragen zur Nichtexistenz

Damit eine Abfrage zum Nichtvorhandensein kompiliert werden kann, muss sie die folgenden Anforderungen erfüllen:

• Mindestens ein UDM-Ereignis muss eine begrenzte Bedingung haben (d. h. es muss mindestens ein UDM-Ereignis vorhanden sein).
• Wenn ein Platzhalter eine unbegrenzte Bedingung hat, muss er mindestens einem begrenzten UDM-Ereignis zugeordnet sein.
• Wenn eine Entität eine unbegrenzte Bedingung hat, muss sie mindestens einem begrenzten UDM-Ereignis zugeordnet sein.

Hinweis :Vermeiden Sie die Verwendung des Keywords not in Ereignis- und Platzhalterbedingungen.

Beispiel: Abfrage zum Nichtvorhandensein

Betrachten Sie die folgende Abfrage, in der der Bedingungsabschnitt fehlt:

rule NonexistenceExample {
  meta:
      author = "Google Security"
      description = "Example: non-existence query."
  events:
      $u1.metadata.event_type = "NETWORK_CONNECTION" // $u1 is a UDM event.
      $u2.metadata.event_type = "NETWORK_CONNECTION" // $u2 is a UDM event.
      $e1.graph.metadata.entity_type = "FILE"        // $e1 is an entity.
      $e2.graph.metadata.entity_type = "FILE"        // $e2 is an entity.

      $user = $u1.principal.user.userid // Match variable is required for multi-event query.

      // Placeholder Associations:
      //   u1        u2
      //   |  \    /
      // port   ip
      //   |       \
      //   e1        e2
      $u1.target.port = $port
      $e1.graph.entity.port = $port
      $u1.principal.ip = $ip
      $u2.target.ip = $ip
      $e2.graph.entity.ip = $ip

      // UDM-Entity Associations:
      // u1 - u2
      // |  \  |
      // e1   e2
      $u1.metadata.event_type = $u2.metadata.event_type
      $e1.graph.entity.hostname = $u1.principal.hostname
      $e2.graph.entity.hostname = $u1.target.hostname
      $e2.graph.entity.hostname = $u2.principal.hostname

  match:
    $user over 5m

  condition:
      //Add valid condition
}

Gültiger Abschnitt „Bedingung“

Hier sind einige gültige Beispiele für den Bedingungsabschnitt:

• $u1 and !$u2 and $e1 and $e2
• Alle UDM-Ereignisse und ‑Entitäten sind im Abschnitt „condition“ vorhanden.
• Mindestens ein UDM-Ereignis ist begrenzt.
• $u1 and !$u2 and $e1 and !$e2
• $e2ist unbegrenzt und zulässig, da es mit $u1 verknüpft ist, das begrenzt ist. Wenn $e2 nicht mit $u1 verknüpft wäre, wäre das ungültig.
• #port > 50 and #ip = 0
• Im Bedingungsabschnitt sind keine UDM-Ereignisse und ‑Entitäten vorhanden. Die vorhandenen Platzhalter decken jedoch alle UDM-Ereignisse und ‑Entitäten ab.
• $ip ist sowohl $u1 als auch $u2 zugewiesen und #ip = 0 ist eine unbegrenzte Bedingung. Begrenzte Bedingungen sind jedoch stärker als unbegrenzte Bedingungen. Da $port $u1 zugewiesen ist und #port > 50 eine begrenzte Bedingung ist, ist $u1 weiterhin begrenzt.

Ungültiger Abschnitt für Bedingungen

Die folgenden Beispiele für den Bedingungsabschnitt sind ungültig:

• $u1 and $e1
• Jedes UDM-Ereignis und jede UDM-Entität, die im Abschnitt events aufgeführt ist, muss auch im Abschnitt condition aufgeführt sein (oder es muss ein Platzhalter dafür zugewiesen sein, der im Abschnitt condition aufgeführt ist).
• $u1, $u2, $e1, $u2, #port > 50
• Kommas sind als Trennzeichen für Bedingungen nicht zulässig.
• !$u1 and !$u2 and $e1 and $e2
• Verstößt gegen die erste Anforderung, dass mindestens ein UDM-Ereignis begrenzt ist.
• ($u1 or #port < 50) and $u2 and $e1 and $e2
• Das or-Keyword wird bei unbegrenzten Bedingungen nicht unterstützt.
• ($u1 or $u2) and $e1 and $e2
• Das or-Keyword wird nicht zwischen verschiedenen Ereignisvariablen unterstützt.
• not $u1 and $u2 and $e1 and $e2
• Das not-Schlüsselwort ist für Ereignis- und Platzhalterbedingungen nicht zulässig.
• #port < 50 and #ip = 0
• Die Platzhalter verweisen zwar auf alle UDM-Ereignisse und ‑Entitäten, aber jede zugehörige Bedingung ist unbegrenzt. Das bedeutet, dass keines der UDM-Ereignisse begrenzt ist, was dazu führt, dass die Regel nicht kompiliert werden kann.

Ergebnisbedingungen

Sie können Bedingungen für Ergebnisvariablen im Abschnitt condition einfügen, die mit dem Keyword and oder or verknüpft oder dem Keyword not vorangestellt sind.

Die Bedingungen für das Ergebnis werden je nach Art der Ergebnisvariablen unterschiedlich angegeben:

• integer: Vergleich mit einem Ganzzahl-Literal mit Operatoren =, >, >=, <, <=, != Beispiel: $risk_score > 10

• float: Vergleich mit einem Gleitkomma-Literal mit Operatoren =, >, >=, <, <=, != Beispiel: $risk_score <= 5.5

• string: Vergleich mit einem Stringliteral mit = oder != Beispiel: $severity = "HIGH"

• Liste mit Ganzzahlen oder Arrays: Bedingung mit der Funktion arrays.contains angeben Beispiel: arrays.contains($event_ids, "id_1234")

Hinweis :Wenn Sie das Keyword or im Unterabschnitt „Bedingungen für Ereignisse oder Platzhalter“ verwenden, müssen Sie den gesamten Unterabschnitt in Klammern setzen. Das Folgende ist beispielsweise gültig: ($e1 or $e2) and $outcome > 0.

Wenn Sie in einer Abfrage mit einem match-Abschnitt eine Ergebnisbedingung angeben, wird die Abfrage für das Abfragekontingent als Multi-Event-Abfrage klassifiziert. Weitere Informationen zur Syntax für den Abgleich finden Sie unter Syntax für den Abgleich.

Beschränkungen

• Vermeiden Sie die Verwendung einer match-Variablen im condition-Abschnitt. Es handelt sich um einen semantischen Fehler, da Ereignisse nach dem match-Variablenwert gruppiert werden.

• Vermeiden Sie es, nur ungebundene Bedingungen für alle event-Variablen anzugeben, denen eine match-Variable zugewiesen ist. Es handelt sich um einen semantischen Fehler. Damit ein match-Variablenwert zurückgegeben wird, muss mindestens ein Ereignis vorhanden sein, das den Wert enthält.

• Wenn Sie ein gleitendes Fenster verwenden, muss die Pivot-Ereignisvariable in mindestens einer begrenzten Bedingung enthalten sein.

Nächste Schritte

• Syntax des Optionsbereichs
• „oder“ im Bedingungsabschnitt verwenden
• N OF-Syntax mit Ereignisvariablen verwenden

Weitere Informationen

• Ausdrücke, Operatoren und Konstrukte in YARA-L 2.0
• Funktionen in YARA-L 2.0
• Zusammengesetzte Erkennungsregeln erstellen
• Beispiele: YARA-L 2.0-Abfragen

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