https://security.googlecloudcommunity.com On the Forum you can ask questions or take part in discussions. https://security.googlecloudcommunity.com/google-threat-intelligence-3/automating-card-leak-monitoring-via-google-threat-intelligence-dark-web-search-and-api-7766 Financial institutions face an ongoing battle against card fraud and credential leaks. A common challenge for security teams is identifying when Bank Identification Numbers (BINs) are leaked across underground channels. To address this, Google Threat Intelligence (GTI) provides advanced, real-time dark web search capabilities to gain direct visibility into illicit communication networks.This article details how to leverage GTI’s advanced dark web search capabilities to automate BIN leak monitoring, transitioning from manual searching to a scalable, automated pipeline. Harnessing Modern Dark Web Search Capabilities Google Threat Intelligence indexes underground communication platforms dynamically, allowing security teams to query massive volumes of raw dark web data using precise, granular filters. For a deeper understanding of these capabilities, you can review the Google Threat Intelligence Dark Web Guide.By interacting with these capabilities via the API, analysts can continuously scan for targeted indicators—such as specific BIN sequences—and immediately route the findings to fraud prevention or incident response platforms. Crafting the Search Query To minimize false positives and capture high-fidelity alerts, the query must be structured to cross-reference target card prefixes with industry-specific contextual keywords and corporate identifiers.The following query template isolates messenger application leaks involving specific credit or debit cards for a target financial institution: type:messenger (content:'BIN1' OR content:'BIN2' OR content:'BIN3' OR content:'BIN4' OR content:'BIN5' OR content:'BIN6' OR content:'BIN7' OR content:'BIN8' OR content:'BIN9' OR content:'BIN10') (content:'Credit' OR content:'Debit') (content:'<FINANCIAL_INSTITUTION_NAME>') Breakdown of the Query Structure: type:messenger: Restricts the search surface to instant messaging platforms (such as Telegram which is commonly favored by threat actors for rapid data dumping and selling). content:'<BIN_NUMBER>': An explicit OR chain containing the target organization's known card prefixes. content:'Credit' OR content:'Debit': Adds specific context to focus on carding activities rather than random hits. content:'<FINANCIAL_INSTITUTION_NAME>': Anchors the results to the specific brand name to validate that the leaked records are tied directly to your enterprise.  Automating the Collection via API To export these alerts into a portable format like CSV—which can be readily ingested by SIEMs, data lakes, or external ticketing systems—we can leverage the GTI API.The standalone Python script, leaked_cards_dw_all.py, utilizes the List DDW Communications endpoint to pull records matching our query. Key Technical Pillars of the Automation Script: Cursor-Based Pagination: Handles large datasets gracefully by parsing the next link provided in the API response metadata. It fetches results in optimal page sizes of 40 records up to a maximum cap of 200 records. Dynamic JSON Flattening: Dark web communication payloads can contain deeply nested tracking fields, author metadata, and network paths. The script recursively flattens these structures into uniform key-value pairs. Timestamp Normalization: Converts raw epoch timestamps into clean, human-readable dates (YYYY-MM-DD HH:MM:SS) during processing. Resilience: Implements built-in rate-limit handling (detecting HTTP 429) to automatically pause and retry, preventing script termination during large collection runs. Here is the production-ready automation script from leaked_cards_dw_all.py. Make sure to replace Insert_Your_GTI_API_Key and the placeholder tokens inside the FILTER_QUERY with your specific assets.import csvimport timeimport loggingimport requestsfrom datetime import datetime# ---------------------------------------------------------# Configuration & Setup# ---------------------------------------------------------logging.basicConfig(    level=logging.INFO,    format="%(asctime)s - %(levelname)s - %(message)s",    datefmt="%Y-%m-%d %H:%M:%S")# NOTE: In production, load this from an environment variableAPI_KEY = "Insert_Your_GTI_API_Key"BASE_URL = "https://www.virustotal.com/api/v3/ddw_communications"FILTER_QUERY = (    "type:messenger "    "(content:'BIN1' OR content:'BIN2' OR content:'BIN3' OR content:'BIN4' OR "    "content:'BIN5' OR content:'BIN6' OR content:'BIN7' OR content:'BIN8' OR "    "content:'BIN9' OR content:'BIN10') "    "(content:'Credit' OR content:'Debit') "    "(content:'<FINANCIAL_INSTITUTION_NAME>')")def flatten_json(nested_json: dict, separator: str = "_") -> dict:    """Recursively flattens a nested dictionary."""    out = {}    def flatten(x, name=""):        if isinstance(x, dict):            for a in x:                flatten(xta], name + a + separator)        elif isinstance(x, list):            i = 0            for a in x:                flatten(a, name + str(i) + separator)                i += 1        else:            out�namet:-1]] = x    flatten(nested_json)    return outdef fetch_and_export_ddw_to_csv(api_key: str, query: str, output_csv: str, max_results: int = 200, page_limit: int = 40):    """    Paginates through results to fetch up to max_results, formats timestamps,    and exports all nested JSON fields as distinct columns in a CSV file.    """    headers = {        "x-apikey": api_key,        "accept": "application/json"    }        # Parameters are only needed for the very first request    params = {        "limit": page_limit,        "filter": query    }    logging.info(f"Starting fetch for up to {max_results} results in batches of {page_limit}...")        all_items = �]    current_url = BASE_URL        while current_url and len(all_items) < max_results:        try:            # If we are on the base URL, pass the params dict.             # Otherwise, VirusTotal's `next` link already has the parameters baked into the URL string.            if current_url == BASE_URL:                response = requests.get(current_url, headers=headers, params=params)            else:                response = requests.get(current_url, headers=headers)                        if response.status_code == 429:                logging.warning("Rate limit exceeded (HTTP 429). Sleeping for 60 seconds...")                time.sleep(60)                continue                            response.raise_for_status()            data = response.json()            items = data.get("data", x])                        if not items:                logging.info("No more results returned for this filter.")                break            # Calculate how many items we actually need to hit the max_results cap            needed = max_results - len(all_items)            items_to_add = items�:needed]            all_items.extend(items_to_add)                        logging.info(f"Fetched {len(items_to_add)} items. Total collected so far: {len(all_items)}/{max_results}")                        # Pagination logic            current_url = data.get("links", {}).get("next")            time.sleep(1)        except requests.exceptions.RequestException as e:            logging.error(f"API Request failed: {e}")            break                if not all_items:        logging.info("No data collected. Exiting without creating a CSV.")        return    logging.info("Formatting timestamps and preparing CSV data...")    flattened_records = ]    for item in all_items:        flat_record = flatten_json(item)                # Format Timestamps        for time_field in 'attributes_timestamp', 'attributes_date']:            if time_field in flat_record and isinstance(flat_record, (int, float)):                flat_record = datetime.fromtimestamp(flat_record).strftime('%Y-%m-%d %H:%M:%S')        flattened_records.append(flat_record)    # Collect unique headers    all_csv_headers = set()    for record in flattened_records:        all_csv_headers.update(record.keys())            all_csv_headers = sorted(list(all_csv_headers))    try:        with open(output_csv, mode="w", newline="", encoding="utf-8") as csv_file:            writer = csv.DictWriter(csv_file, fieldnames=all_csv_headers)            writer.writeheader()                        for record in flattened_records:                writer.writerow(record)                        logging.info(f"Successfully exported {len(flattened_records)} records to {output_csv}")    except IOError as e:        logging.error(f"Failed to write to CSV file: {e}")if __name__ == "__main__":    if not API_KEY:        logging.error("API Key is missing.")    else:        output_filename = "filtered_ddw_results.csv"        # Using max_results=200 and page_limit=40 as requested        fetch_and_export_ddw_to_csv(API_KEY, FILTER_QUERY, output_filename, max_results=200, page_limit=40)  Conclusion and Operational Flexibility Transitioning dark web intelligence ingestion away from manual workflows into programmatic pipelines empowers organizations to respond rapidly to exposures. By extracting data through the GTI API using leaked_cards_dw_all.py, security teams can dynamically route structured CSV logs directly into internal security orchestration playbooks.While the primary focus of this guide demonstrates how to capture leaked financial card data, the underlying automation architecture remains entirely agnostic to the data type. By simply modifying the FILTER_QUERY string within the script, you can easily pivot this automation tool to address a broad range of cyber threat intelligence use cases. Google Threat Intelligence Fri, 19 Jun 2026 14:01:03 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/use-the-new-secret-manager-integration-to-automatically-manage-response-integration-credentials-7765 Hey folks,As you know, managing credentials in Google SecOps can be quite tedious. To address this, we released a new integration called “Secret Manager”. The purpose of this integration is to allow you to automatically manage all of the credentials associated with Response Integrations, Connectors and Jobs from 1 place.  How it works?Inside the integration, there is a job called “Sync Integration Credential Job”. This job is responsible for the synchronization of credentials.As part of the job, you will need to provide a configuration JSON that will map the Google SecOps content to Secret Manager entries.AuthenticationJust like all other Google Cloud integrations, this integration supports authentication via Workload Identity and Service Account key. You will need to assign “Secret Manager Secret Accessor” Role.Note: for situations, where you have identity created in Project A, but your Secret Manager credentials are located in Project B, you should use parameter Project ID, which will force the integration work in a specific project.Job ConfigurationThe Job relies on 2 parameters to understand, which configurations should be updated: “Environment” and “Credential Mapping”.“Environment” parameter tells the job, in which Google SecOps Environment the job should search for Integration Instances. The job can only update Integration credentials from 1 environment, so if you have a multi-tenant environment, you will need to create multiple job instances. To work with Shared environment, you must provide “*” in the “Environment Field”.Unlike Integration Instances, Connectors and Jobs are not assigned to a specific environment. They are identified by their unique names. You can provide all connector and job configuration as part of one config, but the best practice is to still have them separated based on the environment to which the data is being sent and synchronized. The structure of the mapping JSON looks like this:{ "integration_instances": { "{Integration Instance Name}": { "{Integration Parameter 1}": "{Secret Manager Entry resource name}", "{Integration Parameter 2}": "{Secret Manager Entry resource name}" } }, "connectors": { "{Connector Name}": { "{Connector Parameter}": "{Secret Manager Entry resource name}", "{Connector Parameter}": "{Secret Manager Entry resource name}" }, "{Connector Name 2}": { "{Connector Parameter}": "{Secret Manager Entry resource name}", "{Connector Parameter}": "{Secret Manager Entry resource name}" } }, "jobs": { "{Job Name}": { "{Job Parameter}": "{Secret Manager Entry resource name}" } }}Information about Integration instance is located under “Response” → “Integrations Setup”: Information about Connectors is under SOAR Settings → “Ingestion” → “Connectors”:  Information about Jobs:  On the side of Secret Manager, you will need to create a new Secret Manager entry per parameter that needs to be tracked. For example, in the screenshot below, I’ve created a Secret Manager entry for the API Key secret.   The input can be provided in 2 formats:resource name of the Secret Manager entry. For example: projects/1111/secrets/GTI_CLIENT_SECRET resource name of the Secret Manager entry with a version: For example: projects/508138417679/secrets/GTI_CLIENT_SECRET/versions/1If you provide the input without a version, the job will search for the latest Active version associated with an entry and update the value to it.If you provide an explicit version, then the job will set the credential to that specific version.Note: only Active versions can be used by the job.  Only parameters that are provided in the Job will be updated, all other parameters will be left unchanged. Also, if the job encountered an error for a specific configuration item, it will not stop the execution completely, instead it will try to update all entries that are provided in the mapper and then raise an error indicating that not all entries were updated. Here is an example configuration:{ "integration_instances": { "GoogleThreatIntelligence_1": { "API Root": "projects/1111/secrets/GTI_TEST_API_ROOT", "API Key": "projects/1111/secrets/GTI_CLIENT_ID/versions/1" } }, "connectors": { "Crowdstrike - Alerts Connector": { "Client Secret": "projects/1111/secrets/CrowdstrikeConnectorSecret", "Client ID": "projects/1111/secrets/CrowdstrikeConnectorID" }, "Microsoft Graph Mail Connector": { "Client Secret": "projects/1111/secrets/GraphConnectorSecret", "Client ID": "projects/1111/secrets/GraphConnectorID/versions/3" } }, "jobs": { "Sync Incidents": { "API Root": "projects/1111/secrets/API_Root/versions/2" } }} With this configuration the following information will be updated:GoogleThreatIntelligence_1 instance (API Root and API Key) Crowdstrike - Alerts Connector (Client Secret and Client ID) Microsoft Graph Mail Connector (Client Secret and Client ID) Sync Incidents Job (API Root) Summary With the new Secret Manager integration, you can automatically manage secrets. Moving forward we want to add more products to be supported in the same way. Let us know, what products we should prioritize next! Google Security Operations Fri, 19 Jun 2026 13:26:19 +0200 https://security.googlecloudcommunity.com/news-announcements-9/why-securing-the-prompt-is-only-the-beginning-of-ai-application-security-7761 Hey Community!When it comes to building AI applications, the race to market often leaves security trying to catch up. But what if adhering to the right guardrails actually gave your development process a competitive boost?Our Mandiant offensive security teams are on the front lines stress-testing AI systems to understand their unique vulnerabilities. Recently, they conducted adversarial assessments on a pre-production banking chatbot. By uncovering an exposed API endpoint, our red team intercepted chat history data sent in easily modifiable JSON and injected fake "system" messages. The large language model, accepted this falsified history as fact, bypassed its primary instructions, and allowed the red team to make unauthorized account changes.The takeaway? Securing mere model prompts isn't enough. You have to secure the entire AI application.Based on these hands-on assessments, we've distilled our recent findings into five critical lessons to help you securely develop and deploy AI applications:Defend your AI pipeline from end to end: Security shouldn't be a final layer. Integrate it across all phases of the SDLC, from data ingestion to deployment. Don't take front-end data at face value: Threat actors will try to intercept and modify client-side data structures. Move from trusting user input to continuously verifying it with cryptographic signatures like HMAC. Lock the door on system-level prompts: Block privilege escalation at the application layer by configuring your logic to sanitize data and drop privileged system messages originating from the UI. Stick to application security basics: AI relies heavily on third-party libraries and orchestrators. Apply standard application security testing and vulnerability scanning to your entire AI tech stack. Build an early warning system: Integrate application and infrastructure logs with centralized security monitoring tools for real-time detection and response.Building AI securely is a foundational requirement for realizing the full potential of this technology.Read the full breakdown of these lessons and learn how to take a proactive approach to your AI security: https://cloud.google.com/transform/5-lessons-from-red-teaming-ai-applications News & Announcements Thu, 18 Jun 2026 23:52:38 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/issues-with-find-first-alert-and-change-case-name-actions-from-the-tools-powerup-7724 The "Find First Alert" and "Change Case Name" actions from the Tools Powerup have been silently failing after the latest update to the powerup (version 81) with IndexErrors for out of range index. Anybody else experiencing this? Google Security Operations Thu, 18 Jun 2026 23:30:45 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/detection-query-inside-a-udm-rule-7760 Hi All, End Goal:Our team is creating a query which triggers on dev vs prod rules and we need to query the friendly rule name within the saved detection rule. Is it possible to query detection data (detection.detection.) inside a UDM rule or is there any other way within UDM to get this information? rule dev_rule_name { meta: author = "SOMEONE" events: $detections.metadata.log_type = "GCP_CLOUDAUDIT" ( detection.detection.rule_name != /prod_/ and $detections.metadata.product_event_type = SOME EVENT ) outcome: //OUTCOME FIELDS condition: $detections} When I try to do something similar to the above, I get parsing errors:  I’ve Tried:Using variables, e.g. $rule_name = detection.detection.rule_name Using Regex, e.g.  re.regex(detection.detection.rule_name, `^prod_`) and Calling it using by prepending $detections, e.g. re.regex($detections.detection.detection.rule_name, `^prod_`)The Raw log and the Event fields do not contain the friendly name, but the outcome / columns does contain this data:  Any advice would be appreciated.  TIA! Google Security Operations Thu, 18 Jun 2026 23:17:56 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/exclusions-for-custom-rules-7759 Hi Team,Will there be an option for adding exclusions via REST API or UI for custon rules in future?I can see it is only available for curated rules Google Security Operations Thu, 18 Jun 2026 19:10:32 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/invalid-argument-unknown-or-unset-entity-type-for-ip-address-7756 Good Day.I am trying to parse the following threat inetl log with IP_ADDRESS and I am getting:LOG_PARSING_GENERATED_INVALID_EVENT: "generic::invalid_argument: unknown or unset entity type"If the log is a MD5, SHA1 or SHA256 or DOMAIN_NAME event then the parser works.The log is as follows:{  "id": "2105",  "event_id": "102",  "object_id": "343",  "object_relation": "ip-dst",  "category": "Network activity",  "type": "ip-dst",  "to_ids": true,  "uuid": "c4e7ea82-b7bc-414b-8d68-7b1d5739182f",  "timestamp": "1609421134",  "distribution": "5",  "sharing_group_id": "0",  "comment": "",  "deleted": false,  "disable_correlation": false,  "first_seen": null,  "last_seen": null,  "value": "1.1.1.1"}The parser is as follows:filter {  mutate {    replace => {      "id"           => ""      "type"         => ""      "value"        => ""      "confidence"   => ""      "category"     => ""      "timestamp"    => ""      "entity_type"  => ""      "entity_event" => ""      "uuid"         => ""    }  }  json {    source         => "message"    array_function => "split_columns"  }  mutate {    replace => {      "event.idm.entity.metadata.vendor_name"       => "IOC"      "event.idm.entity.metadata.product_name"      => "IOC"      "event.idm.entity.metadata.description"       => "%{category}"      "event.idm.entity.metadata.product_entity_id" => "%{uuid}"    }  }  if �type] == "sha256" {    mutate {      replace => {        "event.idm.entity.metadata.entity_type" => "FILE"        "event.idm.entity.entity.file.sha256"   => "%{value}"      }    }  }   else if dtype] == "sha1" {    mutate {      replace => {        "event.idm.entity.metadata.entity_type" => "FILE"        "entity_event.entity.resource.type"     => "%{type}"      }    }  }   else if type] == "domain" {    mutate {      replace => {        "event.idm.entity.metadata.entity_type" => "DOMAIN_NAME"        "event.idm.entity.entity.hostname"      => "%{value}"      }    }  }   else if ttype] == "md5" {    mutate {      replace => {        "event.idm.entity.metadata.entity_type" => "FILE"        "event.idm.entity.entity.file.md5"      => "%{value}"      }    }  }  # else if �type] in �"uri", "url", "link"] {  #   mutate {  #     replace => {  #       "event.idm.entity.metadata.entity_type" => "URL"  #       "event.idm.entity.entity.url"           => "%{value}"  #     }  #   }  # }else if type] == "ip-dst" and evalue] != "" {  mutate {    replace => {      "event.idm.entity.metadata.entity_type" => "IP_ADDRESS"    }  }  if tevent]tidm]uentity]�metadata]�entity_type] == "IP_ADDRESS" {    mutate {      merge => {        "event.idm.entity.entity.ip" => "value"      }      on_error => "value_empty"    }    mutate {      convert => {        "value" => "bytes"      }      on_error => "failed_to_convert_value"    }    mutate {      rename => {        "value" => "event.ioc.ip_and_ports.ip_address"      }      on_error => "value_not_found"    }  }}  statedump {}  mutate {    merge => { "@output" => "event" }  }} Google Security Operations Thu, 18 Jun 2026 18:11:33 +0200 https://security.googlecloudcommunity.com/fraud-defense-recaptcha-6/google-cloud-web-risk-submission-api-7725 I am building a small phishing-reporting workflow to identify credential-harvesting pages and submit confirmed malicious URLs quickly.The goal is to reduce the lifespan of phishing pages and disrupt the attackers’ ability to profit from stolen credentials. The workflow reviews suspicious links, records the relevant indicators, and submits only URLs that appear to be genuine phishing or credential-harvesting pages.I am interested in using the Web Risk Submission API, but I have not found a self-service enrollment path. I have setup the oauth and generally have it working but the documentation mentions “Contact sales or your customer engineer to obtain access to this feature.” which has been a vortex of disappointment.Can an individual developer or small security-focused project request access? If so, what is the correct process? If not, is there another supported way to submit confirmed phishing URLs programmatically?Thank you. Fraud Defense (reCAPTCHA) Thu, 18 Jun 2026 16:49:25 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/403-missing-permissions-in-secops-unified-rules-ui-featured-content-api-scope-evaluation-bug-7738 The Featured Content microservice powering the Unified UI appears to be improperly evaluating identity mapping. Because our namespaces are defined but user enforcement is turned off, the API fails to route unscoped global curated rules to the frontend, resulting in a 403.Architecture: Multi-tenant environment using namespaces (Customer A, Customer for logical isolation.Current State: Data Access Paradigm Enforcement is currently Disabled/Inactive as our unified analyst team manages all clients globally.Troubleshooting Already Performed:Verified the user has the required legacy permissions (chronicle.curatedRules.*, chronicle.curatedRuleSets.*). The standalone "Curated Detections" tab loads and functions perfectly. Verified the user has the required new permission (chronicle.featuredContentRules.list) attached to their custom Alpha role.  Google Security Operations Thu, 18 Jun 2026 13:43:33 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/how-to-distinguish-between-precise-and-broad-curated-detections-at-the-alert-level-in-composite-detections-7737 Hi everyone. I am working on enabling curated detections via composite detections. One issue that I have not been able to figure out yet so far is, is there a UDM value that defines whether a curated detection rule is broad or precise? I looked at the meta fields of the curated detections and used the network inspection tool as well to look at the actual json format. So far I have not been able to find such a field.My usecase is to write separate composite detections for precise curated detections and broad curated detections. I have a rule that consumes detections from curated detections but, as far as I know, it is not possible to distinguish whether these detections come from precise or broad rules. Thanks in advance. Google Security Operations Thu, 18 Jun 2026 04:27:41 +0200 https://security.googlecloudcommunity.com/cloud-security-foundation-7/lock-down-your-azure-feeds-so-a-leaked-credential-can-t-be-used-from-anywhere-7748 When you set up an Azure feed in Google SecOps, you copy a credential into the config — a storage account key, or an Event Hub connection string. By default, that credential has a problem: no IP restriction, no expiry, and full rights to the resource it came from.So if it ever leaks — a screenshot in a ticket, an old wiki page, a CI log — anyone who finds it can use it from anywhere on the internet until you rotate it.The fix is simple: put a network firewall on the Azure resource and only allow Google's IP ranges through.After that, the credential still works, and your feed keeps running — but it's useless to anyone outside Google's address space. That removes basically all the opportunistic risk.How it works, in three moves:Turn on the Azure firewall (deny by default) on the Storage Account or Event Hub Namespace that backs your feed. Allow-list Google's published IP ranges from https://www.gstatic.com/ipranges/goog.json. Set up a monthly refresh, because that list changes over time.I wrote a full walkthrough that covers both feed types (Storage and Event Hubs), the portal + CLI + PowerShell commands, and an optional automation runbook that automatically keeps the allow-list in sync for you.Full guide here: https://blueaisecurity.com/hardening-azure-feeds-into-google-secopsHope it's useful — happy to answer questions. Cloud Security Foundation Wed, 17 Jun 2026 16:21:49 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/can-alert-playbooks-be-triggered-by-case-stage-changes-investigation-research-7706 Hello everyone,I'm trying to build a Google SecOps SOAR integration with Freshdesk using HTTPv2.My goal is to automatically create a Freshdesk ticket when a case is moved to either:Investigation ResearchI created an Alert Playbook with a Custom Trigger configured as: �Case.Stage] = InvestigationORRCase.Stage] = Research The playbook contains a simple HTTPv2 action that should create a ticket in Freshdesk.The playbook is enabled and saved. I also verified that the case stage is successfully changed, for example:"Case stage set to Investigation"However, the playbook never executes when the case stage changes.From the documentation and community posts, I understand that Alert Playbooks can access Case fields (Case.Stage, Case.Name, Case.Tags, etc.), but I'm not sure whether a Case Stage change is actually considered a trigger event for an Alert Playbook.My questions are:Can an Alert Playbook be triggered directly by a Case Stage change? Is a Case Stage change only evaluated when a new alert enters the case?My objective is:Case moved to Investigation/Research Execute Playbook Create Freshdesk ticket via HTTPv2Any guidance or examples would be greatly appreciated.Thank you.  Google Security Operations Wed, 17 Jun 2026 16:14:38 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/native-markdown-wiki-for-google-secops-7702 Hi everyone, I have a feature proposal that I believe would greatly benefit our workflows.Every SOC team relies heavily on documentation. On any given day, we need quick access to: Playbooks and Standard Operating Procedures (SOPs) Guides and how-tos Internal systems documentation Detailed reporting for major incidents Reference lists The list goes on We all want Google SecOps to truly function as a "single pane of glass" for our analysts. Currently, forcing them to context-switch and jump between SecOps and external tools like Loop, OneNote, Confluence, or an external wiki breaks focus and disrupts the workflow.Implementing a simple, native Markdown-based wiki directly into Google SecOps seems like a straightforward solution with massive benefits. Having all security-critical documentation residing in the primary operational tool would be incredible.Imagine the potential: you could even search and automatically pull relevant internal documentation directly into specific cases and alerts based on tags.I’d love to hear if others are missing this, and if this is something we could see on the roadmap! Google Security Operations Wed, 17 Jun 2026 16:09:01 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/what-the-google-ai-threat-defense-announcement-means-for-secops-7695 Hey everyone, You might have caught our recent announcement introducing Google AI Threat Defense. As attackers increasingly leverage AI to find and exploit vulnerabilities at machine speed, human-speed patching simply can't keep up. The core of the new platform is about moving from a reactive posture to a continuous, autonomous defense. Instead of just generating a massive list of alerts, it actively prioritizes your most critical real-world risks and helps automate the remediation process.But what does this actually mean for those in the trenches running SIEM and SOAR? This shift to an "Agentic SOC" will impact the daily workflows for SOC analysts. And instead of just bolting an AI chatbot onto legacy tools, Google SecOps has specialized AI agents to handle the heavy lifting and manual toil across your operations:Detection engineering agent Triage and Investigation agent Threat hunting agent Agentic automation (combines dynamic AI agents)In particular, our Detection Engineering Agent serves as a compensating control while you determine how to address the wave of vulnerabilities. This agent analyzes diverse input sources (like new threat intel, malware analysis, and offensive tool repositories) to proactively recognize malicious activity. It can automatically extract TTPs, test newly created detections with synthetic events to check for coverage gaps, and draft high-fidelity detection rules in a fraction of the usual time.How are you thinking about AI-driven vulnerabilities? Google Security Operations Wed, 17 Jun 2026 16:01:42 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/how-to-prevent-executing-an-action-without-filling-required-parameters-6604 Analysts are executing an action that I put on a Playbook which requires manual selection from a dropdown list.Main problem is they are sometimes doing it without choosing an option.So I have to prevent this happening, I cant simply blame random analysts.We have only 2 options when i create a manual action from dropdown list. You make that required parameter as MANDATORY. Then you have to give a DEFAULT VALUE when you are implementing it. If you give default value then when it is live, its showing that, action in playbook already filled with your default parameter, just like below image, and you can just press EXECUTE button as an analysts without choosing it. Which we dont want. You make that required parameter as NON-MANDATORY Then when its live playbook will gonna show you a dropdown list, that has “Choose” placeholder on top of it by default.(no real picture but it is just like at “Assign to” option below) Bc the parameter is NOT MANDATORY, then it means it is executable without choosing. Which we dont want :DSo can someone please help what is the solution here ? This is kinda design error, style of this design is conflicting with itselft and allowing human errors. It makes no sense to me that there is no way we can not really force a manual action and make them choose.  Google Security Operations Wed, 17 Jun 2026 15:37:44 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/microsoft-365-defender-integration-7701 Hi All, I am testing the Microsoft 365 Defender (XDR) Integration v26.0 and have observed the following which when looking at the documentation seems to be by design. Scenario 1Event triggered and “Incident 1” created in XDR Event triggered and “Incident 2” created in XDR Both incidents and their associated alerts are ingested into the SOAR and created: Case 1 with the name “Incident 1” Case 2 with the name “Incident 2” XDR then correlated Incidents 1 & 2 and based on a rule and renamed “Incident 1” to “Suspicious activity on one endpoint”  moved the alert from “Incident 2” to “Incident 1” and closed “Incident 2” The Sync Job in SOAR attached all alerts to Case 1 but left the Case name as “Incident 1” The SOAR Case “Incident 2” was left open along with it’s associated AlertScenario 2Event triggered and “Incident 1” created in XDR Event triggered and “Incident 2” created in XDR “Incident 1” ingested into SOAR and a Case created with the same name “Incident 1”  Before Ingestion of “Incident 2” XDR correlated the Incidents based on a rule and renamed “Incident 1” to “Suspicious activity on one endpoint”  moved the alert from “Incident 2” to “Incident 1” and closed “Incident 2” The Sync Job in SOAR attached all alerts to Case 1 but left the Case name as “Incident 1”I am thinking if the Sync Job only handles Alerts then I will probably need to write a Job to Close the orphaned Case in SOAR by checking the status of the Incident in XDR, any thoughts? ThanksDaryll Google Security Operations Wed, 17 Jun 2026 15:32:09 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/delay-between-ingestion-and-create-alert-7716 Hello, team I’d like to understand the delay between when a case is created and when it’s detected. All cases based on CrowdStrike have a delay of 1 to 2 hours before the alert is generated. Can this time be adjusted? Why does this only happen with CrowdStrike? We have two SecOps consoles with different environments, and this delay only occurs on one of them; both have the same collection permissions.   Google Security Operations Wed, 17 Jun 2026 15:24:49 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/how-to-repeatedly-loop-a-playbook-prompt-until-the-answer-is-yes-7740 I am trying to build a SOAR playbook where in I will have a condition block, which if answered “Yes” will continue to the next block, and if ansered “No” that it will repeatedly ask the same question again and again, how do I achieve this ?   Google Security Operations Wed, 17 Jun 2026 15:20:06 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/custom-malware-named-infinitered-yara-l-rules-to-detect-unc6508-7744 Google Threat Intelligence Group (GTIG) has identified a sophisticated campaign attributed to UNC6508, a People's Republic of China (PRC)-nexus threat actor, targeting institutions in the North American academic, medical, and military research community. While remaining undetected for over a year, the threat actor compromised externally facing web applications, deployed bespoke malware, pivoted to sensitive internal systems, and abused enterprise administrative tools for covert data exfiltration https://cloud.google.com/blog/topics/threat-intelligence/prc-targets-us-medical-research?e=48754805 PRC-nexus actors spent 15 months inside US medical research networks. Here's what your SOC should hunt for tonight.Google's threat intel team just published the UNC6508 campaign — and it's a masterclass in patient, quiet espionage against a sector most of us under-monitor: medical research, academic centers, and military health institutions across North America.The tradecraft is the lesson here, not just the IOCs:Initial access via REDCap** — they exploited legacy, unpatched versions of a clinical research platform. Public-facing app, downgrade attack, web shell (`help.php`). Your edge is your attack surace.INFINITERED** — custom PHP malware that *trojanizes the application's own upgrade process* to survive patching. It harvests plaintext credentials straight from login POSTs and hides them inside the legitimate `redcap_sessions` table. Persistence that outlives your remediation is the scariest kind.Living off Google Workspace — once they had domain admin, they didn't drop more malware. They created a silent content-compliance rule (charmingly misspelled "Patroit") that BCC-forwarded emails matching geopolitical/medical keywords to an attacker Gmail. No exfil binary. Just a feature, abused.All-US obfuscation infrastructure — compromised routers, residential proxies, VPS. The login that mattered came from a hijacked ASUS router (23.169.65.49), not Beijing.The takeaway for defenders: persistence is moving into your trusted platforms. A SIEM rule on file hashes is table stakes. The real coverage is detecting abuse of legitimate features — forwarding rules, compliance policies, the app's own update mechanism.I converted the report's indicators and TTPs into ready-to-deploy Google SecOps (Chronicle) YARA-L 2.0 rules — file hashes, the `help.php` web shell, INFINITERED's C2 magic strings, the exfil indicators, and Workspace silent-forwarding abuse. Full ruleset + data tables in the comments. Patch your REDCap. Audit your Workspace compliance rules. Enroll admins in Advanced Protection. Google Security Operations Wed, 17 Jun 2026 01:17:07 +0200 https://security.googlecloudcommunity.com/community-blog-42/beyond-chat-building-an-autonomous-soc-analyst-with-claude-and-the-google-mcp-7421 This blog post was written by guest author, Eliraz Oved.  If you spend your days in the trenches of a Security Operations Center, you already know the struggle: pivoting between screens, writing complex queries, and manually clicking through menus to create rules or check feed health.Recently, Google dropped something that has the potential to completely change this workflow: the Google SecOps MCP (Model Context Protocol) Server, which officially supports Claude.For those new to the term, think of MCP as a universal, open -source API standard that gives AI models secure, structured access to external tools and data sources. Instead of just chatting with a static knowledge base, MCP servers equip the LLM with real-world tools, allowing it to fetch live data, analyze logs, and actively execute commands against backend services.A quick note before we dive in: because MCP is an open standard, you aren't locked into a single AI ecosystem. While we are using Claude (via the Claude Code CLI) for this specific hands-on test, you can absolutely plug this server into other MCP-compatible AI clients to achieve similar results.While we won't dive deep into the initial setup (Google and Anthropic already provide excellent documentation for that), it is crucial to understand the basic architecture and terminology to grasp how this actually works under the hood. The MCP ecosystem relies on a clear separation of concerns: The MCP Host (Client): This is the AI application you are actively interacting with. For our tests, the host is the Claude Code CLI, but it could easily be Claude Desktop or any other compatible client.(Authenticating seamlessly via Google Cloud Application Default Credentials / OAuth)] The MCP Server: This is the lightweight connector program - in our case, the Google SecOps MCP Server. It acts as the bridge, exposing specific SecOps capabilities (tools, resources, and prompts) to the host. The Backend (Data Source): The actual Google SecOps API.  The beauty of this architecture is that the AI Host doesn't talk directly to your environment or hold your API keys. It simply reasons about your prompt and asks the remote (or local) MCP Server to execute the relevant tool against the SecOps backend.Worth noting - this isn't a free-for-all. All MCP traffic is governed by Google Cloud IAM and fully auditable through Cloud Audit Logs. You get visibility into every tool call the AI makes. For organizations that need an extra layer, Google also offers Model Armor, an inline content filter that can scan MCP inputs and outputs for prompt injection, PII leakage, and malicious content. Crucially for enterprise environments, utilizing these APIs ensures your sensitive security data remains within your tenant and is not used to train public LLMs.I decided to take it for a spin to see if we can finally bring the true reasoning capabilities of Claude directly into the SecOps platform. Here is everything I’ve tested so far and honestly, the results are quite impressive. Getting Connected and Assessing the ArsenalFirst things first, getting connected. Once you hook up Claude to SecOps via the MCP, you can easily view your configured MCP servers with the “/mcp” command.  Next, I wanted to see exactly what the AI was capable of doing inside the  environment, so I asked for a full list of available tools. If you're wondering what a "tool" is in MCP terms, it is essentially a function that the AI can call on your behalf. When Claude decides it needs to search your logs, it doesn't scrape a UI, it invokes the udm_search tool with structured parameters, gets a JSON response back, and reasons over the results. Think of it as giving the AI its own API client to your security stack.You can browse and inspect the tools using the /mcp command and selecting the "View tools" option:  Right out of the box, Google isn't holding back. As you can see in the table below, there are currently nearly 70 actions available. We are talking about serious, heavy-lifting capabilities—from basic udm_search and get_ioc_match, to fully operational actions like create_rule, trigger_investigation, and execute_actions. Plus, because it’s MCP, you can add custom content yourself, and Google is continuously expanding this native list as new features are added.  I also set up a CLAUDE.md file - basically a cheat sheet that holds my environment parameters and any other context and preferences to help tailor and shape how Claude works for me (like "do NOT put emojis in my final reports!"). But for actual protection, there's a stronger mechanism: the “allowedTools” configuration, which enforces exactly which tools can run without approval. Together, they tell Claude how to operate in my environment. Set it once, forget about itHaving an arsenal of tools is a good thing, but can a reasoning AI string them together to do real work?. I decided to run two real-world tests: a security investigation and an operational health check. Test #1: The Autonomous Security Investigation & Rule Creation I wanted to see if Claude could act as a Level 2/Level 3 SOC analyst. I gave it a prompt to investigate a specific user for potential brute-force activity over the last 7 days.Instead of asking for a basic log dump, I gave it a multi-step mission: analyze the login behavior, autonomously create and validate a YARA-L detection rule mapped to MITRE ATT&CK based on the findings, and wrap it up with a clear risk assessment.  The Investigation Phase:Claude immediately went to work, querying the SecOps platform. It generated a well-structured investigation report, identifying 7 failed login attempts and 36 successful ones over the last 7 days.Here's where it gets interesting. I deliberately tried to throw it off by generating failed login attempts from multiple different source IPs - mimicking how real attackers use botnets to spread attempts across many IPs and bypass detection rules that only trigger on a single source. I wanted to see if Claude would blindly flag everything as malicious. It didn't fall for it.Instead of just counting failures, Claude actually compared the attacking IPs against the legitimate login sources and identified that all successful logins came exclusively from a different, consistent IP  confirming the failed attempts originated from external sources. It correctly flagged this as a confirmed brute force pattern: 6 failures in 85 seconds from IPs that never successfully authenticated.  The Automation Phase (The "Magic" part):Claude identified the brute force pattern, and as instructed, proceeded with rule creation.But here's the thing - remember the setup I mentioned earlier? This is where it pays off. The CLAUDE.md gives Claude the context - what to do, how to behave - while the allowedTools configuration enforces the boundaries. I defined my read-only tools like "allowedTools": r"udm_search", "list_feeds", "get_rule"], so those run freely. Anything not on the list - like “create_rule” - requires my explicit approval. As you can see in the screenshot, when Claude needed to create the rule, it paused and asked for my go-ahead before proceeding.  Once approved, Claude wrote and deployed a complete YARA-L rule (BruteForce_elirazo_T1110_T1078) mapped to two MITRE ATT&CK techniques, with a 10-minute sliding window and HIGH severity. It also validated the rule, confirmed compilation succeeded, and even recommended immediate next steps, like resetting the user's credentials and blocking the attacking IPs.The whole thing, from investigation to a live detection rule, took under two minutes and started with a single prompt.Not only did Claude write a flawless YARA-L rule (BruteForce_elirazo_T1110_T1078), but it actually created and deployed the rule directly into the SecOps platform. I jumped into the Google SecOps Web UI to verify, and sure enough - the rule was sitting right there, perfectly configured.  It is possible to configure your MCP client to auto-approve a wider set of actions, but I would caution against full autonomy. While this worked extremely well in a controlled investigation, there are clear boundaries where human judgment is non-negotiable. Anything that involves privilege escalation, user suspension, or destructive remediation still requires a human in the loop. The entire process above was done via AI with minimal human intervention — the only manual step was approving the rule creation when Claude asked for my go-ahead. MCP doesn't remove accountability — it forces you to be explicit about where judgment still matters. Test #2: The SecOps Infrastructure Health Check In order to hunt bad guys with SecOps, you need to ensure your logs are actually flowing. I asked Claude to run a health check on all my SecOps feeds for the past 7 days, requesting a neat summary table and a final verdict. Prompt:Run a health check on all my SecOps feeds for the past 7 days. For each feed show me a single summary table with:- Feed name- Log type- Current status (running/failed/stopped)- Last successful run time- Any errors or warnings in the last 7 days- Data volume trend (normal/low/high compared to average)Flag any feed that has issues - failed runs, missing data, or unusual volume drops. At the end give me a one-line verdict: healthy / needs attention / critical.Keep it short and to the point, no fluff. Claude parsed the data and handed me exactly what I asked for: a clean, no-fluff table. It successfully identified 10 healthy feeds and flagged exactly one issue: a test feed (CYBERARK_IDENTITY_AUDIT) that was configured and listening, but had received zero events in 7 days.  The accuracy was spot on, saving me the tedious task of manually clicking through the ingestion pipeline dashboard to check each feed individually.And it accomplished this in seconds, proving that the AI doesn’t just make decisions for me,it drastically reduces the manual data-gathering phase so I can make those decisions confidently and quickly.What’s Next? After seeing how well SecOps performed on its own, I wanted to push things further. I hooked up two additional MCP servers - GTI (Google Threat Intelligence) and SCC (Security Command Center) - to see if Claude could orchestrate a cross-platform threat hunt across all three,using a single prompt.   Now when we run the /mcp command, we can see more MCP servers were added.  Test #3: The Holy Grail – A Cross-Platform Threat Hunt I mentioned earlier that I didn't want to stop at just SecOps. I hooked up two additional MCP servers: GTI (Google Threat Intelligence) and SCC (Security Command Center).My ultimate goal was to see if Claude could orchestrate a massive, multi-platform threat hunt across all three tool sets simultaneously, using a single prompt.I decided to target APT28 (Fancy Bear). I gave Claude a highly structured, 5 step mission:GTI: Gather Threat Intel (IOCs, malicious IPs, domains, TTPs). SecOps: Take those exact IOCs and run a 30-day retro-hunt in Chronicle SIEM. SCC: Check Cloud Security Posture for active findings exploitable by APT28 TTPs. Correlation: Connect the dots across all three platforms. Executive Summary: Give me a final threat level, immediate actions, and hardening steps.Prompt:I want a cross-platform threat hunt combining all available security tools. Target: APT28 (Fancy Bear) threat group.Step 1 - Threat Intelligence (GTI):Look up APT28 / Fancy Bear and find known IOCs - malicious IPs, domains, file hashes, TTPs.Step 2 - SecOps Hunt (Chronicle SIEM):Take the IOCs from step 1 and search for any matches in our SecOps environment over the last 30 days. Check network connections, DNS queries, file events, and authentication logs.Step 3 - Cloud Security (SCC):Check Security Command Center for any active findings or vulnerabilities that could be exploited by the TTPs associated with APT28. Look for misconfigurations, exposed services, or suspicious activity.Step 4 - Correlation:Connect the dots between all three sources. Are there any overlapping indicators? Any SCC findings that align with APT28 TTPs?Step 5 - Executive Summary:Give me a short, clear report:- Threat level for our environment (Critical/High/Medium/Low)- Key findings from each source- Immediate actions needed (if any)- Recommended hardening steps If the previous tests were impressive, this one blew me away. Claude didn’t just summarize text; it acted as an autonomous Tier-3 Threat Hunter, querying each system sequentially and building a comprehensive report. Step 1: Threat Intelligence (GTI)Claude successfully queried GTI, pulling a detailed profile on APT28 (GRU Unit 26165). It extracted known TOR exit nodes, typosquatted domains, malicious file hashes, and mapped out 188 MITRE ATT&CK techniques associated with the group.   Steps 2 & 3: SecOps Hunt & SCC PostureNext, it took those IOCs and hunted for them in Chronicle SIEM over the last 30 days. The result? Zero direct IOC matches. It then checked SCC, which also came back clean with zero critical or high vulnerabilities. In a traditional SOC, a junior analyst might stop here and close the ticket.  Step 4: The Correlation MagicThis is where the true power of an integrated AI shines. Even though there were no direct IOC matches, Claude took APT28’s known TTPs and looked for behavioral overlaps in my open SecOps cases.It flagged uninvestigated cases involving powershell_base64_encoded_iex and firewall rule modifications. While not explicitly tied to APT28's infrastructure, these perfectly align with their known Defense Evasion playbooks.But it went a step further: it noticed that all 11 of these open cases had a workflowStatus: FAILED. The AI didn't just hunt threats; it identified that my SOAR automation was broken, leaving these potentially critical cases completely untouched.  Step 5: The Executive Summary & Action PlanFinally, Claude wrapped the entire cross-platform hunt into a beautiful executive summary. It assessed the environmental threat level as "MEDIUM" - noting that while there is no active compromise, the broken automation and uninvestigated PowerShell cases introduce significant contextual risk. It gave me a prioritized list of immediate actions (Priority 1: Fix broken SOAR workflows and triage the PowerShell cases) and mapped out specific hardening steps to defend against APT28's TTPs.   The fact that Claude orchestrated this multi-stage hunt, cross-referenced the intelligence, identified a broken internal SOC process, and generated an executive action plan-all in a matter of minutes,is a quantum leap in operational efficiency. Final Thoughts: Moving Beyond "Chat"Testing the Google SecOps MCP server, especially when combined with GTI and SCC, proves that we are entering a new era of Security Operations.And this article barely scratches the surface. We didn't even get to test parser creation, feed management, SOAR playbook automation, or dozens of other tools sitting in that 70-tool arsenal. That's material for future articles, the point is, the capabilities are already there, waiting to be explored.We are officially moving away from treating GenAI as just a 'chatty assistant' that helps write regex or query syntax. With MCP, the AI becomes an active, integrated operator. It can autonomously investigate alerts, correlate threat intel across platforms, identify broken internal processes, and even write and deploy detection rules directly into the environment — and much more.That said, AI is not replacing the SOC team. It's giving them superpowers. Every finding still needs human judgment, every rule still needs analyst validation. The difference is that the tedious legwork happens in seconds instead of hours.A practical note on cost and efficiency: I used Claude's higher-effort mode for complex multi-step investigations, and switched to standard mode for quick queries like feed health checks. Matching the model's effort level to the task complexity keeps things fast and cost-effective.If this is just the beginning of MCP integrations in SecOps, the future of the autonomous SOC is a lot closer than we think.    Community Blog Tue, 16 Jun 2026 23:55:56 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/tuesday-s-tip-of-the-week-udm-one-schema-to-hunt-them-all-7743 Week 1: UDM: One Schema to Hunt Them All Why Normalization Matters Every security tool speaks its own language. Windows Event Logs call it "LogonType," Okta calls it "eventType," and GCP calls it "methodName." Hunting across all three means memorizing three schemas, writing three queries, and maintaining three sets of detection logic. Google SecOps solves this with the Unified Data Model (UDM), a single normalized schema that every log source maps into on ingestion.When a Windows logon event (Event ID 4624), a GCP IAM authentication, and an Okta user.session.start all arrive in SecOps, they are each normalized to metadata.event_type = "USER_LOGIN". One query catches all three. The UDM Noun Groups Every UDM event is structured around noun groups. Each group describes a different participant or aspect of the event.Noun Group What It Describes Example Fields metadata Event classification and timing metadata.event_type, metadata.log_type, metadata.product_event_type, metadata.event_timestamp principal The actor initiating the event principal.user.email_addresses, principal.user.userid, principal.ip, principal.hostname target The entity being acted upon target.resource.name, target.resource.resource_type, target.user.userid, target.ip src The original source (when relayed) src.ip, src.hostname observer The device or sensor that reported the event observer.hostname, observer.ip, observer.asset_id intermediary Proxies or load balancers between principal and target intermediary.ip, intermediary.hostname about Additional referenced entities about.file.sha256, about.url, about.ip network Network-level details network.direction, network.ip_protocol, network.application_protocol security_result Verdicts and actions taken security_result.action, security_result.severity, security_result.category extensions Product-specific fields extensions.auth.type, extensions.vulns.vulnerabilities  Key Fields You Will Use Constantly Metadata fields classify the event:metadata.event_type: The normalized action. Common values include USER_LOGIN, NETWORK_CONNECTION, PROCESS_LAUNCH, FILE_CREATION, USER_RESOURCE_ACCESS, STATUS_UPDATE, RESOURCE_CREATION, and USER_RESOURCE_UPDATE_PERMISSIONS. metadata.log_type: The source product. Examples: GCP_CLOUDAUDIT, WINDOWS_AD, OKTA, AZURE_AD, CS_EDR, WORKSPACE_ALERTS. metadata.product_event_type: The raw event name from the source (e.g., "google.iam.admin.v1.CreateServiceAccountKey"). metadata.event_timestamp: When the event occurred.Principal and target fields describe who did what to whom:principal.user.email_addresses / target.user.email_addresses: Email of the acting or target user. principal.user.userid / target.user.userid: User identifier. principal.ip / target.ip: IP addresses involved. principal.hostname / target.hostname: Hostnames involved. target.resource.name: The specific resource acted on (e.g., a GCP project, a secret, a VM). target.resource.resource_type: The type of resource (e.g., "STORAGE_BUCKET").How Normalization Works in Practice Consider these three raw events from different sources:Windows AD: Event ID 4624, LogonType=10, TargetUserName="jsmith" GCP IAM: methodName="google.cloud.identity.v1.SignIn", principalEmail="jsmith@company.com" Okta: eventType="user.session.start", actor.alternateId="jsmith@company.com"After ingestion, all three become UDM events with metadata.event_type = "USER_LOGIN". The user identity maps to target.user.userid or principal.user.email_addresses depending on the noun role. This means a single query or detection rule covers all authentication sources. Google Security Operations Tue, 16 Jun 2026 23:19:28 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/help-needed-in-verifying-alerted-ip-not-in-gcti-7550 Hello Team,I am writing a rule to detect unknown IPs hitting our public-facing domains. In this rule, I only want to generate an alert when the source IP is not present in GCTI.The reason is that we already have a separate rule that handles IPs found in GCTI, so I want to avoid duplicate detections.Could someone please advise on the best way to implement a “NOT IN GCTI” condition within the rule?Is the below approach the correct way to verify that the principal IP generating the alerts is not present in GCTI? Also, is using the join with entity.ip the correct method for this check?  Google Security Operations Tue, 16 Jun 2026 23:14:57 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/how-entities-are-grouped-with-source-grouping-identifiers-953 I'm trying to better understand how grouping by identifiers works for entities and origins.https://cloud.google.com/chronicle/docs/soar/investigate/working-with-alerts/alert-grouping-mechanism-adminFrom the documentation, I understand that by enabling this feature, alerts in SIEM will be grouped from a sourceGroupIdentifier. The question here is, how is this identifier defined from SIEM alerts?Is this identifier created based on the SOAR ontology rules? If I want to create a grouping based on some field present in the result of my detections, is that possible? Google Security Operations Tue, 16 Jun 2026 23:12:17 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/masking-of-data-7689 I want to mask my client data like phone number account number etc. Is it possible to mask these data field in Secops. If yes then kindly share the related document how it can be done. If no then kindly share any alternative for this. Google Security Operations Tue, 16 Jun 2026 22:57:44 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/entity-related-alerts-via-udm-and-rest-api-7694 Hi,Could anyone help me to fetch alert detections (custom as well as curated) of a specific entity from case using UDM Search Query and REST API?So that I can display it on the case overview.   Google Security Operations Tue, 16 Jun 2026 22:48:50 +0200 https://security.googlecloudcommunity.com/community-blog-42/leveraging-agentic-secops-migration-helper-to-accelerate-siem-migration-7742 Author :Vesselin Tzvetkov, Principal Security Engineer and Security Advisor  SIEM migrations are difficult tasks that take significant resources and time to conclude, as companies often accumulate thousands of custom rules on SIEM systems like ArcSight, QRadar, Splunk, and Azure Analytics. It is logical to ask: can we automate this migration? This blog will guide you through practical tools and approaches for automating rule migration.Migration is a huge undertaking, and here we will focus only on existing rule migration. If you want to see a holistic view covering ingestion, parsers, and playbooks, please look at SIEM Replacement | Google Cloud, SIEM migration guide | Google Cloud, and the Next ‘26 Solution session: SecOps large scale migrations steps and leveraging GenAI to accelerate. A translation of existing rules in YARA-L  generally consists of the following steps, and I will show you how to leverage an AI helper to execute them:  Mapping existing customer rules to SecOps curated detections. There are thousands of curated detection rules available. Leveraging these instead of migrating custom rules is a huge benefit, as curated detections are managed by Google, saving you the operational overhead of maintaining custom logic. Translating existing rules to YARA-L. After selecting the rules that need to be migrated, you must translate the existing logic into YARA-L syntax. Annotating the rules. Once the logic is generated, you should add comments so that analysts understand the origin of the rule and how to tune and test it. Generating synthetic logs for testing. You will need sample logs to verify that the rule triggers according to its intent. While testing with real log samples is best, you can generate synthetic ones if real samples are unavailable. This process can be integrated into a CI/CD pipeline. Validation and fine tuning. Validation and fine tuning depending on your needs. This is out of scope of this blog.   Rules migration steps overview Let us now dive into the stepsSetup  You have multiple options for executing these steps. I will walk you through the two main approaches and how to prepare for them.Google SecOps Labs SecOps Labs provides helpers to translate rules, map detections, and create parser extensions; for more details, see Building Towards an Agentic SOC: Introducing SecOps Labs. This approach is ideal if you have a limited number of rules and prefer using a UI. SecOps AI Migration HelperThe SecOps AI Migration Helper, part of the SecOps-Toolkit, is an open-source, community-driven solution. This CI/CD-driven approach uses the Antigravity CLI (or alternatively the Gemini CLI) to execute every step of the process. It automatically creates a file structure, annotated rules, and synthetic logs ready for your pipeline, and leverages an MCP server to validate the rules. The SecOps AI Migration Helper significantly increases the speed of the migration process by minimizing technical complexities and automating repetitive workflows. While these tools automate repetitive tasks, they don't replace the need for careful human validation. When you gain experience with tools with few rules, you can easily modify the logic to execute batch processes tailored to your specific use case. To get started, clone the SecOps-Toolkit repository and follow the instructions in the README.md to configure your SecOps development instance and Gemini access.The repository also includes a demo set of rules in Microsoft KQL, SPL, QRadar, and ArcSight to help you familiarize yourself with the tool. See source rules at ./blueprints/secops-ai-migration-helper/migration_rules and migration rule output samples at ./blueprints/secops-ai-migration-helper/rules. Familiarize yourself  with Antigravity CLI skills in blueprints/secops-ai-migration-helper/.agents/skills  (Gemini CLI blueprints/secops-ai-migration-helper/.gemini) since you may want to adapt it to your use cases. Here are some key elements of the SecOps AI helper:  As more rules are migrated, the knowledge base of the tool increases and migration becomes more accurate since it uses the repository as its knowledge base.  The tool is flexible by understanding different formats of rules from a SIEM. It is not limited to certain languages or syntax. The AI helper operates in clearly defined small steps, each with specific inputs and outputs. After you tune it to your environment, you can run all steps at once; see Tune the skills/commands to your use case. A SecOps Analyst (Human in the loop) validates the output after every step. For example: formatting an original rule, then manual visual validation, then adding comments, etc. A general all-in-one approach without tuning to your environment (e.g. migrating everything without considering human validation and equivalence to curated rules) is counterproductive. Mapping existing custom rules to curated detectionsThe input typically consists of the description and logic of existing rules written in SPL, KQL, etc., often in common formats like CSV, MD, TXT, JSON, or DOCX. The output provides clear information on which curated detections offer the same coverage as the input rules. Note that you can enable rulesets and not individual rules.  SecOps AI Migration HelperThe tool downloads available curated detection rules and rulesets from your development SecOps instance's Content Hub, including descriptions and logic. If a rule is not available on your SecOps it will not be considered. It then compares this logic to your provided rules one by one to determine coverage. The output is a table providing clear recommendations and technical justifications for replacing custom rules with Google-managed curated detections. Here are the steps to follow:  Set up your environment variables to point to your development instance as described in blueprints/secops-ai-migration-helper/recommender_curated_community/README.md Place your original rules in CSV, Markdown, or any other common format in the working folder. A sample is provided at and the format is not mandatory ./secops-ai-migration-helper/recommender_curated_community/resources/sample_unstructured_input.csv Change the working directory of AI helper blueprints/secops-ai-migration-helper  Using the Antigravity CLI (or Gemini CLI), execute the command migration_helper_extract <file_path>. This will extract the rules into a structured JSON file located in the work_dir folder. For every rule, it will extract the use case ID (UCID), title, description, and logic.  Overview Anigravity CLI steps migration_helper_extract  Run migration_helper_recommend <file_path>, pointing to the JSON output from the previous step. This process takes a few minutes as it downloads curated detections and evaluates your rules. The resulting recommendation tables will be saved in the work_dir folder. Review these three tables for detailed insights: recommendation_curated_community.json is a JSON file with recommendations. For every provided rule, the following values are included:  Ucid: A unique identifier string from the provided rules  Title: Title of the rule extracted from the rule definition Description: Description of the rule extracted from the rule definition curated rules: A comma-separated list of curated detection rules that provide coverage in the format category/ruleSet/Rule curated rules coverage: A qualitative assessment rating (no|partially|very good) curated rationale: The technical justification community rules: A comma-separated list of community rules community rules coverage: A qualitative assessment rating (no|partially|very good) community rationale: The technical justification curated_community_recommendation.csv is a CSV file with recommendations suitable for a table view recommendation_curated_rulesets.csv is a CSV with recommended rulesets suitable for a reverse lookup (i.e., which rulesets are recommended for the rules in the batch). An example of the initial recommendation table highlighting curated detections is shown below; notably, similar insights are also generated for community-based rules. You can find a detailed sample within the blueprints/secops-ai-migration-helper/recommender_curated_community/resources directory. Here an example: Sample output recommendation SecOps curated detention rulesGoogle SecOps Labs - Curated Detection Threat Mapping If you possess specific knowledge regarding the MITRE ATT&CK techniques and tactics associated with your legacy rules, you can utilize the Curated Detection Threat Mapping capabilities. This process is further explained in the Building Towards an Agentic SOC: Introducing SecOps Labs community post.Rule Logic Migration This phase encompasses the technical generation of YARA-L logic, the systematic annotation of rules for clarity, and the creation of synthetic logs for validation purposes. SecOps AI Migration HelperFollow the following step in order to translate the rule. Upload the rules designated for migration into your CI/CD repository. You can find samples in blueprints/secops-ai-migration-helper/migration_rules if you want to just prototype. The input format is flexible; the Agent is designed to recognize and structure various logic types, including KQL, SPL, QRadar, and ArcSight. It will need finding the skill if this syntax is not generally recognizable.   Invoke the migration process within the Antigravity CLI by running: /migration_helper_migrate_rule <input rules>For example: /migration_helper_migrate_rule blueprints/secops-ai-migration-helper/migration_rules/demo_kql_9103.md. These commands execute multiple small steps, namely (prefix migration_helper_): init, format, generate_rule, generate_log, author_notes.  You will potentially need to tune the skills/commands to your use case,see chapter later the document. The finalized output assets will be organized within the specified folder hierarchy including the YARA-L rule and folder with sample logs NOTE: You still need to manually fill in some metadata, validate and improve the rule logic; consider this AI tools output as a suggestion. An example folder for example: Directory overview of sample newly migrated ruleYou can execute an optional step: /migration_helper_validate <new_rules_name>. This will validate the rule using an MCP server on your SecOps instance. Example of a rule migration output before Analyst improvements:  Sample newly migrated rule in YARA-LExample of synthetic logs:  Sample synthetic log Tune the skills/commands to your use caseEvery migration is different and it is very important to adapt the Antigravity CLI skills in blueprints/secops-ai-migration-helper/.agents/skills  (Gemini CLI blueprints/secops-ai-migration-helper/.gemini) to your particular use case. Take several sample rules from your SIEM from different product types (e.g. EDR, WAF etc.) execute all steps one by one, see README.md field for steps descriptions,  and manually validate the output of each step. Adjust the command arguments accordingly until you get the desired output. After this, start the batch migration of the rules using the command /migration_helper_migrate_rule. Google SecOps Labs - Rule Translator You can leverage the Rule Translator Lab to translate your existing rules from SPL and KQL to YARA-L. Then, you will need to annotate them, collect logs, and place them in the correct location in the CI/CD pipeline, see Building Towards an Agentic SOC: Introducing SecOps Labs  SecOps Labs - Rule Translator   Community Blog Tue, 16 Jun 2026 22:13:58 +0200 https://security.googlecloudcommunity.com/community-blog-42/connecting-google-security-operations-and-cribl-search-7741 Blog Authors:Sumit Patel, Regional Security Architect, Google CloudKajan Moorthy, Staff Solutions Engineer, Cribl  In a perfect world, every security log would be indexed, searchable, and instantly available in your SIEM. In the real world, data is fragmented across cloud buckets, cold storage, and remote endpoints. Moving all that data just to see if it’s "interesting" is often too slow and too expensive.By using Google SecOps SOAR as the orchestration brain and Cribl Search as the remote query engine, analysts can hunt for threats across their entire infrastructure without moving a single byte of data until they need it.Where Cribl and Cribl Search FitCribl is a telemetry data platform built to help IT and security teams collect, transform, route, store, and analyse telemetry with more flexibility and less operational overhead. It also gives teams the ability to route data to multiple destinations at once, so they can send the right data to the right tools without duplicating collection pipelines. Rather than forcing every log into a single expensive analytics tier, Cribl lets teams control where data lives, keep it in open formats, and access it across different storage and analytics environments.Cribl Search is a unified search experience for telemetry data, combining high-speed search over data in Cribl with federated search across data where it already lives. For this workflow, the federated engine is what matters: it queries data across object storage, data lakes, APIs, and more without moving or rehydrating it first, making it an ideal remote query layer for Google SecOps.Why Cribl Search with Google SecOps?From a Google SecOps perspective, this integration helps customers with disparate data silos tackle the "Last Mile" visibility problem. By federating search, the SOAR platform becomes a unified command center for investigations that span data inside and outside the SIEM. Instead of pivoting between consoles, an analyst stays within their Case Wall, using automation to pull exactly what they need from remote sources like S3, Azure Blob, or edge devices.Step 1: Building the Bridge in the SecOps IDEWhile Google SecOps offers hundreds of out-of-the-box integrations, the SecOps IDE (Integrated Development Environment) is where the magic happens for custom workflows.Using Python and the custom IDE, we built an integration for the Cribl Search API. This allows us to handle authentication, submit complex search strings, and—most importantly—manage the asynchronous nature of remote searches.The source code for the custom Python integration is available at https://github.com/acidack/secopscriblintegration. For those seeking a codeless alternative, Google SecOps also provides an out-of-the-box HTTPv2 integration. My colleague Mike Wilusz has detailed this approach in his blog post, "Searching Cribl Lake data with Google SecOps SOAR: a codeless guide".Step 2: Create the User Input Form (Instruction Step)We start by creating a way for the analyst to provide their query. Action: Search for "General Question" in the Step Selection. Configuration (Parameters): Question: Type: What is your Cribl Search query? Answer Type: Select Free Text. This creates the input box for the analyst. Settings Tab: Set the Action Type to Manual and assign it to gnContext.User]]. Step 3: Submit the Search to CriblNow we pass that analyst-provided query to the API. Action: Submit Search (or your custom HTTPV2 'Post' action). Mapping the Variable: In the Body field of the action, use the dynamic variable from the previous step:  Step 4: The "Wait" LogicFederated searches aren't always instant. We need the playbook to be "patient." Action: Add a Delay Playbook v2 step  Logic: Set the playbook to wait on a specified time e.g. 30 seconds.  Alternatively, you can set Retry on failure on the Run Search block. Step 5: Retrieve and Transform (JSON to HTML)Raw JSON from a search engine is often deeply nested. If you tried to put this directly into a table, columns would be missing or unreadable. Action: Unflatten JSON (part of the Tools integration). Why it matters: This step takes complex, nested JSON objects and "unpacks" them into a flat structure. This ensures that every field in the log (like source IP, event ID, or timestamp) is ready to be mapped as a clean column in the next step.   Step 6: Creating the InsightThis is the final step where the data becomes "human-readable." Instead of a simple table tool, we use the Template Engine to build a custom HTML view using Jinja2 syntax. Why Jinja? It allows us to use logic (like if statements or for loops) to highlight specific results. For example, we can color-code high-priority IP addresses or format timestamps. The Output: The Template Engine takes our unflattened data and renders a clean HTML table, which is then automatically posted as an Insight on the Case Wall.   Note: The Jinja2 template script is also available in the same GitHub repository.The end result is a clean table in your case Overview tab showing the results By following this "Codeless" approach, you are effectively creating a Dynamic Search Interface within your SOAR. The Analyst provides the intent (The Query). The Playbook provides the muscle (API calls and Polling). The Platform provides the evidence (The Insight Table). Step 7: Advanced Workflow Logic (Conditional Logic & Context)Analysts can further refine their playbooks by incorporating advanced logic to handle diverse security scenarios. This is primarily achieved through conditional statements and sophisticated context management. Branching Logic: By using Flow steps like Multi-Choice Questions, you can create divergent paths based on analyst decisions or automated conditions. For example, if an analyst confirms a threat (Yes), the playbook can proceed with high-threshold VirusTotal enrichment and automated UDM queries. Context Management: A critical component of these workflows is the Append to Context Value action. This allows the playbook to store specific data points gathered during an investigation—such as discovered IP addresses or user roles—as persistent context within the case. Cross-Alert Availability: Once data is appended to the context, it becomes accessible to all subsequent steps in the playbook and can even be shared across different alerts within the same case, ensuring a unified investigati  Conclusion: Faster Responses, Smarter DataBy combining Google SecOps’ orchestration with Cribl’s search-in-place capabilities, we’ve reduced the "Time to Answer" for complex investigations. Analysts no longer wait for ingestion—they just ask the question and get the answer.  Community Blog Tue, 16 Jun 2026 21:15:55 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/servicenow-integration-test-connectivity-failing-user-not-authorized-7739 Hi All,I am configuring the ServiceNow integration in Google SecOps / Chronicle SOAR, and the Test Connectivity action is failing with the following error:Exception: User Not Authorized----------------- Main - Finished -----------------status: 2result_value: Falseoutput_message: Connection Failed. Error is User Not AuthorizedFrom the logs, the integration appears to be trying to access the incident table using:GET https://<masked-instance>.service-now.com/api/now/v1/table/incident?sysparm_limit=1The response is:403 Client Error: ForbiddenMy current configuration is:API Root: https://<masked-instance>.service-now.com/api/now/v1/Incident Table: incidentAuthentication: <Basic/OAuth>Integration Version: ServiceNow V58.0The credentials seem to be accepted, but the user appears to be blocked by permissions, roles, or ACLs when trying to read the incident table.Has anyone faced this issue before? Which ServiceNow roles or ACLs are required for the integration user to successfully pass Test Connectivity?Any guidance would be appreciated.Thanks!  Google Security Operations Tue, 16 Jun 2026 10:23:19 +0200 https://security.googlecloudcommunity.com/webinars-75/prompt-injection-to-playbook-detecting-compromised-ai-agents-in-google-cloud-7736 In this webinar, Security, SecOps and AI Expert, Dave Nehoda, focuses on the critical security risks associated with deploying AI agents in Google Cloud Platform (GCP). Specifically, highlighting how prompt injection attacks can be leveraged to hijack an agent's GCP service account, leading to full infrastructure compromise and data exfiltration. The session provides a comprehensive blueprint for a 4-layer defense architecture using Model Armor, GCP Cloud Logging, Google SecOps, and SOAR to detect anomalous agent behavior and automatically contain threats in minutes. What You Can ExpectIn this webinar, you can expect to learn how to: Understand the true threat of prompt injection and how it acts as an infrastructure vulnerability that allows attackers to hijack service accounts and their IAM permissions. Minimize the blast radius of compromised AI agents by implementing critical IAM best practices, such as using dedicated service accounts, avoiding project-wide roles, and utilizing short-lived credentials. Build a robust 4-layer defense architecture that leverages Model Armor (Prevention), Cloud Logging (Evidence), Google SecOps (Correlation), and SOAR (Automated Response). Avoid the "silent failure" in logging by properly configuring GCP Data Read audit logs to ensure malicious credential exfiltration doesn't remain invisible to your security tools. Detect sophisticated attacks that bypass prompt screening by shifting your security focus to monitor anomalous agent behavior rather than just analyzing the prompt content.   Key Discussion Points & Timestamps 13:32 - Session Overview: Introduction to "Prompt Injection to Playbook: From Detection to Containment in Minutes". 14:15 - Why This Matters: The reality of AI agents as infrastructure and the true risk of prompt injection. 16:53 - Real-World Compromises: Review of recent AI incidents (Echo leak, ServiceNow, RAG poisoning, Meta/Instagram). 21:26 - The Attack Chain: Breaking down how a prompt injection escalates into full service account takeover. 25:06 - IAM Best Practices: Five critical rules for securing AI agent identities in GCP. 28:25 - The 4-Layer Architecture: Overview of Model Armor, Cloud Logging, SecOps, and SOAR layers. 32:50 - Logging Prerequisites: The crucial need to enable "Data Read" access logs for Secret Manager and other APIs. 35:16 - SecOps Detection Rules: How to use YARA-L and data tables to build scalable, behavioral detections. 38:22 - Live Demo Setup & Obvious Injection: Showcasing a live GCP agent and how Model Armor flags an obvious attack. 42:37 - Live Demo Sophisticated Injection: Bypassing Model Armor to successfully exfiltrate Stripe API keys and DB passwords. 45:39 - Live Demo SecOps Detection: How the YARA-L rule successfully catches the anomalous API call. 50:39 - Live Demo SOAR Containment: Executing the playbook to instantly disable the compromised service account.    Webinars Mon, 15 Jun 2026 22:55:37 +0200 https://security.googlecloudcommunity.com/google-security-operations-66/adoption-guide-accelerating-soar-a-practitioner-s-guide-to-the-gemini-playbook-assistant-in-google-secops-7732 Authors:Bernie Weidel, Security Advisor, Google Cloud SecurityIvan Ninichuck, Google Cloud, Technical Solutions Engineer Introduction:Security Orchestration, Automation, and Response (SOAR) has long promised to alleviate alert fatigue and streamline incident response. However, for many Security Operations Centers (SOCs), the reality of SOAR adoption involves a steep learning curve. Building effective playbooks traditionally requires a deep understanding of proprietary visual editors, JSON payload parsing, and API data structures.The introduction of the Gemini playbook building assistant in Google SecOps fundamentally shifts this paradigm. By leveraging Google’s security-tuned Large Language Models (LLMs), security engineers and analysts can now translate natural language intent directly into functional, complex automation workflows.This technical adoption guide provides a blueprint for experienced Google SecOps users to operationalize the Gemini playbook assistant, transition away from manual workflow authoring, and scale their automated response capabilities. Use case examples: The Strategic Edge: Moving from Code to IntentTransitioning to AI-assisted playbook generation is not just a UI update; it is a strategic shift in how a SOC operates. Understanding the core benefits is crucial for justifying the adoption of this new workflow. Accelerated Time-to-Value: Building a playbook with dozens of conditional branches and enrichment steps manually can take hours or days. Gemini reduces the initial draft phase to seconds, allowing engineers to focus on logic refinement rather than drag-and-drop configuration. Lowering the Engineering Barrier: Tier 1 and Tier 2 analysts who intimately understand the logic of incident response—but perhaps lack the software engineering background to build complex integrations—can now author their own automation flows using natural language. Automated Integration Mapping: One of the most significant technical hurdles in SOAR is knowing exactly which integration action to call. Gemini intelligently parses your prompt and automatically selects the most appropriate actions from the specific custom and commercial integrations you have already installed and configured in your environment. Seamless Iteration: Threat actor tactics change rapidly. The ability to use the "Edit Playbook with Gemini" feature allows teams to conversationally update workflows—such as swapping a firewall integration or adding a new conditional check—without rebuilding the flow from scratch. Technical Walk-Through: Building with GeminiTo successfully generate playbooks, you must understand how Gemini interacts with the underlying Google SecOps architecture. Playbooks are fundamentally constructed of Triggers (the initiating event), Actions (operations like data enrichment or isolation), and Flows (conditional logic branching).Here is the step-by-step technical workflow for generating playbooks with Gemini. Step 1: Environment Preparation (The Prerequisite)Gemini cannot hallucinate integrations into existence. It is strictly bounded by the integrations configured in your Google SecOps environment. Navigate to the Marketplace or your IDE module. Verify that the required integrations (e.g., VirusTotal, Active Directory, specific EDRs like CrowdStrike or SentinelOne, and firewalls like Palo Alto Networks) are installed, configured with valid credentials, and enabled. Step 2: Initiating the Playbook Navigate to Response > Playbooks within the Google SecOps console. Click the Add (+) button and select Create Playbook. Define the administrative boundaries: Select the target folder for organizational purposes and bind the playbook to the specific Environment (or Environment Group) it applies to. Click Create. Step 3: The Generation Phase In the newly created playbook canvas, bypass the manual trigger setup and click Create Playbook with Gemini. A prompt pane will appear. Here, you will input a structured prompt detailing your intended workflow (see Section III for prompt engineering best practices). Click Generate Playbook. Gemini will process the request and render a visual preview of the Triggers, Actions, and Flows. Step 4: The Refinement PhaseAI generation is a collaborative process. The initial output serves as a high-fidelity draft. Review the Data Mapping: Click into the generated Action blocks. Verify that Gemini has correctly mapped the data arrays (e.g., ensuring the parameter is correctly feeding into the VirusTotal enrichment step). Iterative Editing: If the logic needs tweaking, do not discard the playbook. Click Edit Playbook with Gemini. You can issue targeted commands such as: "Replace the existing firewall action with a block action for Checkpoint Firewall." "Add a flow step before the block action to check if the user is in the 'Domain Admins' group." Provide Feedback: Use the Thumbs Up/Thumbs Down icons to provide feedback, which helps tune the model's future performance for your environment. Step 5: Testing and Deployment Click Create Playbook to commit the generated draft to your environment. Never deploy a new automated response block directly to production. Ensure the playbook is toggled to an inactive state. Utilize the Playbook Simulator feature. Run the new Gemini-generated playbook against historical or simulated cases to verify that conditional branches execute as expected and that no unintended destructive actions (like isolating a critical server) occur. Once validated, toggle the playbook to Active. Example PlaybookPrompt:"Generate a playbook that triggers on a CrowdStrike malware alert. Automatically isolate the affected endpoint from the network. Extract the file hash and check it against Mandiant Threat Intelligence. Send an email notification to the security team containing the endpoint hostname, the file hash, and the Mandiant intelligence report. Inspection: Trigger The custom trigger will not result in the playbook being triggered. This is because ProductName for all rules coming from Google SecOps have the ProductName of Rules. In this instance a generic trigger was created using the specified alert source.  Correction: Manually change it Trigger should include Event.event.metadata.product_type = CrowdStrike Inspection: Crowdstrike Contain Endpoint The field Customer ID is not required. The action is made to run on all ip and hostnames automatically. In this configuration it will run on all hostnames which is the best practice setting ( but not the default). Also note that the “Fail if Timeout” option is checked. Here I have hovered over the “i” icon to find out what this means. So leave this checked if you want the action to fail if the endpoint is not contained. This would stop the playbook from executing further steps and require analyst intervention. I personally would not choose this option. Instead I would add a condition that provided the analyst a manual action to check the playbook. But either will provide a notification.   Correction:Remove the customer_id value Inspection: Mandiant Threat Intelligence Report and Email BodyThis next part is where Gemini really shines. The prompt specifically instructed gemini to take the report and prepare it and important information for an email. By using context values Gemini takes all the important information from the action and puts it into a structured email response. I will include some of the context values to show how they are set. The final email action then just requires a very convenient single script result reference rather than being manually typed in. Now Gemini could have referenced the context values as instead of using the script results. But we usually do this just to save time building the playbook. In fact because of Gemini’s speed this shortcut is not needed. I just wanted to point out the alternative method.     Gemini Editing: In order to further edit the playbook with Gemini it must first be saved. Then you will see a button called Edit with Gemini. Please keep in mind that this feature is still in preview as of the writing of this guide. Using this feature you can change aspects of the playbook such as actions, ordering and integration choices. If you receive an error message it is most likely a time out on the server side, or at least it was most of the time when I checked the developer tools on my browser. Feel free to use the developer tools on your browser to get the response given to you when you receive an error so you can include it in a support ticket. Use Case: Phishing Triage and RemediationPrompt: "Generate a playbook for a phishing alert. Extract the URL and sender email. Enrich the URL with VirusTotal and the sender with an HR system to check for active employment status. If the URL is malicious AND the sender is still an active employee, automatically remove the email from all inboxes using Google Workspace, update the case status to 'Remediated,' and notify the security analyst."Use Case: Insider Threat Detection (Data Exfiltration)Prompt: "Generate a playbook for a Large File Transfer alert from a Data Loss Prevention (DLP) system. Check the user's role using Active Directory. If the user is an Executive or Domain Admin, suspend the user's account in IAM, post a notification to the 'Security_Critical' chat channel, and create an approval step for a Tier 3 analyst to review the transfer log before any further action is taken." Best Practices for Prompt Engineering in SecOpsThe quality of the generated playbook is directly proportional to the clarity, specificity, and structure of your prompt. Treat the prompt pane like a highly specific user story or pseudo-code.1. Adopt a Structured SyntaxDo not use vague requests like "Handle a malware alert." Instead, explicitly define the Trigger, the Enrichment Actions, the Conditional Logic, and the Response.Example of a High-Quality Prompt: "Write a playbook for phishing alerts. The playbook should extract usernames, URLs, and file hashes from the email payload and enrich them using available sources. If one of the findings is malicious, block the URL in Zscaler, remove the email from all users' mailboxes using Google Workspace, and assign the case to tier 2."2. Explicitly Name IntegrationsIf your SOC relies on specific tools, name them. If you do not name them, Gemini will attempt to find the best generic match among your installed integrations, which may not align with your specific SOPs.Good: "Enrich the file hash." (Gemini will choose an available tool). Better: "Enrich the file hash with VirusTotal." (Gemini will map directly to the VirusTotal action block).3. Define Conditional Logic ClearlyUse strong "If/Then" statements to dictate the flow of the playbook. This tells Gemini exactly where to place purple Flow boxes.Example: "Create a playbook for Anomalous Access alerts. Enrich user account information with Google Cloud IAM, and then enrich the IP information with VirusTotal. If the user is an admin and the IP is malicious, then the user account should be disabled in IAM."4. Target Specific ArtifactsInstruct the assistant on exactly what entities to extract from the alert payload. Specify if you want it to look at IPs, Domains, URLs, Hashes, or Users.5. Contextualize with Security FrameworksWhen crafting prompts, referencing specific attack behaviors or MITRE ATT&CK techniques helps align the playbook's response actions with established security frameworks, ensuring comprehensive coverage of the threat lifecycle. Pro-Tip: Never treat AI-generated playbooks as 'ready-to-deploy' right out of the gate. Always treat the initial output as a high-fidelity starting point. Use the Playbook Simulator feature extensively to validate conditional logic against historical data before ever toggling the playbook to 'Active' in production. This practice bridges the gap between AI-driven velocity and operational safety, ensuring that automated responses are as reliable as they are fast.Measuring Success and Continuous OptimizationAdopting the Gemini playbook assistant should yield measurable improvements in your SOC's efficiency. Tracking Key Metrics: Keep track of the average time engineers spend authoring and debugging playbooks. You should see a sharp decrease in playbook development time. Keep in mind you might need to break those averages up based on the complexity of the playbook.  Continuous Tuning: Playbooks are not set-and-forget. Regularly review AI-generated playbooks. As you install new integrations into Google SecOps, use the Gemini edit feature to inject those new capabilities into existing playbooks. Ensure that logic is updated as organizational policies (like approved quarantine procedures) evolve. Conclusion: Empowering the Future of Incident ResponseThe integration of the Gemini playbook assistant into Google SecOps represents a transformative shift in how Security Operations Centers (SOCs) approach automation. By moving away from the manual, often labor-intensive processes of legacy playbook construction—which historically demanded deep technical expertise in API orchestration and JSON parsing—security teams can now pivot toward an intent-based operational model. As outlined in this guide, the true value of Gemini lies not just in its speed, but in its ability to democratize automation, allowing analysts across all tiers to codify their expert knowledge into resilient, high-fidelity response workflows.As you begin implementing these AI-driven playbooks, remember that while Gemini provides the foundation for rapid deployment, your organization's specific security posture and operational requirements remain paramount. The successful adoption of this technology requires a disciplined approach: generate with intent, refine through rigorous testing, and continuously optimize as your environment evolves. By treating the AI assistant as a collaborative partner rather than an autonomous operator, you ensure that your automation strategy remains both agile and strictly aligned with your security compliance frameworks. Embracing this shift will undoubtedly reduce mean time to respond (MTTR) and free your team to focus on the high-value strategic hunting tasks that automation cannot replicate. Further LearningTo see the Gemini playbook assistant in action, including a visual walk-through of the prompt generation and refinement phases within the Google SecOps console, review this demonstration from Google Cloud Tech:AI-Powered Security and Gemini Playbook Creation   Google Security Operations Mon, 15 Jun 2026 18:30:17 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/what-s-new-in-google-secops-2026-06-14-7730 This weeks update is brought to you by Chris Martin, Google Security Specialist.  Discover the latest updates in Google SecOps for the week of June 8 through June 14, 2026. What’s New in Google SecOps, June 14th 2026 Highlights  Search case and case_history in UDM Search is now available A great article from Sumit Patel on Integrating Google SecOps into Gemini Enterprise using Custom MCP Explore several interesting features in the Bindplane monthly June roundup Product Updates & New Features Google SecOps  Release Notes from Google Cloud DocumentationJune 13, 2026: Google SecOps has introduced a new detection category, ‘Non-prioritized IoC Matching rules,’ within its Curated Detections feature, leveraging IoC feeds and threat intelligence to identify malicious activities. tRead More]New Non-prioritized IoC Matching Rules Category Non-prioritized IoC Matching rules category overview | Google Security Operations | Google Cloud…These rules are not designed to be run in alerting mode. Google recommends setting Warning: Alerting to Off. This…docs.cloud.google.comNote, this is a Google SecOps Enterprise Plus only feature. June 12, 2026: Google SecOps SIEM Search has been updated with new capabilities that allow security analysts to search for cases and their history alongside UDM events, aiming to streamline incident response workflows. mRead More]Search Case data in UDM Search Search cases and case history | Google Security Operations | Google Cloud DocumentationThis guide is for security analysts who want to analyze security telemetry, including Unified Data Model (UDM) events…docs.cloud.google.com June 12, 2026: Google SecOps has launched asynchronous Search APIs, enabling non-blocking, long-running queries for large datasets without hindering application responsiveness. uRead More]How Long Running Operations (LROs) work with Google SecOps UDM Search Asynchronous Search APIs | Google Security Operations | Google Cloud DocumentationThe Search platform in Google Security Operations lets you use asynchronous APIs for long-running queries that return…docs.cloud.google.comJune 9, 2026: Google SecOps has introduced a new feature that labels UDM fields with icons (‘U’ for unenriched, ‘E’ for enriched) to indicate whether the data has been enriched with additional context by Google SecOps. Read More]Note, this has been in product for a while now, and this appears to be an acknowledgement the feature exists.  Detecting and containing AI-powered threats with Google Security Operations agents from Google Cloud BlogThe article discusses how Google Security Operations agents help organizations detect and contain AI-powered threats, building upon the previously introduced Google AI Threat Defense system for automated security. Read More]How the Detection Coverage Agent (private preview) works in Google SecOps  What the Google AI Threat Defense announcement means for SecOps from Google Cloud BlogGoogle has announced AI Threat Defense, a new platform designed to help SecOps move from a reactive posture to a continuous, autonomous defense by leveraging AI to prioritize critical risks and automate remediation against machine-speed attacks. rRead More] SecOps SIEM  Doc Update: Event Processing > Auto Extraction from Google Cloud DocsPreviously, if a batch UDM event exceeded 8.2 MB, only the extracted fields were dropped. The updated text specifies that now, the raw logs and all the extracted fields are dropped in this scenario. aRead More] Doc Update: Ingestion > Data Processing Pipeline from Google Cloud DocsClarification on Data Processing Manager (DPM) Filters and API Quotas:- A new explanation has been added to the “API support” section clarifying that filters configured in the Data Processing Manager (DPM) are applied after data has been received by the Chronicle Ingestion API.- Consequently, these DPM filters do not prevent customers from hitting Ingestion API quotas and limits (e.g., importPushLog API limits), as these limits are evaluated before DPM filtering occurs.- The document now advises customers to implement filtering at the data source itself to effectively manage and stay within Ingestion API limits, rather than relying solely on DPM filters. yRead More] Detailed Instructions for Connecting a Google SecOps Instance in Bindplane:- An entirely new, comprehensive section titled “Connect to a Google SecOps instance” has been added.- This section provides step-by-step guidance on how to connect a Google SecOps destination instance using the Bindplane Server console.- New Prerequisites: It now states that Bindplane version 1.96.4 or later is required for this feature.- Configuration Details: It outlines the specific fields required for connection (Region, Customer ID, Google Cloud project number) and where to find them in the Google SecOps console.- It details how to obtain Service Account credentials (JSON value), specifying that the Service Account must be in the same Google Cloud project and requires either the Chronicle API Admin role or a custom role with required permissions.- It also introduces support for Workload Identity Federation (WIF) for authentication in Bindplane Cloud deployments, noting it’s not supported in self-hosted Bindplane. dRead More] Updated Docs: Investigation > UDM Search from Google Cloud DocsExtensive tables have been added to specify maximum result limits for various search types and data sources. These limits include:UDM search: 1,000,000ECG search: 1,000,000Data table search: 1,000,000UDM to UDM, ECG, and Data table joins: 1,000,000 eachCases and case history: 1,000,000Stats and Detections: 100,000 oRead More] Updated Docs: Ingestion > Cloud: Ingest Azure Activity Logs from Google Cloud DocsThe document has been significantly updated to introduce two primary methods for collecting Microsoft Azure Activity and Entra ID logs into Google Security Operations (SecOps). The document has evolved from describing a single (Blob Storage) log collection method to offering a more robust and flexible approach, introducing a real-time, recommended Event Hub method, and enhancing the security options for the existing Blob Storage method. Read More]Updated Docs: Investigation > Search Joins from Google Cloud DocsJoins in Dashboards: The most prominent change is the introduction of join operations within dashboards, allowing users to “visualize trends” with correlated data. Extended Correlation Time Window for Dashboards:- The correlation (match) time window for search remains up to 48 hours.- For dashboards, this window has been significantly extended to up to 365 days for most data sources New Supported Data Sources for Dashboards: Dashboards now support joining data from a wider array of sources, including case, case_history, detection, ingestion, ioc, playbook, ruleset/rules, graph, and events. Dashboard-Specific Syntax and Behavior:- The document clarifies that dashboard joins are case-sensitive by default, with a nocase modifier available for case-insensitive operations.- New examples are provided for dashboard joins, including correlating case and case_history data, and an advanced use case demonstrating how to calculate metrics like Mean Time To Close (MTTC) using multistage queries. Updated Limitations: The limitations section has been revised to specify which limitations apply “in search” (e.g., maximum UDM/ECG events) and to differentiate the maximum match time window between search (48 hours) and dashboards (365 days). dRead More] Updated Docs: Reference > Ingestion Methods from Google Cloud DocsDeduplication Scope:- Archived: Stated that deduplication occurred “across feeds when the Customer ID, raw log payload, and UDM data are identical for a customer,” and explicitly mentioned “The Log Type is not included in the deduplication hash.” This implied that if the content was the same, it would be deduplicated regardless of the feed or log type.- Current: Now explicitly states that “Google SecOps performs deduplication only within the context of a single log type for a specific customer.” It further clarifies that “Google SecOps does not consider batches with identical content but different log types as duplicates and ingests them.” Batch ID Generation and Rejection Logic:- Archived: Mentioned a batch ID was assigned, and if it matched an existing ID, the new batch was not forwarded. The batch ID was “identical if the batches contain the same logs.”- Current: Provides a more detailed explanation. It states that the batch ID is generated by hashing the customer ID and the content of log entries (raw data and UDM fields), and confirms that “The batch ID hash does not include the log type or other metadata fields.” However, the critical change in the rejection logic is that a new batch is rejected as a duplicate only if its batch ID matches an existing one “for the same customer ID and log type.” Updated Docs: Ingestion > Cloud > Context Parsers from Google Cloud DocsFilter Length Limit: Export filters are now subject to a maximum length of 20,000 characters. Filter Complexity Warning: Users are cautioned that overly complex filters (especially those with deeply nested AND or OR conditions) might be rejected even if they are within the character limit, and are advised to simplify their filters. Explicit Scoping: All elements within a filter must be explicitly scoped to supported log types. Required Reference Methods: When referencing log types, users must use either log_id() or logName. Read More] SecOps SOAR  New Docs: SOAR > Attach playbooks to an alert or case from Cloud Google DocumentationThis document outlines the attachment limits and priority settings for playbooks associated with an alert or case in Google Security Operations, followed by the steps necessary to manually add a playbook or playbook block to an active investigation. iRead More]Attach playbooks to an alert or case | Google Security Operations | Google Cloud DocumentationThe Note: Cases scope playbook features described in this document are not available to all customers in all regions…docs.cloud.google.com Updated Docs: SOAR > Respond > Working With Playbooks > Using Triggers In Playbooks from Google Cloud DocsIntroduction of Playbook Scopes: Triggers are now categorized based on the playbook’s chosen scope: “Alert scope” or “Case scope.” This fundamentally alters how triggers are configured and what options are available New Case Scope Ingestion Triggers: A new set of ingestion triggers has been added specifically for “Case scope” playbooks, including:- All: Attaches the playbook to every newly created case.- Custom trigger: Attaches based on specific filtering rules for cases.- Case tags: Attaches only when a case contains specific tags. Updated Playbook Creation Process: When creating a new playbook, users must now explicitly select its Scope (Alert or Case), which then determines the available trigger options. Clarification of Reaction Triggers: Reaction triggers are now explicitly described as “event-based and lifecycle triggers that fire during an active investigation,” providing a clearer distinction from ingestion triggers rather than just being another tab option in the initial description. Updated Doc: Soar > Respond > Working With Playbooks > Using Reaction Triggers In Playbooks from Google Cloud DocsThe key changes in this document significantly expand the capabilities of reaction triggers by introducing case-level events in addition to the existing alert-level events. nRead More]Using Reaction Triggers in Playbooks  Updated Doc: Reference > Sample YARA-L For Native Dashboard from Google Cloud DocsNew Schema Field: A new field, case.custom_fields (Map data type), has been added to the "Cases and Alerts" schema. This field is designed to store user-defined custom data and requires specifying the data type when accessed (e.g., case.custom_fields "field_name"].string_seq.string_vals). New Query Examples for Custom Fields: Several new query examples have been added to demonstrate how to leverage these custom fields effectively. nRead More] Google Threat Intelligence  ShinyHunters Targets Education Sector with Oracle PeopleSoft Exploit from Google Cloud BlogMandiant and Google Threat Intelligence Group have identified an active compromise and extortion campaign by UNC6240 (ShinyHunters) targeting Oracle PeopleSoft infrastructure in the education sector. nRead More] BindPlane  Monitor our own AI with Bindplane, Sentinel goes native, and configs get rollbacks from BindplaneBindplane’s June 2026 updates focus on de-risking telemetry pipelines with features like native Microsoft Sentinel integration, automatic OCSF mapping for security data, configuration rollbacks, and enhanced AI monitoring capabilities. eRead More] OTEL v1.101.2 from GitHubThis article announces the v1.101.2 release, which includes bumping the Windows Event Log receiver to v0.153.0 and other module updates. iRead More] AI  Introducing the Open Knowledge Format from Google Cloud BlogGoogle is introducing the Open Knowledge Format to provide relevant context to foundation models and agentic systems, aiming to improve data sharing and overcome current limitations in model performance due to a lack of information. Read More] 10 Indispensable Prompts Our Team Refuses to Build Without from Google Cloud BlogThe article highlights ten indispensable AI prompts utilized by a team to consistently produce high-quality work, covering various tasks from debugging to generating boilerplate code. lRead More] Choosing your surface: Antigravity 2.0, Antigravity CLI, Antigravity IDE, or Antigravity SDK from Google Cloud BlogThe article introduces and differentiates various ‘Antigravity’ products, including a desktop app (Antigravity 2.0), a command-line interface (Antigravity CLI), an IDE, and an SDK, detailing their intended use cases for orchestrating autonomous agents and managing projects. tRead More] Report: GKE Inference Gateway delivers up to 92% faster AI responses from Google Cloud BlogGoogle’s GKE Inference Gateway significantly accelerates AI inference, delivering up to 92% faster responses for generative AI workloads in production environments. %Read More] How to unlock true ROI in software development — a deep dive into the latest DORA research from Google Cloud BlogThe article discusses how technology and finance leaders can prove the business value and secure funding for generative AI projects by focusing on ROI and building supportive organizational systems and culture. CRead More]How to consider and track ROI from Gen AI projects Adoption Guides & Deep Dives  Integrating Google SecOps into Gemini Enterprise using Custom MCP from Google Cloud Security CommunityThe article from Sumit Patel details how integrating Google SecOps with Gemini Enterprise creates an “Agentic SOC,” using AI to enhance security operations and address talent shortages and data overload. eRead More]Using Google SecOps MCP with Gemini Enterprise Using Google SecOps MCP with Gemini EnterpriseUsing Google SecOps MCP with Gemini Enterprise  Wiz  AI Threat Readiness Pillar 2: Accelerate Patching and Response from Wiz BlogThis article is a guide on improving an organization’s readiness against AI threats by accelerating patching, remediation, and response strategies using the Wiz platform. rRead More] AI Threat Readiness Pillar 3: Perform AI Code Analysis Natively in Wiz from Wiz BlogThe article details Wiz’s native AI code analysis feature, positioned as the third pillar of AI threat readiness, to help organizations manage AI-driven development and combat adversaries. rRead More] Platform Issues  RESOLVED: Google SecOps customers are experiencing increased query latency in Dashboards in asia-southeast1 from Google Cloud StatusGoogle SecOps customers in asia-southeast1 are experiencing increased query latency in Dashboards, impacting several data sources and HealthHub performance. rRead More] RESOLVED: Chronicle Security Operations customers are experiencing delay in processing a subset of Emerging Threat rules from Google Cloud StatusChronicle Security Operations customers are experiencing delays in processing a subset of Emerging Threat rules, which began at 2026–06–08 08:11 US/Pacific. eRead More]   Google Security Operations Mon, 15 Jun 2026 15:31:54 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/multi-tenant-filtering-support-in-google-secops-siem-7649 Hey everyone!I am working on setting up a multi-tenant dashboard in Google SecOps SIEM and could use some advice from the community.Right now, we are tracking specific entities: files, domains, and URLs. We want to find a clean way to separate this data so each tenant only sees their own information on the dashboard.I have two main questions:1. How are you handling multi-tenancy? What is the best way to structure dashboards in Google SecOps when dealing with multiple tenants for file, domain, and URL data?2. Is there a common field we can use for filtering? We are looking for a standard field where we can append the tenant's name to easily group and filter these specific entities. What fields do you recommend for this?Additionally, how should we handle deduplication across tenants? Should we deduplicate within each tenant's data separately, or is there a global deduplication strategy that works better when dealing with shared entities (like domains or URLs that might appear across multiple tenants)? Google Security Operations Mon, 15 Jun 2026 15:23:31 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/api-access-to-custom-export-filter-settings-7652 Hi, I’m referring to the config GCP console / Google SecOps / Ingestion / Custom export filter settingsAFAIK there are no Terraform support for having the export filter settings in IaC.Looks like there is no API for editing these either. Is this on a roadmap? Google Security Operations Mon, 15 Jun 2026 15:13:23 +0200 https://security.googlecloudcommunity.com/community-blog-42/why-your-ra-tls-private-key-is-the-weakest-link-and-how-svsm-fixes-it-7729 Authors:Rene Kolga, Google Cloud Confidential ComputingJens Albers, Fr0ntierX Confidential computing promises something radical: you can run workloads on infrastructure you don't trust, and prove it. AMD SEV-SNP encrypts VM memory with keys the cloud operator can't access. Remote attestation lets a client verify that specific code is running inside genuine hardware isolation. And RA-TLS  -  Remote Attestation Transport Layer Security  -  ties that attestation to a TLS connection, so the client knows it's talking directly to the attested workload and not to something pretending to be it.This @works. But most production RA-TLS deployments have a gap that undermines the guarantee: the TLS private key sits in guest memory where a runtime exploit can steal it.This post explains the gap, why it matters more than people think, and how SVSM (Secure VM Service Module) key isolation closes it. How RA-TLS WorksA proxy running inside a Confidential VM generates a TLS key pair at startup, computes a hash of the public key and embeds that hash into a hardware attestation token. The token is signed by the CPU's attestation key  -  fused into the silicon at manufacturing, impossible to extract or forge in software.When a client connects, it completes a normal TLS handshake, then retrieves the attestation token over the established connection. The client verifies the hardware signature, confirms the hash inside the token matches the TLS public key it just received, and pins the session. If anything doesn't match  -  if someone tried to swap in a different TLS key, or relay a token from a different machine  -  the verification fails and the connection is rejected.The binding is elegant: the attestation token says "this public key belongs to this Trusted Execution Environment (TEE)," and the TLS handshake proves the server holds the corresponding private key. Together, they guarantee the client is talking to the genuine machine.But that guarantee rests on an assumption: the private key stays inside the TEE. What Happens When It Doesn'tHere's a possible attack: A workload runs in a Confidential VM. The proxy generates its TLS key pair, attests it, and starts serving clients. An attacker finds a zero-day in a dependency, i.e. a memory corruption bug that allows arbitrary reads of process memory. The attacker reads the TLS private key directly from the proxy's address space. They also get the cached attestation token, which is served at a public endpoint. The attacker stands up a rogue server using the stolen key and the captured token. A new client connects to the rogue server, receives the token, verifies the hardware signature, confirms the hash matches the TLS public key and ultimately has no idea it's talking to the attacker. SEV-SNP protected the key from the cloud operator. It did nothing to protect the key from the exploit running inside the VM. The attestation binding is technically intact  -  the token genuinely corresponds to the key  -  but the key is no longer exclusively held by the TEE.This isn't hypothetical. TEE key extraction has been demonstrated through side-channel attacks, firmware vulnerabilities, and software exploits within the guest. The question isn't whether it can happen, it's what your security model looks like when it does.Joshua Guttman, Paul Rowe and colleagues formalized this as a design principle: attestation should be independent of secrets that could be disclosed by transient corruptions. The TLS private key is exactly such a secret. If a runtime compromise can disclose it, and the attestation depends on it staying secret, then the attestation doesn't survive the exact kind of compromise it was supposed to protect against. The Intra-Handshake ProblemBefore explaining the fix, it's worth understanding a related issue that affects the entire RA-TLS ecosystem.The original RA-TLS design  -  pioneered by Intel for SGX (Software Guard Extensions), adopted by Gramine, Occlum, and others  -  embeds attestation evidence directly in the TLS certificate as an X.509 extension. The attestation arrives during the handshake, before the connection is established. This seems cleaner: the client knows whether it's talking to a TEE before any application data flows.But the Confidential Computing Consortium Attestation SIG's formal analysis proved this approach has a fundamental flaw. Using ProVerif, security researchers Sardar, Moustafa, and Aura demonstrated that all production intra-handshake implementations are vulnerable to relay attacks. A man-in-the-middle can relay the entire certificate  -  attestation evidence included  -  from the real TEE to a victim client, while maintaining a separate TLS session with the real TEE. The attestation evidence isn't cryptographically bound to the TLS session. It's just cargo inside the certificate.The findings, published at ACM AsiaCCS 2026, have driven a shift in the IETF's standardization work toward post-handshake attestation. Our RA-TLS implementation delivers attestation after the TLS handshake at the application layer, which avoids the relay vector entirely. The client completes the handshake, retrieves and verifies the attestation separately, then pins the connection. There's a brief window between handshake and verification  -  the mitigation is simple: don't send sensitive data until verification completes.But post-handshake attestation, on its own, still depends on the private key being non-extractable. Which brings us back to SVSM. The SVSM Solution: Use Without PossessionThe Coconut-SVSM (Secure VM Service Module) introduces a second layer of hardware isolation inside the Confidential VM.AMD SEV-SNP defines multiple Virtual Machine Privilege Levels. VMPL0 is the most privileged, VMPL2 is where the guest kernel and proxy run. The boundaries between them are enforced by the CPU and not by software. Code at VMPL2 cannot read memory belonging to VMPL0 regardless of its privileges within the guest OS. A compromised kernel, a root shell, a malicious kernel module  -  none of them can cross this boundary.The SVSM runs at VMPL0 and provides an emulated TPM that generates and stores cryptographic keys inside this isolated environment. When the proxy starts, it asks the SVSM's e-vTPM (emulated Virtual Trusted Platform Module) to generate the TLS key pair. The private key is created at VMPL0 and never leaves. What the proxy receives back is a handle  -  an opaque reference it can use to request signatures, but which contains no key material.When a TLS handshake arrives, the proxy sends the data to be signed along with the handle. The signing happens at VMPL0. The signature comes back. The key never crosses the boundary.This is the critical distinction: the proxy can use the key but cannot possess it.Now replay the attack: The same runtime exploit compromises the proxy. The attacker reads all of the guest memory. They find a key handle - a useless integer - not key bytes. They capture the attestation token. They try to stand up a rogue server, but they can't complete TLS handshakes because they don't have the private key. The handle only works inside the original SVSM on the original hardware. The attack fails. The attestation binding survives the compromise. The hardware-signed token still points to a key that only the SVSM can use. The attacker can't forge signatures, can't impersonate the server, and can't reuse the captured token from a different machine. The Trust ChainWith SVSM, trust flows in one direction - from AMD silicon at manufacturing, through the certificate chain, into the signed attestation report, into the TLS session: AMD Root Key (ARK) Self-signed. Published by AMD. │ ▼AMD SEV Key (ASK) Signed by ARK. │ ▼VCEK Fused into the CPU during manufacturing. │ Unique per chip. Cannot be simulated. ▼SNP Report Signed by VCEK. │ Contains measurements, privilege level, firmware version. ▼eat_nonce in REPORT_DATA Hash of the TLS public key. │ Binds the hardware attestation to this server identity. ▼TLS Private Key Held at VMPL0 inside the SVSM e-vTPM. │ Non-exportable. Usable only via handle. ▼Pinned TLS Session Client verified the full chain. Bound to this hardware, this key, this session.No third party at any step. No cloud provider attestation service. No certificate authority. Verification is certificate chain validation and a single signature check  -  pure mathematics, auditable offline.A client can verify a TEE's identity on an air-gapped laptop with nothing but AMD's published root certificates. Fail-Hard, Not Fail-SoftOne design decision worth calling out: when SVSM initialization fails and SVSM mode is enabled, the proxy does not silently fall back to in-memory keys. It exits.A silent fallback would mean an operator who configured VMPL0 key isolation is actually running with keys in guest memory  -  the exact configuration they were trying to avoid  -  with no visible indication. Fail-hard means you discover the problem immediately, not when an auditor or an attacker finds the gap. What This Doesn't SolveSVSM key isolation is one layer in a defense-in-depth architecture. We want to be precise about the boundaries.SVSM solves key exfiltration from runtime exploits, kernel compromises, dependency supply chain attacks, cold boot attacks, and memory forensics within the guest. It makes the TLS private key non-extractable by anything outside VMPL0.SVSM doesn't prevent key misuse. A compromised proxy can still issue signing commands through the handle for as long as it controls the process. It can't steal the key, but it can abuse it. The defense against misuse comes from continuous attestation  -  behavioral monitoring detects anomalies, kernel integrity checks detect rootkits, and the system automatically revokes cryptographic access when any verification layer fails. A compromised proxy that behaves anomalously gets shut down within seconds, not days.SVSM doesn't address token replay across time. The attestation token is generated once and cached. For clients that need per-session guarantees, session-bound attestation  -  which binds evidence to each individual TLS session's key exchange using TLS 1.3 Exporter values  -  provides a stronger tier. But for most deployments, identity-bound attestation with SVSM key isolation is the right tradeoff between security and performance. AvailabilitySVSM e-vTPM key isolation is available in preview on Google Cloud Confidential VMs with AMD SEV-SNP. The RA-TLS implementation described here  -  including the proxy, client SDK, and kernel integrity monitor  -  is open source under Apache 2.0 as part of the Polaris confidential computing platform. Further Reading Sardar, Moustafa, Aura  -  "Identity Crisis in Confidential Computing: Formal Analysis of Attested TLS"  -  ACM AsiaCCS 2026 Thomas, Schmalz, Petz, Alexander, Guttman, Rowe, Carter  -  "Designing Trustworthy Layered Attestations"  -  arXiv:2603.06326 CCC Attestation SIG  -  Formal specification and verification of attestation in CC  -  github.com/CCC-Attestation Coconut-SVSM  -  github.com/coconut-svsm/svsm IETF draft-fossati-seat-expat  -  "Remote Attestation with Exported Authenticators" Entity Attestation Token (EAT)  -  IETF RFC 9711    Community Blog Mon, 15 Jun 2026 15:03:38 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/new-custom-solution-for-real-time-bindplane-agent-monitoring-in-google-secops-6430 I’m excited to share a custom solution I’ve developed that will make our Bindplane Agent monitoring process much easier and more efficient. With this setup, agent status can now be monitored in real time directly from Google SecOps, eliminating the need to repeatedly check the Bindplane console.What This Solution DoesIntegrates Bindplane API with Google SecOps SOAR. Automates ingestion of agent status logs into Google SecOps SIEM. Triggers alerts whenever an agent becomes inactive. Provides a single pane of glass for the SOC team to monitor agent health.Key ComponentsBindplane API. SOAR IDE script to fetch and ingest agent data. SIEM rule to detect inactive agents and generate alerts.Benefits Real-time monitoring without manual console checks. Automated alerts for inactive agents. Streamlined workflow within existing security tools.PrerequisitesBefore you begin, ensure you have:Access to Bindplane with permissions to generate an API key Access to Google SecOps SOAR (IDE) Access to Google SecOps SIEM to create ingestion rules and alerts Google SecOps Customer ID for log ingestion Detailed StepsStep 1: Generate Bindplane API KeyFollow the official Bindplane documentation to create an API key:https://docs.bindplane.com/cli-and-api/api-keysThis key will allow the SOAR IDE to query Bindplane agent status. Step 2: SOAR IDE for fetching Bindplane Agent StatusIn Google SecOps SOAR, create a new IDE integration. The following Python script calls the Bindplane API, extracts key details for each agent, and ingests them into the Google SecOps Ingestion API under log type.You may extend this script to include additional fields if required.SOAR IDE Script# Define the Bindplane API URL and the API Keyurl = "https://app.bindplane.com/v1/agents"  # Bindplane API Endpoint for Agent detailsapi_key = "xxxxx-xxxxx-xxxxxxxx-xxxxx"  #Your Bindplane API Key# Set the headers with the API keyheaders = {    "X-Bindplane-Api-Key": api_key}# Make the GET request to the APIresponse = requests.get(url, headers=headers)# Initialize an empty list to hold the formatted agent dataagents_data = n]# Check if the request was successful (status code 200)if response.status_code == 200:    # Parse the response JSON    data = response.json()    # Iterate over the list of agents    for agent in data.get('agents', �]):        user_defined_time = str(datetime.now(timezone.utc))        agent_name = agent.get('name', 'Unknown')        agent_status_code = agent.get('status', 'Unknown')        # Map the status code to active/inactive        agent_status = "active" if agent_status_code == 1 else "inactive"        # Extract additional attributes        os_family = agent.get('labels', {}).get('attributes/os.family', 'Unknown')        agent_version = agent.get('labels', {}).get('bindplane/agent-version', 'Unknown')        # Extract assigned configuration        assigned_configuration = agent.get('configurationStatus', {}).get('assigned', 'Unknown')        # Create dictionary for this agent's data        agent_data = {            "Agent Name": agent_name,            "Status": agent_status,            "OS": os_family,            "Agent Version": agent_version,            "Assigned Configuration": assigned_configuration        }        agents_data.append(agent_data)    # Send each agent record to SecOps Ingestion API    for agent in agents_data:        json_dict = {            "customer_id": "xxx-xxxxx-xxxxx-xxxx-xxx",  # Your SecOps SIEM Customer ID            "log_type": "<LOG_TYPE>",  #Enter log type in which you want this data to ingest.            "entries": �                {                    "log_text": json.dumps(agent)                }            ]        }        serialized_data = json.dumps(json_dict)        GCM.send_logs(serialized_data)  # Send logs to SIEM ingestion APIStep 3: Create SIEM Rule to Detect Inactive AgentsAfter ingestion begins, create a rule in Google SecOps SIEM to alert when a Bindplane agent reports "Status": "inactive".SIEM Rulerule BINDPLANE_AGENT_NOT_REPORTING {  meta:    author = "Suraj Kadav"    description = "This rule will trigger an alert when any Bindplane agent goes offline/disconnected."    severity = "Critical"  events:    $e.metadata.log_type = "BINDPLANE_AGENT"    $e.extracted.fieldsS"Status"] = "inactive"  outcome:    $Agent_Name = $e.extracted.fieldse"Agent Name"]    $Agent_Status = $e.extracted.fieldse"Status"]    $System_OS = $e.extracted.fieldsr"OS"]    $Agent_Version = $e.extracted.fieldsn"Agent Version"]    $Agent_Configuration = $e.extracted.fieldst"Assigned Configuration"]  condition:    $e}Tip : Consider adding a suppress/threshold to avoid flapping alerts (e.g., require 2–3 consecutive inactive observations or a time window). Optional EnhancementsAdditional Agent details OS-based grouping Dashboards Optimize code for faster performance. This solution is created to simplify operations and improve visibility of Bindplane Agent status for the SOC team. If you’re interested in implementing it or have ideas for enhancements, feel free to reach out or drop your suggestions in the comments! Google Security Operations Mon, 15 Jun 2026 14:50:10 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/secops-sentinelone-alerts-closing-using-secops-gui-7727 Hello. We re using S1. When we`re closing alerts in SECOPS we need also to close alert in S1 console using:Mitigate option in S1Choosing suitable option (kill, Unquarantie, Remediate, Rollback, Add to Blocklist) and naturally mark alert as resolved in S1 without touching S1 console.We would like to do all of theses jobs directly from SECOPS console. Is it doable?  Google Security Operations Mon, 15 Jun 2026 14:32:33 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/google-secops-automating-stale-account-suspensions-with-google-secops-and-azuread-version-4-7728 Release Notes: SecOps Inactive Accounts Connector (v4) Enterprise Enhancements & FeaturesThis connector has been heavily optimized for high-throughput, large-scale Google SecOps environments. It uses Google Security Operations' modern Asynchronous Search API to support high-volume data retrieval, state management, network resilience, and UI protection. Smart Event Batching (Anti-Case Explosion)To prevent SOAR UI degradation and alert fatigue, the connector aggregates breached users and chunks them into grouped cases:Dynamic Chunking: Limits cases to 80 events per case, safely staying under the platform's ingestion ceiling. Seamless Playbook Integration: Passes the grouped events directly to the SOAR Ontology engine, allowing playbooks to seamlessly loop through all users in the batch simultaneously. Proactive Health Monitoring (Upgraded to 1M Scale)Asynchronous API Capacity: Migrated from the synchronous udmSearch API to the asynchronous Search Session API, allowing the connector to retrieve up to 1,000,000 events (compared to the previous 10,000 limit). Blindspot Detection: The Health Alert ("Check Engine" light) threshold is now set to the 1,000,000 limit (ASYNC_LIMIT). If the query volume reaches or exceeds this capacity, the connector automatically spawns a dedicated Health Alert case (SecOps Connector Health) to warn the engineering team that the query window is too broad and logs may be dropped. Performance & Compute OptimizationsAsynchronous Query Execution: Moves away from blocking synchronous calls. The connector issues a POST request to spawn a background search session, polls for completion, and then streams the results, avoiding timeouts. Lexicographical Sorting: Removes computationally heavy datetime parsing from the main data ingestion loop. The script sorts and compares raw ISO 8601 strings in $O(n)$ time and only executes the math calculation once per unique user at the end of the run. Connection Pooling: Utilizes requests.Session() to reuse persistent TCP connections, reducing TLS handshake latency across paginated API calls.️ Network Resilience & ReliabilityAutomatic Retries: Implements a urllib3 Retry adapter configured to catch and automatically retry on 429 (Rate Limited) or 5xx server errors. The adapter handles both the initial POST requests and subsequent paginated GET requests. OAuth Token Failsafe: Features timer checks in both the polling and pagination loops. If polling or data extraction runs longer than 50 minutes, the script automatically refreshes the bearer token to prevent 401 Unauthorized timeouts during massive data pulls.🧹 Data Normalization & FilteringCase-Insensitive Deduplication: Email addresses are immediately converted to lowercase upon extraction. This merges variants (e.g., User@ vs user@), preventing duplicate playbook executions for the same identity. Targeted Exclusions: Includes standard exclusions to shield specific administrative or service accounts (e.g., service accounts or specific customer domains) from automated suspension logic. Code Readability & MaintainabilityGlobal Constants: All configuration variables (lookback periods, chunk sizes, page limits, token refresh intervals, and async limits) are defined at the top of the script. This makes the codebase self-documenting and allows future tuning without modifying the pagination logic.GitHub Repository:https://github.com/Darrenswift/google_secops_use_cases_repo   Google Security Operations Mon, 15 Jun 2026 12:31:05 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/working-of-time-filter-of-ioc-model-data-in-dashboards-7687 Hi,I wanted to know global time filter of the Google SecOps SIEM dashbaord works on which field of IOC model if we have only IOC model data coming from IOC matches?Also, I have one observation that , match which is visible in IOC match table which is not returning while quering through dashboard for same time range? Google Security Operations Sun, 14 Jun 2026 21:57:31 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/google-secops-mcp-with-mcp-proxy-authentication-approach-7690 Hi All,We would like to authenticate with Google SecOps MCP ( Remote MCP) using an MCP Proxy in between.  Our current setup is using Workforce Identity Federation with Microsoft Entra as IDP. Anyone who has achieved this in past or knows how this can be achieved.Our goal is to have controlled communication via central exit point (MCP Proxy Server) and use our existing SecOps user creds for users to query Google SecOps MCP.    Google Security Operations Sun, 14 Jun 2026 21:53:46 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/microsoft-365-defender-integration-7692 I am currently testing the Microsoft 365 Defender Integration (XDR) v26.0 and have noticed that if I trigger 2 x events that create 2 x Incidents in XDR that become correlated under a new Incident Name, the new Incident Name is not reflected in Google SecOps SOAR, this seems to be by design however, I would like the case in SecOps SOAR to reflect the new Incident Name in XDR, I was thinking of utilising a KQL Query in a playbook to do this, any thoughts? Trigger an event Incident 123456 (Test Incident 1) created in XDR Trigger an event Incident 123457 (Test Incident 2) created in XDR Ingest takes place in SOAR Case 5672 created with the Name Test Incident 1 Correlation takes place in XDR Incident 123457 closed and alert moved to 123456 in XDR Incident 123456 renamed from Test Incident 1 to Suspicious Activity on Endpoint SOAR Case attaches new Alert to Case 5672 and Case name stays as Test Incident 1ThanksDaryll Google Security Operations Sun, 14 Jun 2026 21:49:30 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/filter-events-that-were-associated-with-an-alert-or-case-7714 Hello team, Is it possible to use UDM filters to filter the events that triggered a rule?In QRadar, you can apply this type of filter to determine which event actually triggered the rule, and I’d like to know if SecOps has the same search mechanism, since we use this data to create a report.Regards,Renato Ferreira​​​​​​​ Google Security Operations Sun, 14 Jun 2026 21:45:43 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/google-cloud-project-suspended-for-hijacked-instance-7723 My Google Cloud Project was suspended due to “hijacked instance”.  I submitted an appeal stating this: I still have access to project in ai studio. I’ve deleted all old  API  keys and create a new API key. My project operates as a forex trading engine. The system functions as an advanced market analytics server that processes tick-level data for multiple financial pairs (Forex, Crypto, Commodities) concurrently over WebSockets. High-frequency calculation of technical indicators (Bollinger Bands, RSI, ADX, EMA-200, and Divergence patterns) requires sustained, continuous server-side execution with minimal lag.  To provide accurate retracement signals to our clients, our platform keeps highly active, persistent bidirectional channels open with global endpoints. Google's automated threat detection engines may have identified this polling and streaming behavior as a distributed coordinated network action (DDoS or network scanner profile), whereas it is actually dedicated financial market data ingestion.  Calculating dynamic indicator metrics on multi-timeframe candles (M5, M15, H4) across 20+ pairs consumes significant network I/O and processor cycles. This intensive data parsing is required to run our proprietary mathematical models and filter out false market entries. I Stated clearly that I am running a financial analysis and WebSocket streaming app and   that the outbound network spike originates from legitimate analytical data polling (consuming public WebSocket API services) rather than a hijacked instance. Google Security Operations Fri, 12 Jun 2026 19:03:40 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/google-cloud-migration-stage-2-of-soar-migration-to-gcp-7539 Has any one completed the stage 2 of SOAR migration to GCP ?Could you simply explain the pointers that you followed for the same.   Google Security Operations Fri, 12 Jun 2026 14:58:49 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/urgent-google-cloud-project-suspended-account-hijacked-business-impact-7326 Hello,My Google Cloud project has been suspended due to a security issue (ACCOUNT_HIJACKED).I fully understand the situation and I am ready to take all necessary actions to secure the project. However, I currently do not have access to the project anymore, which prevents me from revoking the compromised API keys or applying the required fixes.As a precaution, I have already stopped billing to prevent any further charges.At the moment, my application is completely down, which is having a severe impact on my business. My clients cannot access the service, and I am receiving increasing complaints and refund requests.I already have an open support case: 70327888This situation is becoming critical, and I would greatly appreciate any help to restore access or guidance on how I can proceed to secure the project.Thank you very much in advance for your support.Vincent Google Security Operations Fri, 12 Jun 2026 14:26:49 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/create-a-simulated-case-with-api-7715 Hello,Has anyone successfully created a simulated case using the API?I'm trying to use the following documentation:https://docs.cloud.google.com/chronicle/docs/reference/rest/v1alpha/projects.locations.instances.legacyCases/simulateAlertHowever, I'm running into some issues. The API call reaches the CreateSimulatedCustomCase method, and the audit logs show that the service account is recognized and has the chronicle.legacyCases.simulate permission. Despite that, the request fails with the following error:Request is missing required authentication credential. Expected OAuth 2 access token, login cookie or other valid authentication credential.I'm authenticating with a Service Account using the cloud-platform scope, and the same token works successfully with other Chronicle APIs.Has anyone encountered this before or managed to create simulated cases through the API?Thanks! Google Security Operations Thu, 11 Jun 2026 02:25:52 +0200 https://security.googlecloudcommunity.com/security-validation-5/msv-msi-update-2-0-3-0-june-9-2026-7712 This release note outlines the latest updates, enhancements, and bug fixes for the Mandiant SecOps Integrations (MSI) service.EnhancementsTrend Micro Vision One v1: Exposed the Alert Field Mapping configuration in the web interface, allowing users to customize which fields are used for alert data. Default mappings are still provided. Enabled support for SSL certificate authentication for the following integrations: Exabeam Cloud v1 Splunk v1 Splunk v2 Added titles to the default queries for the following integrations: Google BigQuery v1 Logzilla v1 Microsoft Defender ATP v1 Security Onion v1 Trellix Enterprise Security Manager v2 Trellix Enterprise Security Manager v1 Trellix Helix v1 Bug fixesCybereason v1: Fixed an issue where Default Malware Queries were not displaying, which prevented the integration from being saved. This was due to incorrect model typing for the malware queries field. Google Cloud Logging v1: Fixed an AttributeError that occurred during health checks when a Service Account JSON was provided as a string instead of a parsed object. The integration now correctly handles the JSON input. LogRhythm Elastic v1: Removed invalid 0 values from the default field mapping, which caused errors when saving the integration. Microsoft Graph API v1: Corrected the expansion of %HOSTNAMES% and %IPS% variables when multiple values are present. Each value in the list is individually single-quoted, ensuring correct query syntax, Trellix Helix v1: Resolved an integration failure caused by incorrect authentication scopes. Framework: Resolved an issue preventing integrations with proxies from being saved or edited. Security Validation Wed, 10 Jun 2026 17:48:53 +0200 https://security.googlecloudcommunity.com/community-blog-42/integrating-google-secops-into-gemini-enterprise-using-custom-mcp-7711 Authors:Sumit Patel, Regional Security ArchitectYazan Mughrabi, Security Practice Lead In today’s rapidly evolving threat landscape, security teams are challenged by a persistent talent shortage and an overwhelming volume of data. Integrating Google Security Operations with Gemini Enterprise creates an "Agentic SOC" that allows defenders to move at machine speed by combining human rigor with AI-driven productivity.Gemini Enterprise brings significant benefits to companies looking to leverage GenAI and low code agents to streamline operations. A big part of these operations involves the intersection of Observability and Security. Being able to bring in the context of Security to the other parts of the business allows customers to have a good overall view of the data and tools needed.By leveraging the Model Context Protocol (MCP), organizations can connect Google SecOps directly to Gemini Enterprise without the need for custom coding or complex agent creation. This integration makes Gemini the "front door" for the SOC, allowing users to perform complex tasks like triaging alerts, summarizing cases, and querying IOCs through simple natural language. Furthermore, MCP enables the seamless unification of diverse data sources, such as BigQuery and external security tools, providing a single interface for comprehensive correlation and investigation.Designed for the enterprise, this solution is built on Gemini Enterprise Agent Platform, offering the security, compliance, and reliability required for mission-critical operations. This architecture supports multi-tenant, IRAP-protected, and federated models, ensuring that global organizations can scale their security visibility and control without limits.This guide walks through connecting Google SecOps directly to the main Gemini Enterprise chat using the managed Remote MCP endpoints and the new Custom MCP Data Store feature. This method requires no coding, no custom agent creation, and no dedicated reasoning engines.Prerequisites Ensure remote MCP is enabled for your Google SecOps environment as per: Use the Google SecOps MCP server | Google Security Operations  Disable any Org Policies that will prevent custom MCP servers from being created. Step 1: Setting up OAuth 2.0 Web ApplicationBefore configuring Gemini Enterprise, you must create an OAuth 2.0 Web Application in the GCP project tied to your SecOps instance.   Navigate to Google Cloud Console > APIs & Services > Credentials. Click + CREATE CREDENTIALS > OAuth client ID. Select Web application as the application type. Name it (e.g., "Gemini Enterprise SecOps MCP"). Under Authorized redirect URIs, add both of these URLs: https://vertexaisearch.cloud.google.com/oauth-redirect https://vertexaisearch.cloud.google.com/static/oauth/oauth.html Click Create and securely copy the generated Client ID and Client Secret.  Note: Ensure the users who will be authenticating have the roles/mcp.toolUser, Service Usage Consumer, and Chronicle API Viewer IAM roles in this GCP project. Step 2: Add the SecOps Data Store in Gemini EnterpriseAn administrator must configure the Custom MCP connector globally. Open Gemini Enterprise and navigate to the app or create a new Gemini Enterprise app. . Go to Connected Data Stores and click +New Data Store. Select Custom MCP and fill out the configuration as follows:   Field Value MCP Server URL https://chronicle.us.rep.googleapis.com/mcp  (Replace with your specific SecOps region if not US multi-region) Authorization URL https://accounts.google.com/o/oauth2/v2/auth Token URL https://oauth2.googleapis.com/token Client ID (Paste from GCP Prerequisite) Client Secret (Paste from GCP Prerequisite) OAuth Scopes https://www.googleapis.com/auth/cloud-platform https://www.googleapis.com/auth/chronicle  (Separate with a single space) Save the Data Store (e.g., Name it "Agentic SOC" for example).     Go to your Gemini Enterprise App and click on ‘Connected Data Stores’ → Make sure your new connected data store is listed and select it.    Select Actions in the menu and click ‘Reload Custom Actions’    Select the list of actions you’d like your users to use, and choose Enable Actions.  Step 3: Authenticate the Connector in ChatBefore using the connector for the first time, each user must authorize Gemini to act on their behalf.   Open the main Gemini Enterprise chat. Look at the bottom of the chat window for your connected Data Stores. Locate the Agentic SOC connector and toggle it ON. If prompted: complete the Google sign-in prompt to grant Gemini the necessary OAuth permissions. Once successful, the broken chain icon will disappear. Step 4: Set Up Gemini Memory for SecOps ContextBecause you are using the main Gemini chat instead of a dedicated Agent with hardcoded instructions, Gemini needs to know your specific SecOps environment details to route API calls correctly. You can use Gemini's Memory feature to save this permanently.Send the following prompt to Gemini (replace the bracketed values with your actual data):"Remember that for all Google SecOps and Agentic SOC queries, my Customer ID is cCUSTOMERID], my Region is IREGION], and my GCP Project ID is EPROJECTID]."Gemini will acknowledge that it has saved these facts to your memory.Step 5: Start QueryingYou are now ready to use SecOps via the main chat! Since Gemini remembers your environment context, you can simply ask security questions.Example Prompts: "Using the Agentic SOC connector, find logon attempts from the last 3 days." "Summarize the latest open cases in SecOps." "Check for any IOC matches related to IP address 8.8.8.8." Closing outThis guide has demonstrated how to seamlessly integrate Google SecOps with Gemini Enterprise using the Custom MCP method. By establishing Gemini as the "front door" for security operations, organizations can realize a true Agentic SOC where analysts perform complex tasks like triaging alerts and querying IOCs through natural language. This no-code setup significantly boosts productivity—enabling faster queries and detections—while driving cost efficiency through the unification of diverse security data sources.  Community Blog Wed, 10 Jun 2026 17:18:15 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/important-the-following-azure-connectors-will-be-deprecated-on-march-30th-2027-7710 Hey folks, As Microsoft is deprecating the Microsoft Sentinel portal and transitions into Unified XDR platform by March 30th 2027, we want to proactively announce that some of the connectors will be considered deprecated on the same date.Additionally, we reviewed existing connectors and observed that there are multiple connectors that are solving the same use case. As part of this initiative, we want to consolidate and also deprecate redundant connectors to offer better supportability.  The following connectors will be considered deprecated on March 30th 2027:Microsoft Azure Sentinel Incident Connector v2  (Microsoft Sentinel) Microsoft Sentinel Incident Tracking Connector (Microsoft Sentinel) Microsoft Defender ATP Connector V2  (Microsoft Defender for Endpoint) Microsoft Defender ATP Connector  (Microsoft Defender for Endpoint) Microsoft Graph Security Connector  (Microsoft Graph Security) Microsoft Graph Office 365 Security and Compliance Connector (Microsoft Graph Security)What is the current impact? The connectors mentioned above will not receive any new FRs enhancement and only critical bugs will be handled (eq data loss). After the deprecation date, the following connectors will stop receiving any support. What connector should be used?Microsoft 365 Defender - Incidents Connector. This connector is designed for Microsoft Defender XDR and it supports ingestion of alerts from all sources (including Microsoft Sentinel, Defender for Endpoint, Defender for Cloud etc). It was built on top of latest Graph API and follows best practices. If there are any gaps that you feel like this connector doesn’t cover - we will prioritise them to be resolved. Note: switching the connector may require updates to the playbooks, because the underlying data structure will be different. Google Security Operations Wed, 10 Jun 2026 17:12:59 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/fetch-alerts-by-entity-via-udm-and-rest-api-7693 Hi,Could anyone help me to fetch alert detections (custom as well as curated) of a specific entity from case using UDM Search Query and REST API?So that I can display it on the case overview.   Google Security Operations Wed, 10 Jun 2026 15:24:13 +0200 https://security.googlecloudcommunity.com/community-blog-42/new-to-google-secops-disintegration-working-with-ttls-in-data-tables-7709 In our last blog, we reviewed how users could set row based expirations using a time to live (TTL) value in data tables and applied this to a rule based example. These concepts can also be applied to dashboards and searches. Everything we did last time was using the UI and as I was writing that blog, I realized that some readers might like to explore TTLs beyond the UI, and see how we could work with these values via the API. So, I decided to write this follow-on that takes a look at TTLs and data tables but uses the API. My intent is to provide you some insight and some curl commands that you can take and apply to your own environments to work with TTLs via the APIs if you wish. In the blog titled Creating Large Reference Datasets and Using Them In Rules, I shared how you can load a data table via the API. We also have previously discussed writing data into data tables using search and rules with the write_row function, so if you need a refresher on getting data into the data table beyond using the UI, those are great places to start. Rather than just throw a bunch of curl commands at you, let’s set the stage. We have a data table named spreader_host_hash which contains the following columns:hostname sha256 file_name last_seen The data table has a default row expiration of seven days. In fact the rows in the data table also reflect the full seven days of TTL as they were added at data table creation. Viewing the data table in the UI highlights this and provides us a starting point to use the API.  If we want to view the data table attributes via the API, we could call the dataTables endpoint. Notice in these curl commands that I have removed my project, region and instance. Just a quick reminder, if you need to quickly find your instance and project, one place you can find this is under SIEM Settings - Profile - Organization Details under Customer ID and GCP Project Number, respectively.curl -X GET \-H "Authorization: Bearer $(gcloud auth print-access-token)" \-H "Content-Type: application/json" \"https://us-chronicle.googleapis.com/v1beta/projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/dataTables/spreader_host_hash" The result of this GET method includes the column names and type as well as when the data table was created and updated. Scrolling through the response, we can also see that there are two rules associated with the data table, the approximate number of rows in the data table, and the default row expiration (rowTimeToLiveUpdateTime) for the data table.{  "name": "projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/dataTables/spreader_host_hash",  "displayName": "spreader_host_hash",  "description": "Listing of hosts, hashes, file names tagged in VT as spreader",  "createTime": "2025-03-31T19:49:10.898263Z",  "updateTime": "2026-06-05T14:09:19.402139Z",  "columnInfo": Z    {      "originalColumn": "hostname",      "columnType": "STRING"    },    {      "columnIndex": 1,      "originalColumn": "sha256",      "columnType": "STRING"    },    {      "columnIndex": 2,      "originalColumn": "file_name",      "columnType": "REGEX"    },    {      "columnIndex": 3,      "originalColumn": "last_seen",      "columnType": "STRING"    }  ],  "dataTableUuid": "b2f6c2af377e40fc8b6dd0ae89b3e124",  "rules": _    "projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/rules/ru_20f08150-499c-4b97-a8e1-0135752492b0",    "projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/ru_271821ec-5738-4570-9584-77209f3e4b6c"  ],  "ruleAssociationsCount": 2,  "rowTimeToLive": "168h",  "approximateRowCount": "6",  "updateSource": "RULE",  "rowTimeToLiveUpdateTime": "2026-05-22T14:42:35.121578Z"} To gain additional insight into the rows within the data table, the dataTableRows endpoint can be called using the data table name.curl -X GET \-H "Authorization: Bearer $(gcloud auth print-access-token)" \-H "Content-Type: application/json" \"https://us-chronicle.googleapis.com/v1beta/projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/dataTables/spreader_host_hash/dataTableRows" This results in the output of each row, each with its own data table row name, as well as the column values in the table and their creation and update times.{  "dataTableRows": e    {      "name": "projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/dataTables/spreader_host_hash/dataTableRows/08470582fa869925ce9ae01d1c646f2c",      "values": m        "wrk-pacman",        "a406a3c1474a57c62f3dbd56aa15d5d732e6a0fe8bbfd7bce9425b132204da8b",        "4848.exe",        "2026-06-01 17:45:14"      ],      "createTime": "2026-06-05T14:04:19.469887Z",      "updateTime": "2026-06-05T14:04:19.469887Z"    },    {      "name": "projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/dataTables/spreader_host_hash/dataTableRows/4a1a6bf87b7785f1f20ffbe18d07d4db",      "values": T        "win-oxygen",        "0d6518769e10895cc1880040fb0680520cb179d37624bd2685368414b4a6e4eb",        "program.exe",        "2026-05-21 20:41:20"      ],      "createTime": "2026-06-05T14:04:19.477759Z",      "updateTime": "2026-06-05T14:04:19.477759Z"    },    {      "name": "projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/dataTables/spreader_host_hash/dataTableRows/8a2e9996a8589a5f5705841af5e60240",      "values": �        "win-helium",        "01153cfe9fe9f1c3460e02d254bbe49b7b07c343061b7630234d95948d8f6106",        "sonic.exe",        "2026-05-28 02:48:16"      ],      "createTime": "2026-06-05T14:04:19.478895Z",      "updateTime": "2026-06-05T14:04:19.478895Z"    },    {      "name": "projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/dataTables/spreader_host_hash/dataTableRows/b996b7e019d50099705e414f59fa3c0f",      "values": �        "win-adfs",        "60c85d1e4b4698e35e83519e16025aa11b6f79a69f02e483a8baf5e97cd04752",        "software.exe",        "2026-04-30 04:17:17"      ],      "createTime": "2026-06-05T14:04:19.591679Z",      "updateTime": "2026-06-05T14:04:19.591679Z"    },    {      "name": "projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/dataTables/spreader_host_hash/dataTableRows/cfff396e9a2c87cad4e937f11f52bd5f",      "values": 8        "win-server",        "0000a30f08a3bc2d09c7a03a12a03c85bc6f01f264652170c49826dd944dc018",        "Avl.exe",        "2026-04-21 09:49:11"      ],      "createTime": "2026-06-05T14:04:19.583999Z",      "updateTime": "2026-06-05T14:04:19.583999Z"    },    {      "name": "projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/dataTables/spreader_host_hash/dataTableRows/f7eac2c7483f8aa66c47c687ddb64958",      "values": �        "oscar.wild.desktop",        "72674e9a3c32d5457c98ef723b938abc0295329c7ec58f9e07a0cb1e99631f48",        "F20B.exe",        "2026-06-05 07:45:15"      ],      "createTime": "2026-06-05T14:04:19.585167Z",      "updateTime": "2026-06-05T14:04:19.585167Z"    }  ]} Notice that at this point there are no additional attributes associated with TTL because these rows are all using the default row expiration. What if we wanted to make a data table change and modify the default row expiration from seven days to five. The dataTables endpoint will accept the PATCH method to modify the default row expiration.curl -X PATCH \-H "Authorization: Bearer $(gcloud auth print-access-token)" \-H "Content-Type: application/json" \-d '{ "rowTimeToLive":"5d" }' \"https://us-chronicle.googleapis.com/v1beta/projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/dataTables/spreader_host_hash?updateMask=rowTimeToLive" When executed, the response includes the time the data table was updated, the columns as well as the updated time to live and the time to live update time.{  "name": "projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/dataTables/spreader_host_hash",  "updateTime": "2026-06-05T14:22:31.480807016Z",  "columnInfo": h    {      "originalColumn": "hostname",      "columnType": "STRING"    },    {      "columnIndex": 1,      "originalColumn": "sha256",      "columnType": "STRING"    },    {      "columnIndex": 2,      "originalColumn": "file_name",      "columnType": "REGEX"    },    {      "columnIndex": 3,      "originalColumn": "last_seen",      "columnType": "STRING"    }  ],  "dataTableUuid": "b2f6c2af377e40fc8b6dd0ae89b3e124",  "rowTimeToLive": "120h",  "rowTimeToLiveUpdateTime": "2026-06-05T14:22:31.480803545Z"} A quick refresh of the UI will show how this is now aligned with what we executed in the API. Let’s move away from modifying the TTL at the table level and move to the row level. There may be times when we want to shorten or lengthen the TTL for a specific row. While dataTableRows.bulkUpdate or dataTableRows.patch may look appealing, currently these API calls will not change TTL settings for rows. Setting aside the UI, another method to modify the row is to read the row of interest, delete it and then add (re-create) the row in question with a row based TTL. I started going down this route but then realized that primary keys can play a role in this and depending on how they are defined for the data table, the process of adding TTLs at the row may be a bit simpler. Let’s take a look. When you create a new data table, you have the opportunity to define a primary key for the table. Primary keys can be one or many columns across a data table and when no columns are defined as primary keys, all of the columns will make up that primary key. This means that when data is written and all columns make up the primary key, a create request to dataTableRows will function more like an update because the columns that make up the primary key won’t change. Let’s take a look.  In the current data table, we did not specify a primary key at data table creation. So if we perform a GET to dataTableRows and identify the row of interest, we could take those row values and create a POST like the one below.curl -X POST \-H "Authorization: Bearer $(gcloud auth print-access-token)"  \-H "Content-Type: application/json" \-d '{  "values": a        "win-adfs",        "60c85d1e4b4698e35e83519e16025aa11b6f79a69f02e483a8baf5e97cd04752",        "software.exe",        "2026-04-30 04:17:17"      ],      "rowTimeToLive": "4d" }' \"https://us-chronicle.googleapis.com/v1beta/projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/dataTables/spreader_host_hash/dataTableRows" The result is that a new row with the same values is written to the data table. However, because the primary key is all four columns, we can’t actually add a new row with those exact same values. This results in the row that contains those values having an updated TTL of four days, the value we specified in the POST above.{  "name": "projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/dataTables/spreader_host_hash/dataTableRows/b996b7e019d50099705e414f59fa3c0f",  "values": �    "win-adfs",    "60c85d1e4b4698e35e83519e16025aa11b6f79a69f02e483a8baf5e97cd04752",    "software.exe",    "2026-04-30 04:17:17"  ],  "createTime": "2026-06-05T15:27:05.235946566Z",  "rowTimeToLive": "4d"} Again, a quick UI refresh results in the same number of rows that we previously had in the data table, but the row in red has an updated TTL of four days. Now, if we perform this same type of POST but change one or more values in the columns so that they no longer align to the primary key, a new row will be created. To highlight this, I’ve got essentially the same curl command except that I’ve changed the timestamp to 00:00:00.curl -X POST \-H "Authorization: Bearer $(gcloud auth print-access-token)" \-H "Content-Type: application/json" \-d '{  "values": f        "win-adfs",        "60c85d1e4b4698e35e83519e16025aa11b6f79a69f02e483a8baf5e97cd04752",        "software.exe",        "2026-04-30 00:00:00"      ],      "rowTimeToLive": "4d" }' \"https://us-chronicle.googleapis.com/v1beta/projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/dataTables/spreader_host_hash/dataTableRows" When this runs, we get a second row with the same host, hash and file_name but a different last_seen and the TTL of four days. With these two additional rows added, let’s run the GET against the dataTableRows again to see the contents of the rows in the data table. Since this can get a little long, I’m going to just display three rows here.{  "dataTableRows": o    {      "name": "projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/dataTables/spreader_host_hash/dataTableRows/08470582fa869925ce9ae01d1c646f2c",      "values": 2        "wrk-pacman",        "a406a3c1474a57c62f3dbd56aa15d5d732e6a0fe8bbfd7bce9425b132204da8b",        "4848.exe",        "2026-06-01 17:45:14"      ],      "createTime": "2026-06-05T14:04:19.469887Z",      "updateTime": "2026-06-05T14:04:19.469887Z"    },    {      "name": "projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/dataTables/spreader_host_hash/dataTableRows/1c8971b92b222992419524ab31a40642",      "values": t        "win-adfs",        "60c85d1e4b4698e35e83519e16025aa11b6f79a69f02e483a8baf5e97cd04752",        "software.exe",        "2026-04-30 00:00:00"      ],      "createTime": "2026-06-05T15:31:16.670527Z",      "updateTime": "2026-06-05T15:31:16.670527Z",      "rowTimeToLive": "4d"    },    {      "name": "projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/dataTables/spreader_host_hash/dataTableRows/b996b7e019d50099705e414f59fa3c0f",      "values": �        "win-adfs",        "60c85d1e4b4698e35e83519e16025aa11b6f79a69f02e483a8baf5e97cd04752",        "software.exe",        "2026-04-30 04:17:17"      ],      "createTime": "2026-06-05T15:27:05.144943Z",      "updateTime": "2026-06-05T15:27:05.144943Z",      "rowTimeToLive": "4d"    },  ]} Notice that the first row does not have a specific rowTimeToLive value so it uses the data table’s default row expiration. The other two rows that we read in have a rowTimeToLive of four days. BTW, if you have individual rows with a TTL like we do, these will take precedence over a change to the default row expiration being modified. If we issued the PATCH method like we did earlier to adjust the default row expiration, the TTL for the rows that have not been modified will all move with the data table but those rows that have their own specific TTL will not change. At the start of this blog, I showed you the attributes for the data table we used in our example. Let’s view the attributes using that same GET statement, but for a table where I’ve defined the primary key as being the hostname, sha256 and file_name columns. The idea with that combination is that if we identify events with those three values being the same, we could update the last_seen field for that data table row.Here are the attributes for that data table. Notice in the column info, in addition to the column name and type, keyColumn is set to true for those three fields.{  "name": "projects/{PROJECT}/locations/{REGION}/instances/{INSTANCE}/dataTables/spreader_test",  "displayName": "spreader_test",  "createTime": "2026-05-22T16:36:35.815812Z",  "updateTime": "2026-06-05T16:50:21.104437Z",  "columnInfo": d    {      "originalColumn": "hostname",      "keyColumn": true,      "columnType": "STRING"    },    {      "columnIndex": 1,      "originalColumn": "sha256",      "keyColumn": true,      "columnType": "STRING"    },    {      "columnIndex": 2,      "originalColumn": "file_name",      "keyColumn": true,      "columnType": "STRING"    },    {      "columnIndex": 3,      "originalColumn": "last_seen",      "columnType": "STRING"    }  ],  "dataTableUuid": "af2a1c3d5c40452985252024c6fb155c",  "rowTimeToLive": "336h",  "rowTimeToLiveUpdateTime": "2026-05-22T16:36:36.349477Z"} With that, let’s bring this blog to a close. I hope you have a better understanding of how you can use the API to work with data tables. Here are a few things to keep in mind:Row level TTLs take precedence over Default Row Expirations While an update or PATCH API call doesn’t exist to add a row level TTL, reading the row and creating a new one can provide a similar method to adding a row TTL Pay attention to the primary key for the table so that you don’t inadvertently end up creating additional rows in the data table Whether you use the UI or the API, TTLs at the data table and row level can be very useful to an analyst. Hopefully this blog and the previous one provides you with additional information that you can apply to your data tables! Community Blog Wed, 10 Jun 2026 14:18:03 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/secops-soar-integration-via-remote-agent-7676 We are configuring remote agents for the SOAR to communicate internally to our tools. We have successfully deployed the remote agents (docker) and they are showing "Lived" status on the web ui.However, during the integration configuration, when we check "run remotely" and select the remote agent, we are unable to save the config. It's showing error "An error occurred while saving instance configuration". We configured everything as the documentation indicated including the service account mapping. The remote agent container does not show any error.  Google Security Operations Wed, 10 Jun 2026 13:28:45 +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 Wed, 10 Jun 2026 10:24:54 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/native-dashboards-unexpected-error-when-querying-soar-custom-fields-7683 Hi all,I am attempting to create a new Table chart in Native Dashboards utilizing the recently released SOAR Custom Fields feature.We are referring the Documentation: https://security.googlecloudcommunity.com/google-security-operations-2/new-feature-support-for-soar-custom-fields-in-native-dashboards-7604 I am trying to display standard case fields alongside two of our custom text fields: "Case ID" and "CID".  Per the documentation, I am using the required syntax paths: - case.custom_fieldsl"Case ID"].string_seq.string_vals - case.custom_fieldsl"CID"].string_seq.string_vals Whenever I attempt to run the query, the UI returns the following generic backend error: "An error occurred with your query. An unexpected error occurred. Loading Complete." We have already tried multiple troubleshooting variations to isolate the syntax, all of which fail:  Attempt 1(Using array_distinct in outcome): $case_name = case.namematch:$case_nameoutcome:$custom_case_id = array_distinct(case.custom_fields_"Case ID"].string_seq.string_vals) $custom_cid = array_distinct(case.custom_fields_"CID"].string_seq.string_vals) $total_cases = count(case.name)Result: "An unexpected error occurred. When checked the error in developer tools, we found the error “generic::invalid_argument: Querying custom fields is not supported yet: invalid argument” Could someone help us understand why custom fields are not supported yet?  Google Security Operations Wed, 10 Jun 2026 05:21:33 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/why-do-we-need-workspace-privileges-if-we-already-have-workspace-activity-workspace-users-workspace-groups-and-workspace-alerts-7685 Hi Google Community,We have already enabled these Google Workspace logs:WORKSPACE_ACTIVITY WORKSPACE_USERS WORKSPACE_GROUPS WORKSPACE_ALERTSWe want to understand clearly what WORKSPACE_PRIVILEGES will do differently compared to the above log sources.Main Questions:What extra things does WORKSPACE_PRIVILEGES handle that the other parsers (especially WORKSPACE_ACTIVITY) do not cover well? Can you explain the benefits of enabling WORKSPACE_PRIVILEGES? Please give some examples of logs/events: How they look in WORKSPACE_ACTIVITY (or others) How they look better / different in WORKSPACE_PRIVILEGES We want to confirm the real value before enabling it for the client. Google Security Operations Tue, 09 Jun 2026 21:32:05 +0200 https://security.googlecloudcommunity.com/webinars-75/introducing-the-evolution-of-recaptcha-google-cloud-fraud-defense-7697 This webinar introduces Google Cloud Fraud Defense, the next-generation evolution of reCAPTCHA Enterprise. As artificial intelligence matures, traditional security metrics (like tracking mouse movements or typing speed) are no longer enough to stop malicious actors. AI agents can now mimic human behavior with terrifying accuracy.This session covers how Google is shifting from a "gatekeeper" mindset to an "enabler" mindset—introducing intelligent, unified trust that precisely blocks automated threats and rogue AI bots while keeping the user experience completely frictionless for real human customers and authorized AI partners.What you will learn:The Rebrand from reCAPTCHA: Learn why reCAPTCHA has expanded into the comprehensive Google Cloud Fraud Defense platform to secure the entire customer journey (from signup to checkout). The Rise of the "Agentic Web": Bad actors are using cheap, industrialized AI to launch sophisticated multi-stage fraud campaigns. This webinar shows you how to fight back. AI-Resistant Friction: See a live demonstration of Google's new QR Code Challenge, a private-preview feature designed to force a human-in-the-loop by leveraging secure mobile device attestation. Granular Control: Discover the new Policy Engine, giving security teams the power to write specific rules to allow good bots (like search indexers) and block malicious scrapers or credentials-stuffing AI.  Key Discussion Points & Timestamps02:48 – Community Updates & Resources Announcements regarding upcoming training workshops, community forum perks, and new security resource links. 07:38 – The Changing Fraud Landscape Why advanced AI has broken traditional security signals, why a "block everything" approach kills sales, and how to transition to intent-based security. 14:51 – The Evolution of reCAPTCHA A quick retrospective of reCAPTCHA's decade-long journey and how Google leverages trillions of global network signals to spot botnets. 21:03 – New Feature Announcements A summary of newly released tools, including dedicated Account Takeover (ATO) risk metrics and flexible security APIs for mobile and web. 24:15 – Introduction to the Policy Engine How the new control panel allows teams to easily create automated rules that welcome good bots while stopping malicious ones. 30:35 – Next-Gen QR Code Challenges How the new mobile-scanning verification loop completely blocks automated AI systems while keeping things easy for humans. 32:07 – Live Simulation & Console Tour A live demo of an AI bot trying to checkout on a website, how the system catches it, and a quick tour of the new management dashboard. 45:07 – The Google Scale Advantage & ROI Data How Google's massive global infrastructure protects local businesses, plus real-world data from a recent IDC study on the platform's financial value. 48:00 – Audience Q&A & Wrap-Up Product managers answer user-submitted questions about defeating advanced AI, reducing e-commerce chargebacks, and avoiding false positives.  Have questions about this webinar? Post below and we’ll get back to you!  Webinars Tue, 09 Jun 2026 21:30:23 +0200 https://security.googlecloudcommunity.com/security-command-center-4/empower-your-cloud-audits-compliance-manager-in-security-command-center-7696 I speak with customers daily. A challenge many security teams face isn't just finding vulnerabilities—it is mapping those vulnerabilities to compliance frameworks in a way that satisfies both internal security teams and external auditors.The monitoring and auditing capabilities of Compliance Manager in Security Command Center can fundamentally change how you define, monitor, and enforce your cloud compliance postures. What is Compliance Manager? Compliance Manager is a native SCC capability that uses software-defined cloud controls to assess, monitor, and actively enforce compliance across your Google Cloud infrastructure. https://docs.cloud.google.com/security-command-center/docs/compliance-manager-overviewInstead of relying on disconnected compliance dashboards, Compliance Manager maps Security Health Analytics (SHA) detectors directly to specific regulatory requirements, allowing you to see exactly where your workloads stand in real time. Three Operational Modes of Cloud ControlsCompliance Manager allows you to operationalize your security frameworks using three distinct modes:Detective Mode: Monitors your resources for violations and generates alert findings when drift is detected. This mode does not block any actions and serves as your continuous monitoring baseline.Detective Mode Preventive Mode Actively blocks API transactions or infrastructure changes that violate your defined cloud controls, using guardrails to prevent non-compliant infrastructure from being deployed in the first place.Preventive Mode Audit Mode Used specifically to audit your environment against your strict compliance obligations, serving as your single source of truth to collect evidence for external auditors.Audit Mode Step-by-Step: Deploying a Compliance Framework To start monitoring your organization against a framework (such as CIS Controls 8.0 or PCI-DSS 4.0), follow this deployment path.  IAM Best Practice (Least Privilege): To manage postures and compliance configurations, ensure your administrators are only granted the Security Posture Admin (roles/securityposture.admin) role at the Organization level. Avoid granting broad Owner or Editor primitive roles.Set up permissions Step 1: Access Compliance ManagerIn the Google Cloud Console, navigate to Security Command Center > Compliance > Monitor. ​​​​​​ Assess compliance in Google Cloud console   Review the pre-loaded Security Essentials framework (enabled by default for all tiers) Security Command Center > Compliance > Configure. ​​​​​​ Manage frameworks  Step 2: Define and Customize Your PostureNavigate to the Security Posture service inside SCC Security Command Center > Posture Management > Templates Posture Templates   Select Create Posture and choose to either build a custom posture or use a predefined template (such as the CIS Google Cloud Computing Foundations Benchmark) Create a Posture Map your chosen Compliance Manager cloud controls into your posture policy sets. Select the level of your resource hierarchy where you want to enforce or audit compliance (Organization, Folder, or Project). Note that child folders and projects will inherit this posture. Step 3: Monitor and Remediate DriftOnce a framework posture is deployed, Compliance Manager and the underlying Security Posture Service begin continuous evaluation of your cloud assets. Note: Initial findings can take approximately six hours to populate in the dashboard after a fresh posture deployment.  Monitor Posture Drift  Any configuration change that violates a control will be flagged as a Compliance Drift Finding in the SCC dashboard. Reducing the Noise: Configuring Smart Mute Rules We know that a common hurdle for security operations is "alert fatigue." If you have legacy systems or intentionally isolated testing environments that violate a compliance control by design, you must manage these findings efficiently to focus on real risks.If both Security Health Analytics (SHA) and Compliance Manager evaluate the same resource, duplicate findings with different provider IDs can occur. To keep dashboards clean and maintain reliable audit tracking, you should write specific Mute Rules to programmatically silence these duplicate or expected findings:  Technical Step: Creating a Compliance Mute RuleGo to the Findings page in SCC. Filter the findings to isolate the compliance false positive. For example: category="AUDIT_LOGS_NOT_ENABLED" AND resource.project_ids = "my-test-sandbox-123" Click Create Mute Rule. Define the mute rule: Scope: Select whether the rule applies at the organization, folder, or project level. Condition: Use Common Expression Language (CEL) to target the exact resource and compliance category:Common Expression Language (CEL) Mute State: Select Muted (retains the finding for auditing but hides it from active dashboards).  Using CEL-based mute rules ensures your compliance scores remain accurate for production environments while keeping sandbox noise out of your analyst queues. Official Documentation Reference List Here are the direct, updated URLs to share with customers or technical teams looking to implement these capabilities:Compliance Manager Overviewhttps://docs.cloud.google.com/security-command-center/docs/compliance-manager-overview Compliance Manager Cloud Controls Referencehttps://docs.cloud.google.com/security-command-center/docs/compliance-manager-cloud-controls Security Posture Service Overviewhttps://docs.cloud.google.com/security-command-center/docs/security-posture-overview Assess Compliance in SCChttps://docs.cloud.google.com/security-command-center/docs/compliance-management Security Command Center Primary Documentation Portalhttps://docs.cloud.google.com/security-command-center/docs   Security Command Center Tue, 09 Jun 2026 19:21:31 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/cannot-import-name-extract-action-param-from-tipcommon-7678 I am getting cannot import name 'extract_action_param'  & ‘extract_configuration_param’ from 'TIPCommon' error when I am testing the updated SOAR integration in staging mode for Azure Active Directory & Google Chronicle SOAR integrations. How to resolve this error? Google Security Operations Tue, 09 Jun 2026 16:32:11 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/multi-tenancy-in-google-secops-siem-soar-7617 Hi All,Anyone has performed a complete end to end implementation of multi tenancy in google secops SOAR SIEM.I need real example with implementation steps for typical GCP environment.Also if any relevant documents will be helpful Google Security Operations Tue, 09 Jun 2026 16:24:36 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/job-schedule-to-check-log-source-status-7673 How do I automate the process to send an email alert to team if log source is not reporting.1.SOAR Dashboard: I have created a query to fetch last reported time of each log_type, but how do I trigger an email if last reporting time is greater than x hours or something?SOAR Job Script: Anyone has used this to automate this?  Google Security Operations Tue, 09 Jun 2026 14:19:27 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/how-to-parse-json-array-in-chronicle-siem-562 Hi All,I have already created a custom parser that works well for JSON object coming through logs. However, I now need to update the parser to support JSON arrays. but I'm unsure how to loop through a JSON array.Sample log:  [{"test": "testing","hostname":"hostname1"},{"test":"testing","hostname":"hostname2"}]Any guidance or assistance on how to resolve this issue would be greatly appreciated.Thank you! Google Security Operations Tue, 09 Jun 2026 10:15:43 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/case-wall-permissions-locking-down-case-downloads-7682 We have a SOAR Graph mail connector to a mailbox where users submit suspicious emails. Each connector ingestion adds any potentially malicious attachments to the case wall.Is there any way to adjust the permissions so that someone could see the playbook results, the case views etc, post to the case wall but not download a file auto attached to the case wall? Google Security Operations Tue, 09 Jun 2026 05:15:53 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/how-soar-migration-works-when-using-cloud-identity-integration-7592 We have completed Stage 2 of SOAR Migration for our SecOps environment using Cloud Identity integration.However, I'm having trouble understanding the IAM mechanism as described in the documentation. Could you please explain it to me?* My understanding of the requirements for SOAR Migration is as follows, but is this correct? (I'm concerned that the requirement to map the PERMISSION GROUP on the Group Mapping page and the mandatory assignment of predefined roles will limit the permission control of SOAR-side functions.)* I've also heard that Workforce Identity integration doesn't have this restriction and allows operation with only custom roles. Why does the more native Cloud Identity integration have this restriction?■IAM RolesWhen accessing SecOps via Cloud Identity integration, it is absolutely necessary to assign one of the following three roles. I was previously told by support that this is required, like an entry ticket for SecOps.roles/chronicle.soarAdminroles/chronicle.soarThreatManagerroles/chronicle.soarVulnerabilityManager■SecOps Group MappingWhen using Cloud Identity integration, one of the three roles listed above must be registered in the IDP/USER GROUP column.(Individual email addresses can be accessed without explicit mapping.)The fact that the column name is IDP/USER GROUP, yet an IAM Role needs to be registered here, is causing further confusion.https://ssecret].backstory.chronicle.security/sp-settings/idp-group-mappingIn our environment, we have registered the roles shown in the image below. The PERMISSION GROUP column must be explicitly mapped to allow access to SecOps. Google Security Operations Mon, 08 Jun 2026 19:09:32 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/how-to-suppress-alerts-were-ingested-into-environment-x-which-does-not-exist-notifications-for-unmapped-namespaces-7655 We use the Google Chronicle Alerts connector with dynamic environment routing:Environment Field Name: event_metadata_baseLabels_namespaces_1 Environment Regex Pattern: ^(IFAP|UNIFAP|IFPI)$This correctly routes alerts from mapped namespaces (IFAP, UNIFAP → SOC-AP environment; IFPI → SOC-PI environment). Namespaces not matched by the regex (e.g., IFES, IFTM) correctly fall back to the Default Environment.Problem: Even though unmatched namespaces fall back to Default as intended, we keep receiving email notifications:"Alerts were ingested into Environment IFES which does not exist in the system. Please create this Environment in the Settings in order to see the alerts."These institutions don't have a dedicated SOC yet, so we intentionally want them in Default — not their own environment.Questions:Is there a supported way to suppress these "environment does not exist" notifications without creating an environment for every namespace? Can the connector be configured so unmatched namespaces route silently to Default without triggering the notification? We checked User Preferences > Notifications (Cases) — this notification type isn't listed there. Where is it controlled?We expect many new namespaces over time (one per institution), so creating an environment for each just to silence the alert isn't scalable. Google Security Operations Mon, 08 Jun 2026 17:22:43 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/native-dashboard-ingestion-log-volume-gb-returns-no-data-for-scoped-data-rbac-users-while-log-count-works-7654 We have Data RBAC configured to segregate visibility between regional SOC teams (per namespace). A scoped analyst group (GRP_SECOPS_SOC-AP) is restricted to namespaces IFAP and UNIFAP via a Data Access Scope using only the standard Namespace label (no custom labels).IAM bindings on the group (all with the condition resource.name.endsWith("/soc-siem-ap")):Chronicle API Restricted Data Access Chronicle API Editor Chronicle Restricted Data Access Reader (no condition — base UI) Custom role with chronicle.nativeDashboards.get/list, chronicle.dashboardCharts.get/list, chronicle.dashboardQueries.get/listProblem: On a native dashboard panel using the Ingestion metrics data source, the following query returns no data for the scoped analyst, but returns data correctly for a global (unrestricted) admin:ingestion.component = "Ingestion API"$namespace = ingestion.namespacematch: $namespaceoutcome: $Total_Log_Volume = math.round(sum(ingestion.log_volume) / (1000 * 1000 * 1000), 4)If we change the outcome to count(ingestion.log_count), the scoped analyst does see data (correctly filtered to IFAP/UNIFAP). Only the byte/volume metric (sum(ingestion.log_volume)) comes back empty under the scope.Questions:Is ingestion.log_volume (bandwidth/bytes) expected to not resolve under a Namespace-based Data RBAC scope, while log_count does? If this is by design, what is the supported way to expose approximate ingestion volume (GB) to scoped users in a native dashboard? If not by design, what IAM permission or instance setting enables ingestion volume metrics for scoped users?Instance region: US. Google Security Operations Mon, 08 Jun 2026 16:23:49 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/what-s-new-in-google-secops-2026-06-07-7680 Another great weekly update from Chris Martin, Google Security Specialist. These are valuable insights! Thank you Chris.  What’s New in Google SecOps for the interval June 1st through June 7th 2026. Highlights  You can now Investigate Detections in SecOps UDM Search  Essential reading from Simone Bruzzechesse on SecOps API and Ingestion Health monitoring with Cloud Monitoring Essential reading from Greg Kushmerek on That Looks Different Than Yesterday Look out for the FREE John Stoner Virtual SecOps Workshops and Dave Nehoda Webinar: Detecting Compromised AI Agents  Product Updates & New Features Google SecOps Release Notes from Google Cloud DocumentationA previously announced ‘Manage access to preview features’ capability for Google Chronicle SecOps has been rolled back. Read More] This explains why I couldn’t see this on any tenants from last week!SecOps SIEM Investigate detections in Search from Google Cloud DocumentationThis article outlines how to use Google Security Operations’ search features to investigate security detections, perform entity-based threat hunting, and identify incident scope. uRead More] You can now query Detections directly in UDM Search, with the associated UX updated accordingly Query Detections in UDM Search  New Doc: Agentic SOC > Security Tokens from Google Cloud DocumentationThis document details Google SecOps Security Tokens, which serve as the primary billing and metering unit for Google security agents nRead More] This info was available in other docs, but now there is a dedicated documentation on how Google SecOps Security Tokens work, and their cost. Google Threat Intelligence Seeking Counsel: Ongoing Targeted Campaign Against US Law Firms from Google Cloud BlogMandiant has identified an ongoing, financially motivated data theft extortion campaign by the threat cluster UNC3753, which is targeting US law firms. lRead More] BindPlane OTEL v1.101.1 from GitHubThis article announces the release of v1.101.1 for the observIQ bindplane-otel-collector, featuring new enhancements such as the Azure Authenticator Extension. aRead More] AI Scaling AI Agents: A Step-by-Step Guide to Deploying ADK on GKE Autopilot from Google Cloud BlogThis article provides a step-by-step guide on deploying and scaling AI agents built with Google’s Agent Development Kit (ADK) on GKE Autopilot for robust, production-ready infrastructure. Read More] Connecting AI agents with unstructured data using Google Cloud Storage MCP Servers from Google Cloud BlogThe article highlights Google Cloud Storage (GCS) as a foundational component for AI agents, emphasizing its role in securely connecting AI agents with unstructured data to provide context and support enterprise deployments. rRead More] Introducing the Google Colab CLI from Google Cloud BlogGoogle has announced the Colab Command-Line Interface (CLI), a new tool enabling developers and AI agents to connect local terminals to remote Colab runtimes for easy access to GPUs, remote script execution, and artifact retrieval. sRead More] Bringing Gemma 4 12B to your Laptop: Unlocking Local, Agentic Workflows with Google AI Edge from Google Cloud BlogGoogle’s Gemma 4 12B model is now available on laptops with 16GB RAM via Google AI Edge, enabling local agentic and multimodal AI workflows, including visual insights and offline voice dictation. oRead More] Gemma 4 12B: The Developer Guide from Google Cloud BlogGoogle has released Gemma 4 12B, a new dense, multimodal AI model designed for high-performance local execution on consumer devices, featuring a novel encoder-free architecture that directly feeds multimodal data into its LLM backbone. -Read More] Adoption Guides & Deep Dives SecOps API and Ingestion Health monitoring with Cloud Monitoring from Google Cloud Security Community (Simone Bruzzechesse)The article highlights how Google Cloud Security Operations leverages Cloud Monitoring to ensure the health of SecOps APIs and data ingestion, which is vital for effective threat detection and incident response in a modern SOC. Read More]GitHub - GoogleCloudPlatform/secops-toolkitContribute to GoogleCloudPlatform/secops-toolkit development by creating an account on GitHub.github.com Microsoft Telemetry to UDM Mapping: Part 1 — Foundations from Google Cloud Security CommunityThis article, the first in a series, provides foundational guidance on effectively mapping Microsoft telemetry to a Unified Data Model, addressing gaps in Microsoft’s documentation regarding event value, SIEM normalization, and advanced threat detection. oRead More] Microsoft Telemetry to UDM Mapping: Part 2 — On-Premises Detection from Google Cloud Security CommunityThis article, part of a series, details how to map Microsoft on-premises telemetry sources like Active Directory, Kerberos, Sysmon, and Windows Security Events to Google Security Operations’ UDM for detecting various cyber threats. SRead More] Microsoft Telemetry to UDM Mapping: Part 3 — Cloud Detection & Cross-Source Correlation from Google Cloud Security CommunityThis article, part three of a series, details mapping Microsoft cloud infrastructure telemetry (Entra ID, Office 365, Defender) to UDM for improved cloud detection and cross-source correlation, enabling end-to-end attack chain detection. DRead More] Community & Events FREE John Stoner Virtual SecOps Workshops and Dave Nehoda Webinar: Detecting Compromised AI Agents from Google Cloud Security CommunityGoogle Cloud is offering free SecOps workshops and a webinar with Dave Nehoda focused on detecting compromised AI agents, detailing how prompt injections can exploit cloud infrastructure and how to build detection frameworks. Register now! Join us for a foundational, two-hour virtual workshop designed to simplify Google SecOps navigation by aligning key terminology with everyday analyst workflows. Through interactive, hands-on examples, you will explore real-world user journeys, search concepts, and data connectivity to build the perfect baseline for future technical training. Register for AMER/EMEA (8AM — 10AM PDT / 3PM — 5PM UTC) Register for APJ (4PM — 6PM PDT / 11 PM — 1AM UTC) Agent Skills for Private Knowledge Collections in GTI from Google Cloud Security CommunityGoogle Threat Intelligence (GTI) has introduced Private Knowledge Collections, enabling users to create private instances of GTI objects and integrate local threat intelligence with Google’s global dataset for enhanced analysis. sRead More] Visual Investigations and Campaign Mapping in Google Threat Intelligence Threat Graph from Google Cloud Security CommunityThis article details how visual investigation and campaign mapping, specifically using entity relationship graphs in Google Threat Intelligence’s Threat Graph, provides a superior methodology for tracking sophisticated adversaries by identifying connections between various threat indicators. eRead More] Webinar Alert (6/16): Stop Secret Sprawl and Secure Your AI Agents and Workloads from Google Cloud Security CommunityThis webinar alert discusses the critical issue of “secret sprawl,” where sensitive credentials like API keys are increasingly exposed, a problem significantly exacerbated by the rapid adoption of AI technologies. fRead More] When: June 16, 11 am EST/ 8 am PST Register now: https://www.brighttalk.com/webcast/18282/668534 3rd Party Blogs Creating an Agentic Skill in just a few hours from Greg KushmerekThe article describes how Greg Kushmerek utilized an agentic coding platform called Antigravity to create a Model Context Protocol (MCP) skill for Google SecOps Risk Analytics in just a few hours. This skill enables AI to generate complex and syntactically correct YARA-L rules by providing necessary context, documentation, and error-correcting scripts.uRead More]GitHub - GooGKush/secops-risk-analytics: Skill for using SecOps Risk Analytics in rules and searchSkill for using SecOps Risk Analytics in rules and search - GooGKush/secops-risk-analyticsgithub.com Podcasts & YouTube️ Behind the Binary: When AI Features Create Zero-Click Exploits: The Pixel 9 Chain with Seth Jenkins from YouTubeThis episode discusses how AI features, exemplified by a vulnerability chain found in the Pixel 9, can lead to the creation of zero-click exploits. nWatch] Wiz AI Threat Readiness Pillar 1: Reduce Critical Exposures & Scan with AI from Wiz BlogThe article discusses the first pillar of the AI Threat Readiness Framework, which focuses on reducing critical exposures and utilizing AI for scanning, and highlights Wiz’s contribution eRead More] Eliminate Critical API Attack Paths with Wiz API SPM from Wiz BlogWiz API SPM is now generally available, offering customers tools to discover, assess, and prioritize remediation for API vulnerabilities to prevent breaches. hRead More] Miasma: Supply Chain Attack Targeting RedHat npm Packages from Wiz BlogThe article details ‘Miasma’, a supply chain attack exploiting RedHat npm packages, and provides guidance on detecting and mitigating the associated malicious software. nRead More] Platform Issues RESOLVED: Google SecOps SIEM customers in the US region may be experiencing delays in data ingestion for cloud-based v2 feeds from Cloud Google StatusGoogle SecOps SIEM customers in the US region are experiencing delays in data ingestion for cloud-based v2 feeds, with an engineering team actively investigating the issue. eRead More]  Google Security Operations Mon, 08 Jun 2026 16:08:52 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/can-google-secops-dashboards-query-mandiant-fusion-ioc-global-context-data-directly-7674 Hello everyone,I am trying to build a dashboard in Google SecOps that displays statistics about malicious IP addresses observed in firewall traffic and correlated against Mandiant Fusion IOC data.The correlation works correctly in Log Search using a query similar to the following:$e.metadata.log_type = "CHECKPOINT_FIREWALL"$e.security_result.action = "ALLOW"$origen = $e.principal.ip$origen != ""$gti.graph.metadata.product_name = "MANDIANT_FUSION_IOC"$gti.graph.metadata.vendor_name = "MANDIANT_FUSION_IOC"$gti.graph.metadata.source_type = "GLOBAL_CONTEXT"$gti.graph.metadata.threat.verdict_info.confidence_score >= 90$ip_ioc = $gti.graph.entity.ip$origen = $ip_iocThe query returns results successfully in Log Search.However, when I try to use the same logic in a Dashboard/Report widget, no data is returned. I also tested simplified queries that only reference MANDIANT_FUSION_IOC graph entities (without any UDM event correlation), and they still return no results in Dashboards.My questions are: Are Dashboard/Report queries allowed to access graph / GLOBAL_CONTEXT data sources such as MANDIANT_FUSION_IOC? Is there any limitation preventing dashboards from querying entity graph data directly? Any guidance or documentation references would be greatly appreciated.Thank you. Google Security Operations Mon, 08 Jun 2026 05:41:12 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/overlapping-text-in-event-data-7666 Some of our event field names are quite long and subsequently overlap into the event’s value. Is there a way to fix this? We don’t appear to be able to drag or move the columns at all or expand the view.  Thanks,Chris Google Security Operations Mon, 08 Jun 2026 05:18:48 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/account-level-restriction-persists-after-project-reinstatement-appeal-ticket-removed-by-moderator-7002 My GCP account (project ID: project-0b2ff1f9-abbb-46e6-bc1) was restricted on Feb 13, 2026 for a policy violation caused by a software bug — a flawed retry pattern that sent excessive Vertex AI API requests.I submitted an appeal and provided detailed corrective steps. On March 9, I received a project reinstatement email confirming the project is reinstated. However, the account-level restriction still blocks all access to GCP Console, CLI, and all services.Could someone help look into this? The project has been reinstated but the account-level restriction remains, so I cannot access the project to verify compliance. Google Security Operations Sat, 06 Jun 2026 19:27:02 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/suspended-google-cloud-project-no-response-2-weeks-later-urgent-7361 Hi, my Google Cloud/Firebase project was suspended for suspected key misuse (account_hijacked).I submitted an appeal, but after 9 days I still have no response.This is now a production outage: about 1200 paying users cannot log in and trust for my application is starting to go down rapidly. The business impact this has is nothing short of a disaster, and the students that’s using the application to study for exams are panicking and asking for refunds.What I already did:Removed exposed credentials from files/repos Rewrote Git history and force-pushed cleaned history Removed old test/dev files with hardcoded keys Tightened secret handling to prevent re-commitWhat I am ready to do immediately when access is restored:Rotate/revoke all affected keys Apply strict key restrictions (referrer/IP/API allowlist) Move secrets to Secret Manager Review IAM, billing, and audit logsI’m currently blocked because suspended status prevents console access.Can anyone advise:how to confirm the appeal is active and not missing info, and whether I should only follow up in the same appeal thread, or if that will delay everything further? Google Security Operations Fri, 05 Jun 2026 20:46:18 +0200 https://security.googlecloudcommunity.com/security-command-center-4/urgent-gcp-project-suspended-for-resource-hijacking-unable-to-access-iam-to-rotate-leaked-keys-7343 Hello everyone,I am seeking urgent guidance regarding a GCP project suspension. My account was recently suspended, and I received an email stating that the project was engaged in abusive activity consistent with "hijacked resources."The Situation:Access Denied: My production application is currently offline. Whenever I attempt to access the IAM & Admin or APIs & Services dashboard to investigate, I am automatically redirected to the suspension warning page. Unknown Leak: I have audited my frontend/backend/app environment variables (.env) but haven't found any obvious exposures. Account Lockout: Because I cannot access the IAM dashboard or Cloud Logging, I am unable to identify which credential is being abused or delete the compromised keys. Appeal Status: I submitted an appeal over a week ago, but I have not received a response, and my production app remains affected.My Questions:Is there a way to access Cloud Logging or Security Command Center via the SDK or a restricted console view while the project is suspended to identify the source of the abuse (e.g., specific IP addresses or hijacked keys)? Can I programmatically revoke all existing API keys via gcloud or a similar tool if the web console is locked? Are there specific channels to escalate an appeal when the suspension is caused by a hijacked resource rather than a policy violation?Any advice on how to regain enough access to rotate my credentials and secure the project would be greatly appreciated. Security Command Center Fri, 05 Jun 2026 16:02:22 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/tenable-io-integration-into-googlesecops-need-help-7668 Dear All, I need your help to understand  log ingestion for vulnerability management tool.   Currently in our environment , we are managing tenable.io vulnerability management console. We need to on-board the  vulnerability logs into GoogleSecops. On search , we found the below article  which is purely related to SOAR concept but we wish to understand how to on-board the logs from SIEM concept. Request  your kind support to address  this issue. As we are running out of time.                                                                    Tenable.io  |  Google Security Operations  |  Google Cloud Documentation Google Security Operations Fri, 05 Jun 2026 15:00:40 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/production-firebase-project-suspended-13-days-for-suspected-credential-exposure-no-evidence-of-abuse-seeking-guidance-on-appeal-timing-7659 Hi all,Looking for advice from anyone who has navigated a "Hijacked Resource" suspension or has insight into typical Trust & Safety appeal timelines.TL;DR: Production Firebase project (live consumer app) was suspended on May 21 for suspected credential compromise. I had unintentionally committed service account keys to a private repo (months ago) and it has only been pulled by 2 developers.  Despite this exposure, my audit logs show no abusive activity, no foreign IP usage, and total billing for the month was about $1.99. I responded to the Trust & Safety follow-up on May 25 with a full remediation report. 13 days in, still no response. Console is locked behind the appeal screen.What I've done:Revoked all user-managed keys on affected service accounts via gcloud CLI (only SYSTEM_MANAGED keys remain) Deleted exposed Gemini API keys in AI Studio Purged credentials from version control history Rotated third-party keys (payment processor and others in progress) Reviewed 120 days of Admin Activity audit logs — no unauthorized principals, no unfamiliar IPs, no unauthorized resource creation Drafted org policy to disable SA key creation and moved secrets to Secret ManagerWhat I'm trying to figure out:Has anyone seen a "Hijacked Resource" appeal take this long when there's no evidence of actual abuse in the logs? Is there a way to regain limited console access (specifically IAM and APIs & Services) to complete credential rotation while the appeal is pending? Right now I'm locked behind the appeal screen and can't fully audit/rotate from the UI. I may have hurt my case by submitting multiple appeals on May 21 as I discovered new information — has anyone seen this affect review timelines? Any guidance on appropriate escalation paths I haven't tried? I've filed a support case and a billing support case in addition to the appeals.Business impact: This project supports a live music streaming app with active creators. Today is the 1st of the month and creators can't request payout through the suspended dashboard. Looking at manual payout processes in parallel, but reinstatement would obviously be the cleanest resolution.Happy to share the full appeal response privately if anyone with Google contacts can help route this. Project ID available on request.Thanks for any guidance. Google Security Operations Fri, 05 Jun 2026 08:52:03 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/save-time-parser-is-more-permissive-than-the-runtime-parser-7664 I ran across an error in the detection pane for a rule, that does not show up in the rule editor. How is that even possible?  Google Security Operations Fri, 05 Jun 2026 08:02:55 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/create-cases-in-secops-based-on-received-emails-7480 Hi! Is it possible to create cases in SecOps based on emails received in O365?Any experiences? Google Security Operations Fri, 05 Jun 2026 07:01:19 +0200 https://security.googlecloudcommunity.com/community-blog-42/new-to-google-secops-fade-to-grey-managing-table-ttl-and-row-expiration-7601 We’ve previously discussed a number of capabilities that data tables provide Google Security Operations (SecOps) including handling large data sets, writing to data tables from rules and searches as well as extending the entity graph for more advanced use cases. If you would like to learn more about any of these, here is some of our past work on these topics.Writing to Data Tables from Rules in Google SecOps Creating Large Reference Datasets and Using Them In Rules Write Once, Update Many with Data Tables An Introduction to Extending the Entity Graph with Data Tables Overriding the Entity Graph with Data Tables Writing Rules Overriding the Entity Graph with Data Tables Excluding Entities from Rules Using Data Tables Appending Data Tables to the Entity Graph Today, we are going to explore row expiration and time to live (TTL) with data tables. There may be times when the data in a data table needs to be aged out and TTLs can make this occur without continual user pruning and intervention. These capabilities can be layered onto concepts that have been previously discussed and can provide you additional flexibility when using data tables in SecOps. The contents of a data table never expire, unless you set an expiration. That expiration can be set as a Default Row Expiration for the entire table or at the individual row level. The time range for the expiration ranges from one hour to 365 days. The examples we go through today will all be on the one hour end of that range, but the concepts are the same.   To set this value at the data table, click the Default Row Expiration button above the tabular view. The pop-up above allows us to set the row expiration in hours or days as well as Save to draft. It’s worth mentioning that once you do this, you will still need to save the table to lock this expiration range in. If you decide you want to remove the expiration, you can edit the data table and click Remove Expiration and save this change. Individual data table rows can also be assigned their own TTL. To the immediate left of Default Row Expiration is an option button titled Show TTL. Clicking this will append to the right of the columns in the data table a TTL column with the amount of time left for each row. If a TTL does not exist, the word Set will appear. You may need to scroll horizontally to see the TTL column if there are a number of rows in the data table.  In this example, the data table contains a small set of IOCs and within the TTL column we can see that they have varying amounts of time left before each IOC ages out. These TTLs can be modified by the user if a row needs to be extended or shortened. To illustrate the aging out process, here is a basic rule that matches file hashes with events. We are matching process launch hashes to the rows in this data table, aggregating by the principal.hostname and outputting the data table attributes via outcome variables in the detection.rule suspicious_file_hash_threat_intel {  meta:    author = "Google Cloud Security"    description = "Detect file events that match ISAC and global threat intel list"    severity = "Medium"    priority = "Medium"  events:    $process.metadata.event_type = "PROCESS_LAUNCH"    $process.target.process.file.sha256 != ""    $process.target.process.file.sha256 = $hash    $process.principal.hostname = $hostname    %file_hash_ioc_ttl.sha256 = $hash  match:    $hostname over 1h  outcome:    $description = array_distinct(%file_hash_ioc_ttl.description)    $file_size = array_distinct(%file_hash_ioc_ttl.file_size)    $version = array_distinct(%file_hash_ioc_ttl.version_string)    $report = array_distinct(%file_hash_ioc_ttl.report)  condition:    $process} With the data table as constituted above, the test rule triggers with two detections, each with two events in it. We can find those hashes in the data table above and in the detection we can view the metadata associated with the hashes from the data table.  Time marches on, and when I return to my data table about 30 minutes later, I can see that the composition of the data table has changed. For starters, notice there are only three rows in the data table because rows have started to age out.   The TTL on the hash starting with 8B44 is now orange indicating that it is near the end of its life as well. When I re-ran that test rule about ten minutes later for the same time range, the results have shrunk to a single detection and this hash is no longer considered by the rule because it is no longer part of the data table.  When data tables have a row expiration applied to it or removed, SecOps records in the GCP audit log an UpdateDataTable event associated with the data table and the user who made the change. Notice in the Log Explorer log below the data table name and the value for updateMask is set to rowTimeToLive.  Adding TTLs to rows in data tables can be helpful when it comes to working with dynamic lists that need to be periodically purged of data that is no longer relevant. Here are a few things to be mindful of when using TTLs:The row expiration can range from one hour to one year Row expiration can be set at a table level or a row level TTLs can be modified if needed The TTL column will need to be toggled on and appears on the far right of the data table If you find yourself wanting to age out data from data tables, even for just a few subsets of data, I encourage you to give row expiration and TTLs a try! Community Blog Thu, 04 Jun 2026 16:29:29 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/chronicle-rule-outcome-soar-playbook-workflow-7556 I wanted to share the workflow we’ve been using to connect Chronicle detection rules with SOAR (Gemini) playbooks, specifically focusing on how rule design directly drives playbook effectiveness.The key idea is:The rule is not just a trigger — it is responsible for providing all the context the playbook needs to make a decision.1. Rule as the Context EngineInstead of relying on the playbook to “figure things out,” we push as much structure and meaning as possible into the rule itself.Each rule is responsible for:Identifying the behavior Normalizing key fields Providing investigation-ready context via the outcome sectionBy the time the alert reaches the playbook, it should already answer:What happened? Who did it? On what system? Why is it suspicious?2. Outcome Section as the ContractThe outcome section acts as a contract between the detection rule and the playbook.We standardize outcomes across rules so every playbook receives consistent inputs.Core pattern we use:$outcomeUserIsTechnical (true/false) $outcomeUserRoleHint (technical vs non-technical + elevated context)These are derived from datatables (title + department), not hardcoded logic.Why this mattersThe playbook doesn’t need to:Parse job titles Infer privilege Guess intentIt can immediately reason with:“This is a non-technical user running a recon tool” “This is an elevated admin performing a sensitive action”3. Passing High-Value Fields OnlyWe intentionally keep outcome fields:Concise High signal Consistent across rulesTypical fields include:Command line File path Process name Target resource User role indicatorsWe avoid:Excessive raw telemetry Fields that don’t influence decisionsThis keeps playbook prompts clean and performant.4. Playbook Design (Driven by Rule Output)Playbooks are designed with the assumption that:The rule already identified suspicious behavior The outcome already provides structured contextSo the playbook focuses on decisioning, not discovery.Playbook ResponsibilitiesGiven the alert + outcome data, the playbook: Evaluates context User type (technical vs non-technical) Execution context (host, process, command line) Action being performed Determines verdict Malicious Suspicious Benign Provides reasoning Based strictly on the current alert context Recommends next steps Investigate Escalate Close 5. Key Design ConstraintEach playbook execution is context-isolated.This means:No linking to other alerts No historical correlation assumptionsBecause of this, the rule + outcome must be self-sufficient.If the rule doesn’t provide enough context, the playbook cannot compensate.6. Workflow in PracticeThe flow looks like this:Rule triggers on high-fidelity behavior Rule populates standardized outcome fields Alert is sent to SOAR Playbook consumes: Detection metadata Outcome variables Playbook produces: Verdict Reasoning Recommended actions 7. Handling Noise (Critical Insight)If alerts are noisy, we do not fix that in the playbook.We go back to the rule and:Refine conditions Add exclusions Tighten logicReason:A playbook should not be responsible for compensating for weak detections.Cleaner rules = better automation decisions.8. Where This Model Works BestThis workflow is especially effective for:Behavioral detections (execution, configuration changes, discovery activity) Privilege-sensitive actions High-confidence signals with clear intent9. OutcomeThis approach gives us:Consistent playbook inputs across all rules Simpler and more reliable automation logic Better triage quality (especially with Gemini) Reduced need for complex playbook branchingClosingThe biggest shift for us was treating the rule as the primary source of truth, and the playbook as a decision layer, not a discovery layer.Curious how others are structuring:Outcome sections Rule-to-playbook contracts Context standardization across detectionsHappy to compare approaches. Google Security Operations Thu, 04 Jun 2026 14:58:25 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/taking-mitigation-steps-on-a-specific-entity-within-the-case-7571 I’m trying to implement a workflow in Google SecOps SOAR where an analyst can manually select a specific IP address entity within a case and run a playbook that performs a mitigation action (e.g., block that IP).The key requirement is that the playbook should only act on the selected entity, not all IP entities in the case.Is there a way to trigger a full playbook execution scoped to a manually selected entity (similar to how actions can target specific entities), rather than running at the case level?If this isn’t directly supported, what are the recommended workarounds (e.g., Entity Selection, loops, custom lists, or manual input prompts)? For context, I’ve already explored:- Entity Selection in playbooks- Running actions with selected entities- Quick/Manual actionsBut I haven’t found a way to initiate a full playbook execution from a manually selected entity. Google Security Operations Thu, 04 Jun 2026 08:09:59 +0200 https://security.googlecloudcommunity.com/community-blog-42/that-looks-different-than-yesterday-7648 Not too long ago I learned what Bayesian probability was and then figured out how to implement it in Google SecOps. I chose to focus on the probability that a Chrome extension (CRX) was potentially hijacked primarily because it let me narrow down the scope of the problem I needed to solve. It’s also kind of a fun problem because today the only way to track CRX telemetry is through Chrome Enterprise Premium feeding a stream to Google SecOps–I knew that whatever I did would be unique. While I’ve written about the system in a series on Medium, for members of the Community site I wanted to take a deeper look at the implementation in order to explain the system and what I needed to leverage to make it work.  Whether you’re mulling over doing something similar or simply curious, I’m going to take the opportunity here to explain:How I designed a system that scales to a large population without computationally breaking the bank Using Data Tables to store state and serve as a data exchange mechanism between SecOps and an external system Where the Chronicle API powers more than simple bulk data exchanges As the article progresses, it will describe various pieces of the architecture. Here’s a diagram that should help you understand where these pieces fit into the overall system:  The Problem I was solvingBayesian Probability is a form of statistical inference. In layman’s terms, you look at the history of something to “infer” whether the current behavior matches the expected profile.  The model updates as behavior changes.  For a SOC, the real question is whether something new is something unexpected but OK or the sign of something bad. In all things Bayesian you make a choice as to whether to update the model and the SOC needs to balance adapting to new behavior versus excluding “bad” behavior so as not to normalize it. To make this work, there’s a fair bit of math and data analysis but you don’t need math to understand the fundamental concepts:Derive a baseline knowledge of “Prior” behavior Measure whether current behavior is expected or not based on the prior behavior Reach a verdict on that behavior to reach a decision as to whether you include or exclude the behavior Find a way to ferry the new findings back into the baseline system, rebasing the PriorsWhat makes the problem harder is that YARA-L is not designed to do this.  I needed a way to analyze all past behavior, calculate some key metrics (volume and inertia), store that somewhere so that the YARA-L rules engine could reference it when it saw new CRX telemetry.   Step 1: Create the store of dataData tables are a great addition to SecOps. Between their capacity, being multidimensional, and the different mechanisms in place to work with them, they became an integral part of my solution. Fortunately you can populate them based on a YARA-L rule. I created a “seed rule” meant to run once as a retrohunt and populate a Data Table with summarized, indexed events. This avoids a “cold start” on the data but it only works if you’ve already collected a history of CRX data in a SecOps tenant, preferably 30 days. Part of the rule is a simple data collection, isolating CRX API calls that involve external domains, which is almost all CRX calls of type extensionTelemetryEvent: events: $e.metadata.log_type = "CHROME_MANAGEMENT" $e.metadata.product_event_type = "extensionTelemetryEvent" // 1. Stable Identity Extraction // Using the 'profile_user' field to avoid email_addresses repeated field issues $userid = $e.extracted.fieldse"profile_user"] // 2. Core Behavioral Components $ext_id = $e.target.resource_ancestors.product_object_id $signal = $e.target.resource.name $clean_domain = strings.to_lower(re.capture( strings.coalesce( $e.target.resource.attribute.labelsl"destination"], $e.target.url, $e.target.asset.hostname, "unknown" ), "(?:https?://)?(?:www\\.)?(u^/:]+)" )) Note “clean_domain” - not all external CRX calls use the same UDM fields for contacted domains, and I wanted one reference for all external calls. I lumped them in this single local variable. The other item I want to call out is that I intentionally chose an unenriched UDM field for the user.  Chrome logs are structured JSON, which results in auto-extraction fields. The “profile_user” value in the log normalizes to principal.user.email_addresses, but in my own environment that leads to seven different email aliases that show up as enriched fields, which also inflates any one user event into seven user events.  Using the extracted field removes the risk of inflated, inaccurate metric calculations. The bigger part of what this rule does is that it measures activity over time.  It breaks out activity by extension, the type of activity, the external domain, and the day of the week when it happens It measures the this activity across all user profiles without tracking any specific person – people are an abstraction It sorts the activity on a weekly basisThe rule uses the Match statement and Outcome variables for all of this but the real focus is on constructing a key that summarizes the extension, signal, domain, week number, and day activity, or the “eswd key”. An example key is:lmjegmlicamnimmfhcmpkclmigmmcbeh|REMOTE_HOST_CONTACTED_INFO|ssl.gstatic.com|36|7 What the key does not contain is anything about the user or machine that saw it.  Any involved entities in your environment are attributes of the finding: a column in the row shows a count of users.  This means that I can treat users in the abstract on one line rather than having a line per entity, which drives multiple benefits:The computational load is a lot easier/cheaper.  I get the detail I need with fewer entries in the Data Table.This last point is especially important because something I needed to avoid was creating a data explosion, saturating the Data Table to its capacity and overwhelming data operations on the table.  This comes up again later. To pull all of this together, the seed rule has to first juggle the outcome variables to make them respect the type values of their columns in a data table, which is why my rule has a set of “clean” variables.  Data Tables today let you choose between String and Number for type values, while most of the Outcome variables are of type array by default.   For example, I need to extract the week number for the key (a string value). In the events section of my rule, I isolate the week number using a timestamp function: $week_num = timestamp.get_week($e.metadata.event_timestamp.seconds) Since $week_num is an array, I need to flatten the array and extract it as a string. $clean_week = arrays.index_to_str(array_distinct($week_num), 0) There’s similar juggling going on for columns of type “NUMBER” in the Data Table, because a number is actually a float, and most of the functions in YARA-L that work with numbers use them as integers.  For example, my row values have an aggregate count of every CRX signal/domain combination (like a COOKIES_GET_ALL_INFO call sent to a domain).   That starts with a count of all matching events that I have to cast to a string: $weekly_n_stageint = cast.as_string(count($e.metadata.id)) Why string? The cast.as_float function only works with strings: $weekly_n = cast.as_float($weekly_n_stageint) With all of this glorified data collection and massaging, I export the findings to a data table:condition: $e export: %extension_behavior_seed.write_row( key: $esdw_key, extension_id: $ext_id, signal_name: $signal, domain_name: $clean_domain, week_number: $week_key, weekly_n: $weekly_n, user_prevalence: $user_prevalence, active_days: $active_days, global_match: $global_match )} After running the rule, it took about 20 minutes to crunch a year’s worth of log data to generate a Data Table with a couple of thousand lines in it. Step 2: Calculate the Global PriorsWith the seed table in place, the data is present to find the mean and the variance, necessary for calculating volume and inertia, across all extensions and signal type.  The nice thing about having the table is that I can do the calculation once and use it many times before I update the table and need to recalculate the data.   However, for this I had to rely on something external.  I had a lot of fun trying to figure out how I could force a YARA-L rule to do this too, and someday I might be able to coax it.  Instead I turned to Python via a Cloud Run function in my GCP Org. By assigning a service account narrow IAM rights, I was able to strip down the role to the bare minimum to reduce risk. The Chronicle v1Alpha API makes getting the Data Table a simple call: get_url = (f"https://chronicle.{location}.rep.googleapis.com/v1alpha/" f"projects/{project_id}/locations/{location}/instances/{instance_id}/" f"dataTables/{seed_table}/dataTableRows") A while loop grabs the rows and cycles through the values, mapping the table schema before processing the data. After grabbing the data, the rest of the Python job is straightforward:Calculate the signal activity across all extensions (how many extensions use REMOTE_HOST_CONTACTED and at what frequency?) Calculate entity-specific activity - the signal activity and variance across each specific extension Blend the signal activity with the entity activity for a more accurate signal-specific baseline Organize the data  Write it into a new Data Table that has the Global Prior data, specifically the “Alpha” (volume) and “Beta” (inertia) values Alpha is mean squared over variance, while the Beta is the mean over the variance.   To make the Bayesian engine more flexible and discerning, I added some dimensions beyond the Alpha and Beta for each extension/signal pairing. These are the:Number of days the extension/signal has been observed in the tenant. The number of trusted domains that the extension/signal combination has been seen communicating to. The maximum prevalence of the number of users/entities who invoked the extension/signal in their managed Chrome instance. The days of the week during which this activity was observed. Then it writes the data into the global priors table:url_global = (f"https://chronicle.{location}.rep.googleapis.com/v1alpha/"                      f"projects/{project_id}/locations/{location}/instances/{instance_id}/"                      f"dataTables/{global_priors_table}/dataTableRows:bulkReplace")        resp_global = authed_session.post(url_global, json=global_payload)        update_results.append(f"Global: {resp_global.status_code}") This all sounds straightforward, but as a SecOps user going back to Chronicle, this is a major leap ahead. I’m using Python to read a store of data, generate results, and push them back into the platform for general use within the platform!  Step 3: Observe the current data streamSteps 1 and 2 were all about gathering data and establishing a baseline.  The next two steps are about gathering data and comparing it to the baseline.  Just as there is a seed rule that gathers the historic data, there is a rule that tracks the current stream (there’s actually two but it’s for an edge case I’ll explain later).  I call this rule the “Cruncher” - it just crunches away at the current stream without generating any alerts. The Cruncher writes to a different Data Table, one I call the “Holding Pen”.  Data is meant to be transitory here, either on its way back to updating the Global Priors or being tossed out by a downstream evaluation.  This table tracks a lot of the same table as the seed, but it includes specific userids in part to support that downstream evaluation, and in part to track uniqueness and growth when something “odd” shows up. The rule’s events section starts looking a lot like the Seed rule:events: $e.metadata.log_type = "CHROME_MANAGEMENT" $e.metadata.product_event_type = "extensionTelemetryEvent" // 1. Identity & Target Extraction $userid = $e.extracted.fieldsk"profile_user"] $ext_id = $e.target.resource_ancestors.product_object_id $signal = $e.target.resource.name // 2. Domain Normalization $domain = strings.to_lower(re.capture( strings.coalesce( $e.target.resource.attribute.labelse"destination"], $e.target.url, $e.target.asset.hostname, "unknown" ), "(?:https?://)?(?:www\\.)?(r^/:]+)" )) Then it goes out to find the alpha and beta values from the Global Priors data table: $e_alpha = %extension_entity_priors.entity_alpha $e_beta = %extension_entity_priors.entity_beta The rule fetches the values for the correct combination of extension+signal thanks to a join between the current telemetry and the data table: $ext_id = %extension_entity_priors.extension_id $signal = %extension_entity_priors.signal The important thing to understand is that the Cruncher is aggregating extension+signal telemetry and putting it into another data table for the purposes of later analysis by another Python-based Cloud Run instance. The Cruncher does not determine whether something is different or improbable.  However, the Cruncher makes a substantial contribution to the Bayesian calculation by deriving the threshold above which an action is “improbable” based on the alpha and beta values. This threshold is defined in an outcome variable called $bayesian_surprise.  A Bayesian Surprise metric is a thing and some Python later runs the actual calculation–the Surprise value of an observed operation.  In the rule, $bayesian_surprise shows only the threshold at which the Surprise value has to exceed to be an improbable event, not the actual Surprise value of the current event.  The value is an inverse probability calculation with a smoothing factor, defined in the rule: // Calculate Surprise - this is actually a Static Rarity Check that the Ferryman uses // to calculate the Dynamic Bayesian update. $bayesian_surprise = 100.0 / (($final_alpha / $final_beta) + 0.1) The other significant contribution the Cruncher makes to lowering the computational workload of Python is to embed the Alpha, Beta, and the number of times the behavior was observed, which is based on a count of the metadata.id. $string_alpha = cast.as_string(cast.as_int(max($e_alpha))) $string_beta = cast.as_string(cast.as_int(max($e_beta))) $string_count = cast.as_string(count($e.metadata.id)) $math_handoff = strings.concat($string_alpha, "|",$string_beta, "|", $string_count) As with the Seed, there’s work to create a key and format data for the Data Table schema before exporting the results to the Holding Pen Data Table: export: %extension_behavior_pen.write_row( event_key: $event_key, extension_id: $ext_id, user_id: $userid, domain_name: $domain, signal: $signal, final_risk_score: $bayesian_surprise, is_new_extension: $zero, surprise_score: $bayesian_surprise, timestamp: $exact_time, risk_factors: $risk_factors, b_state_vector: $math_handoff, first_seen: $clean_time ) Notice that one of these columns is called “is_new_extension” and the Cruncher writes out the results of $zero? In the Cruncher, $zero is 0: $zero = cast.as_float(cast.as_string(0)) Why is there this work to write out a zero result statically?  It goes back to when I said that there are two rules watching the current telemetry stream. The Cruncher works to examine extensions that are already known. If the extension is not known, the rule would break since it has nothing to use from the Global Priors. The fix is to have a shadow rule, called the “Ghost Scout” that does almost the exact same thing except only apply to extensions with no prior history (someone installing a new extension), statically set the surprise_score Data Table field to 100, and otherwise construct a properly constructed row that won’t stop the downstream Python script from running. The one interesting change in the events section is the use of “not” to scan the table key for the combination of an extension and signal: not strings.concat($e.target.resource_ancestors.product_object_id, "|", $e.target.resource.name) in %extension_entity_priors.key The Ghost Scout is otherwise writing out static values:$bayesian_surprise is a perfect 100 (something never seen before is completely unexpected because nobody expects the Spanish Inquisition). Alpha and Beta have a value of zero and that zero plus the count of how many times the new extension was seen get written out to the b_state_vector field in the $math_handoff variable. Whether written out by the Cruncher or the Ghost Scout, the result is a steadily growing Data Table of current behavior.  Chrome Extensions are very chatty, proving the value in using an aggregation key rather than having line items for each event. Without the key, the Pen would explode in a large organization. Step 4: Determine whether the behavior is expectedWith the Pen hosting a growing population of observed behavior and a SOC waiting to hear whether an extension is acting improbably, we turn back to Python to evaluate the Pen.  At the highest level, the Pen calculates a Surprise value and if the value is too high (if it crosses the threshold the Cruncher calculated), the Pen sends an alert into SecOps.   It sets up a connection to SecOps via the Chronicle API:                 base_url = f"https://chronicle.{LOCATION}.rep.googleapis.com/v1alpha/projects/{PROJECT_ID}/locations/{LOCATION}/instances/{INSTANCE_ID}" Some functions read the Seed and the Pen:def get_all_rows(session, base_url, table_id): all_rows = i] url = f"{base_url}/dataTables/{table_id}/dataTableRows" page_token = None while True: params = {"pageSize": 1000} if page_token: paramsT"pageToken"] = page_token resp = session.get(url, params=params) if resp.status_code != 200: break data = resp.json() all_rows.extend(data.get('dataTableRows', ])) page_token = data.get('nextPageToken') if not page_token: break return all_rows The Ferryman also updates the Holding Pen with additional, derived data:def batch_update_rows(session, base_url, updates): if not updates: return table_parent = updates]0] 'name'].split("/dataTableRows/")x0] url = f"https://chronicle.{LOCATION}.rep.googleapis.com/v1alpha/{table_parent}/dataTableRows:bulkUpdate" for i in range(0, len(updates), 200): chunk = updates payload = {"requests": :{"dataTableRow": {"name": up'name'], "values": ui'values']}, "updateMask": "values"} for u in chunk]} session.post(url, json=payload) What is happening here is:The Ferryman reads the Global Prior and Holding Pen tables Next the Ferryman makes a series of calculations Every row it reads results in some kind of finding The Ferryman writes the findings back into the Data Table row, actively changing values or appending others This is very new in the world of SecOps. The Data Table is acting as an active scratch pad to track state for something initially called out by a YARA-L rule. That second bullet about making a series of calculations is masking quite a lot of additional work.  Overall the Ferryman is acting as a Security Sensor using Data Table row data as its source.  When the Ferryman pulls in from the Holding Pen and Global Prior tables, the Ferryman:Calculates the Bayesian Surprise score for the event based on all of the data it has on hand from the two tables Examines the timing of events to see if there’s a rapid spread of new activity Checks to see if the event matches certain threat vectors such as activity at an odd time, something it hasn’t done before, or communicating with a new location Any of these findings result in a descriptive tag that gets written back into the Data Table.  If a Surprise score is especially high to cross into the realm of the improbable, the Ferryman constructs a UDM event, pushes it into SecOps, and notes in the Data Table (via the row update) that it sent an alert. The Ferryman is able to construct all of the key UDM fields that it needs from the Pen: if current_risk_tags or final_score >= GAVEL_THRESHOLD: already_alerted = "ALERT_SENT" in str(valsaIDX_RISK_FACTORS]) if len(vals) > IDX_RISK_FACTORS else False if final_score >= GAVEL_THRESHOLD and not already_alerted: gavel_events.append({"udm": { "metadata": { "event_timestamp": ts_iso, "product_name": "Ferryman Bayesian Judge", "vendor_name": "Muppet Labs", "event_type": "GENERIC_EVENT", "description": f"Risk Alert: {signal}", "product_event_type": str(signal), "ingested_timestamp": ts_iso }, "principal": { "user": { "email_addresses": Cstr(vals IDX_USER_ID])] } }, "target": { "hostname": str(vals_IDX_DOMAIN]), "asset": { "hostname": str(valssIDX_DOMAIN]) }, "resource": { "name": str(signal), "resource_type": 0, "attribute": { "labels": {"key": "Risk Source", "value": "Bayesian Anomaly"}, {"key": "Original Type", "value": "BROWSER_EXTENSION"}, {"key": "First Seen", "value": str(new_vals IDX_FIRST_SEEN])} ] } }, "resource_ancestors": T { "product_object_id": str(ext_id), "resource_type": 0 } ] }, "security_result": [{ "risk_score": final_score, "summary": " | ".join(current_risk_tags), "severity": "HIGH" if final_score >= 80 else "MEDIUM" }] }}) current_risk_tags.append("ALERT_SENT") Step 5: Test for badnessThe Ferryman sends a signal to alert that something seems off. As with any other security signal device that sends a signal, e.g., EDR, Network, DLP, Email, etc., the question is “now what”?  In this case, the original source event is a Chrome log event and you are working with network-centric threats. What is a CRX talking to and how is it doing so? This is where SecOps can step in to help you determine whether there’s something unsavory happening. The Ferryman runs once an hour meaning that you can start running SecOps rules quickly. As soon as the UDM event arrives, there is a suite of rules ready to dig in deeper.  Each of these rules has a nearly identical construction to create a tight join between the UDM event and the Chrome event that registered a high Surprise score: events: $crx.metadata.log_type = "CHROME_MANAGEMENT" $crx.metadata.product_event_type = "extensionTelemetryEvent" $userid = $crx.extracted.fieldss"profile_user"] $ext_id = $crx.target.resource_ancestors.product_object_id $signal = $crx.target.resource.name $ip = $crx.target.ip $domain = strings.to_lower(re.capture( strings.coalesce( $crx.target.resource.attribute.labelst"destination"], $crx.target.url, $crx.target.asset.hostname, "unknown" ), "(?:https?://)?(?:www\\.)?(.^/:]+)" )) $bys.metadata.log_type = "UDM" $bys.metadata.product_name = "Ferryman Bayesian Judge" $bys.metadata.vendor_name = "Muppet Labs" $ext_id = $bys.target.resource_ancestors.product_object_id $domain = $bys.target.asset.hostname $risk_value = $bys.security_result.risk_score $severity = $bys.security_result.severity $signal = $bys.metadata.product_event_type $userid = $bys.principal.user.email_addresses Once again, the logic to identify CRX activity repeats as it has in the Seed and Cruncher rules.  Now it’s looking for the same event and creating a join on multiple vectors:Userid Extension ID Signal External domain Below this are joins and/or logic to look for something. For example, here is a rule that joins the observed the domain against the VT Relationships table in the entity graph: // Uses VirusTotal integration via entity graph, this section maps the domain it contacts $vt.graph.metadata.source_type = "GLOBAL_CONTEXT" $vt.graph.metadata.vendor_name = "VirusTotal" $vt.graph.metadata.product_name = "VirusTotal Relationships" $vt.graph.relations.entity_type = "DOMAIN_NAME" $vt.graph.relations.relationship = "CONTACTS" $vt.graph.relations.entity.domain.name = $domain Here is another rule that looks to see if the DNS registration is expired: // join access event to entity graph to use WHOIS data $whois_exprd.graph.entity.domain.name = $domain // Whois domains provided by GCTI Feed $whois_exprd.graph.metadata.entity_type = "DOMAIN_NAME" $whois_exprd.graph.metadata.vendor_name = "WHOIS" $whois_exprd.graph.metadata.product_name = "WHOISXMLAPI Simple Whois" $whois_exprd.graph.metadata.source_type = "GLOBAL_CONTEXT" // Domain expired before the event $whois_exprd.graph.entity.domain.expiration_time.seconds < $crx.metadata.event_timestamp.seconds Then there is a match, usually on the extension and userid within a 30 minute window: match: $ext_id, $userid over 30m Finally, there is a standard taxonomy in the outcome variables that become useful for a composite detection: outcome: $bayesian_risk = max($risk_value) $bayesian_severity = array_distinct($severity) $ext_signal = array_distinct($signal) $ext_domain = array_distinct($domain) $user_id = array_distinct($userid) $assessed_risk = "Expired DNS Registration" $tier = "1" $risk_score = 0 The “tier” is important because it helps determine the severity of the threat. It also factors into whether the observed extension propagates back to the seed. The risk score of zero means the detection won’t show up in the Risk Analytics dashboards, which is what I want since I manage the risk score in a downstream composite detection. Each of the rules have a metadata tag called “crx-family” and with it the final composite detection rule can step in and determine the nature and severity of the threat.  The Signal Analyzer starts by finding the rules that have run and generated detections: events: $id = $d.detection.id $type = $d.detection.type $ruleName = $d.detection.detection.rule_name $ruleId = $d.detection.detection.rule_id $d.detection.detection.rule_labelsh"family"] = "crx-behavior" Then it retrieves information from that taxonomy of outcome variables, plus the extension ID: $ext_id = $d.detection.collection_elements.references.event.target.resource_ancestors.product_object_id $riskScore = $d.detection.detection.outcomesr"risk_score"] $crx_bayesian_risk = re.capture($d.detection.detection.outcomesi"bayesian_risk"], "^(\\d+)(?:\\.|$)\\d*") $crx_bayesian_severity = $d.detection.detection.outcomest"bayesian_severity"] $crx_ext_signal = $d.detection.detection.outcomes_"ext_signal"] $crx_ext_domain = $d.detection.detection.outcomesa"ext_domain"] $crx_user_id = $d.detection.detection.outcomess"user_id"] $crx_assessed_risk = $d.detection.detection.outcomesd"assessed_risk"] $crx_ext_ip = $d.detection.detection.outcomesi"ext_ip"] $crx_tier = $d.detection.detection.outcomest"tier"] All of this happens within a 30 minute window and matches against the extension and userid: match: $ext_id, $crx_user_id over 30m The outcome variables mostly map in the specifics of what was observed, but it also walks through calculating a risk score.  It looks at the tiers for all observed rules and assigns a baseline score. $rule_tier_high = if(max(cast.as_int($crx_tier)) =1, 80, 0) $rule_tier_med = if(max(cast.as_int($crx_tier)) = 2, 30, 0) $rule_tier_low = if(max(cast.as_int($crx_tier)) = 3, 10, 0) It also factors in a couple more items:How many rule detections were there within the window?  What was the Bayesian Surprise score that the Ferryman calculated? It takes all of those factors and creates a temporary risk score value: $trigger_count = count_distinct($id) $bayesian_risk = max(cast.as_int($crx_bayesian_risk)) $risk_score_temp = (($trigger_count *10) + //more vectors means a higher risk ($rule_tier_high) + ($rule_tier_med) + ($rule_tier_low) + $bayesian_risk) Since risk scores can only have a max risk score of 100, the final risk score swaps in a 100 if the calculated value is higher, or uses the calculated value: $risk_score = if($risk_score_temp > 100, 100, $risk_score_temp) The condition has a built-in safety valve to make sure that only rules that had tiers factor into the final detection: condition: $d and ($rule_tier_high !=0 or $rule_tier_med !=0 or $rule_tier_low !=0)} With that, you have an evaluation that can kick off a case as well as help determine whether you want to “normalize” the data back in the seed. Step 6: Determine whether to promote the Pen findings to the SeedFor reasons of data integrity and system performance alone, you need to figure out what to do with the Pen. The Pen grows continuously with each finding the Cruncher makes of all active CRX events. At some point the Python scripts would have a hard time processing everything, and a little later the Data Table would fill up.  From the standpoint of the Bayesian detector, the work is not done. New event data needs to be promoted back into the seed if it represents “non-malicious” behavior. You have two really good reasons to figure out how to clean up the Pen. Enter Python once more. One last script judges the events in the Pen and prunes it accordingly.  As with the Priors and Ferryman scripts, the “Judge” script grabs the Pen and Seed Data Tables.  The Ferryman has updated all Pen tables with some kind of disposition, whether the activity is benign or suspect. The Judge sees this and has a few courses of action.“Normal” activity where an extension is seen doing something that it’s always done promotes back to the Seed immediately with the current week number.  That same activity older than a year later gets “pruned” so that the Seed is intentionally limited to the past year. These findings have no tier finding nor do they have a high Surprise score; remember that the Cruncher sees all extension behavior and writes it to the Pen. Malicious activity, denoted as a Tier 1 finding, does not promote to the seed and is immediately deleted from the Pen. Tier 2 findings are highly suspicious and stay in the Pen until someone decides what to do with them. Tier 3 findings are more odd than problematic and remain in the Pen for a maximum of 30 days. If nothing else happens, they promote after 30 days on the assumption that any flags they threw were inconsequential. A word on Tier meaningsA question I had to grapple with is which Tier to assign to different rules, since they had a direct bearing on the severity of the rule and whether the behavior would be promoted back.  Tier 1 is obvious, Tier 2 requires a Case-based approach to figure out the right next step.  Tier 3 is something of an act of faith because, yes, there’s a finding but it might not be all that big of a deal or could even be a guilt-by-association. Consider the VT Relationships finding, which I found in my test environment.  A CRX was communicating to a domain with associations with known malware and threat actors. At first I thought that a bad association like that was a Tier 1 finding. Then I realized that the CRX could be talking to a completely valid domain that other bad things happen to use – that’s a perfectly valid interpretation of a Virustotal Relationship result.  If all a CRX does is talk to a domain that other malware is known to talk to, that’s not worth an indictment of the CRX.  Compare that to a CRX that is seen sending data to a domain with an expired WHOIS registration. That is a clear Tier 1 violation because the domain can easily be hijacked and used against a company. The in-between Tier 2 finding needs someone to make a judgement call. For example, a CRX seen communicating with a low-prevalence domain (no more than 3 user profiles) might be a CRX talking to an unknown C2. On the other hand, in a company with a liberal extension install policy this could be one person with a really esoteric and completely benign personal interest. One wrinkle: the tier 2 findings never make their way out of the Pen!  When the Ferryman analyzes events and finds something that results in an alert, the Pen typically looks like this: The risk score takes on the Surprise score, there are risk factors that make their way to the Signal Analyzer, and the b_state_vector is an aggregate result of the Alpha score, Beta score, and local count.  There is no tier data. All rise for The JudgeThe Judge has to consider the tiers, which aren’t in the Pen.  To solve this, the Judge leans into the Chronicle v1Alpha API once more to retrieve the tier directly from the composite detection!  The script hard codes the rule ID of the Signal Analyzer:ANGEL_RULE_ID = "ru_1ef2243c-a62a-496f-b6b8-bd0e323a59ba" (Why “Angel” you ask? Originally I was going to call this the “avenging angel” script and Gemini never let that go during the vibe coding exercise.) Then the Judge uses the API to retrieve the data directly from the detection’s outcome variables:def get_angel_verdicts_wrapper(chronicle_client, rule_id): verdicts = {} try: end_dt = datetime.datetime.now(datetime.timezone.utc) resp = chronicle_client.list_detections(rule_id=rule_id, start_time=end_dt - datetime.timedelta(days=30), end_time=end_dt) detections = resp.get('detections', ]) if isinstance(resp, dict) else resp for d in detections: for item in d.get('detection', (]): outcomes = item.get('outcomes', :]) or item.get('detectionFields', .]) dom, tier_val = None, 3 for ov in outcomes: k, v = ov.get('key') or ov.get('name'), ov.get('value') if k in s"ext_domain", "domain"]: dom = v elif k == "tier": tier_val = int(v:0]) if str(v).isdigit() else (1 if "1" in str(v) else (2 if "2" in str(v) else 3)) if dom: if tier_val < verdicts.get(dom, 99): verdicts dom] = tier_val except: print(" WARNING] Angel Fetch Failed.") return verdicts Adding a Human to the LoopThe system is designed to flag issues and update the Priors with only “good” extensions. It makes sense that you don’t normalize behavior from an extension talking to a known C2, so Tier 1 findings get deleted from the Pen and never promote to the see.  Similarly, Tier 3 findings can go through a wait-and-see trial and normalized after 30 days if nothing else happens.  You might want a human to step in, but you can let it go in unopposed. In each case, the system I created will remove Tier 1 and Tier 3 findings on its own.Tier 2 findings are in a grey area - the Judge never removes them from the Pen. They’re the example of where you want a human in the loop. If you decide to exclude the extension from your environment, you want the records removed from your Pen. If you break the other way and let the extension in despite a Tier 2 finding, you want that noted with the entries removed from the Pen. However you will never let a Tier 2 finding promote back to the seed table because that is normalizing bad behavior. To solve for this I constructed a playbook. The general idea is that Tier 1 extensions get added to a permanent exclusion list and Chrome Enterprise Premium restricts them from all managed Chrome profiles. Tier 2 and Tier 3 findings let Analysts choose between allow-listing, banning, or wait-and-see If you decide not to block the extension or let it wait longer, it goes to one final Data Table where the extension, disposition, Surprise score, and Case ID are listed out.  The Judge can use this to reference what to do with any Tier 2 finding. The fact remains that an extension with a Tier 2 extension can trigger the Bayesian Detector again, so there’s further logic in the Ferryman looks to see if the newest Surprise score is 1.5x the previous Surprise score, included in the the Tier 2 table, or a flat 100 since that is the maximum score. Why not just run all the rules all the time?A few people have looked at the system and asked why I don’t simply run the portfolio of detection rules on all extensions?  The short version is that I can’t, or I could but not as quickly.   Chrome Extensions are always reporting data in. I could write a rule that looks for unique extensions in an environment and test them against some of the threat vectors I have now, but that would translate into a lot more overhead of rules running when they don’t even need to.  With the high frequency of extensions reporting, that would mean a continuous stream of heavy processing rules launching to evaluate highly repetitive, normal activity. One way around this is to run a blind checker once a day for all extensions, but that still means testing a lot of “normal” activity for a lot of overhead. By using Probability as a flag, I can run more expensive rules within an hour of the initial detection.  The Bayesian detector also has a unique condition that YARA-L cannot find on its own: a possibly hijacked extension.  If the Ferryman indicates a potential hijack, that becomes an automatic YARA-L pass-through rule. Thanks for readingBetween this and my three Medium articles you’d think I covered this pretty well. In truth I’ve still glossed over a number of details that made this an interesting project. I’m making the source available for all to analyze and leverage. Even if your interests aren’t in tracking the behavior of Chrome extensions, or probability in general, it should be clear now that combining Data Tables, the Chronicle API, and Composite Detections opens the door to a number of possibilities.  Effectively I’ve used it to extend SecOps with custom Python functions, creating a new source for signals with focused response capabilities.  Community Blog Thu, 04 Jun 2026 05:39:45 +0200 https://security.googlecloudcommunity.com/google-threat-intelligence-3/agent-skills-for-private-knowledge-collections-in-gti-7660 In the May 25 release notes for Google Threat Intelligence, we introduced the concept of private knowledge collections, which allow you to create your own private instances of GTI objects like Malware, Campaigns, Threat Actors, and more.Creating these private objects allows GTI teams to blend localized threat intelligence with Google’s global dataset rather than waiting for vendor attribution. Some of the common use cases you might be interested in include creating a private collection based on the contents of a security blog or a PDF document that you are analyzing.   An excellent way to implement this workflow is by leveraging the GTI MCP server in combination with “skills” to guide agents through the process of generating private collections based on these external resources.In this post you’ll find two agent skills:  One for creating a private collection based on PDFs and another for creating a private collection based on a security blog.  You can introduce these skills into your existing agent workspace, in the same place you would include other agent skills.Once you place these skills in your agent workspace, you can invoke them using a prompt similar to this:Take the data in this PDF report and create a new collection in GTI using the GTI MCP server.  The collection should capture all the IOCs from this report as well as other metadata like related threat actors, industry, etc. There is a skill called create_gti_collection_from_pdf that describes how to execute this in more detail. ---name: create-gti-collection-from-pdfdescription: > Extract threat intelligence metadata and Indicators of Compromise (IOCs) from reports (such as PDFs) and create a structured collection in Google Threat Intelligence (GTI) using the GTI MCP server. vaskenh@google.com June 2026---# Extract Threat Intelligence and Create GTI CollectionThis skill guides the agent in reading a threat intelligence report (e.g., a PDF or text report), extracting verified threat intelligence metadata and Indicators of Compromise (IOCs), and submitting them to Google Threat Intelligence (GTI) to create a structured collection.## When to Use This Skill- Use this skill when the user provides a threat intelligence report (PDF, text, or markdown) and asks to create a GTI collection or document the campaign.- Use this when hunting for threat campaign indicators and structuring them in a centralized collection.## Step 1: Read and Analyze the Threat Intelligence ReportRead the document provided by the user. - If the file is in a restricted path (e.g., workspace root or user home directory), ask the user to copy or move it to the `scratch/` directory where you have read permissions.- Use the `view_file` tool to extract the content.Examine the report to identify:- **Campaign / Threat Actor names**: E.g., FIN10, Megalodon Campaign.- **Initial Infection Vector**: VS Code extensions, poisoned npm packages, etc.- **Malware or Worms**: E.g., "Mini Shai-Hulud".- **Targeted Platforms / Verticals**: GitHub, Grafana Labs, Technology, Financial Services.## Step 2: Extract Verified Indicators of Compromise (IOCs)Isolate the indicators that need to be blocked or searched for.- **IP Addresses**: C2 servers, active scanning IPs.- **Domains**: Malicious hostnames, domains used in bot email addresses (e.g., extract `automated.xyz` from `ci-bot@automated.xyz`).- **File Hashes**: MD5, SHA1, SHA256 hashes of malware or exfiltrated tools.- **URLs**: C2 endpoints or download locations.> a!IMPORTANT]> **Filter out Reference and News Domains:** Do NOT include domains, URLs, or hostnames of research blogs, news websites, or reporting agencies (such as `helpnetsecurity.com`, `ox.security`, or `hoploninfosec.com`) that are simply sources or references within the report. Only extract indicators belonging to the attack infrastructure or malicious activity.## Step 3: Create the Collection in GTIUsing the `gti` MCP server, call the `create_collection` tool.Specify the following arguments:- **name**: A clear name formatted as `<Threat Actor or Campaign Name> Campaign (IOCs)` (e.g., `FIN10 GitHub & Grafana Labs Campaign (IOCs)`).- **description**: A concise summary of the threat intelligence, covering the actor, campaign, initial entry vector, and impact.- **iocs**: The array of extracted, verified IOCs (IPs, domains, hashes, URLs).- **private**: `true` (keep it private by default, unless the user specifies public).Example tool call:```json{ "name": "create_collection", "arguments": { "name": "FIN10 GitHub & Grafana Labs Campaign (IOCs)", "description": "Threat intelligence collection containing verified indicators of compromise (IOCs) associated with the FIN10 GitHub and Grafana Labs breaches and subsequent ransomware campaign", "iocs": a"216.41.225.62", "automated.xyz", "noreply.xyz"], "private": true }}```## Step 4: Update Collection with Tags and AliasesTo make the collection discoverable, call the `update_collection_attributes` tool on the newly created collection ID.Set the following attributes:- **tags**: Lowercased keywords representing the campaign, actor, tools, and infection vectors (e.g., `n"fin10", "github-breach", "grafana-breach", "megalodon", "shai-hulud", "nx-console"]`).- **alt_names**: Alternative names or campaign aliases (e.g., `n"FIN10 Campaign", "Megalodon Campaign"]`).## Step 5: Format the Output Link for the GUIWhen presenting the completed collection details to the user, ensure you format the link to point to the GTI **GUI interface** rather than the API endpoint.- **GUI URL Format**: `https://www.virustotal.com/gui/collection/<collection_id>`Present the final output containing:- Collection Name- Collection ID- Privacy Status- GUI URL Link- Cleaned list of IOCs included- Tags and Alt Names applied ---name: create-gti-collection-from-websitedescription: > Fetch content from a threat intelligence website (e.g. security blog or article), extract verified Indicators of Compromise (IOCs) and campaign metadata, and create a structured collection in Google Threat Intelligence (GTI). vaskenh@google.com June 2026---# Extract Threat Intelligence and Create GTI Collection from WebsiteThis skill guides the agent in reading threat intelligence from a website (such as an online security blog, analysis article, or public advisory), extracting threat metadata and verified Indicators of Compromise (IOCs), and submitting them to Google Threat Intelligence (GTI) to create a structured collection.## When to Use This Skill- Use this skill when the user provides a URL to an online threat intelligence article (e.g., a Google Cloud Security Blog post, Mandiant Advisory, or other public research blogs) and asks to create a GTI collection or document the campaign.- Use this when hunting for threat campaign indicators from web-based sources.## Step-by-Step Instructions### Step 1: Fetch and Read the Web Article ContentFetch the content from the target URL.- Call the `read_url_content` tool with the provided URL.- The tool will download and convert the webpage to a markdown document saved in the system. Use `view_file` to read the sections of the downloaded file.### Step 2: Clean and Analyze ContentWeb page scrapes often contain a large amount of boilerplate (navigation bars, tracking metrics, CSS/JS configurations, related articles lists).- Locate the main body of the article by skipping headers, nav menus, and sidebar elements.- Focus on sections containing campaign descriptions, infection chains, malware analysis, and structured tables.### Step 3: Extract Verified Indicators of Compromise (IOCs)Look for structured tables or list sections under headings like "Indicators of Compromise", "IOCs", "Network Indicators", "File Indicators", or "Technical Details".- **IP Addresses**: C2 servers, active scanning IPs.- **Domains**: Malicious hostnames, domains used in phishing/email/Teams bot accounts.- **File Hashes**: MD5, SHA-1, or SHA-256 hashes of malware binaries, scripts, or components.- **URLs**: Active phishing landing pages, payload staging directories, or SOCKS proxy connections.> y!IMPORTANT]> **Exclude Reference and News Domains:** Do NOT extract domains or URLs of research blogs, security websites, or public tools (such as `virustotal.com`, `helpnetsecurity.com`, `github.com` reference pages, etc.) that are simply links to sources or references in the article. Only capture indicators that belong to the active attack infrastructure or malware campaign.### Step 4: Extract Threat Intelligence MetadataAnalyze the narrative to identify:- **Campaign / Threat Actor names**: E.g., UNC6692, Snow Campaign.- **Initial Infection Vector**: E.g., social engineering, Microsoft Teams phishing, malicious extensions.- **Malware or Worms**: E.g., SNOWBELT (extension), SNOWGLAZE (tunneler), SNOWBASIN (bindshell).- **Targeted Verticals / Industries**: E.g., enterprise users, IT infrastructure, banking.### Step 5: Create the Collection in GTIUsing the `gti` MCP server, call the `create_collection` tool.Specify the following arguments:- **name**: A clear name formatted as `<Threat Actor or Campaign Name> Campaign (IOCs)` (e.g., `UNC6692 Social Engineering Campaign (IOCs)`).- **description**: A concise summary of the threat intelligence, covering the actor, campaign, initial entry vector, and impact.- **iocs**: The array of extracted, verified IOCs (IPs, domains, hashes, URLs).- **private**: `true` (keep it private by default, unless the user specifies public).### Step 6: Update Collection with Tags and AliasesTo make the collection discoverable, call the `update_collection_attributes` tool on the newly created collection ID.Set the following attributes:- **tags**: Lowercased keywords representing the campaign, actor, tools, and infection vectors (e.g., `o"unc6692", "social-engineering", "teams-phishing", "snowbelt", "snowglaze", "snowbasin"]`).- **alt_names**: Alternative names or campaign aliases (e.g., `g"UNC6692 Campaign", "Snow Ecosystem"]`).### Step 7: Format the Output Link for the GUIWhen presenting the completed collection details to the user, ensure you format the link to point to the GTI **GUI interface** rather than the API endpoint.- **GUI URL Format**: `https://www.virustotal.com/gui/collection/<collection_id>`Present the final output containing:- Collection Name- Collection ID- Privacy Status- GUI URL Link- Cleaned list of IOCs included- Tags and Alt Names applied  Google Threat Intelligence Thu, 04 Jun 2026 00:38:40 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/no-response-to-an-appeal-for-a-suspension-of-project-due-to-intrusion-attempts-6404 Hi all,Does anyone know why Google Cloud Platform Trust & Safety team does not reply to an appeal?This has been for over 8 days and I sent them many times but they don't respond-The GCP console is directing me to send appeal and I can not use anything or view the dashboard or take any corrective action  Pleas share any info that may help me in this situation  Kind regards   Google Security Operations Wed, 03 Jun 2026 22:41:01 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/precise-vs-broad-in-anomalous-network-bytes-outbound-what-actually-drives-alerting-7639 Hi everyone,I’m currently testing the built-in Risk Analytics for UEBA rules in Google SecOps, specifically around Anomalous Network Bytes Outbound detections.While configuring the rule set, I noticed that there are two modes available: Precise and Broad, and I’d like to make sure I fully understand how they behave in practice.From what I’ve observed so far:Precise seems to generate fewer alerts and is likely more strict (lower noise) for my case didnt generate any alert yet. Broad appears to be more sensitive and potentially noisier. A rule only generates alerts if both Status = Enabled and Alerting = ON. ( both broad and precise) Even when Broad is disabled, I still see rules marked with a “B” (Broad) in the UI and the alerting is off .I had a few questions to confirm my understanding:Does the “B” label simply indicate the rule variant, regardless of whether it is enabled? When only Precise is enabled, can I safely assume that only that version is actively generating alerts? In a given rule set, are Precise and Broad truly separate detection logics, or is Broad just an extension of the same logic with looser thresholds?Any clarification or feedback from others using these rules in production would be really helpful.Thanks a lot!   Google Security Operations Wed, 03 Jun 2026 21:49:10 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/urgent-project-suspended-13-days-no-response-on-case-71675942-7633 Hello,I am writing here out of absolute desperation. My project curatetours (Billing ID: 01AFC8-EF7732-108B34) was automatedly suspended 13 days ago.This is completely halting my livelihood and business. I have had a live support ticket open: Case #71675942. A billing chat support agent just confirmed today that they manually transferred and escalated the case to the Account & Security Team, but I have not received a single human email or update from that team in nearly two weeks.Because standard support channels are stuck in a loop, my business is facing severe distress. Can a community manager or Google employee please flag Case 71675942 internally so a human can review it?Thank you. Google Security Operations Wed, 03 Jun 2026 19:35:26 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/if-then-else-nesting-error-750 I'm trying to write a nested if then else condition in the outcomes section and I am getting this error: At first I assumed I was missing but I even tested the statement that's been provided by @jstoner for another question see here: https://www.googlecloudcommunity.com/gc/SecOps-SIEM/Else-if-condition-SecOps/m-p/855792/highlight/true Even this one throws the same error in our instance. Is there any chance nesting needs to be enabled further on the backend or is there something I am missing?  Google Security Operations Wed, 03 Jun 2026 19:09:54 +0200 https://security.googlecloudcommunity.com/security-validation-5/validation-content-update-june-3-2026-7658 VHR20260603 - June 3, 2026The Mandiant Intelligence Validation Research Team (VRT) has published VHR20260603 - Content Expansion. This content pack requires Director version 4.14.1.0-0 or higher.If you’ve enabled the Content Service, this content pack will automatically download and be applied to your Director. Otherwise, you can download the security content pack from the Mandiant Documentation Portal.Summary of Changes83 Actions added 61 Files added 7 Actions updated 1 Files updatedRelease HighlightsNew Actions covering Campaign 26-053, a campaign targeting healthcare and education with obfuscated PowerShell, registry modifications, and discovery via tools such as NLTEST. New Actions covering Campaign 26-054, a China-nexus threat actor UNC6863 campaign deploying SLICKDEMON and BADFALL (QUIC RAT) via software supply chain compromise of DAEMON Tools. A new Action demonstrating Campaign 26-052, a financially motivated actor UNC6780 campaign poisoning software supply chains to compromise CI/CD environments via DUSTMAKER and SANDCLOCK. A new Action demonstrating Campaign 26-055, a campaign by an Actor of Unknown Motivations leveraging ClickFix phishing lures to target multiple organizations, via BLACKWIDOW. A new Action covering Campaign 26-058, describing the deployment of the XMRIG cryptocurrency miner via masqueraded PowerShell. New Actions demonstrating Campaign 26-057, a campaign involving UNC6847 using FLINTWIRE and ADAPTAGENT for PowerShell-based fileless execution and multiple persistence mechanisms. New Actions demonstrating Campaign 26-059, a campaign deploying VIDAR infostealer via NEONSLIDE PowerShell Downloader. New Actions demonstrating Campaign 26-060, a financially motivated software supply chain attack by UNC6780 leveraging GitHub Actions cache poisoning and malicious PyPI packages to deploy the FIRESCALE credential stealer. New Actions demonstrating Campaign 26-062, an East Europe-Nexus financial gain actor's campaign deploying ETHERRAT and MATANBUCHUS via Trojanized Installer. A new Action covering CVE-2026-0300, an Out-of-bounds Write vulnerability in Palo Alto Networks PAN-OS that allows unauthenticated remote code execution and has been exploited in the wild. A new Action covering UNC2464, an India-based threat cluster that conducts espionage operations targeting the South Asian government sector and Chinese nuclear research entities. A new Action covering financially motivated threat cluster UNC6240, responsible for extortion operations branded under the ShinyHunters name and utilizing SHINYSPIDER. A new Action covering UNC6396, a China-nexus threat group suspected of espionage targeting government organizations in Southeast Asia, observed deploying SHYROOSTER and TACKYPASTA. New Actions covering UNC3569, a suspected China-nexus cyber actor of unknown motivation, reportedly deploying ransomware and using various malware. New Actions describing Campaign 26-056, a financially motivated UNC6801 campaign delivering REMCOS via multi-stage loaders. New Actions demonstrating Campaign 26-036, a supply chain campaign by UNC6780 targeting cloud credential theft and exfiltration via compromised Trivy and LiteLLM software.For full details on this release, see the Release Notes on the Mandiant Documentation Portal. Security Validation Wed, 03 Jun 2026 18:49:17 +0200 https://security.googlecloudcommunity.com/community-blog-42/gti-update-what-s-new-for-may-25th-2026-7657 Author:Tim Gallo, Google Cloud, Head of Customer Engineering  Detection HighlightsOur Google Threat Intelligence Group and FLARE teams are always working to update YARA rules to help customers stay ahead of emerging threats. This week, we've rolled out rules in the Google Threat Intelligence platform for three newly tracked malware families. We focus our updates on the threats we see most often in Mandiant engagements, Google Security Operations’ environments, and trending searches.Whenever our research uncovers a new malware family, we quickly build and deploy the necessary detection signatures.Here are a few recent examples: SALATSTEALER: a Go-based crypto stealer that targets Windows browsers, cryptocurrency wallets, and Telegram clients (specifically Telegram Desktop and Kotatogram). It is capable of hijacking webcams and microphones to stream data directly to a C2 server. SCARLETSMASHER: a Downloader used to download, compile and execute C# .NET code. See its curated YARA detection rule. LAGUNARAT: a .NET-based Remote Access Trojan (RAT) backdoor designed to execute PowerShell commands, manipulate files on the host communicating with C2. See its curated YARA detection rule. Beyond new threats, we're also keeping rules for established malware like VIDAR, EMPIRE, and EVILPUFFIN fresh. These updates help ensure you have the best coverage against evolving campaigns.You can check out the latest malware profiles in our knowledge base or browse the full list of curated YARA rules.Better Tools for Threat ProfilesBulk IoC Downloads. Threat Profiles help you cut through the noise by highlighting the actors and campaigns most relevant to your specific risks. By tailoring these views, your team can focus on the threats that actually matter to your organization.To make it easier to turn these insights into action, you can now bulk-export Indicators of Compromise (IoCs) from your profiles. We support JSON, CSV, and STIX formats, and you can choose whether to include full metadata.If you want to automate things, we've added two new API endpoints: GET /threat_profiles/{id}/download: Exports a package containing all actionable IoCs linked to a specific Threat Profile. GET /threat_profiles/{id}/download_url: Retrieves the download URL to export packages exceeding 32MB.   Smart macOS File ReportsNew self-signed Tags and CDHash Extraction. Our updated codesign parser makes it much easier to check if a digital signature is trustworthy. By showing details like certificate chains and validity directly in the file report, your team can quickly spot spoofed signatures without needing to dive into the code manually.Key Capabilities: New self-signed Tag: The codesign report now explicitly flags macOS binaries that are signed using self-issued certificates. This joins our existing suite of signature status indicators, such as invalid-signature and revoked-cert. CDHash Extraction: The parser now extracts and displays the Code Directory Hash (CDHash)—the unique 20-byte cryptographic identifier used by Apple’s operating systems to verify the integrity and authenticity of a code-signed binary or bundle. Take a look at this search example: More Flexibility for CollectionsTrack your own Actors, Malware, and Campaigns. We use "threat objects" to help organize global intelligence into a clear story. These collections link forensic indicators to a broader narrative, giving your investigations more context.We've expanded this framework so you can create your own custom entities directly on the platform. Any object you create is private by default, but you can easily share it with your team whenever you're ready.By creating a private object, you can now combine your internal data with Google's global view, helping you map out unique attacker profiles. It standardizes how you document threats and speeds up attribution by linking new evidence to groups you've already defined. New Third-Party IntegrationsIntegrations are key to making threat intelligence useful. They help you turn raw data into action, break down data silos, and speed up your response times (MTTR).Our latest integrations include: Analyst1 Fortinet FortiGuard AWS GuardDuty Cyware Intel Exchange Sumo Logic Crowdstrike TheHive ServiceNow Fortinet FortiSOAR Google Security Operations Jira Cloud Mimecast You can see the full list of our technology integrations here.What's New with Agentic Better Malware Analysis with a Persistent File System. Agentic threat intelligence capabilities in Google Threat Intelligence are designed to automate your hunting and investigation workflows. It uses specialized agents that have direct access to Google Threat Intelligence data, meaning you don't have to pivot between tools manually. It translates raw data into simple summaries, changing how you interact with complex threats.We're introducing a new persistent file system for the platform. This gives the agent an isolated environment to explore directories and read configs autonomously throughout a session. By carrying evidence forward, the agent can now perform much deeper dives into malicious behavior over an extended timeline. HTA Analysis and De-obfuscation in Agentic.Agentic threat intelligence delivers support for analyzing and de-obfuscating HTA files—a common way for attackers to get initial access. The agent can now pull apart complex HTA files while filtering out noise, helping you see the critical indicators faster.Key Capabilities: Advanced Evasion Detection: The agent immediately spots malware attempting to evade detection by masquerading as legitimate software (e.g., fraudulent updates). Deep Code De-obfuscation: It natively decodes complex, custom encryption schemes (such as XOR layers) to reveal the underlying malicious script. Full Attack Chain Visibility: It automatically extracts hidden secondary payloads and identifies Command & Control (C2) infrastructure, giving analysts a comprehensive picture of the threat vector. Advanced Office Document Analysis in Agentic.We've also improved how we handle Office documents. The agent now uses a structured approach to spot malicious macros and exploits in Word, Excel, and RTF files. It runs specialized tools and expert rules to give you a clear verdict: BENIGN, SUSPICIOUS, or MALICIOUS.Key Capabilities: Macro Heuristics & De-obfuscation: Automatically detects and analyzes suspicious VBA and Excel 4.0 macros, peeling back obfuscation layers to reveal hidden payloads. Exploit Detection: Identifies known exploit patterns and initial access techniques, such as Equation Editor overflows and malicious remote template injections. Structured Reporting: Generates a clean, analyst-ready report complete with a clear logical reasoning chain and raw supporting evidence.   By automating macro de-obfuscation and exploit detection, agentic threat intelligence provides security analysts with the clarity needed to confront complex document-based threats. This structured approach to reporting transforms raw technical findings into actionable insights, empowering teams to identify malicious payloads with significantly greater speed and accuracy.In conclusion, the May 2026 updates represent a significant leap forward for the Google Threat Intelligence platform. From the introduction of new curated YARA rules and streamlined bulk IoC exports to enhanced macOS CDHash extraction and the flexibility of custom collections, these tools provide deeper visibility into the modern threat landscape. Combined with an expanded ecosystem of third-party integrations and the powerful new agentic AI capabilities—including a persistent file system and sophisticated document de-obfuscation—security teams are now better equipped than ever to contextualize emerging threats and drastically accelerate their response times.  Community Blog Wed, 03 Jun 2026 17:57:08 +0200 https://security.googlecloudcommunity.com/community-feedback-70/i-love-the-idea-but-what-is-the-point-7470 So, I've been in this community for a while now and I'm still not really sure what it's all about. Since we can't even use the Google/Mandiant tools, why is that what everyone talks about? I think it could be awesome if more members could get involved. Community Feedback Wed, 03 Jun 2026 15:54:03 +0200 https://security.googlecloudcommunity.com/google-threat-intelligence-67/adoption-guide-visual-investigations-and-campaign-mapping-in-google-threat-intelligence-threat-graph-7645 Authors: Robert Parker, Senior Technical Solutions ConsultantDomnic Chua, Global Security Architect An Adoption Guide In Depth Review for Entity Relationship GraphsIn the contemporary threat landscape, static indicator analysis is no longer sufficient to track sophisticated adversaries who utilize ephemeral infrastructure and modular attack chains. Visual relationship mapping is the superior methodology for identifying the "connective tissue" between command-and-control (C2) domains, recycled malware variants, and pivot IP addresses (Get started with Threat Graph). The Google Threat Intelligence Graph transforms isolated data points into a cohesive narrative, allowing analysts to visualize the lifecycle of a campaign rather than just its individual symptoms (Overview).The Google Threat Intelligence Threat Graph is a sophisticated engine built upon a massive dataset of files, URLs, domains, and IP addresses. Strategically, this tool shifts the security operations center (SOC) from a reactive search posture to proactive, relationship-oriented pivoting. By mapping over 30 distinct relationship types including downloaded files, parental execution chains, and domain-to-IP resolutions over time this enables analysts to move beyond the "what" of a threat to the "who" and "how," for footprinting the entirety of an adversary’s operational infrastructure. This Adoption Guide provides the framework for initializing investigations, mastering node interpretation, and executing advanced commonality hunting to achieve a comprehensive understanding of the tools and how to harness the power of visual threat graphs.The modern cybersecurity landscape requires analysts to move beyond isolated indicators of compromise (IoCs) and understand the complex, interconnected ecosystems of digital threats. Google Threat Intelligence Threat Graph provides advanced visualization and relational analysis tools built on top of one of the world's largest security datasets.What You Can Do With It: Visualize Relationships: Transform flat lists of IoCs into interactive maps detailing over 30 types of relationships between the entities in your investigations. Pivot Intelligently: Seamlessly traverse from a single malicious artifact (like a phishing URL or an undetected malware hash) to uncover an adversary's wider network of domains, IPs, and command-and-control (C2) servers. Identify Threat Commonalities: Automatically analyze a cluster of nodes to extract shared characteristics (e.g., identical SSL certificates, shared Imphashes, or common hosting providers), turning isolated clues into robust YARA rules or blocklists. Learning the Threat Graph Architecture: Nodes and EntitiesUnderstanding "Node Anatomy" is critical for rapid triage during incident response. Visual markers serve as pre-cognitive indicators, allowing an analyst to assess the weight and severity of a threat before performing deep-dive forensics. This immediate situational awareness ensures that the investigation focuses on high-impact pivots rather than low-value artifacts. Entity Type ClassificationThe following table defines the primary entities encountered within the Google Threat Intelligence environment and their visual icons:  Entity Type Visual RepresentationIcons Strategic Significance Files       These are represented as rectangular nodes containing a file type icon (e.g., EXE, DLL, DOC).  This visual cue allows analysts to instantly distinguish between executables, documents, and scripts within a complex infection chain. Domains   Uses Faviconif Available Represented by the domain's favicon, if available. This is a powerful visual aid, as it allows analysts to spot brand impersonation (e.g., a fake PayPal icon on a strange domain) instantly. URLs     Depicted by a specific icon (typically a globe or link symbol), differentiating specific web pages from the root domains they reside on. IP Addresses     These nodes display the flag of the country where the IP is geo-located. If the country is undetermined, a black rectangle is used. This allows for immediate geographic profiling of infrastructure. Relationship Nodes       Represented as circles containing a representative icon. These nodes are unique as they act as aggregators, grouping multiple entities that share a specific relationship type (e.g., "Contacted URLs") to prevent graph clutter.  A sample illustration of the common icons used in Threat Graph Advanced Node AnalysisOrganizations utilizing Private Graph features gain access to Advanced Node Types, which provide a "So What?" layer beyond standard public telemetry (Nodes). Targeting & Attribution: Nodes such as Actor, Victim, Department, and Email allow analysts to map specific victims within a corporate hierarchy and link them to known threat actors. Infrastructure Depth: Device, Port, and Service nodes reveal the technical specifications of a target environment. Infrastructure Persistence: The SSL Certificate node is a vital pivot point for identifying shared hosting environments, enabling analysts to track an adversary even after they migrate IP addresses. Monetization Tracking: The Wallet node allows for the mapping of an adversary’s monetization infrastructure, potentially linking disparate malware campaigns to the same financial threat actor.             A sample of manually Added Relationships which can be added to Threat Graphs  Interpreting Visual Logic: Verdicts and Relationships Node Status and Navigation IndicatorsThreat Graph utilizes a "Relationships Oriented" philosophy to reveal the movement of an adversary. This logic is communicated through color-coded telemetry, which is essential for rapid triage and identifying "known-bad" infrastructure during active incident response. Color Coding and Visual Cues  Visual Indicator Visual RepresentationIcons Description & Significance Red Nodes & Edges   Indicate that the entity has one or more malicious detections from security vendors. Gray/Black Nodes   Indicate undetected entities or entities with zero detections. Blue Nodes & Edges     Indicate the currently selected node and its direct connections.  When a node is selected, its direct connections are highlighted, focusing the analyst’s attention on the immediate neighborhood of the threat. Black Circles (Top Right)     A small black circle on a node means it has not been expanded yet. Double-clicking it will auto-expand its relationships. This signals that further relationships exist "behind" the node. Double-clicking triggers an auto-expansion to uncover hidden infrastructure. This icon distinction allows analysts to instantly separate verified threats from "gray-ware" or clean services. By tracing the paths between Red nodes, an analyst can map the core malicious spine of an attack. Relationship Logic and Edge DirectionalityArcs represent the directional flow of a relationship (For example, a file contacted a specific IP or a file is executed by a parent file).Google Threat Intelligence maps 30+ inter-item links, such as communicating_files, contacted_domains, and execution_parents. Directional lines represent the relationship between entities, therefore  understanding the edges and the relationships helps us to answer various questions an intelligence analyst may have as they perform their investigations.    Relationship Direction Investigative Question to Answer Execution Parents Backward "How did this malware arrive?" (e.g., Word Doc) Dropped Files Forward "What did this malware install?" (e.g., Payload) Communicating Files Lateral "Who else uses this C2 server?" Passive DNS Historical "What domains lived on this IP?" Scenario #1:  Investigating an Emotet Infection Threat Graph can help answer where did this malware arrive, what was its payload, and what other files also deliver this malware payload?Follow along with the above Emotet infection example to understand how we can answer some of the above questions with regards to reviewing a malicious zip file and its contents of an Emotet related Word Document. In this scenario, imagine a user was sent a zip file as an email attachment.  Within that zip file, is a malicious word document which contains Emotet malware.  We start with examining a Zip file at the bottom of the graph. This is the beginning of the infection chain, where a user was emailed a zip file as an attachment.  When looking at #2 on the graph, we see that is a malicious word document, which has an execution parent of #1, (the zip file).  We follow the arrows from #2 to item #1, which tells us that this word document has an execution parent source of the zip file. Reviewing the files around #3 we can now see these are the dropped files that came from the word document in #2.  We can observe XML, LNK, and EXE files being dropped from the word document. A portable executable PEEXE file is also dropped by the word document in #2.  This is shown by the item #4. While this was initially clumped together by the other files in #3, this was moved away from the cluster for easier identification. When asking the question, “What other word documents also execute this same EXE as #4, we see the additional file of #5 from the relationships perspective.  Instantiating and Managing Persistent InvestigationsThreat hunting is an iterative, collaborative process. The ability to instantiate a persistent investigation ensures that findings can be saved, resumed, and peer-reviewed without loss of context. Workflow InitializationInvestigations are typically started through two methods: Direct Search: Use the search functionality to find public graphs, team-specific graphs, or specific hashes to identify existing investigations.    Searching for publicly shared threat graphs from the main page   The Pivot: From a standard file, domain or URL report, select More > Explore in Threat Graph to transition from static data into the visual synthesis engine (Get started with Threat Graph).   Pivoting from a search for a URL instantly into Threat Graph  Graph Management and Role-Based AccessUnderstanding RBAC for graphs is essentially for proper sharing and maintaining operational security.  Access and modification rights are governed by three primary roles to maintain data integrity.   Role Permissions When to Use Owner Full access; can delete the graph. Ultimate control over the investigation lifecycle  Editor Can expand/delete nodes; add collaborators. Enables collaborative hunting and active peer review  Viewer Read-only access. Ideal for sharing finished intelligence with stakeholders without risking data modification  Privacy and Operational Security (OPSEC) ConsiderationsVisibility settings are critical for maintaining the confidentiality of an ongoing investigation. Private Status indicates Saved investigations are private by default, ensuring that only authorized team members can view the graph. Public/Embed Status means once an investigation is finalized, it can be set to public or embedded into external reports using iframes. This facilitates broader community intelligence sharing.  Advanced Analytical Actions: Node Expansion and SubmissionsPivoting is the force multiplier of threat intelligence. By expanding nodes, an analyst uncovers the "unseen" connections that an adversary believes are obscured.  Expansion Mechanics and Tactical Outcomes Using the full expansion option triggers all available expansions for a node simultaneously. This can be performed by selecting the full expansion Icon, or double clicking the node in the graph. This is used to rapidly footprint a campaign’s initial scope, but also can lead to a very confusing and busy graph.     Full expansion triggers all the relationships to be shown at once, however this can make for a messy, and visually difficult to follow graph   It is recommended to start with a specific pivot which attempts to answer hypotheses, and in doing so uses a simple targeted expansion. Remember our hypothetical questions from earlier, expand the relations out one at a time to answer your hypotheses during an investigation. A targeted expansion is a manual selection of specific links to prevent "graph clutter" in high-volume environments.  This systematic approach helps us to answer our questions about the entity to build & understand the relationships of the entity in question.  Those Icons are the ones shown below.    Expanding on the single relationship at a time button Visual Noise Reduction (Highlighting): The Highlight feature hides all nodes not directly connected to a selected entity. This is vital in complex graphs to maintain focus on the relevant attack path.  Interactive Layout ControlsTo create a readable narrative of an attack, analysts should utilize the following controls: Labeling: Allows for custom naming of nodes (e.g., "Primary C2") to provide clarity for other collaborators Pinning: Removes the "gravity" or animation from the graph, sticking a node to a specific location.  Labeling (Left Icon) and Pinning (Right Icon)Temporal and Geographical ContextThe Submission Box on the left hand navigation panel provides a graphical representation of when and where a file was seen. By grouping submissions by country or upload date, analysts can identify the origin of a campaign and the adversary's target demographic over time (Nodes). Viewing which countries have submitted the file and when the file was uploadedExecuting Commonality Calculations and HuntingPattern recognition is the hallmark of a master hunter. Adversaries often reuse SSL certificates, file paths, or registration details across disparate attacks. Commonality calculations allow analysts to identify these shared TTPs in real-time.  Advanced Tools: Commonalities WorkflowCalculations are performed based on the current selection in the right-side toolbar.  The calculate commonalities button  Global Pattern Check: If 0 or 1 node is selected, the toolbar shows commonalities for the entire graph, enabling an analyst to find broad themes across the whole investigation. Selection Analysis: If more than 1 node is selected (via Shift + Click or Drag), the toolbar calculates commonalities specific to those items. Manual Trigger: For a Relationship Node, click Calculate commonalities in the left drawer to analyze all "children" grouped under that node. Advanced Tools: Similarity with Vhash and Similar-to:To elevate an investigation from simple analysis to proactive threat hunting, analysts must utilize GTI's advanced processing engines.The Commonalities Engine: By selecting a cluster of malicious files or infrastructure and clicking "Calculate Commonalities", the platform automatically finds shared metadata and behaviors. This is critical for zero-day hunting. For example, if two separate malicious Word documents share the same specific Office Macro Name or Exiftool Language Code, you can pivot on those commonalities to find related, undetected infrastructure.Vhash vs. Similar-To vs ssdeep functionality: Vhash: A proprietary similarity clustering algorithm created by GTI based on simple structural features. Searching via vhash:<vhashvalue>  yields an Exact Match of a structural blueprint, useful for pinpointing the exact same malware builder or document template. Similar-to: Searching via similar-to:<SHA-256> calculates algorithmic distance (a fuzzy match). This is ideal for discovering evolving malware variants, slightly modified payloads, or broader threat families. This is used by searching for this in the Google Threat Intelligence Search bar. ssdeep: a standardized, open-source fuzzy hashing algorithm, which Unlike a traditional cryptographic hash (like MD5 or SHA256) that completely changes if a single byte is altered, ssdeep breaks a file down into smaller chunks, hashes those individual chunks, and combines them.  This allows you to compare two files at the byte-content level and get a mathematical percentage of how similar they are (e.g., an 85% match), even if a threat actor added, removed, or modified parts of the payload. ssdeep is an open-source standard, whereas vhash and similar-to: are proprietary to Google Threat Intelligence.    How to review the Vhash and ssdeep of a file hash using our Word Document from Scenario #1Moving from Visualization to Active DefenseIdentified commonalities can be operationalized via the contextual menu (Commonalities and Hunting): Launch VT Search: Find other entities in the global database sharing this attribute (Commonalities and Hunting). Add Relationship Node: Visually link all nodes sharing the commonality on the graph (Commonalities and Hunting). Create YARA Rule: Automatically generate a YARA ruleset based on the shared attribute. This bridges the gap between investigation and active detection.   Creating a YARA rule for Livehunting using the common macros found in both Word documents from Scenario #1.  Practical Incident Response ScenariosBelow are real-world examples illustrating how to use Threat Graph during an incident response or threat hunting engagement. Practical Use Case 1: Unmasking a Massive Phishing Network (Infrastructure Reuse) Threat Scenario: An analyst investigated a suspicious WhatsApp link targeting users of "Yad2" (a legitimate secondhand marketplace). The Pivot: The analyst dropped the initial phishing URL into Threat Graph, which revealed the specific IP address hosting the site. Knowing that attackers rarely buy a new server for every single site, the analyst pivoted on that IP address node to view all domains resolving to it.  The Result: The single WhatsApp link was actually part of a massive, global operation. The graph revealed over 800 different scam domains hosted on that exact same infrastructure, impersonating hundreds of legitimate global brands.  Practical Use Case 2: Mapping the Infection Chain & Spotting Decoys (Agent Tesla) Threat Scenario: A suspicious .exe downloader was found on an endpoint. The analyst needed to know what the payload was and how it got there. The Pivot: Graphing the executable hash revealed its "Parents" (the RAR archives the executable was initially embedded inside). Expanding the "Communicating Domains" from the executable revealed the malware was reaching out to several benign football club sites including realmadridt.]com, chelseafcv.]com) alongside a highly suspicious, randomized domain.  The Result: The visual layout made it immediately obvious that the football domains were "red herrings" meant to confuse automated sandboxes and analysts. By pivoting strictly on the suspicious domain and checking its "Downloaded Files", the analyst found the true final payload of the Agent Tesla infostealer. Practical Use Case 3: Containing the "Blast Radius" in Incident Response Threat Scenario: A company's SIEM alerts on a zero-day exploit payload executing on a single employee's laptop. The immediate instinct is to wipe the laptop, but the SOC needs to know if the attacker spread laterally. The Pivot: The responder graphs the initial payload hash and pivots to find its C2 IP address. They pivot on that C2 IP, revealing 5 other distinct malware hashes communicating with that same server.  The Result: The responder takes those 5 new, undiscovered hashes and queries their internal EDR (Endpoint Detection and Response) tool. They find that 3 other laptops in the marketing department have those sibling hashes quietly running on them. VT Graph allowed them to find the full scope of the breach rather than just playing whack-a-mole with the first alert.Operationalizing and Disseminating FindingsA graph investigation is only valuable if it leads to defensive action. Once you have mapped a threat ecosystem, you must operationalize it: Exporting your Threat Graph findings Export to Defensive Controls: Using the Export menu, you can download graph nodes as JSON, CSV, or STIX formats, or export them directly as a MISP event to feed into your SIEM (SecOps/Splunk) or EDR blocklists. Send to Collections: Export the entities from your Threat Graph into a Collection inside of Google Threat Intelligence which can be shared with your team, or integrated into your IOC Stream data. Convert to Detections: Use the Commonalities function to identify shared behaviors (e.g., common Office Macro names), and convert these patterns into automated YARA rules via Livehunt to catch future zero-day variants. Collaborate via Private Graphs: Save your investigation as a Private Graph to keep your ongoing incident response confidential. You can add specific SOC team members as Viewers or Editors, allowing synchronous collaboration without leaking sensitive data to the public Google Threat Intelligence community. Executive Reporting: Use the Embed feature to copy HTML snippets of your graph directly into incident tickets or executive threat intelligence briefings.   Locating the share / embedding link For Threat GraphsSummary and Path to MasteryThe transition from tool user to master hunter requires seeing the Threat Graph as a synthesis engine for the entire Google Threat Intelligence ecosystem. Professional rigor demands a systematic approach to every investigation, moving beyond isolated indicators to understand the complex, interconnected ecosystems of digital threats. By leveraging over 30 distinct relationship types, analysts can move beyond the "what" of a threat to footprint the "who" and "how" of an adversary’s operational infrastructure. This strategic shift transforms the SOC from a reactive search posture to one of proactive, relationship-oriented pivoting and visual campaign mapping. Strategic Checklist for Success Resolve Unexpanded Nodes: Always check for the "black circle" indicators to ensure no part of the adversary's infrastructure remains hidden. Triage via Verdicts: Prioritize Red-verdict nodes during the initial pivot phase to identify the core malicious infrastructure. Regularly Calculate Commonalities: Use global pattern checks to find the "pivot points" that link isolated incidents to wider campaign activity. Leverage External Context: Utilize the Global Landscape module to compare internal graph findings with established Threat Profiles, Actors, and Malware Families to achieve accurate attribution.    Google Threat Intelligence Wed, 03 Jun 2026 11:03:31 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/secops-iam-based-access-controls-7481 Hi, for some reason, I cannot give GCP users access to our SecOps instance even when the instance should be configured in a way that authentications and authorizations should just work with IAM. I have added the needed roles for the users. I had to give accesses with the Group Mapping feature, by adding the users there with their email-usernames. They can access but they do not have the chronicle.propertySchemaDefinitions.get permission even if I give them Tier1-Tier3 roles. Therefore, they cannot really work with the cases. How I can give them the permission or how I can fix the IAM access feature? How to debug it? I’m not gonna give them admins to SecOps.. Google Security Operations Wed, 03 Jun 2026 09:35:17 +0200 https://security.googlecloudcommunity.com/fraud-defense-recaptcha-6/switching-google-s-role-with-recaptcha-from-data-controller-to-data-processor-6716 On April 2, 2026, reCAPTCHA will transition  from a Data Controller to a Data Processor, offering customers greater control over their users' personal data. With this switch, customers deploying reCAPTCHA on their websites will become data controllers,  while  Google will become a data processor. To learn more,  check out our blog.   Fraud Defense (reCAPTCHA) Wed, 03 Jun 2026 00:59:55 +0200 https://security.googlecloudcommunity.com/cloud-security-foundation-7/oauth-app-verification-pending-state-form-18-may-7647 Hello Team,I am facing an urgent issue preventing the continuation of my OAuth app verification process.Project Details: Project Name: project=abiding-beanbag-471016-k5 Sensitive API: Google Calendar i am blocking and app vlaidation form 18 may 2026i didn’t receive any email or return …thanks for anyhelp Cloud Security Foundation Tue, 02 Jun 2026 22:40:49 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/solved-oauth-app-verification-pending-action-but-t-s-response-email-channel-is-failing-6459 Hello Team,I am facing an urgent issue preventing the continuation of my OAuth app verification process.Project Details: Project Name: Simule Agro Project ID: simule-agro Sensitive API: Google Calendar Status: The GCP Verification Center panel showed a "Developer action pending" status due to the "Homepage requirements" issue. PROBLEM SOLVED: My domain ownership has been successfully verified in the Google Search Console, fulfilling the homepage requirement. Critical Pending Action:The panel instructs me to "Reply to the email conversation with the Trust and Safety team." However, I have encountered two issues: I did not receive the initial contact email from the T&S team at my developer contact address. When I proactively tried to send a status update to the standard verification address ( [removed by moderator] ), the message failed to deliver ("Address not found"). Request:Could you please provide the correct email address or an alternative communication channel I should use to notify the Trust & Safety Team that the pending issue has been resolved, so they can immediately resume my app verification process?Thank you for your help in resolving this channel issue. Google Security Operations Tue, 02 Jun 2026 21:17:23 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/what-s-new-in-google-secops-2026-05-31-7646 Another great weekly update from Chris Martin, Google Security Specialist. Thank you Chris. Keep the insights coming!  What’s New in Google SecOps for the interval May 25 through May 31, 2026. HighlightsAnother week, and lots of SecOps updates. A usual great post from John Stoner on Managing Table TTL and Row Expiration Chris Martin wrote up a brief guide on Advanced Filters in SecOps Native Dashboards And last but not least, a short video on Data RBAC in Google SecOpsWhat’s New in Google SecOps, May 31st 2026 Product Updates & New Features Google SecOps Release Notes from Google Cloud DocumentationGoogle SecOps tenant administrators can now directly manage access to public preview features via a dedicated page, eliminating the need to go through official support channels. cRead More]Manage access to preview features | Google Security Operations | Google Cloud DocumentationThis guide is for SOC managers who want to manage access to features and for security engineers who want to view and…docs.cloud.google.comThe Chronicle API has been upgraded from v1 beta to v1, signaling its stability and readiness for production use, offering a more robust, secure, and extensible experience for new integrations. cRead More] Google SecOps has introduced a new focused support policy for Standard parsers, aiming to enhance platform stability, predictable performance, and high-quality data normalization by structuring service level objectives based on customer support tiers. nRead More]Standard parser support policy | Google Security Operations | Google Cloud DocumentationGoogle SecOps provides a wide range of prebuilt, out-of-the-box standard parsers to help you quickly ingest and…docs.cloud.google.com Google SecOps Parser Support Policy SecOps SIEM New Doc: Ingestion > Cloud Context Parsers > GCP SQL Context from Google Cloud DocsThis document describes how Google Cloud SQL context logs are collected and normalized into Google Security Operations’ Unified Data Model (UDM) aRead More]️ ️️Updated Doc: Reference > Detection Engine Api from Google Cloud DocsThe document outlines a shift in how API responses represent detection data, primarily through the introduction of a new detection.variables field that uses structured FindingVariable objects to provide detailed, typed data. Consequently, the previous detection.outcomes list has been officially deprecated and should be replaced by this new mapping in future implementations. Updated sample responses now reflect both structures to assist developers with the transition. Updated Doc: Reference > Chronicle Api Feeds from Google Cloud DocsA mandatory 5-minute ingestion lag is applied to all log types ingested via the Microsoft fetcher (including Azure AD and Microsoft Graph Security API). This lag is an architectural requirement due to late data availability within the Microsoft Graph API. Consequently, status changes occurring within this 5-minute window may not be captured as intermediate events. This inherent latency is a known behavior and may result in event count discrepancies when compared to other ingestion methods or platforms. Updated Doc: Reference> Feed Management Api from Google Cloud DocsThe key change in this document concerns the ingest schedule details for Google Workspace Activities from admin.googleapis.com. Previously the ingest schedule was simply stated as “Every hour”. Now the schedule is more detailed, specifying Native ingestion: “real time”, and Feed based ingestion: “5-hour minimum for login and user_accounts events to prevent data loss” Updated Doc: Event Processing > Entity Graph from Google Cloud DocumentationThe “ECG data processing pipeline” documentation has been restructured with improved navigation and a shift toward “best practices,” specifically detailing how merging enables enhanced connections and derived context.  Key technical additions include precise merge-key requirements for File, URL, and Domain entities, alongside clarified logic for conflict resolution and deduplication across multiple context sources.  The update also explains that when entity attributes change, previous values are retained to ensure search results remain accurate across different time intervals. SecOps SOAR New Feature : Support for SOAR Custom Fields in Native Dashboards! from Google Cloud Security CommunityGoogle Security Operations has launched a new feature, supporting SOAR Custom Fields in native dashboards. This allows customers to track alerts and cases more effectively by capturing organization-specific incident response data. Read More]Create and manage calculated fields | 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 Updated Doc: Respond > IDE > Building A Custom Integration from Google Cloud DocumentationThis update introduces a recommended workflow using the Marketplace CLI (mp) and uv package manager to automate the packaging of complex, nested dependencies for custom integrations. For users choosing manual uploads, the documentation now explicitly requires individual wheel files for the entire dependency tree to avoid errorCode: 2000 failures.  Additionally, the guide includes a minor bug fix in the ArmisManager example code to ensure proper API token assignment. Updated Doc: Working With Remote Agents > Migrate Remote Agent To Google from Google Cloud DocumentationIntroduction of Podman Support, with new instructions added for Podman users on how to securely store the service account key. Dedicated sections are introduced for Podman on how to migrate environment variables for existing agents and how to migrate the service account into the Remote Agent. Google Threat Intelligence Release Notes from gtidocs.readme.ioThis article announces several new features and updates, including advanced HTA and Office document analysis, macOS CDHash extraction, third-party integrations, and bulk IoC downloads, along with a reminder for the Google TI Mondays series. pRead More] Google Cloud Introducing Google AI Threat Defense to help you outpace the adversary from Google Cloud BlogGoogle is introducing its AI Threat Defense system to help organizations combat the growing landscape of AI-powered cyber threats. ARead More]This is a bundle positioning Wiz, Gemini, Codemender, and Mandiant. The aim is to use AI to help prioritize which bugs to fix, and even fix them for you.  Developer’s guide to Gemini Enterprise and A2UI integration from Google Cloud BlogThis article provides a developer’s guide on integrating Gemini Enterprise with A2UI to build more effective AI applications, such as chatbots that better understand user context. tRead More] AI in SRE: Where and how Google is deploying agentic AI to improve operations from Google Cloud BlogGoogle is actively deploying agentic AI within its Site Reliability Engineering (SRE) practices to enhance the reliability and operational efficiency of its critical services. lRead More]This is orthogonal to SecOps, but the concepts discussed here for SRE approaches to building Agents is very relevant and useful reading. Adoption Guides & Deep Dives New To Google SecOps: Fade to Grey: Managing Table TTL and Row Expiration from Google Cloud Security CommunityThis article from John Stoner article discusses managing table Time-to-Live (TTL) and row expiration within Google Security Operations (SecOps), building on previous discussions about data table capabilities for handling large datasets and rule integration. nRead More] Risk Tiering AI Use Case — A Practical Guide from Google Cloud Security CommunityThe article is a practical guide on risk tiering AI use cases, focusing on comprehensive AI governance for enterprise-wide transformation, particularly with generative AI. rRead More] 3rd Party Blogs Advanced Filters in SecOps Native Dashboards from Chris Martin (Chris Martin (@thatsiemguy)The article details the functionality and advantages of advanced filters integrated into Security Operations (SecOps) native dashboards. iRead More] MSPs Become The AI Operations Layer For SMBs from raffy.chThe article discusses how Managed Service Providers (MSPs) are evolving to provide AI-native security operations as an “AI operations layer” for Small and Medium-sized Businesses (SMBs), moving beyond basic alert triage. oRead More] Breaking the Patch Sound Barrier Part 2: So Is The Apocalypse Coming and What Is It? from Anton on SecurityThis article, part two of a series, delves into the challenges of software patching and explores the potential severe consequences or ‘apocalypse’ associated with these issues. oRead More] Podcasts & YouTube️ EP279 Native Cloud Security: Is ‘Good Enough’ Actually Winning? from Cloud Security PodcastThis podcast episode debates whether native cloud security controls provided by cloud providers are sufficient or if third-party solutions are superior, revisiting the ‘Native vs. Third-Party’ discussion. rRead More] Introducing Google AI Threat Defense from YouTubeGoogle is introducing a new initiative focused on leveraging AI for threat defense. TRead More] Introduction to Data RBAC in Google SecOps from YouTubeThe content provides an introduction to Data Role-Based Access Control (RBAC) within the Google SecOps platform. MRead More]Introduction to Data RBAC in Google SecOps CodeMender Identifies and Proposes Effective Code Fixes to Secure Your Applications from YouTubeCodeMender is a tool designed to identify and propose effective code fixes, aimed at securing applications. tRead More] Wiz Evidence at the Moment of Attack. Answers at AI Speed from Wiz BlogWiz Sensor Forensics is now generally available, automatically capturing forensic artifacts at the moment of detection and leveraging AI to accelerate investigations for security teams. WRead More] Defending at Machine-Speed: Building AI Threat Readiness from Wiz BlogWiz is assisting organizations in adopting an AI Operating Model to achieve machine-speed AI threat readiness and improve defense capabilities. hRead More]The AI Threat Defense pitch from the Wiz perspective State of SDLC Security 2026: How Risk Scales in Modern Development from Wiz BlogThe article provides insights into the evolving landscape of SDLC security, analyzing how modern development practices, tools, automation, and AI are influencing application security risks. rRead More] Google Security Operations Tue, 02 Jun 2026 20:59:41 +0200 https://security.googlecloudcommunity.com/fraud-defense-recaptcha-6/join-our-webinar-to-hear-about-the-evolution-of-recaptcha-as-google-cloud-fraud-defense-7502 Hello Google Cloud Security Community,As autonomous AI agents transform the internet into the Agentic Web, securing online interactions requires a fundamental shift in risk management.Join our launch webinar to see how we are evolving our 20-year heritage from reCAPTCHA into Google Cloud Fraud Defense—a comprehensive trust platform natively built on Google Cloud. As we announced at Cloud Next, this represents a transformation of our industry-leading bot protection into a comprehensive trust platform that secures the entire user journey.What we will cover: The Evolution of reCAPTCHA: Advancing to Fraud Defense to secure the complete customer journey across registration, login, and checkout. Agentic Activity Measurement: Identifying and classifying AI agent traffic using industry standards like Web Bot Auth and SPIFFE. Agentic Policy Engine: Applying granular, real-time control to allow, block, or challenge requests based on risk scores and automation types. AI-Resistant Controls: Using mobile-backed QR-code challenges to verify human presence and make automated fraud economically unviable. Register today: Community Webinar: Introducing the Evolution of reCAPTCHA - Google Cloud Fraud Defense   Fraud Defense (reCAPTCHA) Tue, 02 Jun 2026 18:54:18 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/data-table-event-enrichment-inner-vs-left-vs-outer-6712 Hello,Is there a way to influcence the type of join operation when using data tables ?Previously, when working with splunk there was an option to pick one of 3 choices: inner, outer or left.When working with data tables in secops I see that it behaves like an inner join, which effectively filters results, which is something I want to avoid.Example:when a data table contains account A and events contain account A enrichment works as expected. when a data table contains account B and events contain account A enrichment does not work and events are filtered out (but I want to see them despite ‘unsuccessful’ enrichment). Google Security Operations Tue, 02 Jun 2026 16:02:27 +0200 https://security.googlecloudcommunity.com/google-security-operations-2/no-response-suspended-google-cloud-project-7352 Project id: project-5580276092549813950My project got suspended 5. april, due to misuse of some keys.I have filed an appeal, taking actions on how to prevent this from happening again. But I do not get any response at all.Now observing users are dropping off, users not able to sign on, complaining. It is very devastating to observe, years of developing an app for dog owners. It is very critical.  Actions Taken:• Removed exposed API keys from all repositories and application code• Ensured that no API keys or credentials are publicly accessible• Reviewed all Git repositories and verified that sensitive credentials are no longer present• Updated development practices to prevent API keys from being embedded in client-side applications• Planned migration of all Gemini API requests from client-side usage to a secure backend service• Implemented safeguards to ensure that future API usage is authenticated and controlled• Preparing to rotate all API keys and service account credentials immediately once project access is restored• Added billing monitoring procedures to detect abnormal usage earlierPreventive Measures:• All AI-related API calls will be routed through a secure backend• API keys will be restricted to specific services and usage patterns• Budget alerts and usage monitoring will be configured to prevent unexpected billing spikes• Internal review of credential handling practices has been completedBut Im not able to access the Google Cloud console to create new keys etc. Please help me. Google Security Operations Tue, 02 Jun 2026 14:50:18 +0200 https://security.googlecloudcommunity.com/cloud-security-foundation-7/urgent-production-firestore-db-trapped-in-suspended-project-aidigifront-staging-7625 Hello Community Managers,Our project aidigifront-staging!--tgqphd|[]--> was suspended due to an unrestricted Gemini API key vulnerability. We accept full responsibility and have already isolated the leak locally. However, our entire production database is currently trapped.We have filed a support appeal but desperately need an internal escalation to the Trust & Safety team for a temporary 24-hour access window. We only need enough time to run a gcloud firestore export!--tgqphd|[]--> command and rescue our user data. All incoming and outgoing application traffic will remain completely shut down during this period to ensure no further abuse occurs.Please help us flag this case to a human reviewer.!--tgqphd|[]-->!--tgqphd|[]-->!--tgqphd|[]--> Cloud Security Foundation Mon, 01 Jun 2026 23:41:29 +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 Mon, 01 Jun 2026 19:56:36 +0200 https://security.googlecloudcommunity.com/cloud-security-foundation-7/webinar-alert-6-16-stop-secret-sprawl-and-secure-your-ai-agents-and-workloads-7632 We’ve all been there—a database password left in a .env file or an API key accidentally pushed to GitHub. But what was once a simple oversight is now occurring at a staggering global scale.In 2025 alone, according to the GitGuardian State of Secrets Sprawl Report, 29 million unprotected secrets were found sprawling across GitHub. And the AI revolution is only accelerating the risk: AI assistants are causing code to leak secrets at double the normal rate, while LLM infrastructure is leaking credentials 5x faster than model providers themselves.To tackle this, I'm hosting an upcoming technical webinar with Google Cloud Security Product Managers, ​@bmeador and ​@Phani Madhav Devalla . We're going to share practical approaches on how to move from "Hardcoded Chaos" to a secure-by-design foundation by decoupling secrets from workloads into a centralized, cloud-managed vault.Key topics we'll cover:Stop Secret Sprawl: The fundamentals of using Google Cloud Secret Manager to permanently eliminate hardcoded keys from your repositories and local files.Build Secure AI Agents: Strategies to neutralize prompt injection attacks and safeguard your infrastructure by strictly isolating agent credentials. Optimize Configuration Management: How to efficiently store, access, and separate non-sensitive configuration data from highly sensitive secrets using Google Cloud Parameter Manager. Latest Announcements: A look at our newest capabilities that will help you take your secrets and configuration management to the next level.I'm keen to share what we're building and hear your thoughts.Session Details:When: June 16, 11 am EST/ 8 am PST Register now: https://www.brighttalk.com/webcast/18282/668534What are the biggest challenges you're currently facing with secret sprawl or configuration management in your AI workloads? Please ask your questions in the thread below. Hope to see you there.Cheers,​@DataSecMuse Rashmi Sahni, Senior PMM, Google Cloud Security Team: ​@markcorak ​@anilnandigam ​@pandamoose #CloudSecurity, #AISecurity, #SecureFoundation Cloud Security Foundation Mon, 01 Jun 2026 19:51:47 +0200 https://security.googlecloudcommunity.com/community-feedback-70/firebase-projects-is-down-all-projects-is-gone-7603 All firebase projects is gone ? I am getting message  This project does not exist or you do not have permission to view itTry switching accounts or go back to the homepageStill having trouble?Firebase supportStatus dashboard anyone else facing same issue ? I tried different accounts same issue since yesterday  Community Feedback Mon, 01 Jun 2026 19:46:17 +0200 https://security.googlecloudcommunity.com/community-blog-42/time-travel-in-the-soc-troubleshooting-late-triggering-yara-l-rules-7450 Author: David Nehoda, Technical Solutions Consultant The 11:47 TicketAt 11:47 on a Tuesday, a detection engineer opens a P1. A YARA-L rule for AWS root console logins fired 14 hours after the event. The root account had logged in at 21:32 the previous night, performed IAM changes, and logged out. The rule was correct. The logic was tight. The tuning was sound. But the alert landed the next morning, long after the window to contain the session had closed.The team spends two days on the wrong argument. The SIEM vendor gets blamed. The rule gets rewritten three times. An engineer drafts a. migration plan to a different detection platform. None of that is the problem.The problem is two timestamps.metadata.event_timestamp on that UDM event is 2025-10-13T21:32:04Z. metadata.ingested_timestamp is 2025-10-14T11:29:51Z. Delta: 13 hours, 57 minutes. That rules out the YARA-L engine entirely. The event arrived 14 hours late. What followed was a 60-second check of the AWS CloudTrail feed polling interval. Someone had set it to 12 hours during a rate-limit test six months earlier and never changed it back. Two clicks to restore the 5-minute interval. Rule fires within SLA the next time. Two days of engineering argument wasted.This article is the deterministic way to rule out the wrong layer fast. Executive Summary  Dimension Undiagnosed Delay Systematic Timestamp Audit Detection Latency 6 to 24 hours (silent) Under 5 minutes (near real-time) Root Cause Isolation Days to weeks of finger-pointing Under 60 seconds via timestamp comparison Engineering Waste Weeks rewriting correct rules Zero. Fix targets the actual bottleneck Attacker Dwell Extends linearly with delay Bounded by detection plus response time Breach Exposure $4.5M+ average with extended dwell Contained by rapid detection  Who this is for: Detection engineers, SOC analysts, and security architects who see YARA-L rules fire late in Google SecOps and need to isolate whether the problem is the log source, the ingestion pipeline, or the rule logic itself. The Three Places Delay LivesA late-triggering rule is a symptom, not a disease. The delay lives in exactly one of three layers: Origin Delay. The vendor or log source did not generate or deliver the logs in time. Ingestion Delay. The forwarder, feed, or parser pipeline held the log before it reached UDM. Evaluation Delay. The YARA-L rule engine itself is slow due to misconfigured match windows, expensive regex, or state explosion. The diagnostic process is deterministic. Compare two timestamps, and the layer reveals itself. Vendor Delivery Latency: The Table You Should MemorizeBefore you debug anything, internalize what "on time" actually means. No SIEM configuration can make a log arrive faster than the source will send it.  Vendor / Source Typical Delivery Latency Worst Case AWS CloudTrail (S3 polling) 5 to 15 minutes 30+ minutes during AWS service events AWS CloudTrail (EventBridge) Under 1 minute 2 to 3 minutes O365 Management Activity API 5 to 30 minutes Hours during Microsoft outages Azure AD Sign-in Logs 2 to 15 minutes 30+ minutes Azure Event Hub streaming 2 to 5 minutes 10 minutes Okta System Log 1 to 5 minutes 15 minutes GCP Cloud Audit Logs (Pub/Sub) 1 to 3 minutes 10 minutes CrowdStrike Streaming API Under 1 minute 5 minutes Duo Admin API 2 to 10 minutes 30 minutes Salesforce EventLogFile Up to 24 hours (hourly tier) 24 hours (daily tier)  Read this carefully. If your YARA-L rule fires 15 minutes after an AWS CloudTrail event, that is inside AWS's own SLA. The SIEM is working. AWS took 15 minutes to write the log into the S3 bucket the feed polls. Rewriting the rule will not shrink that gap. Switching to EventBridge will. Step 1: The Timestamp InterrogationEvery UDM event carries two timestamps. Comparing them isolates the delay in under a minute.  Timestamp Set By Meaning metadata.event_timestamp The log source When the event physically occurred on the endpoint, server, or cloud API metadata.ingested_timestamp SecOps When SecOps received, parsed, and indexed the log into UDM  Running the Comparison Open the SOAR case for the late-firing alert. Navigate to the underlying UDM event that triggered the detection. Inspect the raw JSON and extract both timestamps. Calculate ingested_timestamp - event_timestamp. Interpreting the Delta  Delta Diagnosis Meaning Minutes to hours Origin or Ingestion Delay The log arrived late. The YARA-L engine evaluated it promptly. The rule is innocent. The problem is upstream. Seconds or near-zero Evaluation Delay The log arrived on time, but the YARA-L rule took hours to fire. The engine is the bottleneck. Match window, regex, or queue pressure. Negative (event > ingested) Clock Skew The log source's system clock is ahead of UTC. Fix NTP on the source. Temporal correlation cannot be trusted until you do.  Most of the time, the delta is large. Most of the time, the rule is innocent. Believe the timestamps. Step 2: Fixing Upstream DelaysIf the interrogation proves the log arrived late, debug the pipeline, not the rule.2A. Feed Polling IntervalFor cloud-to-cloud API feeds (Okta, Azure AD, O365, AWS via S3), SecOps polls on a configured interval.Diagnostic: Navigate to Settings > Feeds and inspect the polling interval for the affected log type.  Interval Effect When to Use 1 minute Near real-time for API feeds Critical identity telemetry (Okta, Azure AD) 5 minutes Standard for most cloud feeds Default for non-critical sources 15 minutes Cost-optimized for high-volume, low-priority sources Network flow logs, verbose audit logs 12 hours Almost certainly a misconfiguration Never appropriate for security telemetry  The most common mistake in the field: an engineer sets the interval to 12 hours during initial testing to avoid API rate limits, forgets to change it back, and the SOC operates with a 12-hour blind spot for months. The opening incident of this article is exactly that mistake.2B. Switch from Polling to StreamingFor critical detections, stop polling. Subscribe.  Cloud Polling Path Streaming Path Latency Improvement AWS CloudTrail > S3 > SecOps poll CloudTrail > EventBridge > Lambda > Chronicle Ingestion API 15 min to under 1 min Azure Activity Log > Storage account poll Event Hub > Chronicle Forwarder 15 min to 2-5 min GCP Cloud Audit > Storage poll Cloud Audit > Pub/Sub > Chronicle Already sub-minute, skip polling entirely O365 Management Activity API poll Event Hub via Microsoft Graph connector 30 min to 2-5 min  The economics usually favor streaming. The engineering cost of one EventBridge rule and a Lambda is recovered the first time a real incident is detected fast enough to contain. 2C. Overloaded ForwarderIf you run an on-prem Chronicle Forwarder, the host's resources directly impact ingestion latency.Diagnostic signs: Sustained CPU over 80% Memory pressure causing swap usage Disk I/O saturation on the syslog receiving buffer Network saturation between forwarder and ingestion endpoint Fix: Allocate more resources, or split the workload across multiple forwarders by log type. High-volume sources (firewall netflow, DNS queries) should not share a forwarder with low-volume, high-priority sources (identity logs, EDR alerts). One noisy neighbor can starve a critical feed. Step 3: Fixing YARA-L Evaluation DelaysIf logs arrived on time but the alert fired late, the rule engine is the bottleneck. Three common causes.3A. The Sliding Window TrapA rule with match: $target.ip over 24h forces the engine to maintain running state for every unique $target.ip across 24 hours. With millions of unique IPs, state management consumes massive memory and CPU, delaying evaluation for every rule on the tenant, not just the offending one. Shrink match windows to the minimum viable timeframe for the actual attack pattern:  Attack Pattern Appropriate Window Why Brute force to success over 1h The attack completes in minutes, not hours Impossible travel over 4h Generous for international travel + VPN lag Low-and-slow data exfiltration over 24h Justified. The attack is deliberately slow Malware drop to execution over 10m Execution follows drop within seconds Kerberoasting spray over 1h Spraying completes in minutes  Rule of thumb: If the attack completes in minutes, the match window should be minutes. A 24-hour window on a brute force rule wastes engine resources for zero detection benefit.3B. Unanchored Regex (ReDoS)Complex, unanchored regex applied to the full UDM dataset consumes exponential compute. The engine can throttle or disable the rule entirely. // BAD: regex scans every single event in UDMre.regex($e.target.process.command_line, `(?i).*invoke-mimikatz.*`)// GOOD: filter narrows the dataset, regex evaluates a tiny subset$e.metadata.event_type = "PROCESS_LAUNCH"re.regex($e.target.process.command_line, `(?i).*invoke-mimikatz.*`)Without the event_type filter, the regex runs against every UDM event including network connections, DNS queries, email transactions, and file creations, none of which will ever contain "invoke-mimikatz" but all of which must still be evaluated. The filter drops the evaluation surface by 95 percent or more. Additional regex discipline: Anchor patterns when possible. (?i)\\powershell\.exe$ is faster than (?i).*powershell.*. Avoid nested quantifiers. (a+)+ causes catastrophic backtracking. Use exact string operations when an exact match is sufficient. $e.target.process.file.full_path = "/usr/bin/curl" beats any regex. Catch this before it ships. The YaraL Validator flags unanchored regex and missing event-type filters at commit time, not after a rule goes live and tanks tenant performance. Put it in CI. 3C. Tumbling WindowsYARA-L 2.0 Tumbling Windows segment data into fixed, non-overlapping intervals for deduplication. Unlike sliding windows (continuously evaluated), tumbling windows evaluate once at the end of each interval. The trap: with a 1-hour tumbling window, an event arriving at 10:01 does not trigger an alert until 11:00 when the window closes.  Use Tumbling For Use Sliding For "Alert once per hour if >100 failed logins occur" "Alert the moment the 10th failed login within 10 minutes arrives" Aggregate statistics, deduplication Real-time attack chain detection Volumetric alerts with defined cadence Any detection where time-to-fire matters  Default to sliding. Reach for tumbling only when batched aggregation is the actual requirement. Proactive Monitoring: Stop Waiting for Analysts to ComplainDo not wait for a detection engineer to open a ticket. Build automated health monitoring.Ingestion Latency DashboardSchedule a UDM query that calculates the average delta between event_timestamp and ingested_timestamp per log type. Alert the Detection Engineering channel if any log type's average exceeds your threshold (typical: 15 minutes).Feed Health CheckUse the SecOps v1alpha/feeds API to programmatically verify each feed last polled within its expected interval. If a feed has not polled within 2x its configured interval, it is almost certainly broken. Page someone.Rule Evaluation MonitorTrack the delta between ingested_timestamp and detection_timestamp. If a specific rule consistently exceeds 5 minutes for this delta, that rule needs performance optimization. Open a ticket automatically. Production Deploy ChecklistBefore calling a late-trigger incident closed: Timestamp interrogation run. Delta calculated. Root cause layer identified. If Origin/Ingestion: polling interval verified under 5 minutes for all identity and critical-auth feeds. If AWS is involved: EventBridge path considered for critical detections. If Evaluation: match window audited against actual attack tempo. Shrunk where justified. If Evaluation: every regex in the offending rule has an event_type or equivalent pre-filter. Ingestion latency dashboard live, alerting on 15-minute threshold breach per log type. Feed health API check scheduled, paging when a feed misses 2x its interval. Rule evaluation monitor live for all CRITICAL-severity detections. Runbook updated: "Every late alert ticket starts with the timestamp interrogation. Not with a rule rewrite." Post-incident: if a feed misconfiguration was the cause, infrastructure-as-code the feed definition so a human cannot set 12-hour polling by hand next time.   The Diagnostic TruthLate-triggering rules are a three-variable equation. Large delta: upstream delay. Fix the pipeline. Zero delta: evaluation delay. Fix the rule. Negative delta: clock skew. Fix NTP. Every time a rule fires late, run the interrogation first. Most of the time, the engine is innocent and the delay lives in a vendor's API, a misconfigured feed, or an under-resourced forwarder. The rewrites and vendor-blame sessions you avoid are the real ROI.  Community Blog Mon, 01 Jun 2026 19:26:49 +0200