Mit Sammlungen den Überblick behalten Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.

Übersicht über die Sprache YARA-L 2.0

YARA-L 2.0 ist eine Computersprache, mit der Sie Regeln für die Suche in Ihren Unternehmensprotokolldaten erstellen können, während sie in Ihr Chronicle-Konto aufgenommen werden. Die YARA-L-Syntax wird von der YARA-Sprache abgeleitet, die von VirusTotal entwickelt wurde. Die Sprache funktioniert in Verbindung mit der Chronicle Detection Engine und ermöglicht es Ihnen, über große Datenmengen nach Bedrohungen und anderen Ereignissen zu suchen. Siehe auch YARA-L 2.0-Sprachsyntax

Beispielregeln für YARA-L 2.0

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

Anmeldungen aus verschiedenen Städten

Mit der folgenden Regel wird nach Nutzern gesucht, die sich in weniger als fünf Minuten aus zwei oder mehr Städten 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:

  • Gruppiert Ereignisse mit dem Nutzernamen ($user) und gibt ihn zurück ($user), wenn eine Übereinstimmung gefunden wurde.
  • Die Zeitspanne beträgt 5 Minuten. Das bedeutet, dass nur Ereignisse korreliert werden, die weniger als 5 Minuten auseinanderliegen.
  • Nach einer Ereignisgruppe ($udm) wird gesucht, deren Ereignistyp USER_LOGIN ist.
  • 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 Zeitraums von 5 Minuten 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:

  • Gruppiert Ereignisse mit dem Nutzernamen ($user) und gibt ihn zurück ($user), wenn eine Übereinstimmung gefunden wurde.
  • Das Zeitfenster beträgt 4 Stunden, das heißt, es werden nur Ereignisse berücksichtigt, die durch weniger als 4 Stunden getrennt sind.
  • Sucht nach zwei Ereignisgruppen ($create und $delete, wobei $create gleich #create >= 1 ist).
  • $create entspricht USER_CREATION-Ereignissen und ruft die User-ID $user auf.
  • $user wird verwendet, um die beiden Ereignisgruppen zusammenzuführen.
  • $delete entspricht USER_DELETION-Ereignissen und ruft die User-ID $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 als das Ereignis von $create stattfindet. Wird eine Übereinstimmung gefunden, wird eine Übereinstimmung zurückgegeben.

Regel für ein einzelnes Ereignis

Regeln für einzelne Ereignisse sind Regeln, die sich über ein einzelnes Ereignis beziehen. Eine einzelne Ereignisregel kann Folgendes sein:

  • Jede Regel ohne übereinstimmenden Abschnitt.
  • Regel mit einem Abschnitt mit Übereinstimmungen und einem Bedingungsbereich, die nur auf das Vorhandensein eines Ereignisses prüfen, z. B. "$e", "#e > 0", "#e >= 1", "1 <= #e", "0 < #e"

Mit der folgenden Regel wird beispielsweise nur nach einem Nutzer-Anmeldeereignis gesucht und das erste Ereignis wird in den Unternehmensdaten zurückgegeben, die in Ihrem Chronicle-Konto gespeichert sind:

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

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

  condition:
    $e
}

Hier ein weiteres Beispiel für eine einzelne Ereignisregel mit einem Abschnitt zum Abgleich. Mit dieser Regel wird nach einem Nutzer gesucht, der sich in weniger als fünf Minuten mindestens einmal angemeldet hat. Hier wird überprüft, ob ein Nutzerereignis vorhanden ist.

rule SingleEventRule {
  meta:
    author = "noone@google.com"
    description = "windowed single event example rule"

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

  match:
    $user over 5m

  condition:
    #e > 0
}

Regel für mehrere Ereignisse

Mit mehreren Ereignisregeln können Sie viele Ereignisse in einem bestimmten Zeitraum gruppieren und Korrelationen zwischen Ereignissen finden. Eine typische Regel für mehrere Ereignisse hat Folgendes:

  • Übereinstimmungsbereich, der den Zeitraum angibt, über den Ereignisse gruppiert werden sollen.
  • Bedingungsabschnitt, der angibt, welche Bedingung die Erkennung und Prüfung auf das Vorhandensein mehrerer Ereignisse auslösen soll.

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

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
}

