How I integrated CloudGuard AppSec logs into various SIEM services

Netzer Shohet
CloudGuard AppSec Team

CloudGuard AppSec is a fully automated Web Application & API Security solution. It is powered by a patented machine learning engine which continuously analyzes users’ HTTP/S requests as they visit the website or API. The analysis includes the application structure and how users interact with the content in order to identify patterns and automatically stop and block malicious requests and bad actors.

Upon detection of events, triggers are set off, where the most common trigger is sending logs about those events.

While by default logs are sent to the Check Point cloud and can be seen through the Web Management interface for Cloud Guard AppSec, a security administrator can configure to send those events, on top of, or instead of this, to a syslog/syslog CEF server.

In this blog I wanted to show how I used this capability to send the events to common SIEM services.

How to Integrate CloudGuard AppSec logs into Sumo Logic

Prerequisites

Read the steps below before running them. Specifically look at Step 6. In this step you will be required to install a collector and there are several questions in this step regarding the collector’s location.

Step 1: Run the collection setup wizard

When browsing to Manage Data->Collection, it is possible to run the “Setup Wizard”

Step 2: Select “Integrate with Sumo Logic”

Step 3: Select “Your Custom App”

Step 4: Select “Syslog”

Step 5: Select a new collector and the operating system

In my example I used Linux:

Step 6: Set up the collector

This step is actually the only complex step as there are many possible architectures you can use.

• You might have your own syslog server from which you want to collect, or you might want to use the collector to be the “server” for the AppSec logs.
• If you do not have a syslog server already and just want to use the collector, then the location of the collector’s deployment is entirely up to you. But you will need to design the network connection to it so all relevant CloudGuard Appsec Gateways/Agents will have connectivity to it, in the relevant IP protocol and port which will soon be configured.

I did a very simple thing in this example — I used the installation command provided by Sumo Logic at this stage to install the collector on the very same machine as the agent (meaning, I’m going to configure the trigger to send the logs to 127.0.0.1).

Step 7: Configure protocol/port and additional settings

For protocol select UDP. For all other settings use the settings according to your needs:

This is the last step on Sumo Logic’s side, after which the actual set up takes ~15 minutes.

Step 8: Configure the Log Trigger to send syslog traffic to the collector’s location and port

As explained in the CloudGuard AppSec documentation for Log Trigger setup, edit your log trigger object or create a new one.
Then make sure to configure, in the “Log To” section, Syslog service settings, on top of or instead of the default “Cloud” option.

In my example, I installed the collector on the very same machine as the agent, so my logs are sent to the local host address:

Make sure the threat prevention settings on each of the relevant assets are using the Log triggered you created/modified. Edit each relevant asset via Cloud->Assets, go to the Threat Prevention tab and scroll down to the Log Trigger configuration:

Enforce policy and at this point logs should start being visible in Sumo Logic as well.
In my example I sent example attacks through my agent:

How to Integrate CloudGuard AppSec logs into splunk

Prerequisites

Read the steps below before running them. As with Sumo Logic, in this example I opted to simply install a “universal forwarder” as they are called in splunk, on the same machine as the agent itself, but you can opt for a different architecture.
A splunk server or an account in splunk cloud is also needed.

Step 1: Install a universal downloader

Follow the instructions for downloading a universal forwarder in your splunk server. The images below are from a splunk cloud trial license.

Step 2: According to documentation download and install the account credentials

This involves download a file using the “Download Universal Forwarder Credentials” button seen above, moving the file to a local /tmp folder, running an installation command according to the documentation and restarting the forwarder.

Step 3: Configure inputs

This step can be performed in several ways, from UI, to command line.
I simply configured a local $SPLUNK_HOME/etc/system/local/inputs.conf file with the following section (I chose a random UDP listening port, but you may use a different one):
[udp://5140]
disabled = false
connection_host=ip
sourcetype = syslog
index = appsec

After doing this, the splunk forwarder needs to be restarted.

Step 4: Configure the Log Trigger to send syslog traffic to the collector’s location and port

Just like the Sumo Logic example, and as explained in the CloudGuard AppSec documentation for Log Trigger setup, edit your log trigger object or create a new one.
Then make sure to configure, in the “Log To” section, Syslog service settings, on top of or instead of the default “Cloud” option.

In my example, I installed the collector on the very same machine as the agent, so my logs are sent to the local host address and my chosen port:

Make sure the threat prevention settings on each of the relevant assets are using the Log triggered you created/modified. Edit each relevant asset via Cloud->Assets, go to the Threat Prevention tab and scroll down to the Log Trigger configuration:

Enforce policy and at this point logs should start being visible in the splunk server/splunk cloud account as well.

As with the Sumo Logic example, we’ll see the same attack logs I used there:

How to Integrate CloudGuard AppSec logs into Microsoft Sentinel

Prerequisites

Read the steps below before running them.
You also need a Microsoft Sentinel workspace in your Azure account.

Step 1: In your Microsoft Sentinel Workspace, locate the CEF connector under Configuration->Data connectors

Step 2: Select “CEF” and open connector’s page

Step 3: Follow instructions and select a location for the collector’s agent

Similarly to step 6 in the “Sumo Logic” guide, this step is actually the only complex step as there are many possible architectures you can use.

• You might have your own CEF server from which you want to collect, or you might want to use the collector to be the “server” for the AppSec logs.
• If you do not have a CEF server already and just want to use the collector, then the location of the collector’s deployment is entirely up to you. But you will need to design the network connection to it so all relevant CloudGuard Appsec Gateways/Agents will have connectivity to it, in the relevant IP protocol and port which will soon be configured.

I did a very simple thing in this example, similarly to Sumo Logic — I used the instructions to install the collector on the very same machine as the agent (meaning, I’m going to configure the trigger to send the logs to 127.0.0.1).

Important note — The instructions below clearly state that the collector requires TCP traffic. However, it does listen to UDP/514 as well, and while the AppSec agent will support TCP options in the future — Using UDP was enough to make this work even now.

I simply ran the command on the Ubuntu machine I had that contained my existing reverse proxy and embedded agent.

Notes:

• When running the connectivity validation command, it also sends a test log.
• This is the last step on Microsoft Sentinel’s side, after which the actual set up takes ~20 minutes, only after which, the status will changed to “Connected” and you will see logs.

Step 4: Configure the Log Trigger to send CEF traffic to the collector’s location and port

As explained in the CloudGuard AppSec documentation for Log Trigger setup, edit your log trigger object or create a new one.
Then make sure to configure, in the “Log To” section, CEF service settings, on top of or instead of the default “Cloud” option.

In my example, I installed the collector on the very same machine as the agent, so my logs are sent to the local host address:

Make sure the threat prevention settings on each of the relevant assets are using the Log triggered you created/modified. Edit each relevant asset via Cloud->Assets, go to the Threat Prevention tab and scroll down to the Log Trigger configuration:

Enforce policy and at this point logs should start being visible in Microsoft Sentinel as well.

As with the previous Sumo Logic and splunk examples, we’ll see the same attack logs I used there:

Summary

CloudGuard AppSec allows forwarding logs to both CEF and Syslog Servers. SIEM services accept syslog/CEF traffic as inputs, therefore allowing a rather easy integration of CloudGuard AppSec to any existing SIEM services you might have.

This blog has shown simple examples of I managed to easily integrate my CloudGuard AppSec product to a variety of SIEM services and touches on the different options that can be taken for these integrations.