CertifyDeckCargando contenido…
El temario oficial de Google Cloud Certified Professional Security Operations Engineer, organizado por dominio. Marca cada punto según lo vayas repasando.
Inicia sesión para guardar tu progreso entre sesiones.
Enhancing detection and response
Google SecOps recibe datos de Google Cloud por ingesta directa (Cloud Logging, Cloud Asset Metadata y hallazgos de Security Command Center Premium) o por Cloud Storage cuando hay que filtrar antes. Los registros Data Access conviene filtrarlos para evitar volumen sin valor, y los hallazgos de SCC no admiten filtro. Para amenazas del navegador se reenvían los registros de Chrome Management con el conector de Chrome Enterprise.
El Content Hub de Google SecOps reúne Content Packs (ingesta, detecciones seleccionadas y paneles), integraciones de respuesta, playbooks, bloques y búsquedas guardadas. Tras instalar una integración hay que configurar sus conectores, acciones y una instancia por entorno antes de usarla en un playbook. Las actualizaciones se prueban antes en el modo staging del IDE, y Dynamic Mode elige la instancia del entorno del caso.
Cada herramienta cubre un hueco distinto: Security Command Center detecta en registros (Event Threat Detection, con módulos personalizados), sin agentes (VM Threat Detection) y en tiempo de ejecución (Container y Cloud Run Threat Detection); Cloud Logging avisa con alertas basadas en registros sin pasar por el SIEM; y Google SecOps correlaciona hallazgos de SCC con otros registros mediante reglas y detecciones seleccionadas.
Threat detection in Security Command Center ↗Cloud threats ↗
La matriz MITRE ATT&CK de Google SecOps muestra la cobertura por técnica: una tarjeta con cero reglas y tipos de registro disponibles es una oportunidad de detección. Las reglas propias cuentan solo con la clave technique en sus metadatos, y el cálculo se afina por estado en vivo y de alertas. Los conjuntos Managed Detection Testing comprueban que los datos tienen el formato que esperan las detecciones seleccionadas.
Monitor threat coverage (MITRE) ↗Verify data ingestion with test rules ↗
Gemini en Google SecOps genera consultas de búsqueda y reglas YARA-L a partir de lenguaje natural, resume casos y ayuda a crear playbooks. El Triage and Investigation Agent decide si una alerta del SIEM es verdadero o falso positivo con GTI, búsquedas y árbol de procesos; no procesa alertas de conectores de SOAR. Integrado en un playbook, su veredicto y confianza permiten ramificar la respuesta.
Triage alerts with the Triage Agent ↗Embed AI agents in playbooks ↗
La búsqueda de Google SecOps usa filtros UDM y, para estadísticas, secciones match (agrupar, también por hora o día), outcome (count, count_distinct, sum, etc.), dedup, order y limit; no admite condition ni option. Los campos UDM vacíos valen cero y cuentan en count_distinct salvo que se filtren. En búsqueda los campos repetidos usan any implícito; en reglas hay que escribirlo.
Analyze search data with statistics ↗UDM search compared with Rule results ↗
Google Threat Intelligence combina veredicto (Malicious, Suspicious, Undetected, Benign) y gravedad en una puntuación de amenaza dinámica, con señales que caducan; las decisiones automáticas se basan en puntuación y veredicto, y lo sospechoso se trata como pista de búsqueda. Applied Threat Intelligence prioriza las coincidencias de IoC (Active breach, High, Medium) y los conjuntos de prioridad media se recomiendan sin alertas.
Google Threat Intelligence Indicator Score ↗Applied Threat Intelligence prioritization overview ↗
Los IOCs de Google Threat Intelligence llegan a Google SecOps por Applied Threat Intelligence, que compara campos UDM concretos (por eso importa el parser), y el Fusion Feed permite reglas YARA-L con contexto como verdict_info.pwn. Los feeds propios (MISP, STIX) se normalizan en el Entity Context Graph para coincidencia automática, y en SOAR Enrich Entities y Get Related IOCs actúan sobre las entidades del caso.
Applied Threat Intelligence curated detections ↗Integrate your own threat intelligence feeds ↗
Configuring access for human and non-human identities
Los usuarios entran en Google SecOps con Cloud Identity o Google Workspace, o con un IdP SAML u OIDC mediante Workforce Identity Federation (solo SSO iniciado por el proveedor de servicios). El servidor MCP remoto de SecOps usa OAuth 2.0 con IAM, el rol MCP Tool User y, para federados, un proveedor dedicado; los agentes de producción usan su propia identidad. La API de GTI usa claves en la cabecera x-apikey.
El acceso a funcionalidades de Google SecOps (feature RBAC) se controla con IAM en el proyecto vinculado: roles predefinidos como Chronicle API Admin, Editor, Viewer y Limited Viewer, o roles personalizados con permisos chronicle.*. Con Workforce Identity Federation se asigna google.groups y se conceden roles a principalSet de grupos. En proyectos compartidos, una condición sobre modifiedGrantsByRole limita qué roles concede un administrador.
Data RBAC limita qué datos ve cada usuario de Google SecOps mediante ámbitos formados por etiquetas (tipo de registro, namespace o etiquetas propias). El usuario con ámbito recibe Chronicle API Restricted Data Access con una condición de IAM sobre el nombre del ámbito; el acceso global prevalece. Reglas, tablas de datos y listas de referencia también se vinculan a ámbitos, y las detecciones seleccionadas solo las ven usuarios globales.
Google SecOps escribe registros de auditoría con el servicio chronicle.googleapis.com: la actividad de administración (crear reglas, actualizar feeds) siempre se registra, y para guardar las búsquedas UDM hay que activar Data Read en los registros de acceso a datos de Chronicle API. Se consultan en Logs Explorer por principalSubject y methodName; leerlos exige Private Logs Viewer y los principales exentos reducen volumen.
Las automatizaciones deben usar identidades no humanas con mínimo privilegio: una cuenta de servicio asociada al recurso o suplantada con Workload Identity (lo que recomienda la integración de Security Command Center) en vez de claves JSON; una clave de API estándar no identifica a ningún principal. En GTI se usan claves de cuentas de servicio del grupo, y el servidor MCP de SecOps exige MCP Tool User más un rol de Chronicle API.
Integrate Security Command Center with Google SecOps ↗Configure MCP ↗
Workforce Identity Federation permite iniciar sesión en Google SecOps con un IdP SAML u OIDC sin cuentas de Google. Requiere un grupo de identidades de personal dedicado a SecOps en la misma organización que el proyecto, un proveedor con asignación de atributos (google.subject y google.groups, más los de SOAR) y roles de IAM concedidos a grupos del IdP. Las condiciones de atributo limitan quién puede autenticarse.
Configure third-party identity ↗Workforce Identity Federation ↗
Practica por dominio oficial y revisa la explicación de cada respuesta.
Empezar a practicar