QRadar New Features (7.2.5 – 7.2.7)

Posted on Updated on

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?

Third party check engine under the right-click menu

Posted on

Today we’d like to share how you can easily add an extra plugin to your QRadar. This can be useful when you want to do deep investigations in a easy way, just using the right-click function. As an example, let’s add IPVOID (http://www.ipvoid.com/) to check source/destination IPs which can be found in a QRadar event.

 

In order to achieve it, follow below steps:

1. Open a SSH session to your QRadar main console.

2. Make a copy of the ip_context_menu.xml template to the QRadar config folder:
[root@my_radar]# cp /opt/qradar/conf/templates/ip_context_menu.xml /opt/qradar/conf/

3. Add your “new third party search engine” by editing the ip_context_menu.xml file:
[root@my_radar]# vim /opt/qradar/conf/ip_context_menu.xml

3. Add the following line in the ip_context_menu.xml file. You can change the parameters according with your plugin:
<contextMenu>
<menuEntry name=”IPVOID Check” url=”http://www.ipvoid.com/scan/%IP%/&#8221; />
</contextMenu>

4. Restart the tomcat service
[root@my_radar]#service tomcat restart

5. Done! Now you can use your plugin. It will appear under the right click, More Options->Plugins->IPVOID Check.

 

Installing a Device Adapter on the QRadar Risk Manager

Posted on Updated on

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:

[All the files mentioned in this post can be found in this link, or at www.ibm.com/support/fixcentral ]

 

– 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.

Checking if GUI is working on the IMM

Posted on

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

IMM Troubleshooting

QRadar and Big Data

Posted on

Today I was reading about the new QRadar integration with the IBM BigData solution. Instead of writing down here, I decided to share with you guys a very nice video that summarize the benefits of this integration.

 

(Part 1) QRadar Basics and Big Data

 

(Part 2) QRadar BigData Extension:

 

I hope you guys enjoy the videos. You can also check more from the author in his youtube channel.