Übersicht über die Sprache YARA-L 2.0

Unterstützt in:

YARA-L 2.0 ist eine Computersprache, mit der Regeln für die Suche in den Logdaten Ihres Unternehmens bei der Aufnahme in Ihre Google Security Operations-Instanz erstellt werden. Die YARA-L-Syntax basiert auf der YARA-Sprache, die von VirusTotal entwickelt wurde. Die Sprache funktioniert in Verbindung mit der Google SecOps Detection Engine und ermöglicht es Ihnen, in großen Datenmengen nach Bedrohungen und anderen Ereignissen zu suchen.

Hier finden Sie weitere Informationen:

YARA-L 2.0 – Beispielregeln

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

Regeln und Optimierung

Mit der folgenden Regel wird nach bestimmten Mustern in Ereignisdaten gesucht und eine Erkennung erstellt, wenn die Muster gefunden werden. Diese Regel enthält eine Variable $e1 für den Tracking-Ereignistyp und das UDM-Feld metadata.event_type. Die Regel prüft auf bestimmte Vorkommen von Übereinstimmungen mit regulären Ausdrücken mit e1. Wenn das Ereignis $e1 eintritt, wird eine Erkennung erstellt. Die Regel enthält eine not-Bedingung, um bestimmte nicht schädliche Pfade auszuschließen. Sie können not-Bedingungen hinzufügen, um falsch positive Ergebnisse zu vermeiden. 

rule suspicious_unusual_location_svchost_execution
{

 meta:
   author = "Google Cloud Security"
   description = "Windows 'svchost' executed from an unusual location"
   yara_version = "YL2.0"
   rule_version = "1.0"

 events:

   $e1.metadata.event_type = "PROCESS_LAUNCH"
   re.regex($e1.principal.process.command_line, `\bsvchost(\.exe)?\b`) nocase
   not re.regex($e1.principal.process.command_line, `\\Windows\\System32\\`) nocase

condition:

   $e1
}

Anmeldungen aus verschiedenen Städten

Mit der folgenden Regel wird nach Nutzern gesucht, die sich innerhalb von fünf Minuten von mindestens zwei Städten aus 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
}

Abgleichsvariable: $user

Ereignisvariable:$udm

Platzhaltervariable: $city und $user

