Simplifying web application security with the Core Rule Set v3

The Problem: Web application security is hard

It's also mostly unavoidable (anyone who had to run around patching Log4Shell-vulnerable systems recently can tell you that). A simple, universal web security solution simply doesn't exist. Rather, a multi-layered defense in depth approach is best: with multiple, independent layers of defense in place, even if one or more layers should fail there are still other defensive measures in place to block attacks and raise the alarm.

A WAF is one such defensive layer. A WAF isn't a magic bullet, but, as part of a defense in depth strategy, a properly configured WAF should catch and stop common, everyday attacks. It raises the bar for attacking your web service and stops you from being 'low hanging fruit' for attackers: they'll quickly move on to the next target (maybe your competitors?) in search of an easier time. And with the simple attacks taken care of, a WAF frees up your time so that you can focus on more sophisticated threats.

Any web service exposed to the public internet should arguably have at least a baseline level of WAF protection in place. The problem is, WAFs have historically been difficult to configure properly, due to the complexity of WAFs themselves and the web services sitting behind them. An improperly configured or untuned WAF will suffer from false positives (false alarms) where genuine transactions are blocked by the WAF in error.

Why are false positives a problem?

1. Poor user experience: Genuine users being blocked in error leads to complaints. Complaints lead to pressure from management to disable or throw out the WAF.
2. Alert fatigue: If a WAF has a reputation for reporting false positives then its alerts may be ignored, leading to real attack alerts being ignored…
3. Regulatory and compliance issues: False alerts generate log data, which can contain usernames, passwords, payment card data, and more.

Our Solution: Simplifying WAF configuration

I've been working hard over the past nine months spearheading the biggest overhaul of our WAF offering to date, landing as part of our 8.6 product release. Part of that overhaul included adding a new default WAF rule set: the OWASP ModSecurity Core Rule Set v3, or "CRS 3" for short.

CRS 3 lowers the barrier to entry for configuring a basic level of WAF protection. This makes securing a web service with a WAF easier than ever before. CRS 3 is also up-to-date and actively maintained, regarded as the de facto standard for WAFs.

The rest of this blog post covers the key concepts of CRS 3 and how they'll make your life easier. For full details, refer to the entirely re-written WAF chapter of our Administration Manual.

Life before CRS 3: A steep learning curve

Before we added CRS 3, our previous WAF rule set featured a little over 240 rules. Out of the box, all 240 rules were turned on, all the time, always, unless you explicitly turned some of them off. Even rules that were prone to causing false positives were enabled by default. This was like starting on "hard mode". WAF administrators were thrown in at the deep end, having to tame every single rule, even the ones that were known to be "twitchy", right out of the gate.

Introducing 'Paranoia Levels'

CRS 3 introduces a completely new concept to solve this problem. Rules are grouped into paranoia levels, roughly based on how likely they are to cause false positives. This means you can start off with just a solid base set of rules enabled, which are unlikely to cause problems: this is paranoia level 1, "easy mode". The more fragile, complex, and twitchy rules are off by default: these are consigned to paranoia levels 2, 3, and 4, with the most difficult rules of the whole bunch living at paranoia level 4. This approach leads to a dramatic reduction in false positives, making it much quicker and easier to get a working, usable, and useful WAF in place.

By the numbers: Rule set false positives

To get an idea of how our previous default rule set behaved compared to our new CRS 3 rule set, we put our WAF gateway in front of two common web applications and passed genuine, non-malicious testing traffic through it. This meant that any WAF rules being triggered, and hence increasing the anomaly score, were false positives.

Lower scores are better, with the ideal case being a zero score (which equates to no false positives). All four paranoia levels ("PLs") of CRS 3 were tested to create a full comparison. Note that the WAF gateway was completely untuned to give fair and unbiased results.

Key takeaways from this data:

• CRS 3 at paranoia level 1 experienced very few false positives.‌‌
  This means it's easy to put in place, with only a handful of false positives to tune away.
• The previous default rule set wasn't great on false positives.‌‌
  Compared to CRS 3 at PL 1, something as simple as submitting credentials caused rules to be set off left, right, and centre in the previous rule set.
• Paranoia level 4 offers a bonkers level of security.
  ‌‌For web services that need 'nuclear power plant' level security, paranoia level 4 has you covered. It catches many more attacks than the previous default rule set, although it requires an investment of time to properly tune it to make it usable.

We're working upstream and contributing back

An unexpected side effect of the project to add CRS 3 to our WAF offering is that I've become a developer for the Core Rule Set project itself. This means that if our customers encounter problems with rules in CRS 3 (e.g. unexpected false positives) then we can fix the rules upstream in the CRS itself so that the issues don't reoccur, rather than just plastering over them. This is a unique advantage to working with Loadbalancer.org, thanks to our strong ties and participation in the free and open-source software community.

How do I get CRS 3?

Starting with version 8.6 of our product (out now), CRS 3 is the default rule set for all new WAF gateways. These can be created by navigating to Cluster Configuration > WAF - Gateway:

There are two new options available when Modifying a WAF gateway:

It's possible to select the rule set to use, either CRS 3 or the legacy rule set, as well as the paranoia level to use (only relevant for CRS 3 WAFs).

For full details, refer to the entirely re-written WAF chapter of our Administration Manual.

How do I use and configure CRS 3?

We have a wide range of resources available to help.

Our Administration Manual contains lots of CRS 3 specific information, as well as guidance on WAF tuning, and should be your first port of call.

Our blog post on How to train your WAF remains relevant and walks through the process of using and configuring a WAF gateway. I'm hoping to produce an updated WAF configuration blog post in the future, so watch this space.

We have a map of the Core Rule Set which can be downloaded as a PDF file from our website. It serves as a useful and searchable visual overview, showing each rule along with its key information.

If you run into false positives then refer to the thorough advice and examples on WAF tuning and writing rule exclusions in our Administration Manual, as well as the guidance in the WAF training blog post mentioned above. Rule exclusions will allow you to tune away false positives. If you're still having trouble at paranoia level 1 then our support department will be able to help.

We offer WAF training if you or your team would like a structured session to learn how our WAF functionality works and how to configure it. Get in touch if you'd like more information on this.

Finally, we offer WAF consultancy. We can share our knowledge and experience to help with everything from resolving specific issues, to high paranoia level deployments, to carrying out an entire WAF deployment and configuration from start to finish. Get in touch if you'd like more information on this.

Future work

Our 8.6 product release with its overhauled WAF is not the end of the story! We have 101 ideas for enhancements and new features to keep improving our WAF offering. Some of the ideas we're investigating include:

• Easy statistics
• Enhanced logging (useful for web services that need to be fully audit-able)
• Tools to ratchet up to the next paranoia level while in production, with no downtime or disruption
• Substantial speed boosts, particularly for HTTP requests with large bodies (e.g. file upload functions)
• Support for a single, unified approach to tuning ("phase 1 rule exclusions")

In addition to this, I'll be continuing my work upstream on the CRS itself. We're currently hard at work on the next release of the rule set, as well as completely rewriting our documentation to make CRS accessible to the widest audience possible.

Final Thoughts

Web application security is a complex and ever-growing field. Our refreshed WAF functionality makes it easier than ever before to start securing web services with a baseline level of WAF protection. Our new and simplified rule set, easy point and click web interface, and expert support and consultancy all work to simplify the process, from planning and deployment to production.

If you've been thinking about putting a WAF in front of your web service, now might be the time to try!