IBM Security QRadar Reviews

We are using mixed solutions. We are currently working with IBM solutions and Azure system services. We are using two SIEM solutions: Azure Sentinel and QRadar. Azure Sentinel is covering our cloud-based solutions, and QRadar is covering our on-premise solutions.

QRadar has a lot of connectors out of the box. It has a lot of predefined and pre-deployed connectors that you can use. 

It has a lot of good correlation rules. From a customer's point of view, it is one of the best solutions because you don't need to create correlation rules from scratch. You just review them and customize them as you want. 

It supports using SQL queries. Sentinel uses KQL, but you need to learn it from scratch.

It doesn't have a SOAR system by default. You need to purchase it additionally, which is the main problem with QRadar. 

Its reporting can be improved.

I have been using this solution for approximately three years.

It is stable.

It is scalable. It works for small, medium, and large enterprises. You can have a huge SOC, and you can implement it in a big company. 

Our company has more than 5,000 assets, and we are covering them all with the QRadar system.

We are using Azure Sentinel for our cloud-based solutions. The best functionality that you can get from Azure Sentinel is the SOAR capability. So, you can estimate any type of activity, such as when an alert was triggered or an incident was found.

Azure Sentinel doesn't have many connectors for third-party SIEM solutions. Many customers are struggling with the integration of Azure Sentinel with their on-premise SIEM.

If we start to collect all logs from our on-premise SIEM solutions, Azure Sentinel will cost much more than QRadar. If we calculate its cost over the next five or ten years, it will cost more than QRadar.

You have a one-time payment, and you also can purchase it for one year as a subscription. We have it on-premise, and we have a permanent license for it. We have to pay for the support on a yearly basis.

If you compare its cost with Sentinel for one year, QRadar would seem more expensive, but if you compare its cost over five or ten years, Azure Sentinel will be more expensive than QRadar.

I would recommend purchasing a cloud-based license subscription because it doesn't have any limits on the license. You can easily install it in a cloud environment. This cloud pack can be integrated with different types of SIEM solutions. So, you can use one management console to query all of the SIEM systems that you are managing. It is like having one window to manage your SOC. For example, a SOC can operate, manage, or provide services for different types of companies, and all these companies can have different types of SIEM solutions. With the cloud subscription of QRadar, you can cover all companies, which is good in my opinion.

I would recommend both QRadar and Azure Sentinel. It depends on the use case of a customer and the environment that they are using.

I would rate QRadar a seven out of ten. 

• The ability to correlate data across our global enterprise in near real time
• The ability to integrate a lot of third-party solutions
• The machine learning pieces with Watson, indicators of compromise, and utilizing that across the value stream

I look at the solution as the best-of-the-breed product. The fact that it can work with what everybody else is doing in the cyber landscape is really what gives it the edge.

The solution has improved the efficiency of our security team. These improvements prevent the need for more proactive security activities.

The improvements did not reduce our staff. It's funny, because IBM keeps on having this conversation about staff headcount. It probably sounds good to senior leadership, like to a CIO. The reality is that nobody's looking to decrease the number of staff who they are hiring.

We're looking at refocusing those resources and energy on being able to do additional, higher-value activities. It's more of the case that I don't need as many junior resources. I can focus on some of the things that are a little bit more important.

Our equipment collects billions of pieces of data. We're 100,000-plus EPS per second. The daily list of required investigations for the offenses is manageable.

We've had incidents in our environment. How long it takes QRadar to detect them is always a function of the rules being correlated, the people watching them, and pieces of that nature. I'd say it's in real time. The question is, when it comes to tuning, we want to know if it was tuned appropriately, so it's not lost in the pile of needles.

Room for improvement is more in relation to a lot of the features, the automation of incidents themselves, and being able to automate workflow responses.

Overall, I love the product. IBM usually puts good resources and talent behind things. What they fail to do is to bring all the security together and make sure everything inter-operates and creates one pane of glass.

