Sunday, March 5, 2023

Let’s skip the trial and go straight to the sentence!


There’s been a lot of discussion of my most recent post on LinkedIn, as well as of a similar post by Jeff Williams of Contrast Security. Jeff is best known as the originator of the OWASP Top 10, but is now known to me as a player on a men’s over-50 basketball team that has in the past won the national championship and has also beaten the Mexican national team (although they didn’t win this year). Who would’ve thought a basketball star would have a sideline in software security?

But I digress. In the process of replying to the comments on my post (and replying to my replies), I’m now able to articulate my position on this issue more clearly:

1.      The White House is understandably concerned about the increasing volume of software supply chain cyber attacks, many of which are due to an attacker exploiting a vulnerability found in a software product used by the organization attacked.

2.      What remedy does the White House propose for this problem? In the section entitled “Strategic Objective 3.3…” of the White House cybersecurity strategy document released last Thursday, the remarkable statement is found, “We must begin to shift liability onto those entities that fail to take reasonable precautions to secure their software…” Of course, this section makes it clear that “failure to take reasonable precautions” is a fault found only in the supplier of software, not the consumer of the software, not the maker of a security tool that didn’t detect the vulnerability that caused a breach, etc. This section says nothing about apportioning liability, or about anything other than assigning 100% liability to the supplier.

3.      However, suppose that a software developer followed poor development practices and included in their product (during development) either a certain sequence of code that was known at the time to constitute a vulnerability with some non-zero likelihood of being exploited, or a third-party component that contained code that constituted such a vulnerability.

4.      Moreover, suppose that, due to ignorance or deliberate negligence, the developer didn’t patch this vulnerability (or replace the vulnerable code or component) before they shipped the product to end users. Whether or not the developer knew about the vulnerability, they should have identified it in testing before they shipped the product. After all, it was a known vulnerability. I would consider this fact to be clear evidence of negligence on the developer’s part, although that’s not the same thing as liability, of course.

5.      Now, let’s suppose that, some years after the supplier shipped this vulnerable product to customers, one of those customers (“Customer A”) was breached because the vulnerability in question had been exploited by a hacker. The breach caused serious damage to Customer A, perhaps because the attacker used the breach to plant ransomware in the customer’s network.

6.      Sometime after they were breached, Customer A filed a lawsuit against the developer, saying their poor development practices were the cause of the breach; therefore, liability for the consequences of the breach (perhaps a big disruption to their business, caused by the ransomware incident) rests 100% with the developer. They point to this section of the 2023 White House cybersecurity strategy document in support of their assertion that the developer is 100% liable. Sounds like an open-and-shut case, right?

7.      If I were the judge in this case (say it was a bench trial), would I rule that the developer was indeed 100% liable for the damages suffered by Customer A? I would probably do that, as long as no convincing evidence to the contrary were presented by the developer.

8.      However, suppose that the developer defends itself, because they don’t believe they’re liable at all (of course, if they thought they were liable, they would presumably have settled the lawsuit before it ever went to trial). They admit they erred in not doing adequate testing for vulnerabilities before they shipped the version of the product that contained the vulnerability (i.e. the version that Customer A purchased).

9.      However, they point out that, a year after they shipped the product to Customer A, they discovered the vulnerability in the product and immediately produced a patch for it. They notified all their customers that the patch was available, including Customer A.

10.   Customer A never applied the patch that addressed this vulnerability. In fact, they didn’t apply any patches to the product for the next four years. Since the developer produces what are called “cumulative” patches – which include the contents of previous patches – all Customer A would have had to do, in order to be protected against the vulnerability that ultimately brought them low, was to apply any one of the patches released in those four years. But they never applied a single one.

11.   Of course, four years after the developer discovered the vulnerability and issued a patch for it, the customer’s instance of the product was breached, and the rest is history. The developer, since the customer is suing them for a lot of money, has developed evidence showing that many of their other customers, who had applied the patch, were also attacked by the same ransomware group that breached Customer A. However, none of those other customers were breached, because the vulnerability was patched in their instances of the product.

12.   Given this evidence, would I, the judge, now a) dismiss the lawsuit with prejudice (meaning the suit couldn’t be refiled), since in my mind, the developer is clearly not liable at all (perhaps I would also require the plaintiff to pay all the defendant’s legal costs)? Or would I b) find for the plaintiff, because in my mind none of the evidence the developer introduced matters – i.e., the developer is in fact 100% liable (perhaps the strategy document from 2023 would influence my judgment)? Or would I c) dismiss the lawsuit without prejudice, meaning that the plaintiff could still refile the suit if they discovered stronger evidence of the developer’s liability?

13.   Frankly, any of these three outcomes is possible, and there are plenty of other possible outcomes as well. The point is that it would be quite unusual if the case were so open-and-shut that the suit would either be completely successful (option b) or a complete washout (option a).

In fact, if assignment of liability were as clear-cut as the White House strategy document makes it seem, there would never be a need for any trial regarding liability, at least in software breach cases. All Customer A would have to do is file some sort of notice that they use the developer’s software and they were breached. At that point, the developer wouldn’t be able to do anything other than open their checkbook and ask how big a check they need to write.[i]

In ohter words, it now seems the White House (and perhaps DHS) thinks there’s no need at all for court cases to determine liability for software breaches. As far as they’re concerned, the outcome of these cases is determined from the start (actually, from the date of the strategy document).

This is like the story of two cowboys that captured a cattle rustler and were starting to hang him. One of the cowboys had a sudden attack of conscience and asked, “Shouldn’t we give this man a fair trial?” The other cowboy exclaimed, “You’re right! We’ll give this man a fair trial…then we’ll hang him.”

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.


[i] If you pointed out here that the strategy document says the supplier might be given “safe harbor” because they follow secure development practices, I would agree with you that it says that. However, there would still be a legal case, although this one would be over whether or not the developer qualified for safe harbor. Just the fact that they shipped a product with a vulnerability isn’t prima facie evidence that they don’t follow secure development practices. After all, following secure practices doesn’t make the supplier perfect; it just reduces the likelihood that they’ll make a mistake like the one this supplier made. In other words, a lawsuit over liability for the breach would be replaced with a lawsuit over safe harbor. Customer A would be no more likely to win the safe harbor lawsuit than they would the lawsuit described above.

No comments:

Post a Comment