Prácticas recomendadas para la Búsqueda de UDM

En este documento, se describen las prácticas recomendadas de Google para realizar búsquedas con la Búsqueda de UDM. Las búsquedas de UDM pueden requerir recursos de procesamiento considerables para completarse si no se crean con cuidado. El rendimiento también varía según el tamaño y la complejidad de los datos en tu instancia de Google Security Operations.

Cada condición debe tener el formato de udm-field operator value.

Por ejemplo: principal.hostname = "win-server"

Siempre intenta reducir el intervalo de tiempo al mínimo necesario. Google Security Operations puede transferir una enorme cantidad de datos, por lo que limitar la amplitud de esos datos mientras se realiza una búsqueda puede mejorar sustancialmente el rendimiento de la búsqueda.

Puedes utilizar expresiones regulares cuando realices búsquedas de UDM:

  • Usa AND, OR y NOT.
  • Se supone AND en ausencia de los otros operadores.
  • Usa paréntesis para modificar el orden de prioridad.
  • Según el tipo de campo, los operadores de campo pueden incluir: = != >= > < <=

Cómo usar nocase como modificador de búsqueda

nocase se puede usar como modificador para ignorar el uso de mayúsculas.

Por ejemplo, la siguiente búsqueda no es válida:

target.user.userid = "TIM.SMITH" nocase

Las expresiones regulares no funcionan para los campos enumerados

No puedes usar expresiones regulares para campos enumerados (campos con un rango de valores predefinidos), como metadata.event_type o network.ip_protocol.

Por ejemplo, la siguiente búsqueda no es válida:

metadata.eventtype = /NETWORK*/

Sin embargo, la siguiente búsqueda es válida (y se aproxima a lo que se intentó anteriormente):

(metadata.event_type = "NETWORK_CONNECTION" or metadata.event_type = "NETWORK_DHCP")

Uso de cualquiera o todos los operadores en el campo Eventos

En la búsqueda de UDM, algunos campos se etiquetan como repetidos, lo que significa que son listas de valores, o bien otros tipos de mensajes. A diferencia de YARA-L, los campos repetidos en la búsqueda de UDM siempre se tratan con el operador any de forma predeterminada, sin la opción de especificar all en tu búsqueda.

Cuando se usa el operador any, el predicado se evalúa como verdadero si algún valor en el campo repetido satisface la condición. Por ejemplo, si buscas principal.ip != "1.2.3.4" y los eventos en tu búsqueda incluyen principal.ip = "1.2.3.4" y principal.ip = "5.6.7.8", la búsqueda generará coincidencias. Esto amplía la búsqueda para incluir los resultados que coinciden con cualquiera de los operadores en lugar de coincidir con todos ellos.

Cada elemento del campo repetido se trata de forma individual. Si el campo repetido se encuentra en los eventos de la búsqueda, estos se evalúan para cada elemento del campo. Esto puede provocar un comportamiento inesperado, en especial cuando se realizan búsquedas con el operador !=.

Cuando se usa el operador any, el predicado se evalúa como verdadero si algún valor en el campo repetido satisface la condición.

Las marcas de tiempo usan el tiempo Unix

Los campos de marca de tiempo coinciden con el tiempo Unix (cantidad de segundos que pasaron desde el jueves 1 de enero de 1970 00:00:00).

Cuando se busca una marca de tiempo específica, es válido lo siguiente (en tiempo de época):

metadata.ingested_timestamp.seconds = 1660784400

La siguiente marca de tiempo no es válida:

metadata.ingested_timestamp = "2022-08-18T01:00:00Z"

Algunos campos se excluyen de los filtros, entre los que se incluyen los siguientes:

  • metadata.id
  • metadata.product_log_id
  • *.timestamp

Dado que estos campos tienden a tener valores únicos, mostrarlos crea más "ruido" que el valor en la interfaz de UDM Search.

Forma normal conjuntiva

La búsqueda de UDM usa la forma normal conjuntiva, un enfoque de la lógica booleana que expresa fórmulas como conjunciones de cláusulas con OR o AND. Cada cláusula conectada por una conjunción (AND), debe ser literal o contener una disyunción, (OR).

Por ejemplo:

  • (A OR B) AND (C OR D)
  • (A OR B) AND (NOT C OR B)

Las cláusulas también pueden ser literales:

  • A OR B
  • A AND B

No puedes usar A OR (B AND C) de forma conjuntiva normal, pero puedes usar (A OR B) AND (A OR C).

El siguiente ejemplo generaría un error en la búsqueda de UDM:

principal.hostname = "win-server" nocase OR (principal.hostname = "win-adfs" nocase AND metadata.event_type = "NETWORK_CONNECTION")

El siguiente es un ejemplo válido en el que se usa el formato conjuntivo normal en una búsqueda de UDM:

(principal.hostname = "win-server" nocase OR principal.hostname = "win-adfs" nocase) AND (principal.hostname = "win-server" nocase OR metadata.event_type = "NETWORK_CONNECTION")

No puedes usar NOT (A OR B) de forma conjuntiva normal, pero puedes usar NOT A AND NOT B.

Los siguientes datos no son válidos:

principal.hostname = "win-server" nocase AND NOT(metadata.event_type = "PROCESS_TERMINATION" OR metadata.event_type = "USER_RESOURCE_ACCESS")

Lo siguiente es válido:

principal.hostname = "win-server" nocase AND NOT metadata.event_type = "PROCESS_TERMINATION" AND NOT metadata.event_type = "USER_RESOURCE_ACCESS"

No puedes usar A AND (B OR (C AND D)) de forma conjuntiva normal, pero puedes usar A AND (B OR C) AND (B OR D).

Los siguientes datos no son válidos:

principal.hostname = "win-server" nocase AND (metadata.event_type = "PROCESS_LAUNCH" OR (metadata.event_type = "NETWORK_CONNECTION" AND target.ip = "10.128.0.21")

Lo siguiente es válido:

principal.hostname = "win-server" nocase AND (metadata.event_type = "PROCESS_LAUNCH" OR metadata.event_type = "NETWORK_CONNECTION") AND (metadata.event_type = "PROCESS_LAUNCH" OR target.ip = "10.128.0.21")