La guerra de la capa semántica de los datos de seguridad: la economía del cómputo detrás de la especificación de búsqueda de Google SecOps

Un documento que te enseña a ahorrar dinero expone un cambio estructural en toda la industria

Google Security Operations (antes Chronicle) publicó un documento sobre las mejores prácticas de búsqueda en UDM. Se lee como un típico documento técnico de proveedor: habla de campos, de operadores, de ajuste de rendimiento, de solución de problemas.

Pero, al ponerlo de nuevo en contexto, este documento en realidad está diciendo algo más grande: en las plataformas modernas de operaciones de seguridad, la búsqueda ya no es una acción gratuita.

El documento advierte desde el principio: si una consulta se construye de forma inadecuada, la búsqueda consumirá una gran cantidad de recursos de cómputo, y el rendimiento variará según la escala y la complejidad de los datos en la instancia. Después, casi con el tono de un asesor de costos, enumera uno por uno los “campos de alto rendimiento”, los “campos excluidos” y “cómo acotar el rango temporal”.

Esto no es una lección de sintaxis. Es economía de cómputo. Cuando la documentación oficial de un producto de seguridad necesita dedicar una gran cantidad de espacio a enseñar a los usuarios cómo gastar menos, calcular menos y escanear menos datos, indica que la contradicción central de las operaciones de seguridad ya se ha desplazado de “¿se puede ver el ataque?” a “¿podemos permitirnos verlo?”.

Lista blanca de campos: el esquema es poder de infraestructura

La parte más informativa del documento es que ofrece una lista clara de “campos UDM de alto rendimiento” para cada tipo de escenario de consulta. Metadatos, sujeto (principal), origen, destino, red y resultados de seguridad: las seis grandes categorías de campos se enumeran una por una, y se especifica claramente que estos campos “están optimizados para una recuperación rápida”.

Esto refleja un hecho maduro pero a menudo ignorado: el modelo de datos unificado no es solo una especificación de datos; es la definición de los límites de la capacidad de consulta.

En el mundo de los registros sin procesar, en teoría se puede buscar cualquier campo, a costa de escanear toda la tabla. En el mundo de UDM, una parte de los campos está conectada al índice y a las rutas de recuperación, mientras que la otra vive en el texto original y solo se parsea cuando es necesario. Esta estratificación no es un detalle técnico, sino una apuesta de los diseñadores del producto sobre la forma en que se realizarán las investigaciones de seguridad en el futuro: consideran que lo que los investigadores realmente usan con frecuencia son nombres de host, IP, hashes de archivos, ID de proceso, identificadores de usuario, direcciones de correo electrónico, métodos HTTP y nombres de reglas de seguridad.

Esta lista en sí misma es un perfil de la “conducta de la investigación de seguridad”: la unidad atómica de la caza de amenazas moderna son los identificadores de entidades correlacionables, no el texto libre.

Para los competidores, esta lista es además un muro. Quien define los campos define también la forma de escribir las reglas de detección, el modelo mental de los analistas y el costo de migrar fuera de esta plataforma. El esquema (schema) nunca es neutral: es una forma concreta de poder de infraestructura.

Los campos excluidos deliberadamente: las aristas que deja al descubierto la economía de la computación

En la documentación hay un pasaje de rara franqueza: ciertos campos se excluyen deliberadamente de los filtros de búsqueda, incluidos metadata.id, metadata.product_log_id y todos los campos *.timestamp. La razón se expone sin rodeos: los valores únicos de estos campos generan una alta cardinalidad (high cardinality), lo que introduce varianza estadística y perjudica el rendimiento de búsqueda.

Esta frase merece leerse una y otra vez.

En el ámbito de los datos de observabilidad y seguridad, la alta cardinalidad ha sido siempre el adversario más difícil de domar en la estructura de costes. Un campo que contiene millones o incluso miles de millones de valores únicos es prácticamente imposible de indexar de forma eficiente. Los proveedores solo tienen dos opciones frente a él: o cargar con el coste y trasladarlo al usuario, o mantenerlo fuera de la capa de búsqueda rápida, haciendo que el usuario pague un precio más alto cuando lo necesite.

Google eligió la segunda, y lo dejó escrito en documentación pública. Esto significa que admitió una cosa: en una plataforma de datos de seguridad, no todos los datos nacen iguales.

Lo más sutil es que las marcas de tiempo se incluyan en esta categoría. El tiempo debería ser la primera dimensión de una investigación de seguridad, pero precisamente porque sus valores son casi infinitos, no puede usarse como una condición de coincidencia exacta con una buena relación coste-beneficio. La alternativa que ofrece la documentación es comparar segundos de Unix epoch o llamar a las funciones de tiempo de YARA-L para convertir fechas; en otras palabras, traducir el «tiempo legible por humanos» a «enteros indexables por máquinas», y que sea el usuario quien asuma ese coste de traducción.

