Holding ISVs Accountable

In what appears to be an emerging and long-overdue trend, companies are holding software vendors directly accountable for the security flaws in their products.

Perhaps the most poignant example of this is this summer’s Card Systems’ security debacle which caused the identification of 40 million customers of MasterCard, Visa and American Express to be stolen, said Ed Adams, CEO of Security Innovation, a software security testing company.

After it was found that Card Systems’ software was responsible for the security breach, all three company’s terminated their contracts with Card Systems; effectively shutting it down.

“Their customers pulled out and their company was gone,” said Adams.
“They sold on pennies to the dollar to another buyer over the summer.”

While this may be an extreme example of vendor accountability, in increasing numbers companies of all stripes are telling their ISVs they no longer will tolerate the problems associated with poorly engineered software—especially since new laws and regulations require public disclosure if customer information is stolen or hacked.

It’s the Law

California Senate Bill 1386, for example, requires companies to notify customers if their personal information has been compromised. This has caused black-eyes for a number of companies since it became effective in 2003. Because of this law and financial regulations like Sarbanes Oxley, companies are now starting to ask why they must bear the brunt of the bad press for a flawed product, said Kevin Kernan, CEO of Secure Software, a security technology and testing company.

“I think what is driving behavior today, when I talk to our prospects, it’s revenue, reputation and regulation,” he said.

In other words, if a regulation forces a company to loose face and, potentially, customers, through the public disclosure of a software security breach, then that affects revenue.

Why Now?

So, why has it taken so long for companies to start to hold software vendors accountable for their products just like they would in any other industry?

The answer is multifaceted but it comes down to a few basics: end user license agreements (EULA’s), a lack of standards, tradition, and new security threats.

EULAs often contain “hold-harmless” clauses that basically let the vendor off the hook for the quality of their products. Unlike other industries, buyers have accepted this risk and taken on the burden of securing inherently insecure software with firewalls and intrusion detection systems, said The Yankee Group’s Senior Security Analyst Andrew Jaquith.

But, today, with threats evolving and, more importantly, targeting the application layer, traditional approaches to security are no longer enough. This means security can no longer be treated as an after thought by the ISV’s development team and left up to end users. Why? Because those same EULAs often make it impossible for customers to access the underlying, proprietary code to fix the problems that make the application flawed in the first place.

So, if you can’t fix the problem yourself and it’s a problem with the product’s basic design, then, by default, it is up to the producer of that product to be held accountable. At least that is the logic and, up until today, logic that has not been applied to the software industry, said Counterpane’s CTO Bruce Schneier.

“The software industry has really been exempt from product liability laws; really forever, and it’s unclear why,” said Schneier. “If a normal product you buy fails, you have recourse. If a software product you buy fails, you don’t. So, yes, it’s a new trend.”

And perhaps one of the drivers of this trend (and the part that is ruffling the most feathers) is the technology to make software secure from inception has been around for years; it just hasn’t been used, said Jaquith and Schneier.

“It’s not a technical problem,” said Schneier. “We have all the technology. It’s just not being deployed. Security is no longer about technology, it’s about applying technology.”

So now the tradition part. Traditionally, software buyers didn’t have to worry too much about security: firewalls were often enough to do the job. But, with software running everything from the factory floor to the shipping dock to the back office, and hackers getting hold of increasing amounts of sensitive data—events that companies now have to report publicly—this tradition is having its Swan Song.

“I like to use the analogy of the tobacco industry,” said Security Innovation’s Adams. “Even if they said, ‘If you open this pack of cigarettes and smoke it you can’t hold us accountable for the damage this may cause you,’ that’s a bit ludicrous don’t you think?

“So, the end user licenses that are restrictive, that say ‘We’re not accountable for any flaws in this product,’ I think that has been an accepted norm in the software industry. I don’t know about you, but I’m tired of that norm.”

But, in the industry’s defense, continued Adams, there are no universally agreed upon standards by which software security can be measured so, therefore, it is difficult for ISVs to certify that their products are secure.

In an effort to change this, Security Innovation has started a consortium of ISVs, industry analysts and high-profile end users like General Electric, to come up with software security standards that can be applied like ISO standards, which are used in manufacturing.

The idea is still in its infancy but, in time, the group hopes to submit draft guidelines to the IEEE (Institute of Electrical and Electronics Engineers) for adoption.

Until then, though, it will be companies (or perhaps a White Knight—but that seems unlikely) holding software vendors accountable that will change the status quo.

“In the software world it is the 1950s and we don’t have a Ralph Nadar yet,” said Yankee’s Jaquith.