Computer security expert Bruce Schneier has waded into a debate
raging in cyberspace over who is actually to blame for the security flaws that result from poorly coded software.Last week Howard Schmidt, the former White House cybersecurity advisor, argued at a seminar in London that programmers should be held responsible for flaws in code they write. "In software development, we need to have personal quality assurances from developers that the code they write is secure," he said.
Schmidt's argument outraged large swathes of software developers, including readers of ZDNet UK and tech luminaries such as Bruce Schneier. The chief technology officer of Counterpane Internet Security, Wired columnist and security guru, took issue with Schmidt, arguing that the issue lay with the companies selling the software and not with the developers.
Software companies are in the business of making a profit, Schneier argued, and "they try to balance the costs of more-secure software — extra developers, fewer features, longer time to market — against the costs of insecure software: expense to patch, occasional bad press, potential loss of sales".
The result, Schneier argues, is "lousy software". Companies find money to "weather the occasional press storm" rather than to "design security right from the beginning".
"The end result is that insecure software is common," argued Schneier. "But because users, not software manufacturers, pay the price, nothing improves. Making software manufacturers liable fixes this externality".
Many ZDNet UK readers seem to agree with Schneier, and put the blame for security problems squarely with the vendors selling the software.
The results of a ZDNet UK online poll, which attracted more than a 1000 respondents, showed that 53 percent of readers who replied felt that the blame lies with vendors. Of the rest, 40 percent said that no-one is to blame and just six percent said software programmers were at fault..
As far as Schneier is concerned, "computer security isn't a technological problem — it's an economic problem".
Talkback
Indeed, liability should be introduced at the level where the most positive difference can be made.
Since the brass usually doesn't take orders from lower staffed personal, like developers, it's clear where responsibility (e.g.: liability) should be placed if you want things to change.
That said, just introducing liability for computer security related problems at only the IT vendor level isn't enough. There are more organizations involved in the process that leads to implemented, poorly secure(d), software at customers sites. Examples would be IT Solutions Providers, IT System Houses, outsourcing companies, etc..
If we want to introduce liability for poor secure(d) software then we need to take into account all the factors. We can't have years long court battles involving a vendor claiming that their software is secure as long as you implement and maintain it correctly while the implementor and maintainer tells a different story and the customer is sitting in the middle getting nowhere fast.
In short. When pointing fingers of blame make sure there are no grey areas for anyone to hide in beforehand. That means covering all the bases.
Point to keep in mind. There should be a balance between what some external IT company can be held liable for and the amount of revenue achieved from the customer in question.
While this sounds like a good idea, it's highly impractical. As long as humans write software, there will be honest mistakes that lead to vulnerabilities. I'm not making excuses, we should all be scrutinizing our code for flaws, especially security related ones. AFter all I'm one of the biggest promoters of secure software.
Think what impact this will have on the Industry. Software development will all but vanish as a career, and those that remain in it will demand exorbitant amounts of money due to the liability. Nothing would ever get done because no one would be able to get liability insurance to run their software companies.
Companies would make a business out of dragging individuals through civil suits just to make money because they made a mistake. We can't even clearly define security flaws, and where things actually go wrong yet.
It's good in theory, but a really silly idea.
There are two issues here:
1) I agree there is no economic incentive on the vendors to produce decent products which is why, in my opinion, unix and its derivatives is so much better than Windows.
2) Software engineering as a practice is not professional. The kind of engineering design and quality assurance that goes into most software development is laughable in any other engineering practice because the consequences of failure in other branches of engineering are so much higher (e.g. loss of life). Programmers need to stop being coders and start being software engineers. This is of course tied to the first point...
Currently, if you accept the EULA, you are telling the vendor you are assuming all liability for their bad code. As long as they hold no responsibility why should they be concerned? Change the EULA, until the vendor is held responsible or there will be no change.
I agree that Developers should take more responsibility, but it's actually down to everyone involved in delivering the software to make sure things are done properly.
I spent many years in the RAF before becoming a Project Manager and when it comes to flight safety there are many phrases, all of which reinforce the fact that Flight Safety (like security) is everyones responsibility. Any weak link in the chain can cause catastrophic failure, from the front-line engineer to the chef who cooks the pilots breakfast... and likewise with software security, from whoever wrote the specification to the person who maintains the Developers PCs, as you need to put quality in to a productioon team to get quality out, and everyone has the potential to become distracted by their environment (e.g. a crashing PC).
Probably all of us have at some time emailed an attachmenet, which we forgot to attach!
This type of small mistake is common, but when security is important you must have processes in place to prevent these small mistakes from escalating in to serious security flaws.
Of course it's down to the Developers to produce the highest quality of code they can, but it's down to their managers to make sure rigorous testing and QA is planned and carried out throughout the development lifecycle (not just a cursory 'play' at the end), and down to everyone supporting this process to make sure they do their part.
Fact is that if we do nothing then it's likely that things will get worse rather then improved.
As such introducing liability at least offers some hope of improvement although it might come with a learning curve before it becomes optimal tuned into today's business (market) processes.
But should that stop us? No.
As said before (and given historical track records) we simply can't trust the current (overall) IT industry to take care of things themselves.
As a software developer, I can say that I am forced to produce code according to my employer wishes. When a decision is made to deliver "buggy" code and fix it later, no amount of rasing red flags can change it. "Good Enough" product is considered more marketable than "perfect". BTW, this problem is not limited to the software industry as is evidenced by a lot of other industries i.e. auto, electronics, appliances, etc... The corporations have figured out that they can get away with it and so they do.