Earlier today, Cryptome tweeted:
I’m assuming that Cryptome added the highlighting to:
Software developers should be liable for egregiously poor software…
I don’t consider that suggestion to be, as Cryptome puts it:
NIST BS
Presently, there is no liability for software developers.
How’s that working out for you?
One indication of the “success” of the no liability model is Hackmageddon which relies on reported hacks and has hack timelines back to 2011.
A summary of the “success” of the no liability model is the Internet Security Threat Report, April 2016, by Symantec.
Both of those reviews rely on “reported” hacks, which omits those yet to be discovered (thinking NSA or Sony hacks).
By any reasonable measure of “success,” the no liability model is an absolute disaster.
We can debate how “egregious” software has to be for liability, but consider SQL injection attacks.
Here are five SQL injection “cheat sheets” and a listing of SQL injection scanners:
MySQL SQL Injection Cheat Sheet
SQL Injection Prevention Cheat Sheet
Full SQL Injections Cheatsheet
SQL Injection Cheat Sheet & Tutorial: Vulnerabilities & How to Prevent SQL Injection Attacks
How difficult was that?
You have to be able to type “sql injection cheatsheet” and “sql injection scanner” into an internet search engine. (Rating: Easy)
Curious, is there a show of hands by developers who don’t think they can avoid SQL injection attacks?
FYI, if all developers avoided SQL injection attacks, it would kill the #1 cybersecurity hack on the top #10 list maintained by the Open Web Application Security Project.
We aren’t talking about obscure 0-day bugs that no one has ever seen. SQL injection was first noticed in 1998.
Liability for an 18 year old vulnerability isn’t too much to ask.
Yes?
PS: The NIST quote is from the Information Technology Laboratory Newsletter, September—October 2016, page 1.