Asset and Identity correlation

To effectively detect security intrusions, an organization must be able to correlate events in log data with specific assets and identities that may be responsible for, or affected by the intrusion. Splunk Enterprise Security compares indexed events with the data in the asset and identity correlation system to provide data enrichment and context.

Asset correlation

An asset represents any device or system in the environment that generates data. Asset correlation allows indexed events to be matched against a defined list of assets. When a match occurs, the original indexed event gains new fields through association with the asset, enriching the event with information on the asset's priority, location, or other details.

Performing asset correlation with Enterprise Security provides:

• Categorization: allows information about assets to be added to events.
• Prioritization: allows an urgency to be computed based on the assigned priority of an asset.
• Normalization: assists in determining whether multiple events can relate to the same device.

How assets are identified

Enterprise Security performs an asset correlation whenever an event returned by a search contains data in any one of the src, dest, host, orig_host, or dvc fields.

1. The data in the field is evaluated against the merged asset lists for a match as an IP address, a MAC address, a DNS name, or a Windows NetBIOS name.
2. Only one asset or identity match will be returned. Furthermore, for assets, a single IP address match is always preferred over a CIDR subnet match. Overlap between asset or identity entries in any of the key fields will result in indeterministic matching behavior.
3. The fields in the asset list are added to the indexed event as additional fields.
4. The asset fields offer "Event actions," allowing a user to open additional searches or dashboards scoped to the specific asset.

Adding assets to Enterprise Security

Collection and addition of asset information to Enterprise Security supports correlation searches, search tasks, and other features attempting to correlate indexed events with known network devices.

In a highly regulated network environment, one database or repository might be the only source of information for both assets and identities. However, it is more common to find them spread among many unique repositories, hosted on different technologies, and maintained by several departments. For a list of suggested asset sources, see Collection methods for assets and identities in this manual.

After you collect asset information, format the resulting list of assets according to the guidance in the Asset lookup fields topic in this manual. Once formatted, place the list in $SPLUNK_HOME/etc/apps/SA-IdentityManagement/lookups. To configure the list for collection and processing, see the topic on Identity Management in this manual.

Asset lookup details

An asset lookup file has predefined fields. An asset record is required to have an entry in the ip, mac, nt_host, or dns fields. Only fields that accept pipe-delimited lists can define more than one value. If a custom field is added to the lookup file, the field and its contents are discarded. The first line of the lookup file is a column header, and must list all of the fields.

The fields ip, mac, nt_host, and dns accept multiple values in a pipe-delimited format. Only one field should be loaded with multiple values for an asset record. This allows multi-homed hosts or a node with multiple hostnames to use a single asset record. Example: if you are using pipe-delimiting in the ip field to track an asset's IP addresses, the mac, nt_host, and dns fields for the record should contain only one value.

Asset lookup header

ip,mac,nt_host,dns,owner,priority,lat,long,city,country,bunit,category,pci_domain,is_expected,should_timesync,should_update,requires_av

Asset lookup fields

Field	Data type	Description	Example
ip	pipe-delimited numbers	A pipe-delimited list of single IP address or IP ranges. An asset is required to have an entry in the ip, mac, nt_host, or dns fields. Do not use pipe-delimiting for more then one key field per record.	2.0.0.0/8, 1.2.3.4, 192.168.15.9-192.169.15.27, 5.6.7.8|10.11.12.13
mac	pipe-delimited strings	A pipe-delimited list of MAC address. An asset is required to have an entry in the ip, mac, nt_host, or dns fields. Do not use pipe-delimiting for more then one key field per record.	00:25:bc:42:f4:60, 00:50:ef:84:f1:21|00:50:ef:84:f1:20
nt_host	pipe-delimited strings	A pipe-delimited list of Windows machine names. An asset is required to have an entry in the ip, mac, nt_host, or dns fields. Do not use pipe-delimiting for more then one key field per record.	ACME-0005, SSPROCKETS-0102|COSWCOGS-013
dns	pipe-delimited strings	A pipe-delimited list of DNS names. An asset is required to have an entry in the ip, mac, nt_host, or dns fields. Do not use pipe-delimiting for more then one key field per record.	acme-0005.corp1.acmetech.org, SSPROCKETS-0102.spsp.com|COSWCOGS-013.cwcogs.com
owner	string	The user or department associated with the device	f.prefect@acmetech.org, DevOps, Bill
priority	string	The priority assigned to the device for calculating the Urgency field for notable events. An "unknown" priority reduces the assigned Urgency by default. For more information, see Notable Event Urgency assignment in this manual.	unknown, low, medium, high or critical.
lat	string	The latitude of the asset	41.040855
long	string	The longitude of the asset	28.986183
city	string	The city in which the asset is located	Chicago
country	string	The country in which the asset is located	USA
bunit	string	The business unit of the asset	EMEA, NorCal
category	pipe-delimited strings	A pipe-delimited list of logical classifications for an asset. See Categories in this manual.	server | web_farm | cloud
pci_domain	pipe-delimited strings	A pipe-delimited list of PCI domains.See Configure assets in the Splunk App for PCI Compliance Installation and Configuration Manual.	trust, trust|wireless, trust|cardholder, trust|dmz, untrust If left blank, defaults to untrust.
is_expected	boolean	Indicates whether events from this asset should always be expected. If set to true, an alert will be triggered when this asset stops reporting events.	"true", or blank to indicate "false"
should_timesync	boolean	Indicates whether this asset must be monitored for time-sync events. It set to true, an alert will be triggered if this asset does not report any time-sync events from the past 24 hours.	"true", or blank to indicate "false"
should_update	boolean	Indicates whether this asset must be monitored for system update events.	"true", or blank to indicate "false"
requires_av	boolean	Indicates whether this asset must have anti-virus software installed.	"true", or blank to indicate "false"

