Exclude identity resolution for devices or users
As Splunk UBA processes events, the Identity Resolution component (IDR) performs the following:
- Builds associations among IP addresses, MAC addresses, and host names based on login and logout events in Active Directory, VPN, DHCP, or DNS logs. When an IP address is found in an event, the IDR system examines the time of the event and tries to associate a host name with the IP address based on various correlations.
- Tracks which users have logged in to which devices. For example, if user John Smith logged in to a device at 1:00PM for 10 minutes, we can infer that events originating on that device during that time were initiated by John Smith. Splunk UBA can associate John Smith with these events in cases where the event log may not be able to identify the user, such as some firewall logs.
The IDR component in Splunk UBA maintains exclusion lists to improve the quality of these associations. For example, multi-user systems such as domain controllers, shared servers, and proxies must not be assigned to any specific user. These multi-user systems are included in an IDR exclusion list to prevent them from being associated with any specific users.
Another example is a server hosting multiple domain names that are different from the real host name of the server. The domains are assigned IP addresses using DHCP. In this case, a static IP address cannot be accurately assigned to each hosted domain name.
A scheduled job runs daily at 6:00 AM local time that analyzes the data sources listed in the following table to identify entities for IDR exclusion.
Comparing user whitelists and user IDR exclusion lists
User whitelists and user IDR exclusion lists both serve the purpose of preventing anomalies being generated against a user for legitimate purposes. Consider an Active Directory (AD) server in your environment:
- A penetration tester might log in to the server regularly to perform penetration testing against the server. In this case, we include this user on a whitelist because we want to associate the user with the device, but we do not want any anomalies raised.
- An IT admin might also login to the same server to perform routine admin tasks. In this case, we use a user IDR exclusion list to prevent this user from being associated with the device because the admin is not the owner of the device. However, the activity performed by the admin account (not the user) can be tracked by external alarm and endpoint models and may still raise anomalies.
IDR exclusion list usage examples
The following table provides examples of how IDR exclusion lists are used by Splunk UBA to improve the quality of device and user associations.
|Entity Type||Exclusion List Type||Entity Example||Action Example|
|User||Device||jsmith||John Smith logs in to many devices on a regular basis and is not the owner of those devices. Do not associate John Smith with events originating from any devices.|
|Device||User||acme-dc-01||The device |
|Device||DNS||10.23.150.30||The IP address |
The length of time that an entity remains on an exclusion list depends on whether the exclusion list was created by a user or by Splunk UBA:
- Entities added to an exclusion list by a user remain on the list until removed by a user.
- Entities added to an exclusion list by Splunk UBA remain on the list for 30 days from the timestamp of the entity being added or updated. For example, suppose a device was added to an exclusion list on May 1. On May 3, the same device is found again in some events and the timestamp on the exclusion list is updated to May 3. This device remains in the exclusion list for 30 days starting from May 3. After an entity has remained on an exclusion list for 30 days, it is removed from the exclusion list.
Create IDR exclusion lists in Splunk UBA
You can Create IDR exclusion lists for user and devices in Splunk UBA.
User permissions required for creating IDR exclusion lists
The following user permissions are required to Create IDR exclusion lists in Splunk UBA:
- View permissions for HR Data
- Edit permissions for IDR Exclusions.
See Manage user accounts and account roles in Splunk UBA for more information about roles and permissions in Splunk UBA.
PII masking and IDR exclusion lists
PII masking affects IDR exclusion lists in the following ways:
- All entity names will be masked if either User Name or Device Name is selected for PII masking. For example, if User Name is selected for PII masking, then both user names and device names will be PII masked. See Mask personally-identifiable information in Splunk UBA for more information about masking PII in Splunk UBA.
- When PII masking is enabled in Splunk UBA, IDR exclusion lists cannot be edited by any user even if neither User Name nor Device Name are selected as PII masking fields.
Create a user IDR exclusion list
Perform the following tasks to create a user IDR exclusion list. The specified user will not be assigned to any events originating from any devices.
- In Splunk UBA, select Manage > IDR Exclusion List.
- Make sure the User tab is selected on the left side of the screen.
- Click New Entity.
- Provide a valid login ID for the user. View your HR data for valid login IDs.
- Verify that the User is the desired entity. This is automatically populated by Splunk UBA when a valid login ID is provided.
- Use the Notes field to enter any specific notes about why this user is being included on this exclusion list.
- Click OK.
User exclusion lists are applied per user, not per HR account (login ID). For example, user John Smith may have a normal account called
user_jsmith, and an admin account called
adm_jsmith. When adding John Smith to the user IDR exclusion list, if you specify
adm_jsmith as the login ID then John Smith appears as the user. John Smith is not associated with any device events regardless if the events involved his normal account
user_jsmith or his admin account
Create a device IDR exclusion list
Perform the following tasks to create a device IDR exclusion list.
- In Splunk UBA, select Manage > IDR Exclusion List.
- Select the Devices tab is selected on the left side of the screen.
- Click New Entity.
- Select an exclusion type. See IDR exclusion list usage examples for more information about the exclusion types.
- Specify the device to be excluded.
- If you selected User as the exclusion type, provide a valid IP address, MAC address, or host name. Users will not be associated with this device.
- If you selected DNS as the exclusion type, provide a valid IP address or MAC address. Hostnames will not be associated with the specified IP address or MAC address.
- Use the Notes field to enter any specific notes about why this device is being included on this exclusion list.
- Click OK.
View IDR exclusion lists in Splunk UBA
Select Manage > IDR Exclusion List to view the exclusion lists defined on your system.
The Created By column can have the values listed below. A red star indicates that the entity was added to the exclusion list by Splunk UBA.
|User||Manually aded by a user||The entity was manually added to the exclusion list in Splunk UBA. View the audit logs to determine the specific user who added the entity. See Audit user activity in Splunk UBA.|
|Identity resolution data||Data from the previous 7 days is analyzed to identify multi-user systems and admin users frequently logging on multiple machines. Also, data from last 24 hours is analyzed to find occurrences of more than 2 device mappings per hour for more than 6 hours. You can configure these thresholds by configuring the following properties in |
After setting the properties, synchronize the cluster and restart the data sources.
|Splunk UBA model output||The device profiler model in Splunk UBA identifies domain controllers and proxy servers through machine learning. Splunk UBA uses the output of the model to create device exclusion lists.|
|Splunk UBA assets data||When asset data is imported, you can configure the |
Identify assets in your environment
Use allow and deny lists to generate or suppress anomalies
This documentation applies to the following versions of Splunk® User Behavior Analytics: 5.0.0, 5.0.1, 5.0.2, 5.0.3, 5.0.4, 220.127.116.11, 5.0.5, 18.104.22.168
Feedback submitted, thanks!