Some of you may have heard of DevSlop's Pixi-CRS pipeline.
This Continuous Integration (CI) pipeline ensures that developers receive feedback early and often on their Web Application Firewall (WAF) and their application behind the WAF.
The first Pixi-CRS pipeline was built on CircleCI.

DevSlop's goal is to learn about and teach security. And, of course, we also want to learn about pipelines and security in the cloud!
So, implementing the Pixi-CRS pipeline on cloud providers (such as Google Cloud Platform (GCP), Amazon Web Services (AWS) and Microsoft Azure) and as a GitHub Action was obvious.

But first, let's take a step back and see what problem the Pixi-CRS pipeline solves for us.

What is a Web Application Firewall?

Of course, a web application should be implemented securely. But we never have a guarantee that the code is 100 per cent secure.
A Web Application Firewall (WAF) is an additional layer of defense in front of a web application against attacks. It's not a silver bullet against all attacks, but it makes it harder to exploit an existing vulnerability in a web application. A WAF logs and inspects the HTTP traffic and blocks malicious traffic based on patterns or rules.

A very popular and widely used Web Application Firewall is ModSecurity with the OWASP ModSecurity Core Rule Set.

What is Pixi?

Pixi is one module in the OWASP DevSlop project. It is an intentionally vulnerable web application and API for learning about web application security. More information can be found in one of my earlier blog posts.

As the name suggests, Pixi-CRS is a combination of Pixi and the Core Rule Set.
What I particularly like about Pixi-CRS is that it combines two OWASP projects ❤: OWASP DevSlop and the OWASP ModSecurity Core Rule Set.

Problem

Web Application Firewalls can have so-called false positives. A false positive is a legitimate HTTP request or response that smells a bit like an attack, but is actually not an attack. These false positives can hurt in production if they prevent legitimate users from using the web application properly.

These false positives hurt even more in a DevOps environment where everything is fully automated and well-tested. In the end, a WAF is added to production without testing it! That's too late! The operator will probably turn off the WAF so that the user can work again. And that's very bad.

False positives can be tuned away, but to do this, they have to be discovered first.

Solution: Testing in CI Pipeline

If we have automated web application tests, end-to-end or UI tests in a CI Pipeline, we should add the WAF to those tests. And that's exactly what the Pixi-CRS pipeline does.

What is Continuous Integration?

Continuous Integration and Continuous Delivery together form Continuous Deployment. Continuous Deployment means that code changes are merged, built, tested and shipped to production very often.

Pixi-CRS CI Pipeline

The Pixi-CRS Pipeline is a Continuous Integration (CI) Pipeline that focuses on building and testing.
Every code change triggers a CI pipeline that performs the following steps:

• Start Pixi in a Docker container
• Start the WAF ModSecurity with the CRS in a Docker container in front of Pixi
• Loads ModSecurity Tuning rules (in case we have already eliminated false positives)
• Application tests directly against Pixi
• Application tests through the WAF against Pixi
• WAF test with a malicious string
• Test if WAF Logs from legitimate tests are empty
• Test if our malicious test string was logged

If no false positives occurred and the application tests were successful, the code change can be merged into master. We provide early feedback to the developer on false positives. This means that we always have Pixi in a deployable and runable state, even with a WAF (the CRS) in front of it.
Pixi-CRS does not have a CD portion and is currently not deployed anywhere.

Pixi-CRS Tests

The Pixi-CRS pipeline has web application tests that are used to test Pixi. The tests do the following:

• Register a user in Pixi
• Log in as this user
• Searches for a string in Pixi's search box
• Clicks "About"
• Clicks "My Profile" and changes Name
• Log out the user

Pixi-CRS goes to the Cloud

The first Pixi-CRS pipeline was built on CircleCI. A detailed description of this pipeline can be found in one of my earlier blog posts.

And now Pixi-CRS is going to the cloud.
We wanted to learn if we could also implement Pixi-CRS on Google Cloud Platform, Amazon Web Services, Azure Pipelines and GitHub Actions.
And we've been successful!

This was an intro blog post about the new Pixi-CRS cloud pipelines and beginning of a series.
In the next blog posts, I will show what Pixi-CRS looks like in the cloud: on Amazon Web Services, Google Cloud Platform, Azure Pipelines and as GitHub Actions...