Arquitectura y flujos de datos de Google SecOps

Se admite en los siguientes sistemas operativos:

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) a menudo tienen 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 elimina la distinción heredada entre los niveles de datos activos e inactivos.

En este documento, se describen la arquitectura y los flujos de datos de Google SecOps, que abarcan la transferencia, la normalización del UDM, la detección de amenazas con 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 vinculada. Además, incorpora inteligencia contra amenazas de Google Threat Intelligence y VirusTotal, junto con funciones potenciadas por IA generativa de 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 que se basa en la infraestructura Google Cloud principal. 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: Ingieren datos de telemetría de entornos híbridos, incluidos los recopiladores locales (como el agente de BindPlane), las APIs de proveedores de servicios en la nube y los 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 los eventos con el motor de detección de YARA-L y coordina los flujos de trabajo con el motor de administración de casos de SOAR.
• Resultados: Proporciona inteligencia de seguridad práctica y estadísticas de clasificación basadas en IA a los analistas, y envía comandos de contención automatizados a los entornos objetivo 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 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. En cambio, Google SecOps retiene toda la telemetría incorporada en un estado activo y de búsqueda indexada 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 unificado (UDM) estructurado. Durante la normalización, la canalización enriquece cada evento con metadatos contextuales del gráfico de contexto de entidades.

Arquitectura de la colecció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 de 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 de la API de REST directos que transfieren datos de telemetría estructurados y no estructurados desde 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 directorios directamente desde 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 específicos de transformación de los datos sin procesar al formato del UDM.

Descripción general del esquema del modelo de datos unificado

El modelo de datos unificado (UDM) normaliza los registros de diferentes proveedores 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 registros.

Arquitectura del esquema del UDM

El UDM utiliza un esquema jerárquico con escritura segura 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 la transferencia, el nombre del producto del proveedor y el tipo de evento.
• Principal: Es la entidad actuante que inició la actividad (como el usuario, el host, la dirección IP o el proceso de origen).
• Objetivo: Es la entidad directamente afectada por la actividad (como el archivo objetivo, el host de destino o la cuenta de usuario).
• Fuente, intermediario y observador: Son los participantes secundarios de la red (como los proxies de reenvío, los firewalls o los saltos de enrutamiento) que participan en la transacción.
• Red: Atributos del protocolo de red y artefactos de transacción (incluidos los protocolos de aplicación, las consultas de DNS y los detalles de las solicitudes HTTP)
• Resultado de seguridad: Es el resultado de la acción o la gravedad que informa el dispositivo de seguridad (como ALLOWED, BLOCKED o QUARANTINED).
• Extensiones: Son 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 del UDM

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

Arquitectura de búsqueda

Google SecOps proporciona mecanismos de búsqueda potentes diseñados para diferentes flujos de trabajo de investigación. Puedes consultar la telemetría normalizada en el almacenamiento activo, realizar la correlación de patrones con registros sin procesar sin analizar o buscar datos de casos estructurados. Si deseas obtener orientación para la optimización, consulta las prácticas recomendadas para la búsqueda en el UDM.

En la siguiente tabla, se resumen las principales capacidades de búsqueda 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 el período activo de 12 meses. Permite el filtrado, las agregaciones y las correlaciones de varios campos en diferentes fuentes de registros.
Análisis de registros sin procesar	Analiza las cadenas de texto originales sin analizar de los registros transferidos. Esta capacidad admite búsquedas de expresiones regulares (regex) y subcadenas para artefactos y parámetros personalizados que no se asignan a una sintaxis específica del UDM.
Búsqueda en lenguaje natural	Usa la IA de Gemini para traducir preguntas en lenguaje natural directamente a la sintaxis formal de búsqueda de UDM, 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 anotadas dentro de la base de datos de SOAR.

Bucle de detección y respuesta ante amenazas

La arquitectura de Google SecOps crea un ciclo continuo de retroalimentación 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 del embudo de detección

El motor de detección utiliza un enfoque de embudo de varias etapas para sintetizar 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 les aplica formato de forma continua 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 de YARA-L 2.0 con estado evalúa los eventos enriquecidos en función de las reglas de comportamiento y de amenazas en ventanas de tiempo extendidas. Si deseas conocer los lineamientos para optimizar las 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 los 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.

Corrección automatizada y ciclo de retroalimentación

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

