IBM Security QRadar Reviews

Currently, our main use case for IBM QRadar User Behavior Analytics revolves around investigating user activity: specific user activity which we find suspicious. We don't monitor the dashboard of IBM QRadar User Behavior Analytics actively, but whenever we have an alert from other tools, we use it to check whether the user has triggered rules in our SIEM, whether the risk score is high, and other suspicious behaviors we can track.

What I like about IBM QRadar User Behavior Analytics is that it uses machine learning algorithms to generate risk scoring for the user activity. I also like that it syncs with our Active Directory users, so it really has full coverage for all users in our environment. I also find the risk scoring feature of IBM QRadar User Behavior Analytics pretty interesting. I don't use it well enough today, but it's a feature I look at closely.

What needs to be improved in IBM QRadar User Behavior Analytics is the user experience. It's not optimal. For example: we are constantly looking for updates on the app and other features, so we could have a better user experience. Some screens are a bit clunky. We're still trying to figure out whether the solution is going to have a better user experience in the future, but nowadays it's a bit too complex. We need it to be more user-friendly.

I've been using IBM QRadar User Behavior Analytics for eighteen months. 

We've had issues with the stability of IBM QRadar User Behavior Analytics. We had bugs once or twice, but they were quickly solved by IBM's support team. The bugs weren't really something that stopped us from working. We managed to solve them rather quickly.

IBM QRadar User Behavior Analytics is easy to scale.

Technical support for IBM QRadar User Behavior Analytics was helpful.

IBM QRadar User Behavior Analytics was really easy to set up. There were no issues with setting it up.

I don't recall the exact version of IBM QRadar User Behavior Analytics I'm using, but it's probably the latest one. It's version 4.1.7.

My advice to others looking into implementing IBM QRadar User Behavior Analytics is to have a dedicated team to implement the solution. Some solutions require close knowledge of your environment, so someone would have to know your infrastructure, your network, your users, and your Active Directory environment well. These are things partners aren't able to do well if they are not supported by internal teams inside their company.

I'm rating IBM QRadar User Behavior Analytics seven out of ten.

My company has a contract with another company that is a partner of IBM. The company I'm in is just a customer, not an IBM partner.

Currently, we are using only Amazon Web Services for monitoring. We have CloudTrail, GuardDuty, Avast, and some Kubernetes security we have installed on Amazon AWS. By getting these logs, we have created the uses for these components.

I have used IBM QRadar User Behavior Analytics in a Cloud Pak on Amazon, and there it runs on top of it and is easy to assess. Additionally, I have installed processes and characters.

The most useful feature of IBM QRadar User Behavior Analytics is the User Behavior Analytics aspect. For example, whoever logs into the Amazon AWS to the interface, if someone is logging in for the first time that the administrator has created, or someone is logging in, we receive an email notification saying that they have logged in, we need to check. Based on that, we will start checking to see if the visit was a valid one or a malicious one. Even if we only have a few users, such as 25 to 30 Amazon AWS records.

Whenever we are upgrading or installing any type of patch, at that time we have some delays. 

 Sometimes by mistake, AWS has migrated some other accounts to my enrollment. At that time, we receive a notification special for that. We have created one rule and a case. We receive a notification and we are informed that the Amazon AWS team, sent an email apologizing for this happening. They have confirmed that going forward we will not receive this type of account modification issue. They have sent an email to us. 

If you are searching for three to four months back it takes and there is a time delay. If I compare it to Splunk, it is a little bit delayed. It is because Splunk is using Elasticsearch, while IBM QRadar User Behavior Analytics uses a normal one. For example, if Splunk takes two minutes, it will take IBM QRadar User Behavior Analytics approximately three minutes.

I have been using IBM QRadar User Behavior Analytics for approximately seven years.

I have used many other solutions previously, such as Splunk and McAfee SIEM tool.

The initial setup of IBM QRadar User Behavior Analytics is straightforward. We only have to activate a few aspects. We directly installed our process characters, and an all-in-one setup with it to do the installation. The deployment took use 30 to 40 minutes. However, if you want to add components it will take more time.

We have seen a good return on investment with IBM QRadar User Behavior Analytics.

We pay approximately $40,000 to use the solution annually. This solution is a lot less expensive than Splunk.

I rate IBM QRadar User Behavior Analytics an eight out of ten.

We use QRadar to collect logs and monitor user activity and traffic from one network to another. The SOC team is in a room watching the logs from the tool live most of the time. 

QRadar monitors all internet activity and the output of every device configured to send a log. All traffic from various networking devices passes through the QRadar servers, and we can view it live.

We have two data centers, and QRadar is deployed in one. It comes with two physical appliances to allow failover capability. There's a management interface that binds them together, and we set up an interface for each device connected to the network that sends a log.  

