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.

Risk

5/11/2009
01:56 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

The Cost Of Fixing An Application Vulnerability

Security experts say enterprises spend anywhere from $400 to several thousand dollars to fix a single vulnerability in their internally Web developed applications

The cleanup cost for fixing a bug in a homegrown Web application ranges anywhere from $400 to $4,000 to repair, depending on the vulnerability and the way it's fixed.

Security experts traditionally have been hesitant to calculate the actual cost associated with bug fixes because there are so many variables, including the severity of the vulnerability, differences in man-hour rates, and the makeup of the actual fix.

But with the call for more secure coding ringing louder all the time, enterprises are faced with looking more closely at how much they must spend to fix holes in their applications. Jeremiah Grossman, CTO of WhiteHat Security, recently conducted an informal poll about the costs to enterprises for fixing bugs in their Web applications. He went with a relatively conservative estimate, calculating that it takes about 40 man-hours at $100 per hour to fix one vulnerability in a Website, or $4,000. And given that WhiteHat finds an average of seven vulnerabilities per Website, it comes out to about $28,000 to remediate a Website.

John Steven, senior director for advanced technology consulting at Cigital, says Grossman's numbers are "dead on." "Cross-site scripting costs very little to fix, for instance, but the regression rate and 'new findings' rates are very high," says Steven, who has done some number-crunching of his own.

Stevens says security remediation typically occurs outside of the normal development and quality-assurance cycle. It costs an organization about $250 to understand a vulnerability finding, $300 to communicate a vulnerability internally and to get "action," and around $240 to verify the fix itself, he says. A simple bug can take about an hour and a half to fix, he says, or $160, for example, at about $105 per man-hour.

"Endemic problems, like authorization, that require integration with tools take more like 80 to 100 hours," Stevens says, so Grossman's estimate for those cases is right on target, he says.

With XSS, enterprises aren't typically fixing just one XSS bug at a time, either. "Developers tend to fix in batches. So no one fixes [just] one cross-site scripting [bug]," Stevens says. Instead, it's more like eight to 20 at a time, he adds, and while some bugs only cost about $400 to fix, others can cost $9,000 to $11,000 to fix.

A cross-site request forgery (CSRF) vulnerability that requires encryption can require 80 to 100 man-hours of resources to repair, he says. But a low-budget $400 XSS fix is likely to cause more problems later. "Retests will uncover related problems or the same problem elsewhere as a result of that kind of 'fix,'" Stevens says.

Gartner, meanwhile, doesn't calculate actual application repair costs because they can vary so widely, but Joseph Feiman, a vice president and Gartner fellow, says Grossman's estimates are realistic. Gartner, which says 100 percent of all vulnerabilities in homegrown applications are in place prior to production, offers its clients a "cost of effort" analysis framework to determine what it takes resourcewise to fix an application.

"The later you detect a vulnerability [in the software life cycle process], the more the percentage [required] for system testing, construction, and design," Feiman says. "If you find it at operations time, you have to repeat the entire process, so it costs you up to 100 percent effort."

Other experts argue that putting a price tag on vulnerability repair isn't possible. "All in all, the idea of this kind of range is unlikely to either impel or imperil improvements in application security, as it is almost meaningless as a predictor of costs, or as a justifier of investment. There are just too many moving parts," says Jack Danahy, CTO of Ounce Labs.

Danahy says fixing a bug can entail anything from changing one number or API call, to creating and enforcing the use of an input/data validation library. "The fix also varies significantly based on the scope of the chosen repair solution. In cases of widespread poor practices, a single change, made centrally, can eliminate dozens of problems both known and unknown," he says.

Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Previous
1 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Florida Town Pays $600K to Ransomware Operators
Curtis Franklin Jr., Senior Editor at Dark Reading,  6/20/2019
Pledges to Not Pay Ransomware Hit Reality
Robert Lemos, Contributing Writer,  6/21/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-12960
PUBLISHED: 2019-06-25
LiveZilla Server before 8.0.1.1 is vulnerable to SQL Injection in functions.internal.build.inc.php via the parameter p_dt_s_d.
CVE-2019-12961
PUBLISHED: 2019-06-25
LiveZilla Server before 8.0.1.1 is vulnerable to CSV Injection in the Export Function.
CVE-2019-12962
PUBLISHED: 2019-06-25
LiveZilla Server before 8.0.1.1 is vulnerable to XSS in mobile/index.php via the Accept-Language HTTP header.
CVE-2019-12963
PUBLISHED: 2019-06-25
LiveZilla Server before 8.0.1.1 is vulnerable to XSS in the chat.php Create Ticket Action.
CVE-2019-12964
PUBLISHED: 2019-06-25
LiveZilla Server before 8.0.1.1 is vulnerable to XSS in the ticket.php Subject.