What’s New in Google SecOps: 2026–07–06

Forum|Forum|5 days ago
July 6, 2026
0 replies
204 views

+20

matthewnichols
Community Manager

This weeks update is brought to you by Chris Martin, Google Security Specialist.

What’s New in Google SecOps for the interval June 29 through July 07, 2026

Highlights

🚀 Google SecOps has launched Security Tokens into GA, the BigQuery Advanced Export to BigQuery for E+ and GUS customers.

🔥 ✍️ Cloud Monitoring now has a 2 year look back capability in Cloud Monitoring
🔥 ✍️ Add your own remote MCP Servers with Gemini Enterprise Agent Platform
🔥 ✍️ Why we built ADK 2.0 and my favourite line from the blog post:

Before building an autonomous agent, ask if an agent is actually the right tool for the job. If you can clearly map the workflow, use determinism

What’s New in Google SecOps — July 7th, 2026

Product Updates & New Features

Google SecOps

🚀 Release Notes from Google Cloud Docs

Google SecOps announces enhanced security, compliance, performance, and coverage for its Advanced BigQuery Export feature, now available in preview for Enterprise Plus customers. [Read More]
Google SecOps has launched a new unified rules interface in public preview, consolidating custom and curated rule management with a redesigned dashboard, advanced editor, and expanded API capabilities. [Read More]
Google SecOps has launched Security Tokens, a new feature for metering the consumption of generally available security agents when invoked automatically or manually. [Read More]

SecOps SIEM

📝 Updated Docs: Investigation > Data Tables from Google Cloud Documentation

The key changes in this document involve the addition of a comprehensive section detailing limitations and risks associated with renaming or deleting data tables, particularly when using the Chronicle API or Terraform.

Renaming data tables is not supported through the platform or API.
Data tables cannot be deleted if they are referenced by a rule.
In Terraform, renaming a data table triggers a destroy and re-create operation, which will fail if the table is referenced by a rule.
Even if not referenced by a rule, renaming a table via Terraform carries significant data loss risks because active updates to the old table will be lost during the destroy/recreate process.
A recommended workaround is provided: create a new data table with the desired name, update rules to use it, and then delete the old table.

📝 Updated Docs: Agentic SOC > Security Tokens from Google Cloud Documentation

Clearer Definition of Token Consumption:

Consuming Operations: Explicitly defines that tokens are consumed by generally available security agents (invoked automatically or manually).
Non-Consuming Operations: Clearly states that assistive features (e.g., standard chat, automated summaries) and preview agents do not consume security tokens.

Introduction of Billing Model:

The document now specifies a “Commit and Overage” billing model with a global price list.

Detailed Allocation Hierarchy and Consumption Order (New Section):

A strict hierarchy for token consumption is introduced:

Complementary and included Token entitlement (Daily): Provided to Enterprise Plus and GUS, resets daily, does not roll over. Enterprise tiers do not receive this.

Paid subscription tokens (annual): Purchased tokens, valid for 12 months, do not roll over.

Overage: Only triggered after both daily complimentary and annual paid balances are exhausted.

Updated Complimentary Token Allocation Rules:

The table for daily allotment based on Annual Contract Value (ACV) remains, but new rules for tenant allocation are added:
For customers provisioned after July 1st, 2026, daily tokens go to the first tenant.
For customers provisioned before July 1st, 2026, tokens are allocated to the tenant with the highest data ingestion, with options to request re-allocation.

Specific Purchase Rules:

Explicitly states that Security Tokens cannot be purchased as a standalone product; they are add-on SKUs for specific Google SecOps subscriptions (Enterprise, Enterprise Plus, GUS).

Comprehensive Contractual Terms (New Section)

Term length: Maximum 12 months for individual token subscriptions.
Multi-year agreements: Must use annualized ramp structures, and unused ramp tokens do not roll over.
Co-termination: The token SKU contract end-date cannot exceed the primary Google SecOps deployment’s end-date.
Cloud Commitments: Can be applied, but Gemini/Vertex AI tokens cannot be directly transferred for first-party Google SecOps agents (though they can be used for custom agents on Vertex AI).

Tenant Budgets and Overage Protections (New Section):

Per-tenant activation for paid token consumption.
Built-in agent limits to prevent runaway logic.
Configurable consumption ceilings by administrators.

