Arquitectura y flujos de datos de Google SecOps

Compatible con:

Google secops

Los entornos de seguridad modernos generan grandes cantidades de telemetría en la infraestructura nativa de la nube, los microservicios y los extremos distribuidos. Las arquitecturas heredadas de administración de información y eventos de seguridad (SIEM) suelen tener dificultades para escalar con estos volúmenes de datos, lo que genera consultas lentas y visibilidad fragmentada.

La plataforma Google Security Operations proporciona una capa de análisis de seguridad unificada y de alto rendimiento. Se basa en la misma infraestructura que impulsa los servicios globales principales de Google, transfiere y consulta petabytes de telemetría de seguridad con una latencia inferior a un segundo y, al mismo tiempo, elimina la distinción heredada entre los niveles de datos activos y inactivos.

En este documento, se describen la arquitectura y los flujos de datos de Google SecOps, que abarcan la transferencia, la normalización de UDM, la detección de amenazas de YARA-L y la respuesta automatizada.

Convergencia de inteligencia, análisis y respuesta

Google SecOps unifica las capacidades de operaciones de seguridad que históricamente estaban separadas. Combina el análisis de SIEM y la organización, automatización y respuesta de seguridad (SOAR) en una plataforma estrechamente acoplada. Además, incorpora inteligencia contra amenazas de Google Threat Intelligence y VirusTotal, junto con capacidades de IA generativa impulsadas por Gemini directamente en los flujos de trabajo de investigación y detección.

Descripción general de la arquitectura de la plataforma

Google SecOps opera como un plano de seguridad especializado y nativo de la nube creado sobre la infraestructura principal Google Cloud . Hereda las propiedades de escalabilidad, durabilidad y rendimiento de los servicios subyacentes de Google, incluidos Spanner y Colossus.

Contexto del sistema

Google SecOps funciona como el plano operativo central de tu entorno de seguridad, ya que administra los datos en tres etapas principales:

• Entradas: Transfiere telemetría de entornos híbridos, incluidos recopiladores locales (como el agente de BindPlane), APIs de proveedores de servicios en la nube y conectores directos de software como servicio (SaaS) de terceros.
• Núcleo de procesamiento: Normaliza la telemetría sin procesar en el esquema UDM estructurado, evalúa eventos con el motor de detección de YARA-L y organiza flujos de trabajo con el motor de administración de casos de SOAR.
• Salidas: Entrega inteligencia de seguridad práctica y estadísticas de clasificación de IA a los analistas, mientras envía comandos de contención automatizados a los entornos de destino a través de APIs y agentes remotos.

En el siguiente diagrama, se ilustran el contexto del sistema y los flujos de datos.

Ventaja de la infraestructura

Una ventaja arquitectónica clave de Google SecOps es su modelo de almacenamiento activo unificado. Las arquitecturas heredadas mueven la telemetría más antigua al almacenamiento en frío, lo que ralentiza las consultas o requiere una rehidratación manual. Por el contrario, Google SecOps retiene toda la telemetría transferida en un estado activo y con capacidad de búsqueda de índice durante un máximo de 12 meses. Este diseño te permite ejecutar consultas en un año completo de datos históricos con el mismo rendimiento que si consultaras la última hora.

Canalización de recopilación y normalización de datos

Google SecOps usa una canalización de transferencia de alto rendimiento que transforma los registros sin procesar y no estructurados en el modelo de datos unificados (UDM) estructurado. Durante la normalización, la canalización enriquece cada evento con metadatos contextuales del gráfico de contexto de entidades.

Arquitectura de recopilación

La transferencia de datos se produce en tres vectores principales:

