Endpoint Detection and Response (EDR) is becoming increasingly important considering the myriad types of security threat vectors. Many enterprises provide their employees with multiple endpoints, which if left unattended and unprotected can become the entry point for any malware or ransomware. Combining an EDR solution with an SIEM seems to be an optimum option to deal with this security challenge.
This blog builds on our first blog “Unified Security Using IBM QRadar and ReaQta” where we had covered few of the use cases of integrating IBM QRadar with ReaQta. Please refer to the previous blog for detailed steps to integrate IBM QRadar and ReaQta as well as the Reaqta_isolation script mentioned in this blog.
IBM QRadar comes with added User Behaviour Analytics (UBA) capabilities. For this it processes events, flows, vulnerability information, IOCs etc in real time and based on the Machine Learning capabilities of UBA, maintains a list of the most risky Users in an organisation together with all the actions that those Users have done. This is done using a combination of IBM Sense events and UBA Rules. For more information about UBA you may refer to: https://www.ibm.com/docs/en/SS42VS_SHR/com.ibm.UBAapp.doc/c_Qapps_UBA_intro.html.
In this blog, we would cover the use cases of integrating ReaQta with IBM QRadar’s User Behaviour Analytics (UBA) capabilities.
Use Case 1 : Suspicious Activity Followed by Exfiltration
In this use case, we detect a user behaving suspiciously and doing an exfiltration from his system also known as asset. The rule comprises of building blocks related to UBA, which monitor user activities for any large outbound data transfers or possible data exfiltration.
QRadar UBA ranks user via its risk model using Machine Learning (ML)
Rule is as follows:
The rule uses building blocks in its test conditions. Building blocks group commonly used tests to build complex logic so that they can be used in rules.
One of the building blocks used has the following test conditions:
The building block BB:UBA: Compromised Account – Exfiltration track rules that indicate exfiltration activities. It uses three UBA rules from the rich set of default custom rules viz. UBA: Large Outbound Transfer by High Risk User, UBA : Suspicious Access Followed by Data Exfiltration, UBA : Potential Access to DGA Domain.
These rules are themselves full fledged use cases and if enabled, they respond, and trigger alerts as configured.
To learn more about building blocks refer this.
Coming back to our rule, in response section, we can see a custom event is set to be dispatched by the QRadar Custom Rules Engine(CRE) which also updates the SenseValue of the user. That apart, there is a custom action executed named as reaqta_isolation.
This script takes Source IP address of the event which triggered the custom event and isolates that asset. This asset is the one, which was being used by a high-risk user, identified by UBA component of QRadar.
Isolating the asset of a high-risk user, protects the deployment and in turn organisation from any unseen internal threat.
Isolation script and its configuration parameters as explained in detail in our previous blog.
Use Case 2 : User Potentially Phished
In this use case, we are using the UBA Rule in QRadar named as “UBA : User Potentially Phished”, which will detect potential phishing attack on a single user and will take automated action on it.
This rule specifically uses the Building Block called UBA : Compromised Account – Initial Access which will be triggered if a user browses to a malicious website or a phishing website or scam/questionable/illegal websites or a user accessing a risky IP botnet or risky IP malware. Under the scenarios above, there is a chance of user’s account getting potentially compromised.
When this building block will be triggered for 3 times in 1 hour, it will then further trigger the “UBA : User Potentially Phished” rule:
As a response to this rule, we can set a custom action reaqta_isolation which will in turn call the script “isolate_script.sh” used in the previous blog.
Along with increasing the senseValue of the user, we will be able to isolate user’s endpoint immediately using ReaQta API through the custom action script, so that we can prevent any possible impact to the environment while we are investigating the incident.
Use case 3: UBA: Potentially Compromised Account
In this case, we detect a user account which is potentially compromised. This rule uses two other UBA rules to detect if the user account is compromised.
As seen in above image, the two UBA rules: Suspicious Activity Followed by Exfiltration and Initial Access Followed by Suspicious Activity are used. These rules have building blocks, which gather user behavioural data.
If there is a match to this rule, rule response is configured to isolate the user asset temporarily so that he is denied access to the environment and is verified for any potential threats.
Through this blog we showed you how IBM QRadar SIEM’s UBA capabilities combined with ReaQta helps to protect business environments against Insider Threats. More such use cases can be created based on the requirement
If you have any questions regarding any of the points mentioned above or want to discuss this further, feel free to get in touch with us.
Boudhayan Chakrabarty (Bob): bochakra@in.ibm.com
Vikram Khopade: vikhopad@in.ibm.com
Prabhupada Satapathy: prabhupada.satapathy@ibm.com
Special thanks to Darshan Donni: dardonn1@in.ibm.com for reviewing and approving this article.
#Featured-area-2#Featured-area-2-home