New QRadar 7.5.0 UP10 is published

Robert Rojek
2024-10-18
0 comments

A new version of QRadar 7.5.0 UP10 was published on 14 October 2024, bringing many new features, which I will summarize in this article.

Dark mode/Light mode

With the previous iteration of QRadar software, a significant change was introduced, bringing a dark mode as default for QRadar installation. This was not the best solution for some incompatible browsers as well as for some customers who preferred the older, long-term associated with QRadar, the light mode. Luckily in the UP10 developers gave the customers a chance to change the multiple times default theme and quickly switch from dark mode to light mode and vice versa. This menu is accessible from the User menu on the top right side of QRadar.

Parallel Patching

Parallel patching is a new feature for the patching process for QRadar. This feature introduces the ability to patch an entire deployment in a shorter period by patching all attached managed hosts simultaneously instead of patching each managed host one at a time.
Another aspect of this feature is the ability to copy or stage the patch SFS on each host in the deployment before beginning the patching process. This will help with setting up the deployment for patching without extra downtime.
This feature also introduces a new patch menu giving you the option to choose either legacy patching (the old sequential patching) or the new parallel patching. There are now 2 levels to the patching menu, The first level chooses what type of patching, legacy or parallel, and the next level displays options for the selected type of patching. NOTE: The patch menu is only available when running the patch installer from the console.

After choosing legacy patching the same patching menu that has been used for years will appear. It has not changed so it works the same as it did for many years. On the contrary, the Parallel patch menu gives 4 options which are:

Stage SFS on all hosts – this option gives the ability to copy/stage the patch SFS that is on the console to each managed host in the deployment in preparation for patching. This is optional only is not required to start patching the deployment but it saves downtime (especially in low bandwidth deployments).
Patch all hosts in parallel – this option will perform 2 tasks, the first task is to stage the SFS (if not done before) on all of the managed hosts and the next task is to start patching of the deployment. on running the patch right after. If the SFS is already staged on all the managed hosts then the console will just confirm. Once the SFS has been confirmed on all the hosts the console will start patching itself first. If the console patch fails for any reason the patching process will stop and require investigation, no further hosts will be patched. If the console finishes successfully then each managed host is going to start simultaneously.
Check patching status – choosing this option will display a high-level overview of each host with regards to patching.
View Live Report – this option will display the live report of the status of patching. This display will show all the hosts in the deployment and the percentage complete.
*) Exit

With a new way of patching in addition to old patching logs, which can be found in this location /var/log/setup-xxx/patches.log

there will be a new folder in the console /var/log/qradar_patch/ and subfolders for each MH containing the following files patch-report.log, report-updater.log and staging-report.json. Also, the command journalctl -u patch_report_updater -f can be used to check if anything is wrong with the patching and if it is progressing.

Apps changes and minimal v4 Base Image requirement

During patching, you may hit the following message Your current applications are using an earlier QRadar base image stream (v1, v2, or v3), which does not meet the default minimum QRadar base stream.
From UP10 the default minimum of the QRadar base stream is v4, which contains the Python 3.11 version. Older bases are deprecated, so to avoid the message upgrade all your apps to the latest version or remove those which are not actively developed.
For more information about ‘Minimum Permitted App Base Image Stream’, go to the IBM Support website.

Currently, QRadar is supporting a number of out-of-the-box apps, such as Pulse, Assistant, Log Source Management and Use Case Manager. From UP10 there is added to the set AWF (Analyst Workflow) application but for this reason, the minimum system criteria is system configuration should be more than 32 GB if customer apps are running on Console. This check will be skipped for apps running on appHost. Installation problems with the apps can be checked in /var/log/install_preload_content_cron.log

Resetting the response limiter

In UP10 the customers have an option for resetting the response limiter when they close an offense. This is a significant change and requested by many customers but it brings some consequences.

When you close an offence and the response limiter is not reset, then if any new offence is generated by that rule and the rule has a response to generate an event used to rename the offence, that will not happen because the limiter’s counter is not aware of this.

So you should change the value of the response limiter only if you understand what you are doing and you aren’t concerned with offence renaming.

This new variable was added to /store/configservices/staging/globalconfig/nva.conf and it controls the feature RESET_RESPONSE_LIMITOR = false

Dual Stack Networking

Dual stack refers to a system or network configuration where devices can handle both IPv4 and IPv6 protocols simultaneously. This allows for a smooth transition from IPv4 (the older protocol) to IPv6 (the newer protocol) as networks evolve, ensuring compatibility with both types of internet addressing. In UP10 was added feature to configure the DNS service as well as previously added network addresses.

In UP10 there is introduced the -ds flag in /opt/qradar/bin/myver script to indicate whether the console is dual-stack or not. Also, a new script is checking the MTU of the destination when the IPv6 host has been added to UP10. The MTU mismatch of source and destination could lead the host to time out due to jsch error. More information about the dual-stack appliance is available here.