top of page
Christopher Lutat

How you can integrate open-appsec logs into various SIEM services

open-appsec is a fully automated, open-source 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, and allows open-appsec to preemptively prevent against zero-days and OWASP-Top-10 attacks.


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 cloud (or logged locally in case of a local-only deployment) and can be seen through the open-appsec central management WebUI (provided as a SaaS service), a security administrator can configure to send those events, on top of, or instead of this, to a syslog/syslog CEF server.

This blog explains how you can use this capability to send the events to common SIEM services.


How to Integrate open-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 this example let’s use 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 open-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 open-appsec 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 (TCP could be used as well). 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 open-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 this example, the collector is installed on the very same machine as the agent, so the logs are sent to the local host address:

Make sure the threat prevention settings on each of the relevant assets are using the Log trigger you created/modified. Edit each relevant asset via Assets in the top menu, 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. Here are some example attacks that were sent through the agent:

How to Integrate CloudGuard AppSec logs into splunk

Prerequisites

Read the steps below before running them. As with Sumo Logic, in this example we pick the option 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 the documentation download and install the account credentials

This involves downloading 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. Simply configure 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, alternatively you could also use TCP): [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 open-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.

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 Assets in the top menu, 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 sent before:

How to Integrate open-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 open-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 open-appsec Agents will have connectivity to it, in the relevant IP protocol and port which will soon be configured.

Here a simple thing can be done, similarly to Sumo Logic — the instructions to install the collector on the very same machine as the agent can be used (meaning, we 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. So let’s make sure to use TCP in our configuration instead of UDP (open-appsec supports both options, TCP and UDP for syslog and CEF).

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

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 Assets in the top menu, 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, same attack logs as used before can now be seen:

Summary

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

This blog has shown simple examples of how to easily integrate open-appsec with a variety of SIEM services and touches on the different options that can be taken for these integrations.

 

open-appsec is an open-source project that builds on machine learning to provide pre-emptive web app & API threat protection against OWASP-Top-10 and zero-day attacks. It simplifies maintenance as there is no threat signature upkeep and exception handling, like common in many WAF solutions.


To learn more about how open-appsec works, see this White Paper and the in-depth Video Tutorial. You can also experiment with deployment in the free Playground.

Experiment with open-appsec for Linux, Kubernetes or Kong using a free virtual lab

bottom of page