Monitor policy violations with custom threats

Create custom threats to identify verifiable threats in your network, like specific activities that you want to monitor for policy compliance. Create, edit, enable, and manage the custom threats that are most useful for your organization. You can create custom threats that apply to users or devices. Several custom threats are included with Splunk UBA.

Custom threat rules generate threats based on a set of conditions that you specify. You can specify the pattern and characteristics of anomalies that comprise a threat. Custom threat rules run on a daily basis. Each threat contains one participant, whether a user, device, or application, so the rules engine searches for patterns by participant. If three separate participants generate three anomalies that meet the conditions for a threat, the rules engine does not create a threat.

Custom threats included with Splunk UBA

Several custom threats are included with Splunk UBA. Choose whether to enable or disable them and change settings as needed for your environment. Custom threat rules are enabled by default. Edit the threat to review the default parameters.

Custom threat name	Custom threat type	Description
Brute Force	Compromised Account	This rule looks for repeated login failures followed by suspicious behavior.
Compromised Account	Compromised Account	This rule looks for suspicious logins followed by malicious behavior.
Compromised Web Server	Compromised Web Server	This rule monitors web servers for unauthorized access and activity.
Data Exfiltration after Account Takeover, High	Data Exfiltration after Account Takeover	This rule generates a high confidence threat after analyzing data exfiltration following an account takeover.
Data Exfiltration after Account Takeover, Medium	Data Exfiltration after Account Takeover	This rule generates a medium confidence threat after analyzing data exfiltration following an account takeover.
Data Exfiltration after Data Staging	Suspicious Data Collection	This rule looks for data exfiltration following data staging.
Infected Host	Malware	This rule looks for potential infection followed by suspicious activity.
Malicious URI Communications with Potential Malware	Malware	This rule looks for communication attempts to URIs categorized as Malicious by URI filtering followed by other indicators of compromise.
Multiple failed badge attempts and unusual badge access time	Suspicious Badge Activity	This rule detects users that attempted access into multiple or unusual entry locations at unusual times.
Potential Flight Risk Exfiltration	Exfiltration	This rule looks for potential flight risk users who may be exfiltrating sensitive data.
Potential Flight Risk Staging	Suspicious Data Collection	This rule looks for potential flight risk users who may be staging sensitive data.
Potential Phishing Attack	Possible Phishing Attack	This rule looks for a possible phishing email followed by compromised account behavior, exploit attempts, or connections to malicious IP/Domains.
Privilege Escalation after Powershell Activity	Privilege Escalation after Powershell Activity	This rule detects devices with suspicious Powershell activity followed by privilege escalation.
Suspicious Domain Communication followed by Malware Activity	Malware	This rule detects suspicious communication followed by possible malware activity.
Suspicious HTTP Redirects followed by Suspected Infection	Malware	This rule detects HTTP redirects followed by suspicious activity.
Suspicious URI Communications and Redirects	Malware	This rule detects communication attempts to URIs categorized as suspicious by URI filtering, followed by suspicious activity.
Watering Hole Infection	Malware	This rule detects Watering Hole patterns along with signs of malware infection.

Create a custom threat with a threat rule

In addition to using the custom threats included in Splunk UBA, admins can also create their own custom threats by creating threat rules. Those threat rules create threats for analysts to investigate.

1. Select Explore > Threats and click the Custom Threats icon.
2. Click New Threat Rule to open the threat rule creation wizard.
3. Select a participant for the threat. Click User or Device.
   For example, click User to create a threat based on user activities.
4. Click Next.
5. Select the user filters that make up the threat.
   For example, select an Anomalies Count of >= to 3 and a User Watchlist of Privileged Users.
6. Click Next.
7. Choose the threat conditions for this custom threat.
   1. From the drop-down menu, choose anomaly types that make up this threat.
      For example, select a type of Denied Domain to monitor the web browsing activities of the privileged users you selected in the previous step. Click the filter icon next to Denied Domain to rely on a specific filter or confidence level for the excluded domain anomalies.
   2. Type a count of anomaly types.
      For example, type 2 to see excluded domain activity as a threat only when it is repeated.
      Multiple anomalies added to a single condition are evaluated with an implied OR. The condition is satisfied if any filters, categories, or anomaly counts are met. If you need two anomalies and have both Denied Domain and Denied IP in the condition, you can satisfy the condition with two Denied Domains or one of each.
   3. Click Add Condition to select another anomaly type or anomaly filter.
      For example, click the filter icon to choose other anomaly filters such as anomaly categories, watchlists, scores, or devices, apps, and domains. Select an anomaly category of Infection and a Score of Major to identify excluded domain site visits followed by a possible malware infection.
      Multiple conditions have an AND relationship. If you add three conditions, all three must be met in order for the threat rule to be triggered.
      

      If you choose anomaly categories in addition to anomaly types in the same condition, and the categories are not associated with the selected anomaly types, your custom threat rule will not generate any threats.

   4. Click Preserve Order to create a threat based on a specific pattern of anomalous behavior over time.
      In this example, select Preserve Order to create a threat only when an excluded domain is visited before a possible infection is identified. Preserve Order only matters when comparing conditions, and requires one condition to be met before the next is evaluated.
