QRadar in a Cloud World
No, I’m not talking about QRadar on Cloud (QRoC) or even running QRadar in a cloud environment. I’m talking about how to manage a QRadar system when a number of your log sources are sitting in the cloud.
QRadar was not built for a cloud world. You can feed basically any on-premise log sources into the SIEM via syslog, SNMP, JDBC, flat files, etc… there’s no shortage of ways to get on-premise logs into QRadar. Unfortunately it’s not that easy to send random cloud logs into QRadar. Especially if you’re expecting them to be parsed effectively.
What are the options?
QRadar supports a wide variety of cloud log sources out of the box. Leveraging these tools is really like magic sometimes, just a few configuration options and you’re rocking and rolling. But what if the cloud/SaaS tool you’re using isn’t supported out of the box?
The easiest way to get cloud logs into QRadar is through your cloud vendor’s native tooling. This means Azure Event Hubs or Security Graph API. Google Cloud Pub/Sub is also a supported option. You can also use AWS CloudWatch/CloudTrail… just be aware that CloudTrail is really hard on the EPS license. Tools like GuardDuty and Security Hub use processing on Amazon’s side to reduce the number of alerts coming into QRadar. There are trade-offs here too, but the general idea boils down to how much you trust AWS’s logic versus how much you want to pay for EPS.
But unfortunately not everything can be done this way. Take Duo Security for example: I had a client who wanted Duo logs integrated in 2017. We set up a Linux server on-premise and set up a Python-based log forwarder to reach out and grab the logs then format them as syslog and push them into QRadar. I had the same request from another client in 2019 and we decided to take another approach.
Custom Apps
Making a custom app for QRadar can be very easy (as I’ve detailed here). It also allows almost unlimited freedom for gathering, processing, and formatting logs. For the Duo app I built, the vendor needed a very specific authentication mechanism.
Generate the HTTP Password as an HMAC signature of the request. This will be different for each request and must be re-generated each time.
https://duo.com/docs/adminapi#authentication
Unfortunately this isn’t something you’re going to be able to do with QRadar unless it’s a supported protocol (it’s not) or you’re writing code.
As mentioned in my article about QRadar apps, this is easily done in the App Editor (note, this isn’t always the case… I needed Python 3 for one app I wrote, which can’t be supported in the App Editor).
Most of my QRadar apps have been under 100 lines of code. Even Duo (with their weird authentication mechanism) clocked in around 97 LOC. This stuff is simple! In fact, I’ve written a boilerplate that you can check out on my Github here.
Of course if you don’t have development skills on your team’s staff, you can talk to your IBM sales rep and ask for QRadar professional services to help out.
Disclaimer: I work for IBM professional services but the views expressed on this blog are my own and not the opinions of my employer. I also don’t work in sales so I don’t get any extra compensation if you call us for help.
