Vuelve a analizar los datos históricos (repetición de registros)

Compatible con:

Esta guía está dirigida a ingenieros de seguridad y de detección que desean volver a analizar datos de registro históricos en Google Security Operations con la función de reproducción de registros. En él, se explica cómo validar una configuración activa del analizador y solicitar una tarea de reproducción de registros de backend a través de Google Cloud Support para completar los mapeos actualizados de los campos del Modelo de datos unificado (UDM) en un período de hasta 180 días de telemetría histórica. Si sigues este método, podrás aplicar analizadores prediseñados actualizados, analizadores personalizados o extensiones de analizadores a los registros sin procesar almacenados cuando las nuevas instrucciones de asignación se apliquen solo a los registros recién transferidos. La finalización correcta mejora la búsqueda histórica de amenazas y la cobertura de las reglas de detección sin necesidad de volver a ingerir manualmente los registros de los extremos de origen.

Casos de uso habituales

Volver a analizar los registros históricos aborda las siguientes situaciones operativas:

Normalización retroactiva de campos

  • Objetivo: Completar los campos del UDM recién asignados en los registros históricos después de activar una actualización del analizador prediseñado, un analizador personalizado o una extensión del analizador.
  • Valor: Mantiene la capacidad de búsqueda coherente en los datos históricos y en tiempo real sin necesidad de volver a ingerir manualmente desde los extremos de origen.

Búsqueda de amenazas en el Explorador de registros

  • Objetivo: Consultar los registros históricos con los atributos del UDM recién asignados para investigar la actividad pasada de los adversarios.
  • Valor: Acelera la respuesta ante incidentes mostrando indicadores históricos de compromiso (IOC) que antes no se habían asignado en el texto de registro sin procesar.

Evaluación histórica de reglas de detección

  • Objetivo: Evaluar las reglas de detección de YARA-L en función de los datos de registro anteriores que requieren campos específicos de UDM normalizados
  • Valor: Evita los falsos negativos cuando se evalúa la lógica de detección actualizada en función de los eventos históricos.

Terminología clave

  • Log Replay: Es el servicio de backend de Google SecOps que vuelve a procesar los registros sin procesar almacenados a través de una configuración de analizador activa para generar registros del UDM actualizados.
  • Modelo de datos unificados (UDM): Es el esquema estandarizado que utiliza Google SecOps para normalizar la telemetría de seguridad para las búsquedas, los paneles y las reglas de detección.
  • Repositorio inmutable sin procesar: Es la capa de almacenamiento subyacente que conserva los registros sin procesar originales y sin modificar para el cumplimiento, la auditoría y el nuevo análisis histórico.

Antes de comenzar

Antes de solicitar una tarea de Log Replay, confirma que cumples con los siguientes requisitos:

  • Permisos: Debes tener los siguientes permisos:

    • Ver y administrar la configuración del analizador en Google SecOps (por ejemplo, el rol de Editor de la API de Chronicle)
    • Crear casos de asistencia en la consola de Google Cloud (como el rol de editor de asistencia técnica, roles/cloudsupport.techSupportEditor)

  • Verificación del entorno: Confirma que tienes el ID de instancia del cliente de Google SecOps y el ID del proyecto Google Cloud asociado.

Limitaciones

El Registro de reproducción funciona dentro de los siguientes límites de compatibilidad:

  • Período de retención admitido: Puedes solicitar un nuevo análisis histórico de hasta 180 días (6 meses) de datos de registro históricos.
  • Se requiere un analizador activo: Log Replay solo aplica la versión del analizador activo. No puedes usar configuraciones del analizador archivadas, inactivas o de borrador.
  • Especificación del alcance: El nuevo análisis se limita a tipos de registros específicos y a marcas de tiempo de inicio y finalización definidas en formato RFC 3339 UTC.
  • Almacenamiento sin procesar inmutable: Log Replay solo regenera registros UDM normalizados. Los registros sin procesar originales permanecen sin cambios en el repositorio sin procesar inmutable.

Cómo solicitar una tarea de reproducción de registros

Completa los siguientes pasos para validar tu analizador y enviar una solicitud de Log Replay.

Valida la configuración del analizador activo

Confirma que el analizador o la extensión del analizador de destino estén activos y normalicen la telemetría en tiempo real antes de solicitar un nuevo análisis histórico.

  1. En la consola de Google SecOps, ve a Configuración de SIEM > Analizadores.

  2. Ubica el tipo de registro objetivo y verifica que el analizador compilado previamente actualizado, el analizador personalizado o la extensión del analizador tengan el estado Activo y normalicen los registros entrantes en vivo según lo esperado.

