First impression on unpacking the Q702 test unit was the solid feel and clean, minimalist styling.
LINUXWORLD - Make vendors liable for bad code says expert
- — 15 February, 2007 09:58
When U.S. courts ruled more than a decade ago that consumers weren't liable for fraudulent use of their credit card numbers after the first US$50, credit card companies -- which were left holding the huge bill -- took notice and dove into fighting fraud and losses.
That's the same approach needed now in the software industry to help drastically improve IT security, according to Bruce Schneier, a security expert, author and CTO of U.S.-based enterprise security vendor BT Counterpane. Today's more secure credit card systems were "built because the credit card companies were forced to assume the liability for fraud," Schneier said Wednesday at the opening keynote of the first LinuxWorld OpenSolutions Summit held here this week. "The trick here is to align responsibilities with capabilities."
A major problem with IT security, he said, is that even as new software patches and other fixes are posted, not every company or home user installs them. Instead, many users, both at work and at home, aren't motivated to keep up with security because vulnerabilities are often unseen, leaving them unaware that they are risking their own operations -- and the larger global system of networks, Schneier said.
"I think things are getting worse, not better," he said.
To change that, the ultimate economic responsibility for better software should be moved directly to software makers, who can directly influence the creation of more secure applications, he said. "If there is liability, we'll pay more [for software], but at least we'll get better software out of it and things will improve," Schneier said.
A penalty system will ultimately result in a more secure global IT system through better-built and better-maintained products. "That's what I want to affect, and liabilities have a way of doing that," Schneier said.
In his talk about the economics of IT security, Schneier said today's software development system lets software vendors sell products without any real responsibility for it once users begin working with it. That doesn't encourage software vendors to stay on top of security problems that arise, he said. The situation is similar to a company that dumps pollution into a river but doesn't worry about the problem because it's not directly affected by the pollution downstream, he said.
Scenarios like that "are all over [the] security [world] and a lot of security failures are due to them," Schneier said. If a third-party company loses someone's data in a breach, then that company can have little concern because the data loss wasn't ever suffered by a direct customer.
Those attitudes must change, he said. "We're living in a world where our security all depends on each other."
Every year, when Schneier visits his mother, he said, he cleans up her home computer and strips it of worms and other security problems. For her -- and other corporate and private users -- security is seen as mainly important to individuals, without an awareness of the interconnections between users. "I'm sorry to tell you, she really doesn't care about you," he said of his mom's lax home computer security regimen.
By modifying the cost-benefit analysis and giving greater IT security responsibility to software companies through liability assignment, security can eventually be improved, he said. "All I need is for the cost of doing the bad [work] to increase. This is why I favour software liability because it raises the costs of bad software."