Se trata de un compromiso de ingeniería típico y también de una elección de modelo de negocio típica.

Dos relojes: la escisión entre el tiempo del evento y el tiempo de ingesta

Otro detalle de la documentación que se pasa por alto con facilidad pero tiene profundas implicaciones es la explicación sobre «datos recién ingeridos pero con marcas de tiempo antiguas»: el intervalo de tiempo de búsqueda se basa en la marca de tiempo del evento ya parseada, no en la marca de tiempo de ingesta del registro original.

Incluso ofrece una solución: si se quieren buscar registros recién ingeridos dentro de marcas de tiempo de eventos antiguos, hay que usar la opción All time y consultar en su lugar metadata.ingested_timestamp.

Detrás de esto se repite, en el contexto de la seguridad, un viejo problema del procesamiento de flujos: la separación entre el tiempo del evento (event time) y el tiempo de procesamiento (processing time). En los sistemas distribuidos, los registros que llegan tarde, la deriva del reloj, las cachés de los proxies y la retransmisión desde dispositivos sin conexión hacen que el momento de llegada de los datos se desacople del momento en que ocurrió el evento.

Y en una investigación de seguridad, este detalle técnico determina directamente si la conclusión es correcta o incorrecta. Al reconstruir la línea temporal de una intrusión, si el analista da por sentado que la ventana de búsqueda se divide por tiempo de ingesta, podría pasar por alto por completo registros que el atacante plantó semanas antes y que no se subieron hasta hoy.El problema más profundo es: las plataformas de seguridad dividen el concepto de «tiempo» en dos campos, lo que en realidad devuelve parcialmente al usuario el control sobre la interpretación de la semántica del tiempo. Esto es a la vez flexibilidad y una transferencia de responsabilidad. Cuando la plataforma deja de decidir por ti «qué tiempo es importante», el analista tiene que responder por sí mismo una pregunta que debería corresponder a la ingeniería de datos.

La escisión entre entidades y eventos: los datos de contexto se tratan por separado

La documentación indica claramente: si se usa metadata.log_type = "..." para buscar tipos de logs de entidades o de contexto como AZURE_AD_CONTEXT, WORKSPACE_USERS, se devolverán resultados vacíos, ya que la búsqueda de UDM solo consulta registros de eventos UDM. Para acceder a estos datos, es necesario usar la sintaxis graph, a través de rutas como graph.metadata.event_metadata.log_type o graph.entity.user.email_addresses.

Este detalle revela una bifurcación en la arquitectura de datos de seguridad: los eventos (events) y las entidades (entities) se están almacenando y consultando por separado.

Los eventos son «lo que sucedió»; las entidades son «quién es quién». Durante la última década, los SIEM se han ocupado principalmente de los primeros. Pero las operaciones de seguridad modernas dependen cada vez más de las segundas: grafos de identidad, contexto de activos y perfiles de usuario. Los atacantes rara vez se exponen con un solo evento; sus rastros se dispersan entre una gran cantidad de eventos, y solo cuando los eventos se encadenan a través de las entidades emerge la anomalía.

Consultar los datos de entidades con una sintaxis completamente distinta es una señal a nivel de arquitectura: los datos de entidades no son un apéndice de los eventos, sino otra estructura de datos que requiere modelado y optimización independientes. Esto también explica por qué las consultas de grafos (graph) se están convirtiendo en una capacidad estándar de las plataformas de seguridad, y no solo en una herramienta exclusiva de la inteligencia de amenazas.

Para el ecosistema emprendedor, existe aquí una clara ventana de oportunidad: la resolución de entidades, la normalización de identidades y la alineación de entidades entre fuentes están convirtiéndose en una capa de infraestructura independiente de los SIEM.

Campos repetidos y la trampa silenciosa de any

En la documentación hay un apartado sobre los «campos repetidos», con un tono neutro, pero cuyas consecuencias no son menores. Campos como principal.ip, target.file.md5 pueden almacenar varios valores en un solo evento. Por defecto, se evalúan con el operador any: basta con que cualquier valor del campo cumpla la condición para que todo el predicado sea verdadero.El ejemplo que ofrece la documentación es muy representativo: al buscar principal.ip != "1.2.3.4", si un evento contiene tanto 1.2.3.4 como 5.6.7.8, ese evento seguirá coincidiendo. Porque 5.6.7.8 cumple la condición de “distinto de”.

Para los analistas humanos, esto es casi contraintuitivo. Para los ingenieros que construyen reglas de detección automatizadas, es una trampa que puede provocar directamente falsos positivos y falsos negativos.