So funktioniert diese Regel:

  • Gruppiert Ereignisse mit dem Nutzernamen ($user) und gibt sie zurück ($user), wenn eine Übereinstimmung gefunden wird.
  • Der Zeitraum beträgt 5 Minuten. Das bedeutet, dass nur Ereignisse korreliert werden, die weniger als 5 Minuten auseinanderliegen.
  • Suche nach einer Ereignisgruppe ($udm), deren Ereignistyp USER_LOGIN ist.
  • Für diese Ereignisgruppe wird die Nutzer-ID in der Regel als $user und die Stadt der Anmeldung als $city. aufgerufen.
  • Gibt eine Übereinstimmung zurück, wenn die Anzahl der eindeutigen city-Werte (angegeben durch #city) in der Ereignisgruppe ($udm) innerhalb des 5-Minuten-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

Abgleichsvariable: $user

Platzhaltervariable: –

So funktioniert diese Regel:

  • Gruppiert Ereignisse mit dem Nutzernamen ($user) und gibt sie zurück ($user), wenn eine Übereinstimmung gefunden wird.
  • Das Zeitfenster beträgt 4 Stunden. Das bedeutet, dass nur Ereignisse korreliert werden, die weniger als 4 Stunden auseinanderliegen.
  • Es wird nach zwei Ereignisgruppen gesucht ($create und $delete, wobei $create gleich #create >= 1 ist).
  • $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. Bei dieser Regel wird nach einer Übereinstimmung gesucht, bei der die Nutzer-ID in den beiden Ereignisgruppen identisch ist.
  • Mit dieser Regel wird nach Fällen gesucht, in denen das Ereignis aus $delete später als das Ereignis aus $create eintritt. Wenn ein solcher Fall gefunden wird, wird eine Übereinstimmung zurückgegeben.

Regel für einzelne Termine

Regeln für einzelne Ereignisse korrelieren über ein einzelnes Ereignis hinweg. Eine einzelne Ereignisregel kann Folgendes sein:

  • Regeln ohne „Abgleich“-Abschnitt.
  • Regel mit einem match-Abschnitt und einem condition-Abschnitt, in dem nur das Vorhandensein eines Ereignisses geprüft wird (z. B. „$e“, „#e > 0“, „#e >= 1“, „1 <= #e“, „0 < #e“).

Mit der folgenden Regel wird beispielsweise nach einem Nutzeranmeldeereignis gesucht. Das erste Ereignis, das in den Unternehmensdaten in Ihrem Google SecOps-Konto gefunden wird, wird zurückgegeben:

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

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

  condition:
    $e
}

Hier ist ein weiteres Beispiel für eine Regel für ein einzelnes Ereignis mit einem Abschnitt „Übereinstimmung“. Mit dieser Regel wird nach einem Nutzer gesucht, der sich mindestens einmal innerhalb von 5 Minuten angemeldet hat. Es wird geprüft, ob ein Nutzeranmeldeereignis vorhanden ist.

rule SingleEventRule {
  meta:
    author = "alice@example.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
}

rule MultiEventRule{
  meta:
    author = "alice@example.com"
    description = "Rule with outcome condition and simple existence condition on one event variable"

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

  match:
    $user over 10m

  outcome:
    $num_events_in_match_window = count($e.metadata.id)

  condition:
    #e > 0 and $num_events_in_match_window >= 10 // Could be rewritten as #e >= 10
}

Regel für mehrere Ereignisse

Mit mehreren Ereignisregeln können Sie viele Ereignisse über einen bestimmten Zeitraum hinweg gruppieren und versuchen, Korrelationen zwischen Ereignissen zu finden. Eine typische Regel für mehrere Ereignisse hat Folgendes:

  • Ein match-Abschnitt, in dem der Zeitraum angegeben wird, über den Ereignisse gruppiert werden müssen.
  • Ein condition-Abschnitt, in dem angegeben wird, welche Bedingung die Erkennung auslösen soll, und in dem geprüft wird, ob mehrere Ereignisse vorhanden sind.

Die folgende Regel sucht beispielsweise nach einem Nutzer, der sich in weniger als 10 Minuten mindestens 10-mal 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 im Bereich von IP-Adressen

Im folgenden Beispiel wird eine einzelne Ereignisregel gezeigt, die nach Übereinstimmungen zwischen zwei bestimmten Hostnamen 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 innerhalb eines Zeitraums von 5 Minuten nicht mit einer als sicher bekannten IP-Adresse übereinstimmen.

rule SuspiciousIPLogins {
  meta:
    author = "alice@example.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 Ausdruck in YARA-L 2.0 wird nach Ereignissen mit E-Mails gesucht, die von der Domain „altostrat.com“ empfangen wurden. Da nocase der Variablen $host für den regex-Vergleich und der regex-Funktion hinzugefügt wurde, wird bei beiden Vergleichen die Groß- und Kleinschreibung nicht beachtet.

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
}

Beispiele für zusammengesetzte Regeln

Zusammengesetzte Erkennungen verbessern die Bedrohungserkennung durch die Verwendung zusammengesetzter Regeln. Diese zusammengesetzten Regeln verwenden Erkennungen aus anderen Regeln als Eingabe. So lassen sich komplexe Bedrohungen erkennen, die mit einzelnen Regeln möglicherweise nicht erkannt werden. Weitere Informationen finden Sie unter Übersicht über zusammengesetzte Erkennungen.

Erkennung von Stolperdrähten

Zusammengesetzte Tripwire-Erkennungen sind die einfachste Form einer zusammengesetzten Erkennung, die auf Feldern innerhalb von Erkennungsergebnissen basiert, z. B. auf Ergebnisvariablen oder Regelmetadaten. Sie helfen, Erkennungen nach Bedingungen zu filtern, die auf ein höheres Risiko hinweisen können, z. B. ein Administratornutzer oder eine Produktionsumgebung.

rule composite_admin_detection {
  meta:
    rule_name = "Detection with Admin User"
    author = "Google Cloud Security"
    description = "Composite rule that looks for any detections where the actor is an admin user"
    severity = "Medium"

  events:
    $rule_name = $d.detection.detection.rule_name
    $principal_user = $d.detection.detection.outcomes["principal_users"]
    $principal_user = /admin|root/ nocase

  match:
    $principal_user over 1h

  outcome:
    $risk_score = 75
    $upstream_rules = array_distinct($rule_name)

  condition:
    $d
}

Erkennungen für Schwellenwerte und Aggregation

Mit Regeln für die Erkennung von Aggregationszusammensetzungen können Sie Erkennungsergebnisse anhand gemeinsamer Attribute wie Hostname oder Nutzername gruppieren und die aggregierten Daten analysieren. Im Folgenden sind einige gängige Anwendungsfälle aufgeführt:

  • Nutzer identifizieren, die eine große Anzahl von Sicherheitswarnungen oder ein hohes aggregiertes Risiko verursachen.
  • Hosts mit ungewöhnlichen Aktivitätsmustern werden erkannt, indem zugehörige Erkennungen zusammengefasst werden.

Beispiel für die Risikoaggregation:

rule composite_risk_aggregation {
  meta:
    rule_name = "Risk Aggregation Composite"
    author = "Google Cloud Security"
    description = "Composite detection that aggregates risk of a user over 48 hours"
    severity = "High"

  events:
    $rule_name = $d.detection.detection.rule_name
    $principal_user = $d.detection.detection.outcomes["principal_users"]
    $risk = $d.detection.detection.risk_score

  match:
    $principal_user over 48h

  outcome:
    $risk_score = 90
    $cumulative_risk = sum($risk)
    $principal_users = array_distinct($principal_users)
    $upstream_rules = array_distinct($rule_name)

  condition:
    $d and $cumulative_risk > 500
}

Beispiel für die Zusammenfassung von Taktiken:

rule composite_tactic_aggregation {
  meta:
    rule_name = "MITRE Tactic Aggregation Composite"
    author = "Google Cloud Security"
    description = "Composite detection that detects if a user has triggered detections over multiple mitre tactics."
    severity = "Medium"

  events:
    $principal_user = $d.detection.detection.outcomes["principal_users"]
    $tactic = $d.detection.detection.rule_labels["tactic"]
    $rule_name = $d.detection.detection.rule_name

  match:
    $principal_user over 48h

  outcome:
    $mitre_tactics_count = count_distinct($tactic)
    $mitre_tactics = array_distinct($d.detection.rule_labels["tactic"])
    $risk_score = min(100, (50+15*$mitre_tactics_count))
    $upstream_rules = array_distinct($rule_name)

  condition:
    $d and $mitre_tactics_count > 1
}

Sequenzielle zusammengesetzte Erkennungen

Bei sequenziellen zusammengesetzten Erkennungen werden Muster von zusammenhängenden Ereignissen erkannt, bei denen die Reihenfolge der Erkennungen wichtig ist, z. B. eine Erkennung eines Brute-Force-Anmeldeversuchs, gefolgt von einer erfolgreichen Anmeldung. Diese Muster können mehrere Basis-Erkennungen oder eine Kombination aus Basis-Erkennungen und Ereignissen umfassen.

rule composite_bruteforce_login {
  meta:
    rule_name = "Bruteforce Login Composite"
    author = "Google Cloud Security"
    description = "Detects when an IP address associated with a Workspace brute force attempt successfully logs in"
    severity = "High"

  events:
    $bruteforce_detection.detection.detection.rule_name = /Workspace Anomalous Failed Logins/
    $bruteforce_ip = $d.detection.detection.outcomes["principal_ips"]

    $login_event.metadata.product_name = "login"
    $login_event.metadata.product_event_type = "login_success"
    $login_event.metadata.vendor_name = "Google Workspace"
    $login_ip = $login_event.principal.ip

    // Ensure the brute force detection and successful login occurred from the same IP
    $login_ip = $bruteforce_ip

    $target_account = $login_event.target.user.email_addresses

    // Ensure the brute force detection occurred before the successful login
    $bruteforce_detection.detection.detection_time.seconds < $login_event.metadata.event_timestamp.seconds

  match:
    $bruteforce_ip over 24h

  outcome:
    $risk_score = 90
    $principal_users = array_distinct($target_account)

  condition:
    $bruteforce_detection and $login_event
}

Kontextsensitive Erkennungen

Kontextsensitive zusammengesetzte Erkennungen werden mit zusätzlichem Kontext angereichert, z. B. mit IP-Adressen, die in Threat-Feeds gefunden wurden.

rule composite_tor_enrichment {
  meta:
    rule_name = "Detection with IP from TOR Feed"
    author = "Google Cloud Security"
    description = "Adds additional context from the TOR intel feed to detections"
    severity = "High"

  events:
    $detection_ip = $d.detection.detection.outcomes["principal_ips"]
    $gcti.graph.metadata.entity_type = "IP_ADDRESS"
    $gcti.graph.metadata.vendor_name = "Google Cloud Threat Intelligence"
    $gcti_feed.graph.metadata.source_type = "GLOBAL_CONTEXT"
    $gcti.graph.metadata.product_name = "GCTI Feed"
    $gcti.graph.metadata.threat.threat_feed_name = "Tor Exit Nodes"

    $detection_ip = $gcti.graph.entity.ip

    $rule_name = $d.detection.detection.rule_name
    $risk = $d.detection.detection.outcomes["risk_score"]

  match:
    $detection_ip, $rule_name over 1h

  outcome:
    $risk_score = 80
    $upstream_rule = array_distinct($rule_name)

  condition:
    $d and $gcti
}

Erkennung von gemeinsam auftretenden Begriffen

Zusammengesetzte Co-occurrence-Erkennungen sind eine Form der Aggregation, mit der eine Kombination aus zusammengehörigen Ereignissen erkannt werden kann, z. B. eine Kombination aus Erkennungen von Berechtigungseskalierung und Datenexfiltration, die von einem Nutzer ausgelöst werden.

rule composite_privesc_exfil_sequential {
  meta:
    rule_name = "Privilege Escalation and Exfiltration Composite"
    author = "Google Cloud Security"
    description = "Looks for a detection sequence of privilege escalation followed by exfiltration."
    severity = "High"

  events:
    $privilege_escalation.detection.detection.rule_labels["tactic"] = "TA0004"
    $exfiltration.detection.detection.rule_labels["tactic"] = "TA0010"

    $pe_user = $privilege_escalation.detection.detection.outcomes["principal_users"]
    $ex_user = $exfiltration.detection.detection.outcomes["principal_users"]

    $pe_user = $ex_user

  match:
    $pe_user over 48h

  outcome:
    $risk_score = 75
    $privesc_rules = array_distinct($privilege_escalation.detection.detection.rule_name)
    $exfil_rules = array_distinct($exfiltration.detection.detection.rule_name)

  condition:
    $privilege_escalation and $exfiltration
}

Beispiel für eine Regel für ein gleitendes Fenster

Im folgenden YARA-L 2.0-Beispiel für ein Fenster mit Text wird nach dem Fehlen von firewall_2-Ereignissen nach firewall_1-Ereignissen gesucht. Das Keyword after wird mit der Pivot-Ereignisvariablen $e1 verwendet, um anzugeben, dass bei der Korrelation von Ereignissen nur 10-Minuten-Zeiträume nach jedem firewall_1-Ereignis berücksichtigt werden sollen.

rule SlidingWindowRuleExample {
  meta:
    author = "alice@example.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 Nullwerten

Die Rules Engine filtert die Nullwerte für alle Platzhalter, die im Abschnitt match verwendet werden, implizit heraus. Weitere Informationen finden Sie im Abschnitt Umgang mit Nullwerten.match Dies kann mit der Option allow_zero_values deaktiviert werden, wie unter allow_zero_values beschrieben.

Bei anderen referenzierten Ereignisfeldern werden Nullwerte jedoch nicht ausgeschlossen, sofern Sie solche Bedingungen nicht explizit angeben.

rule ExcludeZeroValues {
  meta:
    author = "alice@example.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. The rule behaves as if the
    // predicate, `$hostname != ""` was added to the events section, because
    // `$hostname` is used in the match section.
    $hostname over 1h

  condition:
    $e1 and $e2
}

Beispiel für eine Regel mit dem Abschnitt outcome

Sie können den optionalen Abschnitt outcome in einer YARA-L 2.0-Regel hinzufügen, um zusätzliche Informationen zu den einzelnen Erkennungen zu extrahieren. Im Abschnitt „Bedingung“ können Sie auch Bedingungen für Ergebnisvariablen angeben. Im Abschnitt outcome einer Erkennungsregel können Sie Variablen für die nachgelagerte Verwendung festlegen. Sie können beispielsweise einen Schweregrad auf Grundlage der Daten aus den analysierten Ereignissen festlegen.

Hier finden Sie weitere Informationen:

Regel mit mehreren Ereignissen und Ergebnisabschnitt:

In der folgenden Regel werden zwei Ereignisse berücksichtigt, um den Wert von $hostname zu ermitteln. Wenn der Wert von $hostname über einen Zeitraum von 5 Minuten übereinstimmt, wird eine Schweregradbewertung angewendet. Wenn Sie im Abschnitt match einen Zeitraum angeben, wird die Regel innerhalb des angegebenen Zeitraums geprüft. 

rule OutcomeRuleMultiEvent {
    meta:
      author = "Google Cloud Security"
    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")
}


rule OutcomeRuleMultiEvent {
    meta:
      author = "alice@example.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:
      $total_network_bytes = sum($u.network.sent_bytes) + sum($u.network.received_bytes)

      $risk_score = if(total_network_bytes > 1024, 100, 50) + 
        max(
          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 Ergebnisbereich:

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

    outcome:
        $suspicious_host = $hostname
        $admin_severity = if($u.principal.userid in %admin_users, "SEVERE", "MODERATE")
        $severity_tag = if($file_size > 1024, $admin_severity, "LOW")

    condition:
        $u
}

Umgestaltung einer Regel für mehrere Ereignisse in eine Regel für ein einzelnes Ereignis.

Sie können den Bereich outcome sowohl für Einzelereignisregeln (Regeln ohne match-Bereich) als auch für Mehrfachereignisregeln (Regeln mit match-Bereich) verwenden. Wenn Sie zuvor eine Regel für mehrere Ereignisse erstellt haben, nur um den Ergebnisbereich verwenden zu können, können Sie diese Regeln optional umgestalten, indem Sie den Abschnitt match löschen, um die Leistung zu verbessern. Da Ihre Regel keinen match-Abschnitt mehr enthält, in dem die Gruppierung angewendet wird, erhalten Sie möglicherweise mehr Erkennungen. Diese Umgestaltung ist nur für Regeln möglich, die eine Ereignisvariable verwenden, wie im folgenden Beispiel gezeigt.

Regel für mehrere Ereignisse, in der nur eine Ereignisvariable verwendet wird (gute Kandidatin für eine Umgestaltung):

rule OutcomeMultiEventPreRefactor {
    meta:
      author = "alice@example.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 umgestalten, indem Sie den Abschnitt match löschen. Sie müssen das Aggregat auch im Bereich outcome entfernen, da die Regel jetzt ein einzelnes Ereignis ist. Weitere Informationen zu Aggregationen finden Sie unter Ergebnisaggregationen.

rule OutcomeSingleEventPostRefactor {
    meta:
      author = "alice@example.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 Regel für die Funktion zum Platzhalter

Sie können dem Ergebnis eines Funktionsaufrufs eine Platzhaltervariable zuweisen und diese in anderen Abschnitten der Regel verwenden, z. B. im Abschnitt match, outcome oder condition. Sehen Sie sich folgendes Beispiel an:

rule FunctionToPlaceholderRule {
    meta:
      author = "alice@example.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 Abschnitt condition können Sie Ergebnisvariablen verwenden, die im Abschnitt outcome definiert wurden. Im folgenden Beispiel wird gezeigt, wie Sie mithilfe von Ergebnisbedingungen nach Risikobewertungen filtern, um das Rauschen bei Erkennungen zu reduzieren.

rule OutcomeConditionalRule {
    meta:
        author = "alice@example.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
}

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