• Recopiladores: Recopiladores basados en agentes (como el agente de BindPlane o los agentes de OpenTelemetry) implementados en redes locales para agregar datos de syslog y paquetes. Los recopiladores almacenan en búfer, comprimen y encriptan la telemetría en la capa de transporte (TLS) antes de reenviarla a Google SecOps.
• APIs de transferencia: Extremos directos de la API de REST que transfieren telemetría estructurada y no estructurada de servicios en la nube, aplicaciones personalizadas y canalizaciones sin servidores.
• Integraciones de terceros: Conectores integrados basados en extracción que recuperan registros, alertas y datos de directorio directamente de plataformas SaaS externas y APIs de la nube (como Microsoft 365 o Microsoft Entra ID).

Flujo de la canalización de recopilación y preparación de datos

En el siguiente diagrama, se detallan los pasos de transformación específicos de los datos sin procesar al formato UDM.

Descripción general del esquema del modelo de datos unificados

El modelo de datos unificados (UDM) normaliza los registros de proveedores dispares en un solo esquema estructurado. Esta representación estándar simplifica el análisis y la búsqueda, ya que garantiza que las entidades equivalentes (como las direcciones IP, los nombres de usuario o los hashes de archivos) compartan rutas de campo coherentes en todas las fuentes de registro.

Arquitectura del esquema UDM

El UDM usa un esquema jerárquico y con tipos definidos para representar eventos y entidades de seguridad. Organiza los datos en las siguientes estructuras lógicas principales:

• Metadatos: Contexto sobre el evento de registro en sí, incluida la marca de tiempo del evento, la hora de transferencia, el nombre del producto del proveedor y el tipo de evento.
• Entidad principal: La entidad que actuó y que inició la actividad (como el usuario, el host, la dirección IP o el proceso de origen).
• Destino: La entidad afectada directamente por la actividad (como el archivo de destino, el host de destino o la cuenta de usuario).
• Fuente, intermediario y observador: Participantes secundarios de la red (como proxies de reenvío, firewalls o saltos de enrutamiento) involucrados en la transacción.
• Red: Atributos del protocolo de red y artefactos de transacción (incluidos protocolos de aplicación, consultas de DNS y detalles de solicitudes HTTP).
• Resultado de seguridad: La acción o el resultado de gravedad que informa el dispositivo de seguridad (como ALLOWED, BLOCKED o QUARANTINED).
• Extensiones: Campos personalizados y pares clave-valor específicos del proveedor que no se incluyen en el esquema principal estándar. Para obtener detalles sobre las definiciones de asignación y el desarrollo de analizadores, consulta Configura analizadores personalizados y Campos importantes de UDM.

Diagrama de clases de UDM

En el siguiente diagrama, se proporciona un plano estructural del UDM.

Arquitectura de búsqueda

Google SecOps proporciona mecanismos de búsqueda potentes adaptados a diferentes flujos de trabajo de investigación. Puedes consultar la telemetría normalizada en el almacenamiento activo, realizar coincidencias de patrones con registros sin procesar sin analizar o buscar datos de casos estructurados. Para obtener instrucciones de optimización, consulta Prácticas recomendadas de búsqueda de UDM.

En la siguiente tabla, se resumen las capacidades de búsqueda principales disponibles en la plataforma:

Tipo de búsqueda	Función arquitectónica
Búsqueda de UDM	Es el motor de búsqueda estructurado principal que consulta eventos de UDM normalizados e indexados en la ventana activa de 12 meses. Permite el filtrado, las agregaciones y las correlaciones de varios campos en fuentes de registro dispares.
Análisis de registros sin procesar	Analiza las cadenas de texto originales y sin analizar de los registros transferidos. Esta capacidad admite expresiones regulares (`regex`) y búsquedas de subcadenas para artefactos y parámetros personalizados que no están asignados a una sintaxis UDM específica.
Búsqueda en lenguaje natural	Usa la IA de Gemini para traducir preguntas en lenguaje natural directamente a la sintaxis de búsqueda de UDM formal, lo que acelera la creación de consultas y los flujos de trabajo de investigación.
Búsqueda de casos	Es un motor de búsqueda especializado dentro de la capa de respuesta que consulta casos de investigación, alertas, guías y metadatos de entidades anotados en la base de datos de SOAR.

