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.
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!
We already discussed about how configure log sources, and how configure QRadar to receive the logs. Let’s say that everything is ready, you are in front of the customer, and the logs doesn’t show up, do you know how to troubleshoot it? Here is some quick troubleshooting tips, that can help you in those situations:
- Verify the connectivity between the log source and the QRadar collector:
- You can simply ping from the log source to the collector;
- By default, the IP-Tables from QRadar drop pings, so you will need to stop the iptables process in the QRadar collector. You can do it opening the terminal (or ssh) in the QRadar and using the following command:
services iptables stop ;
- If you cannot even ping the QRadar server from your log source, the issue is the network;
- Don’t forget to restart the IPtables after testing, just use the following command:
services iptables start ;
- Verify the firewalls between the log source and the QRadar:
- The firewalls should allow the ports used to collect. For example, for collecting syslog, the firewalls should allow the port 514/UDP;
- If you have no access to the firewall, a simple way to test the firewall is using the telnet command from the logsource to the QRadar: telnet [IP] [PORT]
Example: telnet 10.1.1.1 514
- If the telnet doesn’t work, some firewall is dropping the packets on the specified port, you should ask for a firewall rule allowing the traffic;
- Verify the flows coming in the QRadar collector:
- You can use the command tcpdump in the QRadar to verify if the packets are being received in the QRadar;
- Syntax: tcpdump -i [INTERFACE] src host [IP-LOGSOURCE] port [PORT]
- Example: tcpdump -i eth0 src host 10.2.2.2 port 514
- If nothing shows up, there is some network issue dropping the packets or the log source is not properly configured;
- Verify the QRadar Logs:
- The QRadar logs are stored in the following folder: /var/log/
- The main log is named qradar.log
- You can simple access and monitor the log using the following command: tail –f /var/log/qradar.log
- You can verify the current EPS using the following command:
tail –f /var/log/qradar.log | grep ‘Events per Second’
I hope this post help you guys to troubleshoot collecting problems on QRadar. If you have any question or suggestion, please leave us a comment!