Google Security Operations

I am trying to write a rule for Google Workspace password resets initiated from a country that has not been seen in the last 30 days.For some reason, the `first_seen` metric is malfunctioning (returning 0 even though the user has logged in from that country before).Any tips? $password_change.metadata.log_type = "WORKSPACE_ACTIVITY"$password_change.metadata.product_name = "login"$password_change.metadata.product_event_type = "password_edit"$password_change.principal.ip_geo_artifact.location.country_or_region != ""$user = $password_change.security_result.about.email$country = $password_change.principal.ip_geo_artifact.location.country_or_regionmatch: $user, $countryoutcome:$first_seen_country = max(metrics.auth_attempts_success( period:1d, window:30d, metric:first_seen, agg:max, target.user.email_addresses:$user, principal.ip_geo_artifact.location.country_or_region:$country))condition: $password_change and $first_seen_country = 0 

**A read-only report for what your rules are actually doing**As detection engineers we all hit the same wall: you can list your rules, but the list doesn't tell you which of them are actually working. Whether a rule is live / alerting, and how much it fires, lives in two other places — the deployment record and the detections endpoint — and nothing joins them back to the rule for you.Following up on the export script I shared earlier, here's the companion: a small, read-only script that joins the three sources and gives you, per rule:- live / alerting / archived state - detections for the **current version** (so the average reflects the config running now, not an old one) - first / last fired, average per day - **who last changed it, and when** - a one-word verdict: **SILENT** (test it) / **STALE** / **TUNE** / **REDESIGN** / **OK**Two honest limits worth flagging: the detections endpoint caps at ~1000 per rule (rules that hit it are marked `CAPPED`), and it's per-rule and rate-limited

The outer join feature recently described by ​@jstoner is a game-changer for YARA-L, but currently its availability is limited to SEARCH.For detection RULES, while the community has shared a couple workarounds, they each come with tradeoffs:in workaround 1. catch-all row in the datatable + reference list guardrail:- scalability: limit of a max number of data tables allowed per rule- longevity: reference lists to be EoL’ed in July 2027- logic conflict: match section is required, turning single-event rules into multi. If the original rule was single-event and -because of enrichment- it is then applied match by any UUID / metadata.id, that would interfere with the alert throttling, making the throttling ineffective.in workaround 2. ingest the table into the entity graphsame limitation of match section described above.My goal is to perform "left outer joins" (enrichments) directly within detection rules - via Data Tables, ECG, or a similar mechanism, to allow us offload heavy enrichment ta

Greetings Team,If we do not want to use Google Cloud's native silent log source monitoring, is there any alternative approach using a scheduled YARA-L rule, similar to the one below that runs hourly?I understand that this approach has a few limitations: The rule requires at least one event from the log source within the previous 24 hours  If incase  a log source has been completely silent from the beginning (i.e., no events have been ingested within the 24-hour lookback window), the rule will not detect it. For intermittently logging sources, because the rule is scheduled to run every hour, it will continue to generate an alert every hour until the log source resumes sending logs consistently. i am aware that even  configuring alert suppression to reduce repeated alerts for the same log source, However, will introduces another limitation: if the log source resumes logging and then becomes silent again during the suppression period, the subsequent log stoppage may not be detected beca

Ingesting Oracle Cloud audit logs to Google Secops. Could anyone tell me which one is the proper type? or what the difference between this two type of logs in Google Secops?https://docs.cloud.google.com/chronicle/docs/ingestion/default-parsers/oci-audit https://docs.cloud.google.com/chronicle/docs/ingestion/default-parsers/oracle-cloud-auditSuper confusing, In oracle side there seems to be inly one type Oracle Cloud Audit Logs,  no idea which one I’m supposed to use. By reading the documentation in google, I cant tell, not event the desciptions. both are are Oracle cloud audit. Thanks in advance. -Eric

Hi Team,Could you please suggest the best approach to integrate Microsoft Copilot logs with Google SecOps.Our objective is to monitor and analyze user interactions with Copilot, including:User prompts submitted to Copilot Copilot responses generated for users

Following the integration guide Collect BeyondTrust Endpoint Privilege Management (EPM) logs  |  Google Security Operations  |  Google Cloud Documentation The python script is quite outdated and attempts to use an API endpoint (/v2/AuditEvents) that no longer exists on the BeyondTrust swagger docs. The OAuth scope & endpoint have also changed since the guide was written. I believe the replacement API is /v2/ActivityAudits, but the response would change the JSON structure slightly, which then could cause parsing issues. Has anyone had any luck with onboarding this source to SecOps? Fairly new to SecOps, but is there a way to submit a ticket and have someone create an updated guide/script/parser?  