Ciclo de detección de amenazas y respuesta ante ellas

La arquitectura de Google SecOps crea un ciclo de retroalimentación continuo entre el análisis de detección y la respuesta automatizada. Las reglas de detección generan alertas de alta fidelidad que activan flujos de trabajo de respuesta, mientras que los resultados de la investigación proporcionan comentarios que se usan para definir mejor y ajustar la lógica de detección futura.

Arquitectura de embudo de detección

El motor de detección usa un enfoque de embudo de varias etapas para destilar grandes volúmenes de telemetría de seguridad sin procesar en alertas de alta fidelidad:

1. Transferencia y normalización: Los registros sin procesar se transfieren y se formatean continuamente en estructuras de eventos UDM estándar.
2. Enriquecimiento: Los eventos se enriquecen de forma dinámica con asignaciones de alias, datos contextuales de activos y la inteligencia contra amenazas global de fuentes como Google Threat Intelligence.
3. Evaluación de detección: El motor con estado de YARA-L 2.0 evalúa los eventos enriquecidos en función de las reglas de comportamiento y de amenazas en períodos extendidos. Para obtener instrucciones de optimización de reglas, consulta Prácticas recomendadas de YARA-L.
4. Priorización y agrupación: Las detecciones coincidentes se agregan en alertas, se les asignan puntuaciones de riesgo dinámicas y se agrupan en casos unificados.

Al combinar los datos contextuales de activos con la inteligencia contra amenazas, esta estrategia de embudo filtra las anomalías inofensivas (lo que reduce los falsos positivos) y destaca las amenazas reales (lo que reduce los falsos negativos), lo que ayuda a tu equipo de seguridad a enfocarse en los incidentes prácticos.

Ciclo de retroalimentación y corrección automatizada

La canalización de detección y respuesta combina la evaluación de reglas con estado con la clasificación y la contención automatizadas:

1. Evaluación continua: La telemetría UDM enriquecida se transmite a través del motor de detección con estado de YARA-L 2.0.
2. Creación de casos y clasificación de IA: Cuando se cumple una condición de regla, Google SecOps genera una alerta y abre un caso. Un agente de clasificación e investigación potenciado por IA ejecuta búsquedas dinámicas y búsquedas de inteligencia contra amenazas para evaluar los resultados.
3. Ejecución automatizada de guías: Si la clasificación de IA confirma un verdadero positivo, la plataforma activa guías de respuesta automatizadas (como aislar un extremo o suspender una cuenta de usuario a través de agentes remotos). Si se clasifica como un falso positivo, el caso se cierra automáticamente.
4. Ajuste continuo: Los resultados de la corrección y los veredictos de clasificación de los analistas se vuelven a enviar para definir mejor los umbrales de detección y reducir los falsos positivos futuros.

Capa de detección de amenazas

El motor de YARA-L 2.0 evalúa la telemetría UDM entrante con una canalización de transmisión de varias etapas para detectar anomalías de comportamiento y patrones de ataque de varios eventos en períodos extendidos. También puedes generar y definir mejor reglas de YARA-L con Gemini.

El ciclo de vida de procesamiento de cada regla de YARA-L sigue cinco etapas de evaluación distintas:

1. Transferencia (Ingest): Los eventos de UDM enriquecidos ingresan a la canalización de evaluación de detección en tiempo real.
2. Filtrado (Filter): Los eventos entrantes se evalúan en función de los criterios de eventos de la regla (sección events). Los eventos que no coinciden se descartan, mientras que los eventos coincidentes pasan a la evaluación con estado.
3. Ventanas de coincidencia (Window): Los eventos coincidentes se agrupan por claves de correlación especificadas en un período definido (que va desde segundos hasta 12 meses). El motor realiza un seguimiento de varios temporizadores con estado simultáneos (TimerStart a TimerEnd) a medida que se acumulan los eventos.
4. Evaluación de condiciones (Condition): Cuando se cierra o se activa la ventana de coincidencia, el motor evalúa los requisitos de umbral y las expresiones matemáticas definidas en la sección condition de la regla (como recuentos de eventos, umbrales distintos o uniones de datos cruzados).
5. Activación (Trigger): Si la condición se evalúa como True, el motor genera una detección, lo que activa una alerta y abre o actualiza un caso en la capa de respuesta. Si es False, se borra el estado sin activar una alerta.