Envía el caso de asistencia

Envía un ticket de asistencia con los parámetros de alcance necesarios para que Google Cloud el equipo de asistencia pueda iniciar el trabajo de reproducción de backend.

  1. Abre un caso de asistencia con la Google Cloud consola.

  2. En la descripción del caso de asistencia, incluye los siguientes detalles:

    • Identificador de instancia: Es el ID de instancia del cliente de Google SecOps y el ID del proyecto Google Cloud asociado.
    • Tipo de registro: Es la etiqueta log_type específica que se volverá a analizar (por ejemplo, PAN_FIREWALL o <var>CUSTOM_LOG_TYPE</var>).
    • Período objetivo: Marcas de tiempo precisas de inicio y finalización en formato RFC 3339 UTC (por ejemplo, 2026-06-01T00:00:00Z a 2026-08-31T23:59:59Z), dentro del límite admitido de 180 días.
    • Detalles del analizador: La versión activa del analizador, el nombre del analizador personalizado o el ID de la extensión del analizador que se aplicará (Log Replay solo aplica la versión activa).
    • Justificación comercial: Es un breve resumen del requisito, como la normalización retroactiva de campos o la investigación de incidentes.

Ejemplos e información de referencia

Usa la plantilla de esta sección para preparar tu solicitud de asistencia.

Plantilla de solicitud de caso de asistencia

Copia y completa la siguiente plantilla cuando envíes la descripción de tu caso de asistencia:

Request type: Google SecOps Log Replay (historical re-parsing)
Customer instance ID: <YOUR_INSTANCE_ID>
Google Cloud project ID: <YOUR_PROJECT_ID>
Target log_type: <LOG_TYPE_LABEL>
Start timestamp (RFC 3339 UTC): 2026-06-01T00:00:00Z
End timestamp (RFC 3339 UTC): 2026-08-31T23:59:59Z
Active parser or extension ID: <ACTIVE_PARSER_NAME_OR_EXTENSION_ID>
Business justification: Retroactive UDM field normalization for active parser update

Soluciona problemas

En esta sección, se describen las expectativas de rendimiento y se proporcionan soluciones de autoservicio para problemas comunes de Log Replay.

Latencia y límites

Después de que el equipo de asistencia al cliente de Google Cloud inicie la tarea de Log Replay, el proceso se ejecutará de forma asíncrona en el backend. El tiempo de procesamiento depende del volumen general de registros dentro del período especificado. A medida que la tarea procesa los registros sin procesar históricos, los registros de UDM recién generados reemplazan de forma incremental los registros de UDM anteriores para ese período. No envíes solicitudes de asistencia duplicadas para el mismo tipo de registro y período mientras se ejecuta una tarea de reproducción.

Corrección de errores

Usa esta tabla para resolver problemas comunes cuando solicites o valides una tarea de Log Replay.

Problema Descripción Corregir
Se rechazó la solicitud debido a que el analizador está inactivo El analizador personalizado o la extensión del analizador solicitados tienen el estado Borrador o Pendiente. En Configuración de SIEM > Analizadores, activa la configuración del analizador, verifica que los registros en vivo se analicen según lo previsto y vuelve a enviar el caso de asistencia.
Se rechazó la solicitud debido al límite de período La marca de tiempo de inicio solicitada es anterior a 180 días. Ajusta las marcas de tiempo de inicio y finalización en la descripción de tu caso de ayuda para que se encuentren dentro del período de retención admitido de 180 días.
Faltan campos del UDM actualizados en la búsqueda Los resultados de la búsqueda del UDM para el período objetivo aún no muestran las nuevas asignaciones de campos. Espera a que la tarea de reproducción asíncrona del backend termine de procesar el período completo y verifica la sintaxis de tu búsqueda en SIEM Search.

Validación y prueba

Después de que el equipo de asistencia al cliente de Google Cloud confirme que se completó la tarea de reproducción de registros, verifica los registros de UDM actualizados en tu entorno:

  1. En la consola de Google SecOps, ve a Investigation > SIEM Search.
  2. Configura el selector de período para que coincida con las marcas de tiempo históricas de inicio y finalización de tu solicitud de repetición.
  3. Ejecuta una búsqueda de UDM que se oriente a los campos de UDM recién asignados para tu log_type y confirma que los eventos históricos muestren los atributos normalizados.

¿Necesitas más ayuda? Obtén respuestas de miembros de la comunidad y profesionales de Google SecOps.