Sintaxis del lenguaje YARA-L 2.0

En esta sección, se describen los elementos principales de la sintaxis YARA-L. Consulta también la Descripción general del lenguaje YARA-L 2.0.

Estructura de la regla

Para YARA-L 2.0, debes especificar las declaraciones, definiciones y usos de variables en el siguiente orden:

1. Meta
2. eventos
3. coincidencia (opcional)
4. resultado (opcional)
5. condición
6. opciones (opcional)

Nota: Si omites la sección opcional match, la regla puede establecer una coincidencia con un solo evento.

A continuación, se muestra la estructura genérica de una regla:

rule <rule Name>
{
    meta:
    // Stores arbitrary key-value pairs of rule details, such as who wrote
    // it, what it detects on, version control, etc.

  events:
    // Conditions to filter events and the relationship between events.

  match:
    // Values to return when matches are found.

  outcome:
    // Additional information extracted from each detection.

  condition:
    // Condition to check events and the variables used to find matches.

  options:
    // Options to turn on or off while executing this rule.
}

Sintaxis de la sección de metadatos

La sección Meta está compuesta por varias líneas y cada línea define un par clave-valor. Una parte de clave debe ser una string sin comillas y una parte de valor debe ser una string entrecomillada:

<key> = "<value>"

El siguiente es un ejemplo de una línea de sección meta válida: none meta: author = "Chronicle" severity = "HIGH"

Sintaxis de la sección de eventos

En la sección events, enumera los predicados para especificar lo siguiente:

• Declaraciones de variables
• Filtros de variables de eventos
• Uniones de variables de eventos

Declaraciones de variables

Para las declaraciones de variables, usa la siguiente sintaxis:

• <EVENT_FIELD> = <VAR>
• <VAR> = <EVENT_FIELD>

Ambos son equivalentes, como se muestra en los siguientes ejemplos:

• $e.source.hostname = $hostname
• $userid = $e.principal.user.userid

Esta declaración indica que esta variable representa el campo especificado para la variable del evento. Cuando el campo de evento es un campo repetido, la variable de coincidencia puede representar cualquier valor en el array. También es posible asignar varios campos de eventos a una sola variable de coincidencia o de marcador de posición. Esta es una condición de unión transitiva.

Por ejemplo:

• $e1.source.ip = $ip
• $e2.target.ip = $ip

Son equivalentes a:

• $e1.source.ip = $ip
• $e1.source.ip = $e2.target.ip

Cuando se usa una variable, esta debe declararse mediante la declaración de variables. Si se usa una variable sin ninguna declaración, se considera un error de compilación.

Filtros de variables de eventos

Una expresión booleana que actúa sobre una única variable de evento se considera un filtro.

Uniones de variables de eventos

Todas las variables de evento que se usan en la regla se deben unir con las demás variables de evento de una de las siguientes maneras:

• Directamente a través de una comparación de igualdad entre campos de evento de las dos variables de evento unidas, por ejemplo: $e1.field = $e2.field La expresión no debe incluir aritmética.

• Indirectamente, a través de una unión transitiva que involucre solo un campo de evento (consulta la declaración de variables para ver la definición de "unión transitiva"). La expresión no debe incluir aritmética.

Por ejemplo, si suponemos que en la regla se usan $e1, $e2 y $e3, las siguientes secciones events son válidas.

events:
  $e1.principal.hostname = $e2.src.hostname // $e1 joins with $e2
  $e2.principal.ip = $e3.src.ip // $e2 joins with $e3

events:
  // $e1 joins with $e2 via function to event comparison
  re.capture($e1.src.hostname, ".*") = $e2.target.hostname

events:
  // $e1 joins with $e2 via an `or` expression
  $e1.principal.hostname = $e2.src.hostname
  or $e1.principal.hostname = $e2.target.hostname
  or $e1.principal.hostname = $e2.principal.hostname

events:
  // all of $e1, $e2 and $e3 are transitively joined via the placeholder variable $ip
  $e1.src.ip = $ip
  $e2.target.ip = $ip
  $e3.about.ip = $ip

events:
  // $e1 and $e2 are transitively joined via function to event comparison
  re.capture($e2.principal.application, ".*") = $app
  $e1.principal.hostname = $app

Nota: Si tu condición de unión única es una cadena or, una comparación de funciones con eventos o una combinación de ambas, es posible que la regla tenga un rendimiento deficiente.

Sin embargo, aquí hay ejemplos de secciones events no válidas.

events:
  // Event to arithmetic comparison is an invalid join condition for $e1 and $e2.
  $e1.principal.port = $e2.src.port + 1

events:
  $e1.src.ip = $ip
  $e2.target.ip = $ip
  $e3.about.ip = "192.1.2.0" //$e3 is not joined with $e1 or $e2.

events:
  $e1.src.port = $port

  // Arithmetic to placeholder comparison is an invalid transitive join condition.
  $e2.principal.port + 800 = $port

Sintaxis de la sección de coincidencias

En la sección match, enumera las variables de coincidencia para los eventos de grupo antes de verificar las condiciones de coincidencia. Esos campos se muestran con cada coincidencia.

• Especifica qué representa cada variable de coincidencia en la sección events.
• Especifica el tiempo que se usará para correlacionar eventos después de la palabra clave over. Se ignoran los eventos que se encuentren fuera de la duración establecida.

• Usa la siguiente sintaxis para especificar la duración: <number><m/h/d>

  En el ejemplo anterior, m/h/d significa minutos, horas y días, respectivamente.

• El tiempo mínimo que puedes especificar es 1 minuto.

• El tiempo máximo que puedes especificar es 48 horas.

El siguiente es un ejemplo de un match válido:

$var1, $var2 over 5m

Esta sentencia muestra $var1 y $var2 (definidos en la sección events) cuando la regla encuentra una coincidencia. El tiempo especificado es de 5 minutos. Los eventos con más de 5 minutos de diferencia no se correlacionan y, por lo tanto, la regla los ignora.

Aquí hay otro ejemplo de una sección match válida:

$user over 1h

Esta sentencia muestra $user cuando la regla encuentra una coincidencia. El período especificado es de 1 hora. Los eventos que tienen más de una hora de diferencia no se correlacionan. La regla no los considera una detección.

Aquí hay otro ejemplo de una sección match válida:

$source_ip, $target_ip, $hostname over 2m

Esta sentencia muestra $source_ip, $target_ip y $hostname cuando la regla encuentra una coincidencia. El período especificado es de 2 minutos. Los eventos que tienen más de 2 minutos de diferencia no se correlacionan. La regla no los considera una detección.

En los siguientes ejemplos, se muestran secciones match no válidas:

• var1, var2 over 5m // invalid variable name
• $user 1h // missing keyword

Manejo de valores cero en la sección de coincidencias

El motor de reglas filtra de forma implícita los valores cero para todos los marcadores de posición que se usan en la sección de coincidencia ("" para cadenas, 0 para números, false para valores booleanos y el valor en la posición 0 para tipos enumerados). En el siguiente ejemplo, se ilustran reglas que filtran los valores cero.

rule ZeroValuePlaceholderExample {
  meta:
  events:
    // Because $host is used in the match section, the rule behaves
    // as if the following predicate was added to the events section:
    // $host != ""
    $host = $e.principal.hostname

    // Because $otherPlaceholder was not used in the match section,
    // there is no implicit filtering of zero values for $otherPlaceholder.
    $otherPlaceholder = $e.principal.ip

  match:
    $host over 5m

  condition:
    $e
}

Sin embargo, si se asigna un marcador de posición a una función, las reglas no filtran de forma implícita los valores cero de los marcadores de posición que se usan en la sección de coincidencias. En el siguiente ejemplo, se ilustran reglas que filtran los valores cero:

rule ZeroValueFunctionPlaceholder {
  meta:
  events:
    // Even though $ph is used in the match section, there is no
    // implicit filtering of zero values for $ph, because $ph is assigned to a function.
    $ph = re.capture($e.principal.hostname, "some-regex")

  match:
    $ph over 5m

  condition:
    $e
}

Para inhabilitar el filtrado implícito de valores de cero, puedes usar la opción allow_zero_values en la sección de opciones.

Ventana de salto

De forma predeterminada, las reglas YARA-L 2.0 con una sección de coincidencia se evalúan mediante ventanas de salto. El intervalo de tiempo de ejecución de la regla se divide en un conjunto de ventanas de salto superpuestas, cada una con la duración especificada en la sección match. Los eventos se correlacionan dentro de cada ventana de salto.

Por ejemplo, para una regla que se ejecuta en el intervalo de tiempo [1:00, 2:00], con una sección match sobre 30m, un conjunto posible de ventanas de salto superpuestas que se podrían generar es [1:00, 1:30], [1:03, 1:33] y [1:06, 1:36]. Estas ventanas se utilizan para correlacionar múltiples eventos.

Ventana deslizante

El uso de ventanas de salto no es una forma eficaz de buscar eventos que suceden en un orden específico (por ejemplo, e1 ocurre hasta 2 minutos después de e2). Una instancia del evento e1 y una ocurrencia del evento e2 se correlacionan solo si caen en la misma ventana de salto generada.

Una forma más eficaz de buscar estas secuencias de eventos es usar ventanas deslizantes. Las ventanas variables con la duración especificada en la sección match se generan cuando comienzan o terminan con una variable de evento dinámica especificada. Luego, los eventos se correlacionan dentro de cada ventana deslizante. Esto permite buscar eventos que suceden en un orden específico (por ejemplo, e1 ocurre en un plazo de 2 minutos a partir de e2). Un caso del evento e1 y un caso del evento e2 se correlacionan si el evento e1 ocurre dentro de la duración de la ventana deslizante después del evento e2.

Especifica las ventanas variables en la sección match de una regla de la siguiente manera:

<match-var-1>, <match-var-2>, ... over <duration> before|after <pivot-event-var>

La variable de evento dinámica es la variable de evento en la que se basan las ventanas deslizantes. Si usas la palabra clave before, se generan ventanas deslizantes que terminan con cada caso del evento de tabla dinámica. Si se usa la palabra clave after, se generan ventanas deslizantes a partir de cada caso del evento de tabla dinámica.

Los siguientes son ejemplos de usos válidos de ventanas deslizantes:

• $var1, $var2 over 5m after $e1
• $user over 1h before $e2

Consulta un ejemplo de regla de ventana deslizante.

Nota: Se sabe que el uso de ventanas deslizantes en lugar de ventanas de salto da como resultado un rendimiento más lento. Google recomienda usar ventanas variables solo para casos específicos, como cuando el orden de los eventos es absolutamente necesario o cuando se busca la inexistencia de eventos.

Google recomienda no usar ventanas variables para las reglas de un solo evento, ya que estas están diseñadas para detectar varios eventos. Si una de tus reglas se encuentra en esta categoría, Google recomienda una de las siguientes soluciones alternativas:

