"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.

With the new year, we are going to introduce a new concept. Well, not a new concept to Chronicle, but perhaps to you. And even if it is not a new concept, hopefully I can provide you additional context (see what I did there).

When we built multi-event rules, we joined different types of events together and we can apply the same concepts to contextual data. Before I dive in and demonstrate, it is important to have a good foundation around contextual awareness. This blog will focus on the concepts and from there we will move to the practical application of deploying contextual analytics with Chronicle’s rule engine.

What is contextual awareness?

When we review an event log, we have a lot of information available to us about the action that was taken on an asset, no matter if the log source is an endpoint, network or authentication event, to name just a few. However, that specific event log does not tell us very much about the user or host that is associated with the event. Sure, it will have a user ID, a hostname or IP address, but there is generally not a lot of context provided that really informs an analyst about the asset or user beyond an identifier. The absence of context is exacerbated with organizations responsible for monitoring hundreds or thousands of employees, contractors and partners coming and going, coupled with a globally distributed enterprise. But, with contextual enrichment of event data, analysts have additional metadata enriched within the events, allowing them to search and develop rules with greater focus and less effort. Let’s have a look!

It is entirely possible that at some point in your career, you have been provided an IP address and asked, “what do we know about…?” Because of that eternal question, let’s start with this example. The question we are attempting to answer is around a particular IP address and the associated processes being run on that asset. We can quickly craft a basic search and based on our time window, we get seven events, two of which are shown below.

metadata.event_type = "PROCESS_LAUNCH" AND principal.ip = "10.1.0.4"

When we view the second process launch event, we can see that we have a Windows 4688 event and a Microsoft Sysmon 1 event. Both of these events are great for capturing processes launching, but neither contain an IP address. They do however, contain a hostname, as you can see in the Raw Log section below.

Chronicle is automatically contextualizing the UDM event data with entity data like the IP address so that an analyst can just ask for the event data and not have to worry whether they have an IP address or a hostname or a MAC address, depending upon the type of event log.

I can’t tell you how many times I have investigated an asset and multiple searches were needed in order to see the events available for that system. I needed the IP address to search network logs, and then conducted a separate search for hostname in endpoint logs. Contextual awareness takes that burden off of the analyst and makes all the relevant data available in a single picture.

How does this apply to users and their identities?

Context applies both to assets and users as they are both entities. In this example, we are searching for process launch events with an email address for a particular user. That email address is not in the Sysmon event, but because the contextual data exists to map the user ID from the event to the email address of the entity, we can search by email address to find the relevant events.

metadata.event_type = "PROCESS_LAUNCH" AND principal.user.email_addresses = "frank.kolzig@stackedpad.local" nocase

This doesn’t just magically happen. We need the entity data to enrich our events. Like any data source, we need to ingest contextual data into Chronicle. Once it is set up, this enrichment continually occurs and updates to characteristics about assets and users flow into Chronicle and are reflected in the event stream.

We can leverage a number of different data sets for this contextual data. Here are a few of them along with a link that contains the most up to date list.

What else can I do with contextual awareness?

Let’s look at one more example. For this example, we will search for the use of administrative shares in Windows. Depending upon the organization, the use of these shares may be something that is monitored. We want to understand if these shares are being used and if so, by whom. In this case, we are particularly concerned about anyone with a title of Intern using them. Our search captures the syntax of the net use command that could be used to enable these shares and we can add to that the field that would identify a user as an intern. When we review our results, we can see additional contextual data like department and location. There are additional contextual fields that are automatically enriched in the UDM event that you can take advantage of both in searches and in rules.

metadata.event_type = "PROCESS_LAUNCH" AND target.process.command_line = /net.*use.*(c|admin|ipc)\$/ nocase AND principal.user.title = "intern" nocase

Ingesting entity data into Chronicle can help provide analysts with additional context around the events they are reviewing. I hope this was a helpful introduction to contextual awareness because in our next blog, we will apply these capabilities to rules!