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