As the depth and breadth of the use cases in QRadar have grown, so has the frequency of the questions I hear from clients about maturing their insider threat program with UBA. The ones I hear consistently are “How do we grow our UBA deployment?” or “How often should I check for new log sources and use cases in the UBA app?”
In this and the next couple of blogs in this series, I’ll address and answer these questions for our UBA clients.
Let’s begin with the basics on how to initiate, grow and mature a UBA deployment. I recommend clients take a staged approach to growth, with the objective to create insights into both known and unknown threats facing the enterprise.
UBA is designed to help organizations detect distinct behaviors of interest in the company. When it comes to security, SOC analysts need to think not only about the human users, but also about their myriad of accounts — service or machine accounts, how they are used, what are they accessing or where are they connecting from etc.
With 160+ different behaviors that UBA can detect, it can get a bit overwhelming to understand exactly where to start. In my experience, it’s best to start with the use cases that help detect account behaviors including their access patterns, authentication patters and login behaviors.
The deviation from the normal login geography or login at unusual times may indicate a malicious user trying to gain access to your network and data. For example, a user attempting to login from North Korea may indicate someone in possession of stolen credentials. Similarly, someone using a suspended account may indicate an insider trying to access data that he has lost access to.
Each of these abnormal behaviors result in the UBA app assigning an elevated risk score to the user account. When the combined risk score of a user goes above a threshold or deviates more than 1 standard deviation of his/her risk posture, the UBA app identifies that user account as a high-risk user. The SOC analyst can quickly review the anomalous activity of that user and either escalate the user for further investigation or mark them as investigated and close the alert.
User account behavior related use cases
Clients of UBA should start their UBA deployment with use cases that monitor the activity of a user account to identify abnormal use, abuse or non-use (dormant) accounts. The data sources needed for these use cases are readily available in most QRadar deployments, enabling SOC analysts to deploy these use cases quickly.
|
UBA : User Account Created and Deleted in a Short Period of Time
|
Detects when a user account is created and deleted in a short period of time.
|
|
UBA : Dormant Account Used
|
Detects and reports functions to indicate that a user successfully logged in after a dormant period. How quickly the rule is triggered after the user goes dormant is governed by the time-to-live setting in "UBA : User Accounts, Successful, Recent".
|
|
UBA : Dormant Account Use Attempted
|
Detects the failed log in attempt from an account that has been determined to be dormant.
|
|
UBA : Expired Account Used
|
Indicates that a user attempted to log in to a disabled or an expired account on a local system. This rule might also suggest that an account was compromised.
|
|
UBA : First Privilege Escalation
|
Indicates that a user executed privileged access for the first time. This reporting rule can be disabled to allow the tracking of user behaviors for baselining purposes.
|
|
UBA : New Account Use Detected
|
Detects and reports functions that indicate a user successfully logged in for the first time. This reporting rule can be disabled temporarily for baselining purposes.
|
|
UBA : Suspicious Privileged Activity (First Observed Privilege Use)
|
Indicates that a user executed a privileged action that the user never executed before. Observations are kept in "UBA : Observed Activities by Low Level Category and Username" map-of-sets.
|
|
UBA : Suspicious Privileged Activity (Rarely Used Privilege)
|
Indicates that a user executed a privileged action that the user has not executed recently. Observations are kept in "UBA : Recent Activities by Low Level Category and Username" map-of-sets. The sensitivity of this event can be modified by changing the TTL (time-to-live) of the Reference Map-of-Sets for "UBA : Recent Activities by Low Level Category and Username". Increasing the TTL reduces the sensitivity. Decreasing the TTL increases the sensitivity.
|
|
UBA : User Attempt to Use a Suspended Account
|
Detects that a user attempted to access a suspended or a disabled account.
|
|
UBA : Bruteforce Authentication Attempts
|
Detects authentication failure brute force attack (Horizontal and Vertical).
|
|
UBA : Repeat Unauthorized Access
|
Indicates that repeat unauthorized access activities were found.
|
|
UBA : Unauthorized Access
|
Indicates that unauthorized access activities were found
|
|
UBA : User Access Login Anomaly
|
Indicates a sequence of login failures on a local asset. The rule might also indicate an account compromise or lateral movement activity. Ensure that the Multiple Login Failures for Single Username rule is enabled. Adjust the match and time duration parameters for this rule to tune the responsiveness.
|
|
UBA : User Accessing Account from Anonymous Source
|
Indicates that a user is accessing internal resources from an anonymous source such as TOR or a VPN.
|
|
UBA : User Time, Access at Unusual Times
|
Indicates that users are successfully authenticating at times that are unusual for your network, as defined by "UBA: Unusual Times" building blocks.
|
|
UBA : VPN Access By Service or Machine Account
|
Detects when a Cisco VPN is accessed by a service or machine account. Accounts are listed in the 'UBA : Service, Machine Account' reference set. Edit this list to add or remove any accounts to flag from your environment.
|
The detailed list of log sources that are needed for each of this use case, along with the description of each of the use case, is embedded in the hyperlink for each use case.
Tuning and customizing the use cases
Analysts may want to tune or customize these use cases or adjust their risk scores depending upon the needs and the risk posture of their environment. This short video walks through the process of how you can create, modify or tune use cases. When you create or modify existing rules, it is important to select a SenseValue (risk score) within a defined range to apply across UBA rules. A risk score set extremely high or low compared to other rules can skew the UBA engine to favor a behavior over others and lead to improper results.
Some of the use cases depend on reference sets for proper detection of their intended behaviors. It is imperative that SOC analysts populate these reference sets before enabling those use cases. If the required reference set is empty or is not populated with proper data, the use case will either be noisy, incorrectly detect a behavior, or go quiet giving you a false sense of security.
If you’d like to learn more about maturing your UBA deployment, stay tuned for the rest of the series or visit the link to browse the collection of available use cases.
#QRadar