Recently active topics

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 custo

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

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.

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 an

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. 

🗄️ 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 │└─────────┬─────────┘│┌──────────────┼──────────────┐▼ ▼ ▼┌────────────────┐ ┌───────────┐ ┌──────────────────┐│

⚠️ 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

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

 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

 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 pas

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 acr

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. 

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

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.

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.

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 cam

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-c

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 bou

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.

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 A

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!

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 au

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

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? ...

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.