"New to Chronicle" is a deep-dive series by Google Cloud Principal Security Strategist John Stoner which provides practical guidance for security teams that are either new to SIEM or replacing their SIEM with Chronicle. You can view the entire series here.

A core capability for an analyst is having the ability to search all the data that is being collected. We’ve illustrated that Chronicle users can do this using UDM, the new and improved search interface and now with the addition of pivot. However, analysts may have a need to explore data, or build searches where the values of interest could be the source or the destination, the parent or the child.

For analysts who have worked with the same set of data for an extended period, they often know which fields align with specific vendor events, but when a new data set is introduced or a new analyst starts, a learning curve must be started to learn the data and where it is mapped.

To address the issue of having to know which field is the “right” field to explore, Chronicle has a new capability called Grouped Fields that provides the threat hunter, detection engineer or SOC analyst the ability to search the data in a much more flexible manner that streamlines data discovery for analysts.

Picture yourself sitting down with your hot beverage of choice, ready to find badness today and you are asked to uncover all activity associated with the IP address of 10.11.12.13. In the past you might have typed:

intermediary.ip = 10.11.12.13 OR observer.ip = 10.11.12.13 OR principal.artifact.ip = 10.11.12.13 OR principal.asset.ip = 10.11.12.13 OR principal.ip = 10.11.12.13 OR src.artifact.ip = 10.11.12.13 OR src.asset.ip = 10.11.12.13 OR src.ip = 10.11.12.13 OR target.artifact.ip = 10.11.12.13 OR target.asset.ip = 10.11.12.13 OR target.ip = 10.11.12.13

Now, with grouped fields, your search syntax looks like this:

ip = 10.11.12.13

Simple, elegant and effective. By using grouped fields combined with speed of UDM search, you get structured search and all of its benefits along with easy to build searches. This isn’t just limited to ip addresses. This also applies to fields that contain:

• Domains

• Email addresses

• File Paths

• File Hashes

• Hostnames

• Namespaces

• Process IDs

• Users

How it works

Now that we have covered the concept, let’s apply this to an example. Let’s start by finding all of the process launch or user login events that are associated with the user tim.smith in the past three days. Notice how we have the two event types enclosed in parenthesis separated by the or operator followed by the user grouped field. (metadata.event_type = "PROCESS_LAUNCH" OR metadata.event_type = "USER_LOGIN") and user = "tim.smith" nocase

With our initial search results, we can see that we have 1194 events that meet our criteria. As you may recall, Quick Filters, found on the left side of the screen, allows us to filter on results by selecting values from a specific field and showing only or filtering out the value. Grouped fields can be worked with in a similar manner, so we can filter on the hostname of the active directory server called activedir.stacked pads.local. Or we can filter on a specific field like target.hostname.

With our filtered results, we want a columnar view of the events that contain the hostname and user of interest. We can use our column picker but rather than selecting specific UDM fields, like target.hostname, we can select under the Grouped Fields section hostname and user. In this case, there are seven fields that contain a hostname value and an additional six fields with a user. Of course, if you want specific fields, you could select them at a field by field level. The ability to save and load column groups is always available, but hopefully you can see how quick and easy it is to get to the data with the relevant values within an event.

In order to make this screen capture readable, I removed a few of the extra grouped fields. Here you can see how depending on the event, tim.smith may be the principal.user.userid or the target.user.userid. Similarly, activedir.stackedpads.local could be found in different fields. In fact, results represented in the image below are ALL user login events, so why would these values be in different fields? The answer is that some of these events are local versus remote login events or a user being logged in by another user.  The good news is that with grouped fields, it is much easier to search and view the data to determine what you need.

Let’s look at one more example. A common request is to search for traffic associated with an IP address pair. Let’s find all the events in Zeek and Suricata for the IP addresses 10.10.20.60 and 206.221.181.253. With grouped fields, our search syntax looks like this:

(metadata.vendor_name = "zeek" nocase OR metadata.vendor_name = "suricata" nocase) and ip = "10.10.20.60" and ip = "206.221.181.253"

Adding grouped IP fields to our results as well as network and security result fields from UDM, we can quickly arrive at the communication between these two IP addresses and HTTP communication, user agent strings, bytes sent, bytes received and alerts triggered.

Grouped fields may seem like a simple concept, but the dividends that are paid back to threat hunters, detection engineers and SOC analysts can be huge as they work through the large data sets that Chronicle is collecting and indexing. Remember to use grouped fields the next time you need to explore your data set. Use them to filter and view the data so you don’t miss a thing.