• Convierte la regla para usar varias variables de evento y actualiza la sección de la condición si la regla requiere que el evento se repita en más de una instancia.
  • De manera opcional, considera agregar filtros de marca de tiempo en lugar de usar una ventana deslizante. Por ejemplo, $permission_change.metadata.event_timestamp.seconds < $file_creation.metadata.event_timestamp.seconds
• Quita la ventana deslizante.

Sintaxis de la sección de resultados

En la sección outcome, puedes definir hasta 20 variables de resultado con nombres arbitrarios. Estos resultados se almacenarán en las detecciones que genera la regla. Cada detección puede tener valores diferentes para los resultados.

El nombre del resultado, $risk_score, es especial. De manera opcional, puedes definir un resultado con este nombre y, si lo haces, debe ser un tipo de número entero o de número de punto flotante. Si se propaga, risk_score se mostrará en la vista de Enterprise Insights para las alertas que provienen de detecciones de reglas.

Si no incluyes una variable $risk_score en la sección de resultados de una regla, se establecerá uno de los siguientes valores predeterminados:

• Si la regla está configurada para generar una alerta, $risk_score se establece en 40.
• Si la regla no está configurada para generar una alerta, $risk_score se establece en 15.

El valor de $risk_score se almacena en el campo security_result.risk_score de UDM.

Tipos de datos variables de resultado

Cada variable de resultado puede tener un tipo de datos diferente, determinado por la expresión que se usa para calcularlo. Se admiten los siguientes tipos de datos de resultados:

• integer
• flotadores
• string
• listas de números enteros
• listas de números de punto flotante
• listas de cadenas

Lógica condicional

Puedes usar la lógica condicional para calcular el valor de un resultado. Los condicionales se especifican con el siguiente patrón de sintaxis:

if(BOOL_CLAUSE, THEN_CLAUSE)
if(BOOL_CLAUSE, THEN_CLAUSE, ELSE_CLAUSE)

Puedes leer una expresión condicional de la siguiente manera: “si BOOL_CLAUSE es verdadero, luego muestra THEN_CLAUSE; de lo contrario, muestra ELSE_CLAUSE”.

BOOL_CLAUSE debe evaluarse como un valor booleano. Una expresión BOOL_CLAUSE toma una forma similar a las expresiones de la sección events. Por ejemplo, puede incluir lo siguiente:

• Nombres de campo de UDM con operador de comparación, por ejemplo:

  if($context.graph.entity.user.title = "Vendor", 100, 0)

• variable de marcador de posición que se definió en la sección events, por ejemplo:

  if($severity = "HIGH", 100, 0)

• otra variable de resultado definida en la sección outcome, por ejemplo:

  if($risk_score > 20, "HIGH", "LOW")

• funciones que devuelven un valor booleano, por ejemplo:

  if(re.regex($e.network.email.from, `.*altostrat.com`), 100, 0)

• Busca en una lista de referencia, por ejemplo:

  if($u.principal.hostname in %my_reference_list_name, 100, 0)

• comparación de agregación, por ejemplo:

  if(count($login.metadata.event_timestamp.seconds) > 5, 100, 0)

THEN_CLAUSE y ELSE_CLAUSE deben ser del mismo tipo de datos. Se admiten números enteros, números de punto flotante y cadenas.

Puedes omitir ELSE_CLAUSE si el tipo de datos es un número entero o un número de punto flotante. Si se omite, ELSE_CLAUSE se evalúa como 0. Por ejemplo:

`if($e.field = "a", 5)` is equivalent to `if($e.field = "a", 5, 0)`

Debes proporcionar ELSE_CLAUSE si el tipo de datos es una cadena o si THEN_CLAUSE es una variable de marcador de posición o una variable de resultado.

Operaciones matemáticas

Puedes usar operaciones matemáticas para calcular el tipo de datos enteros o flotantes en las secciones outcome y events de una regla. Chronicle admite la suma, la resta, la multiplicación, la división y los módulos como operadores de nivel superior en un cálculo.

El siguiente fragmento es un ejemplo de cálculo en la sección outcome:

outcome:
  $risk_score = max(100 + if($severity = "HIGH", 10, 5) - if($severity = "LOW", 20, 0))

Las operaciones matemáticas se permiten en los siguientes tipos de operandos, siempre y cuando cada operando y la expresión aritmética completa se agreguen de forma correcta (consulta Agregaciones):

• Campos de eventos numéricos
• Variables del marcador de posición numérico definidas en la sección events
• Variables de resultado numéricas definidas en la sección outcome.
• Funciones que muestran números enteros o de punto flotante
• Agregaciones que devuelven ints o números de punto flotante

No se permite el módulo en los números de punto flotante.

Variables de marcadores de posición en los resultados

Cuando calculas las variables de resultado, puedes usar variables de marcador de posición que se definieron en la sección de eventos de tu regla. En este ejemplo, supongamos que $email_sent_bytes se definió en la sección de eventos de la regla:

Ejemplo de un solo evento:

// No match section, so this is a single-event rule.

outcome:
  // Use placeholder directly as an outcome value.
  $my_outcome = $email_sent_bytes

  // Use placeholder in a conditional.
  $other_outcome = if($file_size > 1024, "SEVERE", "MODERATE")

condition:
  $e

Ejemplo de varios eventos:

match:
  // This is a multi event rule with a match section.
  $hostname over 5m

outcome:
  // Use placeholder directly in an aggregation function.
  $max_email_size = max($email_sent_bytes)

  // Use placeholder in a mathematical computation.
  $total_bytes_exfiltrated = sum(
    1024
    + $email_sent_bytes
    + $file_event.principal.file.size
  )

condition:
  $email_event and $file_event

Variables de resultado en expresiones de asignación de resultados

Las variables de resultado se pueden usar para derivar otras variables de resultado, similares a las variables de marcador de posición definidas en la sección events. Puedes hacer referencia a una variable de resultado en la asignación de otra variable de resultado con un token $ seguido del nombre de la variable. Las variables de resultado deben definirse antes de que se pueda hacer referencia a ellas en el texto de la regla. Cuando se usan en una expresión de asignación, las variables de resultado no se deben agregar (consulta Agregaciones).

En el siguiente ejemplo, la variable de resultado $risk_score deriva su valor de la variable de resultado $event_count:

Ejemplo de varios eventos:

match:
  // This is a multi event rule with a match section.
  $hostname over 5m

outcome:
  // Aggregates all timestamp on login events in the 5 minute match window.
  $event_count = count($login.metadata.event_timestamp.seconds)

  // $event_count cannot be aggregated again.
  $risk_score = if($event_count > 5, "SEVERE", "MODERATE")

  // This is the equivalent of the 2 outcomes above combined.
  $risk_score2 = if(count($login.metadata.event_timestamp.seconds) > 5, "SEVERE", "MODERATE")

condition:
  $e

Las variables de resultado se pueden usar en cualquier tipo de expresión en el lado derecho de una asignación de resultado, excepto en las siguientes expresiones:

• Datos recopilados
• Llamadas a la función Arrays.length()
• Con los modificadores any o all

Datos recopilados

Los campos de eventos repetidos son valores no escalares. Es decir, una sola variable apunta a varios valores. Por ejemplo, la variable de campo de evento $e.target.ip es un campo repetido y puede tener cero, uno o muchos valores de IP. Es un valor no escalar. En cambio, la variable del campo de evento $e.principal.hostname no es un campo repetido y solo tiene 1 valor (es decir, un valor escalar).

De manera similar, los campos de eventos no repetidos y los campos de eventos repetidos usados en la sección de resultados de una regla con un período de coincidencia son valores no escalares. Por ejemplo, la siguiente regla agrupa eventos con una sección de coincidencias y hace referencia a un campo de eventos no repetidos en la sección de resultados:

rule OutcomeAndMatchWindow{
  ...
  match:
    $userid over 5m
  outcome:
    $hostnames = array($e.principal.hostname)
  ...
}

Cualquier período de 5 minutos en el que se ejecute la regla puede contener cero, uno o muchos eventos. La sección de resultados opera en todos los eventos en una ventana de coincidencia. Cualquier variable de campo de evento a la que se haga referencia en la sección de resultados puede apuntar a cero, uno o muchos valores del campo en cada evento de la ventana de coincidencia. En la regla anterior, si un período de 5 minutos contiene 5 eventos $e, $e.principal.hostname en la sección de resultados apunta a 5 nombres de host diferentes. Por lo tanto, la variable de campo de evento $e.principal.hostname es un valor no escalar en la sección de resultados de esta regla.

Debido a que las variables de resultado siempre deben producir un único valor escalar, cualquier valor no escalar del que dependa una asignación de resultado debe agregarse para obtener un solo valor escalar. En una sección de resultados, los siguientes son valores no escalares y deben agregarse:

• Campos de eventos (repetidos o no repetidos) cuando la regla utiliza una sección de coincidencia
• Marcadores de posición de eventos (repetidos o no repetidos) cuando la regla usa una sección de coincidencia
• Campos de eventos repetidos cuando la regla no usa una sección de coincidencia
• Marcadores de posición de eventos repetidos cuando la regla no usa una sección de coincidencia

Los campos de eventos escalares, los marcadores de posición de eventos escalares y las constantes pueden unirse a una agregación en una regla que no use una sección de coincidencia. Sin embargo, la mayoría de las agregaciones producirán el valor unido y, por lo tanto, son innecesarias. La excepción es la agregación array(), que se puede usar para convertir un valor escalar en un array.

Las variables de resultado se tratan como agregaciones: no se deben volver a agregar cuando se les haga referencia en otra asignación de resultados.

Puedes usar las siguientes funciones de agregación:

• max(): Muestra el máximo de todos los valores posibles. Solo funciona con números enteros y números de punto flotante.
• min(): Muestra el mínimo sobre todos los valores posibles. Solo funciona con números enteros y números de punto flotante.
• sum(): Muestra la suma de todos los valores posibles. Solo funciona con números enteros y números de punto flotante.
• count_distinct(): Recopila todos los valores posibles y, luego, genera el recuento distinto de los valores posibles.
• count(): Se comporta como count_distinct(), pero muestra un recuento no distinto de los valores posibles.
• array_distinct(): Recopila todos los valores distintos posibles y, luego, genera una lista de estos. truncará la lista de valores distintos a 25 elementos aleatorios. Primero se aplica la anulación de duplicación para obtener una lista distinta y, luego, el truncamiento.
• array(): Se comporta como array_distinct(), pero muestra una lista de valores no distinta. También trunca la lista de valores a 25 elementos aleatorios.

La función de agregación es importante cuando una regla incluye una sección condition que especifica que deben existir varios eventos, ya que la función de agregación operará en todos los eventos que generaron la detección.

