Cette page a été traduite par l'API Cloud Translation.

Présentation du langage YARA-L 2.0

Compatible avec :

Google SecOps SIEM

YARA-L 2.0 est un langage informatique utilisé pour créer des règles de recherche dans les données de journaux d'entreprise, qui sont ingérées dans votre instance Google Security Operations. La syntaxe YARA-L est dérivée du langage YARA développé par VirusTotal. Ce langage fonctionne avec le moteur de détection Google SecOps et vous permet de rechercher des menaces et d'autres événements dans de grands volumes de données.

Pour en savoir plus, consultez les ressources suivantes :

Exemples de règles YARA-L 2.0

Les exemples suivants montrent des règles écrites en YARA-L 2.0. Chacun d'eux montre comment corréler des événements dans le langage de règles.

Règles et optimisation

La règle suivante recherche des schémas spécifiques dans les données d'événement et crée une détection si elle les trouve. Cette règle inclut une variable $e1 pour le suivi du type d'événement et un champ UDM metadata.event_type. La règle recherche des occurrences spécifiques de correspondances d'expressions régulières avec e1. Lorsqu'un événement $e1 se produit, une détection est créée. Une condition not est incluse dans la règle pour exclure certains chemins non malveillants. Vous pouvez ajouter des conditions not pour éviter les faux positifs.

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
}

Connexions depuis différentes villes

La règle suivante recherche les utilisateurs qui se sont connectés à votre entreprise depuis au moins deux villes différentes en moins de cinq minutes :

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
}

Variable de correspondance : $user

Variable d'événement :$udm

Variable d'espace réservé : $city et $user

Voici comment fonctionne cette règle :

Regroupe les événements avec le nom d'utilisateur ($user) et le renvoie ($user) lorsqu'une correspondance est trouvée.
La période est de cinq minutes, ce qui signifie que seuls les événements qui se produisent à moins de cinq minutes d'intervalle sont corrélés.
Recherche d'un groupe d'événements ($udm) dont le type d'événement est USER_LOGIN.
Pour ce groupe d'événements, la règle appelle l'ID utilisateur sous la forme $user et la ville de connexion sous la forme $city..
Renvoie une correspondance si le nombre distinct de valeurs city (indiqué par #city) est supérieur à 1 dans le groupe d'événements ($udm) au cours de la période de cinq minutes.

Création et suppression rapides d'utilisateurs

La règle suivante recherche les utilisateurs qui ont été créés, puis supprimés dans un délai de quatre heures :

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
}

Variables d'événement : $create et $delete

Variable de correspondance : $user

Variable d'espace réservé : N/A

Voici comment fonctionne cette règle :

Regroupe les événements avec le nom d'utilisateur ($user) et le renvoie ($user) lorsqu'une correspondance est trouvée.
La période est de quatre heures, ce qui signifie que seuls les événements séparés par moins de quatre heures sont corrélés.
Recherche deux groupes d'événements ($create et $delete, où $create équivaut à #create >= 1).
$create correspond aux événements USER_CREATION et appelle l'ID utilisateur sous la forme $user.
$user est utilisé pour joindre les deux groupes d'événements.
$delete correspond aux événements USER_DELETION et appelle l'ID utilisateur sous la forme $user. Cette règle recherche une correspondance lorsque l'identifiant utilisateur est identique dans les deux groupes d'événements.
Cette règle recherche les cas où l'événement de $delete se produit après l'événement de $create et renvoie une correspondance lorsqu'elle est trouvée.

Règle d'événement unique

Les règles d'événement unique sont des règles qui établissent une corrélation sur un seul événement. Une seule règle d'événement peut être :

Toute règle sans section de correspondance.
Règle avec une section match et une section condition qui ne vérifie que l'existence d'un événement (par exemple, "$e", "#e > 0", "#e >= 1", "1 <= #e", "0 < #e").

Par exemple, la règle suivante recherche un événement de connexion utilisateur et renvoie le premier qu'elle rencontre dans les données de l'entreprise stockées dans votre compte Google SecOps :

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

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

  condition:
    $e
}

Voici un autre exemple de règle d'événement unique avec une section de correspondance. Cette règle recherche un utilisateur qui s'est connecté au moins une fois en moins de cinq minutes. Elle vérifie simplement l'existence d'un événement de connexion utilisateur.

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
}

Règle d'événement multiple

Utilisez plusieurs règles d'événement pour regrouper de nombreux événements sur une période spécifiée et essayer de trouver des corrélations entre les événements. Une règle d'événements multiples type se compose des éléments suivants :

Section match qui spécifie la période pendant laquelle les événements doivent être regroupés.
Une section condition spécifiant la condition qui doit déclencher la détection et vérifiant l'existence de plusieurs événements.

Par exemple, la règle suivante recherche un utilisateur qui s'est connecté au moins 10 fois en moins de 10 minutes :

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
}

Événement unique dans la plage d'adresses IP

L'exemple suivant montre une règle d'événement unique qui recherche des correspondances entre deux noms d'hôte spécifiques et une plage d'adresses IP spécifique :

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
}

Exemple de règle "any and all"

La règle suivante recherche les événements de connexion où toutes les adresses IP sources ne correspondent pas à une adresse IP connue comme sécurisée dans un intervalle de temps de cinq minutes.

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
}

Expressions régulières dans une règle

L'exemple d'expression régulière YARA-L 2.0 suivant recherche les événements avec des e-mails reçus du domaine altostrat.com. Étant donné que nocase a été ajouté à la comparaison de la variable $host regex et à la fonction regex, ces deux comparaisons ne sont pas sensibles à la casse.

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
}