Identity correlation

An identity represents a user, credential, or a role used to grant access to a device or system. Identity correlation allows indexed events to be matched against a defined list of users or system accounts. When a match occurs, the original indexed event gains new fields through association with an identity, enriching the event with information on the identity's priority, role, or the functional area to which it belongs.

Performing identity correlation with Enterprise Security provides:

• Categorization: allows information about an individual or account to be added to events.
• Prioritization: allows an urgency to be computed based on the assigned priority of an individual or account.
• Normalization: assists in determining whether multiple events can relate to the same individual or account.

How identities are identified

Enterprise Security automatically performs an identity correlation whenever an event contains data in either the user, or src_user fields.

1. The data in the field is evaluated against the merged lists of identities for a user or session match.
2. After the first match is found, any additional matches are ignored.
3. The fields in the identity list are added to the event as additional fields.
4. The added identity fields provide "field actions," allowing a user to open additional searches or dashboards scoped to the specific identity.

Adding identities to Enterprise Security

Collection and addition of identity information to Enterprise Security supports correlation searches, search tasks, and other features attempting to correlate indexed events with users or accounts.

In a highly regulated network environment, one database or repository might be the only source of information for both assets and identities. However, it is more common to find them spread among many unique repositories, hosted on different technologies, and maintained by several departments. For a list of suggested identities sources, see Collection methods for assets and identities in this manual.

After you collect information on identities, format the resulting list according to the guidance in the Identity lookup fields topic in this manual. Once formatted, place the list in $SPLUNK_HOME/etc/apps/SA-IdentityManagement/lookups. To configure the list for collection and processing, see the topic Identity Management in this manual.

Identity lookup details

An identity lookup file has predefined fields. Only the Identity field is required. All fields accept string values unless noted. Only fields that accept pipe-delimited lists can define more than one value. If a custom field is added to the lookup file, the field and contents are discarded. The first line of the lookup file is a column header, and must list all of the fields.

Identity lookup header

identity,prefix,nick,first,last,suffix,email,phone,phone2,managedBy,priority,bunit,category,watchlist,startDate,endDate,work_city,work_country,work_lat,work_long

Identity lookup fields

Field	Data type	Description	Example
identity	pipe-delimited strings	Required. A pipe-delimited list of username strings representing the identity. For more information on conditional matching for this field, see Manage Identity matching using identityLookup.conf in this topic.	VanHelsing | a.vanhelsing | abraham.vanhelsing | a.vanhelsing@acmetech.org | abraham.vanhelsing@acmetech.org
prefix	string	Prefix of the identity.	M.D., Ph.D
nick	string	Nickname of an identity.	Van Helsing
first	string	First name of an identity.	Abraham
last	string	Last name of an identity.	Van Helsing
suffix	string	Suffix of the identity.
email	string	Email address of an identity.	a.vanhelsing@acmetech.org
phone	string	A telephone number of an identity.	123-456-7890
phone2	string	A secondary telephone number of an identity.	012-345-6789
managedBy	string	A username representing the manager of an identity.	phb@acmetech.org
priority	string	The assigned priority of an identity.	unknown, low, medium, high or critical.
bunit	string	A group or department classification for identities.	Field Reps, EMEA, APAC
category	pipe-delimited strings	A pipe-delimited list of logical classifications for identities. See Categories in this manual.	Privileged | Officer | CISO
watchlist	boolean	Marks the identity for activity monitoring.	Accepted values: "true" or empty. See User Activity Monitoring in this manual.
startDate	string	The start or hire date of an identity.	Formats: %m/%d/%Y %H:%M, %m/%d/%y %H:%M, %s
endDate	string	The end or termination date of an identity.	Formats: %m/%d/%Y %H:%M, %m/%d/%y %H:%M, %s
work_city	string	The primary work site City for an identity.
work_country	string	The primary work site Country for an identity.
work_lat	string	The latitude of primary work site City in DD with compass direction.	37.78N
work_long	string	The longitude of primary work site City in DD with compass direction.	122.41W

Manage Identity matching using identityLookup.conf

Use the identityLookup.conf to configure additional options for the identity list matching, such as allowing partial matches and setting a preference for order when matches are performed.

The Identity field is capable of storing multiple pipe-delimited strings for use while matching. When importing data from a source such as LDAP, an identity record is created from the login name and email address fields. Those fields can be used for conditional matching, and rearranged into other unique combinations to allow identity matching by changing the settings in identityLookup.conf. The additional results are stored in the Identity field of the identities_expanded lookup.

For a description of the options, review the SA-IdentityManagement/README/identityLookup.conf.spec
For an example, see the SA-IdentityManagement/README/identityLookup.conf.example