Übersicht über die Sprache YARA-L 2.0

YARA-L 2.0 ist eine Computersprache, die verwendet wird, um Regeln für die Suche in Enterprise-Protokolldaten während der Aufnahme in Ihr Chronicle-Konto zu erstellen. Die Syntax von YARA-L wird von der Sprache YARA abgeleitet, die von VirusTotal entwickelt wurde. Die Sprache wird zusammen mit dem Chronicle Detection Engine verwendet. So können Sie in großen Datenmengen nach Bedrohungen und anderen Ereignissen suchen. Siehe auch YARA-L 2.0-Sprachsyntax

YARA-L 2.0-Beispielregeln

Die folgenden Beispiele zeigen Regeln, die in YARA-L 2.0 geschrieben wurden. Sie zeigen, wie Ereignisse in der Regelsprache korreliert werden.

Anmeldungen aus verschiedenen Städten

Mit der folgenden Regel wird nach Nutzern gesucht, die sich in zwei oder mehr Städten in weniger als fünf Minuten in Ihrem Unternehmen angemeldet haben:

rule DifferentCityLogin {
  meta:

  events:
    $udm.metadata.event_type = "USER_LOGIN"
    $udm.principal.user.userid = $user
    $udm.principal.location.city = $city

  match:
    $user over 5m

  condition:
    $udm and #city > 1
}

Übereinstimmungsvariable: $user

Ereignisvariable:$udm

Platzhaltervariable: $city und $user

Im Folgenden wird die Funktionsweise dieser Regel beschrieben:

  • Ereignisse werden mit dem Nutzernamen ($user) gruppiert und zurückgegeben ($user), wenn eine Übereinstimmung gefunden wurde.
  • Die Zeitspanne beträgt 5 Minuten. Das heißt, nur Ereignisse, die weniger als 5 Minuten auseinanderliegen, werden korreliert.
  • Es wird nach einer Ereignisgruppe ($udm) gesucht, deren Ereignistyp USER_LOGIN lautet.
  • Für diese Ereignisgruppe ruft die Regel die Nutzer-ID als $user und die Anmeldestadt als $city. auf
  • Gibt eine Übereinstimmung zurück, wenn die Anzahl der $city-Werte in der Ereignisgruppe ($udm) innerhalb des 5-minütigen Zeitraums größer als 1 ist.

Schnelles Erstellen und Löschen von Nutzern

Mit der folgenden Regel wird nach Nutzern gesucht, die innerhalb von vier Stunden erstellt und dann gelöscht wurden:

rule UserCreationThenDeletion {
  meta:

  events:
    $create.target.user.userid = $user
    $create.metadata.event_type = "USER_CREATION"

    $delete.target.user.userid = $user
    $delete.metadata.event_type = "USER_DELETION"

    $create.metadata.event_timestamp.seconds <=
       $delete.metadata.event_timestamp.seconds

  match:
    $user over 4h

  condition:
    $create and $delete
}

Ereignisvariablen:$create und $delete

Übereinstimmungsvariable: $user

Platzhaltervariable: –

