Software liability... will it make a difference?

Insecure code is written every day.  The impact may range from a Windows “blue screen of death”, to cellular service outages, identify theft, critical infrastructure failure, and so on.   How bad code affects you may vary based on where you work and what you do.  For home users, the damage may be minimal.  For business, the costs can be tremendous.

A posting on Bank InfoSecurity this week asked the question, “Should software developers be held liable?”  While my response to this question is yes, it assumes software negligence can be measured, or it can be shown that a standard of due care was not applied.  Fail this test and you’re in hot water.  So how should companies address the possible threat of being held accountable for bad software?  Education is a great start.

Unfortunately, education these days focuses on making sure applications don’t have any of the Top-10, Top-25, or Top-N security holes.  With a prevalence of lists, such as CWE/SANS Top 25 Programming Errors , developers can become focused on what not to do, versus what to do.  Sure, we need to know what practices to avoid, since there’s definitely merit in quantifying common mistakes and encouraging others not to repeat them.  But is software security really improved by creating new lists year after year?  I am skeptical.

“DON’T DO” lists are no different than black-lists, also known as a negative security model.  As long as we can describe what we don’t want, we can include it in the naughty list, and then block it.  For those of you that have worked with black-listing, you know it’s an endless chore of updates and tuning.  As new threats or bad behaviors are found, we have to update the black-list.  It doesn’t end.  This explains why the Top-N lists need to be updated annually.

“DO” lists, or the positive security model, describes only what is good and allows nothing else.  If an activity falls outside the “good list”, it’s simply not permitted.  With this contrast between negative and positive filtering in mind, I suggest that a stronger emphasis on defensive coding practices will lead to more secure software.   

The threat of legal action shouldn’t force software developers to do what is right.    A zeal for quality and excellence should do that.  After all, HIPAA was enacted in 1996 and we still have privacy leaks.  The PCI/DSS standards council has existed since 2004…  You can read into that anyway you like. 

Cheers!   Simon