When it comes to software vulnerabilities, there are plenty of pieces of blame pie to go around.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
Software vendors get the first helping, because they develop products that are flawed and ultimately exploited by crackers. On the other hand, some users are lax when it comes to installing patches for vulnerabilities, which in some cases have been public for months.
User and vendor liability for vulnerabilities has recently been in the news. Recently, SearchSecurity.com reported a story on downstream liability that enterprises could incur if their unpatched systems are used as pawns in distributed denial-of-service attacks. Companies that don't properly secure their systems could be opening themselves up to damages.
The recent Slammer worm also highlighted the tension between user and vendor responsibility for flaws. For six months prior to the worm's appearance, Microsoft had a patch available for a vulnerability in SQL Server and Microsoft Desktop Engine that would have prevented Slammer from doing much damage. On the other hand, the patch was quite difficult to install and many administrators ignored the "critical" nature of Microsoft's warning about exposing database servers.
On the heels of these two events, SearchSecurity.com asked users who they think is responsible for software vulnerabilities: vendors or users?
Should software vendors be liable?
The lack of liability is why some software vendors aren't focusing as much on security, said Bruce Schneier, chief technology officer of Cupertino, Calif.-based Counterpane Internet Security, during a recent interview. If the company isn't liable for vulnerabilities, then it's not in the company's best business interest to make more secure products.
In a way, software is quite different from other products. For example, if Ford released a car that an attacker could take remote control of and smash into other vehicles on the road, then the automaker would be liable. Why isn't there a similar reaction when a software vendor releases an application so full of holes that it could compromise a system, allowing an attacker to hijack that system and use it to launch a distributed denial-of-service attack?
"If Firestone produces a tire with a systemic flaw and you die, then they are responsible," Schneier said. "But if Microsoft produces an operating system with two systemic flaws a week, it's not responsible."
Yet software is much more dynamic than durable goods such as cars. The development cycle for software is much tighter. Market forces as they are today make vendors focus more on functionality and time-to-market than security. All of this contributes to the debate over responsibility.
"I do not believe that a company deliberately creates bad code, when you consider that a program contain millions of 1s and 0s and a single bit error can open up a hole," said Matt Villion, IT manager for Dynamic Digital Depth Inc.
There are downsides to assigning legal liability for problems with software, Villion said. "The average programmer would be too scared to release his killer app in case of a lawsuit. Bang, you have just killed freeware and shareware," he said.
Besides freezing innovation, vendor liability may have other consequences, such as the creation of "bug insurance" for vendors, said Bryan Finn. "With insurance protection in place, the motivation disappears to produce better software. The cost of the insurance will be passed on to customers," he said.
"In the end, the result will be more money in the pockets of insurance companies and lawyers and less in our own, due to higher prices," Finn said.
Should users be liable for not patching?
Holding users responsible for flawed products is misguided, said Joe Finamore, data security officer at the Marshfield Clinic, a Wisconsin-based group of medical centers. "To take your car analogy and match it to the circumstances in the software world, how can you make the car owner responsible for engineering deficiencies in a car when the only way to remedy the situation is to bring the car into the garage weekly to get the latest recall item fixed?" he asked.
Richard Meyer, IT specialist for Americhen Inc., offers another analogy. Suppose Bob walks into a gun shop and buys a handgun. That evening he shoots someone. Should the manufacturer of the handgun be liable for the actions of Bob?
"If the person intentionally used the product in a way not prescribed by the manufacturer, is the manufacturer liable?" Meyer said. "I don't think so."
The same holds true with a patch from a software vendor. If the vendor says it needs to be installed, it has to be, or "you are to blame, regardless of whether you had time to install the patch or not," Meyer said.
Yet patches can do damage as well as prevent it. Respondent Ralph Smorra had a particularly bad experience with a patch. "The only time I've ever had to restore from backup tape was not due a virus, hardware failure, or misconfiguration; it was because I had downloaded and installed an official Microsoft patch," Smorra said.
For this reason, enterprises usually have to test patches before pushing them out to production systems. This process takes time and adds complexity to the patching process, especially when systems have multiple applications. "Businesses, especially those with many systems that need to be patched, can ill afford the lost time that comes from installing a patch on numerous systems, only to find out that it conflicts with some other required application," said Charles Cassidy.
FOR MORE INFORMATION:
- FEEDBACK: Who's to blame? Vendors or administrators?
Send your thoughts to News Writer Edward Hurley.