Esto revela un problema más general: la semántica de los lenguajes de consulta de seguridad se está convirtiendo en una disciplina que requiere un aprendizaje especializado. Cuando el comportamiento de los operadores lógicos depende de la estructura de almacenamiento interna del modelo de datos, la ingeniería de detección ya no consiste solo en “escribir la lógica correcta”, sino en “entender cómo se evalúan las estructuras de datos subyacentes”.

Esto también explica por qué la documentación menciona específicamente que hay un límite de operadores lógicos dentro de paréntesis (169), por qué no se pueden usar expresiones regulares en campos enumerados y por qué el comportamiento del motor RE2 debe explicarse por separado. La complejidad de los lenguajes de consulta de seguridad se está acercando a la de un pequeño lenguaje de programación —y cada nuevo lenguaje da origen a una nueva especialización profesional.

Los requisitos previos de los agentes de investigación con IA están escritos en esta documentación

Si se lee esta documentación como un preludio del futuro, lo más interesante es que define, sin proponérselo, qué condiciones deben cumplirse primero para que un agente de seguridad con IA pueda funcionar.

Condición uno: el costo de las consultas debe ser predecible. Un agente de investigación que opera de forma autónoma, si cada consulta exploratoria puede desencadenar un consumo de cómputo incontrolable, nadie se atreverá a dejarlo actuar con libertad. Las listas blancas de campos, las restricciones de ventanas temporales y los campos de alta cardinalidad excluidos son, en esencia, formas de hacer que el modelo de costos sea presupuestable.

Condición dos: la semántica debe ser determinista. El comportamiento predeterminado del operador any, la evaluación elemento por elemento de los campos repetidos y la distinción entre el tiempo del evento y el tiempo de ingesta son reglas que el agente debe dominar con precisión, sin ambigüedad. Una máquina no puede eludir las trampas semánticas por intuición.

Condición tres: las interfaces deben estar estructuradas. La documentación recomienda usar listas de referencia (reference lists) en lugar de coincidencia de valores a gran escala, usar Unix epoch en lugar de cadenas de tiempo legibles por humanos y usar rutas de campos explícitas en lugar de búsqueda de texto libre —todo esto convierte la “investigación”, de una actividad humana difusa, en un conjunto de pasos deterministas que pueden ser invocados por un programa.

En otras palabras, conceptos como el SOC agéntico no consisten en que primero exista un agente y luego este se adapte a la plataforma. El orden real es exactamente el contrario: la plataforma primero organiza el modelo de datos, la semántica de consulta y los límites de costos en una forma utilizable por máquinas, y solo entonces el agente tiene un lugar donde establecerse. Esta documentación forma parte de ese trabajo preparatorio, aunque ella misma no lo diga.

La estandarización de esquemas: una competencia silenciosa pero claveSi ampliamos la perspectiva, el campo de batalla en el que se sitúa este documento es la competencia por la estandarización del esquema (schema) de datos de seguridad.

Por un lado están los esquemas propietarios de los proveedores, como el UDM de Google. Su ventaja es la optimización profunda y su estrecha integración con sus propios motores de búsqueda y detección; el costo es el costo de migración y el cierre del ecosistema. Por otro lado está la dirección de esquemas abiertos impulsada conjuntamente por la industria, cuyo objetivo es que los registros de distintas fuentes tengan una semántica de campos coherente y reducir la barrera para la colaboración entre plataformas.

Esta competencia no se presentará ante el público mediante lanzamientos de productos ni guerras de marketing. Se manifiesta en aspectos más áridos: el nombrado de campos, la lista de campos que se pueden buscar, la forma de representar las marcas de tiempo, si las entidades y los eventos están separados, la elección del motor de expresiones regulares.

Pero estos detalles determinan la realidad de la próxima generación: si las reglas de detección pueden reutilizarse entre plataformas, si la inteligencia de amenazas puede intercambiarse entre organizaciones, si los agentes de IA pueden entender datos de distintos proveedores, y cuánto margen de negociación les queda a los equipos de seguridad antes de quedar atrapados.

Conclusión: las operaciones de seguridad están pasando de ser un negocio de almacenamiento a un negocio de capa semántica

Durante los últimos veinte años, la narrativa central de SIEM ha sido «centralizar los registros». El almacenamiento era un costo y la búsqueda, una función.

Ahora esa relación se ha invertido. El almacenamiento es relativamente barato, mientras que hacer que los datos sean consultables, correlacionables y comprensibles para las máquinas es la parte verdaderamente costosa y verdaderamente valiosa.

El valor de este documento de Google SecOps no radica en la sintaxis que enseña, sino en que expone honestamente las nuevas reglas del juego: los campos tienen niveles, el tiempo es ambiguo, las consultas tienen precio y la semántica tiene límites.

Quien pueda definir estos límites no solo está vendiendo una plataforma de seguridad, sino que está definiendo la gramática de la propia investigación de seguridad. Esto merece más atención que cualquier lanzamiento de producto.

---

Origen de la información: Search best practices | Google Security Operations