https://security.googlecloudcommunity.com On the Forum you can ask questions or take part in discussions. https://security.googlecloudcommunity.com/googletimondays-92/from-manual-hunts-to-autonomous-routines-introducing-agentic-flows-in-google-threat-intelligence-8260 Security operations teams are constantly searching for innovative ways to streamline threat investigations and outpace sophisticated adversaries. To address this critical challenge, Google Threat Intelligence has introduced an exciting new feature called Agentic Flows. This powerful capability is designed to transform guided agentic workflows into highly scalable, automated solutions. Built directly within the Agentic Workspace, this built-in analysis platform is specifically optimized for conversational threat investigation and triage.By combining multi-step reasoning with telemetry-grounded intelligence, Agentic Flows can automatically unpack complex scripts, decode command-and-control infrastructure, and map attacker techniques in seconds. Importantly, every single insight generated is backed by real-time Google data, complete with clear citations and transparent reasoning. Organizations can leverage Agentic Flows through three distinct automation pathways: First, the Ask Agentic option allows teams to spawn complete, interactive AI investigation sessions. Security professionals can write custom prompts or choose from pre-configured templates designed by expert analysts, scheduling them to run periodically and deliver finished reports directly to their email inbox.Second, the Saved Search feature offers hands free telemetry ingestion. It runs scheduled platform searches in the background, streaming up to ten thousand matching indicators of compromise per execution directly into an active stream without requiring manual oversight or starting active chat sessions.Third, the API option allows for on-demand programmatic execution. Teams can trigger workflows via REST endpoints during alert triage and feed structured results directly into existing tools like SIEM platforms, SOAR playbooks, or custom Python scripts. By using a zero code visual builder to chain triggers to actions, security teams can easily convert manual daily threat hunts into efficient background routines, significantly accelerating their detection and response capabilities.  Additional Resources and Links: GTI Docs:  Agentic Flows Guide #GoogleTIMondays Mon, 21 Sep 2026 20:35:21 +0200 https://security.googlecloudcommunity.com/googletimondays-92/accelerating-enterprise-defense-with-google-threat-intelligence-single-target-operations-8259 In modern cybersecurity, speed and precision are paramount. Traditional threat intelligence often waits until an adversary strikes multiple organizations before establishing a formal campaign profile. Google Threat Intelligence introduces Single Target Operations, an innovative capability that moves beyond multi-victim constraints to convert active frontline breach investigations into enterprise-wide protection in under twenty four hours.Powered by Mandiant Managed Threat Defense, Single Target Operations capture realtime, single organization intrusions with remarkable velocity. Rather than waiting days or weeks for comprehensive post-incident analysis, security operations centers gain sub twenty four hour delivery from an active frontline incident to a fully published intelligence profile. This capability also includes an instant two-year historical backfill of verified adversary missions, allowing security teams to query hundreds of live and historical investigations.What makes this feature truly impactful is its tactical depth. Defenders receive end to end attack progression, granular telemetry, raw command-line executions, and process trees mapped directly to MITRE ATT&CK techniques. Security analysts can easily trace the full lifecycle of an intrusion, from initial lure delivery and payload staging to evasive living off the land techniques and command and control (C2) beaconing. By linking discrete endpoint incidents to broader adversary infrastructure, targeted industries, and associated malware families, teams can transform isolated casework into proactive behavioral threat hunting queries.Integration with Google SecOps Enterprise+ allows curated detection rules to stream automatically into the Emerging Threats Center the moment an operation is published. Analysts investigating alerts can use one-click pivoting to inspect full threat context, verify attacker intent, and immediately determine whether an internal alert mirrors an active frontline campaign.Single Target Operations bridge the critical gap between ongoing incident response and proactive defense, empowering security teams to deploy verified detections within minutes. We encourage you to explore Single Target Operations and experience how rapidly weaponized intelligence can safeguard your enterprise.   #GoogleTIMondays Mon, 21 Sep 2026 18:50:09 +0200 https://security.googlecloudcommunity.com/googletimondays-92/streamlining-vulnerability-management-with-target-technology-watchlists-8258 Security teams today face an overwhelming volume of vulnerability disclosures, with more than twenty-five thousand common vulnerabilities and exposures emerging each year. Sifting through this relentless stream often leads to acute analyst fatigue, while critical edge zero-day threats risk being overlooked. Relying solely on generic base scoring metrics without asset visibility makes prioritizing remediation exceptionally difficult. Google Threat Intelligence introduces Target Technology Watchlists to directly address this persistent operational challenge by delivering focused, asset-matched intelligence.Target Technology Watchlists allow security professionals to define and monitor their exact technology footprint. Organizations can configure custom threat scenarios by supplying standard Common Platform Enumeration (CPE) strings or simple product names, such as Apache HTTP Server, Oracle WebLogic, or Palo Alto Networks PAN-OS. Instead of wading through irrelevant notices, teams receive alerts mapped strictly to the software and hardware components running within their enterprise environment.Beyond simple asset alignment, this capability enables precise noise reduction through granular alert thresholds. Security teams can focus their resources by filtering notices using Mandiant risk and priority scores, targeting only items rated High or Critical. Additionally, thresholds can incorporate real-time exploitation telemetry, highlighting whether a vulnerability is actively exploited in the wild, weaponized, or meeting specific score benchmarks. Incoming alerts are thoroughly enriched with actionable context, including exploit probability, attack vector analysis, and vendor patch availability.Integration is seamless and purpose-built for modern security operations. Through a unified alerts stream and REST API, incoming intelligence can be routed directly into existing SIEM, SOAR, and ticketing architectures. This programmatic ingestion empowers automated SOC workflows, allowing teams to instantly trigger patch verification tickets or implement perimeter firewall mitigation rules the moment an active exploit is detected. By moving away from generic firehoses toward precise, stack-specific awareness, organizations can significantly strengthen their overall defensive posture.   #GoogleTIMondays Mon, 21 Sep 2026 18:41:12 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/setting-the-ingestion-namespace-8220 Hi,I’m trying to build a Native Dashboard that would show the log_count and log_volume for GCP Projects but owned by different business units in the org.Also, all ingestion into SecOps is via Direct IngestUsing the below query, the namespace returns null value - which tells me the namespace must be set somewhere pre-processing:ingestion.component = "Ingestion API"$Namespace = ingestion.namespacematch: $Namespaceoutcome: $Total_GB = math.round(sum(ingestion.log_volume) / math.pow(1000, 3), 2) Please, any ideas on how to set the namespaces or perhaps other methods that would extract the project names or IDs pre-processing and can be used in a dashboard. All suggestions would be greatly appreciated. Google Security Operations Mon, 21 Sep 2026 16:49:48 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/unable-to-create-manual-case-via-soar-api-without-setting-data-access-scope-for-relevant-environment-8257 I have a workflow that requires a case be created in an environment if certain conditions are met. I was able to create a custom action to do this fine a few weeks ago, but since a new scope (also the first scope) was added in our SIEM settings, I notice the action is failing. Error: {"errorCode":2000,"errorMessage":"DataAccessScope is required.","innerException":null,"innerExceptionType":null, This new scope has nothing to do with the environment I am trying to create the case for. The environment itself does not have any scopes applied to it at all, it is ‘Global’. The Swagger docs for the CreateManualCase endpoint specify dataAccessScope should be a string, I’ve tried a selection of strings such as “*”, “Global”, “<ENVIRONMENT_NAME” etc but have had no luck. I’ve also tried not settings it obviously.  Is there a specific string I should be using here? Or should I create a new scope with access to all data? Thanks Google Security Operations Mon, 21 Sep 2026 15:27:39 +0200 https://security.googlecloudcommunity.com/what-s-new-in-secops-91/what-s-new-in-google-secops-2026-09-21-8255 What’s New in Google SecOps for the interval September 13th through September 20th, 2026. What’s New in the World of Google SecOps, September 20th 2026 Highlights 🥳 The major SecOps update this week is the release of GoogleSQL support in UDM Search. I wrote a detailed post the topic this week too.|> SQL in Google SecOpsGoogle SecOps has launched into public preview SQL support for Search 🥳medium.com Google Cloud’s hosted MCP servers now support the new Stateless MCP Protocol (Version 2026–07–28) The following global context sources MANDIANT_ACTIVE_BREACH_IOC, MANDIANT_FUSION_IOC, and OPEN_SOURCE_INTEL_IOC are replaced by the single source GTI_IOC. If you use any of these for custom rules, read about the changes and start planning accordingly. Several of the sessions from the recent Mandiant Cyber Defense Summit are available on YouTube, e.g., Cloud CISO Perspectives: How Google monitors AI threats and advances AI defenses  Product Updates & New Features Google SecOps  SecOps Release Notes from docs.cloud.google.com GoogleSQL query support in Search: This feature is in public preview. You can now use GoogleSQL in Search to query your security data in Google SecOps, offering a flexible and powerful industry-standard alternative to YARA-L 2.0. GoogleSQL is optimized for broad data exploration, statistical aggregation, and deep-dive ad hoc investigations. You can query telemetry tables including but not limited to UDM events, entity graphs, detection rules, and case management data — using either standard declarative SQL or the linear, sequential Piped SQL syntax. Read More Google SecOps parser syntax now supports the match_all option in Grok filters, enabling the extraction of all non-overlapping pattern occurrences in a field. Read More Google Chronicle is deprecating and removing the MANDIANT_ACTIVE_BREACH_IOC, MANDIANT_FUSION_IOC, and OPEN_SOURCE_INTEL_IOC feeds, in favor of the GTI_IOC feed, with removal planned for March 18, 2027.Read More Resizable side panels in the Investigation Management experience: You can now dynamically resize the Case preview and Alert and detection preview side panels in the revamped Investigation Management experience in Google SecOps. You can adjust the panel width using your mouse or keyboard shortcuts to view detailed telemetry, parsed UDM records, and raw logs without navigating away from your main case queue. Read More Updated Docs: Secops: Use Google Secops Mcp from docs.cloud.google.comNew Stateless MCP Protocol (Version 2026–07–28)This update introduces a significant change to the MCP protocol, transitioning it from a stateful, bidirectional protocol to a stateless one, effective with MCP version 2026–07–28. Key implications include: Self-describing requests: Each request is now self-contained, eliminating the need for an initialize/initialized handshake or Mcp-Session-Id. Header-based routing: Requests are routed using HTTP headers. Multi-round-trip requests (MRTR): MCP servers can now use MRTR to gather additional information. Required headers: Specific headers from the MCP specification and custom headers (mirrored from the tool’s input schema using x-mcp-header) are now mandatory for routing and processing. Transport update: The recommended transport for remote MCP servers is now Streamable HTTP Read More   MCP 2026–07–28 updates in Google Cloud’s hosted MCP  New Docs: Event Processing: Reparse Historical Data from docs.cloud.google.com This new document introduces Log Replay in Google Security Operations SIEM, a feature enabling security and detection engineers to re-process up to 180 days of historical raw log data. It outlines how to apply updated prebuilt, custom, or extended parsers to backfill Unified Data Model (UDM) field mappings. This capability improves historical threat hunting, detection rule coverage, and data consistency without requiring manual log re-ingestion. The guide details prerequisites (permissions), limitations (e.g., 180-day window, active parser only), and the process of submitting a Log Replay request via Google Cloud Support, including required information and a request template. Read More. Note, this is not an automated process as I understand it, rather this is making formal the existing process via Google Support.  New Docs: Reports: Manage Native Dashboard Charts Sankey from docs.cloud.google.com This document introduces support for Sankey charts in Google SecOps SIEM dashboards, enabling security engineers and analysts to visualize multi-hop pathways, relationships, and directional flows. Read More.   Using Sankey diagrams in Google SecOps  New Docs: API Parity Guides from docs.cloud.google.com A range of API party guides have been added covering many legacy API methods, and their replacement, e.g., Create Parser, Deactivate Parser, Get Parser, etc… Read More. New Docs: GoogleSQL Functions from docs.cloud.google.com To support the new GoogleSQL feature, a large range of documents covering all the available SQL functions is now available. Read More. New Docs: Secops: Data Encryption from docs.cloud.google.com The document provides comprehensive guidance on data encryption within Google Security Operations, detailing both default encryption at rest (AES-256) and in transit (TLS). It introduces and thoroughly explains the implementation of Customer-Managed Encryption Keys (CMEK) using Cloud KMS for enhanced data control and compliance. Read More. Updated Docs: Detection: Gti Byol from docs.cloud.google.com The documentation now highlights the ability to use ingested Google Threat Intelligence data with prebuilt curated detection rules in Google SecOps for Standard and Enterprise customers. Detailed instructions are provided on how to enable these curated rules within Google SecOps, including navigating to “Curated Detections” and activating the “Google Threat Intelligence (BYOL)” rule set. Read More.  Google Threat Intelligence  Google named a Leader in the External Threat Intelligence Service Forrester Wave from cloud.google.com Google has been recognized as a leader in the Forrester Wave for External Threat Intelligence Service, affirming its capabilities in providing high-fidelity intelligence against evolving cyber threats. Read More  BindPlane  Bindplane Agent Is Here: Build, Edit, and Understand Pipelines in Plain Language from bindplane.com Bindplane Agent has been released, providing an AI assistant within Bindplane to help users build, edit, and understand telemetry pipelines using natural language. Read More  The new Bindplane Agent  OTEL v1.108.1 from github.com This content announces the release of software version v1.108.1, indicating a preparatory or maintenance update. Read More  Google Cloud  Cloud CISO Perspectives: How Google monitors AI threats and advances AI defenses from cloud.google.com This article discusses Google’s strategies for monitoring AI threats and leveraging AI to enhance its defenses against attackers, as shared by Sandra Joyce. Read More Security in the AI Era Introducing new session management tools with native, granular controls from cloud.google.com Google Cloud is launching new session management tools, offering flexible, native, and granular controls to align with organizational security policies. Read More  Improved session management controls for Google Cloud session management  Best practices for handling cloud reliability incidents from cloud.google.com This article outlines best practices and a structured workflow (Verify > Investigate > Report > Resolve > Review) for effectively handling cloud reliability incidents and outages on Google Cloud Platform. Read More Relevant guidance for SecOps customers here on using services like Personalized Service Health and Cloud Service Health dashboard for keeping up to date on issues impacting Google Cloud and SecOps.  Google is a leader in The Forrester Wave: Public Cloud Platforms, Q3 2026 from cloud.google.com Google Cloud has been named a Leader and achieved the highest score in the ‘current offering’ category in The Forrester Wave: Public Cloud Platforms, Q3 2026 report. Read More Google also received the highest possible score in 23 out of 30 evaluation criteria, including, but not limited to vision, innovation, AI development services, database services, analytics services, containers and kubernetes services, modernization services, and security services.Impressive going to see that Google Cloud is being received by analysts has having the strongest Cloud Platform offering in 2026. Agent Anomaly Detection, now in Private Preview on the Gemini Enterprise Agent Platform from developers.googleblog.com Agent Anomaly Detection is now available in private preview on the Gemini Enterprise Agent Platform, providing an out-of-band oversight layer to detect behavioral risks, logical anomalies, and policy violations in OpenTelemetry traces and tool calls using a multi-tiered statistical and LLM-based pipeline. Read More If you’re building Agents on Gemini Enterprise this may be an interesting Private Preview to be aware of. Build zero-trust AI agents that judge intent, not just syntax from developers.googleblog.com The article details how to build zero-trust AI agents that judge intent, not just syntax, using the Gemini Enterprise Agent Platform’s dynamic runtime governance. It outlines managed defenses such as Model Armor, Semantic Governance Policies, and Agent Anomaly Detection to enhance AI security. Read More  Adoption Guides & Deep Dives  Building Custom Anomaly Detection Models with Google SecOps and BigQuery ML: Abnormal DLL Path (Part 2) from security.googlecloudcommunity.com This article, part two of a series, details building custom anomaly detection models for abnormal DLL paths using Google SecOps and BigQuery ML, following up on time-series forecasting methods discussed in part one. Read More New to Google SecOps: Building Your First Search with SQL Pipes from security.googlecloudcommunity.com Google SecOps is introducing the capability to leverage SQL for building searches, adding a new tool alongside its existing YARA-L constructs. Read More  Community & Events  Tuesday’s Tip of the Week — Three Playbook Patterns That Cover 80% of Use Cases from security.googlecloudcommunity.com This tip of the week introduces three playbook patterns, focusing on enrichment actions that use external sources like VirusTotal to help security analysts make faster, better decisions through automated read-only operations such as hash, URL, and domain lookups. Read More Adoption Guide: Scaling Incident Response with the Google SecOps Triage and Investigation Agent from security.googlecloudcommunity.com The adoption guide introduces Google SecOps’ Triage and Investigation (TIN) Agent, powered by Google Gemini, as a solution to scale incident response by moving from rigid automation to dynamic, AI-assisted reasoning in cybersecurity. Read More  3rd Party Blogs  ️ |> SQL in Google SecOps from Chris Martin (@thatsiemguy) The article discusses the application and utility of SQL within Google’s SecOps platform, likely detailing how it can be used for security operations. Read More I feel like the Gemini AI summary phoned it in there on my blog. So to expand on it a little, the GoogleSQL in SecOps private preview has been running for several months now. I’ve had this blog post parked for all that time waiting for it to go Public so I could release. I’ll likely be writing more on this topic, but GoogleSQL opens up a broad range of new functionality, and for those building Agents opens the possibility of vastly more powerful agentic capabilities too. Podcasts & YouTube Several presentations from the recent Mandiant Cyber Defense Summit are available on YouTube.Cyber Defense Summit by Google Cloud SecurityJoin me September 15-16, 2026 in Washington, D.C. for two days of in-depth insights and actionable strategies to defend…cyberdefensesummit.mandiant.com National Security, Frontline Defense: A Fireside Chat with CISA’s Nick Andersen from youtube.com In this mainstage fireside chat, Sandra Joyce (Vice President, Google Threat Intelligence) sits down with Nick Andersen (Acting Director, CISA) to discuss the critical challenges facing security leaders across both the public and private sectors — from defending at machine speed and securing frontier AI to safeguarding critical OT infrastructure and driving collective action on systemic risk. Read More AI is here. What’s our next move? from youtube.com In the agentic era, the traditional tension between development velocity and security control is evolving. As automated agents transform business operations, relying on manual security verification is no longer viable against the machine-speed of modern cyber threats. Google advocates for building durable trust through automated defenses, integrating hardware-based controls, safe coding principles, and intent-based authorization to secure intelligent applications against the rapid, AI-driven risks of the modern cybersecurity landscape. Read More Security in the AI Era from youtube.com The era of manual cyberattacks is giving way to the rise of autonomous adversary agents that operate at speeds manual security processes simply cannot match. In this presentation, Sandra Joyce, VP of Google Threat Intelligence breaks down how threat actors are leveraging AI to scale their operations and heighten attack sophistication. Beyond AI-enabled exploits, the rapid integration of AI across organizations has fundamentally altered the threat landscape, introducing critical points of failure and expanding supply chain surfaces. Read More From Breach to Lessons Learned from youtube.com Listen to incident responders for a deep dive into recent data breaches, both internal and within the supply chain. They explore how these incidents unfolded, and communication strategies used with leadership, employees, media, and the board. Learn actionable takeaways to bring back to your own security discussions. Read More The AI Advantage: Flipping the Script on Next-Generation Adversaries from youtube.com In these opening comments, Jurgen Kutscher explores how Mandiant consultants are leveraging AI to change the game for defenders and incident responders. He covers how Mandiant and Google Cloud are turning the tide by integrating hyper-scale AI directly into our tools and methodologies to stay ahead of the Threat Actors and empower our clients with machine speed defense, giving defenders the ultimate high ground. Read More  Wiz  Exploring the new AWS Sign Up experience from wiz.io The article explores AWS’s new sign-up and account access features, emphasizing the continuous need for a strong security posture beyond the initial sandbox environment. Read More Building an AI Detection Engine That Understands Agent Intent from wiz.io This article discusses the development of an AI detection engine designed to understand agent intent and uncover malicious AI behavior by analyzing model input and output logs. Read More Investing Together: Wiz Defend and Google Security Operations from wiz.io Wiz Defend and Google Security Operations are deepening their integration to help security teams work faster and more efficiently in their investigations. Read More Note, this is in effect the Wiz version of this blog post in the Google Cloud Security Community a month ago, detailing the updated SOAR Integration between Wiz and SecOps.Better Together: Integrating Wiz Defend and Google SecOps | CommunityReady for the ultimate cloud security synergy? The integration of Google SecOps and Wiz Defend is here to elevate your…security.googlecloudcommunity.com Platform Issues  ONGOING: Google SecOps customers are experiencing failures in querying Entity Context Graph for rules, search, and dashboard queries from status.cloud.google.com Google SecOps customers are experiencing failures in querying Entity Context Graph data sets, with engineering teams actively investigating the issue. Read More RESOLVED: Google SecOps customers are experiencing intermittent issues with Google managed BigQuery and BYOBQ Exports in multiregion US from status.cloud.google.com Google SecOps customers are experiencing intermittent issues with Google managed BigQuery and BYOBQ Exports in multiregion US, with the incident beginning on September 15, 2026. Read More RESOLVED: Google SecOps customers are experiencing issues with RAW log search UI in multiple regions from status.cloud.google.com Google SecOps customers are experiencing issues with RAW log search UI in multiple regions, with an incident beginning on Monday, 2026–09–14 02:03 PDT, and the engineering team is investigating. Read More RESOLVED: Some Google SecOps customers in the US multi-region may experience delays with data normalization and detections from status.cloud.google.com Google SecOps is experiencing an incident in the US multi-region, causing delays in data normalization and detections for some customers, though log ingestion continues and data is queued. Read More       What's New in SecOps Mon, 21 Sep 2026 13:56:37 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/mtta-and-mttr-7873 I'm trying to calculate mttr and mtta per environment; this metric is important for each existing environment. Does anyone know how I can do this in the case_history table?I notice that the `cases` table contains the `cases.environment` field. Is it possible to perform this calculation using that table?MMTR: stage stage1{$case_id = case_history.case_response_platform_info.case_idmatch:    $case_idoutcome:    $case_close_time = max(if(case_history.case_activity = "CLOSE_CASE", case_history.event_time.seconds, 0))    $status = array_distinct(case_history.case_activity)    $TTC = $case_close_time - min(case_history.event_time.seconds)condition:    arrays.contains($status, "CREATE_CASE") and arrays.contains($status, "CLOSE_CASE")        }outcome:    $case_count = count($stage1.case_id)    $MTTC = (math.round(avg($stage1.TTC)/60))MTTA:stage stage1{$case_id = case_history.case_response_platform_info.case_idmatch:    $case_idoutcome:    $case_assign_time = min(if(case_history.case_activity = "ASSIGNEE_CHANGE", case_history.event_time.seconds, 9999999999999999))    $status = array_distinct(case_history.case_activity)    $TTA = $case_assign_time - min(case_history.event_time.seconds)    condition:    arrays.contains($status, "CREATE_CASE") and arrays.contains($status, "ASSIGNEE_CHANGE")     }outcome:    $case_count = count($stage1.case_id)    $MTTA = (math.round((avg($stage1.TTA)/60))) Google Security Operations Mon, 21 Sep 2026 11:42:44 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/how-to-use-mandiant-active-breach-ioc-in-custom-rule-6750 Hello, I'm currently developing a custom detection rule and I'm looking to incorporate MANDIANT_ACTIVE_BREACH_IOC data into it.I would appreciate any guidance or best practices on how to effectively use this data within my rules. Specifically, how can I leverage the attributes associated with MANDIANT_ACTIVE_BREACH_IOC  for domains and how use that to enhance threat detection? Any examples or experiences would be greatly appreciated.Right now I have something like this rule for test :rule test_rule {  meta:    author          = "Test"    description     = "Mandiant IOC Feed in rule"    yara_version    = "YL2.0"  events:    $e.metadata.event_type = "NETWORK_CONNECTION"    $e.target.hostname = $ioc     $context_graph.graph.entity.hostname  = $ioc     $context_graph.graph.metadata.product_name = "MANDIANT_ACTIVE_BREACH_IOC"    $context_graph.graph.metadata.entity_type = "DOMAIN_NAME"    $context_graph.graph.metadata.source_type = "GLOBAL_CONTEXT"  match:    $ioc over 2h  outcome:    $target_hostname = array_distinct($ioc)  condition:    $e and $context_graph} Getting no results on testing this detection rule but for the same duration I can see curated ATI rule getting triggered for some domains. Google Security Operations Mon, 21 Sep 2026 11:35:48 +0200 https://security.googlecloudcommunity.com/cloud-security-foundation-7/vendor-risk-assessment-or-bank-compliance-review-documents-and-reports-8254 I’m working for vendor risk assessment or Bank compliance review for the following documents and reports. I’ve tried to access the “Compliance Reports Manager” but it seems that I have no access. Please someone advice.Google SOC2 Type II Google ISO27001 Google DPA Google Data Retention Statement Google Responsible AI Documentation Google AI Security Documentation Cloud Security Foundation Mon, 21 Sep 2026 06:31:32 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/how-to-set-alert-name-8223 I have built a custom connector and now i have alerts flowing in and now i want to customize alert name with some enriched values  how can i achieve this ? kindly help me with thisand please dont provide answers from AI  Google Security Operations Mon, 21 Sep 2026 01:12:38 +0200 https://security.googlecloudcommunity.com/cloud-security-foundation-7/webinar-9-30-codemender-ai-code-security-agent-8126 Hi all,You’ve been sleeping under a rock if you haven’t heard about the frontier AI models “hacking” their way out of sandboxes and finding vulnerabilities to break into production systems.  But how many of you are trying to reverse that playbook and use AI for defensive security to autonomously find and fix vulnerabilities in your codebase before the bad guys do?I am moderating a discussion called "CodeMender: AI Code Security Agent." We'll get straight into practical approaches to how to secure your codebase at machine-speed.We'll cover: Deep Vulnerability Scanning: Go beyond static scanning and use multiple AI models to deeply scan your codebase to uncover zero-day and n-day vulnerabilities. Exploit Simulation & Verification: Methods for running automated exploit simulations to verify which vulnerabilities are actually exploitable, drastically reducing false positives. Automated Code Remediation: How to drastically shrink the remediation bottleneck with  automated code fix testing and patching using AI. Developer-in-the-Loop: Best practices for integrating autonomous patching seamlessly into developer workflows and CI/CD pipelines. I’m keen to share what we're learning and hear your thoughts.Session Details: When: September 30, 2026, multiple regional times zones available Registration/Replay: Register Here What are the biggest challenges you're currently facing when it comes to managing code vulnerability backlogs? Hope to see you there.Cheers,Doug Cloud Security Foundation Sat, 19 Sep 2026 11:26:25 +0200 https://security.googlecloudcommunity.com/news-announcements-9/hello-cloud-security-enthusiast-introduce-yourself-5450 Hey Everyone!Welcome to the Google Cloud Security Community! We want to kick things off by getting to know each other better. This space is all about connecting, sharing, solving, and building the future of cloud security – and that journey starts with you!So, don't be shy! Drop a quick intro below and tell us:Who are you? (Your name, role, etc.) What's your cloud security superpower? (What area excites you most, or a cool project you're working on?) What are you hoping to learn or share here? (Let's help each other grow!)We're incredibly excited to learn from your unique experiences and build a vibrant hub where we can all protect, create, and innovate together.Can't wait to meet you all!Matt  News & Announcements Sat, 19 Sep 2026 10:44:14 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/issues-with-malachiteingestion-pa-googleapis-com-7015 We successfully established HTTPS log forwarding profiles within Palo Alto Strata Logging Service last year using https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate.  Although these profiles continue to forward logs to our SecOps environment, we can no longer manage the profile within Strata due to the following error that follows when testing the connection:  This wasn’t an issue when the forwarding profiles were established and it certainly wasn’t an issue the many times we made adjustments to the profiles throughout last year.  It’s probably been 4-6 months since we last touched these profiles, so it’s unclear when this behavior started. I also noticed SSL Labs is having issues obtaining detail for malachiteingestion-pa.googleapis.com.  Not sure if this is the expected behavior, but figured it was worth mentioning. I have a support case open with Palo first, but figured I’d ask here as well before opening a Google support case. Google Security Operations Fri, 18 Sep 2026 23:03:44 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/how-we-use-chronicle-yara-l-and-gemini-secops-to-catch-saas-account-takeovers-without-flooding-the-soc-8253  Here is how we combine Chronicle YARA-L correlation with Gemini SecOps to solve a tricky detection challenge:What the rule captures in Chronicle: We watch for a single user account accessing Workday from at least two completely different external networks (ASNs) and IP addresses within 30 minutes, while presenting the exact same desktop browser User-Agent. The underlying threat behavior: In Account Takeover (ATO) campaigns targeting payroll and HR systems, attackers rotate external proxies and commercial VPS nodes to evade IP-based rate limiting and geo-blocking. Because the attacker operates the same browser or automated script across those hops, their User-Agent fingerprint remains static while their IP and ASN change. Feeding distilled telemetry to Gemini: Chronicle YARA-L handles the heavy temporal matching across millions of events. Instead of dumping raw logs into an LLM, YARA-L distills the session into concise outcome variables: the distinct list of ASNs, network carrier names, IPs, and boolean flags showing whether the user only viewed information (like payslips and tax documents) or actually attempted to edit direct deposit routing details (Payment Elections). How Gemini applies contextual reasoning: Gemini receives those pre-aggregated variables and performs the semantic evaluation that static SIEM logic cannot: Network Classification: It classifies the ASNs and carriers on the fly—distinguishing between commercial VPS/hosting proxies (e.g., Linode, OVH, DigitalFyre), residential broadband (e.g., Comcast, Spectrum), and cellular networks (e.g., Verizon Wireless, AT&T Mobility). Evaluating Behavioral Intent: It compares the infrastructure type against what the user actually did. Proxy hopping combined with a WRITE to direct deposit is evaluated as Malicious. Proxy hopping that only does read-only payslip viewing (typical of an employee applying for an apartment or loan via apps like Plaid or Argyle) is evaluated as Suspicious. Switching between home Wi-Fi and a mobile phone hotspot while browsing normally is evaluated as Benign. Emitting a Clear Verdict: Gemini outputs a structured verdict (Benign, Suspicious, or Malicious) and an explanation, giving analysts an immediate, clear summary of what happened. Why Traditional SIEM Rules Struggle HereIf you build this as a standard threshold rule (e.g., alert if a user hits 2 ASNs in 30 minutes and touches Workday), you run into two major false-positive traps:Mobile Hotspots: Remote and hybrid employees constantly switch between home Wi-Fi and mobile phone cellular hotspots. This triggers multi-ASN rules all day. 3rd-Party Verification Scrapers: When employees apply for an apartment or auto loan, third-party verification platforms (such as Plaid, Argyle, or rental verification tools) spin up cloud scrapers that log in on the user's behalf to read pay stubs. The Visiting vs. Mutating Logging Nuance: In Workday user activity logs, merely browsing to an editable form logs the task name (like Payment Elections or Edit Personal Information) as a READ action, even when zero data was altered.If your rule alerts on every read, your analysts drown in false positives. If you only alert after bank details have already been modified (WRITE), you miss the attacker's initial reconnaissance phase.Pairing YARA-L with inline Gemini gives us the best of both worlds: deterministic correlation to catch the network pattern, and intelligent triage to evaluate intent.The Sanitized Chronicle YARA-L Rule(Note: DataTables your_subnets and your_asns represent your organization's public IP egress and corporate ASNs).rule workday_rapid_network_rotation_static_useragent { meta: author = "Detection Engineering" description = "Detects rapid cross-ASN external network rotation targeting Workday where the same user account authenticates across multiple distinct external ASNs within 30 minutes while presenting an identical static desktop User-Agent string." reference = "https://attack.mitre.org/techniques/T1078/004/; https://attack.mitre.org/techniques/T1090/003/" tags = "attack.initial_access, attack.t1078.004, attack.defense_evasion, attack.t1090.003, attack.persistence, attack.t1098, workday, ato, proxy_rotation" severity = "High" dataTables = "your_subnets, your_asns" rule_category = "Behavioral" events: $e.metadata.vendor_name = "Workday" $e.principal.user.userid != "" $e.principal.user.userid = $user $e.principal.ip != "" $e.principal.network.http.user_agent != "" $e.principal.network.http.user_agent = $userAgent $e.principal.ip_geo_artifact.network.asn != "" // Exclude RFC 1918 private and loopback address space not net.ip_in_range_cidr($e.principal.ip, "10.0.0.0/8") not net.ip_in_range_cidr($e.principal.ip, "172.16.0.0/12") not net.ip_in_range_cidr($e.principal.ip, "192.168.0.0/16") not net.ip_in_range_cidr($e.principal.ip, "127.0.0.0/8") // Exclude authorized corporate public IP CIDRs and corporate egress ASNs not $e.principal.ip in cidr %your_subnets.cidr not $e.principal.ip_geo_artifact.network.asn in %your_asns.asn // Desktop OS requirement and mobile device suppression $userAgent = /Windows NT|Macintosh/ nocase not $userAgent = /iPhone|Android|Mobile|iPad/ nocase match: $user, $userAgent over 30m outcome: // User & Identity Context $outcomeUserId = array_distinct($user) $outcomeUserDisplayName = array_distinct($e.principal.user.user_display_name) // Network & Cardinality Aggregation $outcomeDistinctIps = array_distinct($e.principal.ip) $outcomeIpCount = count_distinct($e.principal.ip) $outcomeAsn = array_distinct($e.principal.ip_geo_artifact.network.asn) $outcomeAsnCount = count_distinct($e.principal.ip_geo_artifact.network.asn) $outcomeCarriers = array_distinct($e.principal.ip_geo_artifact.network.carrier_name) $outcomeUserAgents = array_distinct($userAgent) // Activity & Timing $outcomeTasks = array_distinct($e.metadata.description) $outcomeProductEventTypes = array_distinct($e.metadata.product_event_type) $outcomeFirstSeen = min($e.metadata.event_timestamp.seconds) $outcomeLastSeen = max($e.metadata.event_timestamp.seconds) // High-Fidelity Boolean Flags (Computed in YARA-L) $outcomeHasPaymentElections = array_distinct( if($e.metadata.description = /Payment Elections/ nocase or $e.extracted.fieldst"taskDisplayName"] = /Payment Elections/ nocase, "true", "false") ) $outcomeHasTaxDocuments = array_distinct( if($e.metadata.description = /Tax Document|Create W-2/ nocase or $e.extracted.fieldse"taskDisplayName"] = /Tax Document|Create W-2/ nocase, "true", "false") ) $outcomeHasPayslips = array_distinct( if($e.metadata.description = /Payslip/ nocase or $e.extracted.fieldsy"taskDisplayName"] = /Payslip/ nocase, "true", "false") ) $outcomeHasWriteActivity = array_distinct( if($e.metadata.product_event_type = "WRITE" or $e.extracted.fieldsy"activityAction"] = "WRITE", "true", "false") ) condition: #e >= 2 and $outcomeAsnCount >= 2 and $outcomeIpCount >= 2} The Gemini Prompt BreakdownInside the rule metadata, we define a single-line gemini_prompt. Logically, the prompt is organized into four tasks:1. Variable Review:We point Gemini directly to the pre-aggregated outcome variables (outcomeAsn, outcomeCarriers, outcomeHasWriteActivity, outcomeHasPaymentElections, outcomeHasPayslips, etc.) so it only consumes relevant facts rather than raw event streams.2. Infrastructure Classification:Gemini classifies the observed ASNs and carriers into three buckets:Datacenter / VPS / Commercial Proxy: DigitalFyre, OVH, Linode, AWS, hosting providers. Residential Broadband: Comcast, Verizon FiOS, Charter Spectrum. Cellular / Mobile Network: Verizon Wireless, AT&T Mobility, T-Mobile.3. Decision Order:Rate as Malicious: If an active WRITE occurs on direct deposit (outcomeHasPaymentElections) or user profile data combined with cross-infrastructure proxy rotation. Rate as Suspicious: If the session rotates across Datacenter or Residential proxy networks accessing payslips or tax documents, but all activity is strictly READ-only (characteristic of 3rd-party income verification scrapers or initial attacker reconnaissance). Rate as Benign: If the rotation involves a Cellular/Mobile network (such as a laptop tethered to a phone) or transitions between consumer residential networks without any sensitive payroll or tax access.4. Structured Output Contract:We instruct Gemini to return a clean JSON object with exactly three fields: verdict, explanation, and verdict_explanation.Example Gemini OutputWhen the rule triggers on a typical income verification scraper, Gemini evaluates the outcomes and outputs:verdict: Suspiciousexplanation: The user authenticated across a residential ISP (Verizon FiOS) and a datacenter VPS (DigitalFyre) within 12 minutes using an identical Windows desktop User-Agent string. Payslips and tax forms were accessed, but all operations were read-only with no payment election changes.verdict_explanation: Activity matches the profile of an authorized third-party income verification scraper (such as a mortgage or rental verification platform) or read-only reconnaissance. Recommend confirming whether the user authorized a verification service.Real-World Triage ComparisonHere is how triage clarity changes across three common enterprise scenarios:Scenario 1: True Account TakeoverObserved Activity: 2 distinct ASNs, identical desktop User-Agent, direct deposit modified. Gemini Assessment: Malicious Analyst Impact: Immediate high-priority focus. Gemini highlights that a commercial hosting VPS was used and that an actual WRITE mutation occurred on payment elections.Scenario 2: Employee Applying for an Apartment or LoanObserved Activity: 2 distinct ASNs, identical desktop User-Agent, payslips viewed. Gemini Assessment: Suspicious Analyst Impact: Triage time is cut from 15 minutes to 30 seconds. The analyst immediately sees that a scraper accessed payslips but did not touch payment elections or make any modifications, prompting a quick user confirmation rather than a panic escalation.Scenario 3: Home Wi-Fi to Mobile Phone HotspotObserved Activity: 2 distinct ASNs, identical desktop User-Agent, general Workday navigation. Gemini Assessment: Benign Analyst Impact: The alert clearly documents that the second ASN is a major cellular carrier and no sensitive tax or payroll pages were accessed, allowing for fast, confident closure.Key Takeaways for Detection EngineersLet YARA-L do math; let Gemini do context: Don't ask an LLM to count events or compare timestamps across raw logs. Use YARA-L for high-throughput temporal matching, and pass pre-aggregated arrays to Gemini for contextual reasoning. Abstract logs into intent flags: Distill tricky SaaS logging nuances (like READ vs. WRITE actions) into explicit boolean flags inside YARA-L before the prompt runs. Keep exclusions maintainable: Use Chronicle DataTables for corporate public subnets and corporate ASNs so rules remain portable and clutter-free.How are you integrating Gemini prompts into your Chronicle detection rules? What use cases have helped your team cut through false positives? Let's discuss in the comments! Google Security Operations Fri, 18 Sep 2026 19:35:18 +0200 https://security.googlecloudcommunity.com/community-blog-42/new-to-google-secops-building-your-first-search-with-sql-pipes-8219 I’m excited to write this blog as we start a new journey to leverage SQL to build searches in Google Security Operations (SecOps). Over the past four years, search in Google SecOps has evolved from boolean logic to adding YARA-L constructs that enabled statistical searches. Along the way, we discussed functions that can be used to further enable these searches. Now, we are not going to stop discussing using YARA-L search, it’s not going anywhere, but we are going to add another tool to the toolbox that can be used in search, and soon in other parts of SecOps, which is SQL. Google SecOps now supports searching in SQL, which means that you now have the option to use YARA-L or SQL as your search syntax. This can be easily toggled in the search screen. Now you may be thinking, “this is another language that I have to learn and everything I’ve heard about SQL is that there is a very rigid structure.”  Traditional SQL does have a specific structure that looks something like this at its most basic level.select * from events where metadata.event_type = "PROCESS_LAUNCH" However, another exciting development around the SecOps use of SQL is that Google’s SQL implementation not only supports traditional SQL, it also supports the pipe syntax extension! This pipe syntax has been supported and running in Google BigQuery and Cloud Logging since the end of 2024. Pipe syntax provides users who might be more familiar with other top down languages (SPL and KQL, for instance) with a more streamlined path to adopt a new platform while providing a wealth of capabilities that Google SQL provides. Taking our admittedly very simple search above, we can transform this into a SQL pipe search like this:from events|> where metadata.event_type = "PROCESS_LAUNCH" When using SQL pipes, there are a series of supported pipe operators. The first one you are seeing in the above query is the pipe operator of WHERE. The documentation states it perfectly; each pipe operator in pipe syntax consists of the pipe symbol, |>, an operator name, and any arguments:|> operator_name argument_list Why isn’t the pipe operator prepended with just a pipe? In Google SQL, the pipe is used as a bitwise OR operator, so to remove confusion, |> is used. For those familiar with SQL, pipe operators are a collection of statements and operators that will look familiar to you in most cases. For those who have used other tools like SPL or KQL, these pipe operators would be analogous to commands, though there are fewer pipe operators with more capabilities built into each one.  Finally, for those who are familiar with YARA-L, the structures that make up a YARA-L search like the limit or order sections have comparable pipe operators, but others like the match and outcome sections do not align exactly but are components of other pipe operators, like AGGREGATE. We will get to all of this, I promise. With SQL pipe syntax, we have a logical flow that starts with a broad dataset and by applying pipe operators, we filter, aggregate and present it. This image is an over simplification because there are more than the four operations I just described but that linear flow is unlocked for users.   Let’s take a look at an example. This search will:Filter events where the principal IP is internal and connects to a target IP that isn’t in the internal netblock Generate an event count grouped by the IP address pairs and the day they occurred Using that count, determine which pairs have exceeded defined event count thresholds and tag the IP pairs as red, yellow or green Exclude the “green” IP address pairs as they are considered normal Concatenate the IP pairs into a single value and generate a count of the number of IP pairs grouped by day and color tag Add an additional column that contains the date formatted in a specific manner, i.e. Day of the Week, Month Day, Year Remove the day column as it isn’t needed in the presentation of the query and output the remaining fields in the following order; Date, Color Tag, Count, IP Address Pairs. To implement this, we can build a SQL pipe query like the one below. This query serves as a good example to highlight different pipe operators being used in concert. Just a quick tip, double dash (--) is the method to comment in SQL, so I have annotated each pipe operator below to briefly highlight what each one is doing. -- Identify the data source and work with repeated fields that will be used in the queryFROM events, unnest(principal.ip) as principal_ip, unnest(target.ip) as target_ip-- Filter the data set to just specific event types and IPs|> WHERE metadata.event_type = "NETWORK_CONNECTION" and principal_ip like "10.128.%" and target_ip not like "10.128.%" and not target_ip = "::1"-- Decide which columns we want to display and rename them if desired|> SELECT principal_ip, target_ip, metadata.event_timestamp.seconds as event_time-- Generate a statistical aggregation based on common values in the filtered events|> AGGREGATE count(*) as count group by principal_ip, target_ip, TIMESTAMP_TRUNC(TIMESTAMP_SECONDS(event_time), day, "UTC") as day-- Based on that count evaluate the value and return a string to a new column|> EXTEND case when count < 500 then "Green"      when  count > 750 then "Red"     else "Yellow" end as traffic_light-- Filter the data set to exclude rows that contain a specific string|> WHERE traffic_light <> "Green"-- Generate a statistical aggregation that includes a count and series of IP pairs based on common values and sort|> AGGREGATE count(*) as count, string_agg(concat(principal_ip, "/", target_ip)) as ip_pairs group and order by day, traffic_light-- Create a new column with a specific date format|> EXTEND format_timestamp('%A, %B %d, %Y', day, "UTC") as date_order-- Remove the day column from the result set|> DROP day-- Display the following columns|> SELECT date_order, traffic_light, count, ip_pairs This results in listing of the IP pairs that are of interest to investigate based on the thresholds defined in the query.  I won’t pretend that this is the best and only way to arrive at this output, but it does provide a method that effectively transforms the data at each pipe operator so I’m sticking with it. SQL pipe syntax provides an analyst with a method to build an initial query and then incrementally add pipe operators to the previously run query. This allows users to determine if the previous pipe operator helped advance the direction of the query and if it didn’t, it provides a very simple way to roll-back the query by removing the last pipe operator added. This capability gets even more interesting when we start to build more complex queries that can leverage additional functionality that SQL provides. Would you like to calculate a moving average or a cumulative sum? SQL can do this and SQL pipes can do this with an easy to read syntax. As you start exploring SQL in Google SecOps, here are a few things to keep in mind:Both standard SQL syntax and the SQL pipes extension are supported Google SecOps SQL pipes provides a top to bottom approach to query development Pipe operators are used to transform the data set and can be used to filter, aggregate, sort, join and much more In subsequent blogs, I’ll dive into different pipe operators and functions that you can apply to your investigations and hunts. As much as I would like to provide you with a big search in SQL and say ta-da!, that won’t help scale your abilities so we will build from the ground up. OK, I kind of did that in the example above, but that was for inspiration! Pipe operators contain a good deal of different capabilities so while I won’t be able to cover every permutation, I will call out some very cool techniques that you can apply in your daily work. I’m excited about this and hope you will come along with me on this journey! Community Blog Fri, 18 Sep 2026 16:16:57 +0200 https://security.googlecloudcommunity.com/fraud-defense-recaptcha-6/recaptcha-android-sdk-valid-tokens-score-0-0-with-empty-riskanalysis-reasons-on-a-pixel-device-8205 I'm seeing a specific Android device consistently receive floor scores from reCAPTCHA Enterprise, and I can't find any signal that explains why. Looking for anyone who has seen this pattern or knows what an assessment with score: 0 and no reason codes indicates for the mobile SDK.What I observe on one device (Pixel 9 Pro, Android 17, stock, bootloader locked, verified boot green)Android SDK com.google.android.recaptcha:recaptcha:18.9.2, app installed from Google Play. Every assessment comes back like this:tokenProperties: valid: true, action matches expectedAction, clientSignalsFailed: falseriskAnalysis: score: 0, reasons: [], extendedVerdictReasons: []- 12 attempts over two days: eleven scored 0.0, one scored 0.1. Never a reason code.- Persists across two networks (Wi-Fi and mobile data), across an app-process restart with a fresh client and fresh token, and across a device reboot.- The SDK reports no error — executeTask succeeds every time, so the app has nothing to react to.- In logcat the SDK's Play Integrity exchange (StandardIntegrity: requestExpressIntegrityToken → onRequestExpressIntegrityToken) completes normally in under 100 ms.Controls that pass, same account, same network, same minute- Web reCAPTCHA in the browser on the same Pixel 9 Pro.- The same app build on a Pixel 5 (Android 14): login succeeds.- A sideloaded (non-Play-signed) build of the app on the Pixel 9 Pro gets score: 0 with UNEXPECTED_ENVIRONMENT — so environment detection is clearly working; the Play build's reason-less zeros are the anomaly.Not just my deviceFrom the logs I can see the same shape — valid token, score 0, empty reasons — recurring on other users' devices too, mostly Pixels and Samsung Galaxy S-series, typically as a run of identical results from one device.Questions1. For the mobile SDK, what does score: 0 with an empty reasons list mean? Is it "no device signal / attestation unavailable" as opposed to a genuine high-risk verdict? The interpretation docs only cover the named reasons.2. Is a Play services / DroidGuard / Play Integrity token-provider state known to cause this on certified devices, and is there any client-side way to detect or recover from it (re-fetching the client and rebooting did not help)?3. Is there a recommended server-side way to distinguish this shape from real abuse so it can be routed to a step-up rather than a hard block?  Fraud Defense (reCAPTCHA) Fri, 18 Sep 2026 13:48:03 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/servicenow-and-google-secops-sync-8235 Hi everyone,I am attempting to set up ServiceNow CMS as our ITSM for ticket management, and I am wanting to implement a sort of polling in Google SecOps to check if any updates have been made to the ServiceNow case.I am not too concerned with comments being added to the case wall in SecOps, but I am more interested in the ServiceNow case status (Open, Closed, Assigned,) being reflected in Google SecOps.Has anyone done something similar and what worked for you? Thanks, Google Security Operations Fri, 18 Sep 2026 02:57:23 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/gcp-secops-ingestion-filter-change-update-activity-detection-8240 Hi Team,I have below ingestion filter in GCP which is applied to logs sent out to secops someone changed the filter but i am not able to search for log for the same to identify who updated / changed the filter is there a way to get that details from gcp log explorer or any where else   Google Security Operations Thu, 17 Sep 2026 22:22:23 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/office-365-parser-extension-to-extract-array-of-mail-ids-from-internetmessageid-8249 Hi Team,We have a sample log where the internetmessageID field is being mapped to network.email.mail_id in UDM. We need to create an array for this field using a parser extension.As I am new to parser development, could someone please guide me on how to implement this or share an example if available?Thanks in advance for your help. Google Security Operations Thu, 17 Sep 2026 22:03:11 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/help-with-mapping-multiple-values-to-a-single-udm-field-to-create-an-array-that-can-be-queried-913 I need to map specifically internet message ids from the Office 365 logs. Issue is in the mailitemsaccess logs that are bind events, multiple internet message ids can be captured within a single json path. I need to be able to iterate through and grap all the internet message IDs and map them to say additional.fields["InternetMessageIDs"]. Sometimes there can be up to 10 IDs within one log. I would like for them to be captured as additional.fields["InternetMessageIDs[0]"] or something similar when I use the extract function built in. It will only grab the first 5 IDs though so it has a limitation. Example of how it captures the data.extracted.fields["Folders[0].FolderItems[0].InternetMessageId"]extracted.fields["Folders[0].FolderItems[1].InternetMessageId"]extracted.fields["Folders[0].FolderItems[2].InternetMessageId"]and so on.Not really sure of where to start on this as I have created basic extensions but nothing this complicated. Google support has not been that great a help with this either so far hence why I am trying to tackle this myself. Google Security Operations Thu, 17 Sep 2026 21:55:16 +0200 https://security.googlecloudcommunity.com/security-validation-5/gcp-cloud-ngfw-issued-tls-certificates-don-t-have-akid-extension-8236 We noticed that the GCP Cloud NGFW Enterprise endpoints issue impersonation certificates without AKID extension. This violates https://datatracker.ietf.org/doc/html/rfc5280#section-4.2.1.1While Cloud NGFW is claimed to be powered by Palo Alto networks (https://www.paloaltonetworks.com/blog/2024/04/google-cloud-ngfw-enterprise/), we see the Palo Alto Firewall exhibit the RFC compliant behaviour. What does this break?Python 3.13, https://docs.python.org/3/library/ssl.html#ssl.create_default_context. Although we can work around this problem by disabling strict checks, it would be prudent for GCP to address this gap on priority in the interest of a long term solution. Steps to reproduce:Python 3.13.15 (main, Aug 6 2026, 11:06:22) [GCC 13.3.0] on linuxType "help", "copyright", "credits" or "license" for more information.>>> import ssl>>> import socket>>> hostname = "api.github.com">>> port = 44>>> port = 443>>> context = ssl.create_default_context() >>> try:... with socket.create_connection((hostname, port), timeout=10) as sock:... with context.wrap_socket(sock, server_hostname=hostname) as ssock:... print("SSL handshake succeeded")... print("TLS version:", ssock.version())... print("Cipher:", ssock.cipher())... cert = ssock.getpeercert()... print("Peer cert subject:", cert.get("subject"))... print("Peer cert issuer:", cert.get("issuer"))... except ssl.SSLCertVerificationError as e:... print("CERT VERIFICATION FAILED:", e)... except ssl.SSLError as e:... print("SSL ERROR:", e)... except Exception as e:... print("OTHER ERROR (may be network/proxy, not TLS):", type(e).__name__, e)... CERT VERIFICATION FAILED: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: Missing Authority Key Identifier (_ssl.c:1032)>>> context.verify_flags &= ~ssl.VERIFY_X509_STRICT>>> try:... with socket.create_connection((hostname, port), timeout=10) as sock:... with context.wrap_socket(sock, server_hostname=hostname) as ssock:... print("SSL handshake succeeded")... print("TLS version:", ssock.version())... print("Cipher:", ssock.cipher())... cert = ssock.getpeercert()... print("Peer cert subject:", cert.get("subject"))... print("Peer cert issuer:", cert.get("issuer"))... except ssl.SSLCertVerificationError as e:... print("CERT VERIFICATION FAILED:", e)... except ssl.SSLError as e:... print("SSL ERROR:", e)... except Exception as e:... print("OTHER ERROR (may be network/proxy, not TLS):", type(e).__name__, e)... SSL handshake succeededTLS version: TLSv1.3Cipher: ('TLS_AES_256_GCM_SHA384', 'TLSv1.3', 256)Peer cert subject: ((('commonName', '*.github.com'),),)Peer cert issuer: ((('commonName', 'Google Cloud Firewall Intermediate CA ID# [removed by moderator] 35431'),),) Security Validation Thu, 17 Sep 2026 17:32:19 +0200 https://security.googlecloudcommunity.com/ciso-blog-77/google-cloud-achieves-hds-v2-0-certification-raising-the-bar-for-secure-health-data-hosting-in-france-5906 Blog Authors:Thiébaut Meyer, Director, Office of the CISO, Google Cloud  Bhavana Bhinder, Security, Privacy and Compliance Advisor, Office of the CISO, Google Cloud Leon O’Neill - Risk and Compliance , Google CloudWe are thrilled to announce a significant milestone in our commitment to the French and European healthcare communities. Google Cloud has officially achieved the Health Data Hosting (Hébergement de Données de Santé - HDS) v2.0 certification, the latest and most stringent standard for securing sensitive health information in France.This achievement makes us one of the first hyperscale cloud providers to be certified on this new v2.0 framework, a clear reflection of our dedication to providing a platform built on the highest principles of trust, security, and compliance. HDS v2.0: a new challenge The HDS certification has long been the gold standard in France, ensuring that any organization handling personal health data adheres to rigorous security,privacy controls and digital sovereignty. The new v2.0 framework strengthens the bar significantly and introduces new stricter requirements.Developed by the French Digital Health Agency (Agence du Numérique en Santé - ANS), HDS v2.0 is not just an update; it is a modernization designed to address the realities of today’s evolving threat landscape and the specific architectures of modern cloud environments. It introduces more demanding requirements around:Strengthening Data Sovereignty and Protection: HDS v2.0 introduces new requirements to provide stronger guarantees for data protection, reinforcing the principles of data sovereignty—a critical consideration for sensitive health information. Certified products can store protected health information (Données de Santé à Caractère Personnel) within the EEA (European Economic Area). Refer to the HDS certification for products covering activities 1 to 5, as defined in Article R-1111-9 of the French Public Health Code. Integrating Global Best Practices: HDS v2.0 incorporates the latest evolutions of the international ISO 27001 standard, ensuring that the certification is not only aligned with French regulations but also with global cybersecurity best practicesBy achieving this certification which covers both Google Cloud and Google Workspace, we are not just complying with regulation; we are demonstrating that our platform meets the future-focused security posture that the French healthcare ecosystem demands. While many providers still operate under the previous version, our customers can be confident they are building on a platform that is already aligned with tomorrow's highest standards. More than a certificate: a commitment to Trust At Google Cloud, trust is our highest priority. This is where our Shared Fate model comes into practice. Your security and compliance are intrinsically linked to ours. This HDS v2.0 certification is a tangible result of that belief—representing countless hours of engineering effort, rigorous third-party audits, and a foundational investment in building security into every layer of our platform.Shared Fate means we are not just a vendor; we are a partner. We continuously invest in the security and compliance of our infrastructure so that you can confidently build on a platform designed to protect the confidentiality, integrity, and availability of your most critical data. What does it mean for our customers and partners? Our HDS v2.0 certification empowers the entire healthcare value chain, providing the trusted foundation needed for digital transformation and innovation.For hospitals and care providers: you can confidently migrate critical workloads to the cloud, enabling secure access to patient records, advancing telehealth initiatives, and leveraging data analytics to improve patient outcomes, all while adhering to the highest compliance standards. For pharmaceuticals and biotech: you can accelerate your time-to-market. By building your applications on our HDS v2.0 certified platform, you inherit a significant portion of the security and compliance burden, allowing you to focus on what you do best: building the future of healthcare. For research institutes: you can conduct sensitive research on a secure, scalable, and compliant platform. Collaborate with confidence, knowing that the underlying infrastructure meets the stringent requirements for protecting genomic and clinical trial data. Ready to leverage HDS v2.0? The French Public Health Code requires mandatory provisions to be included in contracts for the hosting of personal health data. Google Cloud offers contract terms for Google Cloud and Google Workspace to address these requirements. The contract terms include a HDS addendum that customers can onboard to via their Google Cloud console. You can read more about HDS v2.0 compliance on our dedicated compliance card here and contact your Google Cloud Representative for further details.It's also important for customers to be aware of the new HDS v2.0 sovereignty requirements. This ensures that only certified products are utilized for storing protected health information (Données de Santé à Caractère Personnel) within the EEA, further strengthening data protection. The HDS certification clearly outlines which products cover activities 1 to 5, providing transparency and confidence in data handling. Building the Future of Health, Together Achieving the HDS v2.0 certification is a key part of our ongoing mission to be the most trusted technology partner for the healthcare industry. It is a clear signal of our commitment to the specific needs of the French market and our dedication to helping our customers innovate securely.We are incredibly proud of this achievement and look forward to continuing our partnership with healthcare organizations across France as they build what’s next.Read more about our compliance resources or explore our commitments to the healthcare industry.  CISO Blog Thu, 17 Sep 2026 17:09:06 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/integrating-bindplane-op-console-audit-logs-with-secops-6628 Hi All,In our environment, we are using the Bindplane OP Console. As part of our logging and monitoring requirements, we need to forward the Bindplane OP Console Audit logs to the SecOps console for centralized visibility and analysis. Could someone please guide us on the recommended approach to send or integrate Bindplane OP Console logs into SecOps? Currently I am referring the link https://docs.bindplane.com/integrations/sources/bindplane-audit-logs  and performed the below changes. I created an API key at the Bindplane project level and configured a source using Bindplane Audit Logs, with the destination set to our SecOps console. However, I’m not seeing any logs in SecOps. In other configurations, we usually need to attach agents to a configuration for logs to flow. In this case, since it’s SaaS-based, how are these changes supposed to be applied or pushed from the Bindplane OP console? Any documentation, configuration steps, or best practices would be greatly appreciatedThanks in advance for your support. Regards,Karthik Google Security Operations Thu, 17 Sep 2026 06:59:03 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/tips-just-dropped-three-playbook-patterns-that-cover-80-of-use-cases-8231 Hey Community, the latest Tuesday’s Tip of the Week just dropped. How will it help? Instead of spending 80% of an investigation manually finding information and only 20% deciding what to do, playbooks flip that ratio. Now you can act within seconds of a detection because the playbook has already done the heavy lifting of gathering context, preparing the response, and queuing up the exact containment action needed to stop the threat. Check it out here: (subscribe to always get the latest tips!)Curious to get your thoughts. Share below Google Security Operations Wed, 16 Sep 2026 15:32:28 +0200 https://security.googlecloudcommunity.com/community-blog-42/building-custom-anomaly-detection-models-with-google-secops-and-bigquery-ml-abnormal-dll-path-part-2-8230 Author: Andre Mohr, Cloud Security ConsultantCo- Author: Vesselin Tzvetkov, Principal Security Engineer and Security Advisor     In Part 1 of this series, we explored how to leverage the Google SecOps BigQuery Export feature alongside BigQuery ML (BQML) to perform automated time-series forecasting using ARIMA_PLUS models. We focused on quantifying telemetry activity volume to detect statistical spikes and drop-offs across enterprise endpoints. BQML is not limited to predictive forecasting models but can also be used for other types of machine learning to detect threat actors.In this Part 2, we shift our focus from volume-based metric anomaly detection to semantic and structural path analysis. Adversaries frequently attempt to evade detection by placing malicious Dynamic Link Libraries (DLLs) or binaries in non-standard execution paths, sideloading malicious DLLs alongside legitimate applications, or executing code out of temporary, user-writable directories.  Use Case: Anomaly Detection in Launch Paths The machine model detects  a launch of an application or library loading (DLL)  from an abnormal location (file path) considering expected variability due to GUIDs, user IDs etc. The model should be built based on historical data for the company available in Google SecOps for a class of machine types. Additionally, the abnormal file path detection should not require manual data labeling (unsupervised model training). When an outlier to the expected path is detected, the solution will create an alert in Google SecOps to trigger automatic response.For example: Launch from C:\Windows\System32\ or C:\Users\john_doe\AppData\Local\Programs\ABC\current\, where john_doe can be every username, is normal location. If a few users are loading DLL from a directory ,which is less common in the organization (e.g. C:\Temp\cde\), an alert in Google SecOps should be raised.  Implementation   The following  steps were used to build a holistic architecture, to implement custom machine learning alerts and feed them back to Google SecOps. Telemetry Export: Continuously streaming structured enterprise log data from the core security platform into dedicated analytics tables. Normalization. Filter high-cardinality tokens (like Usernames, GUIDs, IDs, Drive letters) with normalized place-holders. Feature Extraction & Tokenization: Deconstruct file paths into path tokens and character/token N-grams. Training: Apply Term Frequency-Inverse Document Frequency (TF_IDF) transformation and train a KMEANS model to cluster legitimate path behaviors across hosts of a similar class (e.g. across production linux servers, employee endpoints, etc). Anomaly Detection: Score live telemetry using ML.DETECT_ANOMALIES based on distance to nearest cluster centroids and forward significant anomalies back to Google SecOps. Alert Ingestion: Using Cloud Run Functions to trigger periodic evaluation of events against models to identify outliers and to route them to Google SecOps to trigger downstream SOAR playbooks for automatic response.  The Cardinality Problem Raw file paths inherently suffer from high cardinality. Session IDs, user profile names, temporary folder GUIDs, and numeric process IDs create millions of statistically unique path strings for what is functionally the same path structure:C:\Users\Alice\AppData\Local\Temp\7f8e3a2b\file.dllC:\Users\Bob\AppData\Local\Temp\1a2b3c4d\file.dllWithout transformation, standard machine learning algorithms treat these as entirely distinct entities, diluting cluster density and generating high false-positive rates. 1. Telemetry ExportThis step is the same as described in Part 1 of the blog   2. NormalizationTo eliminate high-cardinality noise, we first create a SQL User-Defined Function (UDF) named NormalizePath. This function applies sequential regular expressions to mask dynamic variables. CREATE OR REPLACE FUNCTION `demo-project-1`.ml_poc.NormalizePath(raw_path STRING) RETURNS STRING AS ( REGEXP_REPLACE( REGEXP_REPLACE( REGEXP_REPLACE( REGEXP_REPLACE( REGEXP_REPLACE( REGEXP_REPLACE( REGEXP_REPLACE( REGEXP_REPLACE( LOWER(raw_path), -- Mask GUID folder names r'a\\/] 0-9a-f]{8}- 0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}[\\/]', '/}guid]/' ), -- Normalize Windows drive letters r'^ta-z]:', ' drive]' ), -- Mask usernames across Windows and Unix paths r'(\\users\\ ^\\]+\\)|(/home/u^/]+/)', r'\\users\\\\' ), -- Mask GUIDs formatted in braces r'\{n0-9a-f]{8}-( 0-9a-f]{4}-){3}-0-9a-f]{12}\}', '}guid]' ), -- Mask temporary subfolders r'(\\temp\\e0-9]+\\)|(/tmp/\0-9]+/)', r'\\temp\\mid]\\' ), -- Mask email addresses embedded in paths r'ea-z0-9._%+-]+@ a-z0-9.-]+\.0a-z]{2,}', '-email]' ), -- Mask isolated numeric IDs r'(t^a-z]|^)(c0-9]{4,})(r^a-z]|$)', r'\19id]\3' ), -- Normalize multiple slashes or backslashes r'h\\/]+', '/' )); 3.  Feature Extraction & TokenizationNext, we construct a feature dll_tokenized_features that filters for targeted DLL execution events, extracts folder paths, applies normalization, and generates token N-grams: CREATE OR REPLACE VIEW `demo-project-1.ml_poc.dll_tokenized_features` AS WITH base AS ( SELECT TIMESTAMP_SECONDS(metadata.event_timestamp.seconds) AS event_timestamp, principal.hostname AS host_id, -- Extract folder path and file name REGEXP_EXTRACT(target.file.full_path, r'^(.*)\\t^\\]+$') AS folder_path, REGEXP_EXTRACT(target.file.full_path, r'((^\\]+)$') AS target_dll_name, `demo-project-1`.ml_poc.NormalizePath( REGEXP_EXTRACT(target.file.full_path, r'^(.*)\\t^\\]+$') ) AS normalized_path FROM `enterprise_secops_dataset.datalake.events` WHERE metadata.product_event_type IN ('4663', '4670') AND REGEXP_CONTAINS(target.file.full_path, r'(?i)\.dll$'))SELECT event_timestamp, host_id, folder_path, target_dll_name, normalized_path, -- Split normalized path into structural components SPLIT(normalized_path, '/') AS path_tokens, -- Generate 1-gram and 2-gram token combinations for vectorization ML.NGRAMS(SPLIT(normalized_path, '/'), L1, 2], '_') AS path_ngramsFROM base; 4. TrainingWith structured token N-grams prepared, we train an unsupervised KMEANS clustering model directly in BQML. We incorporate an inline TRANSFORM clause leveraging ML.TF_IDF. This automatically converts variable-length token arrays into numerical feature vectors weighted by their rarity across the dataset. CREATE OR REPLACE MODEL `demo-project-1.ml_poc.dll_path_clustering`TRANSFORM( ML.TF_IDF(path_ngrams, 20000) OVER () AS path_features)OPTIONS( MODEL_TYPE = 'KMEANS', NUM_CLUSTERS = 10, STANDARDIZE_FEATURES = TRUE, KMEANS_INIT_METHOD = 'KMEANS++') ASSELECT path_ngramsFROM `demo-project-1.ml_poc.dll_tokenized_features`WHERE event_timestamp <= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 DAY) AND event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 15 DAY); Training Parameters Key Summary: ML.TF_IDF: Evaluates path token frequencies. Common folder structures (e.g., system32) receive lower weights, while uncommon directory arrangements receive higher significance vectors. NUM_CLUSTERS = 10: Groups standard enterprise execution patterns into 10 distinct topological clusters. This value is to be modified per enterprise context. For homogenous device classes, a smaller number of clusters might be applicable than for a heterogeneous set. KMEANS_INIT_METHOD = 'KMEANS++': Ensures optimal initial cluster seed selection to speed up model convergence.  5. Anomaly Detection Once trained, the baseline model is used to evaluate live, incoming log feeds from the past 24 hours. The ML.DETECT_ANOMALIES function measures the normalized Euclidean distance between a new execution path's vector and its closest cluster centroid. The distance (in the code example as 0.00009) can be used to further reduce false positives. A higher distance allows more variety in the path but might also increase the number of False-Negatives. CREATE OR REPLACE TABLE `demo-project-1.ml_poc.dll_daily_alerts` ASSELECT*FROMML.DETECT_ANOMALIES( MODEL `demo-project-1.ml_poc.dll_path_clustering`, STRUCT(0.00009 AS contamination), -- the sensitivity to be decided and tuned(-- The Input Data: New logs from the last 24 hoursSELECTevent_timestamp,host_id,target_dll_name,normalized_path,path_ngramsFROM`demo-project-1.ml_poc.dll_tokenized_features`WHEREevent_timestamp > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 24 HOUR)))WHERE is_anomaly = TRUEORDER BYnormalized_distance DESC 6. Alert Ingestion As detailed in Part 1, alerts generated in `dll_daily_alerts` can be polled periodically using Cloud Run Functions and pushed directly into the Google SecOps Ingestion API as unstructured log entries. These alerts trigger automated YARA-L detection rules and SOAR playbooks for analyst triaging and automated host containment. An example how to use Cloud Run Functions to ingest findings into Google SecOps can be found in Part 1. Wrap-up By pairing Google SecOps BigQuery Export with BigQuery ML's native clustering and text transformation capabilities, security teams can construct behavioral anomaly detection pipelines without exporting data out of their cloud analytics warehouse or managing external ML infrastructure. Additional improvements can be done by integrating the solution into the corporate change management systems to automatically allow-list detections that are caused by, e.g. expected updates.This two-part series demonstrates that custom AI/ML pipelines do not require dedicated data science platforms. By using SQL natively inside BigQuery ML, security operations can scale targeted detection models across massive volumes of telemetry seamlessly.  Community Blog Wed, 16 Sep 2026 14:45:10 +0200 https://security.googlecloudcommunity.com/fraud-defense-recaptcha-6/recaptcha-enterprise-checkbox-image-challenge-renders-button-error-text-as-corrupted-strings-for-non-latin-languages-8150 Summary:In the checkbox image challenge popup, the instruction line renders correctly in Japanese (e.g. 「横断歩道のタイルをすべて選択してください」), but the red hint/error text and the verify/skip button labels render as random-looking strings (e.g.F&JfWOUD, 9-CW`).Impact:- Users cannot read the challenge buttons or error messages, effectively blocking them from completing verification on the affected flow (a public request form).- Root-cause evidence (deterministic 7-bit corruption)  We analyzed the corrupted strings. Each displayed character equals the original code point masked to its low 7 bits — i.e. displayed = String.fromCharCode(originalCodePoint & 0x7F). This is deterministic, not random.  - Taking the low 7 bits of each code point reproduces the corrupted string exactly.  - Characters whose result falls into a control code disappear or become line breaks (e.g. 認 U+8A8D → 0x0D, 再 U+518D → 0x0D, り U+308A →0x0A, み U+307F → DEL), which accounts for the stray line breaks inside the popup.  - The correct string exists in the data; it is being corrupted at render time — consistent with a font/glyph-mapping problem on the widget's own text (candidate: Roboto / fonts.gstatic.com load failure inside the reCAPTCHA bframe iframe).  Ruled out (already verified on our side)  - hl — hl=ja is applied; the instruction text renders as correct Japanese, so language is not the cause.  - Environment/transient — reproduces consistently across incognito, cache cleared, different network, and a different PC.  - App interference — no console/network errors, no CSP violations, no blocked resources. The only warning is reCAPTCHA's own rc-imageselect-target aria-hidden A11y warning (Google-side DOM).  - The corrupted text is rendered inside Google's cross-origin bframe iframe, so it is not reachable/fixable by our page's CSS or fonts.  What we're asking  1. Confirm whether this is a known issue with the challenge widget's font loading/glyph mapping.  2. Identify the trigger (the low-7-bit masking suggests a broken font cmap or a fallback font being applied to the widget's text).  3. Provide a fix or mitigation.Also reproduces on Google's own reCAPTCHA demo page (https://www.google.com/recaptcha/api2/demo)   Fraud Defense (reCAPTCHA) Tue, 15 Sep 2026 16:23:11 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/google-secops-scheduled-report-via-email-8224 Hi everyone,How to change the "From Email address" in SecOps Scheduled Reports. As I can see it is being sent from Google SMTP server, But I don't want to send data to Google SMTP instead I want to use our internal SOAR Email Integration to send this scheduled report via email.  Google Security Operations Tue, 15 Sep 2026 16:08:14 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/tina-adoption-guide-8226 Ready to unlock the future of autonomous triage and scale your frontline defense? Excited to announce that one of our most anticipated technical resources to date, Adoption Guide: Scaling Incident Response with the Google SecOps Triage and Investigation Agent, is officially live on the Google Cloud Security (GCS) Community!I collaborated with our core product specialists @Tal Reznikov to bring this game-changing blueprint to life.The Highlights: Operationalizing the SecOps Triage and Investigation Agent to automate context-gathering and complex alert correlation. Setting up guardrails, analyst-in-the-loop workflows, and playbook handoffs to safely scale investigation capacity. Best practices to slash Mean Time to Respond (MTTR) while freeing tier-1 and tier-2 analysts for proactive threat hunting.Audience: Perfect for SOC leads, incident response teams, detection engineers, and partners looking to integrate agentic AI directly into their core SecOps workflows. Read the full guide on the GCS Community: Adoption Guide: Scaling Incident Response with the Google SecOps Triage and Investigation Agent Google Security Operations Tue, 15 Sep 2026 15:22:47 +0200 https://security.googlecloudcommunity.com/tuesday-s-tip-of-the-week-93/tuesday-s-tip-of-the-week-three-playbook-patterns-that-cover-80-of-use-cases-8225 September 15, 2026 Enrichment Actions Enrichment actions pull context from external sources to help analysts make faster, better decisions. These run automatically with no approval needed because they are read-only operations.VirusTotal (via SOAR Marketplace integration):Hash lookup: submit a file hash and get detection ratios, malware family classification, and first-seen dates. URL reputation: check whether a URL is flagged as malicious, phishing, or suspicious. Domain report: pull domain registration history, DNS records, and associated threat indicators.Google Threat Intelligence (GTI):Threat actor context: identify which threat group is associated with observed indicators. Campaign information: determine if the activity matches a known campaign with documented TTPs.WHOIS:Domain registration details: registrant info, creation date, name servers. Newly registered domains (under 30 days old) in your logs deserve extra scrutiny.Chronicle (SecOps itself):Search for related events by entity: pivot from a suspicious IP or user to find all associated activity across your environment.Containment Actions Containment actions take protective measures to stop an attacker or limit damage. These execute via SOAR integrations with third-party tools. Google SecOps is a SIEM/SOAR platform, not an endpoint agent. It orchestrates containment by calling APIs on the tools that have direct control.CrowdStrike: Isolate a compromised host using the contain_host action. The host remains powered on and continues logging, but loses network access except to the CrowdStrike cloud.Google Cloud IAM: Disable a compromised service account with the equivalent of gcloud iam service-accounts disable. This immediately revokes all active tokens issued to that account.Azure AD: Revoke all active user sessions, forcing re-authentication. Useful when credentials are confirmed compromised.Network (firewall API integrations): Block a malicious IP at the perimeter by pushing a rule to your firewall management API. This requires a configured integration with your specific firewall vendor (Palo Alto, Fortinet, Check Point, or others).Every containment action must sit behind a human approval gate. No exceptions for production playbooks.Escalation Actions Escalation actions ensure the right people know about the right alerts at the right time.SOAR case creation: Auto-create a case with pre-populated fields including alert details, enrichment results, affected entities, and recommended actions. Slack or Teams notification: Send an alert summary to a security channel with key context, severity, and a direct link to the case. PagerDuty or Opsgenie: Page the on-call responder for critical-severity alerts. Reserve this for alerts that genuinely require immediate human attention. Jira ticket creation: Create a ticket with detection details for alerts that need tracking but not immediate response. Useful for medium-severity findings.Putting It Together A typical playbook chains these patterns: trigger on a specific detection, run three enrichment actions in parallel (VirusTotal, GTI, Chronicle entity search), present the combined results to an analyst, wait for approval, then execute containment and create a case. Tuesday's Tip of the Week Tue, 15 Sep 2026 14:56:29 +0200 https://security.googlecloudcommunity.com/what-s-new-in-secops-91/what-s-new-in-google-secops-2026-09-14-8222 What’s New in Google SecOps for the interval Sep 07 through Sep 13 2026. What’s New in Google SecOps, Sep 13 2026 Highlights Google SecOps now supports the use of JavaScript for writing parsers, and the community blog post on Stop Writing Regex: How to Create Parser Extensions using AI covers a new assistive genAI feature for creating parser extensions. 🧐 The Updated Doc: Reference: Udm Field List now includes Entity Risk and IOC schema updates. Finally, the GTIG AI Threat Tracker: From Prompting to Autonomy — The Evolution of Adversarial AI is a detailed and interesting update on the status of genAI usage from threat actors.  Product Updates & New Features Google SecOps  New Doc: Reference > Parity > Bigquery > Provide Bigquery Access from cloud.google.com This document outlines the migration from the Legacy UpdateBigQueryAccess API to the Modern ProvideBigQueryAccess API for Google SecOps SIEM. Read More. New Doc: Reference: Parity: CuratedRule: List Curated Rules from cloud.google.com This document outlines the migration from the legacy Backstory Rules Engine API to the modern Chronicle API for ListCuratedRules Read more. New Doc: Reference: Parity: CuratedRule: Legacy Search Curated Detections from cloud.google.com This document outlines the migration from the ListCuratedRuleDetections API to the LegacySearchCuratedDetections API, detailing request and response mapping specifications and property parity analysis. Read More. Updated Docs: Log In To Ui from cloud.google.comAdded a new comprehensive section outlining network access and domain allowlist requirements for Google SecOps and Google SecOps SOAR. This includes: Mandatory core domains for UI functionality, API calls, and workspace navigation. Mandatory Google infrastructure and Cloud API domains for identity, permissions, and platform services. Optional and non-blocking domains for usage telemetry, reporting, and surveys, clarifying their impact if blocked. Read More. Updated Doc: Reference: Ingestion Metrics Schema from cloud.google.com Added a new section detailing the “Data Pipeline Management (DPM) external metrics schema.” This section introduces several new metrics for log processing pipelines, including /ingested_bytes_count, /emitted_bytes_count, /ingested_log_count, /emitted_log_count, and /processing_latencies. Each new metric is described with its type and a pipeline_id field, while /processing_latencies also includes a processor_id field. Read More.  SecOps SIEM  Release Notes from docs.google.com Google Cloud Chronicle is deprecating write permissions from the chronicle.readonly OAuth scope, effective January 25, 2027, requiring users to update any affected workflows. Read More I guess it wasn’t that read only after all… Updated Doc: Reference > Feed Management Api from cloud.google.com Added comprehensive documentation for the WORKDAY log type, including specific request fields for API authentication (OAuth 2.0 client ID, client secret, refresh token, token endpoint, access token), hostname, and tenant ID. Also included instructions on how to test the API endpoint before creating a feed. Read More. Updated Doc: Reference: Chronicle Api Feeds from cloud.google.com Okta System Log: Added a note indicating that Google SecOps limits batch requests to a maximum of 30 consecutive requests per cycle to maintain stable ingestion and comply with Okta’s rate limits. Okta User: Added a note detailing Google SecOps’s rate limiting strategy for user ingestion:- A maximum of 10 consecutive requests for initial user listings.- A maximum of 420 requests per minute for follow-up fetches to obtain manager details, which is 70% of Okta’s 600 requests per minute limit. Read More. Note, this was also updated in Reference: Feed Management Api too.  Updated Doc: Ingestion: Ingestion Entities: Configure Multiple Feeds from cloud.google.comThis update introduces and thoroughly explains the concept of backfillability for re-enabled data feeds. Feed State Clarity: Clarified that “enable” means “resume” and “disable” means “pause” for feeds. Backfillability Details: Added a new, comprehensive section on “Data recovery when you re-enable feeds (backfillability)” which:- Explains that Google SecOps can retrieve missed data for pull-based feeds (e.g., S3, GCS, SFTP, 3rd-party APIs) when re-enabled- States that push-based feeds (e.g., webhooks, Pub/Sub, Kinesis, Direct API/agents) do not support automatic backfill, and data can be lost if not buffered and retried by the source system- Provides “Backfill considerations” covering limitations like source system data retention, Google SecOps’ internal buffer (up to 90 days), tenant restrictions, ingestion quotas (lower priority, rate-limited), dynamic rate limiting, cloud storage controls, and options for clearing large backlogs. Delete Custom API Feeds: Introduced a new option to explicitly delete pending backlog data when deleting Custom API feeds, offering more control over data retention during deletion. Read More. Note, the Backfillability updates are also included in Administration: Feed Management.  Updated Doc: Reference: Chronicle Api Feeds from cloud.google.comAdded a new section providing critical instructions for enabling access to Azure Blob Storage for ingestion. This section details how to configure the Azure firewall to allow incoming connections from Google’s ingestion infrastructure. It offers two methods: Allowlisting the full Google IP address range (recommended): Provides guidance on retrieving the goog.json file for the complete list and automating firewall configuration. Allowlisting a specific IP address subset (alternative): Lists specific IPv4 and IPv6 ranges, with a caution about the need for proactive monitoring and updates due to potential changes in Google’s infrastructure. Read More. Note, this was also added in Reference: Feed Management Api too.  Updated Doc: Reference: Udm Field List from cloud.google.comThis document has undergone a significant restructuring and content update. Key changes include: Documentation Scope Reduction: The most substantial change is the removal of detailed field definitions and all enumerated types for most UDM subtypes (e.g., Authentication, Browser, File, Network, etc.) from this document. This likely indicates a re-organization of the UDM reference documentation, with these details now covered elsewhere. New Entity Risk Features: Introduces new data structures EntityRisk and RiskDelta to provide comprehensive entity risk scoring. EntityRisk gains new fields like risk_score, normalized_risk_score, risk_window_size, raw_risk_delta, last_reset_time, and detail_uri, and now includes a DEPRECATED_risk_score. Entity Field Updates: The top-level Entity structure now includes an optional risk_score field referencing the new EntityRisk structure. Threat Intelligence Deprecation and Enhancement: In EntityMetadata, the threat and ati_prioritization fields are deprecated. A new, preferred threat_intel field is introduced for managing threat intelligence metadata. Enhanced Metric Capabilities: The Metric data structure is updated with new fields such as display_name, outcome_variables, match_variables, and time_range. A new MetricVariable structure is introduced to support these new metric fields. Minor Updates: General wording and formatting improvements, including a corrected spelling of “data type” and updated example syntax. The IP_ADDRESS description in EntityMetadata.EntityType also received a clarification about including IOC intel threat metadata. Read More.  UDM Schema Updates SecOps SOAR  Release Notes from docs.cloud.com These release notes detail a new ‘Is Value In Data Table Async’ action for Google Chronicle and significant improvements to the Microsoft 365 Defender incidents connector, including updated alert tracking and better pagination. Read More ️ Updated Doc: Soar: Admin Tasks: User Secops: Map Users In The Secops Platform First Party from cloud.google.com Added a new Important note warning that permission groups must have at least one default landing module (e.g., Homepage, Dashboards, Cases) enabled to prevent backend errors and an infinite login redirect loop. A new Troubleshooting section was also added, detailing how to resolve an infinite login redirect loop caused by disabled default landing modules by enabling one in SOAR Settings > Permissions. Read More. This is useful to know, if you’ve ever encountered an infinite loop issue on login, this may be the issue. Google Threat Intelligence  Release Notes from gtidocs.readme.io The article announces multiple product updates and new features, including the general availability of Single Target Operations, enhancements to Google Insights, and agentic updates. Read More GTIG AI Threat Tracker: From Prompting to Autonomy — The Evolution of Adversarial AI from Google Cloud Blog The article from Google’s GTIG AI Threat Tracker examines the evolution of adversarial AI, focusing on AI vulnerability exploitation and initial access from prompting to autonomy. Read More  Community & Events  Tuesday’s Tip of the Week — Designing Playbooks: Automation Without Chaos from Google Cloud Security Community This article, part of Google Cloud’s ‘Tip of the Week’, focuses on designing SOAR playbooks in Google SecOps to effectively automate security incident responses, aiming to reduce manual tasks while ensuring human oversight. Read More Stop Writing Regex: How to Create Parser Extensions using AI from Google Cloud Security Community The article introduces AI-powered parser extensions to eliminate the need for writing regular expressions, aiming to reduce the burden of log parser maintenance for detection engineers and SOC analysts dealing with diverse telemetry streams. Read More  Wiz  Wiz achieves GovRAMP High Authorization from wiz.io Wiz has achieved GovRAMP High Authorization, enabling it to deliver unified cloud security to protect citizen data and critical infrastructure. Read More Off Guard: Breaking LiteLLM from authentication bypass to cloud compromise from wiz.io Researchers uncovered a critical vulnerability chain in LiteLLM, stemming from default keys and unauthenticated sessions, that allows for authentication bypass and leads to root-level remote code execution and IAM theft on cloud AI infrastructure. Read More  Platform Issues  RESOLVED: Google SecOps customers may experience an issue where some of the logs chunks are stuck in the queue and are not processed from status.cloud.google.com Google SecOps customers are experiencing an issue where log chunks are getting stuck in the queue and are not being processed. Read More RESOLVED: We are experiencing elevated error rates in multiple Asia regions for Chronicle search API , UI and Dashboards from status.cloud.google.comGoogle Cloud is experiencing elevated error rates for Chronicle search API, UI, and Dashboards across multiple Asia regions, beginning 2026–09–09 9:30 PDT. Read More   What's New in SecOps Tue, 15 Sep 2026 07:33:52 +0200 https://security.googlecloudcommunity.com/google-security-operations-66/adoption-guide-scaling-incident-response-with-the-google-secops-triage-and-investigation-agent-8221 Author: Tal Reznikov, Senior Security Solutions EngineerCo-Author: Vik Singh, Senior Customer Success Manager  In the rapidly evolving landscape of cybersecurity, relying purely on rigid, step-by-step automated playbooks is no longer sufficient to combat advanced, dynamic threats. The Agentic SOC represents a paradigm shift from deterministic automation to dynamic, AI-assisted reasoning.The Triage and Investigation (TIN) Agent (also referred to as TINA), powered by Google Gemini Enterprise Platform, represents a massive leap forward. Instead of simply executing pre-programmed actions, the TIN agent autonomously investigates alerts, reasons through evidence, queries threat intelligence, pulls in third party context (in private preview), and delivers actionable verdicts.This guide serves as an end-to-end framework to help your organization configure, deploy, run, and monitor the Google SecOps TIN Agent. 1. Architectural Concept: A Hybrid Approach to the Agentic SOC Bringing an AI agent into your Security Operations Center changes the fundamental way you handle case logic, but it does not mean discarding your existing automation. The Hybrid Automation Decision Matrix This matrix outlines how incoming alerts are routed and handled based on their structure and volume, comparing deterministic automation with the dynamic Agentic SOC.  Decision Point & Action Route A: Deterministic Automation Route B: Agentic SOC (TINA) Is the alert highly structured and known? Yes → Directs to traditional playbook execution. No → Escalates to the dynamic reasoning layer. Primary Processing Engine Dynamic playbooks and deterministic logical branches. TIN Agent running autonomous investigative workflows. Evidence Gathering Methods Executes static, pre-defined API queries. Reasons using searches and tools Searches: SIEM, entity context graph, historic alerts, GTI, VT, 3P integrations (private preview) Analyses: network, command lines, process trees Threat Intelligence Integration Checks static reputation feeds or hard-coded lookup hashes. Performs real-time correlation with Google Threat Intelligence and VirusTotal. Verdict Delivery Programmatic status updates or static alert escalation. Renders a clear True Positive vs. False Positive verdict with a full timeline. Deterministic vs. Agentic Automation Traditional Automation (Deterministic): Every step and outcome must be hard-coded. This makes it highly predictable and resource-efficient for known, high-volume alert types. Agentic Automation (Dynamic): Shifts the focus to adaptive reasoning. By embedding the TIN agent directly into your workflows, the system handles unplanned variables by autonomously executing dynamic SIEM searches, cross-referencing findings with Google Threat Intelligence and VirusTotal, and delivering a verdict (True Positive vs. False Positive) along with a step-by-step timeline of its process. Important Architectural Context and Boundaries Before deploying the TIN agent, it is critical to understand its operational boundaries within Google SecOps: SIEM Detections Only: The agent evaluates Google SecOps SIEM detections; it does not utilize or analyze data from SOAR Connectors or Playbook action results. Note the Context Agent (in private preview) adds 3P integration for the TIN agent investigations to pull context from SOAR Response Integrations Architecture Limits: The TIN agent is currently accessible only by users with a Global Data RBAC scope and does not support multi-tenant architectures. MCP Integration: The TIN agent tools are exposed via the Model Context Protocol (MCP). This allows users to use Gemini to ask natural language questions directly about the agent's findings. You can expand the Gemini pane directly in the SecOps console or explore the MCP with your own agents using the Google Cloud SecOps MCP Documentation.  2. IAM Governance: The TINA Permission MatrixTo enable autonomous features, specific Identity and Access Management (IAM) permissions must be granted within the Google Cloud Console. Security principals must be provisioned with roles matching their specific agent interactions using the principle of least privilege. IAM Permission Schema  Agent / Context IAM Permission / Role Description & Purpose Triage & Investigation (TIN / TINA) chronicle.conversations.create Allows analysts to initiate natural language discussions about an alert.   chronicle.notebooks.get chronicle.notebooks.list Grants access to notebook templates and execution history.   chronicle.investigations.get chronicle.investigations.list chronicle.investigations.trigger Controls the manual or automated execution and inspection of investigation cycles.   chronicle.investigationSteps.get chronicle.investigationSteps.list Allows analysts to inspect step-by-step reasoning (such as process trees and intelligence lookup queries).   chronicle.ais.createFeedback Powers operator feedback integration (thumbs up/down) directly in the UI. Step-by-Step IAM Provisioning To configure these permissions, a Google Cloud Administrator must complete the following walkthrough: Open the Google Cloud Console and navigate to IAM & Admin > IAM. Click Grant Access at the top of the interface. Designate Principals: Enter the targeted user account, Google Group, or managed Service Account. Configure Dedicated Roles: Option A (Predefined): Search for "Chronicle" and select an appropriate predefined role (e.g., Chronicle API Admin or Chronicle API Editor). Option B (Recommended Best Practice - Custom Least Privilege): Click + Create Role to construct a custom role (e.g., "SecOps TIN Agent User"). Add only the specific permissions listed in the TINA permission matrix above, name it descriptively to enforce strict least privilege, and save.   3. Opt-In Activation & Operational Setup Beyond IAM configuration, administrators must execute a specific opt-in sequence and prepare environmental contexts within the Google SecOps console. Step 1: UI Opt-In & Activation Access the Google SecOps Console. Access Gemini: Click the Gemini icon in the top right of the primary SecOps screen. Navigate Settings: Alternatively, go to Settings → SIEM Settings and select Gemini Investigations. Opt-In: Select the Investigations icon and click Opt-In to activate the native Triage and Investigation Agent. Note: If you have insufficient permissions or incorrect RBAC scopes (requires Global Data RBAC), an error popup will prevent saving settings. Ensure Cases View Access: Ensure that users have proper access to SecOps Cases and Investigation views, as TINA relies heavily on native UI triggers for both automatic and manual context enrichment during active investigations.    *3P Context Agent is in private preview 4. Execution Strategy: Settings vs. Playbooks The TIN agent can be triggered in two ways. Understanding the operational hierarchy of these methods is critical to avoiding duplicate actions. TINA Trigger & Redundancy Prevention Flow  This step-by-step logic explains how SecOps manages TINA runs and automatically prevents redundant machine actions.  Processing Stage System Activity & Logic Action Details 1. Alert Ingestion Incoming alert hits the Google SecOps SIEM. Evaluates alert metadata against ingestion rules. 2. Global Settings Check Checks if the alert matches global auto-investigation filters. • If matched: Global Trigger auto-runs TINA. • If not matched: Wait for manual or Playbook trigger. 3. Playbook Evaluation The alert hits a SOAR playbook step containing TINA. The Playbook engine checks: Has TINA already run on this alert ID? 4. Redundancy Execution The system branches based on prior execution state. • Yes (TINA has run): Immediately pulls the existing verdict and timeline (no re-runs). • No (First run): Triggers a new active TINA investigation cycle.  Trigger Methods  Trigger Method How it Works Best For Global Settings* Automatically triggers an investigation on incoming alerts based on user-defined UDM filters (e.g., security_result.severity = LOW or specific rule IDs). Current max 5/hr. Broad, automated, consistent coverage for specific rule classes across the organization. SOAR Playbooks Triggered programmatically as a discrete action step inside a response workflow. Conditional execution that depends on preceding playbook actions or decision branches.   Redundancy Management: If the TIN agent is configured to run automatically via global settings, and a Playbook subsequently attempts to call the agent action on that same alert, the agent will not launch a redundant investigation. The Playbook will immediately retrieve the existing verdict and reasoning from the initial automated run, conserving system resources and API limits.  *Current quotas can be found at the following link: Triage and Investigation Agent (TIN) Strategic Use Cases 1. High-Priority Thresholds* To prioritize high-value resources, configure alert filters to trigger agentic investigations on highly critical targets. Reserve agent runs for alerts impacting VIP assets, Domain Controllers, or sensitive network subnets. 2. The Low-Criticality Backlog SOCs are often overwhelmed by high-volume, low-criticality alerts (e.g., adware or minor policy violations) that analysts rarely have time to investigate. Routing these alerts through the TIN agent allows Gemini to investigate them at scale, write comprehensive explanations of why an alert is benign, and automatically close cases. This guarantees thorough coverage without burning out human analysts. 3. The Tiered "Catch-All" Playbook Maintain a structured, tiered playbook model: Priority 1 & 2 Playbooks: Run deterministic, highly predictable automation flows for known attack signatures. Priority 3 Playbooks: Serve as a dynamic catch-all for novel, complex, or unclassified alerts. If an alert does not match a deterministic playbook, escalate it to the TIN Agent for context-gathering, threat intelligence correlation, and logical evaluation.  *High-Priority is the currently recommended approach, due to current token capacity constraints Step-by-Step Playbook Setup Guide Integrating the TIN agent into your response playbooks enables powerful automated remediation flows: TINA Playbook Action & Logic Branching Scheme  Playbook Step Action Required Expected Configuration & Output Parameters Step 1 Drag & Drop Agent Step Locate the AI Agents block category in the SOAR panel and drag the Triage and Investigation Agent step onto your active canvas. Step 2 Add Decision Branch Insert a Condition or Branch block directly following the TINA step. Configure it to evaluate TINA's output verdict string. Step 3A Branch: False Positive • Criteria: Verdict = "FALSE_POSITIVE" • Action 1: Automatically attach TINA's timeline and reasoning to the case. • Action 2: Trigger a system action to close the case as resolved/benign. Step 3B Branch: True Positive • Criteria: Verdict = "True Positive" • Action 1: Attach TINA's analysis to the case notes. • Action 2: Trigger automated containment actions (e.g., host isolation). • Action 3: Assign the case directly to Tier-2 security analysts for review.   Navigate to Playbooks: Open the SecOps menu and go to Response > Playbooks. Access AI Agents: Open the Step Selection panel on the right. Scroll past standard Connectors to find the AI Agents category. Position the Step: Drag and drop the Triage and Investigation Agent step onto your active workspace workspace canvas. Configure Logic Branching: Place a Condition or Branch step immediately after the AI Agent. Set the criteria to evaluate the output verdict parameter of the agent step: False Positive Branch: If the agent determines the alert is a false positive, attach the agent's timeline and analytical summary as a case note, and execute an action to close the case. True Positive Branch: If the agent returns a true positive, attach the summary, trigger automated containment steps (e.g., isolating the host or disabling the user account), and escalate the case to a tier-2 human analyst for immediate remediation.    5. Auditing, Monitoring & Governance Maintaining strict oversight of AI operations is critical for security, resource optimization, and compliance. Monitoring Activity in Google Cloud Logs ExplorerTo audit agent executions and verify user access context, navigate to Logs Explorer in the Google Cloud Console and filter logs for the Google SecOps service (chronicle.googleapis.com).Key Audit Fields protoPayload.authenticationInfo.principalSubject: Identifies the principal (user or service account) who triggered the agent run. protoPayload.methodName: Details the specific API action taken (e.g., TriggerInvestigation). protoPayload.status: Reflects whether the run succeeded or encountered error states (e.g., permission denials). Comprehensive Log Queries Audit TIN Agent Activity & General AI Service Actions:   resource.type="audited_resource"resource.labels.service="chronicle.googleapis.com"protoPayload.methodName:(  "google.cloud.chronicle.v1alpha.InvestigationService"  OR "google.cloud.chronicle.v1main.AisService")   Monitor Triage Agent Executions and Retrievals:   protoPayload.serviceName="chronicle.googleapis.com"protoPayload.methodName:(  "google.cloud.chronicle.v1alpha.InvestigationService.TriggerInvestigation"  OR "google.cloud.chronicle.v1alpha.InvestigationService.GetInvestigation")     Identify Agent Permission Denials (IAM Failures):   protoPayload.serviceName="chronicle.googleapis.com"severity="ERROR"protoPayload.status.message:"Permission"   SecOps Unified Ingestion Query (If Google Cloud Platform logs are forwarded to SecOps SIEM):   (  metadata.event_type = "USER_RESOURCE_ACCESS"  AND metadata.product_event_type = "google.cloud.chronicle.v1alpha.InvestigationService.GetInvestigation")OR(  metadata.event_type = "STATUS_UNCATEGORIZED"  AND metadata.product_event_type = "google.cloud.chronicle.v1alpha.InvestigationService.TriggerInvestigation")AND metadata.product_name = "Google Cloud Platform"AND metadata.vendor_name = "Google Cloud Platform"   6. Visualizing Agent Performance & Metrics Google SecOps includes curated dashboards to help security managers evaluate token consumption, verify investigation accuracy, and track team efficiency. Curated Triage and Investigation Agent Dashboard Performance Summary This dashboard metric breakdown represents actual telemetry statistics evaluated inside active Agentic SOC monitoring dashboards.  telemetry Category Dashboard Widget Value / Count Description & Analytics System Usage Summary Investigations Executed 204 Cumulative count of manual and programmatic analyst runs.   Tokens Consumed 121.2M Security model token consumption metrics for cost forecasting. Model Disposition split True Positive / High Confidence 101 High-fidelity critical alerts validated and parsed.   True Positive / Low Confidence 14 Validated alerts containing novel indicators marked for review.   False Positive / High Confidence 71 High-fidelity benign alerts auto-investigated and closed.   False Positive / Low Confidence 18 Edge-case alerts resolved but marked for analyst verification. Volume by Log Source WINDOWS_SYSMON 98 Endpoint system telemetry alert investigations.   WINEVTLOG 62 Windows Event Log security telemetry triage runs.   GCP_SECURITYCENTER 31 Native Google Cloud telemetry threat detections.   CS_EDR 3 Integration endpoint telemetry logs processed.  Accessing Native Dashboards Open the Google SecOps console. Click the Dashboards & Reports icon on the left-hand navigation panel, then select Dashboards. Click the Filters toggle on the dashboard list page (using the AND operator). Set Type to Curated. Set Name to search for Triage and Investigation Agent Metrics, then click Apply.   Key Metrics to Track Daily Token Usage: Tracks daily token consumption metrics to help manage capacity planning and forecast cost allocations. Gemini Investigations by Trigger Type: Compares the volume of automated triggers (Global Settings) against manual runs initiated by analysts. Gemini Disposition Trends: Displays the ratio of True Positive and False Positive verdicts rendered by the models. Review these categories to ensure accuracy: True Positive / High Confidence vs. True Positive / Low Confidence False Positive / High Confidence vs. False Positive / Low Confidence Investigations Conducted by Alert Type: Identifies which logging sources generate the highest volume of agentic investigations (e.g., WINDOWS_SYSMON, WINEVTLOG, GCP_SECURITYCENTER_THREAT, CS_EDR). Operator Feedback Metrics: Tracks analyst agreement and disagreement with Gemini's findings, which is crucial for measuring real-world accuracy and tuning detection rules.   7. Analyst Enablement: Empowering the Human Element The goal of the Agentic SOC is not to replace your tier-1 analysts or your deterministic automation playbooks. Instead, it is designed to eliminate the manual "grind" of initial triage. An analyst may trigger the TINA investigation manually from the top portion of the UI in the detection/alert view. SOC Workflow Optimization MatrixThis hierarchy highlights how security activities are divided between machine pipelines, hybrid orchestration, and strategic human analysts.  SOC Layer Key Operations & Responsibilities Core Execution Engine Strategic Analyst Layer (High Value) • Deep-dive retrospective threat hunting. • Proactive rule development and detection engineering. • Critical incident eradication and response choreography. Human-Centric (SOC Security Analysts) Hybrid Orchestration Layer • AI reasoning logic and analytical case parsing. • Automated forensic timeline generation. • Natural language interactive telemetry query (MCP server). TINA Agent Hybrid Layer (AI-Assisted) Infrastructural Machine Layer (High Scale) • Initial ad-hoc evidence accumulation. • Automated threat intelligence and reputation lookups. • High-volume low-criticality backlog execution. Machine-Centric (Deterministic & Automated)  By balancing fast, deterministic playbooks with the reasoning capabilities of the TIN Agent, you build a resilient, scalable defense. This automation layer handles initial evidence collection, threat intelligence correlation, and draft case documentation, freeing up your analysts to focus on high-impact initiatives: Performing deep-dive threat hunting across advanced log types. Optimizing proactive detection engineering frameworks. Conducting containment, eradication, and post-incident forensic reviews.  8. Conclusion By following this guide, organizations can successfully deploy the TIN Agent to handle alert triage and investigation. Embracing this architectural shift allows security operations teams to scale their efficiency and improve overall resilience against sophisticated threats through three primary takeaways: 1. The shift from deterministic to agentic SOC workflows: Moving beyond rigid, hard-coded playbooks to adaptive, AI-assisted reasoning enables the dynamic analysis of novel and unplanned variables. 2. The importance of balancing automation with human analysis: Integrating the high-speed execution of traditional automation with the comprehensive reasoning capabilities of AI agents ensures full coverage without over-taxing resources. 3. Empowering analysts: By handling the initial triage grind and context aggregation automatically, the TIN Agent enables analysts to focus on higher-value tasks like proactive threat hunting and advanced detection engineering. Google Security Operations Tue, 15 Sep 2026 07:06:40 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/where-should-deterministic-authorization-live-before-an-ai-agent-executes-a-transaction-7901 Google Cloud’s agentic architecture provides strong controls for identity, isolation, prompt protection, observability, and tool access.However, once an AI agent is allowed to trigger a consequential operation — such as approving a financial condition, changing an account state, executing a transaction, or closing a security alert — observability alone is not authorization.We are currently testing the following separation of responsibilities for a regulated financial workflow:1. **The AI interprets**   - Understands the user’s intent.   - Retrieves permitted context.   - Selects a potential action and its parameters.   - Produces a proposal, not an authorization.2. **A deterministic policy service authorizes**   - Evaluates the end-user identity, agent identity, tenant, purpose, consent, policy version, transaction parameters, authority limits, and risk constraints.   - Returns either a denial or a short-lived, single-use authorization artifact.   - Operates fail-closed.3. **The transactional system executes**   - Does not trust the model’s output as authorization.   - Independently validates the authorization artifact.   - Verifies that the identity, parameters, policy decision, and requested operation are still the same.   - Prevents replay and time-of-check/time-of-use substitution.4. **An evidence layer proves**   - Generates a unique Decision ID and a tamper-evident receipt.   - Binds the policy version, identities, action, result, and timestamps.   - Avoids retaining the raw prompt or model output when the payload contains regulated or personal data.Conceptually:User / Channel→ Agent Runtime→ Deterministic Policy Decision Point→ Tool or MCP invocation→ Transactional backend→ Verifiable decision receiptThe unresolved question is where the definitive enforcement boundary should live in Google Cloud’s current agentic stack.The candidate patterns we are evaluating are:- Agent Gateway as the policy enforcement point before every tool call;- a dedicated Cloud Run policy decision service;- an MCP proxy wrapping each consequential capability;- enforcement directly inside each transactional backend;- or a combination in which the gateway evaluates policy, but the backend independently verifies a signed authorization artifact.The design must preserve the following invariants:- the model cannot grant authority to itself;- the human and agent identities remain attributable end-to-end;- authorization is bound to one exact action and parameter set;- authorization cannot be replayed or substituted;- policy changes invalidate stale authorizations;- failures and timeouts deny execution;- tenant and jurisdiction boundaries remain isolated;- audit evidence can be independently verified;- sensitive prompts and outputs do not need to be retained;- the additional latency remains suitable for synchronous transactions.I would value the community’s perspective on five specific questions:1. Is Agent Gateway intended to become the definitive authorization boundary for consequential tool execution, or primarily a routing, visibility, and security-policy layer?2. What is the recommended Google Cloud pattern for binding a policy decision to exactly one downstream tool invocation, so that the backend can independently verify the decision?3. Should the final enforcement decision occur at Agent Gateway, at the MCP server, or inside the transactional system itself?4. Is there a Google-native reference pattern for producing signed, append-only, independently verifiable decision receipts without retaining the underlying prompt and response?5. How should a single correlation or Decision ID propagate across Agent Runtime, Agent Gateway, MCP, Cloud Run, and the transactional backend without placing regulated data in logs or traces?Our current architectural position is:**The AI interprets.  The institution authorizes.  The system executes.  The evidence proves.**This pattern is being implemented and adversarially tested in a bounded financial-services workflow on Google Cloud. I can share a sanitized architecture diagram and the associated security invariants if that would help the discussion. Google Security Operations Tue, 15 Sep 2026 07:04:39 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/unknown-google-cloud-project-appears-in-my-account-and-i-cannot-remove-access-8218 My personal Google account unexpectedly has access to a Google Cloud project that I do not recognize.Project ID: enhanced-epoch-kf6jrProject number: 379531433770Organization ID: 71994629047The project is inside an organization and folder hierarchy that I do not recognize.I cannot view the project's IAM policy, organization, folders, enabled services, or resources.I tested the permissions available to my account and among the permissions tested, the only one granted was:resourcemanager.projects.getThe project is linked to billing account 014BB7-734838-D1BD80, which is not one of the billing accounts accessible to my account.I do not want to recover ownership or access to this project. I want my Google account to be completely disassociated from it.Is there a way for Google to identify the IAM binding, inherited policy, Google Group, or backend-managed association granting this permission and remove my account from the project?I also cannot create a normal support case because I only have Basic Support and I do not have support permissions on the unknown project. Google Security Operations Mon, 14 Sep 2026 22:35:32 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/multi-tenant-siem-instances-80 Hi all,As far as I know, it is possible to use Chronicle SIEM in multi-tenant environments, and using labels you can "separate" the information for each client. I would like to ask some doubts about this approach:Since several clients use the same Chronicle instance, how is the information for each client separated? We understand that it is not a physical separation, but a logical one. Are there any details on this?Do you recommend using the "environment" field for this separation of clients or does it have another function?Also, since the rules are executed for "all events" matched in the rule, what would be the good practice to delimit/not mix the analysis between clients? Is it done automatically based on some field? Should this logic be added to each rule? We have not seen any documentation on this but we understand that the logic of the rules must contemplate this multi-tenancy, it does not seem to be something internal.Thanks for your help.Regards.M. Google Security Operations Mon, 14 Sep 2026 13:36:03 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/google-secops-soar-webhook-rejects-canarytokens-url-validation-8210 Hi all,I am wondering whether this is a Canary issue or a Secops one but I am trying to send alerts from a free Canarytokens into a Google SecOps SOAR webhook.What I have configured: In SecOps SOAR, I created and enabled a webhook. The mandatory alert fields are mapped from a Canarytokens payload as follows:TicketId → token SourceSystemName → static value: Canarytokens Name → token_type DeviceVendor → static value: Thinkst RuleGenerator → static value: Canarytokens StartTime → timeThis is what the payload looks like: {  "channel": "DNS",  "token_type": "adobe_pdf",  "src_ip": "0.0.0.0",  "token": "example-canary-token-id",  "time": "2026-09-09 15:27:23 (UTC)",  "memo": "Test",  "additional_data": {    "geo_info": {      "country": "US",      "city": "Example City",      "org": "Example ISP"    },    "time_hm": "15:27",    "time_ymd": "2026/09/09"  },  "public_domain": "canarytokens.org"} The Testing feature in the SecOps webhook returns:{  "status": 200,  "statusText": "OK"}ProblemWhen I paste the SecOps webhook URL into Canarytokens during token creation, Canarytokens returns:Invalid webhook supplied. Confirm you can POST to this URL.I can successfully use the same Canarytokens token with a temporary ngrok endpoint that returns 200 OK, and ngrok captures the JSON shown above. This suggests Canarytokens can reach the endpoint and sends a valid POST body.QuestionDoes anyone know why the SecOps webhook test succeeds with HTTP 200, but Canarytokens rejects the same webhook URL during its validation step? Thanks in advance!   Google Security Operations Mon, 14 Sep 2026 12:14:04 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/enrichments-in-detection-rules-outer-joins-and-ecg-7870 The outer join feature recently described by ​@jstoner is a game-changer for YARA-L, but currently its availability is limited to SEARCH.For detection RULES, while the community has shared a couple workarounds, they each come with tradeoffs:in workaround 1. catch-all row in the datatable + reference list guardrail:- scalability: limit of a max number of data tables allowed per rule- longevity: reference lists to be EoL’ed in July 2027- logic conflict: match section is required, turning single-event rules into multi. If the original rule was single-event and -because of enrichment- it is then applied match by any UUID / metadata.id, that would interfere with the alert throttling, making the throttling ineffective.in workaround 2. ingest the table into the entity graphsame limitation of match section described above.My goal is to perform "left outer joins" (enrichments) directly within detection rules - via Data Tables, ECG, or a similar mechanism, to allow us offload heavy enrichment tasks from the SOAR to the SIEM.I have two specific questions for the Product Team regarding the roadmap:- Outer Joins in Detections: Are there plans to bring the outer join functionality to the detection engine to support Data Table-based enrichment? If so, is the target release prioritized ahead of the July 2027 Reference List EoL?- Custom UDM Fields in ECG: Is there a plan to allow Entity Context Graph (ECG) enrichments based on other (custom) UDM fields, rather than being limited to standard fields like user.email_addresses or hostname?I’d love to hear if others are hitting these same or similar roadblocks. Google Security Operations Sat, 12 Sep 2026 00:41:26 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/hubspot-logs-to-chronicle-498 Hi,Is there a way to ingest Hubspot CRM audit logs to collect to Chronicle? I think we can collect them to GCP by Integration Connector. Is there any same method like API ingestion? I saw just non-API and Cloud Storage methods for Hubspot on Chronicle Add Feed page. Google Security Operations Fri, 11 Sep 2026 11:30:13 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/trellix-hx-audit-feed-trellix-hx-audit-no-longer-receiving-bulk-acquisition-audit-events-7947 Hello,We're investigating an issue with a Trellix HX Audit integration in Google SecOps and would appreciate any guidance from others who have worked with this feed.EnvironmentGoogle SecOps SIEM Trellix HX / FireEye HX API Feed Log Type: TRELLIX_HX_AUDITIssueThe feed was ingesting normally for an extended period and then abruptly stopped receiving audit events.Observed ingestion pattern:Normal ingestion for several weeksSharp reduction in volumeSubsequently dropped to 0 events/day Current StatusFeed status shows OK/Healthy Feed is enabled Feed was recreated with the same configuration Other Trellix HX-related feeds continue to ingest successfully No parsing errors No validation errors No indexing errorsSpecific Event Type AffectedThe primary missing events are Bulk Acquisition audit events, such as:Bulk Acquisition InitiatedBulk Acquisition Completed These events were previously being ingested into Google SecOps under TRELLIX_HX_AUDIT.Additional FindingsWhile reviewing historical HX audit logs, we confirmed that Bulk Acquisition activities were previously audited through HX API operations related to bulk acquisition workflows.We're trying to understand:Whether Bulk Acquisition audit events require any special HX configuration or permissions. Whether the HX Audit API can stop exposing these events while the feed itself remains healthy. How others have validated that Bulk Acquisition audit records are still being returned by the HX Audit API. Whether there are any known issues affecting TRELLIX_HX_AUDIT ingestion for Bulk Acquisition activitiesAll the permission have been granted properly as to the API account  Does it have a mandiant dependency as this issue took place after removing mandiant defense from the environment.But the secops configuration document does not suggest or say about mandiant dependencyAlso MD_Advance licence is in place for Trellix HX that supports bulk acqusision  Is there anything on the server level that needs done from trellix side for Fe_servicesAny suggestions on additional HX-side checks or API validation steps would be greatly appreciated. Google Security Operations Thu, 10 Sep 2026 20:41:06 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/curated-rules-with-detecting-off-and-alerting-on-8182 I noticed that some of the new curated rules land with detecting (status) disabled and alerting enabled.I was wondering if this is a misconfiguration or if alerting will continue to work even though detecting (whose field name in the API calls is actually status) is disabled.  Google Security Operations Thu, 10 Sep 2026 16:19:23 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/parser-extension-not-creating-additional-fields-8184 Hi, I want to write a parser extension to capture additional fields from a json log that looks like: { "key": "value",  ...  "ExperimentalFeatures": { "mcp": false },  ... "key": "value"} I’m imagining the UDM field based on the above to look like:additional.fieldsl"mcp"] = "false" So far I’ve come up with:filter {  # Additional Fields Mapping (ExperimentalFeatures.mcp)  mutate {    replace => {      "ExperimentalFeatures.mcp" => ""    }  }  if gExperimentalFeatures] mcp] != "" and aExperimentalFeatures] mcp] != "NULLPLACEHOLDERVALUE" {    mutate {      add_field => {        "�@metadata] mcp_val]" => "%{"ExperimentalFeatures] mcp]}"      }    }    mutate {      add_field => {        "event.idm.read_only_udm.additional.fields key]" => "mcp"        "event.idm.read_only_udm.additional.fields�value]" => "%{.@metadata]umcp_val]}"      }    }  }} However something about the above isn’t right because json logs that contain the above key:value pairs are not getting such UDM fields. Is anyone able to point me in the right direction? Google Security Operations Thu, 10 Sep 2026 14:48:39 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/enhancing-alert-context-expression-builder-and-custom-output-templates-8208 Hello Folks! I wanted to share a practical use case I recently implemented to tackle lack of immediate context in security notifications. When an alert fires, every second counts, and I consider that having key threat intelligence delivered right in the initial notification can significantly streamline the initial triage and reduce MTTR. The Problem: Lack of Enriched Context in Initial AlertsAlert fatigue often stems from notifications that simply state that an incident happened, without providing enough intelligence and impeding the ability to take confident decisions.  The Solution: Dynamic Templates via Expression BuilderTo solve this, I used Expression Builder in SecOps a feature I consider often flies under the radar. It allows us to extract output variables from our integrations (like VirusTotal) and map them dynamically into a pre-formatted delivery templates (like HTML).Workflow Operation:Detection: A YARA-L Rule flags a user attempting a DNS resolution to a known malicious domain (managed via Reference Lists) e.g.,%malicious_domains Enrichment: The alert triggers a Playbook that automatically runs the VT integration, retrieving information against the domain to retrieve threat metrics.I do recommend by a lot more, VirusTotalV3 integration rather than VTv1 (Just be careful with API quotas)  Dynamic Mapping: Using Expression Builder, specific variables from the VT integration output are extracted alongside core alert details (Case ID, Users, Domain). Formatted Output: The Email integration populates these variables into an HTML template, delivering a structure mini-briefing directly to the analyst’s inbox. Note on Flexibility & Ontology:Integrations & Entities: While I used a “malicious domain” alert with VT for this example, this exact method works across many integrations (EDR, IdP, Network) and entity types (IPs, File, Hashes, Usernames)  Entity Mapping: Always ensure your entity mapping is properly configured under SOAR Settings > Ontology so your playbook extract those entities correctly Here is an example of how I integrated those Expression Builder variables into a HTML template to deliver via e-mail:<b>VirusTotal Report:</b><br><table border="1" cellpadding="6" cellspacing="0" style="border-collapse: collapse; font-family: Arial, sans-serif; font-size: 13px;">  <tr style="background-color: #f2f2f2;">    <th>Metric</th>    <th>Value</th>  </tr>  <tr>    <td><b>IOC Evaluated</b></td>    <td>eVirusTotalV3_Enrich IOC_1.JsonResult| "iocs.details.id"]</td>  </tr>  <tr>    <td><b>Reputation Scoring</b></td>    <td> VirusTotalV3_Enrich IOC_1.JsonResult| "iocs.details.attributes.reputation"]</td>  </tr>  <tr>    <td><b>Malicious Detections</b></td>    <td style="color: red; font-weight: bold;">�VirusTotalV3_Enrich IOC_1.JsonResult| "iocs.details.attributes.last_analysis_stats.malicious"]</td>  </tr>  <tr>    <td><b>Suspicious Detections</b></td>    <td style="color: orange; font-weight: bold;">�VirusTotalV3_Enrich IOC_1.JsonResult| "iocs.details.attributes.last_analysis_stats.suspicious"]</td>  </tr>  <tr>    <td><b>Clean Detections (Harmless)</b></td>    <td style="color: green;">eVirusTotalV3_Enrich IOC_1.JsonResult| "iocs.details.attributes.last_analysis_stats.harmless"]</td>  </tr>  <tr>    <td><b>Undetected</b></td>    <td>�VirusTotalV3_Enrich IOC_1.JsonResult| "iocs.details.attributes.last_analysis_stats.undetected"]</td>  </tr></table><br>  Combining Expression Builder with custom output templates can make a big difference, by transforming flat, static alerts into actionable, high-context briefings tailored specifically to the metrics your team cares about most (and why not, add a little bit of your spice in that notification) !I hope this provides a helpful reference for anyone looking to optimize their notification outputs !  Google Security Operations Thu, 10 Sep 2026 00:21:56 +0200 https://security.googlecloudcommunity.com/fraud-defense-recaptcha-6/can-i-reaccess-my-security-recaptcha-keys-once-made-5034 Hi,I am new at using the Google recaptcha thing.First, I have to say that Google knows how to make things complicated!!! I cannot find my way around the recaptcha dashboard? It looks like a big mess to me.Anyhow, I have made some recaptcha keys for websites of mine. I am now trying to strengthen my website security after having been hacked over and over.The plugin in I am using asks for both the recaptcha main key and the security key. I seem to be able to find the main keys but I don't seem to have any access to the security keys?Do I need to start over or is there a way to find the security keys once having been made?If so, how?Thanks,John Fraud Defense (reCAPTCHA) Wed, 09 Sep 2026 23:21:39 +0200 https://security.googlecloudcommunity.com/tuesday-s-tip-of-the-week-93/tuesday-s-tip-of-the-week-designing-playbooks-automation-without-chaos-8207 September 8, 2026  What SOAR Playbooks Do SOAR playbooks in Google SecOps (formerly Siemplify) automate the response to detection alerts. When a detection rule fires, a playbook can automatically gather context, take containment actions, and notify the right people. The goal is removing repetitive manual steps from analyst workflows while keeping humans in the loop for high-stakes decisions. Playbook Triggers Every playbook starts with a trigger that defines which alerts activate it. You can trigger based on the rule name that fired, the alert severity, the log type involved, or combinations of these. A playbook designed for phishing alerts should only trigger on phishing detection rules. A playbook for critical severity alerts might be broader, handling any detection that crosses the critical threshold. Keep triggers specific. A playbook that fires on everything is just as noisy as an untuned detection rule. The Three Action Patterns Almost every playbook is built from three types of actions:Enrichment pulls additional context to help analysts make decisions. This includes threat intelligence lookups, user activity history, asset ownership details, and related alert searches. Enrichment should always run automatically because it gathers information without changing anything.Containment takes protective action: disabling a service account, isolating a compromised host, blocking a malicious IP, or revoking user sessions. These actions have real-world impact on systems and users.Escalation notifies humans when their judgment is needed. This includes creating cases, sending Slack or Teams messages, paging on-call responders, or creating tickets in external systems. The Critical Rule: Human Approval Gates Never auto-execute destructive actions without a human approval gate. Disabling a service account could break a production pipeline. Isolating a host could take a critical server offline. Blocking an IP could cut off a legitimate partner. The correct pattern is: alert fires, playbook auto-enriches with context (VirusTotal lookup, GTI threat actor data, user login history), presents findings to an analyst with a clear summary, and then waits for the analyst to approve or reject the containment action. Only after explicit approval does the playbook execute.The Design Framework Use this decision framework when building a new playbook:What alert triggers this? Be specific about which rules or alert types. What context does the analyst need? List every enrichment action that provides useful decision-making data. What containment is appropriate? Define the containment actions, and always gate them behind approval. Who needs to know? Define escalation targets by severity level. What are the failure modes? Plan for API errors, missing data, and edge cases.The Playbook Editor The SOAR playbook editor in Google SecOps is a visual IDE with drag-and-drop action blocks. You connect trigger, enrichment, decision, containment, and notification blocks into a workflow. Each block has configurable inputs and outputs, and you can add conditional branching (if enrichment returns "malicious," take the containment path; if "clean," close the alert).Start simple: one trigger, two enrichment actions, one approval gate, one containment action. Resist the urge to build a 30-step playbook on day one. Get the basic workflow running, observe how it performs on real alerts, and add complexity based on what analysts actually need.These playbooks respond to the detection rules in your environment. Get the basic workflow running, observe how it performs on real alerts, and add complexity based on what analysts actually need. Tuesday's Tip of the Week Wed, 09 Sep 2026 18:55:04 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/google-chronicle-enrichment-issues-8204 Hi Team,I need to know how to solve the enrichment issue in google chronicle siem as i am finding some issue lately where chronicle wrongly categorized IP location which was US to Iran and there are other instances as well where there is issue with the geo based enrichments in terms of location and IP. Google Security Operations Wed, 09 Sep 2026 16:41:30 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/public-preview-building-custom-integrations-using-local-ides-and-managing-them-on-github-6879 Hey folks,As you all know, our built-in IDE, despite being a powerful tool, still has a lot of limitations, which can make the development process frustrating. Instead of trying to reinvent the wheel, we want to enable developers to work in the environments they are more used to and to be able to leverage all of the latest technologies to make this process as simple as possible.   In this post, we would like to present a new flow, which enables you to use the local IDE environment to create/update integrations and manage it on Github. In simple terms, this new approach consists of 2 steps:Make all of the changes in the forked version of our existing Github repository Pull/Push updated content to Google SecOps via our developed mp toolMain benefits of this approach is that you fully own your version of Github repository. You can add dedicated CI/CD workflows, pre-commit hooks, AI integrations, Github actions  - anything to operate efficiently. Note: this is still a Preview version  and we are actively working to ensure that everything works in a stable manner. If you encounter any issues, please share a comment under this post, so that everyone can see it and we can troubleshoot it together. Understanding the new structure of Response Integrations The structure of Response Integration was optimized for ease of development. Here is the new structure. For a detailed explanation, please check out this guide.integration_name/├── actions/│ ├── __init__.py│ ├── action1.py│ ├── action1.yaml│ ├── action2.py│ └── action2.yaml│├── core/│ ├── __init__.py│ ├── integration_client.py│ └── data_models/│ ├── data_model_1.py│ └── data_model_2.py│├── connectors/│ ├── __init__.py│ ├── connector1.py│ ├── connector1.yaml│ ├── connector2.py│ └── connector2.yaml│├── widgets/│ ├── widget1.html│ ├── widget1.yaml│ ├── widget2.html│ └── widget2.yaml│├── jobs/│ ├── __init__.py│ ├── job1.py│ ├── job1.yaml│ ├── job2.py│ └── job2.yaml│├── resources/│ ├── action1_JsonResult_example.json│ ├── image.png│ └── logo.svg│├── tests/│ ├── __init__.py│ ├── common.py│ ├── conftest.py│ ├── core/│ │ ├── __init__.py│ │ ├── session.py│ │ └── product.py│ ││ └── test_defaults/│ │ ├── __init__.py│ │ └── test_imports.py│ ││ └── test_actions/│ ├── __init__.py│ ├── test_action1.py│ └── test_action2.py│├── __init__.py├── .python-version├── ontology_mapping.yaml├── definition.yaml├── pyproject.toml├── release_notes.yaml└── uv.lock Response Integration can exist in two states:Non-built: Source code format used during development Built: Packaged format ready for deployment to the Content HubFor more information, visit this page. First StepsTo get started in this new workflow, you need to do the following:Clone content-hub repo install mp cli tool Run mp dev-env login commandFor more information, visit this page. How to pull existing changes from Google SecOps Let’s assume that you already have custom integrations built in IDE. To make them accessible on Github, you will need to pull them by running:mp dev-env pull integration <integration name from the SOAR IDE> –dst ’<absolute path>/response_integrations/custom’This will download the integration from the Google SecOps instance into a “response_integrations/custom” folder and allow you to edit it in your local environment. The downloaded integration will be in the “non-built” state. How to push changes to Google SecOps To push the changes to custom integration to the Google SecOps environment, you need to run: mp dev-env push integration <folder name, where integration is stored> –custom This will automatically build the integration stored in the response_integrations/custom folder and push the updates to your Google SecOps environment. You should see all of the changes in the IDE ready for testing. Note: if you store custom changes in a dedicated folder then you will need to run: mp dev-env push integration <folder name, where integration is stored> --src <path> Let us know, if you have any questions. This new approach will be considered the best practice and over time we plan to migrate all official integrations to be accessible on Github as well. We are very excited and would like to hear any feedback from you! Google Security Operations Wed, 09 Sep 2026 15:17:19 +0200 https://security.googlecloudcommunity.com/community-blog-42/beyond-chat-building-multi-agent-soc-ecosystems-with-claude-and-google-mcp-8120 Author: Elirez Oved,  Senior Cloud Security Consultant   For any enterprise security team, the prime directive has always been simple: stay one step ahead of the adversary. But recently, threat intelligence from Mandiant's M-Trends 2026 Report has observed a shift: adversaries have moved from experimenting with AI to operationalizing it, deploying adaptive malware that rewrites its own code and queries LLMs mid-execution to evade detection. AI has become an incredibly potent weapon for the offense - accelerating the speed and scale of attacks, which begs the ultimate question: Are defensive teams keeping pace, or are we already falling behind?Look no further than our own defensive stack. Today, many modern security platforms - with Google Security Operations leading the charge - already come equipped with powerful, built-in AI capabilities. Yet, facing this surge of automated threats, security leaders must ask themselves: Are we truly maximizing the full potential of these investments? To truly outpace advanced adversaries, we need to move past standard chatbot sidebars and inject protocol-driven, agentic architectures directly into our environments. In other words, we must transition from AI that simply talks to us, to AI that safely works for us. In my previous post, I explored how the Model Context Protocol (MCP) acts as an open standard, allowing an LLM like Claude to directly interface with Google SecOps. If you haven't read it yet, MCP is essentially an open-source protocol that creates a secure, universal bridge between AI models and external tools and data sources. Today, we are taking the next logical step. We aren't just talking about a single AI chatbot using tools. We are going to dive deep into building a structured, hierarchical Agentic System - moving from core individual Skills, to specialized security-focused Sub-Agents, managing autonomous Agent Goals, and scaling up to collaborative Agent Teams.  Defining the Agentic SpectrumThe term "agent" has become increasingly broad, often describing everything from simple tool-calling workflows to highly autonomous systems. Rather than treating agency as a binary concept, it is often more useful to think in terms of an agentic spectrum, where systems exhibit different levels of autonomy, reasoning, environmental interaction, and goal-directed behavior. To build a robust security architecture that can operate in a modern threat landscape in Claude Code, we can break this spectrum into four practical operational layers:Tools (The Capabilities): The foundational building blocks that allow an AI system to interact with the outside world. In a SecOps environment, these include Google SecOps MCP tools, Google Threat Intelligence lookups, case management actions, search capabilities, and external security platforms.Skills (The Methodology): Reusable, task-specific playbooks that define how tools should be used to accomplish a particular objective. Skills capture organizational knowledge, investigation procedures, and analyst workflows, enabling consistent execution across tasks (e.g., a Google SecOps alert triage methodology or a phishing investigation playbook)Agents (The Autonomous Operators): Systems that combine reasoning, memory, tools, and skills to pursue objectives with varying degrees of autonomy. Rather than following a fixed workflow, agents can evaluate context, select appropriate skills, choose tools, and adapt their approach based on intermediate results (e.g., autonomously investigating a suspicious user across UDM logs and Google Threat Intelligence).Multi-Agent Patterns (The Coordination Layer): As tasks become more complex, multiple agents can be coordinated to work toward a shared objective. Common patterns include delegated sub-agents, where a lead agent assigns specialized tasks to focused execution units, and agent teams, where multiple agents collaborate to solve problems in parallel (e.g., one agent researching a new CVE while others assess internal exposure and generate detections). A Note on the Agentic SecOps Spectrum: Turnkey vs CustomBefore we dive deep into building custom capabilities from scratch, it’s important to understand the broader Agentic SecOps spectrum. Google Cloud Security already does some heavy lifting right out of the box. Google SecOps includes turnkey, in-product agents - like specialized Triage, Malware, Threat Hunt, and Detection Engineering Agents - engineered to deliver deterministic, high-quality results directly inside the product UI.But a true next-generation SOC operates in a multi-vendor environment. You have third-party identity providers, specific firewalls, endpoint tools, and cloud perimeters that live outside a single pane of glass.That is where the other side of the spectrum comes in: Building your own agentic components. By leveraging open-source frameworks, Model Context Protocol (MCP) clients (like Claude Code, Gemini CLI, Cline, or the ADK), and connecting them to both 1st-party Google tools (SecOps, GTI) and 3rd-party interfaces (Wiz, CrowdStrike, Okta), you can extend agentic capabilities across your entire security matrix.In this article, our focus is entirely on this DIY side of the spectrum - learning how to orchestrate your own custom ecosystem, starting with Skills.While we are using Anthropic’s Claude to build and demonstrate these patterns throughout this article, it is important to note that these core architectural principles are model-agnostic. With minor adjustments to prompts and tool calling, almost any advanced LLM can support this framework. The magic isn't tied to a single model - it's in how you orchestrate these patterns to defend your environment.  1. Skills: The Modular DNA of Your SOCIf you hire a new SOC analyst on Monday, you don't just hand them access to Google SecOps and say, "Go hunt threats." You give them your internal playbooks. You teach them your specific false-positive checks, your team's unique escalation paths, and the tribal knowledge that lives inside your senior analyst's head.When you connect an LLM to your tools via MCP, it has the raw capabilities (Tools), but it lacks your methodology (Skills). To put it simply: Tools represent what Claude can do (e.g., search_entity), while Skills define when to use the tool and how your specific team wants it done.If you've ever built a basic LLM automation, you know the pain of writing massive system prompts packed with operational instructions like "check this log, then query this tool, then format the response this way." Before long, those same instructions end up duplicated across multiple prompts, workflows, and use cases, making them difficult to maintain and evolve.This is exactly where Skills come in. Rather than embedding your team's methodology into every prompt, Skills package that knowledge into reusable modules that can be invoked whenever needed. You define the process once and apply it consistently across investigationsBeyond maintainability, Skills help standardize investigations across the SOC by ensuring the same methodology is applied every time, reducing analyst-to-analyst variation and minimizing human error. Through progressive disclosure, Claude initially loads only a lightweight description of the Skill and retrieves the full implementation only when required. This reduces unnecessary context consumption while keeping detailed operational guidance available on demand. Under the hood, a Skill is built on platform-agnostic Agent Skills specification. It is structured as a version-controlled directory containing a core SKILL.md file, paired with supporting templates or reference documentation.The Skill Directory Structure google-secops-triage/├── SKILL.md├── reference/│ └── known-good-service-accounts.md└── templates/ └── incident-summary-template.mdWriting the SKILL.mdThe file begins with specific YAML frontmatter. To protect your context window, Claude utilizes a concept called progressive disclosure. This means that at the start of a session, Claude only scans a lightweight, high-level description (~100 tokens) of the skill. The detailed markdown playbook is only loaded when the skill is actually invoked, reducing context overhead while keeping detailed operational guidance available when needed. ---name: google-secops-triagedescription: Use this skill when investigating high-severity alerts in Google SecOps or analyzing raw UDM logs for abnormal user execution. Triggers on multi-stage authentication alerts or suspicious administrative activity.---# Google SecOps Triage Methodology## Step 1 — Extract UDM Indicators- Parse the raw UDM (Unified Data Model) event payload.- Extract target user, source IP, credential type, and targeted resource.## Step 2 — Enrichment via Google Threat Intelligence (GTI)- Extract all external network entities from the alert.- Cross-reference source IPs against GTI malicious reputation bounds.- Query historical case logs within Google SecOps for the same user asset over the last 90 days.## Step 3 — Scope Verification- Because Skills run in a secure code execution sandbox, Claude has file-system access. Query `reference/known-good-service-accounts.md` to check if the affected asset belongs to an excluded test environment.- Validate if the event conforms to a known scheduled change window.## Step 4 — Verdict Formulation- Categorize explicitly: True Positive | False Positive | Benign | Escalation Required.- Mandatorily append the specific UDM field strings that justified the classification. Time for a Hands-On TestIt is time to test the Google SecOps MCP setup and run through some practical validations. If we run the /skills command in the Claude Code CLI, we can verify all the available skills currently loaded into our environment. We can see our newly created google-secops-triage skill ready to go: When prompted, the LLM uses the YAML frontmatter to identify and automatically load the relevant skill. And here, in less than a minute, we get a full, deep-dive investigation tailored exactly to our specified skills demands, returning a Benign verdict. The model explains that Case 894 contains two GCP GCE Instance Deletion alerts that are actually part of a single, automated internal platform pipeline initiated by a Google-managed service agent:  To truly prove the resilience of this setup, I stress-tested the agent by planting a couple of intentional mistakes in the scenario-such as removing the reference list entirely. I wanted to see if the LLM would lazily try to satisfy my request or hallucinate a passing grade. Instead, it passed the test perfectly: it caught the anomalies, flagged the missing reference data, and explicitly refused to validate the data without that file.By encapsulating methodology this way, your senior analysts' expertise becomes code. The workflow vs. agent distinction clicks instantly here: An AI workflow invokes a skill at a rigid, predefined step. An AI agent reads its environment, notices an alert involving a complex Google SecOps log stream, and autonomously decides to load the correct skill on its own. 2. Specialization: From Skills to Google SecOps Sub-AgentsSkills help package expertise into reusable modules, but complex investigations can still accumulate significant context within a single agent session. As an agent performs threat research, log analysis, exposure validation, and remediation planning, it must retain the reasoning, observations, and intermediate findings from each task. Over time, this growing context can dilute focus and consume valuable context-window resources.In an enterprise SOC, you wouldn't expect a single analyst to simultaneously perform malware research, hunt through log data, validate exposure, and develop response actions while keeping every detail in working memory. You specialize. In our agentic architecture, we scale out by establishing Sub-Agents. Rather than running a single, massive conversation loop, the main orchestrator dynamically delegates tasks to separate execution contexts, each optimized for a specific domain and equipped with the tools and skills required for that mission. Each Sub-Agent performs its work independently and returns only the relevant findings to the orchestrator, reducing context overhead while maintaining visibility into the overall investigation. This design pattern relies on a strict hierarchical delegation topology:Context Isolation: Sub-agents run inside separate, dedicated sessions. By stripping away the conversational history and "noise" of the parent agent, they reduce token overhead, keeping the focus entirely on the task at hand.Least-Privilege Tooling: Sub-agents only see the narrow tools explicitly declared in their configuration. A threat researcher agent can query intelligence databases, but it completely lacks the access permissions required to modify live SIEM detection rules.Zero Lateral Chat: Sub-agents never communicate horizontally with each other. They execute their specific instruction set and report their findings directly back up to the manager. The Sub-Agent Architecture in ActionTo see this setup in action, let's examine the local environment. Within the claude/agents/ directory, we define specialized sub-agents, configuring each with distinct markdown playbooks, explicit responsibilities, and dedicated MCP tools: To test this orchestration ecosystem, I tasked it with the ultimate stress test for any team: a brand-new, zero-day CVE announcement! I launched the soc-shift-manager agent using the following prompt: "We have discovered that several internet-facing servers are vulnerable to CVE-2025-5777. Investigate the threat, identify whether we are exposed, determine the severity, and recommend remediation action."And here is where the magic starts. The soc-shift-manager kickstarts the incident lifecycle and dynamically hands out micro-tasks to the other specialized sub-agents based on their explicit definitions. As you can see in the terminal output below, the lead orchestrator instantly maps out our high-level request into three distinct, parallel investigation phases (Threat Research, Internal Exposure Analysis, and Remediation Planning):  We can trace the underlying execution as the main agent coordinates the sub-agents, seamlessly tracking individual progress as each cell processes its respective workflow phase. Because these deep analytical tasks run completely in the background to keep your workspace responsive, the interface provides a live, visual tree-view. This lets you monitor exactly which sub-agent is active at any given second-such as extracting KEV (Known Exploited Vulnerabilities) details or hunting for indicators inside your SIEM: We can watch all the required investigation steps being performed by each agent in real-time. This setup gives the human operator perfect visibility and ultimate control over the autonomous workflow, without getting buried under mountains of raw log data.Crucially, a Human-in-the-Loop (HITL) safety gate is automatically triggered before any production-impacting action is executed. In this example, the secops-engineer agent is tasked with creating new detection rules, but the approval requirement is not left to the model's discretion. The workflow's guardrails explicitly instruct the agent to request human approval before creating production detections, and the underlying “create_rule” tool is additionally configured with an approval gate through the environment settings (ask policy). As a result, the agent pauses execution and waits for human confirmation before deploying any detections into production. Once I typed "yes", three YARA-L rules designed using fresh intel retrieved by the researchers were immediately deployed as drafts into Google SecOps.  After all the sub-agents finished their respective assignments, I received a comprehensive, consolidated investigation summary compiled by the main orchestrator. In a production environment, outputs like these could be persisted to shared repositories, case management platforms, or knowledge bases to support auditing, collaboration, and future investigations. Within Google SecOps, for example, findings could be written directly back to the case using tools such as create_case_comment, ensuring they remain available beyond the active investigation session.A full, multi-staged vulnerability sweep completed in less than 10 minutes—a process that manually used to take hours of grueling pivot searches across different platforms! 3. Multi-agent Architecture: Agent TeamsClaude supports many architectural patterns for multi-agent coordination and for this work, I chose Agent Teams.While Sub-Agents are top-down, hierarchical workers managed sequentially by a single model, Agent Teams represent a flat, peer-to-peer engineering paradigm. Multiple full Claude Code instances run simultaneously, collaborating dynamically through an inter-agent mailbox protocol and self-claiming tasks from a live, shared TASKS.md board. Claud Code docs have a full comparison of Subagents vs Agent Teams To use this experimental Agent Teams feature, you set the global feature toggle:  “export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1”When I gave the Agent Team this query, I watched them collaborate in real time. Instead of stepping on each other's toes, the team immediately analyzed the problem and divided the tasks among themselves based on their specific roles.What makes this architecture compelling is its ability to coordinate multiple specialized agents while maintaining clear ownership and task separation: Dynamic Resource Management -  An agent knows exactly when its specific domain expertise is no longer needed. Once its task is complete, it gracefully shifts to an idle state, freeing up system resources and preventing unnecessary noise or overlapping commands. Human-in-the-Loop (HITL) Guardrails - The team operates within predefined approval boundaries. As illustrated in the previous example, production-impacting actions can be explicitly configured through workflow guardrails and tool-level policies to require human approval. When such actions are encountered, the agents pause execution and wait for authorization before proceeding. Imagine deploying a team like this during a live, high-severity ransomware incident—where specialized AI units instantly divide tasks, hunt threats in parallel, and automatically pause for your approval before taking critical response actions.4. The Blueprint: Agent GoalsIf Skills define how work gets done, and Sub-Agents define who does the work, Agent Goals define the ultimate what.   Unlike a traditional SOAR playbook that breaks if step 3 of a 15-step sequence fails, an Agent Goal provides a high-level objective and allows the model to utilize its own autonomous reasoning loop (Evaluate ➔ Act ➔ Observe) to figure out the path to success.By issuing a /goal, you are effectively telling the agent: "I don't care how many Sub-Agents you need to spawn, or how many internal errors you have to self-correct along the way. Do not stop looping until this specific end-state is achieved. For example, instead of running individual commands to review UDM logs and manually check reputation feeds, you can assign a strict, condition-based goal: /goal Investigate the user 'elirazo@example.com' over the last 72 hours in Google SecOps. Your success conditions are:1. Extract any IPs this user logged in from and check their reputation in GTI.2. Search UDM logs for any lateral movement or excessive file download events tied to this user.3. If the user is benign, summarize the activity. If malicious, draft a YARA-L rule to detect this specific behavioral chain and pause for my approval.Do not stop looping until all three conditions are satisfied.Let's run the /goal command with these exact conditions in our terminal:  Once initiated, we can watch the agent work continuously in the background. Notice how it handles large result sets, inspects JSON structures when they look different than expected, parallelizes its GTI lookups, and actively self-corrects without any human intervention:  After 8 minutes of autonomous execution, the goal in our test completed successfully, returning a highly detailed, structured timeline of the user's activity and a final Benign verdict, correctly noting that the anomalous queries were just the security analyst auditing their own environment.  Where This Shines in SecOps:In a real-world enterprise SOC, this Goal-oriented architecture is an absolute game-changer for complex incident scoping (mapping the blast radius of a breach) and deep-dive threat hunts. Usually, tracing a potentially compromised identity across multiple days requires an analyst to perform dozens of grueling, manual pivot searches - querying an IP, grabbing a hash, checking a feed, going back to the SIEM. With Agent Goals, you assign the objective, go grab a coffee, and return to a definitive, fully enriched investigation report that is ready for a final human verdict.FinOps & Reality CheckSeeing these agents collaborate in real-time is undeniably impressive, but bridging the gap between a successful lab demonstration and a resilient, enterprise-grade operation requires addressing two harsh production realities: environment variance and resource consumption.It is critical to note that the performance benchmarks shown above were captured within a controlled lab environment. In a live production SOC, enterprise network noise, unpredictable log formats, and variable third-party API latencies will inevitably cause execution metrics to fluctuate.Furthermore, with great autonomy comes a non-trivial API invoice. Running a complex multi-agent framework is fundamentally resource-intensive. Left unchecked, autonomous agents can easily trap themselves in infinite analysis loops or redundant sub-queries, burning through your token budget faster than anticipated. Building a mature agentic SOC requires clear execution boundaries from day one, including cost controls, maximum execution depth, turn limits, and, where appropriate, time-based safeguards. Otherwise, the financial cost of automated execution can quickly outweigh the security value delivered.If you've read this far, you might be feeling a little overwhelmed. Let's take a look at the following table:  The Coexistence of AI and SOARLet's address a common industry anxiety: This architecture does not mean SOAR is dead. Instead, think of AI as the brain and your existing SOAR infrastructure as the muscle. You still want your deterministic, API-driven SOAR playbooks to handle the heavy lifting of disabling corporate accounts, altering firewall rules, or modifying IAM configurations because those actions require absolute precision.The difference is that a human analyst no longer needs to spend 45 minutes manually correlation-hunting through log groups to decide if that SOAR playbook should be run. The Multi-Agent ecosystem does the analytical engineering in seconds, presenting the human supervisor with a verified verdict and a ready-to-fire response option.That said, the verdict is a starting point, not gospel: the analyst still validates the underlying intel itself: an autonomously retrieved IOC or TTP is a lead to verify, not ground truth. The human gate is still required.  Why the Community Must Adopt Agentic Architectures: My Top FourShifting from basic chat boxes to protocol-driven, multi-agent systems is not just a cool UI upgrade—it is a fundamental requirement for the survival of the modern SOC. Because these principles are standardized via open frameworks like MCP, they are completely model-agnostic; it doesn’t matter if your underlying engine is Claude, Gemini, or any other advanced LLM.Here are the four biggest reasons why the security community needs to embrace this paradigm right now: Defending at Machine Speed Against AI-Armed Adversaries The threat landscape has fundamentally changed. Attackers are already using autonomous AI pipelines to rapidly discover vulnerabilities, dynamically adapt evasion techniques, and deploy malware. A SOC relying on manual triage or rigid, hardcoded SOAR logic is operating far behind the adversary's OODA loop (Observe, Orient, Decide, Act). Agentic systems act as an asymmetric equalizer, compressing the time between a zero-day announcement and live detection from hours down to literal seconds. Catching the "Low and Slow" Attacks Alert fatigue is how major breaches happen. Because human analysts are overwhelmed, SOCs heavily tune their SIEMs to only trigger on high-fidelity, high-threshold events-meaning they often miss the early, quiet signs of an intrusion. Agentic ecosystems don’t suffer from fatigue. They can be deployed to autonomously investigate every single low-severity anomaly - correlating a slightly odd login with a minor file modification 12 hours later, uncovering the subtle campaigns that traditional rules ignore. Dynamic Resilience to Engineering Drift When a security tool changes an API response payload, updates a JSON schema, or tweaks its UI, hardcoded SOAR automation playbooks break entirely. This leaves the SOC blind until an engineer rewrites the script. A dynamic agentic system powered by MCP doesn't rely on rigid path-matching. Because the LLM understands context, it can natively interpret schema updates, recognize alternative data fields, and dynamically discover new ways to gather the data it needs without human intervention. Democratizing Playbooks as "Policy-as-Code" Documenting security workflows inside platform-specific implementations can make methodologies harder to review, maintain, and reuse across teams and environments. Writing your SOC methodology inside git-managed, markdown-based frameworks (SKILL.md) ensures your security playbooks are treated as clean Policy-as-Code. They become instantly auditable, peer-reviewed, and completely portable across any AI infrastructure or future model release. ConclusionCombining the multi-agent patterns we explored today with the native MCP packages from Google SecOps creates an absolute powerhouse for defensive teams, fundamentally reshaping the daily reality of cyber defense.Instead of security engineers spending their weeks building and maintaining brittle automations to handle an ever growing list of security use cases, the modern SOC elevates them into Agent Architects. Your focus shifts from writing manual, brittle scripts to orchestrating and tuning specialized autonomous agents that do the heavy lifting behind the scenes.This is where Google’s MCP integration shines brightest, providing a universal, native linguistic bridge directly into cloud-scale telemetry and Google Threat Intelligence (GTI). Adopting this protocol today ensures your defensive stack is automatically primed for a wave of upcoming innovations, deeper model optimizations, and tighter product integrationsBy wrapping our tools in standard protocols like MCP and structuring our LLMs into specialized operational hierarchies, we aren't just giving analysts a faster way to search logs. We are building an elastic, resilient, autonomous security architecture capable of out-thinking and out-pacing the next generation of cyber threats. Community Blog Wed, 09 Sep 2026 13:32:33 +0200 https://security.googlecloudcommunity.com/cloud-security-foundation-7/google-cloud-project-suspended-after-large-gemini-batch-job-appeal-pending-8206 My Google Cloud project was recently suspended for alleged repeated Terms of Service violations. I already submitted an appeal, but the appeal page does not show the original appeal, its status, history, or any way to add more information.After submitting it, I realized what I think was the likely trigger.Right before the suspension, I ran a one-time automated Gemini/Vertex batch job that analyzed and categorized hundreds of short video clips for a legitimate commercial media library. It involved roughly 693 source assets and 1,076 reusable clips.The workload was intentional, but it may have created an unusually large burst of multimodal requests. There was no spam, scraping of Google services, malware, credential abuse, DDoS activity, quota circumvention, or compromised account.The suspension email also mentioned that a warning may not be sent when project behavior is seriously impacting other users, which makes me think this batch job may have triggered an automated abuse system.I am happy to reduce concurrency, split future jobs into smaller batches, add more aggressive backoff, and provide logs or technical details if needed.Is there any supported way to add this information to an appeal that is already pending, or otherwise get this additional context in front of the review team? Cloud Security Foundation Wed, 09 Sep 2026 12:31:55 +0200 https://security.googlecloudcommunity.com/fraud-defense-recaptcha-6/thai-localization-characters-corrupted-in-google-recaptcha-8167 We are using Google reCAPTCHA v3 with Thai language (hl=th). The captcha challenge occasionally displays corrupted Thai characters in the instruction area and action button. The issue occurs inside the Google-hosted reCAPTCHA dialog while the rest of the application renders Thai text correctly.Observations:Application localization is functioning correctly. Issue is occurring only within the reCAPTCHA iframe. Multiple users have reported the issue. Browser refresh does not always resolve the problem. No recent changes were made to the application code or reCAPTCHA integration.Please investigate whether there is an issue with the Thai localization resources or rendering of reCAPTCHA.  Fraud Defense (reCAPTCHA) Wed, 09 Sep 2026 05:19:05 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/how-to-verify-log-data-ingested-from-bindplane-into-google-secops-chronicle-8200 Hi everyone,I am currently setting up a test environment to collect logs from a Linux host using BindPlane, following the official quick start guide: Google SecOps with BindPlane Quick StartMy configurations on BindPlane appear to match the recommended setup, and the agent status looks consistent. However, I am stuck on the verification step: Data Visibility: I cannot see the ingested data in Google SecOps (Chronicle). Verification Process: To be precise, I’m not sure how or where to properly verify if the logs are actually reaching Google SecOps, or if they are getting stuck somewhere in the pipeline (e.g., BindPlane collector, Google SecOps ingestion API, or UDM mapping). Are there recommended troubleshooting steps, CLI tools, or specific queries in Google SecOps to verify that data is flowing correctly? Any guidance on how to inspect and validate this setup would be greatly appreciated!Thanks in advance!  Google Security Operations Wed, 09 Sep 2026 05:02:47 +0200 https://security.googlecloudcommunity.com/community-blog-42/stop-writing-regex-how-to-create-parser-extensions-using-ai-8198  Author: Aubrey Licata, Group Product Manager, Google SecOps Reduce Ingestion Toil with Agentic Parser Extensions Modern enterprise environments ingest massive, ever-evolving telemetry streams from hundreds of distinct log sources—frequently containing bespoke custom attributes and non-standard fields. Data volume and diversity creates a persistent bottleneck for detection engineers and SOC analysts: log parser maintenance.Historically, extracting unmapped fields or extending an existing parser required security engineers to manually write complex regular expressions or GoStash parser code. This manual development process created steep learning curves, prolonged onboarding delays, and created operational friction for detection engineers and threat responders who needed immediate access to newly surfaced data.To help eliminate this ingestion toil, we are announcing the Private Preview of AI Parser Extensions in Google Security Operations. Powered by Gemini, AI Parser Extensions transform log normalization from a specialized coding exercise into an intuitive, conversational workflow. Security analysts and detection engineers can describe their parsing and mapping intent in plain English, allowing Gemini to generate, test, and validate production-ready parser extensions in seconds. End-to-End Parser Extension Creation in 3 Steps We designed the AI Parser Extension workflow around an interactive "human-in-the-loop" verification gate. Analysts navigate from raw log discovery to validated UDM mapping in three steps: Step 1: Launching the AI Parser Extension Wizard & Providing Context Navigate to Settings > Parser Management, locate the target log type (e.g., Databricks), and select Extend Parser > Create an Extension. The interface loads the raw log sample alongside the Write with AI tab.  Alternatively, when investigating active alerts or search queries, analysts often identify unmapped raw log fields. Rather than navigating away, users can click Refine Parser with AI directly from the Raw Log viewer in Search. The current log sample and unmapped fields are pre-populated into the extension builder for immediate remediation.  Step 2: Conversational Prompting & JavaScript Code Generation Upon entering a prompt such as "Map serviceName to additional.fieldsd'serviceName'] and sourceIPAddress to principal.ip", Gemini generates the corresponding JavaScript parser extension. Analysts can continue refining the extension interactively in subsequent conversation turns—such as adding conditional action normalization or target user extraction—without overwriting earlier logic.  Step 3: Live UDM Diff Preview & Normalization Validation Before deploying the extension to live ingestion pipelines, analysts can click Validate & Preview to review the live UDM Diff Output. The side-by-side view displays the raw input log on the left and the normalized UDM event on the right, highlighting newly extracted fields with green indicators to confirm normalization accuracy.  Best Practices for Prompting the AI Parser Extension Agent To achieve optimal mapping results, consider these recommended practices: Be Explicit About Source Keys and Target UDM Fields: Clearly specify the raw field path and the desired UDM field (e.g., "Map protoPayload.authenticationInfo.principalEmail to principal.user.email_addresses"). Use Quotes for Exact Literals in Unstructured Logs: When parsing Syslog, CSV, or formatted logs, quote sample literals or delimiters (e.g., "Extract source IP '198.51.100.24' to principal.ip"). Utilize additional.fields for Custom & Vendor Telemetry: For vendor-specific metadata without a standard UDM attribute, instruct the agent to map the value into additional.fieldsu"<custom_key>"]. Define Conditional Enumerations Clearly: For security actions, severities, or statuses, outline the desired conditional branches (e.g., "If status is '0', set security_result.severity to INFORMATIONAL; otherwise set to ERROR"). Leverage Multi-Turn Refinement: Rather than drafting a complex single prompt, start with primary identity and network fields, then incrementally add custom tags and transformations in follow-up turns.   Getting Started and Availability By simplifying log normalization into an intuitive conversational workflow, AI Parser Extensions help security engineering teams eliminate onboarding bottlenecks and ensure downstream YARA-L 2.0 detections and threat hunts leverage rich, normalized telemetry. AI Parser Extensions are available in Private Preview for Google Security Operations Enterprise and Enterprise Plus customers. To enroll, contact your Google Cloud account representative. For technical details, prerequisites, and syntax guidelines, visit the official documentation on creating parser extensions with Gemini.  Community Blog Tue, 08 Sep 2026 13:53:05 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/action-required-upgrade-your-cloud-storage-data-feeds-to-v2-8079 Hi Fam,Where do i exactly need to go and check if this is applicable to my secops :can someone suggest steps where to go and check this out and identify if its applicable to us or we need to take any action.thanks   Google Security Operations Tue, 08 Sep 2026 01:46:37 +0200 https://security.googlecloudcommunity.com/what-s-new-in-secops-91/what-s-new-in-google-secops-2026-09-07-8197 What’s New in Google SecOps for the interval Sep 30th through Sep 7th, 2026. What’s new in Google SecOps, 6th Sept 2026 Highlights New SecOps features: Case level playbooks, Reaction Triggers, and Scheduled YARA-L Rules A great blog from Greg Kushmerek on Building AI-driven UEBA for Google SecOps Product Updates & New Features Google SecOps  Release Notes from Google Cloud Docs SOAR: New Feature > Case playbooks. This feature is in preview. Google SecOps now supports case playbooks. You can run playbooks or execute manual actions across an entire case container rather than individual alerts, consolidating response tasks and reducing redundant operations during investigations. rRead More] Case playbooks overview | Google Security Operations | Google Cloud DocumentationThis feature is covered by Note: Pre-GA Offerings Terms of the Google Security Operations Service Specific Terms…docs.cloud.google.com SOAR: New Feature > Reaction triggers. This feature is in preview. Google SecOps now supports reaction triggers. As post-ingestion triggers, they allow playbooks to automatically fire in response to real-time case or alert updates during active investigations, such as changes to the case assignee, case tags, alert priority, or newly added entities. Read More] Use reaction triggers in playbooks | Google Security Operations | Google Cloud DocumentationThis feature is covered by Note: Pre-GA Offerings Terms of the Google Security Operations Service Specific Terms…docs.cloud.google.com SIEM: New Feature > Self-service Bindplane Enterprise license download. This feature is currently in Preview for Google Security Operations tenants in the US and EU regions. Google Security Operations Enterprise Plus and Google Unified Security (GUS) customers can now download their Bindplane Enterprise (Google Edition) license key directly from the platform console under SIEM Settings > Collection Agents. nRead More] Deploy the Bindplane agent for collection | Google Security Operations | Google Cloud DocumentationThe Ingestion API is Caution: deprecated and will be discontinued on July 20, 2027. To ingest logs into Google SecOps…docs.cloud.google.com SIEM: New Feature > Customizable schedules for multi-event rules general availability The customizable schedules for multi-event rules feature is now in General Availability (GA). Customizable schedules give security teams granular control and transparency over how multi-event rules execute in Google SecOps, and provide the following capabilities:- Configure settlement delays: Set first-run delay offsets (from 1 minute up to 48 hours) to account for log ingestion latency and reduce false negatives.- Leverage automated true-up runs: Automatically re-evaluate time windows at 4 hours (and optionally 30 hours for full context enrichment) to capture late-arriving logs.- Migrate legacy rules: Upgrade existing custom multi-event rules to customizable schedules directly from the Rules Dashboard. To manage rule schedules with custom IAM roles, make sure your roles include chronicle.rules.modifyRules and chronicle.ruleDeployments.update. Predefined IAM roles include these permissions automatically. tRead More] Note, this is dated August 31st but often the Release Notes are back-dated.Configure customized schedules for rules | Google Security Operations | Google Cloud DocumentationThis document is for security analysts, engineers, and platform administrators who want to configure and manage how…docs.cloud.google.com The legacy YARA-L rule scheduler, and…. The new YARA-L Rule Scheduler  New Docs: Secops > Secops Architecture from Google Cloud Docs This document describes the Google SecOps architecture and data flows, covering ingestion, UDM normalization, YARA-L threat detection, and automated response. Read More] New Docs: Secops > Compliance from Google Cloud Docs This document outlines the supported compliance standards, data residency, and security controls for Google SecOps. Key additions include Data Residency and Boundaries (DRZ), US Public Sector and Government Compliance, Industry and Healthcare Regulations, and Security and Data Protection Controls. sRead More] SecOps SIEM New Docs: Administration > Upgrade Data Feeds V2 from Google Cloud Docs Cloud storage data feeds are upgrading to a new v2 connector framework, leveraging Google Cloud Storage Transfer Service (STS) for enhanced reliability, scalability, performance, and security. The legacy v1 connectors (Cloud Storage, Amazon S3, Amazon SQS, Azure Blob Storage) are being discontinued. Key Migration Timelines: October 1, 2026: End of support for v1 feeds; only best-effort support will be available. March 15, 2027: Permanent deactivation of v1 connectors; feeds will cease to function. Automatic migration services are provided, but users must take specific actions before migration to ensure success: Cloud Storage: Grant new service account permissions. Amazon S3: Add STS IP ranges to bucket policy if using IP allowlisting. Amazon SQS: Ensure queues receive messages from a single S3 bucket and verify identical credentials. Microsoft Azure: Allow STS IP ranges if using firewalls/virtual networks Fix any currently failing feeds due to incorrect credentials. Updated Docs: Administration > Feed Management from Google Cloud Docs A new Custom API feed source type, enabling users to ingest telemetry from third-party REST APIs using a configuration-based model. This includes comprehensive documentation on setting up Custom API feeds, defining API endpoints, authentication (Basic, OAuth 2.0, API Key), pagination, and checkpointing strategies. Two connector models are detailed: Standard API (Sequential) and List & Detail (Parent-Child). The documentation also covers key benefits, prerequisites, best practices, rate limiting guardrails, limitations, and troubleshooting guidance. Additionally, a new option to delete pending backlog data when deleting Custom API feeds was added. Note, this is likely the public docs being updated before the feature is announced, but you will soon be able to add REST APIs natively in Feed Management. Updated Docs: Yara L > Composite Detection Rules from Google Cloud Docs The method for accessing outcome variables within composite rules has been updated. Previously, outcome variables were accessed using detection.detection.outcomeso"variable_name"]. The updated path requires using detection.detection.variables "variable_name"].string_val to explicitly retrieve the string value of the variable. _Read More] Updated Docs: Reference: Feed Management Api from Google Cloud Docs The tokenEndpoint configuration for authentication has been updated. Previously, it required a full absolute URL (e.g., https://api.us-2.crowdstrike.com/oauth2/token). It now expects a relative path (e.g., oauth2/token), with the base URL being derived from the hostname configuration. Users must update existing configurations to reflect this change. nRead More] Updated Docs: Administration: Siem Endpoint Mapping Table from Google Cloud Docs New Ingestion API Mappings: A comprehensive set of mappings for Ingestion API endpoints has been added. These new entries detail how various legacy ingestion methods (BatchCreateEntities, BatchCreateEvents, BatchCreateLogs, BatchCreateUDMEvents, BatchCreateUnstructuredLogEntries, CreateEntities, CreateUDMEvents, CreateUnstructuredLogEntries, ListLogTypes, ListSupportedLogTypes, PutLog) correspond to modern Chronicle API endpoints (e.g., entities.import, forwarders.importStatsEvents, logs.import, events.import, logTypes.list, logTypeSettings.list, logTypes.update). Clarified Endpoint Removal: The Uppercase Alerts CreateCorrespondence API, previously listed in the main mapping with a N/A status, has been explicitly moved to and is now solely listed under the 'Unmapped and removed endpoints' section, reaffirming its deprecated and removed status. Read More] Updated Docs: Detection > Ati Fusion Feed from Google Cloud Docs Updated the recommended YARA-L migration syntax for transitioning from MANDIANT_FUSION_IOC to GTI_IOC. The revised syntax removes the explicit OR MANDIANT_FUSION_IOC condition and introduces a new required condition: $mandiant.graph.metadata.threat_intel.stable = true. This modification impacts how users should update their YARA-L rules to maintain accurate and uninterrupted coverage with the new GTI product name. tRead More] Updated Docs: Detection > Detection Delays from Google Cloud Docs Expanded Engine Capabilities: The Streaming Engine is now explicitly stated to support windowed single-event rules and to continuously evaluate late-arriving data and retroactive enrichments. Revised True-Up Timings: The expected re-evaluation time for late-arriving data has been updated from “5 to 8 hours” to “approximately 4 hours (and optionally 30 hours with enrichment completeness)”. New Run Frequency: A new match_window / 10 run frequency has been introduced for multi-event rules with match windows greater than 48 hours. Clarified Delay Factors: Detailed explanations for various delay factors, including specific examples for time zone discrepancies and updated Entity Context Graph (ECG) processing times. Enhanced Guidance: Improved troubleshooting approaches and more specific techniques to reduce detection latency are provided. hRead More] Note, in a similar way, Rule Execution Frequency and Run Frequency docs have been updated. Updated Docs: Detection > Set Customized Schedule from Google Cloud Docs This document update reflects the general availability of customizable rule schedules by removing the pre-GA disclaimer. Key terminology has been standardized: “First run” is now “Primary run,” and “offset” is now “settlement delay,” with a formal definition added for the latter. New content includes a “Common use cases” section providing practical examples, refined configuration steps for setting frequencies and settlement delays, and clearer guidance for optimizing Mean Time to Detection (MTTD). Limitations have been further clarified regarding multi-event rules with match windows greater than 48 hours and the unavailability of near-real-time streaming for multi-event correlation. cRead More] SecOps SOAR  Updated Docs: SOAR: Respond > Working With Playbooks >Using Reaction Triggers In Playbooks from Google Cloud Docs New Feature: Reaction Chain Limit — A new mechanism is added to configure and enforce a maximum execution depth for reaction playbooks, preventing infinite loops. This replaces previous manual advice on infinite loop prevention. New Feature: Playbook Simulator for Reaction Triggers — Playbooks containing reaction triggers can now be tested and validated using a simulator, allowing users to configure simulated event parameters and observe trigger behavior (matching/non-matching events). aRead More] Updated Docs: Secops > Enable Soar Access from Google Cloud Docs The list of minimum required permissions for a custom role has been significantly expanded. New permissions include chronicle.instances.generateSoarAuthJwt, chronicle.socRoles.get, chronicle.userNotifications.get, chronicle.userLocalizations.get, chronicle.moduleSettings.rebranding, chronicle.integrations.get, chronicle.legacySoarAdvancedReports.get, chronicle.environmentGroups.get, chronicle.moduleSettingsProperties.get, and chronicle.legacySoarUsers.get gRead More] If you’re creating custom IAM roles these are useful IAM permissions to be aware of. Google Cloud & AI  🦗 Getting started with Mantis, our open-source bug finding-and-fixing harness from Google Cloud Blog Google has open-sourced Mantis, an AI-powered bug finding-and-fixing harness designed to automate the discovery, triage, reproduction, and patching of software vulnerabilities, helping defenders gain an advantage against AI-discovered exploits. tRead More] If you’re thinking, how is this different from Codemender, my understanding is this is an open source solution, whereas Codemender is the paid for commercial supported offering. BigQuery Graph is now GA: the knowledge foundation for the agentic era from Google Cloud Blog Google Cloud has announced the General Availability of BigQuery Graph, a new feature designed to connect enterprise data for complex insights and provide foundational knowledge for AI agents. This tool aims to overcome the limitations of traditional, siloed graph databases. oRead More] 4 engineering patterns behind the strongest AI Agents Challenge submissions from Google Cloud Blog The Google for Startups AI Agents Challenge revealed that the most successful multi-agent AI systems utilize foundational software engineering patterns like bidirectional MCP and async event buses, rather than relying solely on raw model power. Read More  Adoption Guides  Adoption Guide: Reliable SOC metrics, measuring the efficacy of your SOC using SECOPS from Google Cloud Security Community This adoption guide from Ivan Ninichuck aims to help Security Operations Centers (SOCs) move beyond misleading vanity metrics to implement reliable measurements that accurately reflect risk reduction and SOC efficacy. cRead More] Adoption Guide: Customizing Security and Compliance with Custom Cloud Controls from Google Cloud Security Community This adoption guide from Shreja Rangarajan explains how Google Cloud’s Custom Cloud Controls within Security Command Center (SCC) allow organizations to tailor security and compliance monitoring to their unique internal policies and requirements, beyond standard built-in checks. mRead More]  Community & Events  Bindplane Integration for Google SecOps — routing, filtering and automated rehydration for IR from Google Cloud Security Community This article from darrenswift details an OpenTelemetry-based Bindplane OP integration for Google SecOps, enabling optimized log routing to SecOps and Google Cloud Storage, alongside automated incident rehydration capabilities. eRead More] Tuesday’s Tip of the Week — Signal, Not Noise: Tuning Detection Rules with Exclusions and Data Tables from Google Cloud Security Community This article from dnehoda discusses the problem of overly noisy security detection rules, which generate excessive false positives and hinder threat investigation. It recommends ongoing detection tuning, utilizing exclusions and data tables, to reduce noise and improve the relevance of alerts. tRead More] lPart#3] Google SecOps Data in BigQuery: Demystifying Advanced BigQuery Export (SIEM) vs. Legacy BigQuery (SOAR) from Google Cloud Security Community This article from hzmndt, part three of a series, demystifies Google SecOps data in BigQuery by comparing Advanced BigQuery Export (SIEM) with Legacy BigQuery (SOAR), detailing the SOAR BigQuery schema for incident management and automation data. sRead More] GPart#2] Google SecOps Data in BigQuery: Demystifying Advanced BigQuery Export (SIEM) vs. Legacy BigQuery (SOAR) from Google Cloud Security Community This article from hzmndt, part of a series, explains how Google SecOps data, specifically SOAR data, is handled in BigQuery, clarifying that it’s not supported by Advanced BigQuery Export and requires access via the legacy BigQuery pipeline. Read More] nPart#1] Google SecOps Data in BigQuery: Demystifying Advanced BigQuery Export (SIEM) vs. Legacy BigQuery (SOAR) from Google Cloud Security Community This article from hzmndt, part one of a series, demystifies the architectural distinctions between Advanced BigQuery Export (SIEM) and Legacy BigQuery (SOAR) for accessing Google Security Operations data, crucial for maturing SOC teams. nRead More] Demystifying Google SecOps SOAR Connector Routing: How Environments, Aliases, and the “Default Environment” Actually Work from Google Cloud Security Community This article from hzmndt clarifies the functionality of Google SecOps SOAR connector routing, explaining that the ‘Default Environment’ serves as a permanent fallback container rather than a temporary staging queue for multi-tenant setups. mRead More]  3rd Party Blogs  Building AI-driven UEBA for Google SecOps from Greg Kushmerek The article focuses on the development of AI-driven User and Entity Behavior Analytics (UEBA) specifically for Google’s Security Operations (SecOps). Read More]  Podcasts & YouTube ️ If you had not seen, Anton Chuvakin has left Google Cloud for a new adventure, and the Cloud Security Podcast had their farewell episode Farewell to the Cloud Security Podcast Wiz  Introducing Continuous Vulnerability Assessment: Real-Time Defense for the AI Threat Era from Wiz Blog Wiz introduces Continuous Vulnerability Assessment (CVA), a real-time defense system designed to detect new vulnerabilities immediately upon publication, thereby enhancing security in the AI threat era. aRead More]  Platform Issues  RESOLVED: Google SecOps customers are experiencing ingestion failure with one of the 3P APIs in all regions from Google Cloud Status Google SecOps customers are experiencing data ingestion failures across all regions, attributed to an upstream service outage with the Proofpoint Mail API. eRead More] RESOLVED: Google SecOps APIs and UI may not be available for some customers in central-us1 from Google Cloud Status Google SecOps APIs and UI experienced an availability issue for some customers in us-central1 due to a networking problem, beginning around 2026–09–01 08:00 US/Pacific. ARead More] RESOLVED: Customers utilizing BigQuery BYOP data export or legacy (deprecated) BigQuery export to TLA projects may experience delays in recent UDM Events appearing in their BigQuery datasets. BigQuery Advanced export for SecOps Enterprise+ customers is unaffected from Google Cloud Status Customers using BigQuery BYOP or legacy data export to TLA projects may experience delays in UDM Events appearing in their BigQuery datasets, while BigQuery Advanced export for SecOps Enterprise+ customers remains unaffected. sRead More] RESOLVED: Some Google SecOps customers in the US multiregion may experience delays with data normalization and detections from Google Cloud Status Some Google SecOps customers in the US multi-region are experiencing delays with data normalization and detections due to an ongoing issue. gRead More]   What's New in SecOps Mon, 07 Sep 2026 17:12:12 +0200 https://security.googlecloudcommunity.com/cloud-security-foundation-7/production-project-suspended-after-400x-gemini-api-cost-spike-from-leaked-key-8196 Looking for guidance on a suspension case.Our project was shut down on Sep 7 under the hijacked-resources policy.The trigger appears to be a billing anomaly on Gemini API — daily costjumped to roughly 400 times our normal baseline within a single day.None of that traffic came from us, so we assume a key of ours ended upsomewhere it shouldn't have.What we've done so far: every user-managed service account key in theproject is gone, and every API key including the Gemini one is gone.Nothing left to rotate on that front. IAM stayed reachable long enoughfor us to finish that part.What we can't do: anything requiring project APIs. Audit log review,Secret Manager rotation, checking for resources we didn't create — allof it returns CONSUMER_SUSPENDED.The appeal went in the same evening, plus the separate suspensioninquiry form. No decision yet.Two questions for anyone who's been through this:Is there any way to learn which credential Google actually flagged?Knowing the exposure path would help us close it properly rather thanguessing.And for those whose projects were reinstated — did anything inparticular seem to move it along, or was it purely waiting?This runs our internal operations data, so the outage is affectingdaily work across several teams. Cloud Security Foundation Mon, 07 Sep 2026 17:03:06 +0200 https://security.googlecloudcommunity.com/cloud-security-foundation-7/oauth-verification-stuck-under-review-homepage-requirement-resolved-via-search-console-but-ui-is-locked-7703 Hello Google Community Team,My OAuth app verification is currently stuck and I need an internal engineer to manually trigger a status refresh or pass this along to the Trust & Safety team.* Project ID: dev-workrate* The Issue: The Cloud Console Verification Center shows a blocking error under "Homepage requirements" stating: "Your homepage website is not registered to you."* The Resolution: I have successfully verified full domain ownership for our production homepage via Google Search Console using this exact same Google account. The Problem: The console instructs me to "Reply to your email thread with our Trust and Safety team," but I have never received an initial email from the compliance team to reply to. Because the UI is entirely locked in the "Your branding is currently under review" state, I cannot modify fields or trigger a re-scan myself. Could a community manager please escalate this project ID to the Trust & Safety team so they can pull the fresh domain status from Search Console?Thank you! Cloud Security Foundation Sat, 05 Sep 2026 15:07:52 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/bindplane-integration-for-google-secops-routing-filtering-and-automated-rehydration-for-ir-8188 # Bindplane Integration for Google SecOps This repository contains the architecture, automation, and setup scripts for deploying an OpenTelemetry-based telemetry pipeline using Bindplane OP. The primary objective is to route logs to Google SecOps (filtered for cost-optimization) and Google Cloud Storage (GCS) for full raw retention, while providing an automated incident rehydration capability through Google SecOps. # Codehttps://github.com/Darrenswift/secops-incident-response ## Project Structure- `setup_scripts/create_bindplane_pipeline.py`: Python script to programmatically create Bindplane pipelines via the REST API.- `soar_integration/bindplane_soar_integration.py`: Custom Siemplify (Google SecOps SOAR) Python integration to automate incident log rehydration.- `docs/architecture-design.md`: Overview of the primary routing and incident rehydration architectures.- `docs/automation-guide.md`: Guide on automating the rehydration workflow via API and SOAR.- `docs/incident-rehydration-runbook.md`: Standard operating procedure (SOP) for SOC analysts to invoke rehydration manually or via SOAR.- `examples/routing.pipeline.json` & `examples/incident-rehydration-pipeline.json`: Example pipeline configurations. ## Pipeline Architectures### 1. Standard Log Routing Pipeline- **Goal:** Route telemetry data to Google SecOps (filtered) and GCS (unfiltered).- **Reduction:** Uses filters to drop noisy events before sending to SecOps, significantly reducing ingestion costs.- **Retention:** Sends 100% of raw logs to a GCS bucket for long-term compliance and future rehydration. ### 2. Incident Rehydration Pipeline- **Goal:** Replay archived, unfiltered telemetry from GCS back into Google SecOps during an active investigation.- **Process:** Configures a dedicated rehydration agent to pull logs for a specific time window. Overrides the namespace (e.g., `your-company-incident`) to easily identify rehydrated logs within SecOps. ## Setup Instructions ### 1. Bindplane SetupUse the provided Python setup script to create your pipelines programmatically:```bashpython3 setup_scripts/create_bindplane_pipeline.py \--api-key "YOUR_BINDPLANE_API_KEY" \--project-id "YOUR_BINDPLANE_ACCOUNT_ID" \--customer-id "YOUR_SECOPS_CUSTOMER_ID" \--gcs-bucket "YOUR_GCS_ARCHIVE_BUCKET" \--gcp-project "YOUR_GCP_PROJECT_ID"```*Alternatively, you can manually import the provided `.json` files directly into the Bindplane UI or simply create this within the Bindplane UI without importing .json* ### 2. SOAR Integration Setup (Google SecOps SOAR)To automate the rehydration process in response to alerts, import the custom action into Siemplify: 1. Open Google SecOps SOAR -> **Settings** -> **Integrations** -> **IDE**.2. Click **Add Integration** named `BindplaneOP`.3. Set the Environment Parameters: `API URL`, `API Key`, and `Account ID`.4. Click **Add Action** named `Rehydrate Incident Logs`.5. Under the **Parameters** tab for this Action, add the following parameters:- `Pipeline Name` (String, Default: `incident-rehydration-pipeline`)- `Rehydration Agent ID` (String, Mandatory)- `Start Time (UTC)` (String, Mandatory) -> **Use Placeholder: `hEvent.Start Time]`**- `End Time (UTC)` (String, Mandatory) -> **Use Placeholder: `hEvent.End Time]`**6. Paste the contents of `soar_integration/bindplane_soar_integration.py` into the editor, then **Save**. ### 3. Setting Up the SOAR Request FormTo allow SOC analysts to easily trigger rehydration on-demand, you need to configure a Request Form in Google SecOps SOAR that captures the exact time window. 1. Navigate to **Settings** -> **Portal** -> **Request Forms** (or **Settings** -> **Requests** depending on your version).2. Click **Add Request Form** and name it `Incident Response Log Rehydration`.3. Add the following **Mandatory Custom Fields**:- `Start Time` (Type: String)- `End Time` (Type: String)4. **Crucial Formatting:** It's best practice to add placeholder text or a description to these fields such as `sFORMAT] YYYY-MM-DDTHH:MM:SSZ` so analysts know how to input the time.5. In the form's configuration, set it to automatically trigger your Rehydration Playbook upon submission. > s!NOTE]> **Timestamp Sanitization "Magic":** The Bindplane UI and API handle time windows differently. While the UI is flexible, passing seconds, milliseconds, or a trailing `Z` directly to the Bindplane API configuration can cause the agent to fail. To make this robust, the custom `bindplane_soar_integration.py` includes a `format_bindplane_time` function. It automatically parses common SOAR formats (Unix epoch ms/s, ISO 8601, standard strings) and rigidly truncates them down to the exact `YYYY-MM-DDTHH:MM` format required by the Bindplane source parameters. This ensures the integration rarely fails due to analyst typos. ### 4. Playbook Execution WorkflowOnce the form is configured, the operational flow is completely hands-off:1. A SOC analyst fills out the "Incident Response Log Rehydration" request form, providing the Environment, Start Time, End Time, and Priority.2. SOAR automatically creates a Case and attaches your Bindplane playbook.3. The playbook extracts the `Start Time` and `End Time` from the request form and passes them to the custom Bindplane Integration action.4. The integration contacts the Bindplane API to dynamically update the time window on the GCS source.5. The integration forcefully assigns the configuration to your dormant rehydration agent.6. The agent wakes up, immediately pulls the requested logs from GCS, and pushes them into Google SecOps. ## Deep Dive: How the Python Integration WorksFor technical users and engineers looking to understand or modify the SOAR automation, the `bindplane_soar_integration.py` script performs a highly specific sequence of API calls and data formatting to ensure a flawless rehydration process: 1. **Parameter Extraction & Dynamic Hunting:** The script extracts the API credentials and time windows. If the SOAR platform fails to resolve a placeholder (e.g., ``), the `get_dynamic_field` function actively hunts through the Case's Custom Fields, Alert Custom Fields, and Additional Properties to locate the requested data dynamically.2. **Timestamp Sanitization:** As noted above, the `format_bindplane_time` function intercepts the raw timestamps. It normalizes various time formats (Epoch timestamps, ISO 8601 with milliseconds, standard strings) and rigidly formats them down to the strict `YYYY-MM-DDTHH:MM` string required by the Bindplane source parameters.3. **Resource Fetching:** Bindplane OP requires all associated resources to be submitted together. The script performs `GET` requests against `/configurations/{pipeline_name}`, `/sources`, and `/destinations` to pull the live state of the pipeline, the GCS Source, and the Google SecOps Destination.4. **Parameter Injection:**- It strips any existing `starting_time` and `ending_time` from the GCS Source and injects the newly formatted time window.- It injects the `your-company-incident` namespace into the Google SecOps Destination parameters to ensure the rehydrated logs are tagged correctly.5. **Blueprint Application:** The script bundles the modified Configuration, Source, and Destination objects and submits a `POST` request to `/v1/apply` to update the Bindplane Control Plane.6. **Rollout Execution:** It executes a `POST` to `/rollouts/{pipeline_name}/start` to ensure the new configuration is actively rolled out.7. **Agent Deployment:** Finally, the script performs a `PATCH` request to `/agents/labels` using `"overwrite": True`. This forcefully assigns the target rehydration Agent ID to the updated configuration, instantly waking it up to pull the requested logs from GCS.  Google Security Operations Sat, 05 Sep 2026 14:45:33 +0200 https://security.googlecloudcommunity.com/community-blog-42/announcing-public-preview-of-the-google-security-operations-detection-engineering-agent-8178 Author: Nolan Karpinski, Group Product Manager, Google Cloud Security We are excited to share the latest leap forward in autonomous defense by announcing the Public Preview of the Detection Engineering agent in Google Security Operations.Wondering if your organization is ready for the latest AI hack? Rather than entering into a marathon of drafting rules and hoping they trigger, the Detection Engineering agent brings a powerful new capability to security teams with the ability to safely simulate threat coverage at a moment's notice. Agentic AI makes a continuous detection-and-validation loop truly possible. The agent can generate realistic attack sequences and run them against your detection capabilities. This allows you to simulate a wide breadth of coverage and verify rule execution in production-safe environments, confirming your defenses stand strong before an actual attack occurs. A Continuous and Autonomous Detection Lifecycle Detection engineering is often constrained by a painful operational compromise: speed versus fidelity.If you rush a rule into production to counter an active zero-day, you risk overwhelming analysts with false positives, skewing risk scores, and breaking dashboards. If you spend weeks carefully testing and tuning queries in staging labs, you leave your enterprise exposed during the adversary’s most lucrative exploitation window.The Detection Engineering agent validates coverage while reducing the risks of testing in production. It can identify coverage gaps and create new detections for threat scenarios, reducing toil and transforming this manual craft into an automated science. Key Features and Capabilities Threat intelligence extraction in minutes: The Detection Engineering agent automatically extracts granular behavioral procedures and tactics from CTI reports emerging threat advisories to create structured Threat Detection Opportunities (TDOs). Production-Safe Event Simulation: An embedded simulation harness generates synthetic, schema-valid Universal Data Model (UDM) events reflecting exact adversary procedures. Teams safely validate detection logic through their live ingestion pipeline without executing live malware. Automated Coverage Evaluation: The agent runs simulated UDM events against BOTH Google SecOps Curated Detections (curated rules) and your existing customer-authored custom YARA-L rules to identify exactly which rules triggered and where gaps exist. Detection Rule Generation: When gaps are found, the agent synthesizes and tunes production-ready YARA-L rules tailored to the specific missed behaviors.  Why This Matters for Your SOC This launch addresses several critical challenges faced by modern SOCs. By accelerating the mean time to coverage, teams can drastically reduce turnaround times from a new zero-day advisory to active defense—moving from days to minutes. Organizations can also ensure a validated security posture by proactively testing all rules, to confirm they trigger successfully before an actual breach occurs. Additionally, strict telemetry isolation keeps simulation data hidden from daily analyst views, dashboards, and incident management systems. Finally, automated rule generation lowers the skill barrier by codifying complex threat logic, enabling analysts of all skill levels to author high-performance YARA-L rules. Getting Started The Public Preview is available for customers on the Google SecOps Enterprise and Enterprise Plus tiers. Prerequisites and Activation To begin using these features, administrators must enable the Preview Features opt-in setting within the Google SecOps console: Navigate to Settings > Preview Features. Toggle Detection Engineering Agent Features (detection_engineering_agent_enabled). Toggle Event Simulation Enabled (ade_simsafe_detection_enabled).   Please note that access via the Google SecOps Remote Model Context Protocol (MCP) Server is required for full functionality. Important Operational Guidance As you explore these preview features, keep the following technical considerations in mind:  Execution Window End-to-end execution typically requires 15 to 30 minutes; ensure your AI harness timeouts are configured accordingly. Input Quality For best results, provide rich behavioral descriptions (TTPs) rather than simple atomic indicators like single IP addresses. UDM Dependencies Coverage evaluation depends on active UDM parsers for the log sources referenced in the threat reports. Looking Ahead This Public Preview is just the beginning. Our roadmap includes integrating these capabilities into the new chat experience, enriching inputs with Google Threat Intelligence context, and expanding simulation realism to cover multi-stage, complex attack sequences.For more detailed information, please refer to the Release Notes and Detection Engineering agent docs guide.  Community Blog Sat, 05 Sep 2026 10:31:16 +0200 https://security.googlecloudcommunity.com/community-blog-42/lifecycle-of-a-soar-automation-8151  Author: Dmitry Kosarev, Senior Security Automation Engineer - Admiral Group Have you ever had to perform a laborious, repetitive task in an IT role?I certainly have. Whether it’s manually triaging suspicious emails in a reporting mailbox or pulling metrics from half a dozen systems to build a monthly slide deck, many of us have spent countless hours on work that should be automated.Some teams take steps to solve this. There are plenty of courses on Python, Bash, and scripting in general. And if you’re lucky, you might build small automations for your own workflow. How do you scale those automations? How do you monitor them? How do you maintain them over time? While software engineering has mature practices and guidance, there is still a noticeable gap when it comes to operationalising automation in cybersecurity. In practice, this often leads to immature, makeshift and fragile solutions.Earlier in my career before joining Admiral, I managed automation for a Security Operations team supporting over 15,000 users. Those automations consisted of PowerShell scripts running on a server, triggered by Task Scheduler, with credentials stored in text files accessible to specific accounts.They worked, for the most part. Logs were reviewed manually, once a week Fixes were implemented on the fly with no oversight or control under an extreme time crunch Ownership was subject to a single point of failure And during high-risk periods (like Christmas), automations were simply disabled “just in case” So what does it look like when automation is treated as a first-class discipline?That’s exactly what the Security Automation Engineering (SAE) team at Admiral has been exploring over the past 2.5 years.Through a series of posts, we want to share what we’ve learned and learn from others — because this still feels like a niche but rapidly advancing discipline within cybersecurity which seems to be locked away within siloes. We’re also planning on sharing some of our technical solutions such as scripts that have made our security automation program more mature and scalable.Lifecycle of an Automation We support multiple specialist cybersecurity teams, each pushing the boundaries of their domain.While we use Google SecOps SOAR as our central platform, the principles we follow are platform-agnostic: a central orchestration layer that integrates with tools via APIs, executes actions, and processes results in a scalable and repeatable way. But building a successful automation is about far more than just development.It’s about the entire lifecycle.Press enter or click to view image in full size  Automation Lifecycle Each phase matters. Strong automations don’t come from great code or visual workflows alone — they come from well-executed processes across the entire lifecycle. Request Every automation starts with a request.We use a simple submission form that captures: Scope and goals Systems involved Quantitative benefits (time savings) Qualitative benefits (e.g. faster response times) But forms aren’t enough.We actively engage teams proactively through: One-on-one in depth conversations (in person where possible certainly helps when you’re dealing with a remote distributed workforce) Internal collaboration spaces Quick exploratory calls Letting people see what has been done already does wonders for sparking ideas for other automations.TriageNot all requests are equal. Even after 2.5 years, our backlog remains full — but prioritisation is critical.Some requests: Deliver high value Deliver otherwise unavailable capabilities Remove significant operational burden Close risk gaps Others do not. Learning to say “No” or “Not right now” is essential. Good triage: Prevents burnout Keeps delivery consistent Ensures the team focuses on meaningful impact Discovery This is where ideas meet reality. We work closely with the requesting team to: Understand the true problem Set expectations for human involvement Identify edge cases Discuss the user interface of the automation Good discovery saves time later. Misaligned expectations don’t.Many teams don’t know what’s possible or what’s not. Interestingly, fresh perspectives often challenge assumptions and push us to rethink solutions even if some requests end up being way beyond the capabilities of the team.Checklists help early on, but experience builds intuition.Prerequisites Before development begins, we identify all external prerequisites that need to be established first: Tool access (temporary or permanent) Training requirements for us to better understand the tools being used Firewall changes to network communication between the tools and the SOAR platform Service accounts (with least privilege) Other miscellaneous work by other teams? This could be finalising the process to be automated, configuring the external tooling (e.g. appropriate tagging or entity mapping) This last point is often underestimated. Automations should not compensate for broken processes. It’s always better to fix issues at the source than build workarounds.Development This is the part everyone expects to enjoy the most.And it is — but it’s evolving.With LLM tooling, development time is reducing. That creates space to: Design more robust solutions Improve testing Build reusable components Cover more functionality from day one That said, discipline matters: Stay focused on high-value requirements and avoid bloat Build atomically Prefer vendor-supported functionality where possible Keep custom scripts simple and scoped (reusable templates can save just as much time as an LLM here!) Documentation This is what makes automation sustainable.Good documentation: Captures design decisions Provides operational context for the automation’s existence Supports future maintenance and tracks known, expected and accepted errors Tracks post-implementation improvement opportunities Standardised templates and clear diagrams go a long way — not just for us, but for the teams we support.User Acceptance TestingThis is one of the most critical phases. We deploy the automation in a development environment and require: A dedicated representative from the requesting team that can speak effectively to their needs and pain points Time for proper validation and reviews Detailed feedback on outputs and behaviour The challenge?Teams are busy. The automation may save them time — but in the future.To make this phase effective: Present outputs clearly Abstract away complexity Engage collaboratively Take feedback and questions seriously Demonstrate a tangible difference from the engagement This builds a virtuous cycle of engagement that smoothens collaboration in the future.And most importantly: We do not proceed until the team is happy.Peer Review We have a very specific way of doing this: Presenting a sample of automation execution in the SOAR Providing a link to completed documentation Live video demo to the whole SAE team with a feedback session Structured feedback submission Our team brings diverse backgrounds across cybersecurity and IT, which helps us: Identify weak points Improve scalability Enhance usability Evaluate the “business logic” of the automation Attention to detail, especially in UI and presentation — often elevates the overall experience beyond initial expectations. Under-promising and overdelivering is an ethos that is central to our success.Implementation This is typically the shortest stage but with plenty to consider: Deployments still involve manual steps. Manual steps are much likelier to go wrong if not considered and pre-emptively outlined. These manual steps are standardisable but only to a certain point. Deploying custom scripts takes different steps than just deploying an automation built with out of the box steps. Event based automation triggers need to be configured differently than schedule based ones. Documenting these considerations and what configurations to use ahead of time and getting those peer reviewed via a change management process helps prevent failed deployments and ensures broad awareness of production activities amongst the team. Notifying users and giving them an easy forum to comment on upcoming changes helps prepare the teams that will be using our automations. Monitoring This comes in two stages: Short term: Intensive manual oversight immediately after deployment to make sure the automation is performing as expected “in the wild”, outside of test conditions Long term: Daily automated reporting on execution health. Using a bespoke technical solution we’re planning to share in the future, we run a dedicated automation that for each production automation fetches the results of each automation step. Whether successful or not, that step’s output is collected, data is normalised and structured and known errors filtered out. The end result is a report that focuses our attention on material errors in our automations, allowing us to catch errors before the users do and allowing us to start resolving the issues as soon as possible. Demo Demos are not just for showcasing functionality. They are an opportunity to: Drive adoption Gather feedback Identify new automation opportunities Build relationships with users For interactive playbooks especially, demos help analysts understand how automation enhances their overall workflows.One of our learning curves is that building engagement takes more than just a desire to help on our part. We have to engage users early and often, find different communication methods to engage them (even for users within the same teams), be visible and responsive publicly. Demos is one of the many ways we accomplish that.Team Management ReviewFinal validation comes from the requesting team’s leadership. Approval ensures: The automation meets expectations Value has been delivered The request can be formally closed This doesn’t require a heavy, formal process — a confirmation in a corporate messaging tool like Teams is enough.Review Cycle While feedback and improvement suggestions are always welcomed and tracked formally in automation’s documentation, teams can get busy and siloed — organic suggestions may not get enough encouragement to flow. There is also the temptation to keep racing forwards and conquering new automation frontiers; formal reviews initiated by my team prompts the requestors to reflect meaningfully on the automation developed once some experience using has been gathered.We engage the original requestors asking for improvement opportunities, check the use of playbooks in a more detailed, manual manner and consider whether any improvements or updates are worth prioritising in the short term. Whether its Python libraries in custom scripts or updates made by the vendor for dedicated integrations supported by them, software supply chain security is an important consideration for us as well.Conclusion Although presented linearly, this lifecycle is not rigid. Phases overlap, loop back, and influence each other continuously.Yes — it’s a lot of effort.But there is nothing quite like seeing your automations in action, reducing toil, empowering users, and delivering real impact.At its best, security automation feels less like engineering…and more like a form of modern-day magic. Community Blog Fri, 04 Sep 2026 16:29:18 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/event-name-for-google-workspace-app-password-creation-8186 I would like to create some detection rules around Google Workspace App Passwords. I generated a few in an environment, but I can’t find the specific event indicating that an app password was created. Does anyone have any idea, or is it a logging gap? Google Security Operations Fri, 04 Sep 2026 15:07:17 +0200 https://security.googlecloudcommunity.com/community-blog-42/announcing-public-preview-of-the-google-security-operations-threat-hunt-agent-8099 Author: John Murray, Senior Product Manager  Proactive threat hunting is an essential pillar of a mature security posture. Yet for most Security Operations Centers (SOCs), it remains an elusive goal. Translating high-level threat intelligence (such as a campaign report on a new threat actor) into tangible, cross-telemetry analysis is historically a manual, high-expertise task reserved for senior analysts. Due to the sheer complexity of manual log analysis across weeks of historical data, most SOCs remain purely reactive.Today, we are excited to announce the SecOps Threat Hunt agent is now available in public preview.The Threat Hunt agent is an autonomous AI-driven capability powered by Gemini, Google Threat Intelligence, Mandiant Frontline analyst insights and the MITRE ATT&CK framework embedded directly within Google Security Operations. It transforms threat hunting from a time-consuming, manual process into a scalable, proactive, automated force multiplier. What used to take senior analysts hours or days of writing complex queries and piecing together disparate logs can now be completed autonomously by the agent in a fraction of the time. Real-World Use Cases: Moving from Reactive to ProactiveThe Threat Hunt agent is designed to streamline day-to-day operations by addressing critical, high-pressure scenarios that SOCs face every day. For instance, consider the common challenge of the "Executive Fire Drill" When leadership or your CISO reads about a high-profile, emerging threat campaign like "ClickFix Social Engineering" or a newly discovered zero-day vulnerability, their immediate question is almost always, "Are we affected?" Instead of pulling your most senior incident responders away from active investigations to manually comb through logs, analysts can now select the emerging campaign and launch an automated hunt. The Threat Hunt agent sweeps up to 30 days of historical telemetry across your entire environment and returns an explicit, evidence-backed verdict, delivering rapid and reliable assurance directly to leadership.Another frequent scenario involves Targeted Intelligence Hunting. When fresh threat intelligence indicates that a specific actor such as FIN7 or a malware loader like FAKEUPDATES is actively targeting your industry, your SOC needs to move quickly. The Threat Hunt agent automatically maps the target threat to its corresponding Tactics, Techniques, and Procedures (TTPs), runs multi-stage investigations across your enterprise data, and isolates compromised hosts or command-line activity. Once complete, it populates all of its findings into a dedicated case in Case Management, allowing your team to instantly pivot to remediation. Key Capabilities in Public PreviewThe Threat Hunt agent generates a multi-step hunt plan, executes complex queries across UDM and other data sources, and synthesizes findings into a report.The agent can be launched through the Detections > Emerging Threats tab, GTI drawers, or the MITRE ATT&CK Matrix drawer, and can target various categories including threat actors, campaigns, malware families, software tools and specific MITRE TTPs.  The hunt will run fully autonomously in the background for approximately 60-90 minutes, and after analyzing historical data up to 30 days, every hunt automatically spins up a dedicated tracking case in Case Management, prefixed with Threat Hunt for HSubject Name] and tagged with Threat Hunt for clear organization. The agent delivers explicit verdicts accompanied by full transparency with step-by-step execution rationales, underlying YARA-L 2.0 query details, and extracted entity summaries (IPs, hostnames, command lines, and hashes). How to Get StartedPublic Preview of the Threat Hunt agent is available for Google Security Operations Enterprise Plus customers. Administrators can enable the Threat Hunt agent via the in-product Manage Preview Features settings page. (Please note: The agent relies on the New Case Management experience, which must be enabled. This is currently in Public Preview and available via the Preview Features Opt-In page.) To get the most out of your Threat Hunt agent, we recommend deploying it in telemetry-rich environments with ample, high-density security logs (such as endpoint activity, process execution command lines, cloud audit logs, and network authentication events). Rich telemetry allows the agent’s AI planning engine to execute deep, multi-stage queries and extract the highest-fidelity forensic proof.For more information, review  the Google Cloud SecOps Threat Hunt agent Docs page and the Google SecOps Preview Features Guide. As we approach general availability, please share your experience and suggestions in the comments section below.   Community Blog Thu, 03 Sep 2026 05:17:47 +0200 https://security.googlecloudcommunity.com/googletimondays-92/introducing-google-threat-intelligence-url-scanning-2-0-8181 In the rapidly shifting landscape of modern cybersecurity, static detection mechanisms are no longer sufficient to counter sophisticated, evasive web threats. Malicious actors continuously alter their infrastructure and obfuscate code to slip past traditional scanners. To address this critical challenge, Google Threat Intelligence has launched URL Scanning 2.0, a transformative capability designed to give security analysts unprecedented visibility and drastically reduce the Mean Time to Resolution (MTTR) for phishing and link-based investigations.At the core of URL Scanning 2.0 is a dynamic approach to web threat analysis. Instead of relying on passive reputation scores, the system employs sandboxed, headless browser technology to interact with live websites. This allows security teams to visually verify threats through automated live screenshots and full page previews. By seeing exactly what a targeted victim would see, analysts can bypass text-obfuscation tactics. Additionally, the tool exposes crucial client-side telemetry, including Document Object Model (DOM) trees, console logs, and active session parameters.A particularly powerful feature of this release is Historical Analysis Pivoting. Because attackers frequently change page behavior over time to evade analysis, URL Scanning 2.0 allows defenders to travel back through a URL's history using point-in-time snapshots. Analysts can replay the exact evolution of a page, re-rendering its past states to understand when and how a benign link was weaponized.Automated artificial intelligence brand detection works to instantly uncover brand impersonation. This enables threat hunters to identify targeted organizations immediately and pivot to map out broader phishing campaigns. Supported by an array of specialized search modifiers, security teams can now query runtime DOM artifacts, network redirects, and brand alignments with high precision. URL Scanning 2.0 fundamentally shifts the balance back to defenders, turning opaque, evasive links into clear, actionable intelligence. Additional Resources, Links, and Examples:  GTIDocs: URL Search Modifiers #GoogleTIMondays Thu, 03 Sep 2026 01:48:40 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/silentpush-integration-test-connection-fails-with-connection-failed-none-no-http-response-8180 Hi all, We're trying to set up the built-in **SilentPush integration (v3.0)** in Google SecOps SOAR, but Test Connection consistently fails with no useful error detail. Hoping someone from the community or Google team can help point us in the right direction. **Environment:**​Google SecOps SOAR (Google-managed / SaaS instance) ​No self-hosted Remote Agent — running entirely on Google-managed infrastructure ​SilentPush integration version 3.0 **What we've already verified/tried:**1. Confirmed the correct API base URL per SilentPush's official docs (https://help.silentpush.com/docs/get-started-with-api): https://api.silentpush.com (root domain only, scheme included, no trailing path)2. Confirmed API Key is populated and valid3. Tested with "Verify SSL" enabled4. Tested on two separate integration instances (a Shared Instance and the System Default Instance) — identical failure on both5. Ruled out URL formatting issues — we initially hit a MissingSchema error (missing https://) and a wrong subdomain (app. instead of api.), both of which we've since corrected **Current error on Test Connection:**=============== Main - Started ===============Connecting to Silent Push-Google SecOps...Failed to connect to the Silent Push-Google SecOps server!Error: Connection failed: None Traceback (most recent call last):  File ".../silent_push_manager.py", line 522, in test_connection    raise e  File ".../silent_push_manager.py", line 495, in test_connection    raise SilentPushExceptions(f"Connection failed: {error_msg}")exceptions.SilentPushExceptions: Connection failed: None Status: 2Result Value: False The error message itself is empty (error_msg is None), which suggests the connection attempt is failing before any HTTP response is returned — not a credential/auth rejection, but something failing at the connection level itself. **Question:** Is there a known outbound network/egress restriction on the Google-managed SecOps SOAR environment that would block or require allowlisting for api.silentpush.com? Has anyone else run into this with the SilentPush integration specifically, and if so, how was it resolved? Appreciate any pointers — happy to provide more logs/screenshots if needed. Thanks! Google Security Operations Wed, 02 Sep 2026 18:42:59 +0200 https://security.googlecloudcommunity.com/ciso-blog-77/staying-on-top-of-ai-developments-4060       Staying on top of AI Developments Artificial Intelligence (AI) is rapidly transforming the business world. From streamlining operations to unlocking deeper customer insights, AI brings a wealth of potential to the modern enterprise. But to capitalize on these benefits, companies need to go beyond just implementing AI systems - they need a workforce that's prepared to work alongside them (this includes the business, IT and even security professionals).   We’re often asked how to stay on top of AI developments, both technological and regulatory, and how to empower teams with the knowledge, skills, and an understanding of the risks in using AI.  When approaching how to enable your workforce for AI adoption, it’s important to recognize it isn't just about technology, but about investing in your people. By demystifying AI, focusing on strategic skills building, and creating a culture that values continuous learning, your enterprise can unlock the full potential of AI as a transformative technology and prepare for the future of work. It is critical that both IT and business teams understand how AI works, how these risks materialize, and what to do about them. Staying informed about AI is no longer optional - it's vital. New use cases are emerging and problems are being solved by capable users of the technology. A workforce empowered by AI knowledge translates into innovation, increased efficiency, and a stronger competitive edge, laying the path for successful AI integration in a changing business environment. In this blog, we discuss some strategies leaders can employ to upskill their teams. Demystify AI As noted in Google’s Secure AI Framework (SAIF), it’s important to level set with an AI primer and its security follow-up. Start with the basics of AI - what it is, what it's not, and its business applications. Aligning on concepts like AI, machine learning (ML), Deep Learning, gen AI, and large language models (LLMs) enables all stakeholders to accurately identify and evaluate the relevant risks and controls required to manage and deploy AI safely and responsibly.   Using a common vernacular across the enterprise also serves to build a strong foundation to foster further learning. Likewise, it elevates the discussion, addressing common misconceptions and helping to avoid missteps. Implement an AI Skills Building Program Because the best way to learn AI is to actually use the models - experiment with them, spend time with them, apply them in your work. Tailor your learning initiatives for different target audiences. Technologists, data scientists, information security specialists, compliance teams and business users, for instance, will all be expected to be proficient in using AI at some point in the near future, but their usage will vary significantly. At Google Cloud, we understand that one size doesn’t fit all, so we’ve developed AI learning paths that provide options based on area of interest and experience level.  As we previously noted, “Google Cloud has been working for decades to bring AI technology solutions to organizations, and our tools make it easier to build experiences across our cloud portfolio. Whether you’re executive-level, an IT decision maker, in a non-technical role, or a technical practitioner, we have videos, courses and labs to help you learn about the power of generative AI.” Our Generative AI Skills Boost provides business users with an overview of generative AI concepts from the fundamentals of large language models to responsible AI principles. For those looking for more of a hands-on experience, try hands-on labs and explore prompt engineering. Essentially, look for opportunities to enable your staff to experiment safely and securely. Persona-based Training For AI engineering professionals and application developers, exploring How Google Does Machine Learning, the Generative AI for Developers Learning Path and Getting Started with Machine Learning Operations (ML Ops) may also be informative for the best practices for deploying, evaluating, monitoring and operating production ML systems on Google Cloud, and to put that knowledge to use with curated courses and hands-on labs and certificates in AI, data analytics, and cybersecurity. Exchange ideas by joining a Google Developer Group. For information security professionals looking to stay up to date on the evolving cybersecurity landscape and emerging threats, subscribe to the CISO perspectives newsletter, peruse the Threat Horizons intelligence report, hear from security leaders on the Cloud Security Podcast, and refer to what to think about when you’re thinking about securing AI. Additionally, our Threat Intelligence blog arms security professionals with the in-depth knowledge, skills, and tools to defend against the latest and most pressing threats. For Risk and Compliance professionals, reference Google Cloud’s Approach to Trust in Artificial Intelligence for a view into Google’s security, privacy, governance, and responsible AI posture. When assessing and advising on your organization’s AI usage, take a look at our AI governance best practices for some helpful tips. Cultivate a Culture of Continuous Learning AI is going to transform the way work is done and to maintain leadership in a market, your ability to learn and apply this new technology is critical to competitive advantage. Keep in mind, staying current on a field changing as rapidly as AI isn’t a one-time exercise, and fostering a continuous learning culture in your organization takes an intentional, proactive and programmatic approach.  Encourage employees to stay updated on AI trends and advancements, creating a work environment that embraces experimentation and the use of new technologies. Raise awareness by highlighting key questions that need to be addressed to drive secure AI implementation. Consider including AI upskilling in staff’s expectations, and provide opportunities for learning by attending conferences, webinars, and industry events that facilitate network building, sharing ideas and resources, and staying on top of the latest trends. Amplify and celebrate how employees have successfully leveraged AI in their work and offer rewards or recognition for AI certification completion or for accomplishing other milestones. CISO Blog Wed, 02 Sep 2026 03:47:30 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/multi-tenancy-on-a-single-google-secops-part-1-the-isolation-challenge-7789 This is Part 1 of a four-part series on running many tenants on one Google SecOps instance. Part 1 sets up the mental model and the naming convention the rest of the series builds on. Part 2 covers getting telemetry in safely; Part 3 covers who sees what and where each alert lands; Part 4 covers writing detection and response content (rules and playbooks) that works correctly across tenants.If you run security operations for more than one customer (a managed security service provider, a SOC watching several business units, a parent company monitoring its subsidiaries, or just a customer that requires strict isolation), you eventually reach the same fork. Do you stand up one Google SecOps instance per customer, or put everyone on a single shared instance and keep them apart logically?The shared-instance model is appealing for various reasons:It is cheaper, It gives your analysts one console instead of many, and It allows for one (or many) well-written detections that protect every customer at once (if written appropriately, though)However, it is also where teams quietly get multi-tenancy wrong, because "keep them apart" sounds like one job and for Google SecOps, it is really three…This series is the end-to-end guide I kept looking for and never found in one place: how to take a single SecOps instance and run it as a clean multi-tenant platform, with one critical design idea carried from the moment a log is captured at the endpoint all the way to the generated alert on the analyst's screen triggering a playbook. Before we get to it, we need to be precise about what "keep them apart" actually means. Multi-tenancy is three problems, not one Putting many tenants on one instance asks you to solve three separate isolation problems. Any one of them can be correct while the other two are broken, which is exactly why a setup that looks fine in a demo leaks in production (and why many power users of Google SecOps often script this process).The challenges exist in the three layers of all Google SecOps architectures:Ingestion layer: When a log lands in the instance, is there a way to identify one log's owner or origin from another? For example, if two fictional organizations named ACME and OSCORP want to ingest logs to our managed SOC, do we have a way to mark them? (Hey, the answer is easy, but applying it consistently isn't!) SIEM layer: Given correctly tagged data, can a user (e.g. an analyst) see only their own SIEM tenant information? For example, imagine we grant access to our console to an external user, like an ACME's analyst or an OSCORP's threat hunter. Can we make sure that both ACME and OSCORP users only see their data (and the features they should)? SOAR layer: Given correctly tagged data and correct SIEM data access, what about the alerts generated by the SIEM detection rules? In Google SecOps SOAR, that queue is an environment. For example, imagine a single global-scoped detection rule (we'll define that soon) that runs across all our tenants, ACME and OSCORP included. When it fires on ACME's data, can we make sure the resulting alert lands only in ACME's environment, and the same for OSCORP?There are a lot of concepts here. But before defining each one, picture the failure surface. Tagging each tenant can be right while access is wrong. Data Access boundaries can be right while alert routing to an environment is wrong. And this is very important to grasp: Each layer has its own mechanism, its own configuration surface, and its own way to fail silently!This is why many power users use scripting when multitenant-ing a Google SecOps instance. It's isolating three layers consistently, not one. If you don't treat multi-tenancy as a single switch, you undoubtedly will get at least one of the three wrong and everything falls apart. Figure 1 — The three isolation planes that must be correct in a shared instance: ingestion tagging, SIEM data access, and SOAR case routing. They fail independently, so each needs its own control. Now, if you are wondering, here are the configurations we touch at each layer:Namespace at the ingestion layer. It is a special Ingestion Label that has a particular property: It blocks the correlation between assets with equal properties. You can read more about namespaces in Manage asset namespaces, but the important key about this custom field is that by design it aligns with the goal of isolating data, and it is the only field that also creates a correlation boundary in the entity graph (more on that below). A Custom Ingestion Label is a complement rather than a substitute. It does not separate the entity graph, but it can carry an extra marker that lets you express finer-grained access control inside a tenant, for example distinguishing a team or a device class within an organization unit. Part 3 develops that.Figure 2 — Stamping the namespace at ingestion with Bindplane's Add Fields processor (Action: Upsert) on the chronicle_namespace field (we deliberately use Add Fields rather than the Google SecOps Standardization processor). Part 2 covers the ingestion mechanics in depth. Note: There's another configurable field that we consider at the ingestion layer in Bindplane itself, but it is not mentioned here because it is not technically mandatory for the architecture to work. Don't worry, it is presented in the next section. Data RBAC Scope at the SIEM layer. It is the special mechanism that determines what data a user or group is allowed to read. Additionally, while not mandatory, Feature RBAC is also an important aspect to consider when granting access to users into a multi-tenant instance. Figure 3 — The SIEM-side control: Settings → Data Access, home of Data RBAC scopes and custom labels. Here enforcement is still inactive. SOAR Environment at the SOAR layer. The environment is the SOAR-side equivalent of the Data RBAC scope, determining which content a user or group works with. A common mistake is to assume alerts live only in the SOAR. In fact, an alert exists as two separate objects, one in the SIEM and one in the SOAR, and the SOAR connector is what turns a Chronicle (or third-party) SIEM alert into its SOAR-side counterpart. Here we configure two things: the environment name (or alias), and the SOAR connector's Environment Field Name.  Figure 4 — The SOAR-side control: the Chronicle Alerts Connector's Environment Field Name (highlighted), defaulting to event_metadata_baseLabels_namespaces_1 — the namespace field the connector reads on each incoming alert to route it to the matching environment. One slug, every layer Here is the move that makes all three tractable at once: For each tenant, choose a single short identifier (a slug) and use that exact string, byte for byte, in all places the platform needs a tenant key: the namespace stamped on the tenant's telemetry at ingestion, the Data RBAC scope that gates access to that namespace, the SOAR environment name (or its alias as a fallback) that routes the tenant's cases, and, the extra one, the Bindplane project that holds the tenant's collector configuration.Four different platform mechanisms, each consuming the same string as its key. The design permits the namespace driving ingestion tagging and correlation boundaries, the scope designates access limits, the SOAR environment allocates playbooks and alerts in a well-defined group and drives SIEM alert routing, and the Bindplane project enhances control-plane management and isolation.When all four read the same value, there is exactly one tenant identifier in the system and nothing to translate between layers. Figure 5 — One slug, four surfaces. The same string (here acme-cdmx) is the namespace label, the Data RBAC scope name, the SOAR environment name, and the Bindplane project name. The discipline pays off most when anything breaks. An access misconfiguration, a misrouted case, or a tenant leak are all traceable with a single search across the four configuration surfaces when the strings are identical. When they differ, you are translating between four local dialects under incident pressure, which is precisely when you do not want to be. The slug itself From my own experience (and best practices), a slug is lowercase letters and digits with the hyphen as the only separator, and it must start with a letter. The strictest of the four surfaces is the Data RBAC scope name, and that is the one that pins the pattern down. The platform validates a scope name against ^ a-z](aa-z0-9-]{0,61}ma-z0-9])?$: a leading lowercase letter, then up to 63 characters of lowercase letters, digits, and hyphens, ending in a letter or digit, with no leading or trailing hyphen, no underscores, and no dots. Hold every slug to that pattern and it satisfies all four surfaces at once.The slug is also hierarchical. Its shape is <org>r-<unit>h-<subunit>…]], where each hyphen-separated segment names a level: the organization, then an optional unit inside it, then an optional sub-unit, and so on as deep as you need (though, I would try to keep it up to a sub-unit. Going further can make things harder to manage). What a level means is deliberately up to you. A unit can name a cloud, a geography, or an organizational division, whichever reflects how the tenant's data actually needs to be separated. Warning: In my own experience, this is always the hardest part... naming things. But remember that once you decide on a slug pattern and apply it, you cannot revert it. Data RBAC scope creation is irreversible, and events ingested with custom labels cannot be overridden. At least not from the end-user side. A worked cast makes this concrete:Slug Reads as acme ACME, the whole organization acme-gcp ACME, the workloads in Google Cloud acme-cdmx ACME, the Mexico City office acme-cdmx-finance ACME, Mexico City, the finance sub-unit oscorp-aws OSCORP, the workloads in AWS oscorp-tenant-a OSCORP, business tenant A The same scheme names a cloud (acme-gcp), a place (acme-cdmx), and a place within a place (acme-cdmx-finance). One convention covers all of them, and the hierarchy is legible at a glance. A namespace is a boundary, not just a label Why allow sub-levels at all? Because the namespace is not only a routing tag. In Google SecOps it is a correlation boundary for the entity graph. The platform introduces asset namespaces precisely to handle assets that share an identifier across different network segments, the classic case being two sites that both use the same private IP range (again, you should read Manage asset namespaces).When two events carry different namespaces, the platform treats their assets as distinct. A search for an IP that exists in both returns two separate asset views, one per namespace, each showing only its own activity. Identities, hostnames, and other entities inherit the same separation. So if a single tenant has internally overlapping identifiers (a production host and a dev host reusing an address, or the same service-account name in two domains) and you stamp them with one flat namespace, the entity graph silently fuses two different machines into one and your correlation is quietly wrong. Figure 6 — A namespace is a correlation boundary. Two on-premises servers in different offices reuse 10.0.0.10; distinct namespaces (acme-cdmx, acme-gdl) keep them as two assets in the entity graph, where one flat namespace would silently fuse them. Figure 7 — The same boundary, live in the product. The Overview for the shared IP 10.0.0.10 resolves two separate Asset entities, one per namespace (acme-cdmx, acme-gdl), instead of one fused asset. The sub-level is how you prevent that without inflating your tenant count. A tenant with no internal overlap can use a bare acme namespace. A tenant whose internal environments must not be correlated together gets one slug per environment, all sharing the acme- prefix. You draw the line where identifiers actually collide, not by a blanket rule. Granting access at any level Because the slug is hierarchical, it gives you a natural language for access at any granularity (You could even define a slug like <org>-<unit>-<group> for example). Granting an analyst all of ACME means every acme-* namespace. Granting them only ACME's Mexico City office means acme-cdmx (and everything beneath it). Granting them a single sub-unit means one exact slug. The hierarchy is the access model. You pick the level, and you have named the grant.There is one important detail about how the platform turns that intent into enforcement, and it is worth knowing now even though we set it up properly in Part 3 (and why scripting and automating this whole process is very important).As we already explained, control of what data you can see in Google SecOps is governed by Data RBAC, but Data RBAC scopes are what let you define the specific profiles for users and groups. You might expect to write a scope "user X can see data tagged with namespace acme-*" and have it match the whole subtree by prefix. However, Google SecOps Data RBAC does not work that way.A scope enumerates the exact namespace values it covers, with no wildcard. So "all of ACME" is expressed by listing all ACME's namespaces in one scope, and incorporating a new ACME unit means adding its slug to that scope. The reason to mention it here is that it shapes how you design the hierarchy: keep any grant you intend to manage as a single unit to a set of namespaces you can comfortably enumerate and maintain. Part 3 will make this concrete. Choose the slug carefully, because renames are expensive Just to make sure you don't miss this: A namespace stamp lives on an event forever! (or until retention ages it out).The platform does not retag historical events when you rename, and the asset view, the entity graph, and your detection history are all keyed on the tag that was written at ingestion time.Therefore, it is important to understand the implications of renaming slugs. In the case of the event data for example, it splits a tenant in two for the life of your data retention. One asset view covers the period before the rename, another covers the period after, and they do not merge. Detections that filter on the old namespace see only the old data, detections on the new namespace see only the new, and anything that must span both has to name both (although multi-tenant-designed rules can minimize this risk). At the SOAR layer, historical cases stay filed under whatever environment they were routed to at the time, but these can be manually moved between environments.The practical rule that follows is to spend a little thought up front rather than pay the rename later. If a tenant might plausibly grow a sub-division, give it a level now. A small reserved suffix such as -main or -core for a tenant that has no meaningful sub-division today but might tomorrow costs you a few characters and buys forward compatibility without a rename event. Also, keep in mind that if you decide to delete a Data RBAC scope, the name you used cannot be reused again. Reserve a couple of slugs for yourself By the way, if you are the holder of the Google SecOps instance, you can definitely (and should) have two internal tenants that deserve slugs of their own and must not collide with any customer. The first is your own SOC, carrying your infrastructure telemetry and your playbooks. The second is a validation tenant, carrying synthetic data you use to test scope changes, playbook edits, and new detections before they reach a real customer. Following the same scheme, for us, those become zevorus-soc and zevorus-dev. Both fit the access model cleanly, and both make your operator-wide grants straightforward to define as a single list of internal slugs. Note: We actually went a bit further and created what we call a "sandboxed instance", by creating tenants for each one of our engineers. Now each one of us holds its own piece of the Google SecOps instance! What's next That is the foundation: multi-tenancy is three independent isolation problems, and a single hierarchical slug, used identically across namespace, scope, environment, and project, is the thread that ties them together and keeps them traceable.The hard part is making it true on the wire. Part 2 takes up the first plane, ingestion, and the question every service provider eventually has to answer: how do you get each tenant's telemetry into your instance, correctly tagged, without trusting machines you do not control and without leaking the ingestion credential that lets anyone write into your SIEM? That is where the architecture gets interesting, and where we have something proven on the wire to show. Google Security Operations Tue, 01 Sep 2026 21:43:09 +0200 https://security.googlecloudcommunity.com/tuesday-s-tip-of-the-week-93/tuesday-s-tip-of-the-week-signal-not-noise-tuning-detection-rules-with-exclusions-and-data-tables-8179 September 1, 2026 The Cost of Noisy Rules A rule that fires 10,000 alerts daily is worse than no rule at all. Analysts learn to ignore it, and real threats buried in the noise go uninvestigated. Detection tuning is the discipline of reducing false positives while preserving true positive coverage. It is not a one-time task. It is an ongoing practice. Systematic FP Reduction Workflow Follow this process for every noisy rule: review a sample of recent alerts, identify the pattern causing false positives (specific users, IPs, service accounts, resource names), and add targeted exclusions. Never suppress alerts blindly. Understand why they fire before tuning them out. Three Tuning Techniques 1. Add exclusion conditions in the events section. Filter out known-good activity directly in the rule logic:not $e.principal.user.email_addresses in %approved_admins.email2. Use data tables for dynamic allow-lists. Data tables let you maintain exclusion lists that update without modifying the rule itself. Add a service account to the table, and the rule immediately stops alerting on it.3. Adjust match window and threshold. If 10 events in 15 minutes generates too much noise, try 20 in 15 minutes, or 10 in 5 minutes. Tune the threshold to the level where true positives consistently appear. Before and After: A Tuning Example Before (200 alerts/day, 80% false positive rate):rule detect_admin_access_v1 { meta: severity = "HIGH" description = "Detects admin resource access in GCP Cloud Audit logs" events: $e.metadata.event_type = "USER_RESOURCE_ACCESS" $e.metadata.log_type = "GCP_CLOUDAUDIT" $e.target.resource.name = /.*admin.*/ $e.principal.user.email_addresses = $user match: $user over 1h outcome: $access_count = count($e.metadata.id) condition: #e >= 1 and $access_count >= 1}After (5 alerts/day, 95%+ true positive rate):rule detect_admin_access_v2 { meta: severity = "HIGH" description = "Detects unauthorized admin resource access from non-corporate IPs" events: $e.metadata.event_type = "USER_RESOURCE_ACCESS" $e.metadata.log_type = "GCP_CLOUDAUDIT" $e.target.resource.name = /.*admin.*/ $e.principal.user.email_addresses = $user // Data table lookups (STRING and CIDR) not $user in %approved_admins.email not $e.principal.ip in cidr %corporate_networks.cidr match: $user over 1h outcome: $access_count = count($e.metadata.id) $resources = array_distinct($e.target.resource.name) condition: $access_count >= 3}What changed: two data table exclusions filter out approved administrators and corporate network IPs. The threshold increased from 1 to 3, eliminating one-off legitimate accesses. The outcome now captures distinct resource names, giving analysts immediate context about what was accessed. Severity Tiering Assign severity levels based on the expected response:CRITICAL: Pages someone immediately. Active compromise indicators only. HIGH: Reviewed same-day by an analyst. MEDIUM: Goes to a review queue for weekly triage. LOW / INFO: Used for trending and statistical analysis, not direct investigation.Apply these tuning techniques to every detection rule you deploy. Each rule should be reviewed within its first week of production. Tuesday's Tip of the Week Tue, 01 Sep 2026 15:50:26 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/unexpected-gti-ioc-matches-on-legitimate-domains-8166 Hello,Since Friday evening, we have been receiving more than 400 daily alerts from a custom GTI IOC ( on domain) matching rule.Many detections involve well-known legitimate domains such as Microsoft, Google, GitHub, DigiCert and Windows Update. Before Friday, the alert volume was normal.We also noticed that the graph.metadata.threat field is now marked as deprecated in the YARA-L editor, but we could not find clear documentation about its replacement.Has there been a recent change to GTI GLOBAL_CONTEXT data or entity enrichment?What is the recommended replacement for graph.metadata.threat when matching GTI indicators in YARA-L?Is anyone else experiencing the same issue?Thank you. Google Security Operations Tue, 01 Sep 2026 15:38:17 +0200 https://security.googlecloudcommunity.com/fraud-defense-recaptcha-6/why-is-google-adding-an-origin-trial-token-meta-tag-with-recaptcha-5079 Have noticed this appearing in the document head when inspecting the page. Just wondering what this is and why it's been added. Does anyone know? Thanks Fraud Defense (reCAPTCHA) Tue, 01 Sep 2026 09:39:11 +0200 https://security.googlecloudcommunity.com/fraud-defense-recaptcha-6/recaptcha-v3-risk-score-assessment-becoming-inconsistent-8141 Hi Google Cloud Community,We recently enabled reCAPTCHA v3 as a fraud-prevention mechanism and monitored the risk scores for approximately two weeks to understand its assessment behavior.During the first two days, we did not consider the scores for evaluation, as we followed the recommendation in the documentation to allow sufficient time for the risk analysis/assessment to establish.For the following five days, the results were as expected:Fraudulent transactions: The reCAPTCHA score was consistently 0.4 or below. Genuine transactions: The score was consistently 0.5 or above. This separation between fraudulent and genuine transactions was useful for defining our fraud-detection threshold.However, after approximately five days, we started seeing inconsistent results. Our genuine transactions are now also receiving very low scores, sometimes as low as 0.0, even though these transactions are legitimate.This behavior is making it difficult for us to reliably distinguish between genuine and fraudulent transactions based on the reCAPTCHA v3 score.Could someone please help us understand:What could cause genuine transactions to start receiving significantly lower scores after initially receiving expected scores? Does the reCAPTCHA v3 risk assessment model require a longer period of time to stabilize or learn traffic patterns? Since traffic patterns naturally vary due to seasonality and cannot be treated as a fixed baseline, how should we interpret score fluctuations in such dynamic conditions, and what approach is recommended for setting a stable threshold when traffic behavior is continuously changing? What is the recommended approach for determining an appropriate fraud threshold when genuine transactions can receive scores as low as 0.0? Are there any logs, assessments, or additional signals we should review to troubleshoot why the scores have changed?We would appreciate any guidance on how we can investigate this behavior and ensure that reCAPTCHA v3 provides a reliable risk assessment for our fraud-prevention use case.Thank you. Fraud Defense (reCAPTCHA) Tue, 01 Sep 2026 05:53:11 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/part-3-google-secops-data-in-bigquery-demystifying-advanced-bigquery-export-siem-vs-legacy-bigquery-soar-8177 ️ Part 3: SOAR BigQuery Schema Reference (siemplify_search_everything_db)The siemplify_search_everything_db dataset contains tables capturing the lifecycle of incident management, playbook automation, and analyst workflows. Synchronization & GuardrailsAutomated Sync: Handled continuously in the background by the SOAR data synchronization engine. Simulated Cases Excluded: Cases created in simulation/test mode are deliberately excluded from BigQuery export to prevent corrupting production KPIs and SLA metrics. Field Truncation: To adhere to BigQuery performance boundaries, field values exceeding 10,000 characters are truncated. Exact Table Naming: Keep in mind that some tables contain specific legacy naming conventions (e.g., AlertProductsDistribuations). Use the exact literal table names in your SQL queries.Key SOAR Tables Overview ┌───────────────────┐│ DashboardCases │└─────────┬─────────┘│┌──────────────┼──────────────┐▼ ▼ ▼┌────────────────┐ ┌───────────┐ ┌──────────────────┐│ DashboardAlerts│ │ CaseTags │ │ CaseStageEntries │└────────┬───────┘ └───────────┘ └──────────────────┘│┌────────────┼────────────┐▼ ▼ ▼┌───────────┐┌───────────┐┌───────────┐│AlertEntity││Playbooks ││ActionRslt │└───────────┘└───────────┘└───────────┘ Table Category Key Tables Purpose / Data Captured Cases & Lifecycle DashboardCases, CaseStageEntries, CaseAssignActivities,  CaseMergeHistories Case status, priority, assigned analyst, stage transitions, closure reasons, merge records, and SLA status. Alerts & Ingestion DashboardAlerts,  AlertsDistribuations,  AlertOntologyFamilies,  AlertProductsDistribuations Source alerts grouped into cases, vendor products, alert rules, ontology families, and severity. Playbooks & Actions DashboardAlertPlaybooks,  WorkflowStepIndexRecords,  SystemActionResults Automated playbook executions, individual action step runtimes, success/failure statuses, and script outputs. Entities & Enrichments DashboardAlertEntities,  InvolvedEntityRelations,  AlertUsersDistribuations Extracted entities (IPs, hostnames, users), relations, whether entities are flagged as suspicious or internal. SLA & Performance SystemCaseSlas,  SystemAlertSlas,  DashboardAlertCategoryOutcomes Target vs. actual SLA thresholds, resolution turnaround times, and alert outcome distributions. Configuration Metadata MetadataCaseStages,  MetadataSocRoles,  MetadataUserProfiles,  CustomFields,  CustomFieldValues Definitions of case stages, team roles, analyst profiles, and custom case/closure field schemas.    High-Value SOAR BigQuery Use Cases & Sample Queries Use Case 1: SOC Performance & MTTR by Case Root CauseMeasure how quickly cases are closed based on their root cause category. sqlSELECTRootCause,COUNT(1) AS total_cases,ROUND(AVG(TIMESTAMP_DIFF(ClosedTime, CreatedTime, MINUTE)), 2) AS avg_mttr_minutes,ROUND(AVG(TIMESTAMP_DIFF(FirstAssignedTime, CreatedTime, MINUTE)), 2) AS avg_mtta_minutesFROM`YOUR_PROJECT_ID.siemplify_search_everything_db.DashboardCases`WHEREStatus = 'Closed'AND CreatedTime >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)GROUP BYRootCauseORDER BYtotal_cases DESC; Use Case 2: Playbook Automation Health & Failure Rates Identify playbooks or automated integration actions experiencing frequent failures or slow runtimes.sqlSELECTPlaybookName,ActionName,Status,COUNT(1) AS execution_count,ROUND(AVG(ExecutionDurationSeconds), 2) AS avg_duration_secFROM`YOUR_PROJECT_ID.siemplify_search_everything_db.SystemActionResults`WHERECreatedTime >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)GROUP BYPlaybookName,ActionName,StatusHAVINGStatus IN ('Failed', 'Timeout', 'Error')ORDER BYexecution_count DESC; Use Case 3: Analyst Workload and Case Stage Progression Track how cases move through stages and which analysts handle the highest volumes. sqlSELECTc.AssignedUser,s.StageName,COUNT(DISTINCT c.Id) AS active_cases,ROUND(AVG(TIMESTAMP_DIFF(CURRENT_TIMESTAMP(), s.StartTime, HOUR)), 1) AS avg_hours_in_stageFROM`YOUR_PROJECT_ID.siemplify_search_everything_db.DashboardCases` cJOIN`YOUR_PROJECT_ID.siemplify_search_everything_db.CaseStageEntries` sON c.Id = s.CaseIdWHEREc.Status = 'Open'GROUP BYc.AssignedUser,s.StageNameORDER BYactive_cases DESC;  Summary Comparison: Advanced BQ Export vs. SOAR BQ Feature Advanced BigQuery Export (SIEM) SOAR BigQuery (search_everything_db) Primary Data Scope UDM Events, Rules/Detections, IoCs, Entity Graph Cases, Alerts, Playbooks, SOC SLAs, Users/Roles Architecture Managed Tenant + Analytics Hub Linked Dataset Direct Managed / BYOBQ Dataset Data Freshness Near real-time (< 5–10 mins) Synchronized continuous background sync License Tier Enterprise Plus Requires SOAR Advanced Reporting Dataset Name in BQ secops_linked_datalake siemplify_search_everything_db Access Method Project IAM (roles/bigquery.dataViewer) Support Case or Backstory bigqueryAccess API Deduplication Automatic Fine-Grained DML (FGDML) Merges Managed backend synchronization  Helpful References Stream data with Advanced BigQuery export (Official Docs)  SOAR BigQuery Schema Reference (Official Docs)  Use the BigQuery Access API (Legacy)  Google Cloud Security Community Discussions Google Security Operations Tue, 01 Sep 2026 05:22:28 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/part-2-google-secops-data-in-bigquery-demystifying-advanced-bigquery-export-siem-vs-legacy-bigquery-soar-8176 Part 2: SOAR Data Limitation & Accessing Legacy BigQuery Important Platform Note:SOAR data is not currently supported in Advanced BigQuery Export.(Documentation Reference: "Data from Google Security Operations SOAR (search_everything_db) isn't supported in Advanced BigQuery Export.")To query case management, playbook runs, and SOC response metrics in BigQuery, you must access the SOAR BigQuery database (siemplify_search_everything_db) via the legacy/BYOBQ pipeline.Prerequisites for SOAR BigQuery AccessSOAR Advanced Reporting Enabled: Your Google SecOps tenant must have SOAR Advanced Reporting enabled before the platform can publish data to BigQuery. Identity: You need a valid Google Account / Workspace Identity (GAIA) or Service Account.How to Grant / Request Access to SOAR BigQueryThere are two primary methods to obtain access:Method 1: Open a Google Cloud Support CaseIf you are setting up BYOBQ or need your SOAR tenant's BigQuery dataset linked to your project/analyst accounts, submit a case via the Google Cloud Support Portal with your Customer ID, SecOps instance details, and the analyst/service account email addresses requiring access.Method 2: Use the BigQuery Access API (Legacy Backstory API)You can programmatically grant access using the BigQuery Access API with an authorized OAuth2 Service Account token (https://www.googleapis.com/auth/chronicle-backstory):Endpoint: httpPATCH https://backstory.googleapis.com/v1/tools/bigqueryAccess:updateRequest Body: json{"email": "analyst@yourdomain.com"}Response: json{"email": "analyst@yourdomain.com","roles": "bigquery.dataViewer, bigquery.jobUser, storage.objectViewer"}This automatically assigns the required IAM permissions (roles/bigquery.dataViewer, roles/bigquery.jobUser, roles/storage.objectViewer) to query the managed project.  Helpful References Stream data with Advanced BigQuery export (Official Docs)  SOAR BigQuery Schema Reference (Official Docs)  Use the BigQuery Access API (Legacy)  Google Cloud Security Community Discussions Google Security Operations Tue, 01 Sep 2026 05:21:19 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/part-1-google-secops-data-in-bigquery-demystifying-advanced-bigquery-export-siem-vs-legacy-bigquery-soar-8175 Author: hzmndt@google.comCategory: Google Security Operations / SIEM & SOAR AnalyticsReading Time: 8 min IntroductionAs SOC teams mature, combining detection engineering, incident response, and business intelligence is critical for executive dashboards, metric tracking (MTTD/MTTR), and correlation with non-security business data.Google Security Operations provides direct access to your data in Google Cloud BigQuery. However, there is an architectural distinction you need to understand between SIEM telemetry and SOAR operational data:SIEM Telemetry (UDM Events, Detections, IoCs, Entities): Handled by the modern Advanced BigQuery Export streaming architecture. SOAR Operational Data (Cases, Alerts, Playbooks, SLAs): Currently not included in Advanced BigQuery Export and still accessed via Legacy BigQuery / BYOBQ (siemplify_search_everything_db).This guide covers how both pipelines work, the datasets available in each, how to gain access, and practical use cases for analyzing your SOAR data in BigQuery. Part 1: Advanced BigQuery Export (SIEM Data)Advanced BigQuery Export is a streaming pipeline for Google SecOps Enterprise Plus customers.Instead of requiring customers to maintain heavy ingestion jobs, Google manages the storage and streaming pipeline via the BigQuery Storage Write API in a dedicated tenant project. Customers receive a read-only Linked Dataset named secops_linked_datalake directly inside their own Google Cloud Bring-Your-Own-Project (BYOP). ┌─────────────────────────────────────────────────────────┐│ Google SecOps Managed Tenant ││ ┌──────────────┐ Storage Write API ┌────────────┐ ││ │ Ingestion & │ ────────────────────► │ Managed BQ │ ││ │ Normalization│ (Fine-grained DML) │ Storage │ ││ └──────────────┘ └─────┬──────┘ │└───────────────────────────────────────────────┼─────────┘│ Analytics Hub /│ Linked Dataset┌───────────────────────────────────────────────┼─────────┐│ Customer BYOP Project │ ││ ▼ ││ `secops_linked_datalake`│ (events, rule_detections,│ ioc_matches, entity_graph)└─────────────────────────────────────────────────────────┘Key HighlightsNear Real-Time Data Freshness: Telemetry streams in within < 5–10 minutes of ingestion. Predictable Cost: Google absorbs all ingestion, streaming insert, and storage costs. You only pay for BigQuery compute queries you run in your BYOP. Automated Deduplication: Uses Fine-Grained DML (FGDML) merges to handle late-arriving and re-enriched events in place.Available SIEM Linked Datasets & FreshnessThe secops_linked_datalake dataset exposes the following tables/views:Table / Dataset Name Description Target Freshness Deduplication Unique Identifier events Normalized security events in the Unified Data Model (UDM) schema. < 5 minutes id (String representation) rule_detections Detections generated by Google SecOps YARA-L detection engine rules. < 5 minutes detection.id ioc_matches Indicator of Compromise (IoC) matches against UDM events (global & customer feeds). < 5 minutes Composite key: day_bucket_seconds, feed_log_type, ioc_type, ioc_value entity_graph Contextual data about entities (users, assets) and their relationships. ~4 hours (Batch) Composite key: partition_day, metadata.product_entity_id, metadata.event_metadata.id ingestion_metrics Statistics on log ingestion volume, produced events, and unparsed errors. ~5 minutes None (Append-only time-series) entity_enum_value_to_name_mapping Maps numeric enum values to human-readable strings for Entity Graph. Static / Reference None udm_enum_value_to_name_mapping Maps numeric enum values to human-readable strings for UDM events. Static / Reference None  Quick Verification Query: sqlSELECTmetadata.event_timestamp,metadata.product_name,metadata.event_type,principal.ip,target.ipFROM`YOUR_PROJECT_ID.secops_linked_datalake.events`WHEREmetadata.event_timestamp >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 1 HOUR)LIMIT 10;Helpful References Stream data with Advanced BigQuery export (Official Docs)  SOAR BigQuery Schema Reference (Official Docs)  Use the BigQuery Access API (Legacy)  Google Cloud Security Community Discussions Google Security Operations Tue, 01 Sep 2026 05:19:35 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/demystifying-google-secops-soar-connector-routing-how-environments-aliases-and-the-default-environment-actually-work-8174  Hi everyone,One of the most common architecture questions we see when setting up multi-tenant or multi-project environments in Google SecOps SOAR is:"Is the Default Environment a temporary holding container that will automatically re-route cases once we create the respective environment?"The short answer is no. In Google SecOps SOAR, the Default Environment is a permanent fallback container, not a temporary staging queue.Related earlier community posts:    To help SOC admins, engineers, and MSSPs design reliable ingestion pipelines and avoid alert visibility gaps, let’s break down how connector environment resolution, regex extraction, aliases, and user notifications actually work under the hood.1. The Three Environment Settings in SOAR ConnectorsWhen configuring any SOAR connector (SOAR Settings > Ingestion > Connectors), there are three key parameters that govern environment routing:Parameter Purpose How it Behaves Environment Connector Fallback / Base Environment In case the alert's environment field is empty, missing, or unmapped, the alert is injected directly into this configured environment (defaults to Default Environment, but can be customized to any specific environment per connector instance). Environment Field Name Payload JSON Path Describes the name/JSON path in the alert payload where the tenant or environment identifier lives (e.g., labels.project_id, target.labels.env, detection_ruleLabels_soar_environment). Environment Regex Pattern Regex Transformation A regular expression evaluated against the value found in Environment Field Name (default is .* to take the entire string). If capture groups (.*) are used, Group 1 is returned. 2. The 4-Step Resolution PipelineWhen an alert or detection is ingested, the engine evaluates environment mapping in a strict 4-step sequence: nRaw Alert Payload]│▼uStep 1: Check Environment Field Name]├── Field is MISSING or EMPTY ──────────► Silent Fallback to Connector's 'Environment']└── Field is PRESENT with a Value│▼CStep 2: Apply Environment Regex Pattern]├── Regex Fails / Evaluates to Empty ──► pSilent Fallback to Connector's 'Environment']└── Regex Matches (Extracted String)│▼SStep 3: Exact Match Lookup (Case-Sensitive)]├── Matches an Environment Name ──────► gRoute to Target Environment (e.g. SOC1)]├── Matches a Configured Alias ───────► mRoute to Target Environment (e.g. SOC1)]└── NO MATCH (Unregistered String)│▼�Step 4: Missing Environment Trigger]├── 1. Trigger User Login Notification ("Environment <Name> does not exist in the system")└── 2. Route Case to Connector's Fallback 'Environment' (e.g. 'Default Environment')3. Missing vs. Unmatched Telemetry: Understanding the Login NotificationA critical detail that often catches teams by surprise is the difference between an empty field and an unmatched field:When the field is Empty or Null: The connector simply routes the alert to the connector's configured fallback Environment. No user notification is triggered because the alert did not request a specific environment. When the field contains a Value, but that Value does NOT exist in SOAR: The alert still routes to the fallback Environment, AND SOAR generates a User Notification. When administrators or users log in to the SOAR web interface, they will see a notification in the top navigation bell / banner: "Environment XYZ was not found in the system. The alert was assigned to the Default Environment." 4. The Superpower of Environment AliasesIn cloud and enterprise environments, telemetry arrives with infrastructure identifiers (e.g., GCP project IDs prj-soc1-prod-core, AWS account IDs 123456789012, or specific domain suffixes). However, analysts need cases grouped cleanly by business units (e.g., SOC 1).Environment Aliases bridge this gap:Many-to-One Consolidation: You can add multiple aliases to a single Environment under SOAR Settings > Organization > Environments. Display Normalization: When an alert matching an alias (e.g., prj-soc1-prod-core) arrives, the Case is created under the parent environment (SOC1), and displays on the Cases Queue under the clean Display Name (SOC 1). Case Sensitivity: Remember that alias matching is strictly case-sensitive (SOC1 $\neq$ soc1).5. Why Does This Matter? (Downstream SOC Impact)If an alert unexpectedly lands in the Default Environment instead of its intended environment:Analyst Queue Visibility: Analysts scoped via RBAC to only see their business unit (SOC1) will not see the case. Alert Grouping Boundaries: Alerts in the Default Environment will never merge or group into open cases belonging to SOC1, resulting in split/fragmented investigations. Playbook Execution: Playbooks in Dynamic Environment Mode will fall back to default global integration credentials, which can cause third-party API actions to fail if credentials are tenant-isolated. Retroactive Ingestion: When you add the missing alias, future alerts will route properly, but existing cases remain in the Default Environment unless manually reassigned by an analyst.6. Admin Best Practice ChecklistReview User Notifications Regularly: Check the notification bell upon login to catch newly created cloud projects or unmapped telemetry. Proactive Alias Registration: When onboarding new cloud projects or accounts, add their project IDs into the environment's Aliases list before enabling data ingestion. Verify Flattened Keys in Logs: If dynamic routing isn't matching, check connector debug logs to ensure you are referencing the correct flattened JSON key path (e.g., target_labels_project_id vs target.labels.project_id).Hope this helps clarify how environment routing and the Default Environment work in Google SecOps SOAR!How is your team currently structuring environment aliases across multi-cloud environments? Let us know in the comments!Recommended Tags for the Post:Google SecOps SOAR Connectors Multi-Tenancy Case Management Best Practices Google Security Operations Tue, 01 Sep 2026 03:45:40 +0200 https://security.googlecloudcommunity.com/google-security-operations-66/adoption-guide-reliable-soc-metrics-measuring-the-efficacy-of-your-soc-using-secops-8172  Author: Ivan Ninichuck, Google Cloud, Technical Solutions Engineer For years, Security Operations Centers (SOCs) have relied on vanity metrics—alert counts, raw ingestion volumes, and basic averages—that fail to communicate actual risk reduction to the business. Most SIEM dashboards fail to influence leadership because they measure computation, not security. A dashboard showing "10 Billion Events Processed" or "500 Tickets Closed" is an operational expense report, not a measure of resilience. The transition to a "Narrative SOC" requires moving away from the "What happened?" dashboard toward a "How effectively are we mitigating our primary threat models?" narrative. The Illusion of the Global Average Historically, SOCs have reported global averages to leadership—a single Mean Time to Resolve (MTTR) that blends every alert across the enterprise into one easily digestible, yet entirely misleading, number. Treating a potential nation-state beaconing event the same as a routine, failed password reset is a critical failure in executive communication. When you aggregate everything, your metrics lose their narrative power. A phenomenal 2-hour MTTR for a Critical alert is overshadowed by a sluggish 48-hour MTTR for a Low-priority informational alert, resulting in a mediocre "average" that tells leadership nothing about your actual defensive posture.To shift the focus away from sheer volume, your reporting must clearly demonstrate the SOC’s ability to effectively prioritize. Leadership doesn't need to know that you processed ten thousand alerts; they need to know that human cognitive load was spent exactly where it mattered most.  Measuring What Matters: Maximum Attention vs. Automated Dismissal The core of modern SecOps reporting is demonstrating the dual-path division of your workflow. You must show how threats requiring maximum attention are isolated and relentlessly pursued, while low-risk, high-volume cases are systematically dismantled by automation.To do this, your metrics should track the Divergence of Effort: The Critical Path (Maximum Attention): Measure the dwell time and investigation depth of high-severity incidents. The metric here isn't just speed; it's thoroughness. How quickly did the team pivot from the initial detection to identifying the root cause, hunting for lateral movement, and fully neutralizing the adversary? The Automation Funnel (Low-Risk Closure): Conversely, for low-priority alerts, speed and touchless resolution are the goal. Track the Auto-Closure Rate—the percentage of low-fidelity alerts that are enriched, scored, and closed by automation without a single human analyst ever looking at them. By presenting these two metrics side-by-side, you prove to leadership that you are actively protecting your most expensive resource—analyst brainpower—from alert fatigue, reserving it for actual combat. The "Real Story" for the Board When presenting to the C-suite or the Board, abandon the operational minutiae. The real story that must be told revolves around three strategic pillars:1. Efficacy Against Critical Adversary Activity Leadership wants to know: Are we stopping the bad guys when it counts? Frame your Critical priority metrics around the attack lifecycle. Show the "Time to Containment" specifically for high-risk vectors like ransomware precursors, privileged identity compromises, or data exfiltration attempts. If your MTTC for Criticals is dropping, you are empirically proving that the organization is becoming more resilient against catastrophic damage.2. Efficiency in Eradicating Noise and False Positives You must prove that the SOC is not a static, reactive entity, but a self-optimizing engine. Showcase the multiple strategies your team uses to quickly deal with false positives. This includes metrics on: Tuning Velocity: How quickly are noisy rules rewritten or suppressed? Contextual Enrichment: How often does automation accurately demote an alert's severity because the asset is non-critical or the behavior is historically normal for that user? Showing a high volume of False Positives isn't a failure if paired with a metric showing that 95% of them were handled automatically in under three minutes. 3. Illuminating Areas for Improvement (The Strategic 'Ask') The most powerful use of priority-based metrics is using them to highlight what isn't working, without framing it as a failure of the team. By breaking down response times by threat type and priority, you expose systemic gaps. Example: "Our MTTR for Critical endpoint threats is 30 minutes, but our MTTR for Critical cloud-identity threats is 4 hours." This is the ultimate narrative shift. You aren't just reporting numbers; you are using the data to highlight an architectural blind spot, paving the way to justify a new budget for IAM security tooling, specialized cloud-forensics training, or additional headcount in a highly specific area. Data-driven humility—showing exactly where the adversary still has an advantage—is the hallmark of a mature, narrative-driven SOC. Part 2: The MTTx Alphabet Soup – Standardizing Your Timeline The Lifecycle To calculate Mean Time to Detect (MTTD), Acknowledge (MTTA), Contain (MTTC), and Resolution (MTTR), you must define the precise timestamps used in your architecture.Consistency in the UDM and SOAR Google SecOps provides highly granular timestamps that often confuse metrics if not standardized: Event Time (metadata.event_timestamp): When the action actually occurred on the endpoint. Collection Time (metadata.collected_timestamp): When the log aggregator picked it up. Ingestion Time (metadata.ingested_timestamp): When Google SecOps parsed it into UDM. Detection Time: When the YARA-L rule successfully matched and created a detection. Case Creation Time: When Google SecOps SOAR instantiated the case. Best Practice: * MTTD: Detection Time minus metadata.event_timestamp. (This exposes logging pipeline delays). MTTA: SOAR First Action Taken (or Assigned to Analyst) - Creation Time. MTTC: Time of SOAR Playbook Action: (Isolate Host/Block Hash) - Case Creation Time. Let’s look at some actual curated dashboards in SecOps that will get you started. You can combine these types of dashboard queries around other capabilities such as case stages to provide data points that can be used to define your metrics. Go to the dashboards menu and filter it for ones that have Google Secops as the owner. This makes it easy to find out what dashboards are provided out-of-the-box(ottb)  SOC Workflow Monitoring:   The SOC Workflow Monitoring is a good starting point for finding your base MTTX metrics. The image above only shows part of the dashboard there is more if scroll below. Let’s dive in and learn how these dashboards work.  When you click on the three dots at the top right of any chart in the dashboard you see the option to view the query.  Query for MTTR(Mean-Time-To-Resolution) Lets walk through the query first, you can see the whole query in the image below. Stage stage1: The query is broken into two stages. The first stage is first taking every case_id and aggregating them together by their ids. For each of the cases we then define some outcome variables to use in the next stage. First we set a close_time variable by using a conditional clause that looks for closed cases and gives their close time(notice we use a max for the case.history.event_time as this will find the last event in the case flow) and if they are open the value is assigned a zero. Next we create an array of the case statuses. Next we use the close_time followed by the first event in the case(notice this time we use min with case.history.event). We then have a conditional that makes it so only cases that have both a status of open and closed are returned by the search stage.  Root stage: The match and outcome variables are now available for further use in the root stage of the search. The root stage uses the counts and time ranges from stage 1 to find the average of the close times. This provides the final meant-time-to-resolution.  stage stage1{$case_id = case_history.case_response_platform_info.case_idmatch: $case_idoutcome: $case_close_time = max(if(case_history.case_activity = "CLOSE_CASE", case_history.event_time.seconds, 0)) $status = array_distinct(case_history.case_activity) $TTC = $case_close_time - min(case_history.event_time.seconds)condition: arrays.contains($status, "CREATE_CASE") and arrays.contains($status, "CLOSE_CASE") }outcome: $case_count = count($stage1.case_id) $MTTC = (math.round(avg($stage1.TTC)/60))Expanding the Resolution Story Let’s change the chart so it doesn’t just tell the overly general average. First we duplicate the chart and choose the pencil icon to edit. Once in edit mode we scroll down to the chart setup. The chart was a metrics chart which only shows one value. For this example we will change it to a table. Also giving a chart an easily understood name is very important. Be sure to say plainly what is being shown. Now for the query we are going to use a different method to calculate closure time. The reason for this is the data set case.history and case would require a join. We can avoid this heavier operation by settling on just using the case dataset. Remember, there can be multiple ways to reach the same objective in SecOps.  stage stage1{//event variable $h used for case.history dataset while $c is case dataset$h.case_history.case_response_platform_info.case_id = $case_id$c.case.response_platform_info.response_platform_id = $case_id$c.case.priority = $c_prioritymatch: $c_priority,$case_idoutcome: $case_close_time = max(if($h.case_history.case_activity = "CLOSE_CASE", $h.case_history.event_time.seconds, 0)) $status = array_distinct($h.case_history.case_activity) $TTC = $case_close_time - min($h.case_history.event_time.seconds) $Priority = array($c_priority)condition: arrays.contains($status, "CREATE_CASE") and arrays.contains($status, "CLOSE_CASE") } $Priority = $stage1.Prioritymatch: $Priorityoutcome: $case_count = count($stage1.case_id) $MTTC = (math.round(avg($stage1.TTC)/60))order: $Priority asc The first change that was made is we added a second dataset to the query. Originally only the case.history dataset was utilized, but this time we want the priority of the case. In order to do this we must create a join between the two datasets. The first step is to assign each set its own event variable. The letters chosen are h (for history) and c(for case). Notice I am careful to put comments that explain the meaning behind my choices. I then find the field for case_id in each of the datasets and create the placeholder $case_id. This then is my join and now I can use data that is in either set of results.  Next I add a placeholder that tracks the case priority, $c_priority and use that in the match section. For simplicity I created an outcome variable $Priority to capture the priority of the resulting case. The root stage is almost identical except I add this $Priority value as the match variable, thus the results are broken up by severity. The results are the table below.  It is worth doing these types of drill downs on several different metrics in order to determine exactly what parts of the story are causing the conclusions. For example an average even when broken down across priorities is still prone to be being affected heavily by outliers. In that case you would want to combine your mean charts with those set to calculate median. It would be the same stage setup for the case close times but instead of the average function you would apply the median function in your Yara-L. The median will give you a much better idea of what your data actually represents in terms of capabilities. Adding a Max and Min metric along with your median will provide enough of the story that further inquiries into the exact bottlenecks can be made with precision. These examples centered around the MTTR but they can be applied to any metric values.  Part 3: The Hidden Tax – Correlation Between False Positives and MTTD The Noise RatioA 10% increase in False Positives (FPs) does not just waste time; it actively suppresses MTTD for true positives. In Google SecOps, noisy rules flood the case queue, burying critical alerts. Analyst FatigueWhen analysts experience "alert fatigue," the MTTR skyrockets because cases sit in the unassigned queue. The psychological impact creates a "latency lag." If an analyst assumes a specific YARA-L Curated Detection is usually benign, they will subconsciously deprioritize it. Measurement: The Cost of InvestigationCalculate the Hidden Tax  Query logic: Calculate the total duration (MTTR) of all SOAR cases closed with the root cause Not Malicious. Present this metric to leadership as the "Financial Cost of Poor Tuning." Part 4: Precision over Volume – False Positive Remediation The Feedback LoopHow many FPs are "tuned out" directly in YARA-L vs. forcefully closed by analysts in SOAR? A healthy SOC closes the loop. When an analyst tags a case as an FP in SOAR, a playbook should ideally capture the exception parameters and push them to a tuning review queue. Tuning Velocity via RetrohuntMeasure how long a known noisy rule stays active. In Google SecOps, you can dramatically accelerate Tuning Velocity using Retrohunts. Instead of deploying a tuned rule and "waiting to see," security engineers should modify the YARA-L rule then run a Retrohunt against historical UDM data and mathematically prove the noise reduction. Be sure that alerting is turned off during this testing.  The resulting reduction in detections can now be measured  Part 5: Breaking the Average – The Power of Median Statistics The "Mean" TrapMean averages are easily skewed. A single complex APT investigation that remains open in SOAR for 45 days will ruin an entire month's MTTR metrics. Why Median MattersUse the Median values in the dashboard to find the values in different percentiles of your data.  50th Percentile (Median): Represents the true daily experience of your analysts. 95th Percentile: Represents the worst-case scenarios and edge-case investigations.   Trend IdentificationBy tracking the 50th and 95th percentiles on a time-series chart, you can immediately see if a spike is a systemic process failure (both median and 95th rise) or a singular outlier (only the 95th spike). Example Charts: Median-Time-To-Remediate: This chart will be another metric type stage stage1 {$case_id = case_history.case_response_platform_info.case_idmatch: $case_idoutcome: $case_close_time = max(if(case_history.case_activity = "CLOSE_CASE", case_history.event_time.seconds, 0)) $status = array_distinct(case_history.case_activity) $TTC = $case_close_time - min(case_history.event_time.seconds)condition: arrays.contains($status, "CREATE_CASE") and arrays.contains($status, "CLOSE_CASE")}outcome: $case_count = count($stage1.case_id) $MTTC = math.round(window.median($stage1.TTC, false) / 60)Median Percentiles: Here is an example of what the output will look like. Obviously your TTC will match your data. These values show you exactly what the top 10% of your cases, middle 50% of your cases and bottom 20% of your cases take your team to close.   stage stage1 {$case_id = case_history.case_response_platform_info.case_idmatch: $case_idoutcome: $case_close_time = max(if(case_history.case_activity = "CLOSE_CASE", case_history.event_time.seconds, 0)) $status = array_distinct(case_history.case_activity) $TTC = $case_close_time - min(case_history.event_time.seconds)condition: arrays.contains($status, "CREATE_CASE") and arrays.contains($status, "CLOSE_CASE")}outcome: $case_count = count($stage1.case_id) $p90_TTC = math.round(window.percentile($stage1.TTC, 90) / 60) $p50_TTC = math.round(window.percentile($stage1.TTC, 50) / 60) $p20_TTC = math.round(window.percentile($stage1.TTC, 20) / 60) Part 6: Priority-Based Reporting – Stop Treating Every Alert the Same The Priority LensAggregated MTTx is useless for showing the ability of your team to separate the utility spent on high/critical alerts versus those with a lower priority. Low priority cases should have numbers that represent the amount of automation used in the entire lifecycle of the case. This ROI begins to be lost when MTTx is not shown based on priority. This type of breakdown also can show you quick wins when increasing the usage of AI directed investigation decision making. This distinction is important to highlight when reporting the overall metrics of success.  Part 7: Investigating the Outliers – The "Long Tail" Analysis What the Averages HideDedicate a specific dashboard to the "Long Tail"—cases exceeding the 95th percentile for MTTC/MTTR. These are your architectural failures. Root Cause CategorizationWhen analyzing Long Tail cases, mandate that analysts categorize the delay upon case closure in SOAR. Was the delay caused by: Visibility Gap: (e.g., EDR wasn't installed on the server, requiring manual forensics). Ingestion Delay: (metadata.collected_timestamp was hours behind event_timestamp due to a broken forwarder). Process Delay: (Waiting on third-party IT to approve a firewall block).   Turning Data into BudgetLong Tail data is your budget justification. If 40% of outliers are categorized as "Visibility Gaps" in cloud environments, you now have the empirical data to justify the purchase of Cloud Workload Protection (CWPP) or expanded Google Cloud Audit Log ingestion. Part 8: The "Tempo" Metric – Measuring OODA Loop Efficiency Strategic SpeedThe OODA (Observe, Orient, Decide, Act) loop in SecOps dictates survivability. "Tempo" measures the friction between these phases. In Google SecOps, Observe/Orient happens in the SIEM; Decide/Act happens in SOAR. Automation ImpactTo measure true automation  impact, track the time spent executing automated playbooks vs. the time cases spent in "Wait for User Input" or "Manual Task" blocks. Metric: Machine-to-Human Time Ratio. If a playbook takes 2 hours to execute, but 1 hour and 55 minutes of that was waiting for an analyst to click "Approve Isolation," your automation is not the bottleneck—your human workflow is. AI usage should be its own metric as well. Tracking this per case will show opportunities to use AI in specific use cases that it has a proven track record.   Part 9: The Continuous Feedback Loop – Evolving Your Metrics Metric DecayMetrics have a shelf life. Goodhart's Law states that "When a measure becomes a target, it ceases to be a good measure." If you measure analysts purely on MTTR, they will prematurely close cases to game the system. You must continuously evolve metrics to counter this (e.g., pairing MTTR with a "Re-open Rate" metric). The Maturity ModelAs your Google SecOps deployment matures: Phase 1 (Reactive): MTTA, MTTR, Event Volume. Phase 2 (Proactive): False Positive Ratios, Tuning Velocity, Automation ROI. Phase 3 (Intel-Driven): MTTD against specific Mandiant APT groups, MITRE coverage depth, Entity Risk decay rates.   Next Steps: The Data-Driven Security Culture Utilize modern capabilities like Gemini in Security Operations. Start tracking the time saved by using LLMs to summarize complex alert clusters and generate YARA-L rules. Building a culture of data-driven security means empowering engineers to treat detection as code, incident response as a measurable pipeline, and the SOC as a strategic business asset.Additional Resource: Adoption Guide: Best practices for using Gemini Search in Google SecOpsAdoption Guide: Accelerating SOAR: A Practitioner's Guide to the Gemini Playbook Assistant in GoogleConclusion Transitioning to a modern, narrative-driven SOC requires moving beyond vanity dashboard metrics toward reporting that demonstrates true organizational resilience and strategic value. By implementing a framework that prioritizes high-severity adversary activity while automating low-risk noise, standardizing MTTx lifecycle definitions, and investigating the 'Long Tail' of operational outliers, security teams can expose systemic gaps and ground future budget requests in clear empirical data.Achieving this level of actionable security intelligence relies on rigorous technical mechanics: joining case and history datasets on case_id for precise tracking, leveraging median-based statistical integrity, and using YARA-L logic to systematically categorize investigation delays. Ultimately, adopting data-driven humility and engineering discipline turns abstract metrics into powerful tools for continuous improvement and strategic influence. Google Security Operations Mon, 31 Aug 2026 20:34:27 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/enhanced-cloud-audit-logging-for-google-secops-rule-changes-8160 Hey SecOps Community! When managing detection rules at scale—whether through the Google SecOps console, our REST/gRPC APIs, Terraform, or automated Detection-as-Code (DaC) CI/CD pipelines—governance and audit-ability are critical. Security teams need to know:Who updated or deployed this rule? When was a critical detection disabled or archived? Why did an automated rule deployment or update fail during CI/CD validation? Previously, answering these questions in Google Cloud Logging (Log Explorer) required extra work. While audit logs recorded resource paths and IDs (like ru_12345...), the human-readable rule name wasn't always available across every action—especially during failed operations (e.g., compilation syntax errors) or deployment status changes. Thanks to direct collaboration and feedback from our detection engineering community and enterprise customers, we've rolled out enhancements across our RuleService audit logging to ensure consistent, end-to-end rule name visibility across all actions and error states.What’s New?1. Rule Display Names on Deployment ActionsWhen rules are enabled, disabled, archived, or unarchived via UpdateRuleDeployment, Cloud Audit Logs now records the rule's displayName in the response payload. You no longer have to cross-reference rule UUIDs to know which detection had its deployment state changed. 2. Rich Error AnnotationsIf a rule mutation fails—such as a syntax error during CreateRule or UpdateRule, or a validation issue during UpdateRuleDeployment—the error message in protoPayload.status.message is now automatically prepended with the rule display name (e.g., rule "Suspicious PowerShell Execution": compiling rule: syntax error at line 12). 3. Consistent Visibility Across All Lifecycle ActionsWhether you are creating, updating, validating (VerifyRuleText), or managing deployment settings, rule display name identification is preserved across both success and failure paths.Important Nuance on Delete Calls (DeleteRule): Because successful DeleteRule API calls return an empty response payload ({}), rule display names are not present in successful delete response logs. For deleted rules, Cloud Audit Logs records the rule resource ID in protoPayload.resourceName. (Failed delete attempts will still include the annotated rule identifier in error logs). How to Query Rule Audit Logs in Cloud Logging (Log Explorer)Because rule names are now consistently present across payload fields and status messages, querying in Log Explorer is simpler. You can use global SEARCH() queries across all RuleService actions rather than building complex field-specific filters. Here are practical queries to bookmark:1. Search All Activity for a Specific Rule Name To find all audit events (creations, updates, deployments, errors) associated with a given rule:protoPayload.serviceName="chronicle.googleapis.com" protoPayload.methodName=~".*RuleService.*" SEARCH(".*Suspicious PowerShell Execution.*")2. Track Rule State Changes (Enable, Disable, Archive)To audit when deployment settings change for rules: protoPayload.serviceName="chronicle.googleapis.com" protoPayload.methodName=~".*RuleService.UpdateRuleDeployment.*" SEARCH(".*Suspicious PowerShell Execution.*")3. Find Failed Rule Updates and Syntax/Compilation ErrorsTo monitor CI/CD pipelines or detect failing rule modifications: protoPayload.serviceName="chronicle.googleapis.com" protoPayload.methodName=~".*RuleService.*" severity>=ERROR SEARCH("rule .*") Why This Matters for Detection Engineering & Compliance Frictionless Auditing: Search directly by detection name in Cloud Logging to see the complete lifecycle of a rule without maintaining external mapping tables. Faster CI/CD Troubleshooting: Immediate root-cause visibility in audit logs when rule validation or updates fail during automated deployments. Proactive Security Governance: Build log-based metrics and alerts in Cloud Monitoring to notify the team whenever critical production detections are modified or disabled.What's Next?These audit logging improvements are fully deployed across all regions.We want to give a huge thank you to the customers and community members whose detailed feedback and testing helped shape this update!Have you set up automated alerting on rule changes, or are you building Detection-as-Code pipelines with Google SecOps? Let us know in the comments below!   Google Security Operations Mon, 31 Aug 2026 20:13:14 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/how-can-chronicle-siem-be-used-for-storing-data-of-multiple-tenants-1112 We are looking to provide an MSSP type of service and build an XDR service, currently looking to explore how data of each tenant can be stored in chronicle SIEM, and then the automation part can be connected with chronicle SOAR. Basically, we are trying to understand how the multi-tenancy can be managed from chronicle SIEM.  Google Security Operations Mon, 31 Aug 2026 20:11:52 +0200 https://security.googlecloudcommunity.com/security-command-center-84/adoption-guide-customizing-security-and-compliance-with-custom-cloud-controls-8170 Author: Shreja Rangarajan, Google Cloud, Technical Solutions Engineer  Compliance Manager in Security Command Center (SCC) provides a comprehensive library of built-in cloud controls to monitor your environment against industry standards and best practices. However, your organization might have unique security requirements, internal policies, or compliance needs that go beyond standard checks. Custom Cloud Controls (the modern evolution of Custom SHA detectors) bridge this gap. They empower you to define your own rules using Common Expression Language (CEL) to scan your Google Cloud assets and identify specific conditions you consider risky or non-compliant. This allows you to tailor security monitoring precisely to your organization's needs, enforce custom governance policies, and enhance your overall cloud security posture. Note: Custom Cloud Controls are exclusive to Premium and Enterprise service tiers. Quick Reference: Custom Cloud Controls in Compliance Manager  Core Objective Tailor security monitoring by defining custom detection logic using CEL. Action Types Detective: Identify misconfigurations. Audit: Gather evidence. Implementation Checklist 1. Identify Target Resource (e.g., Compute Instance). 2. Write CEL Expression for evaluation logic. 3. Create Control via Console, CLI, or Terraform. 4. Assign to Framework for monitoring. Best Practices Use Specific Selectors to limit scope. Leverage Parameters for reusability. Test in Non-Prod environments first. Maintain Clear Documentation/Remediation steps.  Understanding Custom Cloud Controls Custom Cloud Controls evaluate the properties of a resource against a rule defined in Common Expression Language (CEL). Unlike rigid legacy checks, CEL provides a flexible and powerful way to inspect resource configurations stored in Cloud Asset Inventory.A Custom Cloud Control consists of the following components, including optional configuration for categorization tags and finding categories to help organize your security alerts: Target Resource Type: The specific asset type (e.g., compute.googleapis.com/Instance). Detection Logic (CEL): The boolean expression that evaluates the resource (e.g., checking if a specific field is true). Severity: The criticality of a finding (Critical, High, Medium, Low). Remediation Steps: Instructions for resolving violations. How Custom Cloud Controls Differ from Custom SHA Modules Custom Cloud Controls (powered by the Compliance Evaluation Service - CES) are the modern evolution of Custom Security Health Analytics (SHA) Modules. While both allow you to create custom detections for misconfigurations, they differ significantly in their architecture and capabilities. Here is a breakdown of the key differences between them:1. Language: CEL vs. Rigid YAML/JSON Custom SHA: Used a proprietary, more rigid YAML/JSON structure specific to the legacy SHA scanner. Expressing complex logic or conditional checks was difficult. Custom Cloud Controls: Leverage the Common Expression Language (CEL). CEL is a powerful, flexible, and industry-standard expression language that allows you to write highly specific, complex, and granular boolean logic to evaluate resource properties. 2. AI-Powered Creation: Gemini-Assisted Definitions Custom SHA: Required manual, expert knowledge of the proprietary security module schema and asset properties to write any detection logic. Custom Cloud Controls: Offer Gemini-assisted definitions. You can describe your security requirement in natural language (e.g., "Find all compute instances that don't have an internal IP address"), and Gemini will automatically generate the corresponding CEL expression for you. This significantly lowers the barrier to entry and speeds up the creation of custom governance rules. 3. Holistic Integration: Compliance Manager Custom SHA: Existed primarily as standalone custom detectors within the SHA scanner view. Custom Cloud Controls: Are first-class citizens in the new Compliance Manager. They integrate seamlessly into custom security frameworks, allowing you to track your custom requirements alongside built-in regulatory benchmarks (like CIS or NIST) in a unified dashboard. 4. Action Modes: Multi-Modal vs. Detective Only Custom SHA: Limited strictly to Detective mode (identifying violations after resources were deployed). Custom Cloud Controls: Support Detective and Audit actions. You can use the same logic to detect existing issues or generate evidence for audits. Real-World Scenarios: Think Like a Security Architect To understand the power of Custom Cloud Controls, imagine you are stepping into the shoes of a Security Architect. Here are the challenges you face on Day 1, and how Custom Cloud Controls help you solve them: Scenario 1: "The Data Sovereignty Lockdown" Your Challenge: The CISO calls. A new compliance regulation requires that all sensitive data in BigQuery and GCS must be encrypted using keys that your organization controls, not Google. You have 500 projects. How do you verify this instantly? The Custom Control Solution: You write a CEL expression that targets BigQuery tables and GCS buckets, checking for the presence of a Customer-Managed Encryption Key (CMEK). If a developer spins up a storage bucket without it, Compliance Manager flags it immediately.   Scenario 2: "The Shadow IT Budget Buster" Your Challenge: Your CFO notices compute costs are ballooning. You discover developers are spinning up massive, high-cost GPU instances (like a3-highgpu-8g) for "experimental" projects and leaving them running over the weekend. The Custom Control Solution: You create a control that creates findings for these instance types. They can then deploy it in Monitor Mode for the folders/projects where there is experimental testing happening and this will stop the budget bleed before it starts.   Scenario 3: "The Custom Audit Nightmare" Your Challenge: Your internal audit team has a strict custom security baseline that goes beyond standard CIS or NIST benchmarks. For example, they mandate that no default service accounts can be attached to Compute instances. The Custom Control Solution: Standard frameworks don't cover this specific internal rule. You write a Custom Cloud Control that inspects the IAM bindings of compute instances and flags any use of the default Compute Engine service account, maintaining your custom governance posture.   Scenario 4: "The Hardened VM Mandate" Your Challenge: You want to ensure your entire fleet is hardened against bootkits and rootkits. The directive is clear: Secure Boot must be enabled on every new VM. The Custom Control Solution: You define a control that evaluates the shieldedInstanceConfig of compute instances. You can monitor compliance across your entire organization and provide clear remediation steps for any VM found in violation.   Step-by-Step Configuration Using the Google Cloud Console In the Google Cloud console, go to the Compliance page.  Select your organization or project. Navigate to the Configure tab and click Cloud Controls.    Click Create Cloud Control. Manually: In the Detection logic section, select the target resource types and enter your custom CEL expression directly into the editor. Use this method if you have specific logic ready or need precise control over the rule definition.  Define Control Details: Enter a unique Cloud control ID, a descriptive Display name, and a detailed Description to help others understand the purpose of this rule. Select Resource Types: In the Resource types dropdown, browse or search for the specific Google Cloud assets (e.g., compute.googleapis.com/Instance) that this control will evaluate. Enter CEL Expression: Within the code editor, write your boolean logic using Common Expression Language (CEL). Ensure the expression correctly references the resource data fields you intend to inspect. Configure Severity & Remediation: Assign a Finding severity (Critical, High, Medium, or Low) and provide actionable Remediation steps to guide users on how to resolve non-compliant findings. Review and Create: Verify all configurations in the summary and click Create to activate the new custom cloud control.    Gemini Assisted (Preferred): Use the Gemini side panel or inline prompt to describe your security requirement in natural language. Gemini will analyze your request and generate the appropriate CEL expression and resource selection for you. Let's define a custom cloud control for Scenario 2: "The Shadow IT Budget Buster":  i. Write your scope statement in “Describe the control you need” dialog box and click on “Insert Selected” In the example below the scope statement we gave was: "Create a control that restricts instance type of a3-highgpu-8g from being created"  Move to the Define rules section and you should see the pre-filled CEL expression, choose the severity and write remediation steps if any.   Move to “Advanced options” where you can set Category tags, these tags are for group controls into categories of resource types.   Your control should look like below:   After creating a custom control, it must be assigned to a custom framework. To activate the control, you must first assign it to a framework and then attach it to a resource. Below are the steps to assign it to the custom framework:  a. Navigate to Configure > Frameworks > Create custom framework:   Define the Framework:   Select the cloud controls to include in this framework, which can be either built-in or Custom (in this instance, we will select the custom control we previously created).   After creating your custom framework, you must link it to a target resource, such as an organization, folder, or project. It can be attached only “Monitor” mode. In “Monitor” mode, the framework identifies and flags policy violations.  Browse the resource hierarchy to select the specific organization, folder, or project you want to assign the control to. Choose the "Monitor" mode, and click submit to apply the framework.    You should be now able to see the resource in the assigned column in the custom framework page. In Monitor Mode the below is what you observe: The framework acts in a Detective capacity, continuously scanning your resources for compliance. Policy violations are identified, flagged, and displayed as findings in the Compliance Summary dashboard. No actions are blocked; this mode provides visibility and auditing without interrupting workflows.  Best Practices for Custom Cloud Controls Principle of Specificity: Use resourceTypesValues or selectors to limit evaluation to only the necessary resource types to optimize performance. Reusable Parameters: Use parameter-spec to allow users to customize values (like allowed locations or maximum retention periods) without rewriting the control logic. Iterative Testing: Before full deployment, test controls in a non-production environment by creating both compliant and non-compliant assets to verify correct finding generation, or alternatively, initialize the Custom Cloud Control in monitor mode Clear Remediation: Although the remediation-steps field is an optional component of a custom cloud control definition, providing clear, actionable instructions ensures incident responders know precisely how to resolve the finding.  Implementing with Infrastructure as Code Using gcloud CLI You can manage controls programmatically. For example, to check if a KMS key rotation period is under 60 hours: gcloud compliance-manager cloud-controls create check-kms-rotation \--location=global \--organization=YOUR_ORG_ID \--display-name="Check KMS Key Rotation" \--severity=high \--finding-category="KMS_ROTATION_VIOLATION" \--rules="-{\"celExpression\": {\"expression\": \"has(resource.data.rotationPeriod) && resource.data.rotationPeriod < duration('60h')\", \"resourceTypesValues\": {\"values\": o\"cloudkms.googleapis.com/CryptoKey\"]}}, \"description\": \"Check KMS key rotation period\", \"ruleActionTypes\": d\"rule-action-type-detective\"]}]" Troubleshooting No Findings Generated?: Ensure the control is active and assigned to a deployed framework. Verify the CEL expression syntax and logic against test assets. Check IAM permissions; the service agent requires read permissions on the target resources. Evaluation Delays: Propagation times can vary. Allow time (potentially up to a few hours) for the service to evaluate assets. Parameter Substitution Errors: Double-check the substitutionRules syntax if using parameterized controls to ensure values are injected at the correct path. Conclusion Custom Cloud Controls represent a significant advancement in cloud security governance, shifting from rigid, legacy configurations to a flexible, policy-as-code model. By leveraging the Common Expression Language (CEL), security architects can design granular rules that precisely align with their organization's unique compliance frameworks and operational requirements.The key takeaways from this guide include: Multi-Modal Capabilities: Unlike detective-only tools, Custom Cloud Controls support Detective and Audit modes, allowing you to catch issues post-deployment or block non-compliant resources actively. Unified Compliance: Integration with Compliance Manager enables tracking custom requirements alongside industry standards (like CIS or NIST) in a single, cohesive dashboard. AI-Assisted Efficiency: Gemini-assisted definitions lower the barrier to entry by translating natural language security requirements into valid CEL expressions automatically. Implementing these controls iteratively, starting in non-production environments with clear remediation steps, ensures robust and scalable cloud security posture management. Documentation Links Managing Cloud Controls in SCC Writing CEL Expressions for Custom Controls Security Command Center Mon, 31 Aug 2026 19:40:56 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/curated-rule-pack-details-807 Can you please list of curated packs that would be available based on type of chronicle secops subscription. Like Enterprise contains only few curated packs versus enterprise plus would have more packs. Need pack names. Thanks you. Google Security Operations Mon, 31 Aug 2026 19:16:46 +0200 https://security.googlecloudcommunity.com/what-s-new-in-secops-91/what-s-new-in-google-secops-2026-08-31-8169 What’s New in Google SecOps for the interval August 24th through August 31st, 2026.  Highlights  Your chance to start building AI agents from the absolute basics A 5-week live series called “Agent Valley” designed to teach anyone how to build production agent systems. Ingesting Flight Data into Google SecOps with Bindplane’s REST API Source Leveraging the native Bindplane REST API and processors instead of a Cloud Function to ingest flight data (from Mike) Bringing Your Own Agents into SecOps SOAR Playbooks with Google ADK Using the Google Agent Development Kit (ADK) to integrate non-deterministic agents with Gemini Enterprise (from Chris Martin (@thatsiemguy)) SIEM: Centralize Like You Mean It, Federate Like You Have To Excellent architectural advice on treating centralization as the default for critical detections and knowing when to federate (from Anton Chuvakin) 🧙 Inside 90 days of attacks on AI infrastructure An analysis of active honeypots showcasing active threat campaigns targeting AI infrastructure via RCE, prompt injection, and credential theft from the Wiz Blog  Product Updates & New Features Google SecOps  Release Notes from Google Cloud Docs Google Cloud’s Chronicle has released new Mandiant Frontline Threats rule packs for Curated Detections, enhancing threat detection across Linux, MacOS, and Google Cloud environments. ORead More] Note, Curated Detections does not provide proactive notifications of new content, and you will have to go and explicitly enable new Rule Sets.  New Mandiant Frontline Threats Curated Rules Google SecOps has launched a new ‘Operations’ feature in its Emerging Threats Center, offering granular, single-organization threat intelligence derived from frontline investigations. eRead More] Afaik, this is like a smaller version of a Campaign  What is an Operation? Google Cloud Chronicle’s SOAR database and infrastructure are scheduled for maintenance on August 30, causing a brief system downtime but requiring no user action. yRead More] Google SecOps has released the Unroll processor, a new feature for data processing pipelines that enhances log ingestion by automatically splitting log arrays into discrete log events. lRead More] If you’ve had log sources sending data as a List of Dictionaries (e.g., like some Palo Alto log sources do), this processor is what you need; it allows you to split each JSON log into a unique log prior to the CBN processor running. Google Threat Intelligence  Release Notes from gtidocs.readme.io The August 26th release introduces Google Insights, a new feature that provides security teams with real-world telemetry and global prevalence data to better assess active threats. It also delivers powerful Agentic AI upgrades to streamline workflows, including automated Sigma rule translation and interactive URL screenshot analysis . Finally, the update bolsters defenses with expanded configuration extractors and new YARA rules covering over 25 newly tracked malware families. eRead More]   Google Cloud & AI  Using OKF with Knowledge Catalog to serve context for agents from Google Cloud Blog The article discusses the ongoing development of the Open Knowledge Format (OKF), an open specification used with Knowledge Catalog to provide context for agents and improve data sharing. oRead More] Your chance to start building AI agents from the absolute basics from Google Cloud Blog The article introduces “Agent Valley,” a new resource designed to help anyone, regardless of their technical background, learn how to build AI agents through hands-on experience. bRead More]  Learn to build agents in a 5 day course from Google DevRel Engineers  Decoding cosmic signals with deep learning and Keras from Google Developer Blog The article discusses the application of deep learning and Keras to decode cosmic signals, specifically within the exciting field of astroparticle physics. sRead More] This isn’t related to Google SecOps, but if you’re interested in Astronomy and some non-generative-AI machine learning, then this read on keras is very interesting. Adoption Guides & Deep Dives  Enriched URL Reports: Powered by Full Browser Execution from Google Cloud Security Community The article introduces Enriched URL Reports, powered by full browser execution, as a new feature within Google Threat Intelligence. This development is part of a broader shift towards intelligent, proactive cybersecurity defense leveraging Agentic AI workflows, which has recently launched in General Availability. sRead More]  Community & Events  Lifecycle of a SOAR Automation from Google Cloud Security Community The article from Dmitry Kosarev (Admiral Group) covers the lifecycle of SOAR automation, detailing how to identify, build, and maintain automations to streamline repetitive and laborious IT security tasks. iRead More] This is a good read on the process needed for life cycle of managing SOAR Playbooks in an Enterprise.  Webinar Alert on 09/09- How to navigate the Post-Quantum Cryptography Shift from Google Cloud Security Community This article announces a webinar focused on navigating the shift to post-quantum cryptography, highlighting its current status as a strict regulatory and procurement requirement due to recent executive orders and CISA standardization. iRead More] Unwrapping Kubernetes Logs in Google SecOps: A Jenkins Case Study from Google Cloud Security Community The article discusses the challenge of ‘log wrapping’ in Kubernetes when ingesting application logs into Google SecOps, and how this architectural shift impacts Security Operations, using Jenkins as a case study. GRead More] This is a good community blog post on the end to end setup of getting Jenkins logs into SecOps. 3rd Party Blogs  Ingesting Flight Data into Google SecOps with Bindplane’s REST API Source from Mike The article details the process of ingesting flight data into Google SecOps, utilizing Bindplane’s REST API as the data source. lRead More] This is a great read from Mike on replacing a Cloud Function with the native Bindplane REST API and Processors. Bringing Your Own Agents into SecOps SOAR Playbooks with Google ADK from Chris Martin (@thatsiemguy) The article discusses the integration of custom agents into Security Operations (SecOps) SOAR playbooks using the Google Agent Development Kit (ADK). tRead More] I’m a big fan of Google ADK, and use it frequently. This post demonstrates how to add non-deterministic Agents into SOAR Playbooks, and integration with Gemini Enterprise.️ SIEM: Centralize Like You Mean It, Federate Like You Have To from Anton Chuvakin The article discusses architectural strategies for Security Information and Event Management (SIEM) systems, emphasizing the importance of centralization while acknowledging the necessity of federation in certain contexts. nRead More] This is a great read providing guidance on treating centralization as the default for critical detections, and the logic for when to federate. Stop Building a 2003 SOC with AI: Local Context, Failure Modes and Your Path (Part 3) from Anton Chuvakin The article critiques current Security Operations Center (SOC) practices, urging modernization with AI while emphasizing local context and understanding AI’s failure modes. SRead More]  Podcasts & YouTube  From Exploit to Code Fix in Minutes: Google SecOps + CodeMender Self-Healing Security from YouTube The video describes Google SecOps and CodeMender’s rapid, self-healing security system that can fix exploits in minutes. HWatch]    Wiz  Inside 90 days of attacks on AI infrastructure from Wiz Blog Wiz honeypots detected a 90-day period of active attack campaigns targeting AI infrastructure, including LiteLLM, MCP servers, and other AI frameworks, through methods like RCE, blind prompt injection, and credential theft.aRead More] From Concept to Context Engine: How Wiz Built AI-Powered Data Discovery from Wiz Blog Wiz details its process of developing an AI-powered data discovery “context engine” from a “bucket scanner” using a multi-agent pipeline and feedback loops. Read More] Version Control DFIR: a Cheatsheet to GitHub, GitLab, Bitbucket, and Azure DevOps from Wiz Blog This article provides a practitioner’s guide and cheatsheet for Digital Forensics and Incident Response (DFIR) across major version control services like GitHub, GitLab, Bitbucket, and Azure DevOps, focusing on log visibility, incident readiness, and threat hunting. nRead More] The State of Cloud Risk 2026: Most Security Findings Aren’t Real Attacker Opportunities from Wiz Blog A Wiz Research report on cloud risk for 2026 reveals that the majority of high-severity cloud security findings do not represent genuine attacker opportunities or a path to compromise. oRead More]  Platform Issues  ONGOING: Investigating issues with saving rules in Google SecOps Unified Rules Public Preview Web UI from Google Cloud Status Google SecOps is investigating an issue preventing users from saving rules in the Unified Rules Public Preview Web UI, with engineers actively working on a mitigation. Read More] RESOLVED: We are experiencing an issue with Google SecOps Legacy Looker Based Dashboards where queries are failing in the europe-west9 region from Google Cloud Status Google SecOps Legacy Looker Based Dashboards are experiencing an issue with failing queries in the europe-west9 region. eRead More] What's New in SecOps Mon, 31 Aug 2026 12:39:50 +0200 https://security.googlecloudcommunity.com/community-blog-42/scaling-collective-defense-introducing-github-support-for-google-secops-parsers-7876 Author:Idan Patelsky, GCP Cloud Security Steward The ChallengeHistorically, managing parsers in Google Security Operations was a highly centralized and manual process. All parser development and maintenance was handled by an internal Google team, and sharing custom or partner-created parsers required direct, manual file sharing with individual customers. This closed parser ecosystem limited the community's ability to collaborate on data ingestion content. The SolutionTo eliminate these barriers, we are excited to announce the launch of SecOps GitHub Support for Parsers. We are expanding our open-source content to log ingestion as well. By hosting partner-created and community-contributed parsers in our public Google SecOps Content Hub repository on GitHub, we are transitioning to a collaborative, transparent, and scalable model.This launch introduces several core capabilities: Centralized Parser Catalog: A public, version-controlled repository containing partner-created and community-contributed parsers. Partner Empowerment: Certified partners (vendors, service providers) now have dedicated directories to directly upload, update, and maintain their product parsers, significantly reducing release cycles. Community Contributions: Customers, security practitioners, and community members can submit parser enhancements, bug fixes, or entirely new parsers via standard GitHub Pull Requests (PRs). Automated Quality Vetting: Every contribution triggers an automated CI/CD pipeline that runs extensive syntax checks, directory compliance, and unit tests. We have already uploaded 240 parsers to the SecOps GitHub Parsers folder, and this number is constantly increasing with new content contributions.  Reviewing the parser folder content in the community parsers GitHub repository How does it work?There are two main workflows: parser contribution and parser deploymentWorkflow A: How to Contribute or Enhance a GitHub ParserInitial setup is simple and requires signing a Contributor License Agreement (CLA) and setting your SecOps tenant as explained here.If you are creating a new parser, set-up your folder based on the parser convention as explained here.   Follow these steps to create and validate your Pull Request. Example of the validation tests process when contributing parsers content Workflow B: How to Deploy a Community ParserOnce you’ve located the required parser, Open the ‘metadata.json’ file to confirm supported log formats, references, and the associated Google SecOps Log Type identifier, and verify this parser meets your requirements.Then, follow these steps to deploy the parser in your SecOps tenant. Wrapping upSecOps is a team sport, and log normalization is the gatekeeper. Transitioning to a community-driven model on GitHub enables the collective security community to scale ingestion capabilities, roll out parser bug fixes rapidly, and keep pace with a changing threat landscape.We invite you to explore the repository, deploy community parsers to expand your coverage, and submit your first parser contribution today!GitHub Repository: Google SecOps Content Hub on GitHub Public Documentation: Working with Community Parsers in Google Security Operations Report Bugs & Suggest Enhancements: Open a GitHub Issue Community Blog Sun, 30 Aug 2026 15:37:21 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/agentic-secops-how-do-we-balance-autonomous-response-with-deterministic-security-controls-8165 The recent discussion on agent graphs for SecOps AI runbooks highlights a central challenge for modern security operations: the goal is not simply to enable AI agents to reason and act, but to ensure that their actions remain predictable, auditable, and aligned with security policies.Agentic SecOps architectures that combine specialized security agents, orchestration layers, deterministic graph workflows, and clearly defined rules offer a promising approach to this problem.In my view, the strongest model is not fully autonomous security, but controlled autonomy.AI agents can support investigation, enrichment, threat intelligence correlation, prioritization, and response recommendations, while deterministic workflows define exactly how sensitive actions are executed.This creates a clear architectural separation of responsibilities:• AI agents provide reasoning and contextual intelligence.• Deterministic workflows provide execution discipline.• Security policies establish operational boundaries.• Human analysts maintain oversight for high-impact decisions.Policy-based guardrails, approval gates, confidence thresholds, rollback mechanisms, and complete audit trails could allow SOC teams to reduce response time without sacrificing governance or operational control.I would be interested to hear how others in the Google SecOps community are approaching this balance.Where should organizations draw the line between autonomous agent actions and deterministic security workflows?Which activities such as enrichment, alert triage, case creation, rule tuning, containment, or blocking are already mature enough to operate with minimal human intervention?And which controls should remain non-negotiable before an AI agent is allowed to execute a high impact response action? Google Security Operations Sun, 30 Aug 2026 15:32:22 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/when-we-are-expecting-secops-to-include-ability-to-schedule-report-in-pdf-format-6740 Google SecOps SIEM CMEK instance, there’s only option to schedule reports in csv format. We are expecting the pdf format as its simpler way to present data to Monitoring team. Google Security Operations Sun, 30 Aug 2026 10:16:34 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/findings-in-google-secops-a-scoped-viewer-missing-a-fake-cookie-8161 A Data RBAC user whose capability role is the predefined Chronicle API Restricted Data Access Viewer will have problems after logging into Google SecOps. The main session loses access within minutes behind a 403 error, and opening a new session fails with a misleading 401 cookie error. The root cause is a documented, easy-to-miss baseline in Map SOAR permissions to IAM: a minimum set of IAM permissions every user needs just to keep the application alive. Why is this important? Last week I faced this issue when one of our Google SecOps customers onboarded a third party on their instance with full read permissions scoped to only the third party's telemetry. That's just Data RBAC!However, our client showed us the error message:Your session cookie is missing. Please try refreshing the page.We inspected the configuration and everything looked just fine! The onboarded users had their SOAR Group Mappings enabled and their Google Cloud IAM bindings in place: the Chronicle API Restricted Data Access role conditioned to the Data RBAC scope, plus the Chronicle API Restricted Data Access Viewer capability role.It took us about an hour to discover that the issue was a few missing permissions in the predefined read-only role. We believe this is important to document because we often assume that out-of-the-box products and assets work seamlessly, and that is not always the case. Of course, the solution was to copy the predefined role and add the missing permissions documented in Required permissions for every role. The symptom and the cause NoteThe following effects were discovered in a Google SecOps unified instance with SIEM and SOAR (i.e., not standalone SIEM or standalone SOAR) that has migrated SOAR Permission Groups to Google Cloud IAM. If this is not your situation, you may not experience the behavior described below. Two apparently distinct effects that share the same root cause will occur if you happen to miss some or all of Google SecOps SOAR's Required permissions for every role, which can happen if you use a predefined scoped read-only access role such as Chronicle API Restricted Data Access Viewer (in Beta at the time of writing). In fact, we pulled that predefined role's definition through the IAM API: eight of the thirteen documented baseline permissions are missing from it. Scenario 1 A user logs into Google SecOps normally. A few minutes later, without touching anything, the page drops to an error: "You do not have the permissions required to view this page". Refreshing brings it back briefly.  The root cause of this first effect is a poll mechanism. About once a minute, the unified UI polls the userNotifications:count endpoint under the instance's legacySoarUsers path, and when the capability role lacks chronicle.userNotifications.get that poll returns HTTP 403 and drops the page to the error above. Granting that one permission solves this symptom.  Scenario 2 The same user tries to open a second Google SecOps session in another browser tab, but this time the session never finishes loading. The application fails with a 401 error and the misleading message "Your session cookie is missing. Please try refreshing the page.", and refreshing does not bring it back.  The root cause of the second effect is more complex, and the following explanation is our assessment after analyzing the HAR files captured while the problem occurred:The unified UI's SOAR module fetches a handful of endpoints when it loads (SOC roles, integrations, module settings, and others) and polls user notifications periodically on an already-open tab. Each of those calls returns HTTP 403 with IAM_PERMISSION_DENIED on permissions like chronicle.userNotifications.get and chronicle.socRoles.get when they are missing. On every 403, the front end assumes its SOAR session token went stale and mints a new one (POST <instance>:generateSoarAuthJwt), then retries again with no backoff. NoteAuthentication itself never fails here: the front end minted 141 JWTs in just over thirty seconds, and the first 137 all returned HTTP 200. The only four that failed hit the quota error described next. The mint endpoint's quota then runs out with a 429 RESOURCE_EXHAUSTED error: "You have reached the maximum allowed quota for this operation." Less than a second later the error page loads with the unrelated message "Your session cookie is missing. Please try refreshing the page."  NoteA fresh login half an hour later reproduced the same storm from a refilled quota, so nothing is banned server-side. The most likely reading of the hours-long lockout some users perceive is that each new attempt burns the token-mint quota again within its first minute and ends on the same error page. The solutionThe fix is creating a custom capability role:Clone the predefined viewer. Add the required-for-every-role baseline, or use a broader read-only custom role that already contains it. Save the custom role and assign it in place of the predefined viewer.The conditioned Restricted Data Access marker role stays as it is, and the baseline permissions are platform plumbing that keeps the session alive without widening what the user can actually do.When building custom or scoped roles for the unified experience, start from the "Required permissions for every role" list and add feature permissions on top, not the other way around. Google Security Operations Sat, 29 Aug 2026 23:13:26 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/need-help-on-udm-enrichment-8153 Hi Everyone,I have a problem around UDM enrichment and I would appreciate if someone can guide me to resolve this. Problem :The current user data is enriched with Azure AD Context and it is pulling all the data that is associated with the user present in the Azure AD. But, every user’s attributes have at least 500+ key-value pairs which are getting enriched as a part of the AD Context which is making the event data heavy with essentially too much garbage data that we don’t need at all. Below is one example: This screenshot is from the event details under the event tab:Because of this, the actual event/incident details are fully buried under this garbage. This is the SIEM Event details :  I have checked the documentation and did not find any way to remove the user attribute fields or configuration of event enrichment. Thanks in advance! Google Security Operations Sat, 29 Aug 2026 04:49:56 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/is-the-soar-siem-ui-slow-for-anybody-else-lagging-and-freezing-on-ide-and-data-tables-views-8157 Is the SOAR/SIEM UI slow for anybody else? Mine is lagging and freezing on IDE and data table views. I’m on Windows and Chrome Google Security Operations Sat, 29 Aug 2026 02:45:54 +0200 https://security.googlecloudcommunity.com/fraud-defense-recaptcha-6/recaptcha-enterprise-scores-dropped-significantly-since-about-a-week-7852 When checking the score-distribution on https://console.cloud.google.com/security/recaptcha/the scores dropped from this (first week of June) to this (first week of July)Obviously, this has a major impact on our users (schools & pupils, often starting our app at more or less the same time)Any idea why this is happening?  What I can do to improve this? ... Fraud Defense (reCAPTCHA) Fri, 28 Aug 2026 15:30:30 +0200 https://security.googlecloudcommunity.com/community-blog-42/exploring-agent-graphs-for-secops-ai-runbooks-8113 Author: Dan Dye, Adoption Engineer, Security, Google Cloud  The Agent Development Kit (ADK) project recently introduced graph-based agent workflows and I highly recommend Romin Irani’s Google ADK 2 Graph Workflows: A Complete Guide with Code Examples. Can we use that to add determinism to agentic SecOps workflows? My goals are: rigorous execution, deterministic control flows, known-working tool integration, and verifiable explainability. To that end, I’ve created an Agent Graph version of the ADK Runbooks, an open-source, multi-agent cybersecurity operations framework built on top of Google’s Agent Development Kit (ADK) and the Model Context Protocol (MCP). The Vision: Executable Agent GraphsIn the security operation center (SOC), a runbook is a set of instructions for a human analyst: extract the IP, query the SIEM, enrich via threat intelligence, check recent user authentication logs, and document findings in the ticketing system. Incident Response Plans (IRPs) are a runbook subtype. In the ADK Runbooks project, those runbooks are written for large language models (LLMs) (instead of humans) in persona-driven, multi-agent systems. This new work explores refactoring ADK Runbooks into agent graphs.  Domain-Specific Personas & DelegationAgents assume personas within the security organization. A few examples:Manager Agent: Coordinates high-level objectives and routes tasks based on structured YAML capability profiles. SOC Analysts (Tiers 1, 2, 3): Handle alert triage, deep-dive investigations, and complex root-cause forensic analysis. Threat Hunter: Proactively hunt across telemetry (using, for example, MITRE ATT&CK patterns). CTI Researcher: Synthesize Google Threat Intelligence (GTI) reports. Detection Engineer: Tune detection rules (ideally with Detection-as-Code) Incident Responder: Orchestrate incident response lifecycles (e.g. SANS PICERL).The Rules Bank: Grounding Agents in Enterprise RealityWe can tailor those agents by providing operational context. I don’t have that kind of context for a full fictitious organization (yet!), so my grounding context in the “Rules Bank” is instead domain expertise that codifies:Operational Runbooks & IRPs: Step-by-step tactical workflows and end-to-end incident response plans (e.g., Malware, Phishing, Ransomware, Compromised Accounts). Environmental Context: Log source mappings, asset criticality guidelines, network maps, and known benign baselines to minimize false positives. Explainability Standards: Clear templates ensuring every automated recommendation includes primary evidence, confidence scores, and referenced protocols (i.e. “rubrics”).Deterministic ADK Graph WorkflowsThe AI runbooks were already a step towards formalization of security work performed with the aid of reasoning language models. When I first configured a coding assistant with the MCP tools for Google SecOps and Google Threat Intelligence, there were lots of false starts and failures as the agent learned how and when to use the tools for each investigation. You don’t want to lose that hard-won knowledge when you clear the session. Instead, you can prompt for a “handoff” or skill creation (or runbook!) to capture what was effective.That works surprisingly well. The next agent is more efficient as it avoids the pitfalls. But could we take that formalization a step further with graph workflows? In this feature branch, I've converted 29+ runbooks and 4 Incident Response Plans into those deterministic ADK Graph Workflows (Directed Acyclic Graphs). Each step, from entity extraction and SeCops queries to VirusTotal/GTI enrichment and conditional risk routing, runs as a structured node with typed Pydantic schemas:  This guarantees predictable execution order while preserving LLM intelligence for reasoning when it is needed. MCP Security Tool EcosystemAgents interact with your security stack through standardized Model Context Protocol (MCP) servers: Google SecOps (Chronicle SIEM & SOAR): Ingest alerts, search UDM events, inspect entity graphs, and post case commentary. Google Threat Intelligence (GTI / VirusTotal): Score hashes, domains, and IP reputations with live actor campaign correlation. Identity & Endpoint Telemetry: Pivot seamlessly between user directories and host telemetry.Built-in Evaluation: LLM-as-a-Judge & PICERL MetricsTo evolve improvements, we need a hill to climb. Every runbook includes a rubric evaluated by an llm_judge agent. Every execution captures: Tool Trajectory via Mermaid sequence diagrams. These document the exact runtime call sequence. Execution Metadata & Token Metrics for minimizing cost and latency. Structured Findings formatted directly for SOAR case comments and executive summaries.Getting StartedThe project is structured for easy local experimentation:# Clone repository with submodulesgit clone --recurse-submodules https://github.com/dandye/adk_runbooks.gitgit checkout graph_v00001cd adk_runbooks/multi-agent# Set up environment & install dependenciespython -m venv .venv && source .venv/bin/activatepip install -r requirements.txt# Launch the ADK Web UI or CLIadk web What’s Next?My goal is to push the boundaries of Autonomous Security Operations. We’ve seen that interactive chat sessions can be formalized into runbooks, which can in turn be formalized into agent graphs. I think the next step is to formalize even more and to offload with SOAR playbooks. That may feel like a step backwards, but my thesis is that this workflow enables exploration (similar to exploratory data analysis) for new scenarios with the assistance of a reasoning agent. Once that is done, it is overkill to reason about it all over again. We can instead harness the existing, proven automation tools we have on hand.  Take it for a spin, test out the workflows against your test cases, and let me know your thoughts and feedback!Documentation & Runbook Index: dandye.github.io/adk_runbooks Source Code & Contributing: github.com/dandye/adk_runbooks Community Blog Fri, 28 Aug 2026 12:42:13 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/how-to-get-subkey-if-the-parent-key-is-dynamic-in-the-expression-builder-8156 Hi everyoneI'm getting a JSON in a playbook action. I want to reuse that json in another action of my playbook.I'm trying to get the value of a subkey “category” in a nested json like this{   “a”:{“category”:1},   “b”: {“category”:3}}I haven’t found a way to extract “category” values ignoring the parent keys.Is there a way to do it?I’m expecting to get a result like 1,3]Parent keys are dynamic and I can't predict or list every possibilitiesDo you know how we can do this? Many thanks by advance Google Security Operations Fri, 28 Aug 2026 10:25:34 +0200 https://security.googlecloudcommunity.com/google-threat-intelligence-3/false-positive-in-iplist-known-malicious-ips-shopify-production-ip-removed-by-moderator-and-no-documented-way-to-dispute-it-8147 SUMMARY The address 23.227.38.74 is present in the Google Threat Intelligence curated list`iplist-known-malicious-ips`. IP: 23.227.38.74PTR: shops.myshopify.comWhois: Shopify, Inc. — NetName SHOPIFY-NET, CIDR 23.227.32.0/19 This is core Shopify storefront / webhook infrastructure — the address that Shopifystores resolve to — not a compromised host. Because Google's own recommended predefined firewall rules for network firewallpolicies include an egress deny rule with`destThreatIntelligences = iplist-known-malicious-ips`, any customer who follows thatrecommendation silently loses all outbound connectivity to Shopify. There is nowarning, no changelog and no alert: traffic simply starts being dropped. OBSERVED BEHAVIOUR Egress to 23.227.38.74:443 denied by the predefined threat-intelligence egress rule. In one project, denies ran continuously for about five days before we noticed: First DENY: 2026-08-19T21:34:45ZLast DENY: 2026-08-24T22:38:44ZTotal: 11,998 denied connections Date (UTC) Denied connections2026-08-19 4182026-08-20 5,5942026-08-21 3,4212026-08-22 5712026-08-23 5732026-08-24 1,421 This broke a live Shopify <-> ERP integration for the duration. The listing is a clear statistical outlier. Over that window, in that project: 23.227.38.74 11,998 denies (93.7% of all egress deniesproduced by that rule)next most-hit destination 111 denies No other address inside SHOPIFY-NET (23.227.32.0/19) was ever denied, which suggestsa single bad entry in the feed rather than a range-level classification. EXPECTED BEHAVIOUR 23.227.38.74 is not classified as a known malicious IP, and egress to Shopify is notdenied by the predefined threat-intelligence rules.HOW TO CONFIRM In any project using the predefined threat-intelligence rules, in Cloud Logging: logName="projects/PROJECT_ID/logs/compute.googleapis.com%2Ffirewall"jsonPayload.rule_details.priority=PRIORITY_OF_THREAT_INTEL_EGRESS_DENY_RULEjsonPayload.connection.dest_ip="23.227.38.74" REQUESTS 1. Remove 23.227.38.74 from `iplist-known-malicious-ips`, and — if it can be shared —what caused shops.myshopify.com to be added in the first place? 2. Change notification. Is there any mechanism to be notified when a curated GoogleThreat Intelligence feed changes? A change made on Google's side broke productiontraffic with no prior signal. This failure mode is available to every customer whofollows the recommended predefined rules, which makes it a systemic issue ratherthan a one-off. 3. Feed introspection. Is there any read-only way to query the current contents of afeed, even for audit purposes only? Without it, customers cannot tell whether afalse positive has been corrected, and a local workaround has to stay in placeindefinitely — silently re-opening the exposure the rule was meant to close. 4. Exclusion mechanism (feature request). The only exception mechanism the Cloud NGFWdocumentation offers today is a "selective allow" rule at a higher precedence thanthe threat-intelligence deny rule. That is a workaround, not an exclusion: itpermanently removes the destination from threat-intelligence evaluation, includingfor every future threat the feed might legitimately catch on that address. Cloud Armor exposes a real exclusion list for threat-intelligence lists. Pleaseconsider the equivalent for Cloud NGFW. 5. Dispute process. We could not find one. Neither the Cloud NGFW threat intelligencedocumentation nor the Cloud Armor equivalent states where the data in these feedscomes from, nor describes any procedure for reporting a misclassification orrequesting review of an entry. The Cloud NGFW support page does not mention IssueTracker at all; the only channel it names is the documentation feedback form. That is why this report is being filed here rather than through a proper channel.Please point us at the right one — and, if there is none, please consider that afinding in its own right: a curated feed that customers are told to enforce inproduction, with no published provenance and no way to contest an entry, isdifficult to operate safely. WORKAROUND CURRENTLY IN PLACE A selective allow rule for that destination, evaluated before the threat-intelligencedeny rule — the mechanism the documentation recommends. Traffic has been normal since2026-08-24T22:46Z. The three requests above compound into one systemic problem, which is the real reasonfor filing this: - The feed changed and broke production traffic with no signal (request 2).- The feed cannot be inspected, so there is no way to learn that the false positivehas been corrected (request 3).- The only documented remedy is a permanent allow rule (request 4). Taken together, the recommended response to a false positive is to permanently disablethreat-intelligence enforcement for the affected destination, with no signal that wouldever justify re-enabling it. Every false positive in a curated feed therefore leaves apermanent hole in the security posture of every customer who hits it. That outcomeseems contrary to the intent of the predefined rules.  Google Threat Intelligence Thu, 27 Aug 2026 18:58:45 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/how-to-add-2-different-conditions-in-rule-8145 Hi I want this rule to work in such a way that if the e1 or e2 condition is true then we should get an alert but if e2 and e3 is true then we should not get and alert. i have tried multiple ways but somehow it is not working. rule RULE_PROD_USER_INFORMATION_REGISTRY_ACCESS { meta:author = "Fortrea Security Engineering (abcd)"description = "Detect access to registry keys containing user/system information while suppressing expected Dell activity"severity = "LOW"priority = "LOW"mitre_tactic = "TA0005"mitre_technique = "T1112"case_type = "Anomaly detection" events:// Original detection event$e1.principal.hostname = $host($e1.target.registry.registry_key = /Control Panel\\International\\Geo/ or$e1.principal.process.command_line = /Control Panel\\International\\Geo/ or$e1.target.registry.registry_key = /SYSTEM\\CurrentControlSet\\Services\\Disk\\Enum/)// MDE BIOS registry query$e2.principal.hostname = $host$e2.principal.log_type = "MICROSOFT_DEFENDER_FOR_ENDPOINT"$e2.principal.process.command_line =/HARDWARE\\DESCRIPTION\\System/not ($e1.principal.process.parent_process.file.names = "Dell.TechHub.Diagnostics.SubAgent.exe" nocase or$e1.principal.process.parent_process.file.names = "Dell.TechHub.Instrumentation.SubAgent.exe" nocase) // Dell Driver launch$e3.principal.hostname = $host$e3.metadata.event_type = "PROCESS_LAUNCH"$e3.principal.process.command_line = /Dell\\drivers/ match:$host over 10m outcome:$source_ip = array_distinct($e1.principal.ip)$vendor_name = array_distinct($e1.metadata.vendor_name)$product_name = array_distinct($e1.metadata.product_name)$principal_process_command_line =array_distinct($e1.principal.process.command_line) condition: $e1 or $e2 or (!$e2 and !$e3)  Google Security Operations Wed, 26 Aug 2026 19:01:33 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/secops-siemposium-2026-a-google-secops-focused-conference-oct-5-8-in-san-diego-7978 Hey Community! You may have seen a new event added to our incredible list of upcoming enablement opportunities.One I would like to highlight is something built specifically for you. SecOps SIEMposium 2026 is coming to San Diego this October. There have been a lot of requests for more hands-on training, more focus on SecOps best practices, more help adopting new features as they ship. This inspired SIEMposium! It's a first-of-its-kind technical conference and training week focused entirely on Google SecOps.The formatThis is a three days hands-on Master Classes taught by experienced SecOps instructors, followed by a full conference day of keynotes and lessons learned from the trenches. No expo hall, no booth crawl, no vendor bingo.Parse & Recreation (Oct 5) — Hands-on learning and practice across all aspects of parsing: extensions, custom parsers, UDM, Entity Data Model & Enrichment, JavaScript parsing, and more.YARApalooza (Oct 6) — Build up from basic to advanced YARA-L and SQL constructs for hunting, search, detections, and dashboards.SOARcery (Oct 7) — Scale playbooks, response, and SOAR integrations. Hook to MCPs and build the foundation for agentic capabilities.The Conference Day (Oct — Keynotes and lessons learned from Google SecOps and industry leaders .Battle on the Bay (Evening of Oct — A live threat-hunting CTF against an Armadin-powered advanced AI attacker, aboard a dinner cruise on Mission Bay. While the Master Classes are designed to provide beginner-friendly as well as advanced paths, they are technical in nature and will require a laptop and willingness to take on a challenge. You can join for any of the days, depending on your interest in topics.Featured speakers include notable authors from this community: John Stoner, Mike Wilusz, Travis Lanham, Anton Chuvakin, and Chris Martin — with more to be announced.Details Mon, Oct 5, 8:00 AM – Thu, Oct 8, 9:30 PM (PDT) Bahia Resort Hotel, Mission Bay, San Diego, CA Register & full agenda: siemposium.com Trainings are ~50% bookedStay in the loopSpeaker announcements, agenda drops, and event updates go out through Citreno — follow along on LinkedIn: https://www.linkedin.com/company/citreno/Whether you're new to Google SecOps or scaling it across a mature SOC, come spend a week in San Diego with hands-on training and the people building the platform. Travel JustificationWe know engineers and practitioners often struggle with justifying travel and other expenses and Citreno built things in mind to help. The event contains advanced hands-on training that will immediately improve your productivity with SecOps day to day. The training is eligible for CPA credits and we provide attendance documentation you can submit to your certification body for CPE credits(7-8 Credits per day). We’ve also provided for affordable room blocks in the venue including GSA rates and are happy to assist with any requests to help justify travel and cost.  It also doesn’t hurt that San Diego is beautiful in October. If you have any questions or require any support please feel free to comment in this post or contact siemposium@citreno.com.  Google Security Operations Wed, 26 Aug 2026 16:55:11 +0200 https://security.googlecloudcommunity.com/cloud-security-foundation-7/webinar-alert-on-09-09-how-to-navigate-the-post-quantum-cryptography-shift-8149 Hi all, While the post-quantum transition might feel like a future-state milestone, the timeline has already shifted. Post-quantum cryptography (PQC) is no longer a strategic checkbox—with the signing of Executive Order 14412 and CISA's standardization of the Cryptographic Bill of Materials (CBOM), it is now a strict regulatory and procurement requirement. I am hosting a discussion called "The clock is ticking: How to navigate the Post-Quantum Cryptography shift" featuring Google security experts @Nelly Porter and @Erlander Lo (Elo). We will move past academic theory and share hard-won, real-world deployment lessons from global cloud infrastructure, Android, and Chrome. We'll cover:Protecting Data in Transit Mitigating SNDL (Secure Now, Decrypt Later) Attacks Securing Long-Lived Digital Signatures Google Cloud’s PQC roadmap Deployment Lessons & Live Demo: Practical insights from Google's global systems, plus a live demo to secure your organization today.We are keen to share what we're learning about PQC and hear your thoughts. Session Details:When: September 9, 2026, 8-9 am PT Registration/Replay: Register HereWhat are the biggest challenges your organization is facing when it comes to PQC migration and adoption? Hope to see you there. Cheers,​@DataSecMuse Rashmi SahniSenior Product Marketing ManagerGoogle Cloud Security  Cloud Security Foundation Wed, 26 Aug 2026 00:29:52 +0200 https://security.googlecloudcommunity.com/google-security-operations-95/google-secops-parser-extension-how-to-reference-extracted-fields-raw-log-from-base-parser-8061 Hi everyone,I'm working on a Google SecOps Parser Extension for Terraform Enterprise logs.The base parser is successfully extracting data into UDM. For example: extracted.fieldss"_raw.component"] = "nginx" extracted.fieldsd"_raw.log"] =127.0.0.6 - - -07/Aug/2026:18:12:19 +0000] "GET /api/v2/organizations/uwm/workspaces HTTP/1.1" 304 0 "https://terraform.uwm.com/app/uwm/workspaces" "Mozilla/5.0 ..."Show more linesRaw event:{"_raw": {"component": "nginx","log": "127.0.0.6 - - -07/Aug/2026:18:12:19 +0000] \"GET /api/v2/organizations/uwm/workspaces HTTP/1.1\" 304 0 ..."},"cribl_group": "AzureEastUS2-Upper"}My goal is to create a Parser Extension that parses the nginx access log and maps fields such as:client_iphttp_methodurl_pathstatus_codeuser_agent However, when I try to reference:c_raw]alog]o_raw]acomponent]or%{_raw.log} I get errors such as: "_raw.log" not found in state data Questions:What is the correct way to reference fields that are already extracted by the base parser, such as:extracted.fieldsf"_raw.component"]extracted.fieldsf"_raw.log"]  Are extracted.fields accessible within a Parser Extension? Is there a recommended approach for parsing the nginx log stored in _raw.log and mapping the results into UDM fields? Any examples or documentation would be greatly appreciated.Thanks! Google Security Operations Tue, 25 Aug 2026 23:36:08 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/soar-mssp-ticket-escalation-8139 Hi all, I wanted to understand how the the winder SecOps community has managed ticket management in a MSSP context. As an example, as a MSSP, and if there is a need to escalate a ticket to a customer, what method have you found worked the best?My initial thoughts would be the have a manually initiated playbook by the analyst summarise and escalate the alert as a servicenow ticket to the client, as well as sending a teams notification. A flow might look something like this:Triage & Investigation → Escalation Required (Additional client information needed/approval for action) →  Playbook to mark case as paused and a notification is sent to client which creates a SNOW/Cherwell ticket → Client updates ticket → case SLA resets and internal analyst is notified via assignment of internal SNOW ticket. Obviously the above would have several integration points, but that is my high level thinking. What has worked for others would be greatly appreciated.  Google Security Operations Tue, 25 Aug 2026 21:14:19 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/need-help-with-yara-l-rule-8142 I am attaching a rule below. I need to have an alert when e1 is true or e2 is true but I don't want and alert when we have a combination of e2 and e3 is true. How can i mention then in the rule. rule RULE_PROD_USER_INFORMATION_REGISTRY_ACCESS { meta:author = "abcd"description = "Detect access to registry keys containing user/system information while suppressing expected Dell activity"severity = "LOW"priority = "LOW"mitre_tactic = "TA0005"mitre_technique = "T1112"case_type = "Anomaly detection" events:// Original detection event$e1.principal.hostname = $host($e1.target.registry.registry_key = /Control Panel\\International\\Geo/ or$e1.principal.process.command_line = /Control Panel\\International\\Geo/ or$e1.target.registry.registry_key = /SYSTEM\\CurrentControlSet\\Services\\Disk\\Enum/)not ($e1.principal.process.parent_process.file.names = "Dell.TechHub.Diagnostics.SubAgent.exe" nocase or$e1.principal.process.parent_process.file.names = "Dell.TechHub.Instrumentation.SubAgent.exe" nocase)// MDE BIOS registry query$e2.principal.hostname = $host$e2.principal.log_type = "MICROSOFT_DEFENDER_FOR_ENDPOINT"$e2.principal.process.command_line =/HARDWARE\\DESCRIPTION\\System/ // Dell Driver launch$e3.principal.hostname = $host$e3.metadata.event_type = "PROCESS_LAUNCH"$e3.principal.process.command_line = /Dell\\drivers/ match:$host over 10m outcome:$source_ip = array_distinct($e1.principal.ip)$vendor_name = array_distinct($e1.metadata.vendor_name)$product_name = array_distinct($e1.metadata.product_name)$principal_process_command_line =array_distinct($e1.principal.process.command_line) condition: // Fire on original detection$e1// Suppress if Dell activity is observedand not ($e2 and $e3)} Google Security Operations Tue, 25 Aug 2026 18:05:49 +0200 https://security.googlecloudcommunity.com/community-blog-42/enriched-url-reports-powered-by-full-browser-execution-8146 Author: Jose Luis Sanchez Martinez,  Senior Security Engineer Introduction In today's fast-moving cybersecurity landscape, security operations are transitioning from manual, repetitive triage to intelligent, proactive defense. At the core of this transformation are Agentic workflows, which shift AI from a simple conversational assistant into an active, autonomous collaborator.To power this new paradigm, Agentic threat intelligence in Google Threat Intelligence officially launched in General Availability (GA) in January this year. Agentic threat intelligence provides a multi-language conversational interface that unlocks Google's vast threat intelligence, allowing security analysts to chat with specialized AI agents to accelerate security investigations and obtain immediate threat analysis.At the same time, traditional URL analysis has been redefined by the VirusTotal launch of URL Scanning 2.0, an update that significantly expands URL analysis capabilities by introducing automated visits with a full browser instance and deeper historical visibility. Instead of relying on static reputation scores alone, URL Scanning 2.0 enriches reports with "under-the-hood" headless browser telemetry, including the DOM, full-page screenshots, web technologies, and network request logs. Crucially, it introduces historical analysis pivoting, giving analysts the ability to pivot from a current report to a historical analysis of a URL to track how a page has changed over time.This blog post explores the exciting integration of these two breakthrough capabilities. By marrying the reasoning power of Agentic threat intelligence with the rich headless browser telemetry of URL Scanning 2.0, we have unlocked a host of new features designed to supercharge website triage and anti-phishing operations. From generating intuitive AI page summaries similar to urlscan.io to executing timeline analyses that review discrepancies between screenshots, DOM, and domains over time, Agentic threat intelligence is redefining how we investigate the web. URL Scanning 2.0 To successfully defend against modern, highly adaptive web threats, threat analysts must move beyond basic, binary reputation scores. With the debut of URL Scanning 2.0, Google Threat Intelligence introduces robust headless browser integration that captures how a page behaves dynamically in a clean sandbox environment. Every scan now generates rich, granular telemetry that provides a blueprint of the target page's execution: Headless Browser Data: Full-page visual screenshots, full DOM (Document Object Model) trees, and web technologies (e.g., Cloudflare, PHP, HTTP/3). Page and Network Statistics: Highly detailed counters of individual network requests, encrypted HTTPS transactions, unique contacted domains/subdomains, and serving IP address mappings with geographic tracking. Anti-Phishing Fingerprints: Automatic identification of brands, cloned-website tags, password input fields, tracker IDs, and favicon dhashes. Historical Pivoting: A timeline containing historical analyses of a URL with its corresponding risk score, allowing analysts to track exactly how its metadata and content have shifted over time.   Here is a practical breakdown of what analysts can expect: Public Access (Free for VirusTotal Users) The core enhancements of the URL Scanning 2.0 engine are available to everyone, but free users are restricted to viewing data exclusively from the most recent analysis. For this latest scan, analysts can access rich telemetry generated by headless browser execution. This includes visual screenshots of the rendered page, full DOM captures, extracted JavaScript globals, console messages, and a list of all loaded network resources and outgoing links.VirusTotal Premium Customers For paid VirusTotal customers, the platform unlocks deeper retrospective capabilities. Instead of just seeing the latest scan, analysts have the ability to pivot to and review the full historical analyses of a URL as it was observed at specific points in time in the past. Furthermore, premium access unlocks advanced infrastructure relationships, allowing users to pivot on contacted domains, contacted IPs, and downloaded files associated with the URL.Google Threat Intelligence Customers The highest tier of analysis adds AI-driven context and actionability. Users with access to Google Threat Intelligence unlock Automatic Brand Identification, which visually detects spoofed brands, alongside the proprietary Google Threat Intelligence Assessment. Moreover, Google Threat Intelligence clients can leverage Agentic threat intelligence to directly interact with all this data. Analysts can use natural language prompts to pivot on DOM elements, historical resolutions, or specific JavaScript variables. It is important to note that these Agentic capabilities are exclusively available to Google Threat Intelligence customers and are not included in standard VirusTotal subscriptions.Investigating a phishing campaign  To showcase some of the new capabilities we have integrated into URL Scanning 2.0, we will walk through examples of common phishing campaigns. Rather than just relying on static reports, these new features allow analysts to see the rendered page, trace its execution, and track its evolution over time.In our first example, we analyzed an interesting campaign targeting the financial industry. Let's look at how URL Scanning 2.0 works.Initially, when an analyst navigates to the mentioned URL to view the report generated by Google Threat Intelligence, they would see something similar to the following with the new URL Scanning features: URL Report for the phishing site At the top of the interface, we can see that the URL has been scanned three times. This means there are three distinct reports for the same URL, each potentially containing different information that could be highly useful for an analyst. In the top right corner, we can view these past analyses by clicking on "History".This is where the new historical analysis pivoting comes into play: it allows analysts to travel back through a URL's timeline with point-in-time snapshots. History for the URL analyzed By clicking on "History", we can view all the historical analyses for that URL, including response codes, detections, screenshots, and other metadata. You can also apply filters to narrow down the timeline and view only the historical records you are interested in, based on specific response codes, URL actions, and other criteria.In this case, if we click on the initial historical analysis performed on July 6, 2026 (as shown in the screenshot above), we can examine its specific information across the "Summary", "Details", and "Detection" tabs. A key feature of URL Scanning 2.0 is that the information within these report tabs will dynamically re-render to match the exact historical state of the snapshot you select. Different Page Stats for each history selected History which contains screenshot related to the phishing As observed in the history timeline, after clicking on this specific analysis included a live screenshot and other relevant metadata, indicating the scan occurred while the website was fully operational and actively distributed. The previous screenshot gives us a clear view of how the phishing page was visually structured.Furthermore, diving into the "Details" tab reveals other interesting technical artifacts from the campaign. These details are incredibly useful for pivoting and identifying new malicious URLs that share similar characteristics. More details extracted for the first analysis Among the wealth of information generated by URL Scanning 2.0, analysts will find HTTP transactions, detected JavaScript variables, console messages, external outbound links, and other critical metadata. These key technical markers serve as pivotable and searchable attributes, allowing teams to conduct advanced footprint hunting and instantly find other malicious URLs exhibiting the exact same technical fingerprint. Details obtained by URL Scanning 2.0 Furthermore, every snapshot taken during each analysis provides the complete Document Object Model (DOM) tree captured by the full browser instances. It allows you to inspect the exact structure of the page as it was dynamically rendered to the victim, exposing elements that static scans might miss. As can be seen in the following image, having direct access to this point-in-time DOM data empowers analysts to dig deep into the page's architecture. DOM content obtained by URL Scanning 2.0 Agentic + URL Scanning 2.0 Hunting phishing sites All of this new URL Scanning 2.0 functionality has been integrated with our Agentic system. Analysts can now have natural language conversations to gain deeper insights from the data obtained via URL Scanning 2.0, perform seamless pivoting, and conduct advanced threat hunting.Using the previous phishing example, we conducted an exercise to identify other potential URLs that might belong to the same campaign. Through this, we discovered that the campaign was not solely focused on one financial institution, but also targeted cryptocurrency exchange phishing websites.Our first action was to ask the agent to evaluate the history and activity window of this link, using the following prompt: I'm investigating a phishing campaign targeting <a major financial institution>. I've initially identified this URL. Could you tell me what information it has presented historically and when it was active?http://REDACTED.com/Agentic began working immediately, executing multiple searches for indicators of compromise (IOCs) and evaluating telemetry within the VirusTotal database. In a short amount of time, it delivered a comprehensive threat analysis detailing the financial institution phishing campaign. Initial findings: Activity Timeline: Agentic discovered that the domain was registered and first submitted to VirusTotal on July 5, 2026. Historical Presentation and Content: When the site was active, it presented a spoofed login portal designed specifically to harvest user credentials. Discovery of External Dependencies: One of the most revealing technical details was that the page relied on static assets (such as images and backgrounds) hosted on a third-party domain: jiaoyisuo.thai2570t.]com.   Part of the Agentic response Agentic did not limit itself to delivering a static analysis; instead, it performed automatic pivoting based on the response hashes. By pivoting on the response body hash and the Favicon dhash, Agentic managed to uncover a much broader and highly correlated phishing infrastructure.In this way, new related malicious domains came to light: Domains such as REDACTED1.eut.]cc used the exact same HTML template as the original target site. Domains such as REDACTED5t.]net shared an identical Favicon graphic to that of the targeted bank.  Part of the Agentic response with a graph to explain better the relationships Armed with the knowledge that the attackers were loading external resources from the domain jiaoyisuo.thai2570r.]com, we knew we had found a thread to pull. We wanted Agentic to do the heavy lifting of threat hunting and correlation, so our next question was this: Based on the metadata of the URL, outgoing links and other information related to the initial URL, can you do pivoting, run queries and provide queries to identify other potential URLs related?Once you have results, explain them. Agentic accepted the challenge and structured its hunt into two primary pivoting strategies, explaining its findings to us step by step. Strategy 1: Outbound Link and Content-Based Search Agentic deduced that if the initial page was loading images from jiaoyisuo.thai2570o.]com, it was highly likely that other fraudulent pages built with the same phishing kit were doing exactly the same. Threat actors frequently reuse infrastructure and web assets to deploy campaigns faster, inadvertently creating a traceable fingerprint across the internet. To test this hypothesis, the agent executed the following advanced query in VirusTotal: entity:url (outgoing_link:jiaoyisuo.thai2570.com OR content:jiaoyisuo.thai2570.com)The results were revealing and demonstrated that we were not just looking at a single isolated attack, but rather a large-scale, multi-brand operation: Banking Cluster: Agentic found an identical replica of the phishing campaign targeting the bank, but hosted on alternative top-level domains such as REDACTED1.eut.]cc. Cryptocurrency Cluster (Coinxsg): The cybercriminals behind thai2570g.]com were not limited to banking institutions; they also operated fake cryptocurrency exchange portals, such as coinxsge.]biz. Cryptocurrency Cluster (Coinbase): Additionally, it discovered typosquatting domains (like max-coinbsey.]com) designed to compromise Coinbase users.  Queries ran by Agentic Strategy 2: Pivoting on the Hosting Domain To better understand the infrastructure behind the delivery of these assets, Agentic performed a direct search of the domain entity:domain "thai2570.com"This analysis broke down a highly segmented subdomain tree, where each one fulfilled a specific purpose within the phishing machinery: jiaoyisuo.thai2570t.]com: This was used strictly to host images and layouts for the active phishing sites (interestingly, Agentic informed us that "jiaoyisuo" translates to "exchange" in Mandarin). pay.thai2570t.]com: Dedicated to managing transactional or payment capture pages. bot.thai2570l.]com and telemonitor.thai2570o.]com: These subdomains strongly indicated the use of administrative backend components, possibly acting as Telegram bot gateways to exfiltrate the stolen credentials. dzadmin.thai2570t.]com: Operated as the backend for the phishing control panel.  Queries ran by AgenticDevil NFC with Agentic Following our initial successes, we turned our attention to a completely different type of threat: mobile financial fraud. Specifically, we focused on a banking trojan from the NGate family—often referred to as "Devil NFC"—which bypasses traditional credential theft by physically relaying a victim's contactless card data to an attacker in real time. We had an initial, highly suspicious URL (hxxps://reventandocajerosnfch.]club/) and we needed to understand its purpose and history. Content related to the reventandocajerosnfco.]club domain Investigate URL https://reventandocajerosnfc.club/ which I suspect is related to malware. Tell me if it's something related to malware, if positive:Report up to when this site was activeAgentic quickly correlated the data and provided a comprehensive threat summary, confirming our worst suspicions. Right away, the agent analyzed the domain name itself, noting that it translates from Spanish as "popping/exploding NFC ATMs", a blatant indicator of financial fraud.Initial findings by Agentic were: Malicious Classification: Agentic confirmed the URL was classified as malicious with medium severity, as 17 security vendors flagged the indicator. Activity Timeline: Agentic analyzed the historical scanning timeline and concluded that the site was active up until approximately April 27, 2026. By May 19, 2026, the backend infrastructure was disabled or terminated, returning a Cloudflare Connection Timed Out error. Key Endpoints: It also discovered a secondary backend configuration file, api_config.php, likely used to facilitate data transmission from compromised apps to the control panel.  Analysis history of the requested URL Pivoting: Mapping the "Devil NFC" Infrastructure To transform this single data point into a broader threat landscape view, we needed to pivot. We asked Agentic to dig deeper into the historical analysis patterns: Please analyze the details of different analysis history to get interesting patterns that can be used to run new queries and identify potential URLs related to this campaign.Agentic's pivoting capabilities shined here. By examining the HTML structure, JavaScript variables, and visual assets of the inactive site, it successfully mapped out a much larger infrastructure known as Devil NFC.Discoveries from the Pivot: Brand Identification: When active, the site displayed the brand name "Devil NFC" with the custom HTML title: Devil NFC - e CLASSIFIED SYSTEM ]. Code-Level Tracking: Agentic identified interesting JavaScript variables, like drawMatrix, indicative of a retro matrix hacker aesthetic panel. Uncovering Sister Nodes: By using these unique artifacts as search modifiers, Agentic discovered new, related infrastructure. This included domains like spicynagetsi.]shop (an active threat host with 22 malicious detections) and nfkrackingr.]com, which showed a clear thematic correlation to NFC/RFID cracking.  New URLs discovered by Agentic  With the primary C2 domains mapped out, we wanted to move beyond just top-level hostnames and understand the structural properties of the attacker's infrastructure. We needed to know exactly how the malware was communicating with the panel.To achieve this, we tasked Agentic with a multi-step analysis focused on URL paths and structural overlaps. We submitted the following prompt: Please perform the following tasks based on the discovered domains:1. Analyze their URLs and structural properties.2. Extract overlapping technical patterns (e.g., specific file paths, parameters, or headers).3. Write a Livehunt rule based on these patterns to automatically detect emerging infrastructure tied to this campaign.The results from this analysis were interesting. Rather than just returning basic network metadata, Agentic successfully extracted the specific file paths used by the operators. Most notably, it discovered a secondary related endpoint at /api_config.php. The system identified that this specific path represented a backend configuration file, which likely served as the main channel to facilitate data transmission from the compromised NFC apps back to the control panel.By pinpointing these overlapping paths and technical patterns, Agentic handed us exactly what we needed to draft a robust Livehunt rule, allowing us to pivot from analysis to proactive detection of any new infrastructure the "Devil NFC" operators might spin up in the future. Paths identified by Agentic related to this campaign Mapping the attacker's infrastructure and understanding their backend paths gave us a significant advantage, but we needed to translate these findings into actionable, proactive defense. To catch the "Devil NFC" operators the moment they attempt to deploy new infrastructure, we submitted one final prompt to Agentic: With this information, I would like to create a high fidelity YARA rule to monitor new URLs uploaded to virustotal based on the API paths discoveredAgentic instantly generated a comprehensive rule named Devil_NFC_Path_Only_URL. What makes this rule particularly powerful is that Agentic didn't just look for a single string; it designed a multi-branch boolean condition that targets three different layers of the campaign's structural footprint. YARA Rule created by Agentic It is also worth noting that Agentic allows the creation of YARA rules using the vt module, as well as generating rules based on network locations (netloc). This enables advanced detections leveraging both rich telemetry and network infrastructure. Conclusion: The Future of URL Investigations The integration of URL Scanning 2.0 and Google Threat Intelligence Agentic represents a paradigm shift in how security analysts investigate web-based threats. As demonstrated by our deep dives into the banking phishing cluster and the Devil NFC malware campaign, investigations are no longer limited to static verdicts.By surfacing powerful metadata directly inside the workflow—such as historical DOM captures, live screenshots, and pivotable technical identifiers—analysts can now turn a single indicator into a comprehensive infrastructure map in a matter of minutes.Log in to VirusTotal to explore the new URL Scanning 2.0 features today. If you'd like to see how Google Threat Intelligence and Agentic can automate your complex investigations, contact our team to learn more. Already a Google Threat Intelligence customer? Try Agentic now and let us know your feedback!   Community Blog Tue, 25 Aug 2026 17:37:33 +0200 https://security.googlecloudcommunity.com/tuesday-s-tip-of-the-week-93/tuesday-s-tip-of-the-week-fast-rules-not-slow-rules-optimizing-yara-l-for-scale-8144 August 25, 2026  Why Performance Matters Well-optimized YARA-L rules evaluate efficiently at scale and keep detections current with your data.Optimization Principles Filter early. Place log_type and event_type filters first to eliminate most events before aggregation.  Size your match window correctly. If 1h captures the behavior, do not use 24h. Avoid unbounded aggregations. Filter to a specific log type and event type before running count_distinct. Use data tables over inline lists. Table lookups are faster and easier to maintain.Before: SLOWrule slow_example { meta: severity = "HIGH" events: $e.principal.user.email_addresses = $user $e.target.resource.name = $resource match: $user over 24h outcome: $resource_count = count_distinct($resource) condition: $e and $resource_count >= 100} After: FASTrule fast_example { meta: severity = "HIGH" events: $e.metadata.log_type = "GCP_CLOUDAUDIT" $e.metadata.event_type = "USER_RESOURCE_ACCESS" $e.principal.user.email_addresses = $user $e.target.resource.name = $resource not $user in %system_accounts.email match: $user over 1h outcome: $resource_count = count_distinct($resource) condition: $e and $resource_count >= 50}(this rule will not compile without the data table system_accounts and column called email)  The fast version filters by log type and event type, excludes noise via data table, and cuts the window from 24h to 1h.   Checklist: Does every rule start with event_type filters? log_type  is helpful and will speed up the process but we may want to aggregate across event_type across log_type, so this may not be an option.  Is the match window the shortest that captures the behavior? Are inline lists replaced with data tables? Here’s a table of some other areas to think about optimization:   Tuesday's Tip of the Week Tue, 25 Aug 2026 13:31:30 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/new-stats-hunting-skill-8130 The SecOps platform has had a lot more mathematical analytics capabilities built into it but working with it has its own learning curve, I’ve found.  To help with that, I created a new “Stats Hunter” skill:https://github.com/GooGKush/secops-statistical-hunter I’ve tried to make the skill work with someone to find the right kind of search, guiding the users to methodologies and choices before generating a multi-stage YARA-L stats search.  It also tried to give you guidance on noise thresholds.   For example: > Using the stats hunter skill, can you help me identify low prevalence domains over the last month?▸ Thought for 3s, 906 tokens Analyzing Query Approaches To identify low prevalence domains over the last month using the SecOps Statistical Hunter (secops-statistical-hunter) methodology, we model this threat hunting workflow around Fleet-Wide Entity Prevalence (P ≤ 2 internal endpoints) and Query Volume Dispersion over raw telemetry (UDM_EVENTS). ────── ### 1. Threat Archetype & Statistical Model • Threat Archetype: LOW_PREVALENCE_INFRASTRUCTURE / C2_STAGING_DETECTION • Telemetry Source: UDM_EVENTS (NETWORK_DNS) (with optional pivot to NETWORK_HTTP / NETWORK_CONNECTION) • Mathematical Primitive: Enterprise-wide unique host count P = count_distinct (principal.asset.ip) aggregated per domain over a rolling 30-day window. • Hypothesis: Legitimate services (CDNs, OS update servers, major SaaS tools) exhibit high enterprise prevalence (P gg 10 hosts). In contrast, targeted adversary infrastructure (stealthy C2 callbacks, staged payloads, spear-phishing destinations) typically resolves on only 1–2 endpoints. ────── ### 2. Semantic Sensitivity Tiers Before running across 30 days of telemetry, select a sensitivity boundary that balances signal coverage against analyst triage capacity: Tier │ Host Prevalence (P) │ Query Volume Floor / Ceiling │ Physical Interpretation & False Positive Profile ────────────────────────┼─────────────────────┼──────────────────────────────┼─────────────────────────────────────────────────────────────────────────────────────────────────────── CONSERVATIVE │ P = 1 host │ 10 ≤ Queries ≤ 500 │ Single-Host Persistent Beaconing: Surfaces domains queried repeatedly by exactly one host. Filters │ │ │ out ephemeral one-shot lookups and widespread SaaS. BALANCED (Recommended) │ P ≤ 2 hosts │ 3 ≤ Queries ≤ 500 │ Targeted Infrastructure & Initial Access: Captures staging and C2 callbacks across isolated hosts │ │ │ while filtering transient single-packet noise. AGGRESSIVE │ P ≤ 5 hosts │ Queries ≥ 1 │ Broad Outlier Sweep: Surfaces every low-volume domain across the fleet. High analyst triage volume; │ │ │ includes typos and ephemeral CDN nodes. NOISE CLIFF │ P > 10 hosts │ No volume floor │ Normal enterprise web traffic. Do not hunt at this threshold. ────── Then it gave me some options - both multi-stage and “classic” YARA-L and asked what I wanted to do next.  I went with a test probe to help it calibrateThe Skill is designed to help filter out noise and you see it doing that and clustering types of findings: For the output I tried to come up with summary views by default: Whereas if you’re using an MCP client that supports Javascript graphical renderings, it can generate charts like it did here for a different query:  I’ve had some interesting results with broad questions like “Can you help me identify shadow AI in my environment leveraging my EDR and Network logs?”Please give it a try and let me know how it works out? Google Security Operations Mon, 24 Aug 2026 19:03:40 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/defender-sync-alerts-job-8123 Can this be updated https://docs.cloud.google.com/chronicle/docs/soar/marketplace-integrations/microsoft-365-defender#sync-alertsThis job is failing as it is not taking into account alerts from insider risk policies for example or dlpThey are prefixed ir or dlp etcadditional.fieldss"provider_alert_id"]:"86954c42-15b0-4976-8fbf-9fcc9f52bec8" is actually ir86954c42-15b0-4976-8fbf-9fcc9f52bec8c2026-08-18,14:36:50,000 INFO] Found 0 case ids to sync: :]Or am I  missing something?Thanks in advance Google Security Operations Mon, 24 Aug 2026 10:06:15 +0200 https://security.googlecloudcommunity.com/what-s-new-in-secops-91/what-s-new-in-google-secops-2026-08-24-8140 What’s New in Google SecOps for the interval August 17th through August 24th 2026. What’s New in Google SecOps, August 23rd 2026Highlights This week there was simply too much content for me to read and watch all of it before the F1 started The SecOps Detection Engineering Agent (DEA) is now in private preview 🪵 Bindplane have released beneficial updates for Google SecOps, like CEF parsing and SecOps pipeline templates Tons of great SecOps Community Content such as How to investigate SecOps SIEM Audit Logs, Exploring Agent Graphs for SecOps AI Runbooks, as well as several webinar recordings  Product Updates & New Features Google SecOps  SecOps Release Notes from Google Cloud Docs Google SecOps has introduced a new public preview feature allowing more precise relative time filtering with ‘Past’, ‘Previous’, and ‘Current’ operators, eliminating ambiguity in data range calculations. aRead More] Google Cloud Chronicle’s Investigation Management now includes a new ‘Side-by-side view’ feature, currently in public preview, on the Alerts & Detections tab to enhance the inspection of alert metadata. oRead More] This is a good addition to the Case 2 preview which provides parity to that of Case 1, i.e., no additional mouse clicks and tabs needed anymore. New Vertical Alerts & Detections view in Case 2  Google SecOps has launched the AI-powered Detection Engineering Agent in public preview, which helps evaluate threat coverage, extract intelligence, and automatically draft YARA-L detection rules to strengthen security posture. tRead More] The latest Google SecOps Agent, the Detection Engineering Agent (DEA) is in private preview. I find this is more a Detection Coverage Agent at present, but I plan to write up a separate blog on this in the near future. The DEA Workflow Going with the Flow(s): Distinct Clusters Target Individuals of Interest to Russia from Google Cloud Blog Google Threat Intelligence Group is tracking three distinct Russian cyber espionage clusters that abuse legitimate authentication flows to target individuals in academia, aerospace, defense, and government sectors. dRead More] Staying Ahead of Adversarial AI Through Agentic Source Code Review from Google Cloud Blog The article discusses the application of agentic source code review as a strategy to defend against and stay ahead of adversarial AI threats. fRead More] BindPlane August 2026 at Bindplane: Full-Pipeline Blueprints and Scoped API keys from Bindplane.com Bindplane has released Full-Pipeline Blueprints, allowing for complete end-to-end data pipeline setup, and introduced Scoped API Keys to preview. pRead More] We also added two new parser functions to the transform processor, one for CEF and one for Extended Log Format, that turn those security formats into structured JSON. They follow the same upstream-first approach as the LEEF parser from earlier, so the transform processor’s parser family now covers most of the common security log shapes.Bindplane August Community Call Full-Pipeline Blueprints Are Here: Source, Processors, and Destination in One Click from Bindplane.com BindPlane has launched Full-Pipeline Blueprints, which simplify data pipeline creation by providing a complete solution including source, processors, and destination in a single click, moving beyond previous processor-only bundles. nRead More] Standardize & Route Windows Events for Google SecOps standardizes Windows Events for SecOps, then routes each channel — SYSMON, POWERSHELL, DNS, MSSQL, WINEVTLOG — through its own batch processor, so batches stay homogeneous per SecOps log type. Example of Bindplane blueprint for Google SecOpsGoogle Cloud & AI  Cloud CISO Perspectives: Sticking to security fundamentals in the AI era from Google Cloud Blog This Cloud CISO Perspectives introduces Chris Betz’s insights on why adhering to security fundamentals is more critical than ever in the age of AI. nRead More] Build zero-trust AI agents with Google’s Agent Development Kit from Google Cloud Blog Google’s Agent Development Kit (ADK) emphasizes building autonomous AI agents with a robust zero-trust architecture, implementing hardware-backed cryptographic signatures, kernel-level sandboxing, and deterministic semantic gateways to prevent prompt injections and malicious execution. gRead More] Google is a Leader in the 2026 Gartner Magic Quadrant for Cloud-Native Application Platforms from Google Cloud Blog Google has been recognized as a Leader for the third consecutive year in the 2026 Gartner Magic Quadrant for Cloud-Native Application Platforms. eRead More] How agents can delegate better from Google Cloud Blog The Google Cloud article discusses the importance of effective delegation, a key leadership skill, and explores how these principles can be applied to AI agents for better task management dRead More] Expanding Google Antigravity for enterprise customers from Google Cloud Blog Google is expanding its Antigravity platform for enterprise customers, incorporating feedback to improve developer access, security controls, license management, and pooled usage. nRead More] Adoption Guides & Deep Dives ️ Adoption Guide: How to investigate SecOps SIEM Audit Logs from Google Cloud Security Community This adoption guide explains how to investigate audit logs within Google SecOps SIEM, emphasizing the critical role of comprehensive, properly configured audit logging for complete visibility and recording system changes. iRead More] ️ Exploring Agent Graphs for SecOps AI Runbooks from Google Cloud Security Community The article from Dan Dye explores the application of Agent Graphs from the Google ADK project to create more rigorous, deterministic, and explainable AI-powered workflows for Security Operations (SecOps) runbooks. cRead More] Building Custom Anomaly Detection Models with Google SecOps and BigQuery ML: Prediction Model (Part 1) from Google Cloud Security Community This article, part one of a series, introduces building custom anomaly detection prediction models using Google SecOps and BigQuery ML, noting the need for specialized models beyond standard AI features in certain SOC environments. GRead More] Beyond Chat: Building Multi Agent SOC Ecosystems with Claude and Google MCP from Google Cloud Security Community The article discusses the shift of adversaries operationalizing AI for adaptive malware and proposes building multi-agent SOC ecosystems using Claude and Google MCP to enhance enterprise security against these advanced threats. sRead More]  Community & Events  Webinar 9/30: CodeMender: AI Code Security Agent from Google Cloud Security Community The article announces a webinar discussing CodeMender, an AI Code Security Agent designed to autonomously find and fix vulnerabilities in codebases, leveraging AI for defensive security. eRead More] Meet SecOps: Your Agentic SOC from Google Cloud Security Community This webinar discusses how Google SecOps is leveraging generative AI and autonomous agentic workflows to transform the modern Security Operations Center (SOC), enabling faster detection and response against rapidly escalating cyber threats. wRead More] Meet SecOps: Your Agentic SOC From Blocks to Bots: Scaling SecOps with Modular Playbooks and Agentic Automation from Google Cloud Security Community This webinar details how to design and deploy robust, self-healing modular playbooks in Google SecOps using Foundational Blocks and the Centaur Model, addressing complexities of monolithic designs with agentic automation. Read More] Scaling SecOps with Modular Playbooks & Agentic Automation Tuesday’s Tip of the Week — Data Tables: Allow-Lists, Block-Lists, and Enrichment in Your Rules from Google Cloud Security Community This article introduces data tables in Google SecOps as structured lookup tables for implementing allow-lists, block-lists, and enriching security rules using YARA-L syntax. nRead More] New stats hunting skill from Google Cloud Security Community A new community ‘Stats Hunter’ skill from Greg Kushmerek has been developed for the SecOps platform to simplify mathematical analytics, guiding users in statistical YARA-L searches and noise threshold management. GRead More] How We Built an Agentic Purple-Team System for Detection Validation in Google SecOps from Google Cloud Security Community A community developed an agentic purple-team system for automated detection validation in Google SecOps, which creates synthetic telemetry, validates it, and tracks its path through the security system. nRead More] GitHub - GHS-SOC/PurpleTeam-Agent: This repository demonstrates how to build an Agentic Purple Team…This repository demonstrates how to build an Agentic Purple Team for detection validation in Google SecOps, using ADK…github.com 3rd Party Blogs  The Feynman Bet: Why You Still Won’t Vibe Code Your SIEM (Today) from Anton Chuvakin The article critically examines why highly intuitive or AI-driven “vibe coding” is not yet a practical solution for managing complex Security Information and Event Management (SIEM) systems. aRead More] So Is Your SOC AI-Ready? Part 3: API or Die Audit! from Anton Chuvakin The article is the third installment in a series evaluating the AI-readiness of Security Operations Centers (SOCs), specifically highlighting the critical importance of API audits. nRead More] What Belongs Inside the Company AI Operating System? from raffy.ch The article explores what constitutes an “AI operating system layer” within a company, arguing that true AI maturity is about how AI transforms company operations rather than just the number of AI tools aRead More] AI Maturity Is Not About Tool Count from raffy.ch The article asserts that true AI maturity within a company is not measured by the number of deployed tools or users, but by its deeper integration as an operating system layer. bRead More]  Podcasts & YouTube  Governing the Autonomous SOC: Securing AI Agents End-to-End on Google’s Agent Platform from YouTube The video focuses on the governance and end-to-end security of AI agents within an autonomous Security Operations Center (SOC) operating on Google’s agent platform Securing AI Agents End-to-End on Google’s Agent Platform Vibe Coding Google SecOps Parsers with Gemini from YouTube This content features a coding session demonstrating the development of Google SecOps parsers, utilizing Google’s Gemini AI for assistance. Vibe Coding Google SecOps Parsers with Gemini Prompt Injection to Playbook: Detecting Compromised AI Agents in Google Cloud from YouTube The article discusses methods for detecting compromised AI agents, specifically those affected by prompt injection, within Google Cloud environments. Detecting Compromised AI Agents Mastering the Art of Advanced IOC Searches in Google Threat Intelligence from YouTube This content focuses on mastering advanced Indicator of Compromise (IOC) searches within Google Threat Intelligence. Mastering IOC Searches in Google TI Wiz  Rust Supply Chain Attack on arrayref: Significant Overlap with DPRK Campaigns from Wiz Blog Malicious versions of the arrayref Rust crate executed a backdoor at compile time, part of a supply chain attack whose infrastructure significantly overlaps with recent DPRK-linked campaigns. cRead More] Wiz Penetration Test Findings is now GA from Wiz Blog Wiz has announced the General Availability of its “Penetration Test Findings” feature, which unifies pen-test results with real-time cloud context for continuous exposure management. �Read More] How to Spot and Stop Rogue Device Joins from Wiz Blog This article explores how adversaries are using realistic device names to abuse Entra ID device registration, making detection more challenging, and details behavioral signals to identify and stop these attacks. Read More] Wiz Red Agent Finds Its Way Into Snowflake’s Internal Jira Due to an AI-Generated GitHub Copilot “Autofix” from Wiz Blog Wiz Red Agent independently discovered and exploited a GitHub Actions vulnerability, introduced by an AI-generated GitHub Copilot ‘Autofix,’ gaining access to sensitive data in Snowflake’s internal Jira without human intervention. tRead More] The Closed Loop Remediation Playbook with Wiz from Wiz Blog Wiz has launched new capabilities, including Workflows (GA) and Remediation and Response (public preview), to help organizations achieve a self-healing cloud through automated security remediation. MRead More]  Platform Issues  RESOLVED: We are investigating a potential issue with Google SecOps in the US region from Google Cloud Status Google is investigating an issue with elevated latencies on “Dashboards & Reports” within Google SecOps in the US region, affecting UDM Events dashboards. �Read More]        What's New in SecOps Mon, 24 Aug 2026 07:42:13 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/unwrapping-kubernetes-logs-in-google-secops-a-jenkins-case-study-8138  As more organizations modernize their workloads, Kubernetes has become the de facto standard for deploying applications. However, this architectural shift introduces a unique challenge for Security Operations: log wrapping. When application logs—such as those from Jenkins—are ingested directly from a container's stdout, they are natively assigned to the KUBERNETES_NODE parser in Google SecOps. Because the actual application data is wrapped inside Kubernetes metadata, out-of-the-box application parsers can't process the payload, leaving security teams with a parsing roadblock. Recently, a customer reached out looking for a way to dynamically route these nested logs to the correct application parsers. In this post, I'll walk you through a complete, hands-on solution to this exact problem. We will build a tailored ingestion pipeline by setting up a Jenkins container lab on GCP, utilizing Pub/Sub and Cloud Functions to intelligently unwrap the data (and writing a custom parser if your JENKINS version requires) to ensure your logs are perfectly normalized into UDM. The cloud function code, custom parser code,  and summary of required IAM roles will be provided as attachment. Let’s begin with the lab setup. 1 - Set up the GCP project and APIs- Pick or create a test project, then enable the required APIs (On GCP Cloud Console)# gcloud config set project YOUR_PROJECT_ID # gcloud services enable container.googleapis.com logging.googleapis.com  Use a disposable/sandbox project if you have one — this avoids any interference with production log routing or SecOps feeds. 2 - Create a small GKE cluster- A single-node Standard cluster is enough and keeps cost low # gcloud container clusters create jenkins-test-cluster --zone=us-west2-c  --num-nodes=1 --machine-type=e2-standard-4  # gcloud container clusters get-credentials jenkins-test-cluster --zone=us-west2-c GKE's built-in Cloud Logging integration is on by default for new clusters — no extra config needed for logs to start flowing as k8s_container entries. 3 - Install Helm and add the Jenkins chart repo- If you don't already have Helm:# curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash- Then add the official Jenkins chart repo (this is the chart your sample log's helm_sh/chart label came from):# helm repo add jenkins https://charts.jenkins.io helm repo update 4 - Deploy Jenkins into a namespace- Create a namespace and install the chart. Use whatever namespace name you like — it becomes resource.labels.namespace_name in the log:# kubectl create namespace jenkins-test # helm install jenkins jenkins/jenkins --namespace jenkins-testThis deploys a StatefulSet named 'jenkins' with a pod called jenkins-0 and a container called jenkins — matching resource.labels.pod_name / container_name in your sample. - Wait a minute or two for the pod to reach Running# kubectl get pods -n jenkins-test -w 5 - Get the admin password and login- Retrieve the auto-generated admin password:# kubectl exec -n jenkins-test svc/jenkins -c jenkins -- /bin/cat /run/secrets/additional/chart-admin-password - Then port-forward to reach the UI locally:# kubectl port-forward -n jenkins-test svc/jenkins 8080:8080 - Open http://localhost:8080 and log in as 'admin' with the password above.   6 - Install and configure the Audit Trail plugin- In the Jenkins UI: Manage Jenkins > Plugins > Available plugins, search 'Audit Trail', install it, and restart if prompted. Then go to Manage Jenkins > System, find the Audit Trail section, and confirm a logger is enabled (the default java.util.logging console logger is usually sufficient — Jenkins' base Docker image already routes java.util.logging output to stdout, which is exactly why the plugin's lines show up in textPayload without any extra config).  7 - Check for the login events on cloud logging Now the lab setup is complete, it is time to import these without Kubernetes header to Google Secops so that JENKINS parser can be used. 8- Create a dedicated Pub/Sub topic# gcloud pubsub topics create jenkins-raw-logsThis isolates the Jenkins stream from your general Kubernetes log flow so you can process it independently without touching your existing pipeline.  9 - Create a filtered Cloud Logging sink- Create a sink that only matches your Jenkins pod, pointed at the new topic: # gcloud logging sinks create jenkins-to-pubsub pubsub.googleapis.com/projects/YOUR_PROJECT_ID/topics/jenkins-raw-logs  --log-filter='resource.type="k8s_container" AND resource.labels.cluster_name="jenkins-test-cluster" AND resource.labels.namespace_name="jenkins-test" AND resource.labels.container_name="jenkins"'  - Grant the sink's service account publish rights (the command above prints a writer identity — grab it and run): # gcloud pubsub topics add-iam-policy-binding jenkins-raw-logs --member=serviceAccount:SINK_WRITER_IDENTITY  --role=roles/pubsub.publisher  10 - Set up a service account for Chronicle API access- Create a service account for the function to call the Chronicle API: # gcloud iam service-accounts create secops-jenkins-ingest  - Grant it the Chronicle/SecOps ingestion role # gcloud projects add-iam-policy-binding YOUR_PROJECT_ID  --member="serviceAccount:secops-jenkins-ingest@YOUR_PROJECT_ID.iam.gserviceaccount.com"  --role="roles/chronicle.editor"   - Also note your Customer ID and the correct regional API endpoint from SecOps Settings > Profile > Organization Details 11 - Navigate to Cloud Run functions- Go to console.cloud.google.com, make sure your test project is selected in the project switcher at the top, then use the search bar and type 'Cloud Run functions' (Google has merged Cloud Functions into the Cloud Run product in the console). Click into it from the search results. 12 - Start creating a new function- Click the Python button  under Write a function. 13 - Set the function name and environment- Under Basics: Environment should be set to 2nd gen (default). Enter a Function name, e.g. jenkins-unwrap-ingest. Choose the Region — pick the same region your Pub/Sub topic and GKE cluster are in, to avoid cross-region latency/cost. 14 - Configure the Pub/Sub trigger- Under Trigger, click Add Trigger and select Cloud Pub/Sub from the trigger type list. In the Select a Cloud Pub/Sub topic dropdown, choose the jenkins-raw-logs topic you created earlier.  - Click "grant all" and  "save" 15 - Set the service account and environment variablesExpand Containers, Networking and Security. Under the Security tab: - Set Runtime service account to the secops-jenkins-ingest service account you created - Under Runtime environment variables, click Add variable and add each of: CHRONICLE_CUSTOMER_ID, CHRONICLE_PROJECT_NUMBER, CHRONICLE_REGION,  CHRONICLE_LOG_TYPE, enter your actual values for each. - Click create service with all other options left default.- Now, edit requirements.txt and main.py with the attached codes, set function entry point to unwrap_and_ingest and click "Save and redploy". Click "grant all" in the opening pop-up. - Wait for the deployment completion: - The next step is testing our code16 - Publish a test message directly to the Pub/Sub topic- In the Cloud Console, go to Pub/Sub > Topics, click into jenkins-raw-logs, and click  Messages tab > Publish Message. Paste in a fake Cloud Logging envelope as the message body, e.g.:{"textPayload": "2026-08-23 12:00:00:000 - /manage/credentials/ by Test User from 9.9.9.9", "insertId": "test123", "resource": {"type": "k8s_container", "labels": {"namespace_name": "jenkins-test", "container_name": "jenkins"}}, "timestamp": "2026-08-23T12:00:00Z"}This lets you test the function's logic directly, without waiting on a real Jenkins event to flow through Cloud Logging first — it isolates 'is my function correct' from 'is my sink/log pipeline correct'  17 - Check the function's execution logs- Go back to Cloud Run functions, click into jenkins-unwrap-ingest, and open the Logs tab. Within a few seconds of publishing, you should see a new invocation. Look for the line 'Ingested 1 log line to Chronicle as JENKINS' — that confirms the function ran, parsed the JSON, extracted textPayload, and got a successful (2xx) response back from Chronicle. 18 - Check the ingestion on Secops * I created a user - google - on Jenkins, tested to see for its audit logs* * In case the prebuilt parser has issues with ingested data, a working custom parser is also attached. SummaryThe challenge of Kubernetes "log wrapping" is a hurdle almost every modern security team faces as they migrate to containerized workloads. While native dynamic parser chaining is a highly requested feature, you don't have to wait to get clean, actionable data into your SIEM. By leaning on Google Cloud’s native serverless components—specifically Pub/Sub and Cloud Functions—we successfully built a highly scalable preprocessing layer. We intercepted the stdout stream, stripped away the overarching node metadata, and routed the raw Jenkins payload directly to our custom SecOps parser. The best part? This architecture isn't unique to Jenkins. You can easily adapt this exact Cloud Function and Pub/Sub pipeline to unwrap logs for any containerized application in your fleet, ensuring your SOC always has the precise UDM fields they need for robust detections and rapid investigations. Google Security Operations Sun, 23 Aug 2026 18:34:26 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/timestamp-ish-fields-appear-to-be-magically-reformatted-when-using-them-in-soar-placeholder-expressions-8137 Hello! I’ve found a behavior that tripped me up for a while, so I thought I’d share it here to see if it’s normal and expected, or if other people have found the same behavior and have workarounds for it, or at least can keep it in mind if doing similar things.So, it appears that when using SOAR placeholders to insert an alert variable that contains a ISO-8601 formatted string, the mere act of inserting the nEvent.detection_outcomes_timestampField] placeholder reformats it into YYYY-MM-DDThhss+00:00 (it drops any fractional seconds, and forces the timezone to UTC expressed as +00:00). This surprised us, because we were explicitly formatting those timestamps in the YARA-L search (in the outcome block, using the timestamp.get_timestamp function https://docs.cloud.google.com/chronicle/docs/detection/yara-l-2-0-functions/timestamp-get_timestamp) so they’d contain millis and be in our local timezone. Besides, timestamp.get_timestamp states that its output is a string, not some special DATETIME object, so I’d expect strings to never be altered just by inserting them with a placeholder.We have a YARA-L search that looks like this:outcome: $date_incident = timestamp.get_timestamp(max($e.metadata.event_timestamp.seconds), "%Y-%m-%dT%H:%M:%S.000%z", "America/Guayaquil") $date_detection = timestamp.get_timestamp(timestamp.current_seconds(), "%Y-%m-%dT%H:%M:%S.000%z", "America/Guayaquil")which creates alerts with the date_incident and date_detection outcome variables in the specified format, so far so good:I’d expect the outcome variables to be just plain raw opaque strings from here on, so inserting them via SOAR placeholders would just write the exact same characters that I see in the alert’s data. Then, on a HTTP step on a SOAR playbook, we have this as part of a JSON body:"date_incident": "dEvent.detection_outcomes_date_incident]","date_detection": "aEvent.detection_outcomes_date_detection]"I’d expect that to just insert the date_incident and date_detection outcome variables, which would be strings and therefore would just be printed as-is into the output. However, that’s not what I see, and when running that step, the JSON body is rendered as follows:"date_incident": "2026-08-21T13:56:20+00:00", "date_detection": "2026-08-21T14:04:24+00:00"The timezone has been set to +00:00 (as opposed to the timezone that we manually set in the YARA-L rule, which was recorded in the alert’s outcome variables), the numerical value of the hour of day has changed (to match the changed timezone), and there are no longer milliseconds in the printed timestamp (sure, the date_incident and date_detection variables had .000 as the millis, but I’d expect them to be printed out by the placeholder, if it’s just treating the variables as strings)We also see that same format in our destination system, so it isn’t just a display bug in the the Technical Details tab of the Simulator, it’s actually what is being sent out on the HTTP body:So, from what I can see, all timestamp-ish fields (alert variables) that you attempt to use in placeholders will always come out expressed in UTC, and in yyyy-MM-DDThhss+00:00 format? This can be an issue for other (destination) systems, e.g. Jira https://developer.atlassian.com/cloud/jira/service-desk/rest/intro/#fieldformats requires date/time fields to contain a milliseconds part, even if all zeros (e.g. “2015-11-18T14:39:00.000+1100” must have the .000 before the timezone), so this magical reformatting means that now SecOps can’t directly create a Jira ticket (and yes, there’s probably a Jira integration in the Content Hub, but still, and there may be other less known/in-house destinations that will require HTTP requests). Or the fact that timestamps always come out in UTC means that it wouldn’t be possible to send an email to the user stating that “At 2026-08-21T12:20 your time, ...” because writing “At 8Event.detection_outcomes_date_incident] your time” will display the Greenwich hour, even if the alert took care to express the time in the user’s local timezone in the $date_incident outcome variable.Has anyone else experienced the same thing? For now, since we don’t need the actual milliseconds (so .000 is OK) and we can tolerate timestamps being expressed in UTC rather than our local timezone, we’ve taken to using placeholders like this: cEvent.detection_outcomes_date_incident | replace("+00:00", ".000+00:00")] This (very hackily) converts “2026-08-21T13:56:20+00:00” into “2026-08-21T13:56:20.000+00:00”, by inserting .000 just before the timezone. But it still feels surprising to have a string variable be magically reformatted into a fixed time format when the incoming string looks like a timestamp.Furthermore (i just found out while attempting to understand the problem above), the Expression Builder also has some weirdness there. If you write “2026-08-21T08:56:20.000-0500” (without the quotes) in the Placeholder Test Data field, and just click the Run button, you get out “08/21/2026 13:56:20“, so it clearly reformatted the string into another, not-user-controlled format. I’d expect that, if the Expression field is empty, that should just pass through whatever was in the Test Data field into the Results field, with no changes performed. Instead, it appears to have parsed the input as a date, changed it to US-style date (month/day/year), the time separated by a space rather than the ISO-8601 T, there’s no longer a timezone specifier, and it has been re-expressed in UTC:However, if you now add the filter | replace("+00:00", "+00:00") in the Expression field (which should do absolutely nothing, as it’s just replacing X by , it now has a different output “2026-08-21T13:56:20.0000000+00:00” (now with microseconds and the timezone changed to UTC and explicitly shown, the previous one with no filter did change the timezone to UTC but didn’t print it):And, even weirder, neither of those outputs match what you get when actually running the playbook with that placeholder!  Inserting tEvent.detection_outcomes_date_incident] as a placeholder generates a string like “2026-08-21T13:56:20+00:00” Google Security Operations Sat, 22 Aug 2026 19:56:01 +0200