Cool things you can do with Assets and Identities

Background

It’s important to have visibility into the overall security posture across an environment, but logs from different vendors and technologies can be challenging to correlate. Typically distinct log sources provide different information. For example, a firewall log may contain IP addresses, while a Windows Event Log may contain only hostnames. To build a wholistic picture of security it’s important to glue these data sources together.

This is the key to the Assets and Identities framework, and why it’s the heart of a Splunk Enterprise Security deployment. This post is a brainstorming of use cases (obvious and less obvious) for these two tables, that hopefully provides motivation to get this data organized.

Ideas

IP and DNS/Hostname correlation for all logs

Most logs will only contain either an IP address or hostname. Logs that only provide an IP address (especially network appliance logs) are much less informative unless the analyst knows what IPs belong to what hosts.

Asset enrichment makes these logs immediately more meaningful for ad-hoc searches. More importantly, disparate logs are tied into particular hosts, meaning that for each host, an analyst can dig into what’s happening across all aspects of activity (network, process, file system, configuration, and authentication).

Prioritize hosts and people so that notables get the attention they deserve

The priority column is arguably the most important in the assets table. This column allows Splunk to assign a severity from a notable involving that asset or identity. The priorities of assets and identities involved are averaged with a “severity” that is optionally calculated within the SPL of a search to determine an overall severity for the notable. Careful attention to priorities of assets and identities will significantly improve the accuracy of notables’ severities.

Enrich notables with information about device owners

ES allows for a host of Assets and Identities context to be added to each notable event. Most of this information will be available when the notable is expanded in the Incident Review page. Additionally, more informaiton is available within the Assets Investigator, which essentially functions as a drilldown. For example, an analyst could quickly find the phone number for a user involved in a notable by clicking on the “Asset Investigator” workflow action for that notable.

Easily filter categories of devices from alerts

A common issue when it comes time to write alerts is that many devices may be irrelevant to particular alerts. On the other hand, it’s often impractical to whitelist these devices by IP or hostname within the searches themselves.

An example of this issue is a search that looks for scanning activity on the network. A search that looks for this kind of traffic may alert on security devices that are designed to scan, and are trusted.

These devices can be quickly whitelisted in searches if they are categorized in the assets table. A trusted device that is meant to scan can be categorized as “known_scanner,” and any searches where these hosts should be whitelisted can filter out this category. These can may be surprisingly performant, as the Assets and Identities fields are accelerated in the most of the CIM data models.

Track security issues by department or subsidiary

The “bunit” and “cim_entity_zone” columns, as well as “category,” can be used for tracking after the fact. cim_entity_zone iss brand new in ES 6.4.0, and it is probably best-suited to label data from subsidiaries or regions. All of these fields are availbable in the notable index.

Depending on how these fields are used, reporting on security by department, subsidiary, or region could be useful for tracking where in a company attention is needed.