The race to patch known flaws is giving birth to the next buzz-worthy approach, but most “virtual patches” are neither. It’s against this backdrop that Virtual Patching is emerging as a solution to the problem of too many unapplied software fixes. However, not all virtual patches are created equal.
The race to patch known flaws is giving birth to the next buzz-worthy approach, but most “virtual patches” are neither
Statistics have been around for years that point to known code flaws in web applications as the primary culprit in successful cyberattacks. Gartner offers the most dire prediction: 99% of successful attacks involve (and will continue to involve) vulnerabilities known to cybersecurity professionals for at least one year.
Veracode’s finding that 86% of high severity flaws go unpatched for 30 days or more adds another dimension to one of cybersecurity’s dirty little secrets. It takes a long time to apply software patches at the server level.
Consumers (and more than a few corporate executives) think patching is easy. After all, when that little red dot shows up on your mobile phone or you get a pop-up on your laptop, you just click something and you are automagically updated. How difficult can it be to patch enterprise software?
Very. Ask the teams (or former CISO’s) at any number of companies who have seen their company’s AppSec program and reputations dissected in the wake of a breach related to the failure to patch a known flaw.
It’s against this backdrop that “Virtual Patching” is emerging as a solution to the problem of too many unapplied software fixes. However, not all virtual patches are created equal. There are basically two approaches, only one of which actually remediates a known software flaw.
Some vendors refer to their ability to take the markers of an attack against a known flaw and apply that to their protection schema as a “virtual patch.” You see this in Web Application Firewalls (WAFs) and some Runtime Application Self-Protection (RASP) products.
In reality, that is merely the application of pattern matching or RegEx to block an attack. It is not the remediation of the code flaw. Under this scenario, someone still has to put fingers on a keyboard to rewrite or update the code; test the fix and hope it doesn’t break the application; schedule app downtime (a precious commodity); apply the patch; and, restart the app.
It is that time consuming and expensive manual process of manually applying patches server by server that leads to the increasing time lag between when a patch is released and when teams can apply the patch. Meanwhile, attackers are constantly scanning the Web for known vulnerabilities.
What is true Virtual Patching?
True virtual patching is very different. Using techniques developed by compiler engineers to fix performance bugs in software, a true virtual patch is a functional equivalent to a physical binary patch applied while the application runs with no source code changes.
The flaw is fixed in the compilation pipeline of Java and .NET applications, reducing the time to patch from weeks, months (or years!) to a matter of minutes. Once under the protection of a virtual patch, resource and time constrained teams can prioritize which applications receive a physical patch and which continue to run with virtual patches.
And, the process of applying new virtual patches only requires an app administrator to select the patches to be applied and click apply. The rest is an automated function.
With an estimated 111 billion (yes, billion with a B) new lines of code written each year, and NIST adding a new software bug every 30 minutes on average, there simply is not enough time in the day or fingers on keyboards to fix the known software flaws and the ones that are on the horizon.
Automated, true virtual patches that fix code vulnerabilities are the best way to secure vulnerable web applications from known code flaws..and protect customer and company data from attack.