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

11/29/2007
07:10 AM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

Insecure Software Costs US $180B per Year

'Vulnerability tax' might be the answer, says SANS instructor and security expert David Rice

Consumers have protections when it comes to E. coli-ridden vegetables, lead-tainted toys, and other defective products. Why not from insecure and vulnerability-flawed software that threatens their personal data?

That's one argument posed by David Rice, director of the Monterey Group and a SANS course instructor who has just published a new book called "Geekconomics: The Real Cost of Insecure Software".

In the book, Rice, who has worked on national security issues for the National Security Agency and the military, poses a bold solution to cleaning up what he calls the "pollution" of insecure software: instituting a "vulnerability tax" on vendors.

"I know [tax] is a four-letter word in this country," Rice said an in interview with Dark Reading today. "I expect a lot of heated debate."

He estimates that the actual cost of insecure software to the U.S. is at least $180 billion per year, although he acknowledges that such numbers are "soft." He based his estimates on other numbers -- including a recent General Accounting Office report that says the U.S. cybercrime market is around $117 billion -- as well as other reports, such as estimates of worldwide phishing operations of $350 billion per year.

But it's Rice's controversial proposal for making the software industry more accountable for flawed software that is likely to raise some eyebrows. It's a taxation model akin to what automakers pay, and which buyers ultimately absorb when purchasing carbon-emitting vehicles.

According to Rice, software bugs have led to everything from physical danger (software defects led to a 1996 Boeing 757 crash) to infrastructure disruption (the 2003 power blackout caused by a software problem) to a burgeoning cybercrime market.

Rice acknowledges that taxing software vendors would cause an unpopular side effect: Consumers would ultimately pay more for software. But the software theoretically would be less buggy. "Right now, people don't feel the social cost of insecure software," he says. "That's what this model tries to do."

Just as a traditional manufacturer would pay less tax by becoming "greener," the software manufacturer would pay less tax for producing "cleaner" code, he says. "Those software manufacturers would pay less tax pass on less expense to the consumer, just as a regular manufacturing company would pass on less carbon tax to their customers," he says.

It's not clear how the software quality would be measured, he says, but the idea would be for a software maker to get tax breaks for writing code with fewer security vulnerabilities.

And the consumer ideally would pay less for more secure software because tax penalties wouldn't get passed on, he says.

Rice says this taxation model is just one of many possible solutions, and would likely work in concert with torte law or tighter governmental regulations. This accountability approach would likely vary from country to country, he says, but it's a global issue. "This is a global concern. I'm not sure we're going to see a Kyoto protocol here, but there would have to be some type of concerted international effort" to handle insecure software, he says.

There's no way to write flawless software, Rice says, but vendors need to step up and better protect the consumer. "We're not asking for perfection in products, but for some level of accountability," he says.

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.

Kelly Jackson Higgins is the Executive Editor of Dark Reading. 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

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/22/2020
The Problem with Artificial Intelligence in Security
Dr. Leila Powell, Lead Security Data Scientist, Panaseer,  5/26/2020
How an Industry Consortium Can Reinvent Security Solution Testing
Henry Harrison, Co-founder & Chief Technology Officer, Garrison,  5/21/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-10737
PUBLISHED: 2020-05-27
A race condition was found in the mkhomedir tool shipped with the oddjob package in versions before 0.34.5 and 0.34.6 wherein, during the home creation, mkhomedir copies the /etc/skel directory into the newly created home and changes its ownership to the home's user without properly checking the hom...
CVE-2020-13622
PUBLISHED: 2020-05-27
JerryScript 2.2.0 allows attackers to cause a denial of service (assertion failure) because a property key query for a Proxy object returns unintended data.
CVE-2020-13623
PUBLISHED: 2020-05-27
JerryScript 2.2.0 allows attackers to cause a denial of service (stack consumption) via a proxy operation.
CVE-2020-13616
PUBLISHED: 2020-05-26
The boost ASIO wrapper in net/asio.cpp in Pichi before 1.3.0 lacks TLS hostname verification.
CVE-2020-13614
PUBLISHED: 2020-05-26
An issue was discovered in ssl.c in Axel before 2.17.8. The TLS implementation lacks hostname verification.