Im Folgenden wird die Funktionsweise dieser Regel beschrieben:

  • Ereignisse werden mit dem Nutzernamen ($user) gruppiert und zurückgegeben ($user), wenn eine Übereinstimmung gefunden wurde.
  • Ein Zeitfenster beträgt 4 Stunden. Das heißt, es werden nur Ereignisse berücksichtigt, die durch weniger als 4 Stunden getrennt sind.
  • Suche nach zwei Ereignisgruppen ($create und $delete, wobei $create mit #create >= 1 übereinstimmt).
  • $create entspricht USER_CREATION-Ereignissen und ruft die Nutzer-ID als $user auf.
  • $user wird verwendet, um die beiden Ereignisgruppen zusammenzuführen.
  • $delete entspricht USER_DELETION-Ereignissen und ruft die Nutzer-ID als $user auf. Diese Regel sucht nach einer Übereinstimmung, bei der die Nutzerkennung in den beiden Ereignisgruppen identisch ist.
  • Diese Regel sucht nach Fällen, in denen das Ereignis „$delete“ später auftritt als das Ereignis aus „$create“. Wenn es gefunden wird, wird eine Übereinstimmung zurückgegeben.

Single-Event- und Multi-Event-Ereignisse

Die folgenden Beispielregeln zeigen, wie Sie eine Regel erstellen, mit der Sie nach einem einzelnen Ereignis suchen und es dann ändern können, um nach mehreren Ereignissen zu suchen.

Im Folgenden sehen Sie eine Version der Regel für einzelne Ereignisse:

rule SingleEventRule {
  meta:
    author = "noone@altostrat.com"

  events:
    $e.metadata.event_type = "USER_LOGIN"

  condition:
    $e
}

Bei dieser Regel wird einfach nach einem Anmeldeereignis eines Nutzers gesucht und das erste Ereignis in den Unternehmensdaten zurückgegeben, das in Ihrem Chronicle-Konto gespeichert ist.

Folgende Regelung gilt für mehrere Ereignisse:

rule MultiEventRule {
  meta:
    author = "noone@altostrat.com"

  events:
    $e.metadata.event_type = "USER_LOGIN"
    $e.principal.user.userid = $user

  match:
    $user over 10m

  condition:
    #e >= 10
}

Mit der Regel wird nach einem Nutzer gesucht, der sich in weniger als zehn Minuten mindestens zehnmal angemeldet hat.

Einzelnes Ereignis innerhalb eines IP-Adressbereichs

Das folgende Beispiel zeigt eine einzelne Ereignisregel, die nach einer Übereinstimmung zwischen zwei bestimmten Nutzern und einem bestimmten IP-Adressbereich sucht:

rule OrsAndNetworkRange {
  meta:
    author = "noone@altostrat.com"

  events:
    // Checks CIDR ranges.
    net.ip_in_range_cidr($e.principal.ip, "203.0.113.0/24")

    // Detection when the hostname field matches either value using or.
    $e.principal.hostname = /pbateman/ or $e.principal.hostname = /sspade/

  condition:
    $e
}

beliebiges Regelbeispiel

Mit der folgenden Regel wird nach Anmeldeereignissen gesucht, bei denen alle Quell-IP-Adressen innerhalb eines Zeitraums von fünf Minuten nicht mit einer sicheren IP-Adresse übereinstimmen.

rule SuspiciousIPLogins {
  meta:
    author = "noone@google.com"

  events:
    $e.metadata.event_type = "USER_LOGIN"

    // Detects if all source IP addresses in an event do not match "100.97.16.0"
    // For example, if an event has source IP addresses
    // ["100.97.16.1", "100.97.16.2", "100.97.16.3"],
    // it will be detected since "100.97.16.1", "100.97.16.2",
    // and "100.97.16.3" all do not match "100.97.16.0".

    all $e.principal.ip != "100.97.16.0"

    // Assigns placeholder variable $ip to the $e.principal.ip repeated field.
    // There will be one detection per source IP address.
    // For example, if an event has source IP addresses
    // ["100.97.16.1", "100.97.16.2", "100.97.16.3"],
    // there will be one detection per address.

    $e.principal.ip = $ip

  match:
    $ip over 5m

  condition:
    $e
}

Reguläre Ausdrücke in einer Regel

Im folgenden Beispiel für einen YARA-L 2.0-Ausdruck mit regulären Ausdrücken wird nach Ereignissen mit E-Mails gesucht, die von der Domain "altostrat.com" eingehen. Da „nocase“ dem $host-Variablen regex und der Funktion regex hinzugefügt wurde, wird bei beiden Vergleichen nicht zwischen Groß- und Kleinschreibung unterschieden.

rule RegexRuleExample {
  meta:
    author = "noone@altostrat.com"

  events:
    $e.principal.hostname = $host
    $host = /.*HoSt.*/ nocase
    re.regex($e.network.email.from, `.*altostrat\.com`) nocase

  match:
    $host over 10m

  condition:
    #e > 10
}

Beispiel für Regeln für Schiebefenster

Im folgenden Beispiel für das YARA-L 2.0-Schiebefenster wird nach firewall_2-Ereignissen nach firewall_1-Ereignissen gesucht. Das Keyword after wird mit der Pivot-Ereignisvariablen $e1 verwendet, um anzugeben, dass nur 10 Minuten nach jedem firewall_1-Ereignis beim Korrelieren von Ereignissen ein Häkchen gesetzt werden soll.

rule SlidingWindowRuleExample {
  meta:
    author = "noone@google.com"

  events:
    $e1.metadata.product_name = "firewall_1"
    $e1.principal.hostname = $host

    $e2.metadata.product_name = "firewall_2"
    $e2.principal.hostname = $host

  match:
    $host over 10m after $e1

  condition:
    $e1 and !$e2
}

Beispiel für einen Nullwert

Wenn die Regel keine Optionen für allow_zero_values angibt, werden keine Werte von Übereinstimmungsvariablen zurückgegeben. Bei anderen referenzierten Ereignisfeldern werden Werte nur dann ausgeschlossen, wenn Sie solche Bedingungen explizit angeben. Weitere Informationen findest du hier.

rule ExcludeZeroValues {
  meta:
    "author" = "noone@google.com"

  events:
    $e1.metadata.event_type = "NETWORK_DNS"
    $e1.principal.hostname = $hostname

    // $e1.principal.user.userid may be empty string.
    $e1.principal.user.userid != "Guest"

    $e2.metadata.event_type = "NETWORK_HTTP"
    $e2.principal.hostname = $hostname

    // $e2.target.asset_id cannot be empty string as explicitly specified.
    $e2.target.asset_id != ""

  match:
    // $hostname cannot be empty string.
    $hostname over 1h

  condition:
    $e1 and $e2
}

Beispiel für eine Regel mit Ergebnisbereich

Du kannst den optionalen Abschnitt outcome in der YARA-L 2.0-Regel hinzufügen, um zusätzliche Informationen zu jeder Erkennung zu extrahieren. Die Syntax dieses Abschnitts und die Übersicht dieses Abschnitts finden Sie in der Verwendung.

rule DetectionWithOutcomeSectionAndConditionalsAndAddition {
    meta:
    events:
      $u.udm.principal.hostname = $hostname
      $asset_context.graph.entity.hostname = $hostname

      $severity = $asset_context.graph.entity.asset.vulnerabilities.severity

    match:
      $hostname over 5m

    outcome:
      $risk_score =
        max(
            100
          + if($hostname = "my-hostname", 100, 50)
          + if($severity = "HIGH", 10)
          + if($severity = "MEDIUM", 5)
          + if($severity = "LOW", 1)
        )
    condition:
      $u and $asset_context
}