IBM QRadar

Employees who are targets of phishing attacks, share credentials, or mistakenly download malware are some of the many ways external actors pose as insiders to obfuscate their user behavior and attack an enterprise. Security teams are responsible to protect the organization, from both external threats and disgruntled employees with malicious intent who have access to confidential data and intellectual property. Attackers know that after they compromise an authentic insider’s credentials they can remain undetected for days or months. This is often enough time for attackers to cause major damage to the organization.

Insider threats are responsible for over 60 percent of the security attacks facing organizations today. An integrated security platform with user behavior analytics provides early visibility to insider threats and allows security operations to act and mitigate issues before a large-scale breach.

IBM QRadar administrators can download the QRadar UBA app from the X-Force App Exchange to start monitoring risky activity and detect insider threats. In this blog, we will explore the first phase of deploying UBA with use cases that can help get immediate value from your QRadar UBA app and SIEM platform. Additional articles will focus on building up to a more mature model that covers multitude of advanced use cases.

In the first phase of setting up your UBA environment, you can enable use cases to monitor threats related to user accounts, access, and logins. The deviation from normal access or login behavior could indicate a rogue or malicious user trying to gain access to your network and data. For example, if a user accesses the network from an unusual geographical location (e.g.: Russia, Iran, or Iraq) where there are no official company locations) might indicate compromised credentials are in use by a bad actor. Alternately, if a user whose account is dormant while on vacation accesses proprietary data can indicate compromised credentials.

In other cases, we may need more information or activity to help us make a better determination of the user’s risk. For example, if a user logs in at an unusual time than normal then this activity could indicate a malicious / rogue employee, but it could also be an employee working on an urgent deadline. Therefore, QRadar UBA app assigns a risk score to each unusual activity or use case triggered. When a combination of use cases fire and elevates the risk score of a user above a defined threshold, the application identifies the high-risk user. The security team can review the activity to ensure it is not a malicious user attempting to infiltrate your network.

User access & login related use cases

Clients of IBM QRadar who have downloaded the UBA app may consider beginning with a set of use cases that monitor the activity of user accounts to identify improper use, abuse, or non-use of users’ accounts. The data sources needed for these use cases are normally available in a majority of QRadar environments, as a result it allows administrators to show user behavior value quickly.

Recommended use cases for phase I

• New Account Use Detected – Provides reporting functions that indicate a user successfully logged in for the first time. Disabling this rule temporarily can help establish a baseline of normal new account activity in your network.
• Dormant Account Used – Provides reporting functions to indicate that a user successfully logged in after a dormant period. The time-to-live setting in “UBA: User Accounts, Successful, Recent” defines how quickly the rule triggers after the user goes dormant.
• User Has Gone Dormant (no activity anomaly rule) – Indicates that a username’s activity count changed by greater than 80%. This rule and the dependent rule “UBA: User Dormant Account Found (privileged)” indicate that a user suddenly stopped producing activity.
• Account, Group or Privileges Added or Modified – Detects events related to modification of a user’s account, group, or privileges.
• User Account Change – Indicates when user account activity changes the user’s effective privileges, either up or down.
• User Attempt to Use a Suspended Account – Detects attempt by a user to access a suspended or a disabled account.
• Dormant Account Found (privileged) – This rule identifies when a username’s activity count has changed by greater than 80%. “UBA: User Dormant Account Found (privileged)” and “UBA: User Has Gone Dormant (no activity anomaly rule)” and indicates a user has stopped producing activity for an extended period. This condition identifies users who no longer require access due to an absence of activity associated with their username.
• VPN Certificate Sharing – This rule detects when a VPN event’s Username is not equal to ‘VPNSubjectcn’. This could indicate that there is VPN certificate sharing has occurred. Certificate sharing or other authentication token sharing can make it difficult to identify true user activity. These actions can complicate a security investigation in the event of a compromise.

Download the complete list of data sources for above use cases here

Customize rules

In addition to the out of the box use cases, you can create new rules and customize existing rule functionality. This short video walks through the process of how you can create, modify or tune custom rules in the QRadar UBA App. 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 rule over others and lead to improper results.

User access related threats identified by current clients

Based on above use cases, clients have identified several anomalies indicating risky behavior by users.

• In one instance, a commercial bank found users sharing VPN credentials to access corporate networks. On further investigation, they found that internal users were sharing VPN access with 3rd party partners. This is a direct violation of the bank’s security policy and could lead to compromised credentials.
• Another client in the entertainment industry found a user trying to use a suspended account. The activity indicated the credentials of the suspended account required a review for compromise. Consequently, the account was shutdown permanently by the security team.
• In another case, a client in the chemical industry reported accounts being accessed from abroad minutes after logins from North America. This user behavior led to the discovery of (unauthorized) credential sharing within the company.

In conclusion, the setup of the basic UBA use cases allows for easier monitoring of user account access.  To help you continue the evolution of your UBA deployment, we will publish additional use cases to help you mature your UBA environment, tune rules, and to detect more complex behavior.

What’s next

The next blog will focus on use cases for monitoring users’ behavior on end-point devices to track patterns of access to critical resources.

Authors: Milan Patel and Rohan Ramesh