Verificar Sophos XDR Data Lake Search y exportaciones

Data Lake Search, en Security Operations > Data Lake Search, consulta los eventos y detections ingeridos en el tenant. Antes de la primera consulta se definen pregunta de investigación, fuente necesaria y ventana temporal. Un resultado vacío solo es significativo tras verificar ingestión, esquema y filtros.

Esta guía describe la interfaz Security Operations actual. Live Discover y Live Endpoint Search distinguen datos históricos y consultas directas al dispositivo, conservando los procedimientos Classic distintos. Adaptar los ejemplos QL al esquema propio, al intervalo de tiempo y a los valores reales del origen.

Elegir fuente y método de búsqueda

Antes de buscar, comprobar en Integrations > Configured Data Sources que la fuente prevista aporta datos actuales asignados al esquema necesario. Una conexión verde no basta. La aceptación de integraciones explica la diferencia.

Data Lake Search ofrece AI Search, Query Builder y Query Editor. AI Search genera una propuesta a partir de una pregunta en lenguaje natural. Revisar esquema, condiciones y periodo antes de usarla; la IA no sustituye la aceptación de la fuente. Query Builder representa visualmente condiciones y Query Editor usa Advanced Search Query Language. El icono de chincheta permite establecer el método preferido como predeterminado.

Comenzar con una fuente pequeña conocida y un periodo corto. En Query Builder elegir primero Detections o Events y después el tipo de evento para Events. En Query Editor, FROM establece el esquema. No mezclar detections y eventos en una misma consulta.

Comprender Schema Library y campos lógicos

Un esquema es una categoría estructurada de eventos, como auth, process o netflow. Schema Library muestra esquemas, campos consultables y Logical Types. No todo campo rellenado por el parser es necesariamente consultable. Validar el mapping con los campos realmente disponibles para búsqueda, no solo con otro de nombre parecido del fabricante.

Los campos lógicos con @, como @ip o @user, agrupan campos apropiados de varios esquemas. Una búsqueda multiesquema combina resultados por esquema; una condición solo afecta a los esquemas que contienen el campo. No es un join relacional. Filtrar campos de eventos en una búsqueda de detections requiere el prefijo de esquema correspondiente, como process.commandline.

La siguiente plantilla inocua muestra una búsqueda breve en el esquema de autenticación. example-user es un marcador elegido libremente que debe sustituirse por una identidad autorizada para la investigación:

FROM auth WHERE @user CONTAINS 'example-user' earliest=-1h

CONTAINS busca subcadenas, sin garantizar una coincidencia exacta de identidad. Para pruebas inequívocas de una cuenta, comprobar campo real, operador y fuente. No sumar sin revisión cuentas locales y de dominio con el mismo nombre.

Distinguir periodo, retención y límite Raw

Para Events normalizados, la ayuda de esquemas del 2 de octubre de 2026 permite como máximo 31 días por consulta. El inicio puede ser cualquier fecha dentro de los datos realmente conservados. Para investigaciones más largas usar ventanas coordinadas con límites documentados. Las detections pueden buscarse para cualquier periodo; aun así hay que verificar historial disponible y permisos.

Estos 31 días no son una retención. Next-Gen SIEM puede ofrecer conservación más larga sin permitir una consulta única ilimitada.

Para @raw y original_data, la guía SQL-QL del 15 de septiembre de 2026 describe acceso separado a los últimos 20 días. Una solicitud Raw fuera de ese alcance se rechaza, no se recorta silenciosamente. La página Query Language anterior también menciona incrementos de 20 días. No garantiza que dividir solicitudes haga disponibles datos sin procesar más antiguos. Antes de prometer pruebas Raw históricas fuera del alcance documentado debe existir una vía de producto confirmada. Esto no es retención general de 20 días ni prueba de borrado físico.

Considerar límites QL y problemas de comparación

