Virtual patching is a security strategy that involves applying protective measures to the WordPress application without modifying any of the source code (core/plugins/themes). Virtual patches aim to provide a real-time response and are specific to individual security vulnerabilities.
This is specifically useful in enterprise environments where Software Development Life Cycle (SDLC) is dictating how and when updates (including security updates) are released to production.
This week, let’s discuss what virtual patching is and isn’t and why it’s considered one of the most important security measures every WordPress website should get right.
PS! Few days ago, I did a live presentation about this topic at StellarWP academy, which you can watch here: https://academy.solidwp.com/event/virtual-patching-instantly-fix-vulnerable-plugins-for-wordpress-sites/
It’s actually all about threat intelligence
Every virtual patch is custom made for a security vulnerability. To make this even possible, one would need to a) know about the vulnerability’s existence b) know exactly how the vulnerability behaves c) know if and where the vulnerability exists in customer website.
Once these conditions are met, it’s possible to accurately mitigate a security vulnerability on an affected website. However, the most important part is actually to deploy virtual patches and mitigate vulnerabilities before the hackers have been able to launch mass-exploiting campaign against every website online.
To make this happen, some of the most valuable cyber security companies such as Crowdstrike invest heavily into threat intelligence and counter-adversary operations to make sure they can deploy mitigation rules to their customers before they get hit.
Keep in mind that speed and accuracy is the most important factor of vulnerability mitigation. Try to filter out companies who claim to do virtual patching, but don’t do any vulnerability research or threat intelligence on their own.
How does virtual patching actually work?
This depends a lot on the programming language and what kind of applications are being protected. It also depends on the implementation of the vendor who is offering such service.
I can share how Patchstack does this.
As mentioned above, it all starts from the threat intelligence. We very detailed security reports from out bug bounty program, via our mVDP partners and through our internal threat intelligence tools.
Once a vulnerability is validated, we test the PoC and assign a Patchstack Priority score system. All “low priority” vulnerabilities (which are trivial and unlikely to be exploited) will be published immediately on our public vulnerability database, while all high and medium priority vulnerabilities go to a virtual patching stage.
Virtual patches are JSON based security rules which can include different instructions. Let’s look at a an example of a virtual patch that is mitigating a SQL injection vulnerability.
By analysing the security vulnerability, we’ve noticed that SQL injection can be achieved by including a malicious payload in the id POST parameter. In this case, we are mitigating the security vulnerability with a whitelist based virtual patch where the id can only include a number.
This is very different approach to standard Web Application Firewalls, such as ModSec, Cloudflare and many others which are mostly relying on pattens which try to identify exploitation techniques. For that reason, generic firewall are always optimised for low false-positives rate and by that their effectiveness is greatly reduced.
What about performance?
If virtual patching is done right, it has the benefits of a very low performance footprint on the website. Because every security rule is custom made for a vulnerability, you need to know exactly which security rules a specific website needs.
Patchstack currently has nearly 9000 virtual patches created for WordPress security vulnerabilities. This is by far the largest collection of security rules compared to any other vendor.
However, we don’t deploy all 9000 on every single website and trigger them on each page visit. Because Patchstack is directly connected to the application, we know exactly which vulnerabilities are present, and which ones are not – so we can provide custom security for every single site.
Virtual patching not only provides a more accurate security protection for your websites, but it’s also much more lightweight compared to application firewalls which rely on generic rulesets.
That being said, my recommendation is to use both, but generic WAF’s should be deployed on the network layer, where the load is handled by the service provider before the traffic even hits your server & application.
Join the Conversation!
There's a dedicated thread on this post inside of The Admin Bar community. Join in on the conversation, ask questions, and learn more!
Group Thread
Oliver Sild
Oliver Sild is the CEO and Co-founder of Patchstack. He is an entrepreneur and cyber security expert with a strong focus on community building. He has been organising hacking competitions (& local CTF community) in Estonia since 2016, has kickstarted a startup community in his hometown and has nearly 10 years of experience with WordPress security.
