Developers 'should be accountable' for security holes
Summary: Security expert Howard Schmidt wants coders to be held responsible for vulnerabilities in their code, but others say their employers should be held to account
Software developers should be held personally accountable for the security of the code they write, said Howard Schmidt, former White House cybersecurity advisor, on Tuesday.
Speaking at Secure London 2005, Schmidt, who is now the president and chief executive of R&H Security Consulting, also called for better training for software developers, many of who he believes don't have the skills needed to write secure code.
"In software development, we need to have personal quality assurances from developers that the code they write is secure," said Schmidt, who cited the example of some developers he recently met who had created a Web application to talk to a back-end database using SSL.
"They had strong authentication, strong passwords, an encrypted tunnel. The stored data was encrypted. But, when that data was sent to the purchasing office, it was sent as a plain text file. This was not an end-to-end solution. We need individual accountability from developers for end-to-end solutions so we can go to them and say: 'Is this completely secure?'," Schmidt said.
Schmidt also referred to a recent survey from Microsoft which found that 64 percent of software developers were not confident they could write secure applications. For him, better training is the way forward.
"Most university courses traditionally focused on usability, scalability, and manageability, not security. Now a lot of universities are focusing on information assurance and security, but traditionally Web application development has been measured in mouse clicks — how to make users click through," said Schmidt.
Companies that develop software also have a role to play, said Schmidt, by checking that prospective employees have relevant security qualifications before hiring them.
The British Computing Society (BCS) agreed that there should be accountability in software development, but argued that companies should be held responsible for the security of the code written by their employees, rather than the employees themselves.
"Howard has gone to an extreme by saying software developers should be held personally responsible for the security of the code they write, but we broadly agree with the direction he's taking. I know a lot of developers who would be very uncomfortable with that level of accountability, especially if that were legal accountability. It is a company's responsibility to make sure the security features of its software are tested with rigour," a security spokesperson for the BCS told ZDNet UK.
"There is also the point that code isn't static — once purchased it can be modified," the spokesperson added, pointing out this would reduce individual accountability.
In addition, many security attacks succeed because users have not installed the latest patches, or installed a system incorrectly.
Businesses themselves should accept some responsibility for the security of the software they purchase, according to the BCS.
"There is an element of 'caveat emptor' — buyer beware. Before buying any software an enterprise should check whether a vendor uses their own security software. They should also be accredited with a CMM [Capability Maturity Model] standard — it's like a kitemark. CMM level three, four or five is an indication the software has been developed by quality developers," the BCS spokesperson said.
"The software has to be shown to be fit for purpose. This is essential for producing a trustworthy online environment."
Do you agree with Schmidt's views? You can have your say by voting in this poll.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
I'm so fscking SICK of these people who treat as if it's something that can be permanently gained by doing A, B, and C.
BULL!
Security is about understanding your platform.
It's about knowing the strengths and weaknesses of said platform.
It's about maximizing the strengths and limiting/minimizing the impact and exploitability of the weaknesses.
It's about doing A, B and C, to get going. Then next week, you do D and E. Then think about implementing F. But make sure that it doesn't conflict with B.
Also, they need to understand that security is NOT about keeping people out of the system. Face it. If someone wants to get into your systems bad enough, they WILL get in. Regardless of your protections.
It's about making it so difficult to access it in an unauthorized manner that:
A: The invader gives up and moves on to easier targets.
B: Spends so much time trying to gain access that he gets noticed eventually.
C: Has to utilize truly heroic (and traceable and wildly obvious) means to gain access that he gets noticed right away.
So please, people! STOP with the damn pipe-dreams about "totally secure" systems already!
The only "totally" secure system is one that's been rendered down to shavings and disbursed in random geographic locations via wind, water, and other means of distribution.
Add to that, the fact that most tenders have only the vaguest of specifications, which lead to enormous amounts of remedial coding after delivery.
Security? All very well, unless you have users who can't remember their password from one day to the next and write it on the desk. Either that or have everyone in the office log in as "Admin".
I would really like to know the alternate reality this guy is in, it must be a nice place..
** Since most companies have developers relinquish their rights to the code, it doesn't make sense that they should be liable.
** The developer has little / no input into the QA process and can not be expected to find their own bugs. Since a company can choose to minimize QA or eliminate it --its not fair to penalize the developers.,
** Few Developers design the architect or write the specifications. How can you single out a developer who is writing to specification?
Also, the article mentions CMM as a sign of quality - It is ins't.
1. There are no more developers except those that have signed contracts with their target audience, which limit damages and responsibility.
2. Software development slows to a crawl and most projects are scraped. It is almost impossible to secure a piece of software from seurity breaches. Case in point: sendmail. This program has been around since the early seventies. It was written and rewritten many times. It still has problems with security to this day. Its not that its authors are bad programers but that security is a very difficult thing to nail down.
The only way this gets any better is to have well written and documented requirements for each and every project out there. This has historically not been the case.
rid of security holes. Developers all leave the field
after the first few lawsuits, no software gets written,
no bugs are introduced.
Security holes are often the function not of
developers work but of managements, and/or
software integrators. I doubt any one developer
at microsoft is responsible for the ease with which
spyware is installed. The fact that users can easily
run code off the net is not a bug, its a design
feature. The code works as its supposed to, the
problem is that management puts convience far
above security in its priorities.
However in a complex system its very hard to
insure that it is secure, or even define what
secure means. For example your home provides
only symbolic security. Glass is easily broken,
locks are easily picked or drilled, etc. making
software truly secure would be like building a
fortress that can stand up to all attacks
unguarded. It simply can't be done. Users must
take some responsibility when it comes to
security just as a home owner must in the real
world.
CMM 5 organizations still launch satellites that are completely non-functional. CMM 5 organizations still produce software with security holes.
The fact of the matter is if your reputation as a company is built on secure software then you just _PAY_ for several experts in the field to review every piece of code, or have them write it. The problem is these greedy bastards just want to send the software to India, and you only end up with half ass work.
Insecurity is the outcome of not treating hardware, firmware and software as a system in need of optimization. What current functions that have been happily executing in each of these three boxes since the 1950s need to be moved, spit or enhanced? The "no execute" bit was recently rediscovered by Intel and AMD but Alpha had it on day one. VMS uses descriptors to define strings while the insecure operating systems of the world don't. Back in the 1970s the idea of opcode encryption was used to prevent theft of software while later research has shown the idea prevents virus injection. The political aspects are important in this discussion as well.
The bottom line Howard's proposal would lead to malpractice insurance for programmers and possibly eight years of school and two years of residency before they could start writing software. We all know what this has done for America in terms of doctors. This would drive development overseas. Keep in mind, American sofware is an important asset that must be maintained by loyal Americans and not by foreign nationals here on H1B visas like so many Congressmen want so they can stroke their rich company friends. H1B visa holders will eventually (hopefully) go home possibly leaving eastereggs in the software they wrote here. What would happen if stock market, hospital, banking or power plant software went offline due to attack? Can you trust foreign nationals?Threatening programmers with personal liability is not the answer. Exporting programming jobs is senseless and makes security impossible just like importing foreign nationals here to do the work.
Howard, the sign on the wall says Good, Quick and Cheap. You get to pick two of the three.
I hate guys like this. I have an appendum to his suggestion: stupid idots should be liable for the stupid things they say. Then maybe we can get rid of clowns like this. Good job america! Schmidt was the White house cybersecurity advisor? Well he's even dumber than his boss. I just want to know how does he feeds himself.
One thing not mentioned in the article was the client's responsiblity - if you want REALLY secure, you're going to have to pay for it. That means stepping away from 'always buying cheapest' or 'screw them in the contract' mentalities that so many companies take. I guess, in short, if you want something reliable you've got to get real about your investment.
a) developers are only one part of the TEAM that produces the code; what about those that were involved in the code inspections? What about those in verification? What about those that chose the features in the first place? What about a CEO that chooses to ship when a product isn't ready?
b) developers are in a hugely economically disadvantaged situation compared to the company they work for. The developers would need to take out personal liability insurance that would either push people out of the industry and/or push up the wages, so the company would end up paying for it anyway. In many cases it's more expensive to buy insurance than for the company to self insure.
c) companies can put enormous pressure on developers to agree to sign off on things the developer knows aren't fully tested. What would you do, agree to ship or get fired? Probably ship. Basically, in practice, the code always ships when the companies says, and the company would do this knowing they aren't carrying the can for damages.
All ways around, it's a stunningly, appalling, terrible idea.