QRadar allows you to filter by the source and destination IPs and see detailed logs on that. For example, if a user is trying to access a server using a malicious port like 4.5.0, I can get valuable data and take action from other devices. 

It also has a graph that shows the traffic history. I can see what happened yesterday or today. If there's an incident, I can check the traffic behavior on QRadar.

I would like to see QRadar add more integration and interoperability. For instance, we are not able to send logs from Windows servers. We can send logs to the QRadar server from network devices and other types of servers. However, we have more than a hundred Windows servers that still don't use QRadar. 

Our company has been using QRadar for the last five years. We implemented it in 2017.

QRadar's performance has room for improvement because it cannot handle the volume. I need massive amounts of logs from various devices in our existing network architecture. IBM needs to improve QRadar's capacity to handle more logs. 

Usually, disk space is the issue. When it runs out of space, we need to stop logs from different network devices, especially the firewall, before it starts working. 

It's hard for me to estimate the number of QRadar users because all of our banking traffic and user activity will pass through QRadar. At the higher end, more than 25,000 active users might use QRadar.

I was directly involved with the IBM support team during the implementation, and we received training for some time after. The service has been excellent and supportive. 

When we needed to upgrade, our security team invited the IBM technician back, and it was very smooth. Now, they are planning to set up redundancy in our second data center. Generally speaking, the support is good, and they check in about once a month remotely. I am directly involved with them, but I hear positive feedback from the team. 

The initial setup was configured in Linux on the server. We had a technical guy from IBM who came from Kenya. We only prepared the environment, like setting up the rack, but an IBM technician took care of the implementation. We also rely on the vendor for support and activities that require professional expertise.

I rate QRadar eight out of 10 for return on investment. We get a lot of valuable data from QRadar.

I rate QRadar eight out of 10. 

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. 

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.

My use case for IBM QRadar User Behavior Analytics is to consolidate all the logs and events from a different tool so that I can see the alerts from that other tool on the dashboard.

My company connects the Windows event logs to the Xfinity router deployed on the main server, but I have to make some configurations to detect activities.

My team is working on reinforcing IBM QRadar User Behavior Analytics features since the solution has not been used for a while because there's a new generation of engineers in my company. My team has to reconfigure almost every screen, including IBM QRadar User Behavior Analytics.

What's most valuable in IBM QRadar User Behavior Analytics is its higher availability than other tools. It consolidates all alerts and detections from the other tools, but my team has to check each tool. As my company lacks the manpower to do that, my team has to do monitoring while working on making each function clear.

As a product, IBM QRadar User Behavior Analytics does everything mentioned on the datasheet for my company's version. Still, compatibility is a problem because my company needs to use an updated version of the tool. That version doesn't integrate with many new-generation tools, so this is an area for improvement.

You can scale IBM QRadar User Behavior Analytics, but it has room for improvement.

I've been using IBM QRadar User Behavior Analytics for years.

IBM QRadar User Behavior Analytics has been stable, and my team has made no significant changes since 2015. The team is working on utilizing it most efficiently.

The scalability of IBM QRadar User Behavior Analytics is a six out of ten.

My company doesn't get support from IBM because it's on a perpetual usage type of contract. My team can configure IBM QRadar User Behavior Analytics but cannot contact IBM for help.

When I used to get technical support for IBM QRadar User Behavior Analytics, I'd say it was a seven out of ten.

The version of IBM QRadar User Behavior Analytics, which my company uses, is a little outdated from 2013. That version doesn't have the log collection feature.

My rating for the version of IBM QRadar User Behavior Analytics I'm using is a seven overall.

The most valuable features currently are the security behaviors and pdf files.

I would like to see more integration in place after the security lock.

I have been using IBM QRadar User Behavior Analytics for a couple of years now.

The product is very stable.

The initial setup was straightforward and took three to four months to deploy.

We used a vendor team to assist us in the process of deployment.

I would rate IBM QRadar User Behavior Analytics an eight out of ten.

Our primary use case for the solution is providing visibility for what occurs in our security system and IT assets. So all our event logs and information from a setting and criticality level go there. Additionally, there's AI used to trigger alerts when things are going bad, and then we can action them.

We find predictive analysis capabilities valuable.

The solution should include remote action capabilities.

We have been using the solution for approximately three years.

The solution is stable.

The solution is scalable. Over 1,000 people in our organization use the solution.

The initial setup is moderate, and it is neither easy nor difficult. However, it took approximately one week to complete the implementation.

We implemented it through a vendor team.

We chose this solution because it was provided to us through software as a service.

I rate the solution an eight out of ten. The solution is good but can be improved with enhanced remote control ability. I recommend the solution to new users considering it.