Apps
Understanding the UBA Risk Score
The Use Behaviour Analytics (UBA) app is one of the most interesting QRadar apps. It allows you to detect internal threats, such as rouge employees and compromised accounts. The UBA works by observing the behaviour of each user and attributing a risk score for each person. For each UBA rule triggered, the risk score for the user is incremented. In this way you can track which users are performing risky (or abnormal) actions. Once a user surpass the company risk threshold, an offence is generated for the user. If a user stays a long period of time without having any risky action, then the risk is gradually decreased, which is called risk decay.
To exemplify the risk score concept, take a look on the figure above. Let’s imagine that John access a suspicious website. This triggers an UBA rule that increase his user risk by 10 points. Then, John logs into a server and escalate his privileges to root for the first time. Again, an UBA rule is triggered and his risk is increased. After that, he does not present any risky behaviour for 8 hours, so his score slowly starts to decay. Eight hours later, John dumps an entire SQL database, increasing his risk again. After that, he SSH into a server in Russia, which also increases his score. At this point, his risk is higher than the company threshold risk, so an offence is generated for John. After that, even if John’s risk decay, his offence will still be open.
This example shows the real value of the UBA app, since each small action is not enough for a traditional rule-based offence. However the combined actions are indeed suspicious and the UBA app was able to detect it.
If you want to learn more about the UBA and other QRadar apps, check this online course in which the main QRadar apps are presented.
Proactively identifying performance issues with the HCF plugin
In the last post, we talked about the Health Check Framework (HCF) and its benefits. Since I’ve been using the plugin for over a month I was able to collect useful performance information and identify some potential performance issues even before they occur. In this post, you will learn how to proactively monitor your system performance and prevent potential performance issues from happening.
First, you will need to install the Health Check Framework plugin. The installation process is quite straightforward: all you need is to go to your IBM app store on your QRadar environment, search for “Health Check Framework” and install it following the steps on the screen. With the plugin installed, you can start by browsing the plugin interface and extracting a report about your system performance. In this report, you will see a lot of details about your system, such as CPU Usage, Disk Usage, EPS, FPM, heavy reports, current users, etc.
In my case, we are planning to expand the scope of servers monitored by QRadar, so I wanted to understand if we would need any hardware upgrades. For testing purposes, I disabled the log collection of 30 Windows servers that were currently being monitored and I noticed that the RAM memory usage reduced by around 5% (see images below). Obviously, this number will vary according to the server usage, but this test gave me a rough estimation that for each 30 servers my RAM memory usage will increase around 5%. So with the help of the HCF plugin, I was able to identify hardware upgrades to accommodate the monitoring of new servers, avoiding system outages due to lack of resources during the scope expansion.
Even if you’re not planning to expand your scope, you can use historical performance data to proactively identify issues. For example, let’s say, your QRadar monitors a new e-commerce website. The number of logs you get depends on the traffic your website has. With the historical data, you will be able to identify a performance trend: as the e-commerce website becomes more popular, the EPS increases and the CPU/Memory usage also increases. With this data, you will be able to estimate at which point in time you will need a hardware upgrade, avoiding any unexpected system outages due to lack of resources.
Another very interesting data that I found in this report was the “Event Average Payload Size”, which as the name says, tells you the average size of logs received. This can be very useful to identify hard drive requirements when expanding your EPS.
Using the same plugin I was also able to identify heavy reports and rules that were severely impacting the performance of my QRadar environment. After reviewing and fixing the queries of the reports and rules, it was noticed a considerable reduction in the CPU usage.
Monitoring the performance of your system puts you in a proactive posture in relation to your environment. Being proactive means that you will not be firefighting issues as before, but instead, monitoring and planning upgrades ahead to avoid issues even before they happen.
QRadar Insights 