Google SecOps recupera HTTPS Push tras fallos con tipos de log personalizados
Una actualización causó errores de validación en logs personalizados enviados por HTTPS Push a Google SecOps. Google revirtió el cambio, normalizó el tráfico nuevo y reprocesó el backlog histórico el 29 de octubre.
Google confirma que Google SecOps SIEM tuvo fallos de ingesta entre el 27 y el 29 de octubre, pero el alcance fue concreto: tipos de log personalizados enviados por feeds HTTPS Push. El panel de estado de Google Security Products sitúa el comienzo a las 10:32 PDT del día 27 y el cierre a las 13:30 PDT del 29. La compañía comunicó impacto global para esa combinación de origen y tipo de log, no una caída general de todo el SIEM.
La frontera del incidente está en el tipo de feed
En Google SecOps, un feed combina un origen de datos con un tipo de log. La documentación enumera varios orígenes que pueden empujar eventos por HTTPS, como webhooks, Pub/Sub y Amazon Data Firehose; cada uno tiene tipos de log compatibles. Por eso el aviso no debe resumirse como «SecOps dejó de recibir logs»: la incidencia se limitó a tipos personalizados que llegaban por HTTPS Push.
-InfraCrew dice: cuando una integración tiene dos ejes —origen y tipo—, el titular que dice “todo falla” suele fallar primero.-
Los tipos de log personalizados sirven para organizar datos propios del cliente que no encajan directamente en un formato estándar. El equipo define el formato y su parser para que el SIEM pueda interpretar esos eventos. En este caso, Google atribuye los errores de ingesta a una validación que empezó a fallar después de una publicación de software reciente; el panel no identifica un problema de red del cliente ni un fallo de todas las rutas de entrada.
Rollback y recuperación de la cola
Google indicó que el tráfico nuevo volvió a procesarse con normalidad el 28 de octubre a las 16:00 PDT, tras revertir la actualización a una versión estable anterior. Eso no cerró al instante la incidencia: los eventos históricos que se habían retrasado todavía estaban en cola. El estado final llegó el 29 de octubre a las 13:30 PDT, cuando Google confirmó que también había terminado de reprocesar ese backlog.
-InfraCrew dice: recuperar la entrada nueva y vaciar la cola antigua son dos hitos distintos; el panel de estado, al menos, los separó.-
La diferencia tiene peso operativo. Mientras los eventos no llegan al SIEM, las detecciones y las investigaciones que dependen de esas fuentes pueden quedarse desactualizadas; que la API vuelva a responder no devuelve automáticamente la visibilidad que faltaba. Google afirma que los datos históricos retrasados se procesaron correctamente, pero no publica cuánto tardó cada cliente en recuperar su propia ventana ni qué reglas concretas quedaron afectadas.
Qué revisar en fuentes propias
Si la organización usa tipos personalizados con HTTPS Push, conviene revisar el estado de esos feeds y confirmar que el intervalo retrasado ya aparece en las búsquedas y reglas esperadas. La documentación de Google recomienda consultar el estado de los feeds en la interfaz o revisar sus registros en Cloud Logging para analizar actividad y problemas de ingesta. El panel indicó que no hacía falta un workaround una vez aplicada la mitigación y que Google reprocesaría los datos de forma automática.
El episodio también recuerda una limitación de las señales operativas: un feed aparentemente saludable no basta para probar que el contenido está al día. En un incidente de validación, el transporte puede seguir configurado mientras el servicio rechaza una clase concreta de eventos. Para una fuente crítica, resulta útil comparar timestamps recientes del origen con los eventos indexados y dejar anotada la última hora confirmada, sin asumir que la recuperación de la plataforma cubre por igual cada tenant.
-InfraCrew dice: en un SIEM, “conectado” describe el tubo; la hora del último evento útil describe mejor el servicio.-
Google atribuyó la causa a una release, mitigó con rollback y confirmó la recuperación tanto del tráfico entrante como del retraso acumulado. El impacto fue real pero acotado a una ruta de ingesta concreta; el estado público no respalda hablar de pérdida permanente de datos ni de una caída completa de SecOps.
Diccionario de la Crew
SIEM — Plataforma que centraliza eventos de seguridad para buscarlos, correlacionarlos y detectar actividad sospechosa.
HTTPS Push — Método en que el origen envía logs a Google SecOps mediante un endpoint HTTPS.
Origen de datos — Sistema o conector que entrega eventos a un feed.
Tipo de log personalizado — Formato de eventos definido para una fuente propia y procesado con un parser correspondiente.
Backlog — Eventos acumulados que esperan procesamiento después de una interrupción o retraso.