Token Consumption Metrics and Estimates (New Section):

Provides strategies for projecting token consumption, including a 90-day evaluation period for new deployments and pre-GA visibility for preview agents.

Trial Period Status Update:

The previous specific trial period (April 1 — June 30, 2026) has been updated to state the official trial period has ended, directing interested parties to their Google SecOps account representative.

Google SecOps Security Tokens are now GA

📝 Updated Docs: Reports > Bigquery Export from Google Cloud Docs

Expanded Feature Capabilities:

CMEK and VPC Service Controls Support: Advanced BigQuery Export is now available for customers using Customer-Managed Encryption Keys (CMEK) and is compatible with VPC Service Controls, addressing previous limitations where CMEK was not supported.
Enhanced Data Integrity and Deduplication: The feature now employs “Fine-grained DML (FGDML)” merges to ensure data integrity. This automatically updates and deduplicates records in place (including late-arriving or re-enriched events), rather than creating duplicates, and “Data integrity and deduplication” is listed as a core benefit.
Managed Security Service Provider (MSSP) Support: A significant new section details a “hub-and-spoke” model for MSSPs, allowing centralized access to multiple customer tenants’ data through dedicated APIs (ProvisionPartnerSubscription, fetchSubscriptions, revokePartnerSubscription) for programmatic management. "Seamless MSSP support" is added as a core benefit.
Built-in Compliance Features: New benefits include native support for data residency and customer-facing audit logs (Access Transparency) delivered via Federated Resource Identification Service (FRIS) to your Cloud Logging workspace.
New Mapping Tables: Two new linked datasets, entity_enum_value_to_name_mapping and udm_enum_value_to_name_mapping, are added to help translate numerical enum values into human-readable strings, improving query efficiency.
Troubleshooting for API Calls: New troubleshooting guidance is provided for API permission errors related to the MSSP features.

Key Clarifications and Refinements:

Updated Dataset Naming: The primary linked dataset name has changed from secops_linked_data to secops_linked_datalake throughout the document, including in setup instructions and query examples.
Expanded “Key Terminology”: New terms like “BYOP (Bring Your Own Project)”, “Fine-grained DML (FGDML)”, and “Managed Security Service Providers (MSSP)” are formally defined.
More Specific Deduplication Identifiers: The document now provides detailed unique identifiers for deduplication for various datasets like rule_detections and ioc_matches in the "Linked datasets" table.
Comprehensive Best Practices: New best practices emphasize using the new enum mapping tables and leveraging audit logging integration.
Extensive FAQ Section: An entirely new “Frequently asked questions” section addresses common concerns regarding backward compatibility with legacy queries, data retention, billing for backend DML updates, availability for different Google SecOps tiers, and reasons for temporary discrepancies between BigQuery data and the Google Security Operations UI.

New Limitations and Important Caveats:

SOAR Data Not Supported: Data from Google Security Operations SOAR (search_everything_db) is explicitly listed as not being supported in Advanced BigQuery Export.
Cross-Region MSSP Federation Not Supported: The hub-and-spoke MSSP model is currently limited to the same geographical region; cross-region federation is not supported.
Minor Duplicate Event Possibility: While FGDML aims for deduplication, the document now notes a remote possibility (<1%) of temporary duplicate events during edge-case ingestion windows in high-throughput streaming systems.
Late-Arriving/Re-enriched Data Delay: A new note clarifies that there can be a delay of up to 12 hours for certain late-arriving or re-enriched records to appear in the BigQuery dataset, despite the DML merges.
ingestion_metrics data will continue to be exported only to the existing Google-managed project until the feature reaches General Availability.

The Advanced BigQuery Export for SecOps E+ customers

📝 Updated Docs: Administration > Create Azure Feed from Google Cloud Docs

This new section, inserted before the “Configure the Azure feed” instructions, provides guidance for users who restrict network access to their Azure Event Hub namespace (e.g., using firewalls or private endpoints). It instructs users to allowlist Google SecOps IP addresses to ensure connectivity and data ingestion.

Two options for allowlisting are provided:

Allowlist all Google IP addresses (recommended), with a link to retrieve them from https://gstatic.com/ipranges/goog.json.
Allowlist region-specific IP addresses by contacting Google SecOps Support, noting that these IPs can change.