Actually, I don’t want to say "one pane of glass" because we have seen other vendors do that. They fail miserably because they do not understand where people are coming from.

In terms of some of the right-click functionality that is within QRadar, it should work automatically for all the other IBM products. It shouldn't be something that customers develop. There are pieces in which they have to step back and get some of the foundational pieces.

There are pieces that I feel that IBM should do better. They own Guardium, they own AppScan, and they own some of these other pieces of the security infrastructure that need to relate to QRadar or to Watson. It's the foundational pieces that I feel they need some focus on.

Let's do some of the basics really well. I'm looking at it from owning 50 or 60 different security products across a global organization.

They keep on adding products based on a simple feature set that they can do real well, but they can't integrate them into the rest of the security economy. It doesn't make sense to keep on buying products like that. Whether it's IBM or others, there are companies in the endpoint space that are taking over because they're saying, "Hey, we're going to do everything across your gamut of security needs."

IBM needs to look at that and how they are going to integrate across all of the security products and have them work together.

We have been using this solution for four years.

The stability is good.

The scalability is great.

We don't really use technical support. We're part of some of the engineering and development behind it and we work with a lot of the backend engineers.

Once in a while, we may put something in PMR but most of the time, we are working with the engineers themselves to figure out a solution. They are not really tech support issues.

We have used other solutions, but that was years ago. We've had QRadar for four years. Before that, it was the Symantec solution. The landscape for SIEM has changed progressively over the years.

You're not even talking about the same set of requirements around those things. We just needed to upgrade. We needed the speed, the flexibility, and we needed the correlation building block pieces of it.

I was involved in the initial setup. We are an advanced user of QRadar. While the initial setup was not hard for us, it is a lot more complex where we are right now. It works with integrating some of other IBM products into QRadar, and there's work that needs to be done there to make it seamless.

We were able to be operational in a matter of weeks or months, which is not a long time.

When picking a vendor, the most important thing is partnership.

I honestly have nothing but good things to say about the IBM relationship that we have related to QRadar.

Partnership is going be important. Having the right skillset from an engineering standpoint is important to ensure that you don't set up things backwards. You have a high probability of doing it. This is one of those pieces where IBM doesn't “dummify” the solution for you.

On one side for my senior engineers, they don't want it “dummified” because they need to do it. On the other side of it, there are some aspects that don’t need to be this complex.

For the SMB market, those are some of the areas where I counsel people and say they need to get these types of solutions and do these types of processes. Selling something like QRadar to them becomes a little bit more of a burden because of that complexity. It's like a compliance check mark.

Log aggregation and event correlation did not occur in an enterprise fashion before this product. Troubleshooting more complex issues became much simpler with the addition of this product.

Search capabilities are sufficient for most tasks, although not as easy to use as some other products.

Search capability and indexing still lag behind competitors. We also need to see improved rule based access controls and rule/event tuning.

The search capabilities in QRadar are decent in their ability to be granular but the methodology of search prevents the rapid and easy modification of search parameters as an analyst works through the hunting process.

There are several examples of this. Let’s say you add two or three parameters to your search using various filter methods.

You can quickly change items like the scope of time for your search or the presentation of data, but you cannot quickly change the other parameters such as the IP address you are looking for. So you have a search of 10.0.1.1, the system processes that search, but then you realize you need to search for 10.1.1.2 instead.

You have to delete the old IP and recreate. At that point the search starts over from the beginning. In a system like Splunk if when using the filters the query string is written for you and can be easily modified/edited on the fly. While that may still result in a search restarting the manipulation of that search is faster and more efficient. This is just a single example.

I feel that some of the stability issues are attributed to our network. However, too many issues existed with the product and too many more appeared as they tried to fix different issues.

We never scaled the product before we decided to remove it from our network. From all appearances, scalability was not going to be an issue.

Technical support was OK at best due to the length of time before resolution.