Por ejemplo, si las secciones outcome y condition contienen lo siguiente:

outcome:
  $asset_id_count = count($event.principal.asset_id)
  $asset_id_distinct_count = count_distinct($event.principal.asset_id)

  $asset_id_list = array($event.principal.asset_id)
  $asset_id_distinct_list = array_distinct($event.principal.asset_id)

condition:
  #event > 1

Dado que la sección de condición requiere que haya más de un event para cada detección, las funciones de agregación operarán en varios eventos. Supongamos que los siguientes eventos generaron una detección:

event:
  // UDM event 1
  asset_id="asset-a"

event:
  // UDM event 2
  asset_id="asset-b"

event:
  // UDM event 3
  asset_id="asset-b"

Entonces, los valores de tus resultados serán los siguientes:

• $asset_id_count = 3
• $asset_id_distinct_count = 2
• $asset_id_list = ["asset-a", "asset-b", "asset-b"]
• $asset_id_distinct_list = ["asset-a", "asset-b"]

Recuerda lo siguiente cuando uses la sección de resultados:

Otras notas y restricciones:

• La sección outcome no puede hacer referencia a una nueva variable de marcador de posición que no se definió en la sección events ni en la sección outcome.
• La sección outcome no puede usar variables de evento que no se hayan definido en la sección events.
• La sección outcome puede usar un campo de evento que no se usó en la sección events, dado que la variable de evento a la que pertenece el campo de evento ya se definió en la sección events.
• La sección outcome solo puede correlacionar variables de evento que ya se correlacionaron en la sección events. Las correlaciones ocurren cuando se equivalen dos campos de eventos de diferentes variables de evento.

Puedes encontrar un ejemplo en el uso de la sección de resultados en Descripción general de YARA-L 2.0. Consulta Crea estadísticas contextuales para obtener detalles sobre la anulación de duplicación de detección con la sección de resultados.

Sintaxis de la sección de condición

• Especifica una condición de coincidencia sobre los eventos y los marcadores de posición definidos en la sección events. Consulta la siguiente sección, Condicionales de eventos y marcadores de posición, para obtener más detalles.
• (Opcional) Usa la palabra clave and para especificar una condición de coincidencia mediante las variables de resultado definidas en la sección outcome. Consulta la siguiente sección, Condicionales de resultados, para obtener más detalles.

Contar carácter

El carácter # es un carácter especial de la sección condition. Si se usa antes de cualquier nombre de evento o variable de marcador de posición, representa la cantidad de eventos o valores distintos que cumplen con todas las condiciones de la sección events.

Por ejemplo, #c > 1 significa que la variable c debe ocurrir más de 1 vez.

Carácter de valor

El carácter $ es un carácter especial de la sección condition. Si se usa antes de cualquier nombre de variable de resultado, representa el valor de ese resultado.

Si se usa antes de cualquier nombre de evento o variable de marcador de posición (por ejemplo, $event), representa #event > 0.

Condicionales de eventos y marcadores de posición

Enumera los predicados de la condición para los eventos y las variables de marcador de posición aquí, unidos con la palabra clave and o or. La palabra clave and se puede usar entre cualquier condición, pero la palabra clave or solo se puede usar cuando la regla tiene una sola variable de evento.

Este es un ejemplo válido del uso de or entre dos marcadores de posición en el mismo evento:

rule ValidConditionOr {
  meta:
  events:
      $e.metadata.event_type = "NETWORK_CONNECTION"

      // Note that all placeholders use the same event variable.
      $ph = $e.principal.user.userid  // Define a placeholder variable to put in match section.
      $ph2 = $e.principal.ip  // Define a second placeholder variable to put in condition section.
      $ph3 = $e.principal.hostname  // Define a third placeholder variable to put in condition section.

  match:
    $ph over 5m

  condition:
    $ph2 or $ph3
}

Este es un ejemplo no válido del uso de or entre dos condiciones en eventos diferentes:

rule InvalidConditionOr {
  meta:
  events:
      $e.metadata.event_type = "NETWORK_CONNECTION"
      $e2.graph.metadata.entity_type = "FILE"
      $e2.graph.entity.hostname  = $e.principal.hostname

      $ph = $e.principal.user.userid  // Define a placeholder variable to put in match section.

  match:
    $ph over 5m

  condition:
    $e or $e2 // This line will cause an error because there is an or between events.
}

Nota: No uses la palabra clave not en condicionales de eventos y marcadores de posición.

Condiciones delimitadas y no delimitadas

Las siguientes condiciones son condiciones delimitadas. Fuerzan la existencia de la variable de evento asociada, lo que significa que al menos un caso del evento debe aparecer en cualquier detección.

• $var // equivalent to #var > 0
• #var > n // where n >= 0
• #var >= m // where m > 0

Las siguientes condiciones son condiciones no delimitadas. Permiten que la variable de evento asociada no exista, lo que significa que es posible que no aparezca ningún caso del evento en una detección y que cualquier referencia a los campos de la variable del evento produzca un valor de cero. Se pueden usar condiciones no delimitadas para detectar la ausencia de un evento durante un período. Por ejemplo, un evento de amenaza sin un evento de mitigación en un período de 10 minutos. Las reglas que usan condiciones no delimitadas se denominan reglas de inexistencia.

• !$var // equivalent to #var = 0
• #var >= 0
• #var < n // where n > 0
• #var <= m // where m >= 0

Nota: Para las reglas de inexistencia, el motor de detección agrega un retraso de 1 hora a la latencia esperada (según la frecuencia de ejecución de la regla) para permitir los datos tardíos.

Requisitos por inexistencia

Para que se pueda compilar una regla inexistente, esta debe cumplir con los siguientes requisitos:

1. Al menos un evento de UDM debe tener una condición delimitada (es decir, debe existir al menos un evento de UDM).
2. Si un marcador de posición tiene una condición no delimitada, debe estar asociado con, al menos, un evento de UDM delimitado.
3. Si una entidad tiene una condición no delimitada, debe estar asociada con al menos un evento de UDM limitado.

Considera la siguiente regla con la sección de condición omitida:

rule NonexistenceExample {
  meta:
  events:
      $u1.metadata.event_type = "NETWORK_CONNECTION" // $u1 is a UDM event.
      $u2.metadata.event_type = "NETWORK_CONNECTION" // $u2 is a UDM event.
      $e1.graph.metadata.entity_type = "FILE"        // $e1 is an Entity.
      $e2.graph.metadata.entity_type = "FILE"        // $e2 is an Entity.

      $user = $u1.principal.user.userid // Match variable is required for Multi-Event Rule.

      // Placeholder Associations:
      //   u1        u2
      //   |  \    /
      // port   ip
      //   |       \
      //   e1        e2
      $u1.target.port = $port
      $e1.graph.entity.port = $port
      $u1.principal.ip = $ip
      $u2.target.ip = $ip
      $e2.graph.entity.ip = $ip

      // UDM-Entity Associations:
      // u1 - u2
      // |  \  |
      // e1   e2
      $u1.metadata.event_type = $u2.metadata.event_type
      $e1.graph.entity.hostname = $u1.principal.hostname
      $e2.graph.entity.hostname = $u1.target.hostname
      $e2.graph.entity.hostname = $u2.principal.hostname

  match:
    $user over 5m

  condition:
      <condition_section>
}

Los siguientes son ejemplos válidos para <condition_section>:

• $u1 and !$u2 and $e1 and $e2
  • Todos los eventos y las entidades de UDM están presentes en la sección de la condición.
  • Al menos un evento de UDM está delimitado.
• $u1 and !$u2 and $e1 and !$e2
  • $e2 no está delimitado, lo cual está permitido, ya que está asociado con $u1, que está delimitada. Si $e2 no estuviera asociado con $u1, no sería válido.
• #port > 50 and #ip = 0
  • No hay eventos ni entidades de UDM en la sección de condiciones. Sin embargo, los marcadores de posición que están presentes abarcan todos los eventos y entidades de UDM.
  • $ip está asignado a $u1 y $u2, y #ip = 0 es una condición no delimitada. Sin embargo, las condiciones delimitadas son más sólidas que las no delimitadas. Como $port se asigna a $u1, y #port > 50 es una condición delimitada, $u1 sigue delimitada.

Los siguientes son ejemplos no válidos para <condition_section>:

• $u1 and $e1
  • Cada evento y entidad de UDM que aparece en la sección Eventos deben aparecer en la sección Condición (o tener asignado un marcador de posición que aparezca en la sección Condiciones).
• $u1, $u2, $e1, $u2, #port > 50
  • No se permiten las comas como separadores de condición.
• !$u1 and !$u2 and $e1 and $e2
  • Infringe el primer requisito de que al menos un evento de UDM está delimitado.