📝 Updated Docs: Ingestion: Cloud: Workspace To Chronicle from Google Cloud Docs

This document details significant updates to the Unified Data Model (UDM) field mappings for various Google Workspace log types, with these changes becoming effective after July 2nd, 2026.

Deprecation and Replacement of .labels Fields:

All previously deprecated about.labels, intermediary.labels, observer.labels, principal.labels, src.labels, security_result.about.labels, and target.labels fields have been removed from the explicit mapping.
For new parsers, these are now explicitly mapped to generic additional.fields key/value pairs, and users are recommended to update existing rules to use additional.fields for consistency.

Major Changes in UDM Event Type Mappings:

Many event types across applications (Chrome, G+, Data Studio, Mobile, Groups, Calendar, Chat, Drive, Keep, Google Meet, Rules, User Accounts, Login, Admin) have been refined to be more specific. For example:
Chrome DLP_EVENT changed from USER_UNCATEGORIZED to SCAN_UNCATEGORIZED.
Mobile DEVICE_COMPROMISED_EVENT changed from STATUS_UPDATE to SCAN_HOST.
Groups accept_invitation changed from USER_UNCATEGORIZED to GROUP_MODIFICATION.
Several mobile device-related events are consolidated under a new DEVICE_CONFIG_UPDATE type.
Some event types have become less specific, moving to GENERIC_EVENT or USER_UNCATEGORIZED. For instance, many gplus comment actions and some drive comment/suggestion actions now map to GENERIC_EVENT.
login security_result.action now distinguishes FAIL for login_failure instead of a generic BLOCK.

Shifts and Refinements in Field Mappings:

Ownership/Context Shifts (Principal vs. Target vs. About):
chrome DEVICE_NAME and DEVICE_PLATFORM shifted from target.asset to principal.hostname/principal.asset.
data_studio ASSET_ID/ASSET_NAME/ASSET_TYPE mappings are now consistently to target.resource fields, simplifying previous conditional logic.
google_meet product_type shifted from principal.resource to target.resource.
rules resource_recipients shifted from mapping to principal.user.email_addresses to target.user.email_addresses.
keep owner_email and rules resource_owner_email shifted from principal.user.email_addresses to about.user.email_addresses.
Increased Specificity and Promotion from additional.fields:
chrome CONTENT_HASH now maps to specific hash fields (target.file.sha256, target.file.md5, target.file.sha1) based on pattern matching, rather than a generic additional.fields.
chrome CONTENT_NAME, CONTENT_SIZE, CONTENT_TYPE now map to target.file.full_path, target.file.size, target.file.mime_type respectively, including a large lookup table for file_type.
gmail post_delivery_info.action_type is a newly added field mapped to security_result.action_details, providing granular insights into post-delivery email interactions (e.g., opened, clicked link, downloaded attachment).
Several gmail connection-related boolean flags (dkim_pass, dmarc_pass, spf_pass) were promoted from additional.fields to security_result.detection_fields.
chat external_room is promoted from additional.fields to target.group.attribute.labels.
calendar access_level and remote_ews_url are promoted from additional.fields to more specific target.resource.attribute.labels and target.url respectively.
Decreased Specificity and Demotion to additional.fields:
drive field, field_id, label, label_title now map to additional.fields instead of target.resource.attribute.labels.
gplus comment_resource_name changed from target.resource.product_object_id to additional.fields.
Many admin fields like BULK_UPLOAD_FAIL_USERS_NUMBER, EMAIL_MONITOR_DEST_EMAIL, EMAIL_EXPORT_INCLUDE_DELETED, API_SCOPES, and EMAIL_LOG_SEARCH related fields were demoted to additional.fields.
Enhanced Conditional Logic:
actor.callerType, actor.email, actor.key, actor.profileId, actor.gaiaId, actor.orgunitPath, actor.groupId now have an expanded list of event names that trigger mapping to target nouns for login/authentication-related events.
chat identifier_type now has more specific conditional logic to map identifier to principal.asset.asset_id, principal.user.phone_numbers, or principal.user.email_addresses.
Drive-Specific Structural Changes:
destination_folder_id and destination_folder_title fields are now consistently mapped to target.resource_ancestors.product_object_id and target.resource_ancestors.name, reflecting a hierarchical structure.
source_folder_id and source_folder_title similarly moved to principal.resource_ancestors fields under specific event conditions.
Admin Application Type Mappings:
admin application_name, PRODUCT_NAME, and implicit resource type mappings have been updated with more precise conditional logic and expanded event lists to better categorize events into UDM fields like target.application, CREDENTIAL, ACCESS_POLICY, or SETTING.

