Why Splunk UBA requires HR data

Add human resources (HR) data, such as employee details and their account information, from Active Directory or other HR systems to Splunk UBA. HR data must be loaded before any other data is loaded into Splunk UBA.

Splunk UBA uses HR data to do the following with other data loaded into Splunk UBA:

• Categorize accounts by type. Splunk UBA defines the normal, admin, service, and system account types by default. These account types are used by the various threat models in Splunk UBA to generate threats and anomalies. You can define additional account types as needed.
• Identify human users (employees) for the accounts found in the attributes of log records, such as loginId or email.
• Associate multiple accounts of a user to a single human user using a unique ID, such as an employee ID. For example, user John Smith might have a normal account called jsmith, and an admin account called adm_jsmith. Splunk UBA normalizes these separate accounts to a single unique ID jsmith which belongs to John Smith. All events generated by these two accounts are analyzed under a single user for anomaly detection.

Understand HR data resolution

When performing HR data resolution, Splunk UBA takes following steps to identify the human user for any account found in log events:

1. The account name is extracted from an event. The account name can be in a variety of formats, including Jsmith, acme\jsmith, acme\\jsmith, acme/jsmith, jsmith\acme, jsmith@acme, acme\jsmith@acmesecured, or jsmith@acme.com.
   In this example, we will use jsmith@acme.com as the account name found in the log event.
2. The full account name jsmith@acme.com is searched against the HR data. If there is no match, the account name is normalized by removing the domain information and performing another search against the HR data. In this example, the @acme.com portion of the account name is removed and jsmith is searched against the HR data.
   • If the search for either jsmith@acme.com or jsmith returns a match, the account name is replaced with the name of the human user, such as John Smith.
   • If a human user is not found, the account name becomes an unknown user in Splunk UBA. By default, Splunk UBA drops all events associated with unknown users.
   If your HR data contains the domain+loginId field, Splunk UBA can use an account name such as acme\jsmith to locate a human user when performing HR resolution.

The following example shows how HR data and HR data resolution are used by Splunk UBA to identify a data exfiltration use case. Suppose John Smith has been an employee at his present company for 10 years. He has multiple admin accounts created over those years. Using his multiple admin accounts, he performs the following tasks:

1. Uses his jsmith_admin account to access a development server and download data to his laptop.
2. Uses his adm_jsmith1 account to access a sales server and download data to his laptop.
3. Uses his jsmith_a33 account to access a cloud server and download data to his laptop.
4. Downloads all of the data he has obtained from his laptop onto a portable USB drive.

Without proper HR data configuration, this data exfiltration scenario is missed as individually each of John Smith's actions do not raise any anomalies in Splunk UBA. However, with proper HR data configuration linking John Smith to each of his admin accounts, Splunk UBA can stitch together this series of behaviors and raise the proper anomalies and threats.

HR data resolution using a configured domains list

Account name normalization can also be configured by defining the company's internal domains. See Define the AD domains in use for devices.

When you define any internal domains, Splunk UBA only normalizes account names with domains matching the configured domains list. For example, if a domains list contains the following domains:

• domain1
• domain2

The account jsmith@acme.com will not be normalized since acme.com is not one of the configured internal domains. The jsmith@acme.com account becomes an unknown user and all events for that account are dropped.

If an account such as domain1\jsmith is found in a log event, it is normalized to jsmith when Splunk UBA performs HR data resolution.

Resolving active or inactive users

Some organizations allow an email address to be reused when a new employee joins the company and that employee has the same name as a previous employee. For example, John Smith might be assigned the email address jsmith@acme.com, which is the same email as a John Smith who worked at the company previously and who has already been terminated.

IT departments usually create unique account names or login IDs for each employee. In this case, the terminated John Smith might have the account name jsmith and the current John Smith might have the account name jsmith1. When Splunk UBA finds jsmith@acme.com in a log event, it is not possible to immediately identify whether this email address is for the terminated John Smith or the active John Smith. However, Splunk UBA can use the account status and termination date in the HR data to identify that this email address belongs to the active John Smith with the account name jsmith1.