Esta página se ha traducido con Cloud Translation API.

Descripción general del lenguaje YARA-L 2.0

Disponible en:

SecOps de Google SIEM

YARA-L 2.0 es un lenguaje informático que se utiliza para crear reglas con las que buscar en tus datos de registros empresariales mientras se ingieren en tu instancia de Google Security Operations. La sintaxis de YARA-L se deriva del lenguaje YARA desarrollado por VirusTotal. Este lenguaje funciona junto con el motor de detección de Google SecOps y te permite buscar amenazas y otros eventos en grandes volúmenes de datos.

Para obtener más información, consulta las siguientes secciones:

Reglas de ejemplo de YARA-L 2.0

En los siguientes ejemplos se muestran reglas escritas en YARA-L 2.0. En cada uno de ellos se muestra cómo correlacionar eventos en el lenguaje de reglas.

Reglas y ajustes

La siguiente regla busca patrones específicos en los datos de eventos y crea una detección si los encuentra. Esta regla incluye una variable $e1 para hacer un seguimiento del tipo de evento y del campo metadata.event_type de UDM. La regla comprueba si se dan casos específicos de coincidencias de expresiones regulares con e1. Cuando se produce el evento $e1, se crea una detección. Se incluye una condición not en la regla para excluir determinadas rutas no maliciosas. Puedes añadir hasta not condiciones para evitar falsos positivos.

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
}

Inicios de sesión desde diferentes ciudades

La siguiente regla busca usuarios que hayan iniciado sesión en tu empresa desde dos o más ciudades en menos de 5 minutos:

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 coincidencia: $user

Variable de evento:$udm

Variable de marcador de posición: $city y $user

A continuación, se describe cómo funciona esta regla:

Agrupa los eventos por nombre de usuario ($user) y los devuelve ($user) cuando se encuentra una coincidencia.
El intervalo es de 5 minutos, lo que significa que solo se correlacionan los eventos que tienen una diferencia de menos de 5 minutos.
Buscar un grupo de eventos ($udm) cuyo tipo de evento sea USER_LOGIN.
En ese grupo de eventos, la regla llama al ID de usuario $user y a la ciudad de inicio de sesión $city..
Devuelve una coincidencia si el número de valores city distintos (denotados por #city) es superior a 1 en el grupo de eventos ($udm) en el intervalo de 5 minutos.

Creación y eliminación rápidas de usuarios

La siguiente regla busca usuarios que se hayan creado y eliminado en un plazo de 4 horas:

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 de evento:$create y $delete

Variable de coincidencia: $user

Variable de marcador de posición: N/A

A continuación, se describe cómo funciona esta regla:

Agrupa los eventos por nombre de usuario ($user) y los devuelve ($user) cuando se encuentra una coincidencia.
La ventana temporal es de 4 horas, lo que significa que solo se correlacionan los eventos separados por menos de 4 horas.
Busca dos grupos de eventos ($create y $delete, donde $create es equivalente a #create >= 1).
$create corresponde a los eventos USER_CREATION y llama al ID de usuario como $user.
$user se usa para unir los dos grupos de eventos.
$delete corresponde a los eventos USER_DELETION y llama al ID de usuario como $user. Esta regla busca una coincidencia en la que el identificador de usuario de los dos grupos de eventos sea el mismo.
Esta regla busca casos en los que el evento de $delete se produce después del evento de $create y devuelve una coincidencia cuando la encuentra.

Regla de evento único

Las reglas de un solo evento son reglas que se correlacionan con un solo evento. Una regla de evento puede ser:

Cualquier regla sin una sección de coincidencia.
Regla con una sección match y una sección condition que solo comprueba la existencia de un evento (por ejemplo, "$e", "#e > 0", "#e >= 1", "1 <= #e", "0 < #e").

Por ejemplo, la siguiente regla busca un evento de inicio de sesión de usuario y devolvería el primero que encuentre en los datos de empresa almacenados en tu cuenta de Google SecOps:

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

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

  condition:
    $e
}

Aquí tienes otro ejemplo de una regla de evento único con una sección de coincidencias. Esta regla busca un usuario que haya iniciado sesión al menos una vez en menos de 5 minutos. Comprueba si existe un evento de inicio de sesión de usuario.

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
}

Regla de varios eventos

Usa varias reglas de eventos para agrupar muchos eventos en un periodo determinado e intenta encontrar correlaciones entre ellos. Una regla de varios eventos típica tendrá lo siguiente:

Una sección match que especifica el intervalo de tiempo en el que se deben agrupar los eventos.
Una sección condition que especifica qué condición debe activar la detección y comprueba la existencia de varios eventos.

Por ejemplo, la siguiente regla busca un usuario que haya iniciado sesión al menos 10 veces en menos de 10 minutos:

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
}

Evento único dentro del intervalo de direcciones IP

En el siguiente ejemplo se muestra una regla de evento que busca coincidencias entre dos nombres de host específicos y un intervalo de direcciones IP concreto:

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
}

Ejemplo de regla "cualquiera" y "todos"

La siguiente regla busca eventos de inicio de sesión en los que todas las direcciones IP de origen no coinciden con una dirección IP que se sabe que es segura en un periodo de 5 minutos.

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
}

Expresiones regulares en una regla

En el siguiente ejemplo de expresión regular de YARA-L 2.0 se buscan eventos con correos recibidos del dominio altostrat.com. Como nocase se ha añadido a la comparación de la variable $host regex y a la función regex, en ambas comparaciones no se distingue entre mayúsculas y minúsculas.

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
}

