CertifyDeckCargando contenido…
The official Google Cloud Certified Professional Security Operations Engineer syllabus, organized by domain. Check off each point as you review it.
Inicia sesión para guardar tu progreso entre sesiones.
Enhancing detection and response
Google SecOps receives Google Cloud data through direct ingestion (Cloud Logging, Cloud Asset Metadata and Security Command Center Premium findings) or through Cloud Storage when logs must be filtered first. Data Access logs should be tuned to avoid low-value volume, and SCC findings cannot be filtered. Browser threats need Chrome Management logs from the Chrome Enterprise reporting connector.
The Google SecOps Content Hub gathers Content Packs (ingestion, curated detections and dashboards), response integrations, playbooks, blocks and saved searches. After installing an integration you configure its connectors, actions and an instance per environment before a playbook can use it. Updates are tested first in IDE staging mode, and Dynamic Mode picks the instance of the case's environment.
Each tool covers a different gap: Security Command Center detects from logs (Event Threat Detection, with custom modules), agentlessly (VM Threat Detection) and at runtime (Container and Cloud Run Threat Detection); Cloud Logging notifies with log-based alerting policies without the SIEM; and Google SecOps correlates SCC findings with other logs through rules and curated detections.
Threat detection in Security Command Center ↗Cloud threats ↗
The Google SecOps MITRE ATT&CK matrix shows coverage per technique: a card with zero rules but available log types is a detection opportunity. Custom rules count only with a technique key in their metadata, and the calculation can be refined by live and alerting status. Managed Detection Testing rule sets confirm that data has the format that curated detections expect.
Monitor threat coverage (MITRE) ↗Verify data ingestion with test rules ↗
Gemini in Google SecOps generates search queries and YARA-L rules from natural language, summarizes cases and helps build playbooks. The Triage and Investigation Agent decides whether a SIEM alert is a true or false positive using GTI, searches and process trees; it does not process SOAR connector alerts. Embedded in a playbook, its verdict and confidence drive conditional branches.
Triage alerts with the Triage Agent ↗Embed AI agents in playbooks ↗
Google SecOps search uses UDM filters and, for statistics, match (grouping, also by hour or day), outcome (count, count_distinct, sum and others), dedup, order and limit sections; it has no condition or option sections. Empty UDM fields default to zero values and count in count_distinct unless filtered. Search applies implicit any to repeated fields; rules need it written.
Analyze search data with statistics ↗UDM search compared with Rule results ↗
Google Threat Intelligence combines verdict (Malicious, Suspicious, Undetected, Benign) and severity into a dynamic threat score whose signals age off; automated decisions rely on score and verdict, and suspicious results are treated as hunting leads. Applied Threat Intelligence prioritizes IoC matches (Active breach, High, Medium), and medium-priority rule sets are recommended in non-alerting mode.
Google Threat Intelligence Indicator Score ↗Applied Threat Intelligence prioritization overview ↗
Google Threat Intelligence IOCs reach Google SecOps through Applied Threat Intelligence, which matches specific UDM fields (so parsers matter), and the Fusion Feed supports YARA-L rules with context such as verdict_info.pwn. Your own feeds (MISP, STIX) are normalized into the Entity Context Graph for automatic matching, and in SOAR Enrich Entities and Get Related IOCs work on case entities.
Applied Threat Intelligence curated detections ↗Integrate your own threat intelligence feeds ↗
Configuring access for human and non-human identities
Users sign in to Google SecOps with Cloud Identity or Google Workspace, or with a SAML or OIDC IdP through Workforce Identity Federation (SP-initiated SSO only). The SecOps remote MCP server uses OAuth 2.0 with IAM, the MCP Tool User role and, for federated users, a dedicated provider; production agents use their own identity. The GTI API uses keys in the x-apikey header.
Google SecOps feature access (feature RBAC) is controlled with IAM on the bound project: predefined roles such as Chronicle API Admin, Editor, Viewer and Limited Viewer, or custom roles with chronicle.* permissions. With Workforce Identity Federation you map google.groups and grant roles to group principalSets. In shared projects, a modifiedGrantsByRole condition limits which roles an administrator can grant.
Data RBAC limits which data each Google SecOps user sees through scopes built from labels (log type, namespace, ingestion or custom labels). A scoped user gets Chronicle API Restricted Data Access with an IAM condition on the scope name; global access overrides scoped access. Rules, data tables and reference lists are also bound to scopes, and curated detections are visible only to global users.
Google SecOps writes Cloud Audit Logs under the chronicle.googleapis.com service: Admin Activity (creating rules, updating feeds) is always recorded, and to keep UDM searches you must enable Data Read in the Chronicle API Data Access logs. Query them in Logs Explorer by principalSubject and methodName; reading Data Access logs requires Private Logs Viewer, and exempted principals reduce volume.
Automations should use least-privilege non-human identities: a service account attached to the resource or impersonated through Workload Identity (as the Security Command Center integration recommends) rather than JSON keys, because a standard API key does not identify a principal. In GTI, integrations use group service account keys, and the Google SecOps MCP server requires MCP Tool User plus a Chronicle API role.
Integrate Security Command Center with Google SecOps ↗Configure MCP ↗
Workforce Identity Federation lets users sign in to Google SecOps with a SAML or OIDC IdP without Google accounts. It needs a workforce identity pool dedicated to SecOps in the same organization as the project, a provider with attribute mapping (google.subject and google.groups, plus the SOAR attributes) and IAM roles granted to IdP groups. Attribute conditions limit who can authenticate.
Configure third-party identity ↗Workforce Identity Federation ↗