Google PSOE Exam Insights: Threat Hunting Across Environment Logs

Preparing for the Google Cloud Security Operations Exam, Part 3

Continuing Your PSOE Exam Journey

Welcome back to the journey of preparing for the Professional Security Operations Engineer (PSOE) certification from Google Cloud Security, our next target objective will be 3.1 Performing threat hunting across environments, specifically:

Developing queries to search across environment logs to identify anomalous activity.

Threat Hunting is domain #3 of the Google Cloud Professional Security Operations Engineer cert

While the parent objective, “Performing threat hunting across environments”, is specifically referencing threat hunting, the target objective, “Developing queries to search across environment logs to identify anomalous activity”, applies to a much broader list of roles.

Threat Hunters, SOC Analysts, Engineers, and more all need to understand how to develop queries to identify anomalous activity.

An important distinction is that the objective is asking you to understand how to do this across the environment. This means that you should be able to query across multiple products and event types in a given scenario.

Why Google SecOps Excels at Environment-Wide Search

One of the most powerful capabilities of Google SecOps is the ability to accurately and swiftly query specific data from an expansive dataset. This efficiency is largely due to the implementation of Unified Data Model (UDM). UDM refers to the schema of the standardized log structure developed by Google. 

Diagram showing how Google SecOps normalizes diverse log sources into the Unified Data Model (UDM) for unified search and detection

UDM, YARA-L, and Grouped Fields

Logs that are sent to the Google SecOps SIEM are normalized into UDM. This allows for wide reaching observability, detection rules, and searching. It is important to understand UDM when creating searches because that is the system for how the information you’re looking for is cataloged.

The next consideration when searching is YARA-L. YARA-L is the language that you’ll be using to create the query itself. The only other concept that will be necessary for this article are Grouped Fields in Google SecOps Search. This takes multiple UDM Fields that are logically grouped and consolidates them for the purpose of holistic searching.

An example of a grouped field would be file_path. This grouped field is a collection of the following UDM Fields that can all be accessed by using file_path instead of listing them individually.

• principal.file.full_path
• principal.process.file.full_path
• principal.process.parent_process.file.full_path
• target.file.full_path
• target.process.file.full_path
• Target.process.parent_process.file.full_path

Discovering UDM Fields

Finally, one of the hardest things about learning to use SIEM Search is knowing which UDM Field to use and even just knowing what UDM Fields exist to begin with. The UDM Lookup feature will be the best tool to bridge this gap.

UDM Lookup

UDM Lookup will allow you to search using fields or values. When searching using values, it will prioritize real UDM matches from your logs. The top section is matching on real logs, and then the tool begins to fill in with possible matches.

Using UDM Lookup in Values mode to display real log data matches for “command” fields across your environment

Searching for fields, on the other hand, is helpful when you know the general type of data you’re looking for, but you’re unsure which UDM fields exist that could be representing that data.

Using UDM Lookup in UDM FIelds mode to discover available command_line fields when building YARA-L queries

Example Scenario: Incident Scoping

Let’s explore an example to see how we can combine these concepts to approach a scenario.

Incident

There’s an ongoing incident in your organization. EDR fired a detection on a file named “invoice_q1.docx”. The detection shows that WINWORD.EXE was used to open Powershell.exe with a base64-encoded command. Following this, an unusual network connection was observed to <unusual_IP>:443.

Other team members have verified that this was phishing via email and are already working on investigating the sender and emails that were sent. Your team has been looped in to assist with scoping and you need to craft a search to quickly ensure no other hosts have been compromised.

Indicators of Compromise (IOCs)

For this scenario:

File name: “invoice_q1.docx”
File hash: <hash>
IP: <unusual_IP>
Command: “dGhpcyBpcyBhIHZlcnkgc2tldGNoeSBjb21tYW5kbGluZSBeX14=”

The first killer for time to respond in this situation is looking for these IOCs by product, checking EDR, then AV, then Windows Events, then ProofPoint etc. Because SecOps is ingesting all of these products, and all of their logs are mapping to the same UDM format, we can cast a very wide net with very specific criteria.

Sample YARA-L query in Google SecOps showing Indicators of Compromise (IOCs) across environment logs

If your first thought is, “Oof, that’s a lot of fields”, I’m right there with you. While the above query would now match if any of the IOCs were present in any of the fields listed, it isn’t very efficient to write it out. This is where Grouped Fields can shine.

Optimizing the Search with Grouped Fields

Simplified Google SecOps query using grouped fields and key IOCs to streamline threat hunting across data sources

Now that we’ve incorporated the available grouped fields, searching across all log sources for various types of data is very fast and simplified.

Command_line doesn’t have a grouped field currently, however, if you start typing it out as displayed in the image below, a list of relevant UDM fields will appear for you to choose from.

Google SecOps auto-suggests available command_line fields, helping analysts quickly select the right UDM field

Aggregating Results: Finding the True Scope

Taking this one final step further, we can aggregate our findings logically based on the original goal in the scenario, which was to determine all potentially impacted hosts. We can accomplish this by adding a match section to group the UDM events together. The match section will provide a list of unique hosts that are impacted, instead of generating a large list containing every matching event.

Aggregating threat hunting results in Google SecOps using the strings.coalesce function and match clause to list unique affected hosts

Additionally, you’ll notice a strings.coalesce function when establishing the hostname variable. This function elects to use the first field that has a value assigned to it. In this case, principal.hostname is the primary choice (listed first in the array), and if there is a value assigned to that UDM Field in the triggering event, that value will be used as $hostname. However, if no value is present in principal.hostname, then the function will look at the next UDM Field listed to see if a value exists there. 

It is optional to add an aggregation time frame such as: 

match:  
    $hostname over 12h

This can be helpful and even necessary in some cases if you’re hunting for multiple unique events within a set timeframe.

Exam Tip: Study the “Search for Events and Alerts” Documentation

This article establishes a good baseline understanding for Developing queries to search across environment logs to identify anomalous activity. SIEM Search is a very deep topic and I would encourage anyone who is preparing for the PSOE to read through the “Search for events and alerts” documentation to further cement and expand upon the concepts covered in this article. 

Building effective queries is more than a test objective — it’s a core competency of modern SOC analysis. Google SecOps’ UDM schema, YARA-L query power, and grouped fields make multi-environment threat hunting faster, more accurate, and more scalable than ever.

Extend Your Google SecOps Environment with Managed Detection, Automation, and Threat Intelligence from Foresite

Explore Catalyst →