The Security Rules Engine – A Glimpse Into Shield’s Future

We want to tell you about Shield’s new Security Rules Engine.

The new Security Rules Engine is the new foundation for how Shield will handle security for nearly all WordPress requests.

This article will outline what brought this about, what the Rules Engine is and does, and how it will inform future development and our approach to WordPress Security.

The Challenge Of Ever-Expanding WordPress Security

We’re all familiar with how Shield, and every other WordPress security plugin, offers security.

You get lots of configuration options, along with tables, charts, and notifications, to help you monitor the how well your WordPress site is being protected.

This works well for the most part.

But this approach has always had a particular challenge, one that we’ve been battling with from day one: how can we create a WordPress Security system that handles all the current threats we face, and at the same time be versatile enough to take on new and emerging threats.

It’s a huge challenge.

Just add more configuration options to let us switch on the new features! I hear you say…

That’s not a scalable solution. But let me give you a few examples to help think about this.

Example #1

There is a potential leak for WordPress Author usernames using the ?author=query within WordPress.

Shield provides a feaure to prevent exploitation of this leak, and of course its associated configuration option to switch it on or off.

What happens when there’s another “leak” discovered, or feature you want to lock-down (think Application Passwords)? Do we provide an option for that too?

And when another one emerges?

And another?

You see my point.

It’s not practical to keep providing options for every possible threat ever. There are a few reasons for this:

• Usuability. Shield already has numerous configuration options, there’s a limit to what we can add.
• Admin Overload. 1 more option isn’t just 1 more option. Each option is multiplied across all the sites you manage.

Let’s look at another example.

Example #2

Some WordPress admins don’t like certain web crawlers to access their sites – Yandex, for example. Perhaps the site owner doesn’t have any interest in serving Russian consumers.

But another site owner does want to allow Yandex. Do we provide an option to allow/block Yandex?

What about SemRush?

What about Ahrefs? And Yahoo!?

And so on…

Yet another configuration option.

Example #3

Bad user agents. Someone has discovered that their site gets malicious requests by bots with particular user agents.

They want to block all requests by the bad useragents they’ve discovered.

One admin doesn’t want to block the IP outright, but instead increment offenses.

Someone else wants to increment by 2 offenses, another by 3 offenses.

To handle this scenario, you’d need several different configurations within the plugin:

• an option to provide user agents to block
• an option as to whether to increment offenses or block
• an option to specify how offenses to increment by

You can see this problem beginning to emerge with our Bot Signals options here:

This screenshots highlights a perfect example of where complexity leads to configuration bloat. A failed login, and failed login with an invalid username, are practically the same thing, but we’ve had to provide 2 separate options, each with 5 different cases.

But even then, it still doesn’t cater to all possible scenarios.

The Solution: Shield’s Security Rules Engine

What if, instead of an infinite set configuration options, you could create a list of “rules” which would be applied to every request, and when a request triggers the conditions of any given rule, the consequences defined for that rule are applied.

The rules would basically be a series of statements like: “IF a request looks like … THEN do this to the request … “

Rather than have to wade through pages of configuration options, you’d have a single list of rules that apply to your sites.

Each rule would consist of:

• A Condition, or set of Conditions (e.g. If the request is accessing the XML-RPC endpoint…?)
• A Result/Consequence (e.g. Then… kill the request and permanently block the IP address)

It sounds simple in theory, but it’s actually a very complex system to build.

But the flexibility and power is like nothing else.

What Are The Advantages To The Rules Engine?

We wouldn’t be advocating using the Rules Engines if we weren’t absolutely convinced it’s the better approach.

Here are some reasons why a Rules Engine is superior to infinite pages of configuration options:

#1 Unbeatable Flexibility For The Security Admin

A rules engine that can take any condition and apply any result, can do anything you want it to do – i.e. it can do anything that any particular WordPress admin wants it to do.

• One admin may want to block a particular request, but not block the IP altogether.
• Another admin may want to increment by 3 offenses
• Another admin may want to redirect elsewhere
• Another admin may want to display a captcha
• Another admin may want to send a notification email
• Another admin may want to do any combination of these…

There’s no way to cater to all of these scenarios with static options.

But with a flexible rules system, you can do anything you want.

#2 Easy Import/Export/Sharing of Rules

Currently it’s quite easy for the admin to import and export options between WordPress sites running Shield.

It’s not as straight forward, however, to select to include or exclude those options. It’s doable, but it’s not entirely user-friendly.

Each Rule is a clear logical directive: IF … THEN … and importing/exporting/transfering rules is more practical for the admin.

Not only this, it would theoretically be possible for admins to share their rules with others.

And, most exciting of all, we could build and distribute “Community Rules” to all sites via ShieldNET. This way we can provide new protections quickly by. Instead of releasing a plugin update with new configuration options, we just publish new rules and sites can download and apply them automatically.

#3 Easier Troubleshooting and Request Handling Analysis

Imagine you can track a single request and watch how it progresses through the Rules Engine. You can see where it passes by or where it gets caught and why, and then see how the rule handled the response.

We get similar visibility with the Audit Trail/Activity Log, but again it’s static and dependent on the static configuration options within the plugin.

We also envisage being able to trigger tests more easily – you could construct a test request and watch how the engine would assess it.

What Is Required To Get The Rules Engine?

With ShieldPRO 15 the Rules Engine is already here. It doesn’t offer everything we’ve outlined above, as it’s only the first stage of its introduction.

There are many different components to build in this system, and we’ve started the following:

• Rules Compiler
• Rules Executor
• Rules Conditions Processors
• Rules Consequences Processors

This means we’ve been able to take many of the existing features within Shield and translate them automatically (using the Compiler) to the new Rules Engine each time you update your configuration. With Shield v15+ much of the processing for IP blocks, Firewall blocks etc. is now done by the Rules Engine.

Over time we intend to move as many features/options as possible over to Rules. Once we’re satisfied with it, we’ll provide the ability add entirely custom rules.

Shield’s Rules Engine Summary

We’re really excited about the direction Shield is taking and ability to scale up security handling with a flexible, modern Rules Engine. The potential for improvements for everyone is huge.

We have a lot of work ahead of us to get there but we’re up to the challenge!

If you have any questions or suggestion, or if there’s anything that’s unclear, please do let us know in the comments below!