We are pleased to announce that IBM Security and Zscaler have completed the Zscaler CloudNSS—QRadar integration.

With its completion any QRadar system can now ingest events from Zscaler's CloudNSS product. In collaboration with the IBM Security and Zscaler alliances teams QRadar development has architected and implemented a new data flow and configuration options to get your data from Zscaler's CloudNSS servers directly to your QRadar system. It leverages the existing out-of-the-box functionality of Zscaler's NSS DSM which was created as an integration with ZScaler NSS, the original on-premise version of Zscaler CloudNSS.  

 This blog post will walk through the technical details of the integration and provide a step-by-step guide, in parallel with the official documentation, on how to set it up. 

So grab a cup of tea or coffee and we can begin! 

Overview

High-level View 

At a high level this integration uses an encrypted API POST from the Zscaler CloudNSS server to the QRadar system to propagate the data. This is different from the existing Zscaler NSS product in that it required you had to have an NSS system on your network, and that system sent raw syslog data to the QRadar system on the same network. With the new Zscaler CloudNSS QRadar integration, any QRadar system can receive Zscaler CloudNSS logs, without the need of an on-prem Zscaler NSS system. 

Low-level View 

At a more detailed level, this integration uses QRadar's HTTP Receiver protocol to receive the API POST from Zscaler CloudNSS. This post includes a batch of several events which get delimited by QRadar on arrival and are ingested as single events into the pipeline. Two major elements were completed on the QRadar side – adding efficiency to the HTTP Receiver delimiting and caching logic, and unlocking the HTTP Receiver as a supported protocol of the existing Zscaler NSS DSM. Unlocking the protocol means rigorously testing the Zscaler NSS DSM with the HTTP Receiver and creating the documentation on all the peripheral points of interest involved in configuring it, for example in this case the ability to add custom certificates to the HTTP Receiver cert chain. Because Zscaler CloudNSS requires a public CA signed cert on the receiving end in order to properly set up the data flow, QRadar now officially documents the way to perform this action on your QRadar appliance as part of the configuration of this integration. 

Summary

We will create a public CA cert-validated connection from Zscaler CloudNSS to QRadar, send batched events over API POST calls, and QRadar will delimit them and parse them with the ZScaler NSS DSM, and the data is in! 

Materials & Equipment 

Documentation followed: 

QRadar Zscaler NSS DSM with HTTP Receiver documentation:
https://www.ibm.com/docs/en/dsm?topic=service-http-receiver-log-source-parameters-zscaler-nss 

QRadar HTTP Receiver documentation: 
https://www.ibm.com/docs/en/dsm?topic=options-http-receiver-protocol-configuration  

QRadar Setting up certificate-based authentication for HTTP Receiver 
https://www.ibm.com/docs/en/dsm?topic=options-setting-up-certificate-based-authentication-http-receiver  

Correct RPM versions 

First things first we'll ensure we have the updated HTTP Receiver and Zscaler NSS rpms installed in QRadar.  

If you are on QRadar 7.4.x, these are the minimum versions of the RPMs 

7.4.0-QRADAR-DSM-ZscalerNss-7.4-20220706124141.noarch.rpm 

7.4.0-QRADAR-PROTOCOL-HTTPReceiver-7.4-20220610135542.noarch.rpm 

If you are on QRadar 7.5.x, these are the minimum versions of the RPMs 

7.5.0-QRADAR-DSM-ZscalerNss-7.5-20220706124113.noarch.rpm 

7.5.0-QRADAR-PROTOCOL-HTTPReceiver-7.5-20220610135831.noarch.rpm 

Checking RPM versions:

We can perform this either via the UI or command line, so I will show you both ways.  

First option, UI:  

1. Navigate to: About -> Additional Release Information... 
2. Look for the RPM in the list. 

Second option, command line:  

rpm -qa | grep HTTPReceiver 

rpm -qa | grep ZscalerNss 

Downloading RPMs:

Zscaler NSS DSM if you’re on 7.4 

https://www.ibm.com/support/fixcentral/swg/downloadFixes?parent=IBM%20Security&pro[…]rpm&includeRequisites=1&includeSupersedes=0&downloadMethod=http 

Zscaler NSS DSM if you’re on 7.5 

https://www.ibm.com/support/fixcentral/swg/downloadFixes?parent=IBM%20Security&pro[…]rpm&includeRequisites=1&includeSupersedes=0&downloadMethod=http 

 HTTP Receiver if you’re on 7.4 

https://www.ibm.com/support/fixcentral/swg/selectFixes?parent=IBM%20Security&product=ibm/Other+software/IBM+Security+QRadar+SIEM&release=7.4.0&platform=All&function=fixId&fixids=7.4.0-QRADAR-PROTOCOL-HTTPReceiver-7.4-20220610135542.noarch.rpm&includeSupersedes=0&source=fc  

HTTP Receiver if you’re on 7.5 

https://www.ibm.com/support/fixcentral/swg/selectFixes?parent=IBM%20Security&produ[…]ver-7.5-20220610135831.noarch.rpm&includeSupersedes=0&source=fc  

Method: Set up the Log Source 

First step - set up the log source. A log source is the conceptual mapping of a log source type (DSM) and a protocol to a log source identifier (hostname or IP). This allows QRadar to route data from that host through the proper ingestion and normalization. 

We will follow this documentation: https://www.ibm.com/docs/en/dsm?topic=service-http-receiver-log-source-parameters-zscaler-nss  

1. Navigate in the UI to Admin -> Log Sources 

2. Create a new Log Source with the Zscaler NSS DSM and the HTTP Receiver protocol, following this guide: 

https://www.ibm.com/docs/en/dsm?topic=service-http-receiver-log-source-parameters-zscaler-nss  

3. Protocol configuration: 

Note that you will add a message pattern of .*zscaler-nss 

Once you’ve created the log source, go to the Admin tab and deploy. 

Add certs:

This step confounded me on my first go because I didn't include all the certs in my cert chain - my particular cert from Let's Encrypt included a private.key and ca-bundle.crt which needed to be concatenated together to produce the full cert chain. This may or not be the case for you but I've included this section in order to highlight a way to show what your cert config looks like when correct, and also when incorrect.  

Here is the documentation to follow: 

https://www.ibm.com/docs/en/dsm?topic=options-setting-up-certificate-based-authentication-http-receiver 

Note that before you even begin it mentions ensuring your PKCS12 file has all the certs necessary. Here’s how I concatenated mine: 

cat certificate.crt > chain.crt 
cat ca_bundle.crt >> chain.crt 

After it's concatenated you can use it as chain.crt in command #3 of the docs, and the rest of the steps are nice and straightforward.  

Once you complete the steps, to allow the certs to take effect, disable and re-enable the log source. 

Verification 

Ok so that was a lot of fun, but how can we check our work?

You can check whether the HTTP Receiver is listening on the port you set it up by using the openssl command. Note that you will need to use the Listen Port from the Protocol configuration. Mine as you can see above is 12469.

openssl s_client -connect localhost:12469 

What does this return when you haven’t set it up properly?  

Here are two examples of incorrectly set up certs: 

What does it look like when it is set up properly? 

Here is an example of a correctly set up cert. 

After this, you should be ready to perform the test on the Zscaler side.  After you setup the Zscaler side, give it a few quick moments and you'll soon see the events flowing into QRadar's Log Activity screen. Tada! Happy correlating!