IBM Security QRadar

Introduction
This blog is in line with the series of blogs that have been published around QRadar EDR (Endpoint Detection and Response) integration with QRadar SIEM (Security Information and Event Management). In the previous blogs, we have dealt with how different security use cases like data exfiltration, vulnerability exploits, potential phishing etc. are implemented. The links of previous blogs are pasted at end for reference.

To provide a brief introduction for the products:

QRadar SIEM

In cybersecurity, Security Information and Event Management (SIEM) consists of technologies that provide analysis, threat mitigation and logging of security events and packets of data flowing in the wire within a network. SIEM provides a general view of all technical infrastructure, with specific data of security events and flows and the mitigation of any security threat vectors that are found in the environment. A SIEM solution responds to advanced threats which cannot be analysed with general monitoring tools.

IBM QRadar SIEM is one of the most popular SIEM solutions in the market today. It has been the Leader in the Gartner’s Magic Quadrant for more than a decade now. It helps you to quickly uncover existing and potential threats by using its advanced analytics capabilities. It also provides many useful features such as centralized visibility, flexible deployment, automated intelligence, machine learning, and pro-active threat hunting.

QRadar EDR 

QRadar EDR is an Endpoint Threat Detection and Response solution that uses Artificial Intelligence driven behavioural analysis to detect and respond to various advanced threats and protect the organisation from any security breach. QRadar EDR uses its proprietary Nano OS Technology to remain invisible to attackers as well as to provide visibility into the system at the hypervisor level. Traditional endpoint management solutions are mostly signature based and are incapable of zero-day attacks. QRadar EDR on the other hand uses behavioural detection approach, which monitors events generated by every process and in case of any suspicious behaviour, it triggers an alert. When an alert is triggered, the agent switches to deep monitoring mode to collect more data to enrich the alert. Thus, it achieves low storage and bandwidth consumption and logs only the information that matters. Apart from detecting the threats, QRadar EDR also provides robust solution for quick and automated response where it can isolate and de-isolate the endpoints and interact with endpoints in real time leveraging its Live-Response feature.

The idea behind this blog

QRadar EDR consists of different agents which are installed on endpoints and these agents report to the QRadar EDR hive. It is responsible for storing events from the endpoints, running correlation and behavioral analysis, and triggering alerts and corresponding response. QRadar EDR also consists of a dashboard which is used to view policies, events, alerts, status of agents and different responses etc. Overall, the architecture of QRadar EDR would consist of multiple agents, the hive, and the dashboard. 

Figure 2: Sample Pulse dashboard

Apart from the Pulse dashboard, QRadar SIEM now has data from all the endpoints reporting to different hive servers. This helps in implementing different security use cases which not just restricted to a limited number of endpoints. This integration helps QRadar EDR to extend its capabilities like correlation across the complete environment which was not possible with single QRadar EDR. 

Figure 3: Multiple hive servers connected to one QRadar SIEM

In this blog we have defined a few of these security use cases by creating custom rules on QRadar SIEM.

Use case 1: Lateral ransomware behavior detected across hive servers:

We have integrated two QRadar EDR hive servers with QRadar SIEM with the help of the existing QRadar EDR DSM. The EDR servers appear as two different log sources in the QRadar SIEM log source management app as following.

i.              EDR_ATL

ii.             EDR_AWS

Figure 4: Log source management app view in QRadar SIEM

QRadar EDR works on behavioral detection method and has multiple in-built protection policies as well as custom Detection Strategies (Destra) to detect malicious behaviors. Events from the registered endpoints are sent to the EDR hive, where it is corelated and if matches any of the policies, it triggers alerts. These alerts are sent to QRadar SIEM with the help of QRadar EDR Rest API protocol, which is parsed and mapped to the log source created for the entire EDR server.

In this use case, we will focus on ransomware behavior. QRadar EDR has the capability to detect ransomware behavior on the endpoints. Also, it tells us the footprint of the ransomware across the endpoints which are registered to the EDR server. But there are instances where multiple EDR servers are deployed within the same organization based on region or organizational structure or be it number of endpoints being limited to 10,000. In case of any malicious threats, it is important to detect and stop the lateral movement of the threat vector as soon as possible to minimize the impact. And when it’s a ransomware, the stake is even higher.

So, in this case, we can use powerful, ready to use and customizable correlation rules in QRadar SIEM to detect ransomware behaviour across the multiple EDR servers.

We have created the following rule in QRadar SIEM:

 

Figure 5: Sample rule conditions

The first condition in the rule looks out for specific ransomware events coming from any of QRadar EDR log source.