Einzelnes Ereignis innerhalb des Bereichs von IP-Adressen

Das folgende Beispiel zeigt eine einzelne Ereignisregel, die nach einer Übereinstimmung zwischen zwei bestimmten Nutzern und einem bestimmten Bereich von IP-Adressen 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
}

Beispiel für eine beliebige Regel

Mit der folgenden Regel wird nach Anmeldeereignissen gesucht, bei denen alle Quell-IP-Adressen nicht mit einer IP-Adresse übereinstimmen, die innerhalb von 5 Minuten sicher ist.

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 regulären YARA-L 2.0-Ausdruck wird nach Ereignissen mit E-Mails gesucht, die von der Domain altostrat.com empfangen wurden. Da nocase zum Vergleich der regex-Variable $host und der Funktion regex hinzugefügt wurde, wird bei diesen 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 Schiebefensterregel

Im folgenden Beispiel für YARA-L 2.0 mit Schiebefenstern wird nach Ereignissen von firewall_2 nach firewall_1-Ereignissen gesucht. Das Schlüsselwort after wird mit der Ereignisvariablen $e1 verwendet, um anzugeben, dass nur 10 Minuten nach jedem Ereignis firewall_1 stattfinden, wenn Ereignisse korreliert werden.

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 den Ausschluss von null

Wenn in der Regel keine allow_zero_values-Optionen angegeben sind, werden keine Werte von Übereinstimmungsvariablen zurückgegeben. Für andere referenzierte Ereignisfelder werden Nullwerte jedoch nicht ausgeschlossen, sofern Sie diese Bedingungen nicht explizit angeben. Weitere Informationen

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 dem Ergebnisbereich

Sie können den optionalen Abschnitt outcome in der YARA-L 2.0-Regel hinzufügen, um zusätzliche Informationen zu jeder Erkennung zu erhalten. Im Bedingungsabschnitt können Sie auch Bedingungen für Ergebnisvariablen angeben.

Hier finden Sie weitere Informationen:

Regel für mehrere Ereignisse mit Ergebnisbereich:

rule OutcomeRuleMultiEvent {
    meta:
      author = "noone@google.com"
    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)
        )

      $asset_id_list =
        array(
          if($u.principal.asset_id = "",
             "Empty asset id",
             $u.principal.asset_id
          )
        )

      $asset_id_distinct_list = array_distinct($u.principal.asset_id)

      $asset_id_count = count($u.principal.asset_id)

      $asset_id_distinct_count = count_distinct($u.principal.asset_id)

    condition:
      $u and $asset_context and $risk_score > 50 and not arrays.contains($asset_id_list, "id_1234")
}

Regel für ein einzelnes Ereignis mit Ergebnis:

rule OutcomeRuleSingleEvent {
    meta:
        author = "noone@google.com"
    events:
        $u.metadata.event_type = "FILE_COPY"
        $u.principal.file.size = $file_size
        $u.principal.hostname = $hostname

    outcome:
        $suspicious_host = $hostname
        $severity_tag = if($file_size > 1024, "SEVERE", "MODERATE")

    condition:
        $u
}

Eine Ergebnisregel für mehrere Ereignisse wird in eine Ergebnisregel mit einem Ereignis umgewandelt.

Sie können den Ergebnisbereich sowohl für Regeln für einzelne Ereignisse (Regeln ohne Zuordnungsauswahl) als auch für Regeln für mehrere Ereignisse (Regeln mit einer Übereinstimmung) verwenden. Wenn Sie die Regel zuvor als Multi-Event-Strategie entworfen haben, um nur den Ergebnisbereich zu verwenden, können Sie diese Regeln optional refaktorieren, indem Sie den Übereinstimmungsbereich löschen, um die Leistung zu verbessern. Da Ihre Regel keinen Übereinstimmungsbereich mehr hat, in dem die Gruppierung angewendet wird, erhalten Sie möglicherweise mehr Erkennungen. Diese Refaktorierung ist nur für Regeln möglich, die eine Ereignisvariable verwenden, wie im folgenden Beispiel gezeigt.

Ergebnisregel für mehrere Ereignisse, die nur eine Ereignisvariable verwendet (ein guter Kandidat für einen Refaktor):

