Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Ghost in the Machine: Vulnerability Patching

DZone's Guide to

Ghost in the Machine: Vulnerability Patching

A ''ghost in the machine'' is a vital, but hidden, process that makes all complex outcomes seem easy and simple. Let's reveal the cyber ghost in the machine by digging into vulnerability patching, uncovering the process, and discussing how it might be improved.

· Security Zone
Free Resource

Discover how to protect your applications from known and unknown vulnerabilities.

It's called a "ghost in the machine." A vital, but hidden, process that makes all complex outcomes seem easy and simple. Out of the view of most people, these processes are often messy and can be more than a bit scary for the uninitiated. As the saying goes, you never want to see laws or sausage made.

The end result of most ghosts is a disconnection with reality. Modern society makes it easy to lose sight of the fact that milk comes from cows, paper comes from trees, and that cybersecurity is not a given.

Defining the Ghost: Vulnerability Patching

The cyber ghost in the machine that puts organizations and society-at-large at risk the most is vulnerability patching. When cybersecurity teams are able to keep pace with the unrelenting flow of new vulnerabilities, no one notices. Let an organization fall behind on their vulnerability patching schedule, allowing hackers to exploit a known vulnerability, and the results range from mildly annoying to harmful to life-threatening.

Routine critical patches that come from Oracle and Microsoft represent a significant part of the burden teams face. Microsoft's Patch Tuesday is an institutional event ( 76 patches this month) and Oracle's quarterly Critical Patch Updates (CPU) have more than doubled in size since April 2016 - from the 130s to the 300s per CPU in July. The most recent CPU reflected finding a new vulnerability every 68 hours (on average) based on the Java-related CVEs patched - 2/3rds of which had a High Severity CVSS score and 87 percent of which could be remotely exploited without authentication.

The Problems Born Out of the Patching Process

A 2015 report from an independent security firm claimed that most companies required at least 100 days to deploy a patch at an enterprise level. In the intervening years, the sheer volume of applications with known vulnerabilities requiring patches has exploded. One testing vendor reported earlier this year that 83 percent of retail and e-commerce applications they scanned had high-risk vulnerabilities from open source code. Think the Struts 1 & Struts 2 vulnerability that has attracted so much media attention of late.

What's more, the average length of time the vulnerability had been known and unpatched—five years. This proves, once again, that finding flaws is not the problem. Fixing them is. Improving the patching process cries out for a new approach that reduces the associated risk and cost to an organization.

Virtual patches allow teams to apply code equivalent patches while an app continues to run, without any code changes or tuning required. That means applications are instantly protected from cyber attacks that attempt to exploit the latest known vulnerability without taking the application out of production.

Put another way, what has historically taken months (or years) to patch–while you continue to risk an attack while you fix an application–can now be done in a matter of hours or days with less cost and effort. And that restores patching to the ghost in the machine status it deserves.

Find out how Waratek’s award-winning virtualization platform can improve your web application security, development and operations without false positives, code changes or slowing your application.

Topics:
security ,patching ,vulnerabilities ,oracle cpu ,struts 2

Published at DZone with permission of James Lee, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}