8. Type time periods to control how often and when the threat rule creates a custom threat.
   1. Type an Anomalies Interval to limit the custom threat to anomalies occurring in a specific period of time.
      For example, if you only want to see a threat for users visiting excluded domains followed by infections if all the anomalous behavior happens in the same 24 hour period, type 24 hours for the anomalies interval.
   2. Type a Max Threat Duration to specify the maximum amount of time that you want the threat to cover. After a threat is created, anomalies can be added to it if they occur in the time period specified in this threat duration period. If you want to see more threats for matching behavior patterns, set a short max threat duration or match the max threat duration to the anomalies interval. If you want to collect evidence and see fewer threats in the system, set a longer max threat duration to capture many anomaly patterns in the same threat.
      For example, type a max threat duration of 4 days to create a threat the first time the excluded domain and infection pattern is identified in user behavior and update it with additional anomalies and activity over an 4 day period. If the anomaly pattern appears again after the 4 day period is over, a new threat is created.
   3. Type a Threats Gap to specify the minimum time interval between two threats. You can set either a max threat duration or a threat gap, or both. If you set both, the threat duration takes precedence over the threat gap.
      For example, choose not to type a threat gap for this custom threat.
9. Click Next.
10. Choose to process anomalies from this day forward or process anomalies in the past, or both. If you select Process anomalies in the past, define the time period in the past to process anomalies, or a date range to cover.
11. Click Next.
12. Select a Threat Score.
    For example, a score of 6 to indicate a medium threat of an excluded domain visit followed by an infection.
13. Choose a Custom Threat Type. You can use an existing threat type or create a new one.
    For example, select an existing custom threat type of Malware.
14. Type a Threat Description and Threat Recommendation for this custom threat.
    For example, a Threat Description of "Privileged user potentially infected by malware from an excluded domain." and a Threat Recommendation of "Suspend the account or place it on a watchlist."
15. Click Next.
16. Type a Rule Name and Rule Description.
    For example, type a Rule Name of "Monitor privileged user activity with excluded domains" and a Rule Description of "Identify privileged users that visit excluded domains and are then infected by malware."
17. Click OK to save the threat rule.

After you create a custom threat, you can disable it, delete it, or edit it on the Custom Threats page. When you disable or delete a threat, you can select the checkbox In addition delete the threats previously generated by this rule to delete all threats that were created by this custom threat rule.

Custom threats are added to the /etc/caspida/local/conf/rules directory so that they are not affected when you upgrade Splunk UBA.

Time intervals and threat rule processing

Different parameters of a custom threat influence whether or not a threat is created by the rules engine. See the following table for details:

Parameter	Description
Anomalies interval period	Set by you when you create a custom threat. Any interval of time. Defines the maximum span of time for a pattern of anomalies to create a threat. If the pattern of anomalies is identified but over a span of time greater than this interval period, a threat is not created.
Max threat duration	Can span several days. All anomalies that might create a threat are associated to the same threat until the max threat duration period ends.
Threat gap	The gap in time between the last anomaly associated with the custom threat and the newly detected anomaly or anomalies for the same entity.
Rules engine lookback period	Defined by the rules engine and affected by the processing period that you select. The amount of time over which the rules engine looks for patterns that occur in a time frame no greater than the anomaly pattern interval period. The rules engine runs every day at 3 a.m. If you select a date range or time period, the lookback period is equivalent to that date range or period of time. If you choose to process anomalies from this day forward, the lookback period is 24 hours by default, or equal to the interval period if the interval is greater than 24 hours. The lookback period ends at 23:59:59 of the day before the rules engine run. For example, if the rules engine runs at 3 a.m. on Tuesday, the lookback period ends at 23:59:59 on Monday.

First example

At 3 p.m. Tuesday, you set up a custom threat that expects three anomalies with specific characteristics to occur in a 6 hour interval, processing anomalies from this day forward. You set a max threat duration of two days and do not set a threat gap.

At 3 a.m. Wednesday the rules engine looks for the parameters you specified.

• One anomaly for user A was identified at 1 p.m. on Tuesday.
• A second anomaly for user A was identified at 4 p.m. on Tuesday.
• A third anomaly for user A was identified at 5:30 p.m. on Tuesday.

The rules engine creates a threat for user A.

On Wednesday, a fourth anomaly for user A was identified at 10 a.m. and a fifth anomaly at 2:30 p.m. The rules engine does not create a new threat. The two new anomalies for user A are added to the original threat.

Second example

At 3 p.m. Tuesday, you set up a custom threat that expects three anomalies to occur in a 6 hour interval, processing anomalies from this day forward.

At 3 a.m. Wednesday the rules engine looks for the parameters you specified.

• One anomaly for user B was identified at 4 p.m. Tuesday.
• A second anomaly for user B was identified at 5 p.m. Tuesday.
• A third anomaly for user B was identified at 7 p.m. Tuesday.
• A fourth anomaly for user B was identified at 9 p.m. Tuesday.

The rules engine creates a threat for user B that includes all four anomalies.

Third example

At 3 p.m. Tuesday, you set up a custom threat that expects two or more anomalies to occur in a 48 hour interval, processing anomalies from this day forward.

At 3 a.m. Wednesday the rules engine looks for the parameters you specified.

• One anomaly for user C was identified at 12 a.m. Monday.
• A second anomaly for user C was identified at 12 p.m. Monday.
• A third anomaly for user C was identified at 7 p.m. Monday.
• A fourth anomaly for user C was identified at 3 p.m. Tuesday.
• A fifth anomaly for user C was identified at 11:59 p.m. Tuesday.

The rules engine creates a threat for user C.