If we have 2 events with the same event name having specific QIDs, coming from different log sources (EDR servers) within 30 minutes, then it suggests that the ransomware behavior has been observed across the enterprise level and there is a possibility that the same ransomware has traversed across the multiple endpoints within the organization which needs urgent attention.

The rule response has been set as the following:

Figure 6: sample rule response

When the conditions of the rule are met, it will trigger an offense as “Ransomware detected” as per the configuration of rule response.

Figure 7: Offense page in QRadar SIEM dashboard

Once we click the offense details, we can find more information about it. From the associated events to the offense, we can find out the details regarding the endpoint where the ransomware event has taken place.

Figure 8: offense details page

From the offense details, we get the high-level view of pattern/trend of the attack, we can execute custom scripts from rule response section or can go to the respective EDR dashboard to utilize its capabilities for further investigation and action to mitigate the attack quickly and effectively.

Use case 2: Multiple login failures for same user(s) across hive servers:

In this use case we create a rule, where we detect multiple login failures across multiple endpoints. Usually, any SIEM can detect login failures. Similarly, any EDR can generate alerts for login failures. But imagine the amount of log sources that SOC admin will have to create to detect if a single user such as Domain administrator is being compromised across the complete domain. If you have 10,000 endpoints, then in any SIEM, analyst will have to create 10,000 log sources to be able to get these login failures related events. 

Similarly, in EDR you may have 10,000 alerts, but they will be missing the correlation powers of SIEM; which can help you determine if something fishy is happening at enterprise network level. 

This makes this use case extremely interesting and exciting. Here we will have alerts from individual hive servers being sent to QRadar SIEM. As in previous case, each of the Hive servers is an individual log source.

We have created following rule:

Figure 09: Sample rule test conditions

Here in the first condition, we are looking for specific login failure events coming from any of the QRadar EDR log sources.

If we have 10 events showing login failures for same user for example: Domain Administrator, coming from different log sources, which in this case is hive servers in span of 15 minutes, it means that someone is trying to hide the brute force attack detections by avoiding attempts on single endpoints. Instead, they are attempting to try different passwords on different machine. 

This is where the robust detection capabilities and custom rules capabilities of QRadar SIEM comes to rescue. With the above rule, we can correlate the happenings on different hive servers and identify the issue.

As seen in the above rule test conditions, event name will be  “Custom Destra Alert” as we have used a DeStra (Detection Strategy) to generate an alert in  QRadar EDR for login failure events. 

The DeStra created on all the QRadar EDR hive servers looks like this:

Figure 10: Sample Destra

Note: The DeStra created is as is and should be additionally validated and customized as per need basis.

This DeStra binds on “Account Logged on Failed” event received by QRadar EDR from individual endpoints connected to it. For every login failure the alert generated on EDR dashboard looks like this:

Figure 11: Alert displayed on QRadar EDR dashboard.

Once we have set the rule response and rule action in QRadar SIEM rule wizard, and if the rule is matched and offense will be generated like this:

Figure 12: Offense summary page in QRadar SIEM

Here we can see that the user with username Administrator and Security have had multiple login failure attempts across different hive servers.

Once we click offense details, one can find more information:

Figure 13: Offense details page in QRadar SIEM

Over pulse dashboard we can add multiple widgets of our choice, so that these data is visible at single pane at a single glance for all the users.

Figure 14: Pulse dashboard widget

Figure 15: Pulse dashboard widget

Figure 16: Pulse dashboard widget

We have customized the pulse dashboard to look like this:

Figure 17: Complete sample Pulse dashboard

As you have seen, multiple QRadar hive servers can be integrated with QRadar SIEM to implement security use cases for a broader attack surface. Many more security use cases can be implemented using the power of correlation of QRadar SIEM and broader reach using multiple QRadar EDR endpoints. This blog was a part of series of blogs on integration of QRadar EDR. The previous blogs that were referenced here are: 

·      Unified Security Using IBM QRadar and QRadar EDR - https://ibm.biz/BdSpBX

·      Integrating QRadar EDR with IBM QRadar User Behaviour Analytics - https://ibm.biz/BdSpBH

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:

Ashish Kothekar: ashish.kothekar@in.ibm.com
Vikram Khopade: vikhopad@in.ibm.com
Prabhupada Satapathy:  prabhupada.satapathy@ibm.com

Special thanks to Boudhayan Chakrabarty (bochakra@in.ibm.com) for reviewing and approving this article.

*QRadar EDR was previously known as ReaQta. Going forward we will use QRadar EDR as standard nomenclature.