Asset & Identity for Splunk Enterprise Security - Part 1: Contextualizing Systems

Dear Buttercup, 

My SOC analysts are frustrated. They are looking at events but don’t have any idea of the context of the systems referenced. Sure, they have a device with the name SW-MX-F1-d2100-DL585 but they can’t tell if it is PCI Compliant or where it is located. They aren’t certain what to prioritize and are always looking at spreadsheets to learn more. To make matters worse, we have multiple lists of systems from different groups in our organization. They are looking to me for answers! Heaven knows I’m miserable now. Can you help?

Morosely,
Steven M.

Thank you for your note, Steven! I feel like we have heard from you before, but perhaps I am mistaken. No matter.

One of the key values that a SIEM must provide is the ability to take events as they occur and correlate them with systems in an organization. This is critical to allow analysts to nimbly understand more than just the event they have but the system the event is occuring on.

The contextualizing of devices, or assets, as we refer to them at Splunk, is quite important to better understand the output of your SIEM. If an analyst can look at a notable event and understand where an asset is located, who it is owned by, the data classification the system holds within a specific audit boundary, and so on, these contextual clues can help speed decision making. Taking this an additional step forward, having this contextualization can also allow an organization to build correlation searches that are specific to certain assets.

One of the five frameworks that Splunk built into its Enterprise Security (ES) platform is the Asset & Identity framework. Its goal is to contextualize systems and user accounts and associate them with the events that Splunk is collecting and indexing. In the example below, the host titan.thirstyberner.com is located in San Francisco, is categorized as an Active Directory and Windows system, it part of the IT business unit and has an IP address of 10.1.1.10. The framework is pulling these supporting pieces of information for every system (asset) and user account (identity) that have information for when an analyst reviews events.

You may be wondering where the asset and identity data come from, dear reader. It can come from any number of places including a CMDB, but also Active Directory, LDAP and many more data sources. Splunk ES can generate a lookup that will store this information. These data sources can then be polled on a regular basis to get updated information. The following fields are available to map asset data. Identities have a slightly different set of fields associated with it. 

Steven, you mentioned that you have multiple lists of assets in your organization. Have no fear, it is possible to have multiple lookup tables for assets and identities and Enterprise Security will automatically merge them. This can be quite handy if you are collecting from different sources or different parts of an organization. However, it is important to understand that on occasion, the same asset might be in multiple lookups. When I say the same asset, I am referring to a device with one of the four key fields; ip, dns, mac or nt_host having the same value in multiple lists.

For example, 10.1.4.99 is in two distinct lists. For ease of viewing I pulled them together in a single search here:

One list has the mac (MAC Address) field populated, the other has the dns field populated with a fully qualified domain name, however, the devices are categorized differently and their priorities are different. Obviously, there are more fields, but you get the idea. Because it is not uncommon for an asset to exist in multiple lists, Enterprise Security has a mechanism built into it to merge values and choose a single value for certain fields by ensuring that one list takes precedence over another. That mechanism is to apply a rank to each list. Some fields, such as category, will merge the values together. However, other fields, like priority, must be a single value. The Asset and Identity Management configuration screen has been revised in version 6.0 and can be found by navigating to Configure -> Data Enrichment -> Asset and Identity and on the far left of the screen you can see which lists are ranked in order or precedence.

The merging of asset and identity data is facilitated by a set of searches that run automatically at an administrator-defined time interval. There are two lookups created for assets, asset_lookup_by_str, and asset_lookup_by_cidr. asset_lookup_by_str is for individual assets and their specific attributes. asset_lookup_by_cidr represents CIDR blocks of addresses and their attributes. After this merging of assets occurs, all of our assets are available to us in a single view called the Asset Center. Alternatively, running the search | `assets` or searching the Identity Management data model will return all of the assets as well. A unique key exists for each asset and the assets macro will return that value as well.

Below is our Asset Center dashboard where we can see that the mac and dns have merged into a single asset record, the categories have merged in the multi-select field of category and the value for priority in our lookup frothly_assets_2019 has taken precedence over Thirsty Berner ICS Assets, due to its ranking.

One final item I will leave you with is that there are a series of automatic lookups that return asset and identity attributes at search time. They are comparing fields like src, dest, and dvc and if a match occurs at search time they are returning the additional attributes. That is how we were able to get Destination Category and Destination City in the first image I showed you! Below is an example directly from a search of Microsoft Sysmon.

Here is the full Sysmon event, but notice those asset attributes being returned, only this time, they are called src_category and src_priority because this time the asset is represented in the source (src) field. There is nothing required of you to make this occur, so with each search you get these attributes automatically for context! I mention this now because we can take advantage of this immediately in our searches, but is used extensively throughout the asset and identity framework.

Steven, I hope that this introduction into working with assets in Splunk Enterprise Security has given you a solid foundation to work from. 

Until next time,
Buttercup

----------------------------------------------------
Thanks!
John Stoner