Monitoring Software-as-a-Service (SaaS) cloud solutions with QRadar

Posted on Updated on

One of the big advantages of having a Software-As-A-Service (SaaS) solution is the fact you don’t need to worry about infrastructure issues, such as patching, network availability, and etc. Also, most of the companies assume that all the security aspects of the solution will be handled by the vendor. Indeed, the vendor is (or should be) responsible for ensuring their system is secure, but it’s important to note that we should still monitor the SaaS solution for hacking attempts, which can be done through QRadar.

Picture this: imagine you have your website on wordpress, you pay wordpress as a service so you don’t need to worry about patching or updates. In theory, the wordpress team also monitors if someone tries to perform an attack against your site (for example, a SQL injection). But let’s say a malicious actor finds out the password of one of your wordpress users and creates a backdoor account for later exploitation. It wouldn’t be flagged by the wordpress security team (since it’s just a new user being created). That’s where QRadar can add value. If you integrate your wordpress with your QRadar solution, you would be able to generate an alert to your system administrator when a user is created or even correlate this event with other events such as pages being modified.

The easiest way to integrate your SaaS with QRadar is through email alerts from your SaaS solution. Let’s take the WordPress example and put it into a step-by-step:

  • Install the WordPress “Security Audit log” plugin
  • Create a mailbox to receive the alerts
  • Create a script that reads your mailbox and saves into a file. For example, you can modify this script to achieve that.
  • Create a custom DSM parser that interprets the file generated by the script above.
  • Create a log source on QRadar that monitors the file created by the script mentioned on step three. Use the custom DSM on this log source.

The implementation may require some time in the first time, but after setting up your first SaaS it will be trivial to set up the second one (since you will already have the mailbox set up and the script that reads the file). The same step by step can be adapted for a number of other SaaS services, such as: Dropbox, Gmail, Office365, Salesforce, AWS Cloudtrail and CloudWatch, etc…

Some of the events that can be interesting for us: New accounts created, change on security settings, login out of business hours, bruteforce attacks, configuration changes, etc.

Monitoring your SaaS solutions will put you one step ahead, ensuring that even applications on the cloud are being monitored and secure. Remember, even the server not being in your datacentre, the data in a SaaS application still yours.


Monitoring Cloud Servers with QRadar

Posted on Updated on

Cloud computing is an inevitable upward trend. Companies are looking for all the benefits cloud computing, such as cost effectiveness and scalability, but they may be neglecting the need of event monitoring in a cloud environment.

Configuring a SIEM solution to collect events from servers in a cloud environment may be simpler than you think. Cloud servers are still servers, meaning that they produce logs and events as any in-house server. In this post we will be discussing few strategies and architectures to consider when planning a QRadar implementation with servers in the cloud.

The first scenario is when you have just few servers in the cloud (less than 15% of your environment, or less than 500EPS coming from the cloud). A easy approach for this scenario can be simply configuring your cloud servers to send logs to your existing in-house QRadar collector (Figure 1). This can be accomplished by using a VPN between your cloud environment and your datacentre, or by configuring your firewalls to allow your cloud servers to send logs directly to your in-house collector. The benefits in this case are the fact that is a very easy setup and there’s virtually no costs. The downside on this design is that if your server generate a high number of events, your firewall/VPN could be overloaded.

Figure 1: Cloud servers sending logs directly to internal SIEM collector
Figure 1: Cloud servers sending logs directly to internal SIEM collector

The second scenario is when you have a substantial amount of servers in the cloud (between 30%-40% of your environment, or less than 5000 EPS). In this case, if you try to send all your events directly through a firewall or VPN you may overload the border network devices of your environment. The recommended approach in this case would be implementing a virtual collector/processor in your cloud environment (Figure 2). The cloud servers would send logs to your virtual collector/processor, which will parse the data locally and compress it before sending to the in-house SIEM collector.  This architecture benefits from the fact that you will have an increased EPS capacity. Also, if your VPN dies or if the network is unstable you don’t lose events due to the fact the collector buffers the logs locally. In other hand, this architecture will have an extra cost (the additional collector) and, even with the traffic being compressed, it still may affect your firewall/VPN performance in case you’re monitoring a large quantity of servers.

Figure 2: Virtual collector in the cloud.
Figure 2: Virtual collector in the cloud.

The third scenario is when most of your servers are in the cloud. In this case, a good approach would be having QRadar collectors (or even your whole QRadar infrastructure) deployed on the cloud, as seen on Figure 3. In this way, your border network devices will not be overloaded by logs sent from cloud servers to your internal SIEM. A similar approach would be having “QRadar as service”, which is a service from IBM where all the SIEM infrastructure is taken care by the IBM team. The advantages of having SIEM as a service is that you don’t need to worry about the SIEM maintenance and there’s little to none setup effort. The disadvantages is that your data will be stored in the IBM cloud environment, which for some companies may not be adequate.

Figure 3: Cloud SIEM solution or QRadar as a Service Architecture.
Figure 3: Cloud SIEM solution or “QRadar as a Service” Architecture.

Those are the three most common approaches when monitoring cloud servers with a SIEM solution. It is important to remember that each case is a case, meaning that each company should analyse their current and future environment before designing a SIEM implementation. You may find that a combination of the presented approaches may suit best your needs. The most important thing is remembering that monitoring servers in the cloud is as important as monitoring in-house servers.

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 ( 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:
<menuEntry name=”IPVOID Check” url=”; />

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 ]


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

Windows Desktops Log Collection – Methods Comparison

Posted on Updated on

Hi folks! I’m glad of receiving good feedback from you guys! The topic of this post was one recent request from our followers, asking about what the best way to send windows logs to QRadar is. As you can imagine, there’s no best solution, it depends on what kind of environment we have. So to reply this question as simple and short as possible, I created the following table comparing some log collection methods.


To get more information about the Snare Agent, you can check out the vendor website. To get more information about the another two collection methods, you can check out our post about configuring log sources and the official documentation in this another post.

Do you have any question or suggestion? Let us know in the comments!

Configuring the Log Sources

Posted on Updated on

When implementing a large QRadar environment we can face several types of log sources across the network. QRadar support more than one hundred type of devices out-of-the-box and can integrate with any another log source using customized parsers. The log source parsers are known in QRadar as Device Support Modules (DSMs).

A personal recommendation to integrate log sources with QRadar is: always use syslog when it is possible. Why? Basically syslog is the standard log protocol for many devices, and QRadar can easily collect, identify and receive logs using this protocol. The syslog typically uses UDP connections, so make the log collection more fast and with almost zero latency. Make sure that all the firewalls of your environment allow traffic to QRadar in the port 514 (default syslog port).

IBM provide a good documentation explaining thorougly how to configure each type of device to send logs to QRadar. You can find the DSM configuration guide in the following link:


Do you have another tips to configure your devices? Share with us!