I used ArcSight at a previous company. I would much rather have a correctly scoped and built QRadar to manage. However, as a consumer of ArcSight, it was a very good product.

I was not involved in the initial setup.

Do your due diligence. I found other solutions, with more features at the same cost or less. You don’t have to leave the Gartner Magic Quadrant to beat their price.

I did not choose this product.

Evaluate the product based on a full set of requirements and your security analyst workflow. Do not base your decision on the company name or promises of new abilities years down the line.

We use the product to customize rules and detect malicious behavior. 

The tool's most valuable feature is real-time detection. 

The solution is not as flexible as Splunk. 

I have been working with the product since 2016. 

I haven't contacted technical support yet. 

I worked with Splunk before IBM Security QRadar.

The solution's pricing is based on the EPS model. 

I prefer Splunk since it gives a lot more freedom and flexibility. I rate the overall solution a six out of ten. 

We utilize the product for our Security Operations Center operations. Additionally, we extend its use to our customers, employing it for tasks such as threat hunting, investigation, and triage analysis.

The tool's most valuable feature is log source management. It enables us to connect to various log sources, including content, authentications, or other customized integrations. These integrations can be tailored for use with other platforms that don’t already have built-in IBM add-ons.

Its scalability is also important. It is also compatible with ISO 27001, DSS API, and various certifications.

As part of our security infrastructure, this tool excels in detecting a wide range of attacks. Its responsiveness surpasses that of alternative solutions. Moreover, the user-friendly interface greatly benefits our analysts. The product is helpful in anomaly detection scenarios.

Additionally, we leverage out-of-the-box content and libraries within the IBM ecosystem. Its user behavior analysis helps us to ensure that our customers are protected. 

Correlation plays a pivotal role in our security strategy. It helps us to analyze logs from different sources. This process helps to correlate logs from endpoints. 

Certain updates—especially when using Azure—don't apply directly. Our engineering team must invest additional effort to implement these updates. However, the tool's cloud-based version poses no issues. However, upgrading the product can sometimes be challenging for on-premises instances.

Our current query language (KQL) serves its purpose, but there's room for improvement. Consider introducing a more human-friendly language to streamline analyst training. Analysts could then express queries in a manner akin to human language. This change would expedite processes, making it easier for new analysts to adapt.

I have been working with the product for five years. 

I rate the tool's scalability an eight to nine out of ten. 

Troubleshooting delays have been a recurring challenge. Occasionally, responses take two to three days, leading to escalations. While their website’s knowledge base is commendable, troubleshooting scenarios demand more time. My observation is that they may be understaffed.

Neutral

My company has customers using Splunk and Chronicle SIEM. When comparing Splunk and IBM Security QRadar, they indeed offer similar features, but their business models differ. Chronicle SIEM predominantly operates in the cloud. However, we cannot offer the cloud model if a customer prefers an on-premises solution.

Splunk and IBM Security QRadar both cater to diverse deployment preferences. Splunk boasts a slightly more robust correlation engine than IBM Security QRadar. Splunk tends to be marginally more expensive than IBM Security QRadar.

The number of log sources significantly impacts deployment complexity. The process becomes more complicated for environments with 50 log sources compared to those with fewer sources (e.g., 20 or 10).

Each log source requires a connection to IBM, a task that can take several days or hours, depending on its complexity.

On average, the entire deployment process spans six to eight weeks.

The tool's on-premise version is expensive. However, it is cheaper than Splunk. The hybrid model offers shared instances for customers, which is not expensive. Customers with a limited budget can opt for it. You can get premium support with licenses. However, if you need customized integration, you need to buy it. 

I rate the overall product an eight out of ten. 

Our primary use case is in the banking industry in two banks here in Egypt. We generally are monitoring the user behavior of the employees, For example, working after working hours, and signing into the machines after working hours.

The most valuable feature is the machine learning module.

I would like to see the interface improved along with the tuning and any adjustments when it comes to maintenance. It is not straightforward. I would also like to see some artificial intelligence and alternative solutions.