📝 Updated Docs: Unified Data Model: UDM Usage from Google Cloud Docs

This document has undergone several key changes, primarily introducing new UDM event types, expanding existing event type requirements, and providing concrete UDM examples for various event types.

New UDM Event Types Introduced:

FILE_UNCATEGORIZED (under File events)
REGISTRY_UNCATEGORIZED (under Registry events)
SCAN_PROCESS_BEHAVIORS (under Scan-oriented events)

New Sections for Event Type Requirements and Examples:

NETWORK_DHCP: A completely new section detailing required fields (e.g., network.application_protocol as DHCP, network.dhcp.opcode) and a UDM example.
NETWORK_DNS: A completely new section detailing required fields (e.g., network.application_protocol as DNS, network.dns.questions.name) and a UDM example.
RESOURCE Event Types: A new section grouping RESOURCE_CREATION, RESOURCE_DELETION, RESOURCE_PERMISSIONS_CHANGE, RESOURCE_READ, RESOURCE_WRITTEN, and providing a minimal UDM example.
USER_BADGE_IN: A new section with required fields (metadata, target, extensions.auth.type) and a UDM example.
FILE_MOVE, FILE_SYNC: New required fields section and a UDM example for FILE_MOVE.

Expanded Event Type Groupings and Requirements:

EMAIL_TRANSACTION requirements now also apply to EMAIL_UNCATEGORIZED.
FILE_CREATION, FILE_DELETION, FILE_MODIFICATION, FILE_READ, and FILE_OPEN requirements now also apply to FILE_UNCATEGORIZED.
MUTEX_CREATION requirements now also apply to MUTEX_UNCATEGORIZED, with an added note about principal.process being required for UDM validation.
NETWORK_CONNECTION requirements now also apply to NETWORK_FLOW, NETWORK_FTP, and NETWORK_SMTP.
REGISTRY_CREATION, REGISTRY_MODIFICATION, REGISTRY_DELETION requirements now also apply to REGISTRY_UNCATEGORIZED.

Deprecations and Warnings:

The EMAIL_URL_CLICK event type is explicitly marked as deprecated.
For SETTING event types, a note clarifies that setting resource.type is deprecated and resource.resource_type should be used instead.
A note for EMAIL_TRANSACTION specifies that about.file.hash is not an Indexed field for hash views, and network.email is not an aliasing field (requiring parser extensions for aliasing/enrichment).

Updated Field Naming Conventions in Entity Types:

References to entity.resource.type for MUTEX and RESOURCE entity-specific requirements have been updated to entity.resource.resource_type.

Clarifications and Minor Updates:

NETWORK_HTTP now explicitly lists network.http.method as a required field within the network and network.http section.
Dhcp.type enumerated values no longer include WIN_DELECTED and WIN_EXPIRED.
Numerous existing UDM examples have been updated, mostly from a Proto3 format to a more concise JSON-like structure, and some have been simplified.

📝 Updated Docs: YARA-L: Composite Detection Rules from Google Cloud Docs

The key change in this document is the addition of a detailed explanation regarding how composite rules handle time intervals and hop windows.

Composite rules now match detections and events against a time interval rather than a single point in time.
They match if the input detection time window (WindowStart to WindowEnd) overlaps with a composite hop window.
A single detection can trigger multiple alerts if its time window spans the boundary between adjacent hop windows, providing an example of this behavior with 60-minute hop windows to prevent false negatives.
The introduction of suppression windows as a mechanism to prevent boundary duplication and enforce rate-limiting (e.g., one alert per campaign per day).
A new reference to “Hop windows” for more information.

📝 Updated Docs: Administration: Create Azure Feed from Google Cloud Docs

Previously, it simply recommended setting the partition count to 40. Now, the document clarifies that you must have the Premium Tier of Azure Event Hubs in order to set more than 32 partitions. This impacts the ability to achieve the optimal scaling recommended (40 partitions).

📝 Updated Docs: Reference > Chronicle Api Feeds from Google Cloud Docs

