Recently active topics

We successfully established HTTPS log forwarding profiles within Palo Alto Strata Logging Service last year using https://malachiteingestion-pa.googleapis.com/v2/unstructuredlogentries:batchCreate.  Although these profiles continue to forward logs to our SecOps environment, we can no longer manage the profile within Strata due to the following error that follows when testing the connection:  This wasn’t an issue when the forwarding profiles were established and it certainly wasn’t an issue the many times we made adjustments to the profiles throughout last year.  It’s probably been 4-6 months since we last touched these profiles, so it’s unclear when this behavior started. I also noticed SSL Labs is having issues obtaining detail for malachiteingestion-pa.googleapis.com.  Not sure if this is the expected behavior, but figured it was worth mentioning. I have a support case open with Palo first, but figured I’d ask here as well before opening a Google support case.

 Here is how we combine Chronicle YARA-L correlation with Gemini SecOps to solve a tricky detection challenge:What the rule captures in Chronicle: We watch for a single user account accessing Workday from at least two completely different external networks (ASNs) and IP addresses within 30 minutes, while presenting the exact same desktop browser User-Agent. The underlying threat behavior: In Account Takeover (ATO) campaigns targeting payroll and HR systems, attackers rotate external proxies and commercial VPS nodes to evade IP-based rate limiting and geo-blocking. Because the attacker operates the same browser or automated script across those hops, their User-Agent fingerprint remains static while their IP and ASN change. Feeding distilled telemetry to Gemini: Chronicle YARA-L handles the heavy temporal matching across millions of events. Instead of dumping raw logs into an LLM, YARA-L distills the session into concise outcome variables: the distinct list of ASNs, network carrier names

I’m excited to write this blog as we start a new journey to leverage SQL to build searches in Google Security Operations (SecOps). Over the past four years, search in Google SecOps has evolved from boolean logic to adding YARA-L constructs that enabled statistical searches. Along the way, we discussed functions that can be used to further enable these searches. Now, we are not going to stop discussing using YARA-L search, it’s not going anywhere, but we are going to add another tool to the toolbox that can be used in search, and soon in other parts of SecOps, which is SQL. Google SecOps now supports searching in SQL, which means that you now have the option to use YARA-L or SQL as your search syntax. This can be easily toggled in the search screen. Now you may be thinking, “this is another language that I have to learn and everything I’ve heard about SQL is that there is a very rigid structure.”  Traditional SQL does have a specific structure that looks something like this at its most

I'm seeing a specific Android device consistently receive floor scores from reCAPTCHA Enterprise, and I can't find any signal that explains why. Looking for anyone who has seen this pattern or knows what an assessment with score: 0 and no reason codes indicates for the mobile SDK.What I observe on one device (Pixel 9 Pro, Android 17, stock, bootloader locked, verified boot green)Android SDK com.google.android.recaptcha:recaptcha:18.9.2, app installed from Google Play. Every assessment comes back like this:tokenProperties: valid: true, action matches expectedAction, clientSignalsFailed: falseriskAnalysis: score: 0, reasons: [], extendedVerdictReasons: []- 12 attempts over two days: eleven scored 0.0, one scored 0.1. Never a reason code.- Persists across two networks (Wi-Fi and mobile data), across an app-process restart with a fresh client and fresh token, and across a device reboot.- The SDK reports no error — executeTask succeeds every time, so the app has nothing to react to.- In log

Hi everyone,I am attempting to set up ServiceNow CMS as our ITSM for ticket management, and I am wanting to implement a sort of polling in Google SecOps to check if any updates have been made to the ServiceNow case.I am not too concerned with comments being added to the case wall in SecOps, but I am more interested in the ServiceNow case status (Open, Closed, Assigned,) being reflected in Google SecOps.Has anyone done something similar and what worked for you? Thanks,