Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Attacks/Breaches

11/8/2011
05:19 PM
50%
50%

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?

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.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Sodinokibi Ransomware: Where Attackers' Money Goes
Kelly Sheridan, Staff Editor, Dark Reading,  10/15/2019
Data Privacy Protections for the Most Vulnerable -- Children
Dimitri Sirota, Founder & CEO of BigID,  10/17/2019
7 SMB Security Tips That Will Keep Your Company Safe
Steve Zurier, Contributing Writer,  10/11/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: The old using of sock puppets for Shoulder Surfing technique. 
Current Issue
7 Threats & Disruptive Forces Changing the Face of Cybersecurity
This Dark Reading Tech Digest gives an in-depth look at the biggest emerging threats and disruptive forces that are changing the face of cybersecurity today.
Flash Poll
2019 Online Malware and Threats
2019 Online Malware and Threats
As cyberattacks become more frequent and more sophisticated, enterprise security teams are under unprecedented pressure to respond. Is your organization ready?
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-17513
PUBLISHED: 2019-10-18
An issue was discovered in Ratpack before 1.7.5. Due to a misuse of the Netty library class DefaultHttpHeaders, there is no validation that headers lack HTTP control characters. Thus, if untrusted data is used to construct HTTP headers with Ratpack, HTTP Response Splitting can occur.
CVE-2019-8216
PUBLISHED: 2019-10-17
Adobe Acrobat and Reader versions , 2019.012.20040 and earlier, 2017.011.30148 and earlier, 2017.011.30148 and earlier, 2015.006.30503 and earlier, and 2015.006.30503 and earlier have an out-of-bounds read vulnerability. Successful exploitation could lead to information disclosure .
CVE-2019-8217
PUBLISHED: 2019-10-17
Adobe Acrobat and Reader versions , 2019.012.20040 and earlier, 2017.011.30148 and earlier, 2017.011.30148 and earlier, 2015.006.30503 and earlier, and 2015.006.30503 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .
CVE-2019-8218
PUBLISHED: 2019-10-17
Adobe Acrobat and Reader versions , 2019.012.20040 and earlier, 2017.011.30148 and earlier, 2017.011.30148 and earlier, 2015.006.30503 and earlier, and 2015.006.30503 and earlier have an out-of-bounds read vulnerability. Successful exploitation could lead to information disclosure .
CVE-2019-8219
PUBLISHED: 2019-10-17
Adobe Acrobat and Reader versions , 2019.012.20040 and earlier, 2017.011.30148 and earlier, 2017.011.30148 and earlier, 2015.006.30503 and earlier, and 2015.006.30503 and earlier have an use after free vulnerability. Successful exploitation could lead to arbitrary code execution .