We seem to be starting out 2007 rehashing old ideas – especially bad ones. Schneier has a new/old posting on software liability on his blog today. I guess it is time for me to rehash the counterargument that outlines why software liability is a bad idea.
Here is the opener from an old Computerworld article I wrote on the topic:
All of you who support software liability, do me this favor — the next time you see a software developer, just walk up to him and slap him in the face! All this latent hostility is making you come up with really, really bad ideas.
You see, liability proponents often hide their discussions of liability behind "evil" big companies such as Microsoft, but the fact remains that they’re targeting each and every software developer out there, because every developer codes vulnerabilities into their programs.
(By the way, I was just kidding about the whole slap in the face thing.)
I also wrote about this here on my blog in the past (here and here, in particular).
Here is a summary of my solution:
Software Safety Data Sheets modeled after the chemical industry’s Material Safety Data Sheets that describe the interactions of a chemical with its environment. The SSDS would include checksums on every file, processes and subprocesses, file system ACLs, input buffer sizes for every variable, all network ports used, shared DLLs and other files, and anything else smarter people than me deem necessary to identify how software interacts with its environment. This policy (XML document) would then be imported into my Host Intrusion Prevention solution.
slapping the developer in the face is going after the wrong person, though… from my own experience, business decisions corrupt the integrity of the software development process… business decisions aren’t usually made by the developers…
software security data sheets may be a good idea in theory, but there’s one advantage schneier’s idea has over yours – it deals with the problem of inertia… you haven’t proposed anything that would change the business equation enough to make companies want to create software security data sheets…
how about a compromise – make it so that the ssds gives companies immunity against liability… if you don’t do X you ‘may’ be held liable for problems in your software…
@Kurt -
“slapping the developer in the face is going after the wrong person, though… ”
That’s my point – I believe folks who support software liability are slapping developers, not me.
Re: immunity from liability
I think of this like (I believe) the v-chip brouhaha went in the television world – self-governance trumping government interference that would inevitably turn out poorly. I think your idea is a great one, to combine the two.
Yep, SSDS approach is the way to go. Here is an example, via Jeff Williams’ OWASP presentation awhile back
http://1raindrop.typepad.com/1_raindrop/2005/04/owasp_europe_wr.html
@Gunnar -
The food label approach is a useful one – I am definitely a fan of objective metrics that describe software complexity. But the SSDS isn’t a set of numbers, it is a full-blown policy that can be used to allow/deny program operations.
Just my 2 pennies…..
Any idea or suggestion must take into account the end user of the idea. Waltz into your favorite watering hole and ask the bartender if they understand the MSDS sheet for the funny looking/smelling chemical she is spraying in/around your food. My guess is no. While the argument that Software Liability benefits only the big companies that could theoretically afford the insurance has potential, how the hell does an SSDS solve that? The approach, not even half baked, benefits larger consumers that even have host-based IDS/IPS to begin with. What of the small guy with limited budget, struggling to keep the lights on that has no choice but to rely on vendor (or developer) supplied security controls that may on may not suck (or suck as bad as the next competitor)? In either manner your talking an increase in the cost of doing business. As liability costs are baked into the development cycle the market will eventually place competition on them to reduce the cost no?
@thehawk
ultimately if we’re going to wind up with better/more secure code then the organizations producing the code are going to have to do more than they’re doing now and probably spend longer doing it – that alone is going to increase the cost of doing business…
the problem is that there’s insufficient motivation for most organizations to do that so we need a set of motivations to help things along – we need a carrot and we need a stick… software liability is the stick, the get out of software liability (sorta) free card is the carrot…
arguably, the cost of not improving the quality of the code being produced may be greater than the cost of the improvements… that’s the underlying assumption, anyways…
@TheHawk -
Great comments. Here are some responses:
1) No user would read the SSDS like they might need to for protection from MSDS. This is a manifest for import locally.
2) An SSDS is a hedge against much worse “general liability” for any software. Hopefully, it would forego the need for software liability. To the extent that it doesn’t, costs would be minimized because of the very specific nature of the information available.
3) Every major antivirus vendor already has HIPS built into their product. Since this would take a few product cycles to accomplish anyway, there is no reason the costs for the after-market security products would change.
4) Kurt already addressed the cost of doing business point. I believe anything that is specific and defendable provides a better avenue than what I picture with the ambiguous approach being offered up today.
Hope this clarifies.