Understanding Acquia Edge powered by Cloudflare’s OWASP Core Ruleset

February 22, 2024
5 minute read
Like 1

Dislike 0

In this document we will be covering the Acquia Edge powered by Cloudflare OWASP Core Ruleset.

What is OWASP?

To better understand Acquia Edge powered by Cloudflare OWASP ruleset we should first cover what OWASP is. The Open Web Application Security Project, or OWASP, is an international non-profit organization dedicated to web application security. OWASP requires all of their materials be freely available and easily accessible on their website. Making it possible for anyone to improve their own web application security. The materials they offer include documentation, tools, videos, and forums. Perhaps their best-known project is the OWASP Top 10.

Acquia Edge powered by Cloudflare Managed Rulesets

Inside of your Acquia Edge powered by Cloudflare application under the Security -> WAF you will find the Managed Rules section. WAF Managed Rules allow you to deploy pre-configured managed rulesets that provide immediate protection against multiple types of threats. These managed rulesets are regularly updated by Cloudflare to defend customers against new and emerging threats. You can adjust the behavior of specific rules in these rulesets, choosing from several possible actions.

Overview of OWASP Core Rule Set

The Acquia Edge powered by Cloudflare OWASP Core Rule Set is Cloudflare’s implementation of the OWASP ModSecurity Core Rule Set (CRS) as part of their WAF Managed Rulesets.

The Acquia Edge powered by Cloudflare OWASP Core Rule Set is designed to work as a single entity to calculate a threat score and execute an action based on that score. When a rule in the ruleset matches a request, the threat score increases according to the rule score. If the final threat score is greater than the configured score threshold, Acquia Edge powered by Cloudflare executes the action configured in the last rule of the ruleset.

Configuration

The OWASP Core Rule Set Has Three Available Score Thresholds:

Low: 60 and Higher
Medium: 40 and Higher
High: 25 and Higher

Most customers are comfortable with a Low and Medium Threshold to start off with.

Configuring a Low threshold means the CRS rule won’t trigger its action until the threshold value reaches 60 or greater. This means that, when using a Low threshold, more rules have to match the current request for the managed ruleset to perform the configured action (the request threat score is the sum of the individual scores of rules that match).

Each rule in the managed ruleset is associated with a certain paranoia level (PL). Paranoia levels vary from PL1 to PL4. Higher paranoia levels provide increased protection, but can cause more legitimate traffic to get blocked due to false positives.

Most customers are comfortable using a PL1 or PL2 paranoia level as going any higher causes them to have to write more skip exceptions for their applications.

Skip exceptions are a new feature of the new Managed ruleset that allows you to skip all the rules or just specific rules that are not needed for your applications. You can create a skip exception by clicking on the “Add Exception” button under the Managed Rules tab.

Understanding Anomaly Scoring

Anomaly scoring, also known as “collaborative detection”, is a scoring mechanism used in the Core Rule Set. It assigns a numeric score to HTTP transaction requests, representing how ‘anomalous’ they appear to be. Anomaly scores can then be used to make Action decisions.

Below is a visual representation of an HTTP request going through the system and being scored by multiple rules. Each request it is assigned a threat score based on its total score after it makes it through the system. The figure below is meant to visually represent how an HTTP Request would go a score of 0 in the beginning to a total of 7 once processed by the Ruleset.

“949110: Inbound Anomaly Score Exceeded”

When reviewing the security events in Acquia Edge powered by Cloudflare for Managed Rules you might see the following: “949110: Inbound Anomaly Score Exceeded”. While this looks like a normal rule that was triggered by either the Managed Rule or OWASP Rules, it is actually a flag used to indicate if the threat score that you set was exceeded by the different traffic events that occurred.

This flag will take precedence over the selected actions of the individual rules and will respond with a block as necessary.

Since this is not a rule, searching for “949110: Inbound Anomaly Score Exceeded” in the list of OWASP or Managed Rules it will not turn up any results.