I have been using IBM QRadar User Behavior Analytics for almost five years now.

I would give stability an eight on a scale of one to ten.

The scalability is not a problem and we have above three thousand in our organization.

The initial setup is extremely easy and straightforward.

The deployment took around two to three days and we did it ourselves in-house. We simply downloaded the application and went from there following the deployment process.

We are seeing a return on investment when it comes to profiling the employees.

The pricing is higher but cheaper than others and there are no additional costs.

We looked at ArcSight but the cost is more expensive than IBM. ArcSight did have the artificial intelligence model.

I would recommend tuning it to the maximum before going live. I would rate IBM QRadar User Behavior Analytics a seven on a scale of one to ten.

We're a customer, partner, or reseller. We use QRadar on our own internal SOC. We are also a reseller of QRadar for some of the projects. So, we sell QRadar to customers, and we're also a partner because we have different models. We roll the product out to a customer as part of our service where we own it, but the customer is paying. We also do a full deployment that a customer owns. So, we are actually fulfilling all three roles.

The most valuable thing about QRadar is that you have a single window into your network, SIEM, network flows, and risk management of your assets. If you use Splunk, for instance, then you still need a full packet capture solution, whereas the full packet capture solution is integrated within QRadar. Its application ecosystem makes it very powerful in terms of doing analysis.

In terms of the GUI, they need to improve the consistency. It has been written by different teams at different times. So, when you go around the interface, you'll find a lot of inconsistencies in terms of the way it works.

I'd like them to improve the offense. When QRadar detects something, it creates what it calls offenses. So, it has a rudimentary ticketing system inside of it. This is the same interface that was there when I started using it 12 years ago. It just has not been improved. They do allow integration with IBM Resilient, but IBM Resilient is grotesquely expensive. The most effective integration that IBM offers today is with IBM Resilient, which is an instant response platform. It is a very good platform, but it is very expensive. They really should do something with the offense handling because it is very difficult to scale, and it has limitations. The maximum number of offenses that it can carry is 16K. After 16K, you have to flush your offenses out. So, it is all or nothing. You lose all your offenses up until that point in time, and you don't have any history within the offense list of older events. If you're dealing with multiple customers, this becomes problematic. That's why you need to use another product to do the actual ticketing. If you wanted the ticket existence, you would normally interface with ServiceNow, SolarWinds, or some other product like that. 

Their support should also be improved. Their support is very slow, and it is very difficult to find knowledgeable people within IBM.

Its price and licensing should be improved. It is overly expensive and overly complex in terms of licensing. 

I have been using this solution for 12 years.

Their support is very slow. it is very difficult to find knowledgeable people within IBM. I'm an expert in the use of QRadar, and I know the technical insights of QRadar very well, but it is sometimes very painful to deal with IBM's support and actually get them to do something. Their support is very difficult to work with for some customers.

I work with Prelude, which is by a French company. It is a basic beginner's SIEM. If you never had a SIEM before and you wanted to experiment, this is where you would start, but it is probably that you would leave very quickly. I've also worked with ArcSight and Splunk.

My recommendation would depend upon your technical appetite or your technical capability. QRadar is essentially a Linux-based Red Hat appliance. Unfortunately, you still need some Linux knowledge to work with this effectively. Not everything is through the GUI. 

Comparing it with Splunk, in terms of licensing, IBM's model is simpler than Splunk's model. Splunk has two models. One is volume metrics, so you pay for the number of bytes that are transmitted daily. The other one is based upon the number of events per second, which they introduced relatively recently. Splunk can be more expensive than QRadar when you start to get into adding what they call indexes. So, basically, you create specific indexes to hold, for instance, logs related to Cisco. This is implicit within QRadar, and it is designed that way, but within Splunk, if you want to get that performance and you have large volumes of logs, you need to create indexes. This is where the cost of Splunk can escalate.