rule OutcomeMultiEventPreRefactor {
    meta:
      author = "noone@google.com"
      description = "Outcome refactor rule, before the refactor"

    events:
      $u.udm.principal.hostname = $hostname

    match:
      $hostname over 5m

    outcome:
      $risk_score = max(if($hostname = "my-hostname", 100, 50))

    condition:
      $u
}

Sie können die Regel refaktorieren, indem Sie den Abschnitt „Übereinstimmung“ löschen. Außerdem müssen Sie die Aggregation im Ergebnisbereich entfernen, da die Regel jetzt ein einzelnes Ereignis ist. Weitere Informationen zu Aggregationen finden Sie in der Dokumentation zu Ergebniszusammenfassungen.

rule OutcomeSingleEventPostRefactor {
    meta:
      author = "noone@google.com"
      description = "Outcome refactor rule, after the refactor"

    events:
      $u.udm.principal.hostname = $hostname

    // We deleted the match section.

    outcome:
      // We removed the max() aggregate.
      $risk_score = if($hostname = "my-hostname", 100, 50)

    condition:
      $u
}

Beispiel für eine Funktion mit einer Platzhalterregel

Sie können dem Ergebnis eines Funktionsaufrufs eine Platzhaltervariable zuweisen und diese in anderen Bereichen der Regel verwenden, z. B. im Abschnitt zu Übereinstimmungen, Ergebnissen oder Bedingungen. Sehen Sie sich folgendes Beispiel an:

rule FunctionToPlaceholderRule {
    meta:
      author = "noone@google.com"
      description = "Rule that uses function to placeholder assignments"

    events:
        $u.metadata.event_type = "EMAIL_TRANSACTION"

        // Use function-placeholder assignment to extract the
        // address from an email.
        // address@website.com -> address
        $email_to_address_only = re.capture($u.network.email.from , "(.*)@")

        // Use function-placeholder assignment to normalize an email:
        // uid@??? -> uid@company.com
        $email_from_normalized = strings.concat(
            re.capture($u.network.email.from , "(.*)@"),
            "@company.com"
        )

        // Use function-placeholder assignment to get the day of the week of the event.
        // 1 = Sunday, 7 = Saturday.
        $dayofweek = timestamp.get_day_of_week($u.metadata.event_timestamp.seconds)

    match:
        // Use placeholder (from function-placeholder assignment) in match section.
        // Group by the normalized from email, and expose it in the detection.
        $email_from_normalized over 5m

    outcome:
        // Use placeholder (from function-placeholder assignment) in outcome section.
        // Assign more risk if the event happened on weekend.
        $risk_score = max(
            if($dayofweek = 1, 10, 0) +
            if($dayofweek = 7, 10, 0)
        )

    condition:
        // Use placeholder (from function-placeholder assignment) in condition section.
        // Match if an email was sent to multiple addresses.
        #email_to_address_only > 1
}

Beispielregel für Ergebnisbedingungen

Im Bedingungsabschnitt können Sie Ergebnisvariablen verwenden, die im Ergebnisbereich definiert wurden. Im folgenden Beispiel wird gezeigt, wie Sie nach Risikobewertungen filtern, um Rauschen in Erkennungen mithilfe von Ergebnisbedingungen zu reduzieren.

rule OutcomeConditionalRule {
    meta:
        author = "noone@google.com"
        description = "Rule that uses outcome conditionals"

    events:
        $u.metadata.event_type = "FILE_COPY"
        $u.principal.file.size = $file_size
        $u.principal.hostname = $hostname

        // 1 = Sunday, 7 = Saturday.
        $dayofweek = timestamp.get_day_of_week($u.metadata.collected_timestamp.seconds)

    outcome:
        $risk_score =
            if($file_size > 500*1024*1024, 2) + // Files 500MB are moderately risky
            if($file_size > 1024*1024*1024, 3) + // Files over 1G get assigned extra risk

            if($dayofweek=1 or $dayofweek=7, 4) + // Events from the weekend are suspicious

            if($hostname = /highly-privileged/, 5) // Check for files from highly privileged devices

    condition:
        $u and $risk_score >= 10
}