Welcome Guest. | Log In | Register | Membership Benefits

The Curious Case Of Unpatchable Vulnerabilities

Verizon's annual breach investigations reports have consistently shown that fewer -- and in the most recent edition, only five of 381 -- attacks exploit vulnerabilities that could have been patched. Should companies re-evaluate their priorities?

Nov 08, 2011 | 05:19 PM | 

By Robert Lemos, Contributing Editor
Dark Reading


A fundamental component of most, if not all, IT security programs is the timely patching of vulnerabilities in critical systems.

Yet security experts are taking a new look at the strategy as data on breaches continues to show that very few attacks compromise systems using a vulnerability that could have been patched. In 2010, for example, only five vulnerabilities were exploited by attackers in the 381 breaches investigated by Verizon, according to the company's Data Breach Investigations Report (DBIR). Instead, most attackers exploited misconfigurations or gained credentials for otherwise secure systems.

The data suggests the focus of corporate IT on patching could cause managers to miss other important strategies to minimize risk, says Wade Baker, director of risk intelligence for Verizon.

"In general, the security industry is far more vulnerability-minded than we are threat-minded or focused on impact," he says. "Threat, vulnerability, and impact are the components of risk, but most of our time is spent on vulnerabilities."

The data from Verizon's report underscores that patching, while a necessary component of any vulnerability management program, is not sufficient. It's a meme that other security professionals have echoed, as well: Josh Corman, Akamai's director of security intelligence, has cited the research as a reason for companies to consider other strategies to reduce their vulnerabilities to attack and the impact of breaches.

The security experts are, however, not telling businesses to toss out their vulnerability management strategies and patch processes. Companies should just make sure they are balancing their priorities, Baker says. For example, if a company patches its systems once per quarter, then pushing for faster patches is less important that ensuring that patches are applied to all systems.

"Making that faster is probably not going to reduce the risk as much for you as making sure that the patch is deployed everywhere," Baker says. "The problem is not speed of patch deployment -- it's missing the patch deployment."

Companies should also pay more attention to detecting poorly configured information systems and educating developers on methods for more secure programming, says Marc Maiffret, chief technology officer for eEye, a vulnerability management firm. In a survey of the vulnerabilities that Microsoft patched in 2010, the company found that two simple changes -- blocking WebDAV connections and disabling Office file converters -- could have prevented the exploitation of 12 percent of all the software maker's vulnerabilities, including those used in major attacks.

"Simple best practice configurations around your operating system software and network architecture could have mitigated or helped mitigate the threat of Stuxnet, Aurora, and other major attacks," Maiffret says.

Maiffret takes issue with Verizon's data on patchable vulnerabilities, however. SQL injection flaws are not counted as patchable vulnerabilities, but could be discovered by a good vulnerability scanner and fixed, just not with a third-party patch in most cases, he argues.

Verizon's Baker accepts such critiques of the data, but responds that the data does show a valid trend: Attackers are avoiding the exploitation of vulnerabilities in favor of exploiting poor design flaws, abusing stolen credentials, or preying on trusting users. In addition to searching out poor configurations, IT security managers need to educate their users, reduce the attack surface area of their networks, and improve developers' secure-coding skills.

"Secure code development is equal [to], if not more important than, patching," Baker says. "Patching is just failed secure development."

Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.



Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dark Reading encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dark Reading moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing/SPAM. Dark Reading further reserves the right to disable the profile of any commenter participating in said activities.

Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
Subscribe to RSS



Vulnerability Management Reports

report Choosing the Right Vulnerability Scanner for Your Organization
Vulnerability scanners can be used to help detect and fix systemic problems in an organization's security program and monitor the effectiveness of security controls. However, a vulnerability scanner can improve the organization?s security posture only when it is used as part of a vulnerability management program, in which products, processes and people are working together to find, identify, prioritize and mitigate threats. Here are some tips on choosing and implementing vulnerability scanners in your enterprise.

report Using Google to Find Vulnerabilities In Your IT Environment
Attackers are increasingly using a simple method for finding flaws in websites and applications: they Google them. Using Google code search, hackers can identify crucial vulnerabilities in application code strings, providing the entry point they need to break through application security. Sound scary? It is, but there is good news: You can use these same methods to find flaws before the bad guys do. In this special report, we outline methods for using search engines such as Google and Bing to identify vulnerabilities in your applications, systems and services--and to fix them before they can be exploited.

report Security Pro's Guide to Patch Management
It's no longer sufficient to patch just Windows, Office and IE. With the massive array of applications now residing on enterprise PCs, and the proliferation of mobile and cloud-based applications, your business is far too vulnerable to exploitation unless you have a solid strategy for patch prioritization, deployment and quality assurance. Follow these steps to put your plan in place.

Other reports from the Vulnerability Management Tech Center:




Featured Webcasts
Featured Whitepapers
Featured Reports