Will they hang the cowboy?

Last month, after the National Cybersecurity Strategy was released, I published this post on it. I didn’t object to the document in general, but rather one specific section, which seeks to make software suppliers liable for breaches by assuming they’re always at fault - although they could receive a “get out of jail free” card if they could show they followed NIST’s Secure Software Development Framework (SSDF). Never mind that there are plenty of other ways that the supplier could be liable for a breach, that have nothing to do with development practices. I elaborated on what I said in the first post in this second post.

To be honest, after those posts, and a third post based on conversations on LinkedIn with Dale Peterson, I put the issue out of my mind, since I didn’t hear anything more about it. I thought it was likely that the idea had already been consigned to the trash heap where it belongs.

However, I was disappointed to read in NextGov this week that Jen Easterly, CISA Director, and Kemba Walden, Acting National Cyber Director, said the following at a recent meeting:

“’We can't allow the end user to be held liable for flaws in code,’ Walden said. “It's just that simple.’ Easterly echoed this stance, saying that the design of secure software will have to pivot at a market level to incentivize the manufacturing of systems created with a safety-first approach.”

In my second post, I had described a thought experiment, in which a trial judge is determining liability for a devasting ransomware attack and learns that the vulnerability that enabled the breach was there because of a mistake made by the supplier in the development process (furthermore, I stipulated that this breach could have been avoided if they had followed the SSDF better). It would seem this is a textbook example of what Easterly and Walden are talking about, right? If the trial ended at that point, I’d tell the jailhouse personnel to start readying the gallows for the unfortunate defendant.

However, I then imagined that the defendant would get to state their case - under a quaint doctrine that liability should be determined by a judge or jury, not by some random person in DHS or the White House, and that both sides should be allowed to present their case. But that doctrine is sooooo 20^th Century. 😊

In my thought experiment, the defendant (the developer) points out that they discovered the flaw about a year after the vulnerable product had shipped; they immediately patched the flaw, but the company that was breached never applied the patch. In fact, they didn’t apply any patches that came out over the next three years. Since this supplier provides cumulative patches, all the company had to do was apply any one of those patches and the vulnerability would have been closed. The developer also showed evidence that other customers of the same product, that had applied the patch, were never breached, despite indications that they were attacked by the same ransomware group.

It seems ridiculous that this idea should even get this far without dying a well-deserved death, but I would also think that considerations like my thought experiment would finally put it to rest. However, it seems someone did bring up a consideration like mine, and either Walden or Easterly said the following during the meeting (unfortunately, I read at least one other story on this meeting, and I don’t know where I saw this): Software suppliers, instead of fixing problems in their code before shipping it, just wait for others to discover vulnerabilities (sometimes the hard way, by getting hacked). Then, the suppliers deluge their customers with patches – and if the customer has missed a single patch, the supplier will claim any breach isn’t their fault. Oh, the perfidy!

The only problem with this idea is it makes no sense if you know anything about vulnerabilities. It seems to assume that:

1.      The number of software vulnerabilities in the world never changes (in fact, about 25,000 new CVEs were identified in 2022).

2.      One goal of a secure development process is to make sure that every one of this fixed set of vulnerabilities is patched and therefore not exploitable.

3.      This means that no security patches will be needed after a software product ships. Ergo, if a supplier issues a lot of patches for their products, this just means they’re lazy. They deserve to be liable for a breach, since they didn’t have the foresight to patch every possible future vulnerability before they shipped their product.

I hope nobody reading this post will need an explanation of why the above is pure nonsense. But if you do, I have one word for you: log4shell.

What surprises me most is that DHS, and especially CISA, is filled with people who could have corrected the misperceptions behind this section of the strategy document. Why didn’t they?

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC. If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com.