1. Evaluación continua: Flujos de telemetría del UDM enriquecidos a través del motor de detección con estado de YARA-L 2.0
2. Creación de casos y clasificación con IA: Cuando se cumple una condición de regla, Google SecOps genera una alerta y abre un caso. Un agente de clasificación y de investigación potenciado por IA ejecuta búsquedas dinámicas y consultas de inteligencia contra amenazas para evaluar los resultados.
3. Ejecución automatizada de guías: Si el triage de IA confirma un positivo verdadero, la plataforma activa guías de respuesta automatizadas (como aislar un endpoint o suspender una cuenta de usuario a través de agentes remotos). Si se clasifica como falso positivo, el caso se cierra automáticamente.
4. Ajuste continuo: Los resultados de las correcciones y los veredictos de clasificación de los analistas se retroalimentan 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 del UDM entrante con una canalización de transmisión de varias etapas para detectar anomalías de comportamiento y patrones de ataque de múltiples eventos en períodos extendidos. También puedes generar y perfeccionar 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 del UDM enriquecido ingresan en la canalización de evaluación de detección en tiempo real.
2. Filtrado (Filter): Los eventos entrantes se evalúan según los criterios de eventos de la regla (sección events). Los eventos que no coinciden se descartan, mientras que los eventos que sí coinciden pasan a la evaluación con estado.
3. Agrupación de coincidencias (Window): Los eventos de coincidencia se agrupan por claves de correlación especificadas en un período definido (que va desde segundos hasta 12 meses). El motor hace un seguimiento de varios temporizadores con estado simultáneos (TimerStart a TimerEnd) a medida que se acumulan los eventos.
4. Evaluación de la condición (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 los recuentos de eventos, los umbrales distintos o las combinaciones de datos cruzados).
5. Activación (Trigger): Si la condición se evalúa como True, el motor genera una detección, activa una alerta y abre o actualiza un caso en la capa de respuesta. Si es False, el estado se borra sin activar una alerta.

Máquina de estado 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. Funciona como un motor de organización sobre la capa de análisis para incorporar 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 las alertas relacionadas en casos unificados, ordena y filtra las colas de incidentes, asigna tareas y colabora en las 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 prediseñadas.
• Entorno de desarrollo integrado (IDE): Usa el IDE integrado basado en código para escribir secuencias de comandos de Python personalizadas, modificar integraciones de acciones existentes y depurar flujos de trabajo de automatización complejos.
• Vistas de investigación y Graph Investigator: 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 Activo, Dirección IP, Hash, Dominio y Usuario) muestran los eventos relevantes de la línea de tiempo de forma instantánea.
• Paneles e 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 integrados 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 manuales visuales y en integraciones personalizadas del IDE.

Arquitectura del agente remoto

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

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

1. Inicio de la tarea: Cuando una acción de la 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 dentro de tu entorno privado sondea continuamente la cola del publicador 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 las herramientas de seguridad internas o los 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 del publicador a través de TLS, donde se recuperan y se muestran en la vista del caso 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 infraestructura de Google Cloud . Según este modelo, sucede lo siguiente:

• Google administra lo siguiente: Seguridad física del centro de datos, infraestructura de nube subyacente, disponibilidad de la plataforma y encriptación predeterminada de datos en reposo y en tránsito.
• Tú administras: 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 arrendatario.

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, pasando por las carpetas y los proyectos, hasta tu arrendatario controlado por el 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 arrendatarios controlados por cumplimiento. Estos usuarios aplican estándares de seguridad rigurosos a través de Assured Workloads, lo que admite tanto los marcos de cumplimiento de reglamentaciones como los paquetes de protección de datos técnicos.

Marcos de cumplimiento de reglamentaciones admitidos:

• FedRAMP: Niveles de impacto moderado y alto (FEDRAMP_MODERATE, FEDRAMP_HIGH)
• Niveles de impacto del DoD: IL4 y IL5 (IL4_AND_IL5)
• Salud y finanzas: HIPAA y PCI DSS (HIPAA, PCI_DSS)

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

Residencia de los datos y transparencia de acceso

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

Paquetes de residencia y seguridad de los datos compatibles:

• Claves de encriptación administradas por el cliente (CMEK): Controla y administra las claves que se usan para encriptar los datos en reposo (CMEK_V1).
• Residencia de datos avanzada: Aplica límites regionales de residencia de datos y controles de acceso administrativo (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 cimientos reforzados de la infraestructura principal de Google:

La pila de seguridad de cuatro capas:

1. Capa de control de seguridad del cliente: Son tus controles administrativos de nivel superior, incluidos los controles de acceso basados en roles (RBAC) que se administran 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 arrendatario, encriptación predeterminada para los datos en reposo y en tránsito (TLS), y registros 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, controles biométricos de varios factores y 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 arrendatario 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 muestra 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.