Palo Alto Network Firewall Logs Not Parsing. We are using Palo’s Strata Logging to forward Palo Alto Network Firewall Logs to Google Secops Webhook. Some logs are getting parsed and some are not.When we take a look at the logs not getting parsed it shows the raw logs are coming in as a Stacked JSON with no way to do split delimiter due to the structure of the JSON. Has anyone seen this issue?

I'm trying to calculate mttr and mtta per environment; this metric is important for each existing environment. Does anyone know how I can do this in the case_history table?I notice that the `cases` table contains the `cases.environment` field. Is it possible to perform this calculation using that table?MMTR: stage stage1{$case_id = case_history.case_response_platform_info.case_idmatch:    $case_idoutcome:    $case_close_time = max(if(case_history.case_activity = "CLOSE_CASE", case_history.event_time.seconds, 0))    $status = array_distinct(case_history.case_activity)    $TTC = $case_close_time - min(case_history.event_time.seconds)condition:    arrays.contains($status, "CREATE_CASE") and arrays.contains($status, "CLOSE_CASE")        }outcome:    $case_count = count($stage1.case_id)    $MTTC = (math.round(avg($stage1.TTC)/60))MTTA:stage stage1{$case_id = case_history.case_response_platform_info.case_idmatch:    $case_idoutcome:    $case_assign_time = min(if(case_history.case_activity =

If writing your first Google SecOps parser feels like typing in the dark, this is the light switch.Let me say out loud what most tutorials skip: building a parser in Google SecOps is the least friendly part of the platform. Other SIEMs hand you a form, a wizard, a field-mapping screen. SecOps hands you a code block — a filter { } pipeline inherited from Logstash, full of things called grok, kv and mutate, with a regex dialect that isn't quite the one you know, and a preview that answers your mistakes with a single line: "No UDM events generated."No line number you can use. No list of variables. No hint.If you have spent years in Logstash, this feels like home. If you haven't — and most security analysts haven't — your first parser is a wall.To be fair: the design is not wrong. A parser-as-code is versionable, reviewable, portable, and far more powerful than any mapping wizard — this is why serious detection engineering teams end up preferring it. The problem is not the model. The probl

A five-step method for deciding which logs not to ingest — and proving that no live detection depends on them.Google SecOps prices what you ingest. That model is easy to reason about: the bill follows your telemetry, not your seats or your servers. It is a strength, not a weakness — a volume-based cost model is predictable, budgetable, and it forces an honest question onto the table: is this data worth what it costs?But the bill does not tell you which gigabytes are doing security work.Here is what that looks like in the field. One business unit in a retail environment. One log source — the FortiGate firewall fleet, ingested as FORTINET_FIREWALL. In a 48-hour window: 95.3 million events, about 47.6 million a day. 96.7% of them were NETWORK_CONNECTION records. 87.7% carried level = notice — permitted, routine traffic. A healthy network doing healthy-network things.Nobody designed that as a detection surface. It just arrived. And every gigabyte of it cost the same as the gigabyte carryin

I need a dashboard query to fetch the SecOps SIEM alert creation time and SecOps SOAR Case creation time of that same alert. So that I can find latency in case creation.

I wanted to share a practical workflow pattern I’ve been using with Google SecOps for detection rule management.This is not meant as a replacement for the Gemini capabilities already available in Google SecOps. In my environment, Gemini has mostly been relevant on the SOAR / automation decisioning side, while Claude Code has helped in a different layer: as an external workflow layer on top of the Google SecOps API for repetitive rule-management tasks.That distinction matters.I’m not using Claude Code to “chat about alerts.” I’m using it to operate on top of real rule workflows that are usually slow, manual, and inconsistent when done only through the console.The common problems are familiar to anyone who has operated a SIEM for a while:rules become outdated over time rules are created by different engineers or different teams metadata drifts naming conventions diverge validation becomes inconsistent some rules outlive the people who originally wrote themThe detection logic may still be

Hello, We have been using the Triage and Investigation Agent in Google SecOps SOAR using the automatic and manual triggers via the GUI (we’re having separate issues with adding it in as a playbook step).We can collect case data, including case close codes for example which reflect manual verdicts on cases (benign, malicious etc.) - how can we collect data on the verdicts given by the agent? Is there an API? Something in Bigquery or cloud logs?

