Under the General Data Protection Regulation which took effect on May 25 this year, there may be some circumstances where organizations could be held liable for a breach of security that relates to measures, such as patches, that should have been taken previously.

For 2,600 years we’ve been hearing the story of the Tortoise and the Hare, where slow and steady wins the race.  Aesop never met a hacker or a regulator.

Attackers have become so adept at using automated scanning tools to exploit code flaws that the first attacks against a new CVE often comes within hours of the public announcement.  Yet, most businesses require days, or months (if ever) to apply physical patches to enterprise web applications.

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 vulnerabilities known to cybersecurity professionals for at least one year.

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 a message pops-up on your laptop, you just click and you are automagically updated.

How difficult can it be to patch enterprise software on a timely basis?

Very.  One vulnerability management vendor claims that 86% of high severity flaws go unpatched for 30 days or more in web applications.  A stunning 26% of respondents to a survey at the 2018 RSA Conference admitted they do not have time to patch applications and 16% do not have the skills.  The CyberEdge Group reinforces the RSA findings: Teams do not patch known software flaws because of “infrequent windows…for patching” and a “lack of qualified personnel.”

While there are many reasons why organizations do not patch on a timely basis, there is one clear, new motivation to speed the patch cadence:  25 May 2018.  That’s the day the European Union’s General Data Privacy Regulation (GDPR) became enforceable.

Under the GDPR, fines of up to 10 million EUR or 2 percent (2%) of an organization’s annual, global sales revenue – whichever is greater – can be assessed for failing to ensure security.  Fines for more severe or repeat infractions may result in fines up to 20 million EUR or four percent (4%) annual global sales.

GDPR fines are designed to change behavior, not just appeal to enlightened self-interest. European regulators have already sent signals that they believe a failure to patch on a timely basis is an infraction under GDPR.

When issuing a fine against Carphone Warehouse for a breach, the United Kingdom’s Information Commissioner’s Office (ICO) cited a “seriously inadequate” patching program.  The ICO also issued additional guidance:

“Under the General Data Protection Regulation which took effect on May 25 this year, there may be some circumstances where organizations could be held liable for a breach of security that relates to measures, such as patches, that should have been taken previously.”

What is Virtual Patching?

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.

Today, some vendors refer to the 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, these are merely the use of pattern matching or RegEx to block attacks and do not remediate the flawed code. This approach comes with the same positive and negative impacts of any heuristic-based approach – a level of protection against a similar attack, but with routine tuning required, false positives, and performance impact.

To remediate the flaw in this case, someone still has to put fingers on a keyboard to update the source 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.

True virtual patching is very different.

A true virtual patch is the functional equivalent of a physical binary patch applied while the application runs with no source code changes.  Flaws are fixed in the compilation pipeline of an applications’ runtime, reducing the time to patch to minutes without breaking the app. No tuning required, no false positives, and no performance impact.

The process of applying new virtual patches across an entire application estate requires an administrator to select the patches to be applied and the rest is an automated function that takes minutes. Once under the protection of a virtual patch, resource and time constrained teams can prioritize which applications receive physical patches and which continue to run with virtual patches.

With an estimated 111 billion new lines of code written each year and NIST adding new software bugs an average of every 30 minutes, there is not enough time or fingers-on-keyboards to fix known software flaws.  Regulations like the GDPR and New York Department of Financial Services Part 500 are adding a new sense of urgency to already stressed patching programs.

Automated, virtual patches that fix known code vulnerabilities, in addition to blocking attacks, may the best option for allowing the sure to take the cybersecurity race from the swift.


This article appeared in InfoSecurity Magazine.