Máquina de estados de ejecución de reglas

En el siguiente diagrama, se ilustra el ciclo de vida de la ejecución de una regla.

Arquitectura de respuesta y ejecución remota

Google SecOps SOAR representa el pilar de respuesta de la plataforma. Opera como un motor de organización sobre la capa de análisis para transferir alertas, clasificar casos y ejecutar flujos de trabajo de respuesta automatizados.

Organización, automatización e investigación

La capa de respuesta incluye herramientas especializadas diseñadas para optimizar los flujos de trabajo del Centro de operaciones de seguridad (SOC) en la investigación, la administración de casos y la automatización de guías:

• Administración de casos: Agrupa alertas relacionadas en casos unificados, ordena y filtra colas de incidentes, asigna tareas y colabora en investigaciones con un seguimiento de auditoría completo.
• Diseñador de guías: Crea guías de respuesta automatizadas con un lienzo visual de arrastrar y soltar sin código con acciones de integración precompiladas.
• Entorno de desarrollo integrado (IDE): Usa el IDE integrado basado en código para escribir secuencias de comandos de Python personalizadas, modificar las integraciones de acciones existentes y depurar flujos de trabajo de automatización complejos.
• Vistas de investigación y explorador de gráficos: Visualiza las rutas de ataque y las relaciones entre entidades con vistas de investigación basadas en gráficos. Los resúmenes de entidades dedicados (como las vistas de activos, direcciones IP, hashes, dominios y usuarios) muestran eventos relevantes de la línea de tiempo de forma instantánea.
• Paneles y generación de informes: Realiza un seguimiento de las métricas operativas del SOC, la carga de trabajo de los analistas y el tiempo medio de respuesta (MTTR) con paneles listos para usar o widgets de informes personalizados.

Arquitectura de componentes de SOAR

En el siguiente diagrama, se ilustra cómo las alertas entrantes fluyen hacia el motor de administración de casos y activan flujos de trabajo de corrección automatizados en guías visuales e integraciones de IDE personalizadas.

Arquitectura de agentes remotos

Para ejecutar acciones de corrección en redes privadas (como centros de datos locales o nubes privadas virtuales), Google SecOps se basa en una arquitectura de agentes remotos segura y solo saliente.

Según este modelo, la plataforma Google SecOps nunca inicia conexiones entrantes a tu entorno privado:

1. Inicio de tareas: Cuando una acción de guía requiere ejecución local, Google SecOps publica la instrucción en una cola de publicadores segura alojada en Google Cloud.
2. Sondeo asíncrono: El agente remoto implementado en tu entorno privado sondea continuamente la cola de publicadores a través de una conexión saliente encriptada con TLS.
3. Ejecución local: Cuando se recupera una instrucción de tarea, el agente remoto ejecuta la acción requerida de forma local en herramientas de seguridad internas o extremos de red (como inhabilitar una cuenta o bloquear un puerto de firewall).
4. Informes de estado: Una vez completado, el agente remoto devuelve el estado de la acción y los registros de ejecución a la cola de publicadores a través de TLS, donde se recupera y se muestra en la vista de casos de SOAR.

Seguridad, cumplimiento y responsabilidad compartida

Como plataforma nativa de la nube, Google SecOps opera según un modelo de responsabilidad compartida: Google es responsable de la seguridad de la plataforma, mientras que tú eres responsable de la seguridad en la plataforma.

Modelo de responsabilidad compartida