As SIEM admins, we all get asked for the same thing every so often: "export the rules — give me everything we run." It's routine, and it shows up a lot in audit and compliance.😅Most of the time we don't want to stand up a whole versioning / detection-as-code setup just for that. We just want to export our rules, the way you can in pretty much any other SIEM.Google SecOps doesn't really hand you that today. The docs on this are either thin or jump straight to a full detection-as-code pipeline with Terraform, Git, and CI/CD — great if you run a platform team, overkill if you just need a copy of your rules.So I wrote the simple middle: a small, read-only Python script.- Pulls every rule via list_rules (it never modifies anything). - Writes an Excel, one row per rule, with each meta field and each outcome variable as its own column — filterable and readable. - Also drops one .yaral file per rule as a literal backup.Requirements: a service account with chronicle.rules.list, and pip install

Hello Google SecOps Community,I am facing an issue with a dashboard query that retrieves custom field values from SOAR cases.The dashboard was working correctly until last week, and no changes were made to the query. However, it has recently started failing with the following error:“compilation error query uses a feature that is not yet allowed: invalid argument” The error occurs specifically when querying custom field values. The same dashboard and query were previously returning results without any issues.I've already verified:No changes were made to the dashboard query. The custom fields still exist and contain data. The issue started suddenly after the dashboard had been functioning normally.Has anyone else experienced a similar issue recently? Is there a known change, limitation, or update related to custom field queries that could cause previously working queries to fail with an "invalid argument" error?Any guidance or recommendations would be greatly appreciated.Thank you!

Hi,I am observing 25-45 mins of delay in SecOps case generation.I compared this using alert created time and SOAR case created time.Does anyone know what could be causing this delay issue? This is really critical issue for High and Critical priority incidents. 

Hello,I’ve noticed a new ingestion metric popup from SecOps in GCP Cloud Monitoring. An “is_unhealthy” metric, which I’m seeking to understand a bit further to figure out what it can do. If it lets us do real time alerting based upon findings from Health Hub, that’ll be awesome. If it’s doing something else, some insight here would be rather useful.So, I’ve set a basic threshold based alert, but the “is_unhealthy” metric appears to return a numeric value, which depending on the log type can be anywhere between 40 and 110 in this environment. Is there any view as to what this number represents?  Here’s a view of what I’ve initially setup, which has blasted me with 10-15 alerts on a nightly basis:"conditions": [    {      "name": "projects/redacted",      "displayName": "Chronicle Collector - Ingestion Health Status",      "conditionThreshold": {        "aggregations": [          {            "alignmentPeriod": "7200s",            "groupByFields": [],            "perSeriesAligner": "ALIG

Hello all, We have a use case where we want to fetch a list of filtered playbooks. We have a bunch of playbooks in a specific environment, but only some should pass through the filter -e.g. we only want containment playbooks returned rather than enrichment playbooks.The only API method I know of is this: ApiWorkflowMenuCardDefinitionDataModel  |  Google Security Operations  |  Google Cloud Documentation but there it looks like the only filtering option is client side by string filtering on the playbook name (e.g. only fetch playbooks with a particular string component in the name).Does anyone know of other Chronicle API options? 

Hey everyone, Can a Google SecOps Line Graph display multiple metrics (different numeric fields) in the same chart, or is it limited to a single Y-axis metric?For example, if my query returns:Date Hostname Current_Usage Historical_Average Historical_ThresholdCan a single Line Graph plot the three numeric fields (Current_Usage, Historical_Average, and Historical_Threshold) as three separate colored lines over time, or is one Line Graph limited to only one numeric field?Thank you ^.^

Hello Community Managers,I am posting on behalf of the project owner and urgently asking for guidance or manual escalation.Our GCP project appears to have been affected by credential exposure, hijacked resources, or unauthorized usage.Affected project:- Project name: my digital twin- Project ID: my-digital-twin-5561f- Appeal / Ticket Reference ID: T4RJ5FJRTGPBQAPKNBAOMHF6R4The project was first suspended on May 9, 2026 due to activity related to hijacked resources / malicious activity. We submitted an appeal and explained that a Firebase/API key may have been unintentionally exposed during development, and that remediation steps had been taken.Google restored the project on May 11, 2026 and instructed us to resolve the remaining compliance issues.However, around June 4, 2026, the project appears to have been suspended again after subsequent legitimate use/testing. Since then, we have been unable to access the project normally through the Google Cloud Console. We are redirected to the a

I want to create a rule where the prinicpal ip should not be a private ip. However, we see that the principal ip is containing 2 comma separated values (ipv4, ipv6). I want to split these values so that we can use a data table to store the private ip range range and compare one of the IP from the data table. How can i do that