Installing QRadar is very simple. You insert a DVD, boot the system, and it runs the installation after asking you a few questions. It runs pretty much automatically, and then you're up and going. From an installation point of view, it is very easy.

The only thing that you have to get right before you do the installation is your architecture because it has event collectors, event processes, flow collectors, flow processes, and a number of other components. You need to understand where they should be placed. If you want more storage, then you need to place data nodes on the ends of the processes. All this is something that you need to have in mind when you design and deploy.

It is overly expensive and overly complex in terms of licensing. They have many different appliances, which makes it extremely difficult to choose the technology. It is very difficult to choose the technology or QRadar components that you should be deploying. 

They have improved some of it in the last few years. They have made it slightly easy with the fact that you can now buy virtual versions of all the appliances, which is good, but it is still very fragmented. For instance, on some of the smaller appliances, there is no upgrade path. So, if you exceed the capacity of the appliance, you have to buy a bigger appliance, which is not helpful because it is quite a major cost. If you want to add more disks to the system, they'll say that you can't. If they ship a disk with 2 terabytes that the older appliances have, and you say to them that you can commercially get 10 terabyte disks, they will say this is not possible, even though there is no technical reason why it cannot be done. So, they're not very flexible from that point of view. For IBM, it is good because you basically have to buy new appliances, but from a customer's point of view, it is a very expensive investment.

Make sure that you have the buy-in from different teams in the company because you will need help from the network teams. You will potentially need help from IT. 

You need to have a strategy of how you onboard logs into SIEM. Do you take a risk-based approach or do you onboard everything? You should take the time to understand the architecture and the implications of design choices. For instance, QRadar Components communicate with each other using SSH tunnels. The normal practice in security is that if I put a device in a DMZ, then communication between the device on the normal network, which is a higher security zone, and the DMZ, which is a lower security zone, will be initiated from the high-security zone. You would not expect the device in the DMZ to initiate communication back into the normal network. In the case of QRadar, if you put your processes in the DMZ, then it has to communicate with the console, which means that you have to allow the processor to communicate. This has consequences. If you have remote sites or you plan to use cloud-based processes, collectors, etc, and have an internal console, the same communication channels have to exist. So, it requires some careful planning. That's the main thing.

I would rate QRadar an eight out of 10 as compared to other products.

QRadar improved risk assessment and vulnerability, plus it has reduced some staff. It has also improved the training abilities of the people who use it, e.g., IR teams. It is the core of our entire SOX. Therefore, we use it for everything through training all the way up through management. 

Due to the skills shortage, we are able to use it from the standpoint of bringing in a lower level employee or a person who may not have security knowledge. We can put them in front of the product and they will still have the information that they need and have them at a level where they can run the system. Also, products, like Watson, make it work better.

The overall workload automation should be built into it. Part of the efficiency side of it is the ability to take the information as it comes in and assign it into a group. Now, the team leader no longer needs to assign it manually. He manages the workflow as it comes in directly to the individuals. Then, the individuals respond on it. As it closes, it goes back to the workflow, recording the amount of time it took for them to close it. It should show: 

• How long did it take to get assigned?
• How long did it take for the person to open it?

Then, you can show that a person may have issues opening network problems.

We have not suffered a network breach.

The solution has improved the efficiency of our security team.

We are at 115,000 events per second.

We run 65 servers with just two people: an engineering person and me.

We have 65 servers globally, and I just got my own.

The technical support is poor. Mostly because when I open a PMR for IBM, I am stuck with Level 1 staff. As an engineer, nothing that I am bringing them does not require Level 2 or Level 3 support. Most of the stuff that I open ends up code changes or bug fixes.

Our company is far more mature than most. Our issue is that the support is slow.

It was a whole different product when we installed it.

The most important criteria when selecting a vendor: stability. The security space is tough. Unlike a lot of other spaces, IBM will not be bought anytime soon as a 100 year-old company.