Exemples de règles composites

Les détections composites améliorent la détection des menaces à l'aide de règles composites. Ces règles composites utilisent les détections d'autres règles comme entrée. Cela permet de détecter les menaces complexes que les règles individuelles ne peuvent pas détecter. Pour en savoir plus, consultez Présentation des détections composites.

Détections de câbles tendus

Les détections composites Tripwire sont la forme la plus simple de détection composite. Elles fonctionnent sur les champs des résultats de détection, tels que les variables de résultat ou les métadonnées de règles. Ils permettent de filtrer les détections selon des conditions pouvant indiquer un risque plus élevé, comme un utilisateur administrateur ou un environnement de production.

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
}

Détections de seuil et d'agrégation

Les règles de détection composites d'agrégation vous permettent de regrouper les résultats de détection en fonction d'attributs partagés, tels qu'un nom d'hôte ou un nom d'utilisateur, et d'analyser les données agrégées. Voici quelques cas d'utilisation courants :

Identifier les utilisateurs qui génèrent un volume élevé d'alertes de sécurité ou de risques agrégés.
Détection des hôtes présentant des schémas d'activité inhabituels en agrégeant les détections associées.

Exemple d'agrégation des risques :

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
}

Exemple d'agrégation de tactiques :

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
}

Détections composites séquentielles

Les détections composites séquentielles identifient des schémas d'événements associés où la séquence de détections est importante, comme une détection de tentative de connexion par force brute, suivie d'une connexion réussie. Ces modèles peuvent impliquer plusieurs détections de base ou une combinaison de détections de base et d'événements.

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
}

Détections contextuelles

Les détections composites contextuelles enrichissent les détections avec un contexte supplémentaire, comme les adresses IP trouvées dans les flux de menaces.

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
}

Détections de co-occurrence

Les détections composites de cooccurrence sont une forme d'agrégation qui peut détecter une combinaison d'événements associés, comme une combinaison de détections d'escalade de privilèges et d'exfiltration de données déclenchées par un utilisateur.

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
}

Exemple de règle de fenêtre glissante

L'exemple de fenêtre glissante YARA-L 2.0 suivant recherche l'absence d'événements firewall_2 après des événements firewall_1. Le mot clé after est utilisé avec la variable d'événement pivot $e1 pour spécifier que seules les périodes de 10 minutes après chaque événement firewall_1 doivent être vérifiées lors de la corrélation des événements.

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
}

Exemple d'exclusion de valeurs nulles

Le moteur de règles filtre implicitement les valeurs nulles pour tous les espaces réservés utilisés dans la section match. Pour en savoir plus, consultez la section Gestion des valeurs nulles dans match. Vous pouvez désactiver cette option à l'aide de l'option allow_zero_values, comme décrit dans allow_zero_values.

Toutefois, pour les autres champs d'événement référencés, les valeurs nulles ne sont pas exclues, sauf si vous spécifiez explicitement de telles conditions.

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
}

Exemple de règle avec une section `outcome`

Vous pouvez ajouter la section facultative outcome dans une règle YARA-L 2.0 pour extraire des informations supplémentaires sur chaque détection. Dans la section "Condition", vous pouvez également spécifier des conditions sur les variables de résultat. Vous pouvez utiliser la section outcome d'une règle de détection pour définir des variables à utiliser en aval. Par exemple, vous pouvez définir un score de gravité en fonction des données des événements analysés.

Pour en savoir plus, consultez les ressources suivantes :

Règle multi-événements avec une section "Résultat" :

La règle suivante examine deux événements pour obtenir la valeur de $hostname. Si la valeur de $hostname correspond sur une période de cinq minutes, un score de gravité est appliqué. Lorsque vous incluez une période dans la section match, la règle vérifie la période spécifiée.

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")
}

Règle à événement unique avec section "Résultat" :

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
}

Refactorisation d'une règle de résultat multi-événements en règle de résultat à événement unique.

Vous pouvez utiliser la section outcome pour les règles à événement unique (règles sans section match) et les règles à événements multiples (règles avec une section match). Si vous avez déjà conçu une règle multi-événements uniquement pour pouvoir utiliser la section "Résultat", vous pouvez éventuellement refactoriser ces règles en supprimant la section match pour améliorer les performances. Notez que, comme votre règle ne comporte plus de section match qui applique le regroupement, vous risquez de recevoir plus de détections. Cette refactorisation n'est possible que pour les règles qui utilisent une variable d'événement, comme illustré dans l'exemple suivant.

Règle de résultat multi-événements qui n'utilise qu'une seule variable d'événement (un bon candidat pour une refactorisation) :

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
}

Vous pouvez refactoriser la règle en supprimant la section match. Notez que vous devez également supprimer l'agrégat dans la section outcome, car la règle sera désormais un événement unique. Pour en savoir plus sur les agrégations, consultez Agrégations de résultats.

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
}

Exemple de règle de fonction vers espace réservé

Vous pouvez attribuer une variable d'espace réservé au résultat d'un appel de fonction et l'utiliser dans d'autres sections de la règle, telles que les sections match, outcome ou condition. Consultez l'exemple ci-dessous :

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
}

Exemple de règle de conditions de résultat

Dans la section condition, vous pouvez utiliser les variables de résultat définies dans la section outcome. L'exemple suivant montre comment filtrer les scores de risque pour réduire le bruit dans les détections à l'aide de conditions de résultat.

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
}

Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.