Google SecOps hereda el diseño de seguridad principal, las capacidades de procesamiento y la arquitectura de almacenamiento de la Google Cloud infraestructura. Según este modelo:

• Google administra lo siguiente: La seguridad física del centro de datos, la infraestructura de nube subyacente, la disponibilidad de la plataforma y la encriptación predeterminada de los datos en reposo y en tránsito.
• Tú administras lo siguiente: La administración de datos, los controles de acceso y el RBAC de datos configurados a través de Identity and Access Management (IAM), las reglas de detección personalizadas y la configuración de cumplimiento del tenant.

Todos los requisitos de cumplimiento, las reglas de residencia de datos y las políticas de acceso se heredan y se aplican desde la jerarquía de tu organización a través de carpetas y proyectos hasta tu tenant controlado por cumplimiento.

Cumplimiento y preparación para empresas

Para cumplir con los estrictos requisitos reglamentarios y de administración de la organización, Google SecOps ofrece tenants controlados por cumplimiento. Estos tenants aplican estándares de seguridad rigurosos a través de Assured Workloads, que admiten marcos de cumplimiento de reglamentaciones y paquetes técnicos de protección de datos.

Marcos de cumplimiento normativo compatibles:

• FedRAMP: Niveles de impacto Moderate y High (FEDRAMP_MODERATE, FEDRAMP_HIGH)
• Niveles de impacto del Departamento de Defensa: IL4 y IL5 (IL4_AND_IL5)
• Salud y finanzas: HIPAA y PCI DSS (HIPAA, PCI_DSS)

Para implementar un tenant controlado por cumplimiento, vincula tu instancia de Google SecOps a un Google Cloud proyecto ubicado en una carpeta de Assured Workloads configurada para el paquete de control requerido.

Residencia de datos y transparencia de acceso

Google SecOps aplica un aislamiento lógico estricto del tenant y admite la Transparencia de acceso para brindarte un control verificable y visibilidad de auditoría sobre el acceso administrativo a los datos.

Paquetes de seguridad y residencia de datos compatibles:

• Claves de encriptación administradas por el cliente (CMEK): Controla y administra las claves que se usan para encriptar datos en reposo (CMEK_V1).
• Residencia de datos avanzada: Aplica límites regionales de residencia de datos y controles de acceso administrativos (DRZ_ADVANCED).
• Controles del servicio de VPC: Establece perímetros seguros y personalizados alrededor de tus recursos de seguridad en la nube con los Controles del servicio de VPC (VPC-SC).

La arquitectura de seguridad de la plataforma se basa en un modelo de herencia de cuatro capas, en el que tus controles de seguridad administrativos se basan en los fundamentos reforzados de la infraestructura principal de Google:

La pila de seguridad de cuatro capas:

1. Capa de control de seguridad del cliente: Tus controles administrativos de nivel superior, incluidos los controles de acceso basados en roles (RBAC) administrados a través de Identity and Access Management (IAM), las claves de encriptación administradas por el cliente (CMEK) y las políticas regionales de residencia de datos.
2. Capa de seguridad de la plataforma: Aislamiento lógico del tenant, encriptación predeterminada para datos en reposo y en tránsito (TLS) y registro de auditoría de Transparencia de acceso.
3. Capa de infraestructura de Google: Infraestructura principal de procesamiento y almacenamiento, incluida la administración de clústeres de Borg, el almacenamiento distribuido de Colossus y las bases de datos globales de Spanner.
4. Capa de seguridad física: Seguridad fundamental respaldada por los centros de datos empresariales de Google, los controles biométricos de varios factores y los chips de seguridad Titan personalizados (roots of trust).

Por ejemplo, cuando la Transparencia de acceso está habilitada, si un especialista de Atención al cliente o de ingeniería de Google accede a los datos de tu tenant para resolver un ticket de asistencia, debe enviar una justificación de acceso criptográfica válida. Esta solicitud de acceso se registra de forma segura y se hace visible en tus registros de auditoría casi en tiempo real.

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