Ejemplos de reglas compuestas

Las detecciones compuestas mejoran la detección de amenazas mediante reglas compuestas. Estas reglas compuestas usan detecciones de otras reglas como entrada. Esto permite detectar amenazas complejas que las reglas individuales no podrían detectar. Para obtener más información, consulta la información general sobre las detecciones compuestas.

Detecciones de vallas virtuales

Las detecciones compuestas de alerta son la forma más sencilla de detección compuesta que opera en campos de los resultados de detección, como variables de resultado o metadatos de reglas. Ayudan a filtrar las detecciones de condiciones que pueden indicar un riesgo mayor, como un usuario administrador o un entorno de producción.

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
}

Detecciones de umbrales y agregaciones

Las reglas de detección compuestas de agregación te permiten agrupar las detecciones en función de atributos compartidos, como un nombre de host o un nombre de usuario, y analizar los datos agregados. A continuación se indican algunos de los casos prácticos habituales:

Identificar a los usuarios que generan un gran volumen de alertas de seguridad o de riesgo agregado.
Detecta hosts con patrones de actividad inusuales agregando detecciones relacionadas.

Ejemplo de agregación de riesgos:

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
}

Ejemplo de agregación de tácticas:

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
}

Detecciones compuestas secuenciales

Las detecciones compuestas secuenciales identifican patrones de eventos relacionados en los que la secuencia de detecciones es importante, como una detección de intento de inicio de sesión por fuerza bruta, seguida de un inicio de sesión correcto. Estos patrones pueden implicar varias detecciones básicas o una combinación de detecciones básicas y eventos.

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
}

Detecciones contextuales

Las detecciones compuestas contextuales enriquecen las detecciones con contexto adicional, como las direcciones IP encontradas en feeds de amenazas.

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
}

Detecciones de co-ocurrencia

Las detecciones compuestas de coocurrencia son una forma de agregación que puede detectar una combinación de eventos relacionados, como una combinación de detecciones de escalada de privilegios y de exfiltración de datos activadas por un usuario.

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
}

Ejemplo de regla de ventana deslizante

En el siguiente ejemplo de ventana deslizante de YARA-L 2.0 se busca la ausencia de eventos firewall_2 después de eventos firewall_1. La palabra clave after se usa con la variable de evento de pivote $e1 para especificar que solo se deben comprobar las ventanas de 10 minutos después de cada evento firewall_1 al correlacionar eventos.

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
}

Ejemplo de exclusión de valores cero

Rules Engine filtra implícitamente los valores cero de todos los marcadores de posición que se utilizan en la sección match. Para obtener más información, consulta la sección sobre cómo gestionar los valores ceromatch. Para inhabilitar esta opción, utilice allow_zero_values como se describe en allow_zero_values.

Sin embargo, en el caso de otros campos de eventos a los que se hace referencia, los valores cero no se excluyen a menos que especifique explícitamente esas condiciones.

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
}

Ejemplo de regla con sección `outcome`

Puedes añadir la sección opcional outcome en una regla de YARA-L 2.0 para extraer información adicional de cada detección. En la sección de condiciones, también puede especificar condicionales en las variables de resultado. Puede usar la sección outcome de una regla de detección para definir variables que se usarán más adelante. Por ejemplo, puede definir una puntuación de gravedad basada en los datos de los eventos que se analizan.

Para obtener más información, consulta las siguientes secciones:

Regla multievento con sección de resultados:

La siguiente regla analiza dos eventos para obtener el valor de $hostname. Si el valor de $hostname coincide durante un periodo de 5 minutos, se aplica una puntuación de gravedad. Cuando se incluye un periodo en la sección match, la regla comprueba si se da alguna de las condiciones que has especificado en ese periodo.

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

Regla de un solo evento con sección de resultados:

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
}

Refactorizar una regla de resultados de varios eventos en una regla de resultados de un solo evento.

Puedes usar la sección outcome tanto para reglas de un solo evento (reglas sin sección match) como para reglas de varios eventos (reglas con una sección match). Si antes diseñabas una regla para que fuera multievento solo para poder usar la sección de resultados, puedes refactorizar esas reglas eliminando la sección match para mejorar el rendimiento. Ten en cuenta que, como tu regla ya no tiene una sección match que aplique la agrupación, es posible que recibas más detecciones. Esta refactorización solo es posible en las reglas que usan una variable de evento, como se muestra en el siguiente ejemplo.

Regla de resultados de varios eventos que solo usa una variable de evento (un buen candidato para refactorizar):

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
}

Puedes refactorizar la regla eliminando la sección match. Ten en cuenta que también debes quitar el agregado en la sección outcome, ya que la regla ahora será de un solo evento. Para obtener más información sobre las agregaciones, consulta Agregaciones de resultados.

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
}

Ejemplo de regla de función a marcador de posición

Puedes asignar una variable de marcador de posición al resultado de una llamada de función y usarla en otras secciones de la regla, como la sección match, la sección outcome o la sección condition. Consulta el siguiente ejemplo:

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
}

Ejemplo de regla condicional de resultados

En la sección condition, puede usar variables de resultado que se hayan definido en la sección outcome. En el siguiente ejemplo se muestra cómo filtrar las puntuaciones de riesgo para reducir el ruido en las detecciones mediante condicionales de resultados.

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
}

¿Necesitas más ayuda? Recibe respuestas de los miembros de la comunidad y de los profesionales de Google SecOps.