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