Ransomware is one of the top trending concerns in any business; hundreds of business are seeing their data being encrypted even with the latest security solutions. As most of anti-virus solutions are signature based, they are not fully capable of detecting the latest ransomware strains. In this post we will be discussing how to configure QRadar to detect ransomware threats in real time by observing events’ behaviour.
Ransomware may seem a complex attack, but most of them are actually quite simple: The malware encrypts files and then shows a ransom message to the user. The objective of the attacker is to encrypt the files as fast as possible to maximize the impact (if the encryption is slow the user may notice and stop the attack before all the files gets encrypted), and that’s how we can detect the threat.
In a simple language, the encryption process consists in: open a file, read a file, write the encrypted file, close the file. If you are monitoring your servers with QRadar, every time a file is updated an event is generated. So if you detect a high volume of “file update” events in a short period of time, it may be a sign of a ransomware infection.
Based on that, to implement an effective ransomware monitoring capability on QRadar all you need to do is:
- Ensure file audit is enabled on your windows servers: You need to be able to see events such as “File open”, “File Update” and “File Delete”. Before creating any rule, search for those event names to make sure you are getting them. Please note that this can considerably increase your EPS rate, so if you have a large environment and you’re enabling file-access audit consider enabling it in stages and observing your EPS rate.
- Create an offense rule that detect multiple file updates: A good threshold is 500 file updates in a minute. If you see more than 500 file updates in less than a minute, that’s an indication that there is an automated process updating your files (which may be a sign of ransomware).
If you have any mitigation system (such as IBM BigFix or McAfee EPO), you can even trigger a mitigation action to stop the ransomware. For example with QRadar you can send a “process kill” request to IBM BigFix, which will quickly login into the machine and kill the ransomware process.
It is important to note that QRadar is detecting ransomware through system behaviour. This puts QRadar in advantage if compared to regular signature-based anti-virus solutions, since we will be capable of detecting “zero-day” ransomware, which anti-virus solutions may not have signature for it.
This post is based on a very interesting video series called “QRadar Stopping Ransomware” by Jose Bravo. If you want to see step-by-step of how to configure your SIEM to stop ransomware, you should check out his youtube channel.
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.
One of the most interesting features introduced on QRadar 7.2.6 is the AppExchange, which allow you to install plugins (or also called, QRadar Apps) within just few clicks. Last week I came across a very interesting app called Health Check Framework (HCF) that allows you to perform health checks on your QRadar platform. What I found interesting is that the plugin brings you information that you would need to spend hours trying to find in the complicated QRadar log files or that you would need to be manually running scripts on the server. The plugin also creates for you real-time dashboards showing information around data compression, index file usage, EPS usage, and others.
The plugin, which can be easily installed through the IBM AppExchange, is developed by a company called Science Soft, you can check their app details in their website, but here’s the main features that caught my attention:
- HCF provides a 360-degree view of all essential characteristics of QRadar operation. It indicates deviations, which allows security officers to take urgent steps to fix them.
- QRadar health check can be both scheduled and started manually on demand, and its results are provided as a report.
- HCF assesses QRadar’s state with 60+ operational metrics that are configured into 25 health markers showing either ‘OK’ or ‘Failed’ and reported in an email to HCF subscribers.
- The reports describe how well the security system components are connected to QRadar and if there are security events that are not classified.
- Ability to create a system-health baseline using the called “health markers”, which are are like a snapshot of QRadar, allowing you to compare the health status over a period of time.
- ‘Failed’ markers are followed by recommendations on further actions.
The HCF app has been helping me to troubleshoot performance issues and helped me to proactively identify some issues (for example, that my server was using almost all of its RAM memory in a constant trend). The app also reduced the amount of time I spend analyzing the QRadar log files, so it may be useful for you to keep control of your SIEM environment and increase the ROI of your SIEM investment.
Since my last post several new features were introduced on QRadar. In the last couple of years, IBM is really trying to stay ahead of its competitors (and also trying to catch up and in some forgotten features). In this post I want to discuss about the new capabilities that I believe are significant improvements in the new versions of QRadar (7.2.5 – 7.2.7).
- Multitenancy: Probably the feature that all the SOC service providers were waiting for. Now it’s possible to have multiple clients in one single QRadar installation, meaning that if you monitor QRadar for more than one company now you can see all your clients in one single dashboard. This feature also allow you to assign a specific amount of EPS for each tenant, making it easy to control the SIEM usage for each client. There’s a lot of improvements with this feature, so if you want more information just check the official IBM video about this feature.
- Historical Correlation: Several times in the past I struggled with the fact it was not possible to apply a new offense rule to past events. I had to use several bash tricks to be able to replay logs. However, in the latest versions of QRadar it is possible to “replay” historical logs to figure out if your new offense rule happened in the past. IBM also has a good video about this topic.
- Deployment Editor: Finally IBM got rid of the java applet that managed the QRadar deployment. The new QRadar 7.2.7 allows you to manage your appliances through the web interface!
- Custom Action Scripts: This is a feature that can be powerful if well written or dangerous if misconfigured. It can be powerful because allow an offense to trigger any action on an external system, for example, allow you to write an script that creates a new firewall rule if an “brute-force offense” is observed. At same time this is a great feature, the pentester side of me can see a lot of potential vulnerabilities with this feature: basically you’re allowing an script to execute a command in a server based on an input of a log received from a non-trusted device, meaning that if someone properly craft a syslog, they may be able to inject a command into your script. It’s not easy, but it may be possible. So make sure you properly sanitize the inputs in your action script. Also, make sure you properly configure the access to the script file (since it probably will contain access keys to other systems)
- Data Obfuscation: This feature basically obfuscate sensitive data coming in the logs. For example: let’s say that your application use as user-id the credit card number of the customer (which is NOT recommended), then your application sends the user-id to QRadar as part of the logs of some action. With this feature, you can obfuscate the user-id to ensure your SOC team will NOT see the credit card number of your customers. Check this IBM video for more information, they discuss where you can apply data obfuscation and where you shouldn’t apply it.
There are several other new features in the new QRadar versions but the above are the ones that in my opinion really aggregated value to the tool! Check out the IBM channel on Youtube, you can find several videos about the new QRadar features! What is your favorite new QRadar feature?
Today I was trying to install device adapters into the new QRadar Risk Manager 7.2. After sometime struggling (due the “incomplete” IBM documentation) I decided to create this post to help you guys to configure a new adapter in the Risk Manager. First things first, for those who don’t know, the QRadar Risk Manager need an adapter for each kind of device that you want to monitor the configuration. It means for example, if you have few Checkpoint Firewalls and few Cisco routers that you want to monitor the configuration, you will need to install the Checkpoint adapter and the Cisco adapter.
So, here’s the step by step to configure the adapters:
– Install the dependencies: (Only necessary in the first time configuration)
- Download the rpm files: “ziptie-server” and “adapters-common” in your machine;
- Connect to the Risk Manager server using SSH.
- Create a new folder: /tmp/adapters
- Copy the downloaded files from your computer into the new folder
- Execute: rpm -Uvh ziptie_filename.rpm (use the ziptie file that you just transferred)
- Execute: rpm -Uvh adapterscommon_filename.rpm (use the adapterscommon file that you just transferred)
- Execute: service ziptie-server restart
– Install the adapter: (Repeat it for all the necessary adapters)
- Download the rpm files for your adapter, example: cisco_adapter.rpm into your machine;
- Connect to the Risk Manager server using SSH;
- Copy the downloaded files from your machine to the folder /tmp/adapters ;
- Execute: rpm -Uvh cisco_adapter.rpm (Change the filename for the adapter downloaded)
- Execute: service ziptie-server restart
After those steps your adapter will be ready for use.
If you want, you can check the official IBM documentation in this link, but I found some missing steps on it.
Hi guys, sometimes you’re not able to log in to the IMM web interface and check many information regarding event processor/ collector. If the GUI is down you can go through the following easy steps:
- ssh to the IMM,
- check if the server is running: system> ssl
- if it’s running try to reset the IMM.
- if the server is not running just turn it on: system> ssl se on