Virtual Patching: How It Can Be Possible to Get Off the Hamster Wheel of Vendor Patching for Enterprise Software AND Have Better, Less Expensive Tech Support

Virtual Patching: How It Can Be Possible to Get Off the Hamster Wheel of Vendor Patching for Enterprise Software AND Have Better, Less Expensive Tech Support

This article originally appeared on


In the research report Why Adopt Virtual Patching vs. Vendor Patching for Enterprise Software Security?, I wrote about the never-ending, inevitably unsuccessful hamster wheel of a traditional, vendor patch-oriented approach to security for enterprise databases and applications.

Never-ending, because the typical enterprise computing infrastructure is a complex mix of databases, applications, systems, and networks — and the sheer volume and frequency of vulnerability disclosures make keeping all of it securely configured, patched, and up-to-date a process that never reaches the finish line. By one analysis, there were more than 22,000 vulnerabilities disclosed in calendar year 2020 alone.

Inevitably unsuccessful, because roughly 1 in 10 known vulnerabilities have no vendor patches available — e.g., they may relate to out-of-support systems, OEM systems, outsourced code, and so on. This unfortunate reality leaves the window of vulnerability for enterprise computing infrastructure wide open, even for organizations with well-resourced and highly mature vendor-patching processes.

Even when vendor patches are available, the patching process can be costly, time-consuming, and inconvenient for the business — so when it comes to vendor patching there are not only drivers to go faster, but also drivers to delay and defer.

My analysis found that that 90 days after public disclosure (i.e., zero-day) — that is, after a full quarterly patching cycle — about 1 in 5 (20%) of known vulnerabilities in the typical enterprise computing infrastructure remain unpatched. Roughly half of these are due to vendor risk (i.e., vendor patches are not available to implement), and the other half are due to patching risk (i.e., vendor patches are available, but have not yet been implemented.)

For more details about both the technical case and the business case for virtual patching vs. vendor patching, be sure to check out the report.

In doing the research, however, it turned out that there can be another benefit to a virtual patching approach that there just wasn’t room to include in the report: the opportunity to get better, less expensive technical support. The following customer case-in-point provides an illustrative example.

Customer Case-in-Point: A Not-for-Profit Makes a Smart Move in Their Approach to Technical Support and Patching for Databases and Application Middleware

Much like the senior leaders in countless other organizations, the Chief Information Security Officer of a well-known, US-based not-for-profit was looking for opportunities to reduce the operational costs of their computing infrastructure, without introducing additional security risks.

Their assessment was that the security protections provided by a leading third party support vendor

was not merely on par with that of traditional patching, but in many dimensions better. “Given the frequency, cost, and time it takes to apply vendor patches, we determined that slow vendor patching is not as secure as virtual patching,” the CISO said. In terms of typical enterprise patch cycles — from zero-day vulnerability disclosures, to the availability of vendor patches, to testing and implementation of patches on production systems — he noted that “90 days is just not what it used to be, and it still takes up the time of a lot of people.”

The cost of technical support was the biggest factor in the organization’s decision matrix, but during the decision process they were led to believe that the quality of technical support with a leading third party support vendor would be better as well. “It turned out to be monumentally superior,” said the CISO. “Over time we had trained ourselves to be more self-reliant in terms of support, so we had to sort of wean ourselves into using it. Now, we actually use technical support a lot more — it was a huge value-add, which we weren’t necessarily expecting.”

“As a recent example, we had a knowledge gap in certain aspects of WebLogic Server,” he noted. “But the leading third party vendor does not, and they quickly brought that expertise to bear to help us address the problem, no questions asked.”

Since implementation of the leading third party support vendor security protections, there have been a handful of zero-day exploits that were available in the wild and relevant to the organization’s infrastructure. But the protections provided by the leading third party support vendor were already in place — saving the organization from having to bear the cost and time of going through the vendor patching cycle to be protected.

Asked about lessons learned or words of wisdom from their experience to share with other organizations, the CISO told Aberdeen: “We’ve already reduced the cost of support, and so in terms of that initial goal it was mission accomplished. And we’ve had the added benefit of superior support, which has exceeded our expectations, really.”

“The only risk was the bets we made on the security protections,” he said. “But our group was able to implement them even faster than we initially thought. It was worth it to lean in, and get them stood up quickly.”

You may also like:


About the Author

Derek E. BrinkDerek E. Brink, CISSP
Vice President and Research Fellow, Aberdeen Strategy & Research
Adjunct Faculty, Harvard University and Brandeis University

Derek E. Brink, CISSP is a vice president and research fellow at Aberdeen, focused primarily on topics in Information Security and IT GRC. He earned an MBA with honors from the Harvard Business School and a BS in Applied Mathematics with highest honors from the Rochester Institute of Technology. Derek is also adjunct faculty at Harvard University and Brandeis University, where he teaches graduate-level courses in cyber security.