La ayuda Query Language establece 100 Query Units en ejecución simultánea por tenant y un límite de escaneo de 10 TB por consulta. Una búsqueda puede ocupar varias Query Units; cien usuarios no reciben cien búsquedas paralelas cada uno. Acotar por ello búsquedas lógicas amplias y periodos largos. Una búsqueda fallida o limitada no equivale a cero eventos.

Las expresiones regulares de eventos usan un motor compatible con Java; las búsquedas de detections, uno basado en Lucene. No copiar ciegamente una expresión entre ambos. La resolución de hostname también es especial, con comparación literal sensible a mayúsculas y operadores limitados.

En arrays, las condiciones pueden coincidir con entradas diferentes del mismo evento. Una coincidencia de nombre y valor de cabecera no prueba, por ejemplo, que pertenezcan a la misma entrada. Si esta relación es decisiva para el hallazgo, inspeccionar individualmente los datos subyacentes.

Verificar resultados y guardar la búsqueda

Tras seleccionar el periodo ejecutar con Search o Shift + Enter. Full Screen amplía los resultados. El menú de la cabecera de columna permite filtrar, mostrar/ocultar, fijar o redimensionar campos; las columnas se ordenan arrastrándolas.

Para un hallazgo fiable, comprobar filas representativas: tenant correcto, fuente, hora del evento con zona, identidad y acción. El número de filas visibles o una detection positiva no sustituye la revisión de campos. Para una prueba fuente, comparar el evento con la evidencia original.

En AI Search y Query Editor, Save Query abre el guardado. En Query Builder elegir antes Save Search. Introducir después nombre, categoría y descripción opcional y confirmar con Save Query; Bookmark this Query añade a favoritos personales. Un nombre útil identifica propósito y fuente sin secretos ni datos personales sin procesar. Las búsquedas se registran en el historial del tenant. El texto de una consulta guardada no es un archivo permanente de resultados.

Guardar exportaciones completas antes de su caducidad

Desde Actions, encima de la tabla de resultados, exportar todo el conjunto o un subconjunto deliberado. Abrir después Security Operations > Data Exports. Verificar el estado por separado del éxito de la consulta:

• Processing: exportación aún en curso.
• Completed: archivo disponible para descarga.
• Errored: analizar el error y usar Retry en el menú de tres puntos si es apropiado para su causa.
• Cancelled: exportación cancelada, sin evidencia completa.

Los archivos se limitan a 100.000 filas por archivo. Para volúmenes mayores, dividir adecuadamente ventanas, filtros o parámetros y documentar varias solicitudes. El número y cobertura de archivos parciales deben coincidir juntos con el alcance investigado. Descargar un archivo no demuestra que una búsqueda mayor esté completa.

File Expiration muestra cuándo caduca el archivo. Antes de ese momento guardarlo mediante Download en la ubicación aprobada. No inventar un TTL universal fijo a partir de un ejemplo. Cancel detiene una exportación en curso; Delete la elimina irreversiblemente. Ninguna acción confirma que la telemetría original se haya borrado del Data Lake.

La evidencia de exportación incluye consulta, límites temporales explícitos y zona, fuentes/esquemas, alcance, estado, filas y conservación en destino. Regular antes acceso y compartición de telemetría sensible. Para un cliente propio completamente paginado, el runbook Search GraphQL explica Search-URN, fallos parciales, cursores y caducidad.

Analizar resultados inesperados

Si faltan coincidencias, revisar primero tenant, fuente, esquema, ventana y condiciones. Tras un error Raw, no asumir disponibilidad más antigua probando ventanas nuevas continuamente. Al alcanzar un límite de escaneo o concurrencia, reducir la consulta y documentar la división en lugar de iniciar reintentos incontrolados.

Si la vista previa es correcta pero una regla activa de detection o suppression reacciona de otra forma, revisar la operación actual de reglas. Los motores de streaming y suppression procesan en momentos y con límites diferentes a una búsqueda histórica.