The key change in this document is a clarification and expansion of the guidance regarding IP allowlisting for log ingestion.

Previously, the document generally recommended enabling IP allowlisting for all log types ingesting data from third-party APIs.

The updated document now specifies:

IP allowlisting is only supported for certain feed types: S3_V2, SQS_V2, Azure_Blobstore_V2, S3, SQS, Azure_Blobstore, and Azure Event Hub.
HTTPS push feeds do not require IP allowlisting as they are push-based.
Google SecOps cannot guarantee that all feeds will originate exclusively from IP addresses within a specified region.

📝 Updated Doc: Event Processing: Data Enrichment from Google Cloud Docs

The key change in this document is the addition of a new note providing important details about how Google SecOps handles entity-context data’s time-to-live (TTL) and its display in the user interface.

Google SecOps uses a five-day lookback window for entity-context data to accommodate late-arriving information.
When the entity.metadata.interval.end_time field is omitted, an implicit five-day TTL is applied to the data.
The Google SecOps user interface will display the interval.end_time as truncated to the beginning of the day after the `interval.start_time*, even though the underlying data is stored for the full five-day lookback period. An example is provided to illustrate this UI display behavior.

📝 Updated Doc: Review Alert from Google Cloud Docs

The key change in this document is the addition of a statement clarifying that mobile operating systems (iOS/Android) and mobile browsers are not supported by Google Security Operations.

SecOps SOAR

📝 Updated Doc: SOAR > Admin Tasks > Configuration > Setting The SLA from Google Cloud Docs

The key change in this document clarifies the behavior of Case SLAs specifically when they are configured based on Case Stage or Case Priority.

Case Stage SLA Behavior: If a Case SLA is tied to a specific Case Stage, its timer is active only while the case is in that stage. The SLA resets once the case transitions to a different stage.
Case Priority SLA Behavior: If a Case SLA is based on Case Priority, the SLA will reset if the case’s priority is changed.
Historical Data Preservation: Despite these resets, historical SLA data for previous stages or priorities is not lost. Users can review all historical SLA status information within the Dashboards & Reports section.

Google Threat Intelligence

🚀 Release Notes from gtidocs.readme.io

This changelog entry details updates including the integration of observed threats with Splunk, improved explainability for GTI scores, and the addition of Access Control Lists (ACLs) for private scanning. [Read More]

✍️ Google’s Continued Disruption of Malicious Residential Proxy Networks from Google Cloud Blog

Google, in coordination with the FBI and others, has taken action to disrupt the malicious NetNut (Popa) residential proxy network, continuing its efforts against such threats. [Read More]

✍️ New IDC study: The business value of Mandiant Consulting from Google Cloud Blog

A new IDC study highlights the business value of Mandiant Consulting, demonstrating how it enables security leaders to protect business growth and clearly articulate security’s worth to their boards. [Read More]

✍️ The Bear Necessities: A Look at the Drivers, Dynamics, and Applications of the Pro-Russia Influence Ecosystem from Google Cloud Blog

The article analyzes the evolution of the pro-Russia influence ecosystem, detailing its transformation from a tool of war supporting the invasion of Ukraine into a global strategic asset. [Read More]

Google Cloud

🔥 ✍️ Anomaly detection using dynamic thresholds and two-year-long alerts in Cloud Monitoring from Google Cloud Blog

Google Cloud Monitoring is introducing new features for anomaly detection, including dynamic thresholds and two-year-long lookback alerts for PromQL, to address issues with static thresholds and reduce alert fatigue [Read More]

✍️ Cloud CISO Perspectives: How Google Cloud Security uses AI internally from Google Cloud Blog

Google Cloud Security is leveraging AI internally to progress towards autonomous software development lifecycle security, as discussed in the latest Cloud CISO Perspectives. [Read More]

AI

✍️ Get started with the Claude apps gateway for Google Cloud from Google Cloud Blog

The article announces the Claude apps gateway for Google Cloud, detailing how Anthropic’s Claude Code integrates with GCP projects using specific configuration and IAM roles [Read More]

🔥 ✍️ Build agents even faster with Gemini Enterprise Agent Platform’s fully-managed, remote MCP server from Google Cloud Blog

Google is introducing the Gemini Enterprise Agent Platform, featuring a fully-managed, remote MCP server to accelerate agent development, building on a previous release of over 50 Google-managed MCP servers [Read More]

🔥 ✍️ Why we built ADK 2.0 from Google Developer Blog

The article explains the rationale and features behind ADK 2.0, encouraging developers to consider upgrading after its launch. [Read More]

✍️ Build reliable multi-agent applications with ADK Go 2.0. Discover our new graph-based workflow engine, built-in human-in-the-loop, and dynamic orchestration from Google Developer Blog

ADK Go 2.0 has been released, introducing a graph-based workflow engine, built-in human-in-the-loop, and dynamic orchestration to help developers build reliable multi-agent applications. [Read More]

Community & Events

✍️ Multi-tenancy on a single Google SecOps — Part 2: Getting Telemetry In Safely from Google Cloud Security Community

This article, part two of a four-part series, details the process of safely ingesting telemetry for multiple tenants on a single Google SecOps instance, focusing on the first isolation problem: ingestion tagging.[Read More]

✍️ Tuesday’s Tip of the Week — When Logs Don’t Parse: Writing CBN Parsers for Custom Sources from Google Cloud Security Community

This article explains the necessity of writing custom parsers (CBN Parsers) for custom log sources in Google SecOps, emphasizing that proper log parsing into UDM is critical for effective security detection, hunting, and analysis. [Read More]

✍️ Best practices for using Gemini Search in Google SecOps from Google Cloud Security Community

This article outlines best practices for leveraging Gemini Search within Google SecOps, aiming to streamline and improve the traditionally complex workflows of Security Operations Centers amidst increasing data volumes. [Read More]

3rd Party Blogs

✍️ Stop Building a 2003 SOC with AI: A Modern People & Process Framework (Part 1) from Anton Chuvakin (Medium)

The article critiques outdated approaches to integrating AI into Security Operations Centers (SOCs) and introduces the first part of a modern framework designed to improve SOC people and processes. [Read More]

✍️ From Cloud to Chaos: Defining Shared Responsibility for AI Security from Anton Chuvakin (Medium)

The article aims to define and clarify the shared responsibilities for ensuring AI security, navigating the complexities from cloud environments to potential chaotic scenarios. [Read More]

Wiz

✍️ Build AI Security Agents with Wiz MCP from Wiz Blog

Wiz is introducing Wiz MCP, a new platform designed to power AI-driven security agents and skills by providing a trusted security context [Read More]

✍️ Start Secure in the AI Era: Accelerating AI Threat Readiness with WizOS from Wiz Blog

The article highlights the critical need for AI threat readiness due to shrinking vulnerability exploitation times and introduces WizOS as a solution to accelerate the securing of AI components. [Read More]

Note, this does not appear to actually be an actual Operating System, rather it’s a pre-packaged container base image.

✍️ Bridging the Visibility Gap: A Unified Security Operating Model for Hybrid Cloud Teams from Wiz Blog

Wiz has released its Sensor Workload Scanner (WLS), extending its risk prioritization engine to on-premise environments to provide a unified security operating model for hybrid cloud teams. [Read More]

✍️ The Red Agent POV: Exploiting Broken Object-Level Authorization in an Airline GraphQL API from Wiz Blog

This article details how a ‘Red Agent’ exploited Broken Object-Level Authorization (BOLA) in an airline’s GraphQL API to expose its entire booking database within fifteen minutes. [Read More]

Platform Issues

✅ RESOLVED: Some Google SecOps customers in Europe Multi-region may experience delays with data normalization and detections from Google Cloud Status

Google SecOps customers in Europe multi-region are experiencing delays with data normalization and detections due to an ongoing issue that began on 2026–07–02 01:53 US/Pacific. [Read More]

✅ RESOLVED: Google SecOps customers may be experiencing higher than normal search latency from Google Cloud Status

Google SecOps customers are currently experiencing higher than normal search latency, an issue that began on July 1, 2026, at 14:45 PDT and is under investigation by the engineering team. [Read More]

✅ RESOLVED: A subset of Google Security Operations (SecOps) customers experienced a data freshness issue affecting Statistical Search and Dashboards from Google Cloud Status

A subset of Google Security Operations (SecOps) customers experienced a data freshness issue affecting Statistical Search and Dashboards, starting on June 30, 2026, at 02:57 US/Pacific. [Read More]