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.

Vulnerabilities / Threats

3/1/2012
07:57 PM
50%
50%

Fixing Vulnerabilities On A Shoestring

A study of 15 vulnerability remediation projects finds only a third of time is actually spent fixing flaws. More on the costs and how to reduce them

Click here for more articles.

RSA CONFERENCE 2012 -- San Francisco, Calif. -- It takes less than 10 minutes at the keyboard to fix a cross-site scripting vulnerability, but any company that expects a remediation project to follow a simple calculus is in for a surprise.

On average, the actual programming only accounts for one-third of the total time in any effort to fix vulnerabilities, application development expert Daniel Cornell told attendees here today. A principal at the Denim Group, a software security consultancy, Cornell tracked 15 vulnerability remediation projects and discovered that fixing the vulnerability accounted for anywhere from 15 percent to nearly 60 percent of the total development time, with an average of 29 percent.

"It's not just the time spent on the keyboard that you have to watch out for -- there is a lot outside of that as well," he said. "The [vulnerability] may only take five minutes to fix, but then there is a lot of other hoops to jump through for, in some cases, the other 85 percent of the time."

Setting up the development environment took up to a third of some remediation projects, and confirming the fixes took up to 44 percent of project time. While the data makes up a small sample size, it can help companies take a better approach to fixing vulnerabilities in their code and reduce the time -- and thus, the cost -- spent on projects.

With more than two-thirds of a remediation project spent off the keyboard, a good way to reduce costs is to make nonprogramming activities more efficient, Cornell said. Having an automated way to stand up a development environment can cut, on average, one-sixth off the project time, and efficiently confirming fixes can eliminate another quarter of the overhead.

"In some cases, confirming the fixes and doing quality assurance took longer than fixing the actual vulnerability," Cornell said.

While actual development time accounted for the minority of most projects, be ready for outliers, Cornell warned. In its study, the Denim Group ran into an authorization flaw that took longer to fix than all the other flaws combined, he says.

To speed up development times, the security group should work with developers to plan out the remediation process. Working together can eliminate misunderstandings and combine expertise to more quickly fix flaws, he said.

The worst thing that security teams can do is bring in a voluminous PDF report from an automated static code-analysis tool, slap it on a developer's desk, and tell them to fix the issues, Cornell said. You are telling them to take time from developing features to work on fixes, a task for which they might not have the background.

"There is a lot of friction in organizations when security jumps in and tries to dictate what the development team does," he says.

In the end, taking a team-based approach helps both the developers and the security teams. A badly managed project helps no one, Cornell says.

"The result is that the business guys have no new features, which is really what they wanted, and they have half-fixed or non-fixed vulnerabilities," he said. "If you were the person that spearheaded that first remediation effort, good luck getting your next remediation effort funded."

Have a comment on this story? Please click "Add Your Comment" 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
danielcornell
50%
50%
danielcornell,
User Rank: Apprentice
3/5/2012 | 11:48:15 PM
re: Fixing Vulnerabilities On A Shoestring
Thanks for covering my talk! I posted a copy of the presentation slides as well as some follow-up information online here:
http://blog.denimgroup.com/den...

@danielcornell:twitter-
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 .