• ($u1 or #port < 50) and $u2 and $e1 and $e2
  • La palabra clave or no es compatible con las condiciones no delimitadas.
• ($u1 or $u2) and $e1 and $e2
  • No se admite la palabra clave or entre diferentes variables de eventos.
• not $u1 and $u2 and $e1 and $e2
  • No se permite la palabra clave not para las condiciones de eventos y marcadores de posición.
• #port < 50 and #ip = 0
  • Los marcadores de posición que están presentes abarcan todos los eventos y las entidades de UDM. Sin embargo, todas las condiciones no están delimitadas. Esto significa que ninguno de los eventos de UDM está delimitado, lo que provoca que no se pueda compilar la regla.

Nota: No uses una variable match en la sección condition. Es un error semántico, ya que los eventos se agrupan por el valor de la variable match.

Nota: No especifiques solo condiciones no delimitadas en todas las variables event a las que se asigna una variable match. Es un error semántico. Para que se muestre un valor de variable match, debe existir al menos un evento que contenga el valor.

Nota: En caso de usar una ventana deslizante, la variable de evento dinámica debe estar involucrada en al menos una condición delimitada.

Condicionales de resultados

Enumera los predicados de condiciones para las variables de resultado aquí, unidos con la palabra clave and o or, o precedidos por la palabra clave not.

Especifica los condicionales de resultado de manera diferente según el tipo de variable de resultado:

• integer: Compáralo con un literal de número entero con los operadores =, >, >=, <, <=, !=. Por ejemplo:

  $risk_score > 10

• float: Compáralo con un literal de número de punto flotante con los operadores =, >, >=, <, <=, !=. Por ejemplo:

  $risk_score <= 5.5

• string: Compárala con un literal de string que utiliza = o !=. Por ejemplo:

  $severity = "HIGH"

• lista de números enteros o arreglos: Especifica la condición con la función arrays.contains, por ejemplo:

  arrays.contains($event_ids, "id_1234")

Nota: Si usas la palabra clave or dentro de la subsección <event/placeholder condicionales>, debes encerrar toda la subsección entre paréntesis. Por ejemplo, ($e1 or $e2) and $outcome > 0.

Clasificación de reglas

Especificar un condicional de resultado en una regla que tiene una sección de coincidencias significa que la regla se clasificará como de varios eventos para la cuota de reglas. Consulta la regla de un solo evento y la regla de varios eventos para obtener más información sobre las clasificaciones de uno o varios eventos.

Sintaxis de la sección de opciones

En la sección options, puedes especificar las opciones para la regla. A continuación, se muestra un ejemplo de cómo especificar la sección de opciones:

rule RuleOptionsExample {
  // Other rule sections

  options:
    allow_zero_values = true
}

Puedes especificar opciones con la sintaxis key = value, en la que key debe ser un nombre predefinido de opción y value debe ser un valor válido para la opción, como se especifica en las siguientes opciones:

allow_zero_values

Los valores válidos para esta opción son true y false, que determinan si esta opción está habilitada o no. El valor predeterminado es false. Esta opción se inhabilita si no se especifica en la regla.

Para habilitar este parámetro de configuración, agrega lo siguiente a la sección de opciones de tu regla: allow_zero_values = true. Esto evitará que la regla filtre de manera implícita los valores cero de los marcadores de posición que se usan en la sección de coincidencia, como se describe en manejo de valores cero en la sección de coincidencias.

Expresiones booleanas

Las expresiones booleanas son expresiones con un tipo booleano.

Comparaciones

Para que una expresión binaria simple use como condición, utiliza la siguiente sintaxis:

• <EXPR> <OP> <EXPR>

La expresión puede ser un campo de evento, una variable, un literal o una expresión de función.

Por ejemplo:

• $e.source.hostname = "host1234"
• $e.source.port < 1024
• 1024 < $e.source.port
• $e1.source.hostname != $e2.target.hostname
• $e1.metadata.collected_timestamp.seconds > $e2.metadata.collected_timestamp.seconds
• $port >= 25
• $host = $e2.target.hostname
• "google-test" = strings.concat($e.principal.hostname, "-test")
• "[e-mail]" = re.replace($e.network.email.from, "com", "org")

Si ambos lados son literales, se considera un error de compilación.

Funciones

Algunas expresiones de función muestran un valor booleano, que se puede usar como un predicado individual en la sección events. Estas funciones son las siguientes:

• re.regex()
• net.ip_in_range_cidr()

Por ejemplo:

• re.regex($e.principal.hostname, `.*\.google\.com`)
• net.ip_in_range_cidr($e.principal.ip, "192.0.2.0/24")

Expresiones de lista de referencia

Puedes usar listas de referencias en la sección de eventos. Para obtener más información, consulta la sección Listas de referencia.

Expresiones lógicas

Puedes usar los operadores lógicos and y or en la sección events, como se muestra en los siguientes ejemplos:

• $e.metadata.event_type = "NETWORK_DNS" or $e.metadata.event_type = "NETWORK_DHCP"
• ($e.metadata.event_type = "NETWORK_DNS" and $e.principal.ip = "192.0.2.12") or ($e.metadata.event_type = "NETWORK_DHCP" and $e.principal.mac = "AB:CD:01:10:EF:22")
• not $e.metadata.event_type = "NETWORK_DNS"

De forma predeterminada, el orden de prioridad de mayor a menor es not, and, or.

Por ejemplo, “a o b y c” se evalúa como “a o (b y c)” cuando los operadores or y and se definen de forma explícita en la expresión.

En la sección events, los predicados se unen mediante el operador and si no se define de forma explícita un operador.

El orden de evaluación puede ser diferente si el operador and está implícito en la expresión.

Por ejemplo, considera las siguientes expresiones de comparación en las que or se define de forma explícita. El operador and está implícito.

$e1.field = "bat"
or $e1.field = "baz"
$e2.field = "bar"

Este ejemplo se interpreta de la siguiente manera:

($e1.field = "bat" or $e1.field = "baz")
and ($e2.field = "bar")

Debido a que or se define de forma explícita, los predicados que rodean a or se agrupan y evalúan primero. El último predicado, $e2.field = "bar", se une de forma implícita con and. El resultado es ese orden de la evaluación que cambia.

Nota: Existe un límite en la cantidad de valores and y or que puedes especificar para una sola regla. Este límite varía según la complejidad de la regla y la complejidad de los datos de tu cuenta de Chronicle. Comunícate con tu representante de Chronicle para obtener información sobre alternativas a este tipo de regla.

Tipos enumerados

Puedes usar los operadores con tipos enumerados. Se puede aplicar a reglas para simplificar y optimizar el rendimiento (usa un operador en lugar de listas de referencia).

En el siguiente ejemplo, “USER_UNCATEGORIZED” y “USER_RESOURCE_DELETION” corresponden a 15,000 y 15014, por lo que la regla buscará todos los eventos de la lista:

$e.metadata.event_type >= "USER_CATEGORIZED" and $e.metadata.event_type <= "USER_RESOURCE_DELETION"

Lista de eventos:

• USER_RESOURCE_DELETION
• USER_RESOURCE_UPDATE_CONTENT
• USER_RESOURCE_UPDATE_PERMISSIONS
• USER_STATS
• USER_UNCATEGORIZED

Modificador sin mayúsculas

Cuando tienes una expresión de comparación entre valores de string o una expresión regular, puedes agregar ningún uso de mayúsculas al final de la expresión para ignorar las mayúsculas.

• $e.principal.hostname != "http-server" nocase
• $e1.principal.hostname = $e2.target.hostname nocase
• $e.principal.hostname = /dns-server-[0-9]+/ nocase
• re.regex($e.target.hostname, `client-[0-9]+`) nocase

No se puede usar cuando un tipo de campo es un valor enumerado. Los siguientes ejemplos no son válidos y generarán errores de compilación:

• $e.metadata.event_type = "NETWORK_DNS" nocase
• $e.network.ip_protocol = "TCP" nocase

Campos repetidos

En el Modelo de datos unificado (UDM), algunos campos se etiquetan como repetidos, lo que indica que son listas de valores o de otros tipos de mensajes.

Campos repetidos y expresiones booleanas

Existen 2 tipos de expresiones booleanas que actúan sobre campos repetidos:

1. Modificado
2. Sin modificar

Considera el siguiente evento:

event_original {
  principal {
    // ip is a repeated field
    ip: [ "192.0.2.1", "192.0.2.2", "192.0.2.3" ]

    hostname: "host"
  }
}

Expresiones modificadas

En las siguientes secciones, se describe el propósito y cómo usar los modificadores any y all en las expresiones.

cualquiera

Si algún elemento del campo repetido satisface la condición, el evento en su conjunto cumple con la condición.

• event_original satisface any $e.principal.ip = "192.0.2.1".
• event_original falla con any $e.repeated_field.field_a = "9.9.9.9.

todos

Si todos los elementos del campo repetido satisfacen la condición, el evento en su totalidad cumple la condición.

• event_original satisface net.ip_in_range_cidr(all $e.principal.ip, "192.0.2.0/8").
• event_original falla con all $e.principal.ip = "192.0.2.2".

Nota: Para usar any o all con una función, el modificador debe preceder al campo repetido y no a la función. Por ejemplo, re.regex(any $e.about.hostname, `server-[0-9]+`) es válido, mientras que any re.regex($e.about.hostname, `server-[0-9]+`) no lo es.

Cuando escribas una condición con any o all, ten en cuenta que negar la condición con not puede no tener el mismo significado que usar el operador negado.

Por ejemplo:

• not all $e.principal.ip = "192.168.12.16" verifica si no todas las direcciones IP coinciden con 192.168.12.16, lo que significa que la regla verifica si al menos una dirección IP no coincide con 192.168.12.16.
• all $e.principal.ip != "192.168.12.16" verifica si todas las direcciones IP no coinciden con 192.168.12.16, lo que significa que la regla verifica que no haya direcciones IP que coincidan con 192.168.12.16.

Restricciones:

• Los operadores any y all solo son compatibles con los campos repetidos (no con los campos escalares).
• No se pueden usar any y all para unir dos campos repetidos. Por ejemplo, any $e1.principal.ip = $e2.principal.ip no es válido.
• Los operadores any y all no son compatibles con la expresión de la lista de referencias.

Expresiones sin modificar

Con expresiones sin modificar, cada elemento en el campo repetido se trata de manera individual. Si el campo repetido de un evento contiene n elementos, la regla se aplica a n copias del evento y cada copia tiene uno de los elementos del campo repetido. Estas copias son transitorias y no se almacenan.

La regla se aplica en las siguientes copias:

copia del evento	principal.ip	principal.hostname
event_copy_1	“192.0.2.1”	"anfitrión"
event_copy_2	“192.0.2.2”	"anfitrión"
event_copy_3	“192.0.2.3”	"anfitrión"

Si alguna copia de un evento satisface todas las condiciones no modificadas en el campo repetido, el evento en su totalidad cumple con todas las condiciones. Esto significa que, si tienes varias condiciones en un campo repetido, la copia del evento debe satisfacer todas ellas. Los siguientes ejemplos de reglas usan el conjunto de datos de ejemplo anterior para demostrar este comportamiento.

La siguiente regla muestra una coincidencia cuando se ejecuta en el conjunto de datos de ejemplo event_original, ya que event_copy_1 satisface todos los predicados de eventos:

rule repeated_field_1 {
  meta:
  events:
    net.ip_in_range_cidr($e.principal.ip, "192.0.2.0/8") // Checks if IP address matches 192.x.x.x
    $e.principal.ip = "192.0.2.1"
  condition:
    $e
}

La siguiente regla no muestra una coincidencia cuando se ejecuta con el conjunto de datos de ejemplo event_original, ya que no hay una copia de eventos en $e.principal.ip que satisfaga todos los predicados de eventos.

rule repeated_field_2 {
  meta:
  events:
    $e.principal.ip = "192.0.2.1"
    $e.principal.ip = "192.0.2.2"
  condition:
    $e
}

Las expresiones modificadas en campos repetidos son compatibles con las expresiones sin modificar en campos repetidos porque la lista de elementos es la misma para cada copia de evento. Ten en cuenta la siguiente regla:

rule repeated_field_3 {
  meta:
  events:
    any $e.principal.ip = "192.0.2.1"
    $e.principal.ip = "192.0.2.3"
  condition:
    $e
}

La regla se aplica en las siguientes copias:

copia del evento	principal.ip	cualquier $e.principal.ip
event_copy_1	“192.0.2.1”	[“192.0.2.1”, “192.0.2.2”, “192.0.2.3”]
event_copy_2	“192.0.2.2”	[“192.0.2.1”, “192.0.2.2”, “192.0.2.3”]
event_copy_3	“192.0.2.3”	[“192.0.2.1”, “192.0.2.2”, “192.0.2.3”]

En este caso, todas las copias satisfacen any $e.principal.ip = "192.0.2.1", pero solo event_copy_3 satisface $e.principal.ip = "192.0.2.3". Como resultado, el evento en su conjunto coincidiría.

Otra forma de pensar sobre estos tipos de expresiones es la siguiente:

• Las expresiones en campos repetidos que usan any o all operan en la lista en event_original.
• Las expresiones en campos repetidos que no usan any ni all operan en eventos event_copy_n individuales.

Campos y marcadores de posición repetidos

Los campos repetidos funcionan con asignaciones de marcadores de posición. Al igual que las expresiones sin modificar en campos repetidos, se crea una copia del evento para cada elemento. Con el mismo ejemplo de event_copy, el marcador de posición toma el valor del valor de campo repetido de event_copy_n para cada una de las copias de eventos, donde n es el número de copia del evento. Si se usa el marcador de posición en la sección de coincidencias, es posible que se generen varias coincidencias.

En el siguiente ejemplo, se genera una coincidencia. El marcador de posición $ip es igual a 192.0.2.1 para event_copy_1, que satisface los predicados de la regla. Las muestras de eventos de la coincidencia contienen un solo elemento, event_original.

// Generates 1 match.
rule repeated_field_placeholder1 {
  meta:
  events:
    $ip = $e.principal.ip
    $ip = "192.0.2.1"
    $host = $e.principal.hostname

  match:
    $host over 5m

  condition:
    $e
}

En el siguiente ejemplo, se generan tres coincidencias. El marcador de posición $ip es igual a valores diferentes para cada una de las diferentes copias de event_copy_n. La agrupación se realiza el $ip, ya que está en la sección de coincidencia. Por lo tanto, obtienes tres coincidencias en las que cada una tiene un valor diferente para la variable de coincidencia $ip. Cada coincidencia tiene la misma muestra de evento: un solo elemento, event_original.

// Generates 3 matches.
rule repeated_field_placeholder2 {
  meta:
  events:
    $ip = $e.principal.ip
    net.ip_in_range_cidr($ip, "192.0.2.0/8") // Checks if IP matches 192.x.x.x

  match:
    $ip over 5m

  condition:
    $e
}

Nota: any y all no se pueden usar cuando se asigna un campo repetido a una variable de marcador de posición ni cuando se combina con un campo de otro evento. Por ejemplo, any $e.principal.ip = $ip no es válido.

Resultados que utilizan marcadores de posición asignados a campos repetidos

Los marcadores de posición se asignan a cada elemento de cada campo repetido, no a la lista completa. Por lo tanto, cuando se usan en la sección de resultados, el resultado se calcula solo con los elementos que cumplieron con las secciones anteriores.

Ten en cuenta la siguiente regla:

rule outcome_repeated_field_placeholder {
  meta:
  events:
    $ip = $e.principal.ip
    $ip = "192.0.2.1" or $ip = "192.0.2.2"
    $host = $e.principal.hostname

  match:
    $host over 5m

  outcome:
    $o = array_distinct($ip)

  condition:
    $e
}

Hay 4 etapas de ejecución para esta regla. La primera etapa es la copia de eventos:

copia del evento	$ip	$host	USD e
event_copy_1	“192.0.2.1”	"anfitrión"	event_id
event_copy_2	“192.0.2.2”	"anfitrión"	event_id
event_copy_3	“192.0.2.3”	"anfitrión"	event_id

A continuación, en la sección Events, se filtrarán las filas que no coincidan con los filtros:

copia del evento	$ip	$host	USD e
event_copy_1	“192.0.2.1”	"anfitrión"	event_id
event_copy_2	“192.0.2.2”	"anfitrión"	event_id

event_copy_3 se filtra porque "192.0.2.3" no cumple con $ip = "192.0.2.1" or $ip = "192.0.2.2".

La sección de coincidencia se agrupará por variables de coincidencia y la sección de resultados realizará la agregación en cada grupo:

$host	$o	USD e
"anfitrión"	[“192.0.2.1”, “192.0.2.2”]	event_id

$o = array_distinct($ip) se calcula con $ip de la etapa anterior y no con la etapa de copia de eventos.

Por último, la sección Condición filtrará cada grupo. Dado que esta regla solo verifica la existencia de $e, la fila anterior producirá una única detección.

$o no contiene todos los elementos de $e.principal.ip porque no todos los elementos cumplen con todas las condiciones de la sección de eventos. Sin embargo, todos los elementos de e.principal.ip aparecerán en la muestra del evento porque esta usa event_original.

Indexación de arrays

Puedes indexar arrays en campos repetidos. Para acceder al enésimo elemento de campo repetido, usa la sintaxis de lista estándar (los elementos tienen indexación 0). Un elemento fuera de los límites muestra el valor predeterminado.

• $e.principal.ip[0] = "192.168.12.16"
• $e.principal.ip[999] = "" Si hay menos de 1,000 elementos, esto se evalúa como true.

Restricciones:

• Un índice debe ser un literal de número entero no negativo. Por ejemplo, $e.principal.ip[-1] no es válido.
• Los valores que tienen un tipo int (por ejemplo, un marcador de posición establecido en int) no se tienen en cuenta.
• La indexación de arrays no se puede combinar con any ni all. Por ejemplo, any $e.intermediary.ip[0] no es válido.
• La indexación de arrays no se puede combinar con la sintaxis de mapa. Por ejemplo, $e.additional.fields[0]["key"] no es válido.
• Si la ruta del campo contiene varios campos repetidos, todos ellos deben usar la indexación de arrays. Por ejemplo, $e.intermediary.ip[0] no es válido porque intermediary y ip son campos repetidos, pero solo hay un índice para ip.

Mensajes repetidos

Cuando se repite un campo message, un efecto no deseado es reducir la probabilidad de una coincidencia. Esto se ilustra en los siguientes ejemplos.

Considera el siguiente evento:

event_repeated_message {
  // about is a repeated message field.
  about {
    // ip is a repeated string field.
    ip: [ "192.0.2.1", "192.0.2.2", "192.0.2.3" ]

    hostname: "alice"
  }
  about {
    hostname: "bob"
  }
}

Como se indica para las expresiones sin modificar en campos repetidos, se crea una copia temporal del evento por cada elemento del campo repetido. Ten en cuenta la siguiente regla:

rule repeated_message_1 {
  meta:
  events:
    $e.about.ip = "192.0.2.1"
    $e.about.hostname = "bob"
  condition:
    $e
}

La regla se aplica en las siguientes copias:

copia del evento	about.ip	about.hostname
event_copy_1	“192.0.2.1”	"alicia"
event_copy_2	“192.0.2.2”	"alicia"
event_copy_3	“192.0.2.3”	"alicia"
event_copy_4	""	“bob”

El evento no coincide con la regla porque no existe una copia de evento que satisfaga todas las expresiones.

Indexación de arrays y mensajes repetidos

Otro comportamiento inesperado puede ocurrir cuando se usa la indexación de arrays con expresiones sin modificar en campos de mensajes repetidos. Considera la siguiente regla de ejemplo que usa la indexación de arrays:

rule repeated_message_2 {
  meta:
  events:
    $e.about.ip = "192.0.2.1"
    $e.about[1].hostname = "bob"
  condition:
    $e
}

La regla se aplica a las siguientes copias:

copia del evento	about.ip	alrededor de[1].nombredehost
event_copy_1	“192.0.2.1”	“bob”
event_copy_2	“192.0.2.2”	“bob”
event_copy_3	“192.0.2.3”	“bob”
event_copy_4	""	“bob”

Dado que event_copy_1 satisface todas las expresiones en repeated_message_2, el evento coincide en la regla.

Esto puede generar un comportamiento inesperado porque a la regla repeated_message_1 le faltaba indexación de arrays y no produjo coincidencias, mientras que la regla repeated_message_2 usaba la indexación de arrays y generó una coincidencia.

Comentarios

Designa comentarios con dos barras diagonales (// comment) o comentarios de varias líneas que tengan un asterisco de barra (/* comment */), como lo harías en C.

Literales

Se admiten números enteros no negativos, números de punto flotante, string, booleanos y literales de expresión regular.

Literales de string y de expresión regular

Puedes usar cualquiera de los siguientes caracteres para encerrar cadenas en YARA-L 2.0. Sin embargo, el texto citado se interpreta de manera diferente según el que utilices.

1. Comillas dobles ("): Se usan para strings normales. Se deben incluir caracteres de escape.
   Por ejemplo: “hello\tworld” —\t se interpreta como una pestaña.

2. Comillas inversas (`): Se usan para interpretar todos los caracteres literalmente.
   Por ejemplo: `hello\tworld` —\t no se interpreta como una tabulación.

Para las expresiones regulares, tienes dos opciones.

Si quieres usar expresiones regulares directamente sin la función re.regex(), usa /regex/ para los literales de expresión regular.

También puedes usar literales de string como literales de expresión regular cuando usas la función re.regex(). Ten en cuenta que, para los literales de string de comillas dobles, debes escapar los caracteres de barra inversa con caracteres de barra inversa, lo que puede parecer incómodo.

Por ejemplo, las siguientes expresiones regulares son equivalentes:

• re.regex($e.network.email.from, `.*altostrat\.com`)
• re.regex($e.network.email.from, ".*altostrat\\.com")
• $e.network.email.from = /.*altostrat\.com/

Google recomienda usar comillas inversas para strings en expresiones regulares a fin de facilitar la legibilidad.

Operadores

Puedes usar los siguientes operadores en YARA-L:

Operador	Descripción
=	igual/declaración
!=	no igual
<	menor que
<=	menor o igual que
>	mayor que
>=	mayor o igual que

Variables

En YARA-L 2.0, todas las variables se representan como $<variable name>.

Puedes definir los siguientes tipos de variables:

• Variables de evento: Representa grupos de eventos en forma normalizada (UDM) o eventos de entidades. Especifica las condiciones para las variables de evento en la sección events. Las variables de evento se identifican usando un nombre, una fuente del evento y campos de evento. Las fuentes permitidas son udm (para eventos normalizados) y graph (para eventos de entidad). Si se omite la fuente, udm se establece como la fuente predeterminada. Los campos de eventos se representan como una cadena de .<field name> (por ejemplo, $e.field1.field2). Las cadenas de campos de evento siempre comienzan desde la fuente de nivel superior (UDM o entidad).

• Variables de coincidencia: Declara en la sección match. Las variables de coincidencia se convierten en campos de agrupación para la consulta, ya que se muestra una fila por cada conjunto único de variables de coincidencia (y por cada período). Cuando la regla encuentra una coincidencia, se devuelven los valores de la variable coincidente. Especifica qué representa cada variable de coincidencia en la sección events.

• Variables de marcador de posición: Declara y defínelas en la sección events. Las variables de marcadores de posición son similares a las variables de coincidencia. Sin embargo, puedes usar variables de marcador de posición en la sección condition para especificar condiciones de coincidencia.

Nota: Cada variable de marcador de posición debe asignarse a un campo de evento. Por ejemplo, si solo hiciste referencia al siguiente marcador de posición en esta única línea de una regla, no se compilaría, ya que $var no está vinculado a una variable de evento: $e.field != $var

Usa variables de coincidencia y variables de marcador de posición para declarar relaciones entre campos de eventos a través de condiciones de unión transitivas (consulta Sintaxis de la sección de eventos para obtener más información).

Palabras clave

Las palabras clave en YARA-L 2.0 no distinguen mayúsculas de minúsculas. Por ejemplo, and o AND son equivalentes. Los nombres de variables no deben entrar en conflicto con las palabras clave. Por ejemplo, $AND o $outcome no son válidos.

Las siguientes son palabras clave para las reglas del motor de detección: rule, meta, match, over, events, condition, outcome, options, and, or, not, nocase, in, regex, cidr, before, after, all, any, if, max, match/ match/ match/match/match/2.minsumarrayarray_distinctcountcount_distinctisnull

Maps

YARA-L admite el acceso a mapas para structs y etiquetas.

Estructuras y etiquetas

Algunos campos de UDM usan los tipos de datos Struct o Label.

Para buscar un par clave-valor específico en Struct y en Label, usa la sintaxis de mapa estándar:

// A Struct field.
$e.udm.additional.fields["pod_name"] = "kube-scheduler"
// A Label field.
$e.metadata.ingestion_labels["MetadataKeyDeletion"] = "startup-script"

El acceso al mapa siempre muestra una string.

Casos compatibles

Sección Eventos y resultados

// Using a Struct field in the events section
events:
  $e.udm.additional.fields["pod_name"] = "kube-scheduler"

// Using a Label field in the outcome section
outcome:
  $value = array_distinct($e.metadata.ingestion_labels["MetadataKeyDeletion"])

Asigna un valor de mapa a un marcador de posición

$placeholder = $u1.metadata.ingestion_labels["MetadataKeyDeletion"]

Usa un campo de mapa en una condición de unión

// using a Struct field in a join condition between two udm events $u1 and $u2
$u1.metadata.event_type = $u2.udm.additional.fields["pod_name"]

Casos no compatibles

No se admiten mapas en los siguientes casos.

Cómo combinar palabras clave any o all con un mapa

Por ejemplo, no se admite lo siguiente: all $e.udm.additional.fields["pod_name"] = "kube-scheduler"

Otros tipos de valores

La sintaxis del mapa solo puede mostrar un valor de cadena. En el caso de los tipos de datos Struct, la sintaxis del mapa solo puede acceder a las claves cuyos valores sean cadenas. No es posible acceder a claves cuyos valores sean otros tipos primitivos, como números enteros.

Manejo de valores duplicados

Los accesos a mapas siempre muestran un solo valor. En el caso límite poco común de que el acceso al mapa pueda hacer referencia a varios valores, el acceso al mapa mostrará de manera determinista el primer valor.

Esto puede suceder en cualquiera de los siguientes casos:

• Una etiqueta tiene una clave duplicada.

  La estructura de etiquetas representa un mapa, pero no aplica la unicidad de la clave. Por convención, un mapa debe tener claves únicas, por lo que Chronicle no recomienda propagar una etiqueta con claves duplicadas.

  El texto de regla $e.metadata.ingestion_labels["dupe-key"] mostraría el primer valor posible, val1, si se ejecuta en el siguiente ejemplo de datos:

  // Disrecommended usage of label with a duplicate key:
  event {
    metadata{
      ingestion_labels{
        key: "dupe-key"
        value: "val1" // This is the first possible value for "dupe-key"
      }
      ingestion_labels{
        key: "dupe-key"
        value: "val2"
      }
    }
  }
  

• Una etiqueta tiene un campo principal repetido.

  Un campo repetido puede contener una etiqueta como campo secundario. Dos entradas diferentes en el campo repetido de nivel superior pueden contener etiquetas que tienen la misma clave. El texto de regla $e.security_result.rule_labels["key"] mostraría el primer valor posible, val3, si se ejecuta en el siguiente ejemplo de datos:

  event {
    // security_result is a repeated field.
    security_result {
      threat_name: "threat1"
      rule_labels {
        key: "key"
        value: "val3" // This is the first possible value for "key"
      }
    }
    security_result {
      threat_name: "threat2"
      rule_labels {
        key: "key"
        value: "val4"
      }
    }
  }
  

Funciones

En esta sección, se describen las funciones de YARA-L 2.0 que Chronicle admite en Detection Engine.

Estas funciones se pueden usar en las siguientes áreas de una regla:

• Sección events.
• BOOL_CLAUSE de un condicional en la sección de resultados.

arrays.length

arrays.length(repeatedField)

Descripción

Muestra la cantidad de elementos de campo repetidos.

Tipos de datos de parámetros

LIST

Tipo de datos que se muestra

NUMBER

Muestras de código

Ejemplo 1

Muestra la cantidad de elementos de campo repetidos.

arrays.length($e.principal.ip) = 2

Ejemplo 2

Si hay varios campos repetidos a lo largo de la ruta, se muestra la cantidad total de elementos de campo repetidos.

arrays.length($e.intermediary.ip) = 3

math.abs

math.abs(numericExpression)

Descripción

Muestra el valor absoluto de un número entero o una expresión flotante.

Tipos de datos de parámetros

NUMBER

Tipo de datos que se muestra

NUMBER

Muestras de código

Ejemplo 1

En este ejemplo, se muestra el valor True si el evento ocurrió más de 5 minutos desde la hora especificada (en segundos a partir del tiempo Unix), sin importar si el evento ocurrió antes o después del tiempo especificado. Una llamada a math.abs no puede depender de múltiples variables ni marcadores de posición. Por ejemplo, no puedes reemplazar el valor de tiempo codificado de 1643687343 en el siguiente ejemplo por $e2.metadata.event_timestamp.seconds.

300 < math.abs($e1.metadata.event_timestamp.seconds - 1643687343)

metrics

Las funciones de métricas pueden agregar grandes cantidades de datos históricos. Puedes usar esto en tu regla con metrics.functionName() en la sección de resultados.

Para obtener más información, consulta Métricas de YARA-L.

net.ip_in_range_cidr

net.ip_in_range_cidr(ipAddress, subnetworkRange)

Descripción

Muestra true cuando la dirección IP proporcionada está dentro de la subred especificada.

Puedes usar YARA-L para buscar eventos de UDM en todas las direcciones IP dentro de una subred con la declaración net.ip_in_range_cidr(). Se admiten IPv4 e IPv6.

Para buscar en un rango de direcciones IP, especifica un campo de IP de UDM y un rango de CIDR. YARA-L puede administrar campos de dirección IP únicos y repetidos.

Para buscar en un rango de direcciones IP, especifica un campo de UDM ip y un rango de enrutamiento entre dominios sin clases (CIDR). YARA-L puede administrar campos de dirección IP únicos y repetidos.

Tipos de datos de parámetros

STRING y STRING

Tipo de datos que se muestra

BOOL

Muestras de código

Ejemplo 1

Ejemplo de IPv4:

net.ip_in_range_cidr($e.principal.ip, "192.0.2.0/24")

Ejemplo 2

Ejemplo de IPv6:

net.ip_in_range_cidr($e.network.dhcp.yiaddr, "2001:db8::/32")

Para ver una regla de ejemplo que use la declaración net.ip_in_range_cidr(), consulta la regla de ejemplo en Evento único dentro del rango de direcciones IP.

re.regex

Puedes definir la coincidencia de expresiones regulares en YARA-L 2.0 con cualquiera de las siguientes sintaxis:

• Uso de la sintaxis YARA: relacionado con eventos La siguiente es una representación genérica de esta sintaxis: none $e.field = /regex/
• Uso de la sintaxis YARA-L como una función que toma los siguientes parámetros:
  • Campo al que se aplica la expresión regular.
  • Expresión regular especificada como una cadena. Puedes usar el modificador nocase después de las cadenas para indicar que la búsqueda debe ignorar el uso de mayúsculas. La siguiente es una representación genérica de esta sintaxis: none re.regex($e.field, `regex`)

Descripción

Esta función muestra true si la string contiene una substring que coincide con la expresión regular proporcionada. No es necesario agregar .* al principio o al final de la expresión regular.

Notas

• Para hacer coincidir la cadena exacta o solo un prefijo o sufijo, incluye los caracteres de anclaje ^ (inicio) y $ (final) en la expresión regular. Por ejemplo, /^full$/ coincide exactamente con "full", mientras que /full/ podría coincidir con "fullest", "lawfull" y "joyfully".
• Si el campo de UDM incluye caracteres de línea nueva, regexp solo coincidirá con la primera línea del campo de UDM. Para aplicar la coincidencia completa de campos de UDM, agrega un (?s) a la expresión regular. Por ejemplo, reemplaza /.*allUDM.*/ por /(?s).*allUDM.*/.

Tipos de datos de parámetros

STRING y STRING

Tipos de expresiones de parámetros

ANY y ANY

Tipo de datos que se muestra

BOOL

Muestras de código

Ejemplo 1

// Equivalent to $e.principal.hostname = /google/
re.regex($e.principal.hostname, "google")

re.capture

re.capture(stringText, regex)

Descripción

Captura (extrae) datos de una string mediante el patrón de expresión regular proporcionado en el argumento.

Esta función tiene dos argumentos:

• stringText: Es la cadena original que se buscará.
• regex: Es la expresión regular que indica el patrón que se debe buscar.

La expresión regular puede contener 0 o 1 grupos de captura entre paréntesis. Si la expresión regular contiene 0 grupos de captura, la función muestra la primera substring completa que coincida. Si la expresión regular contiene 1 grupo de captura, muestra la primera substring coincidente para ese grupo. Si defines dos o más grupos de captura, se mostrará un error del compilador.

Tipos de datos de parámetros

STRING y STRING

Tipo de datos que se muestra

STRING

Muestras de código

Ejemplo 1

En este ejemplo, si $e.principal.hostname contiene "aaa1bbaa2", las siguientes afirmaciones serían verdaderas, ya que la función muestra la primera instancia. En este ejemplo, no hay grupos de captura.

"aaa1" = re.capture($e.principal.hostname, "a+[1-9]")

Ejemplo 2

Este ejemplo captura todo lo que aparece después del símbolo @ en un correo electrónico. Si el campo $e.network.email.from es [e-mail], el ejemplo muestra google.com. El siguiente ejemplo contiene un grupo de captura.

"google.com" = re.capture($e.network.email.from , "@(.*)")

Ejemplo 3

Si la expresión regular no coincide con ninguna substring en el texto, la función muestra una string vacía. Puedes omitir eventos en los que no se produzcan coincidencias si excluyes la string vacía, lo cual es especialmente importante cuando usas re.capture() con desigualdad:

// Exclude the empty string to omit events where no match occurs.
"" != re.capture($e.network.email.from , "@(.*)")

// Exclude a specific string with an inequality.
"google.com" != re.capture($e.network.email.from , "@(.*)")

re.replace

re.replace(stringText, replaceRegex, replacementText)

Descripción

Realiza un reemplazo de expresiones regulares.

Esta función toma tres argumentos:

• stringText: Es la cadena original.
• replaceRegex: Es la expresión regular que indica el patrón que se debe buscar.
• replacementText: Es el texto que se insertará en cada coincidencia.

Muestra una nueva cadena derivada del stringText original, en la que todas las subcadenas que coinciden con el patrón en replaceRegex se reemplazan por el valor en replacementText. Puedes usar dígitos con escape de barra inversa (de \1 a \9) dentro de replacementText para insertar texto que coincida con el grupo entre paréntesis correspondiente en el patrón replaceRegex. Usa \0 para hacer referencia a todo el texto coincidente.

La función reemplaza las coincidencias no superpuestas y priorizará el reemplazo del primer caso que se encuentre. Por ejemplo, re.replace("banana", "ana", "111") muestra la string "b111na".

Tipos de datos de parámetros

STRING, STRING y STRING

Tipo de datos que se muestra

STRING

Muestras de código

Ejemplo 1

En este ejemplo, se captura todo lo que está después del símbolo @ en un correo electrónico, se reemplaza com por org y se muestra el resultado. Observa el uso de funciones anidadas.

"[e-mail]" = re.replace($e.network.email.from, "com", "org")

Ejemplo 2

En este ejemplo, se usan dígitos con escape de barra inversa en el argumento replacementText para hacer referencia a coincidencias con el patrón replaceRegex.

"test1.com.google" = re.replace(
                       $e.principal.hostname, // holds "test1.test2.google.com"
                       "test2\.([a-z]*)\.([a-z]*)",
                       "\\2.\\1"  // \\1 holds "google", \\2 holds "com"
                     )

Ejemplo 3

Ten en cuenta los siguientes casos cuando trabajes con strings vacías y re.replace():

Usa una cadena vacía como replaceRegex:

// In the function call below, if $e.principal.hostname contains "name",
// the result is: 1n1a1m1e1, because an empty string is found next to
// every character in `stringText`.
re.replace($e.principal.hostname, "", "1")

Para reemplazar una cadena vacía, puedes usar "^$" como replaceRegex:

// In the function call below, if $e.principal.hostname contains the empty
// string, "", the result is: "none".
re.replace($e.principal.hostname, "^$", "none")

strings.base64_decode

strings.base64_decode(encodedString)

Descripción

Muestra una string que contiene la versión decodificada en base64 de la string codificada.

Esta función toma una cadena codificada en base64 como argumento. Si encodedString no es una string válida codificada en base64, la función muestra encodedString sin cambios.

Tipos de datos de parámetros

STRING

Tipo de datos que se muestra

STRING

Muestras de código

Ejemplo 1

"test" = strings.base64_decode($e.principal.domain.name)

strings.coalesce

strings.coalesce(a, b, c, ...)

Descripción

Esta función toma una cantidad ilimitada de argumentos y muestra el valor de la primera expresión que no se evalúa como una string vacía (por ejemplo, "valor distinto de cero"). Si todos los argumentos se evalúan como una cadena vacía, la llamada a función muestra una cadena vacía.

Los argumentos pueden ser literales, campos de eventos o llamadas a funciones. Todos los argumentos deben ser del tipo STRING. Si algún argumento es campos de evento, los atributos deben ser del mismo evento.

Tipos de datos de parámetros

STRING

Tipo de datos que se muestra

STRING

Muestras de código

Ejemplo 1

En el siguiente ejemplo, se incluyen variables de cadena como argumentos. La condición se evalúa como verdadera cuando (1) $e.network.email.from es [e-mail] o (2) $e.network.email.from está vacío y $e.network.email.to es [e-mail].

"[e-mail]" = strings.coalesce($e.network.email.from, $e.network.email.to)

Ejemplo 2

En el siguiente ejemplo, se llama a la función coalesce con más de dos argumentos. Esta condición compara la primera dirección IP no nula del evento $e con los valores de la lista de referencia ip_watchlist. El orden en que se combinan los argumentos en esta llamada es el mismo que el orden en el que se enumeran en la condición de la regla:

1. Primero se evalúa $e.principal.ip.
2. A continuación, se evalúa $e.src.ip.
3. A continuación, se evalúa $e.target.ip.
4. Por último, la string “Sin IP” se muestra como valor predeterminado si no se establecen los campos ip anteriores.

strings.coalesce($e.principal.ip, $e.src.ip, $e.target.ip, "No IP") in %ip_watchlist

Ejemplo 3

En el siguiente ejemplo, se intenta fusionar principal.hostname del evento $e1 y $e2. Se mostrará un error del compilador porque los argumentos son diferentes variables de evento.

// returns a compiler error
"test" = strings.coalesce($e1.principal.hostname, $e2.principal.hostname)

strings.concat

strings.concat(a, b, c, ...)

Descripción

Muestra la concatenación de una cantidad ilimitada de elementos, cada uno de los cuales puede ser una string, un número entero o un número de punto flotante.

Si algún argumento es campos de evento, los atributos deben ser del mismo evento.

Tipos de datos de parámetros

STRING, FLOAT, INT

Tipo de datos que se muestra

STRING

Muestras de código

Ejemplo 1

En el siguiente ejemplo, se incluye una variable de cadena y una variable de número entero como argumentos. Tanto principal.hostname como principal.port provienen del mismo evento, $e, y se concatenan para mostrar una cadena.

"google:80" = strings.concat($e.principal.hostname, ":", $e.principal.port)

Ejemplo 2

En el siguiente ejemplo, se incluye una variable de string y un literal de string como argumentos.

"google-test" = strings.concat($e.principal.hostname, "-test") // Matches the event when $e.principal.hostname = "google"

Ejemplo 3

En el siguiente ejemplo, se incluye una variable de cadena y un literal de número de punto flotante como argumentos. Cuando se representan como cadenas, los números de punto flotante que son números enteros no tienen el punto decimal (por ejemplo, 1.0 se representa como “1”). Además, los números de punto flotante que superan los dieciséis dígitos decimales se truncan al decimosexto decimal.

"google2.5" = strings.concat($e.principal.hostname, 2.5)

Ejemplo 4

En el siguiente ejemplo, se incluye una variable de string, un literal de string, una variable de número entero y un literal de número de punto flotante como argumentos. Todas las variables son del mismo evento, $e, y se concatenan con los literales para mostrar una string.

"google-test802.5" = strings.concat($e.principal.hostname, "-test", $e.principal.port, 2.5)

Ejemplo 5

En el siguiente ejemplo, se intenta concatenar principal.port desde el evento $e1, con principal.hostname del evento $e2. Se mostrará un error de compilador porque los argumentos son variables de evento diferentes.

// Will not compile
"test" = strings.concat($e1.principal.port, $e2.principal.hostname)

strings.to_lower

strings.to_lower(stringText)

Descripción

Esta función toma una string de entrada y la muestra después de cambiar todos los caracteres a minúsculas.

Tipos de datos de parámetros

STRING

Tipo de datos que se muestra

STRING

Muestras de código

Ejemplo 1

En el siguiente ejemplo, se muestra true.

"[e-mail]" = strings.to_lower($e.network.email.to)

strings.to_upper

strings.to_upper(stringText)

Descripción

Esta función toma una string de entrada y muestra una string después de cambiar todos los caracteres a mayúsculas.

Tipos de datos de parámetros

STRING

Tipo de datos que se muestra

STRING

Muestras de código

Ejemplo 1

En el siguiente ejemplo, se muestra true.

"[e-mail]" = strings.to_upper($e.network.email.to)

timestamp.current_seconds

timestamp.current_seconds()

Descripción

Muestra un número entero que representa la hora actual en segundos Unix. Esto equivale aproximadamente a la marca de tiempo de detección y se basa en el momento en que se ejecuta la regla.

Tipos de datos de parámetros

NONE

Tipo de datos que se muestra

INT

Muestras de código

Ejemplo 1

En el siguiente ejemplo, se muestra true si el certificado venció por más de 24 horas. Para calcular la diferencia de tiempo, se restan los segundos Unix actuales y, luego, se comparan con un operador mayor que.

86400 < timestamp.current_seconds() - $e.network.tls.certificate.not_after

timestamp.get_date

timestamp.get_date(unix_seconds [, time_zone])

Descripción

Esta función muestra una string con el formato YYYY-MM-DD, que representa el día en el que se encuentra una marca de tiempo.

• unix_seconds es un número entero que representa la cantidad de segundos pasados de la época Unix, como $e.metadata.event_timestamp.seconds o un marcador de posición que contenga ese valor.
• time_zone es opcional y es una string que representa una zona horaria. Si se omite, el valor predeterminado es "GMT". Puedes especificar zonas horarias mediante literales de string. Las opciones son las siguientes:
  • El nombre de la base de datos de TZ, por ejemplo, “America/Los_Angeles”. Para obtener más información, consulta la columna “Nombre de la base de datos de TZ” de esta página.
  • El desplazamiento de la zona horaria de UTC en formato (+|-)H[H][:M[M]], por ejemplo: “-08:00”.

Estos son ejemplos de especificadores de zona horaria válidos, que puedes pasar como el segundo argumento a las funciones de extracción de tiempo:

"America/Los_Angeles", or "-08:00". ("PST" is not supported)
"America/New_York", or "-05:00". ("EST" is not supported)
"Europe/London"
"UTC"
"GMT"

Tipos de datos de parámetros

INT, STRING

Tipo de datos que se muestra

STRING

Muestras de código

Ejemplo 1

En este ejemplo, se omite el argumento time_zone, por lo que el valor predeterminado es "GMT".

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_date($ts) = "2024-02-19"

Ejemplo 2

En este ejemplo, se usa un literal de string para definir el time_zone.

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_date($ts, "America/Los_Angeles") = "2024-02-20"

timestamp.get_minute

timestamp.get_minute(unix_seconds [, time_zone])

Descripción

Esta función muestra un número entero en el rango [0, 59] que representa el minuto.

• unix_seconds es un número entero que representa la cantidad de segundos pasados de la época Unix, como $e.metadata.event_timestamp.seconds o un marcador de posición que contenga ese valor.
• time_zone es opcional y es una string que representa una zona horaria. Si se omite, el valor predeterminado es "GMT". Puedes especificar zonas horarias mediante literales de string. Las opciones son las siguientes:
  • El nombre de la base de datos de TZ, por ejemplo, “America/Los_Angeles”. Para obtener más información, consulta la columna “Nombre de la base de datos de TZ” de esta página.
  • El desplazamiento de la zona horaria de UTC en formato (+|-)H[H][:M[M]], por ejemplo: “-08:00”.

Estos son ejemplos de especificadores time_zone válidos, que puedes pasar como el segundo argumento a las funciones de extracción de tiempo:

"America/Los_Angeles", or "-08:00". ("PST" is not supported)
"America/New_York", or "-05:00". ("EST" is not supported)
"Europe/London"
"UTC"
"GMT"

Tipos de datos de parámetros

INT, STRING

Tipo de datos que se muestra

INT

Muestras de código

Ejemplo 1

En este ejemplo, se omite el argumento time_zone, por lo que el valor predeterminado es "GMT".

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_hour($ts) = 15

Ejemplo 2

En este ejemplo, se usa un literal de string para definir el time_zone.

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_hour($ts, "America/Los_Angeles") = 15

timestamp.get_hour

timestamp.get_hour(unix_seconds [, time_zone])

Descripción

Esta función muestra un número entero en el rango [0, 23] que representa la hora.

• unix_seconds es un número entero que representa la cantidad de segundos pasados de la época Unix, como $e.metadata.event_timestamp.seconds o un marcador de posición que contenga ese valor.
• time_zone es opcional y es una string que representa una zona horaria. Si se omite, el valor predeterminado es "GMT". Puedes especificar zonas horarias mediante literales de string. Las opciones son las siguientes:
  • El nombre de la base de datos de TZ, por ejemplo, “America/Los_Angeles”. Para obtener más información, consulta la columna “Nombre de la base de datos de TZ” de esta página.
  • El desplazamiento de la zona horaria de UTC en formato (+|-)H[H][:M[M]], por ejemplo: “-08:00”.

Estos son ejemplos de especificadores time_zone válidos, que puedes pasar como el segundo argumento a las funciones de extracción de tiempo:

"America/Los_Angeles", or "-08:00". ("PST" is not supported)
"America/New_York", or "-05:00". ("EST" is not supported)
"Europe/London"
"UTC"
"GMT"

Tipos de datos de parámetros

INT, STRING

Tipo de datos que se muestra

INT

Muestras de código

Ejemplo 1

En este ejemplo, se omite el argumento time_zone, por lo que el valor predeterminado es "GMT".

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_hour($ts) = 15

Ejemplo 2

En este ejemplo, se usa un literal de string para definir el time_zone.

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_hour($ts, "America/Los_Angeles") = 15

timestamp.get_day_of_week

timestamp.get_day_of_week(unix_seconds [, time_zone])

Descripción

Esta función muestra un número entero en el rango [1, 7] que representa el día de la semana que comienza con el domingo. Por ejemplo, 1 = domingo y 2 = lunes.

• unix_seconds es un número entero que representa la cantidad de segundos pasados de la época Unix, como $e.metadata.event_timestamp.seconds o un marcador de posición que contenga ese valor.
• time_zone es opcional y es una string que representa una zona horaria. Si se omite, el valor predeterminado es "GMT". Puedes especificar zonas horarias mediante literales de string. Las opciones son las siguientes:
  • El nombre de la base de datos de TZ, por ejemplo, “America/Los_Angeles”. Para obtener más información, consulta la columna “Nombre de la base de datos de TZ” de esta página.
  • El desplazamiento de la zona horaria de UTC en formato (+|-)H[H][:M[M]], por ejemplo: “-08:00”.

Estos son ejemplos de especificadores de zona horaria válidos, que puedes pasar como el segundo argumento a las funciones de extracción de tiempo:

"America/Los_Angeles", or "-08:00". ("PST" is not supported)
"America/New_York", or "-05:00". ("EST" is not supported)
"Europe/London"
"UTC"
"GMT"

Tipos de datos de parámetros

INT, STRING

Tipo de datos que se muestra

INT

Muestras de código

Ejemplo 1

En este ejemplo, se omite el argumento time_zone, por lo que el valor predeterminado es "GMT".

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_day_of_week($ts) = 6

Ejemplo 2

En este ejemplo, se usa un literal de string para definir el time_zone.

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_day_of_week($ts, "America/Los_Angeles") = 6

timestamp.get_week

timestamp.get_week(unix_seconds [, time_zone])

Descripción

Esta función muestra un número entero en el rango [0, 53] que representa la semana del año. Las semanas comienzan con el domingo. Las fechas anteriores al primer domingo del año están en la semana 0.

• unix_seconds es un número entero que representa la cantidad de segundos pasados de la época Unix, como $e.metadata.event_timestamp.seconds o un marcador de posición que contenga ese valor.
• time_zone es opcional y es una string que representa una zona horaria. Si se omite, el valor predeterminado es "GMT". Puedes especificar zonas horarias mediante literales de string. Las opciones son las siguientes:
  • El nombre de la base de datos de TZ, por ejemplo, “America/Los_Angeles”. Para obtener más información, consulta la columna “Nombre de la base de datos de TZ” de esta página.
  • El desplazamiento de la zona horaria de UTC en formato (+|-)H[H][:M[M]], por ejemplo: “-08:00”.

Estos son ejemplos de especificadores time_zone válidos, que puedes pasar como el segundo argumento a las funciones de extracción de tiempo:

"America/Los_Angeles", or "-08:00". ("PST" is not supported)
"America/New_York", or "-05:00". ("EST" is not supported)
"Europe/London"
"UTC"
"GMT"

Tipos de datos de parámetros

INT, STRING

Tipo de datos que se muestra

INT

Muestras de código

Ejemplo 1

En este ejemplo, se omite el argumento time_zone, por lo que el valor predeterminado es "GMT".

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_week($ts) = 0

Ejemplo 2

En este ejemplo, se usa un literal de string para definir el time_zone.

$ts = $e.metadata.collected_timestamp.seconds

timestamp.get_week($ts, "America/Los_Angeles") = 0

Función para asignar un marcador de posición

Puedes asignar el resultado de una llamada a función a un marcador de posición en la sección events. Por ejemplo:

$placeholder = strings.concat($e.principal.hostname, "my-string").

Luego, puedes usar las variables del marcador de posición en las secciones match, condition y outcome. Sin embargo, existen dos limitaciones con respecto a la asignación de funciones a marcadores de posición:

1. Cada marcador de posición en la función a la asignación de marcador de posición debe asignarse a una expresión que contenga un campo de evento. Los siguientes ejemplos son válidos:

   $ph1 = $e.principal.hostname
   $ph2 = $e.src.hostname
   
   // Both $ph1 and $ph2 have been assigned to an expression containing an event field.
   $ph1 = strings.concat($ph2, ".com")
   

   $ph1 = $e.network.email.from
   $ph2 = strings.concat($e.principal.hostname, "@gmail.com")
   
   // Both $ph1 and $ph2 have been assigned to an expression containing an event field.
   $ph1 = strings.to_lower($ph2)
   

   Sin embargo, el siguiente ejemplo no es válido:

   $ph1 = strings.concat($e.principal.hostname, "foo")
   $ph2 = strings.concat($ph1, "bar") // $ph2 has NOT been assigned to an expression containing an event field.
   

2. La llamada a función debe depender de uno y exactamente un evento. Sin embargo, se puede usar más de un campo del mismo evento en los argumentos de llamada a una función. Por ejemplo, lo siguiente es válido:

   $ph = strings.concat($event.principal.hostname, "string2")

   $ph = strings.concat($event.principal.hostname, $event.src.hostname)

   Sin embargo, la siguiente información no es válida:

   $ph = strings.concat("string1", "string2")

   $ph = strings.concat($event.principal.hostname, $anotherEvent.src.hostname)

Sintaxis de las listas de referencia

Consulta nuestra página sobre las listas de referencias para obtener más información sobre el comportamiento y la sintaxis de las listas de referencias.

Puedes usar las listas de referencias en las secciones events o outcome. A continuación, se muestra la sintaxis para usar varios tipos de listas de referencias en una regla:

// STRING reference list
$e.principal.hostname in %string_reference_list

// REGEX reference list
$e.principal.hostname in regex %regex_reference_list

// CIDR reference list
$e.principal.ip in cidr %cidr_reference_list

También puedes usar los operadores not y nocase con las listas de referencias, como se muestra a continuación: ```none // Excluye los eventos cuyos nombres de host coincidan con subcadenas de my_regex_list. No $e.principal.hostname en la regex %my_regex_list.

// Los nombres de host de los eventos deben coincidir con al menos 1 cadena en my_string_list (no distingue mayúsculas de minúsculas). $e.principal.hostname en %my_string_list sincase ```

El operador nocase es compatible con las listas STRING y REGEX.

Por motivos de rendimiento, Detection Engine restringe el uso de las listas de referencias.

• Cantidad máxima de declaraciones in en una regla, con o sin operadores especiales: 7
• Cantidad máxima de declaraciones in con el operador regex: 4
• Cantidad máxima de declaraciones in con el operador cidr: 2

Comprobación de tipos

Chronicle realiza la comprobación de tipo en tu sintaxis YARA-L a medida que creas reglas dentro de la interfaz. Los errores de comprobación de tipo que se muestran te ayudan a revisar la regla para asegurarte de que funcionará según lo esperado.

Los siguientes son ejemplos de predicados no válidos:

// $e.target.port is of type integer which cannot be compared to a string.
$e.target.port = "80"

// "LOGIN" is not a valid event_type enum value.
$e.metadata.event_type = "LOGIN"

Muestreo de eventos de detección

Las detecciones de reglas de varios eventos contienen muestras de eventos para proporcionar contexto sobre los eventos que causaron la detección. Existe un límite de hasta 10 muestras de eventos para cada variable de evento definida en la regla. Por ejemplo, si una regla define 2 variables de eventos, cada detección puede tener hasta 20 muestras de eventos. El límite se aplica a cada variable de evento por separado. Si una variable de evento tiene 2 eventos aplicables en esta detección y la otra variable de eventos tiene 15 eventos aplicables, la detección resultante contiene 12 muestras de eventos (2 + 10).

Se omiten de la detección todas las muestras de eventos que superen el límite.

Si deseas obtener más información sobre los eventos que causaron la detección, puedes usar agregaciones en la sección de resultados para generar información adicional en la detección.

Si estás viendo las detecciones en la IU, puedes descargar todas las muestras de eventos para una detección. Para obtener más información, consulta Cómo descargar eventos.