For close to a year, there has been a lot of discussion of liability for software suppliers. This came about after the White House put out a document and talked with reporters about the need to “…place liability ‘where it would do the most good’. This meant primarily ‘the company that is building and selling the software’”. I’ve written 5 or 6 posts on the question; the one I like best is here.
However, after I wrote these posts, the White House (and
DHS) didn’t drop everything they were working on and immediately adopt my
opinion in full; I was amazed that didn’t happen. This just goes to show there’s
no accounting for tastes…
The WH (and a lot of other people, unfortunately) seems to
believe that software developers are currently getting away with grand larceny,
since their malfeasance is the root of many (and really most) software breaches.
Moreover, today there’s no way that those evil developers can be held liable
for those breaches.
I want to discuss the lack of liability first. I honestly
don’t know what this means. As long as one party has standing to sue another in
court for any sort of damages, there is liability. If anyone knows of a state
in which it’s forbidden for a software customer to sue the developer of the software
– or knows of some obscure provision of federal law with the same effect –
please let me know. However, this simply isn’t the case.
On the other hand, there is one thing currently placing a
big obstacle in the path of small software users who wish to sue a software
developer for a hack caused by alleged insecure development practices: the EULA
(End User License Agreement). Of course, we all approve the EULA without
reading it, whenever we want to use a new software product or online service.
I don’t think EULAs should be banned altogether, but it
should be illegal to include a blanket disclaimer of liability for all software
flaws – although perhaps a few test cases in court could establish this
principle without requiring legislation (BTW, since bigger companies can
negotiate their procurement contract terms with their suppliers directly, I
think the government shouldn’t intervene on their behalf. But since small
organizations and individuals have almost no bargaining power - and it might
violate antitrust law if they banded together to force terms on a developer -
there needs to be some intervention by governments to protect end users from these
one-sided “agreements”).
However, in the various articles declaiming the damages
caused by software suppliers, I have never seen any passage that points to
EULAs as the heart of the software liability “problem”. One statement they
almost all seem to include is that there needs to be some sort of “safe harbor”
for software developers who follow “good” software development practices. In
other words, if a software developer is sued, their only possible defense is to
point out that they followed the practices laid out in some document like the
NIST Secure Software
Development Framework (or SSDF for short).
Sounds simple, right? Just take a look at the SSDF; then imagine
the pressure you’d be under if you were a supplier in a court of law and the
only way you could avoid bankruptcy because of a lawsuit from an aggrieved
customer was to somehow “prove” that you had followed the SSDF. Here’s just one
of the many Practices required by the SSDF:
Implement Roles and Responsibilities (PO.2): Ensure
that everyone inside and outside of the organization involved in the SDLC is
prepared to perform their SDLC-related roles and responsibilities throughout
the SDLC (SDLC stands for “Secure Software Development Lifecycle”).
Think of all the documentation you would need to gather to
prove you had followed this Practice. For a large percentage of the employees
in your organization, you would have to show a) they understood their SDLC-related
role(s) and responsibilities and b) they were “prepared to perform” them throughout
the SDLC lifecycle (for most employees, this probably means during every moment
they were employed by the software developer).
What if the supplier couldn’t find some of the required
documentation, especially for employees who left the company long ago? Would they
be SOL? Even more importantly, the jury (probably not made up of highly educated
software engineers) would need to determine where the line falls between the
supplier’s complying and not complying with this Practice. Where will they draw
that line?
Moreover, these questions will come up for every Practice
and Task in the SSDF. The supplier’s lawyers will have to argue each one of
those in front of the jury, against the lawyers for the plaintiff. Then the
jury will need to deliberate on each of them. Even more importantly, they will
have to make a decision, for each Practice and Task, whether the supplier “complied”
with it.
Finally, the jury will have to look at the list of SSDF Practices
and Tasks that the supplier “complied with” and compare that with the list they
didn’t “comply with”, then come up with a single up-or-down decision on whether
or not the supplier “followed” the SSDF. If they decide the supplier did follow
it, they will be allowed to continue in business (minus a big chunk of change for
the legal defense). But if the jury decides the supplier didn’t follow the
SSDF, they might just head down the hall to Bankruptcy Court and save a trip
back to the courthouse.
Does anyone think this very complex “safe harbor” is practical?
If not, what if someone creates a “simple” standard, in place of the SSDF, that
just listed maybe five steps the supplier needs to follow to receive safe
harbor? And suppose each of these is a “no-brainer” - e.g., “You must lock the
door of your office before going home every night”. That would make it a cinch for
every supplier who was sued to receive safe harbor. But is that fair to the
plaintiffs? No matter how strong a case they might have, there would be no
possibility of ever holding the supplier liable for the damages they caused.
Even more importantly, why should the burden be on the
supplier to prove they developed the software using safe practices? Even if they
didn’t follow a few of the SSDF Practices, shouldn’t there also be a burden on
the customer (the plaintiff) to prove they followed safe practices in using the
software?
For example, what if the supplier diligently provided a
patch for every important vulnerability they identified in their software over
the ten years that the customer used the software – yet the customer never
applied a single one of those patches? Moreover, what if the customer’s loss
was caused by a hacker who exploited one of those important vulnerabilities? Is
that irrelevant to the question of whether the supplier is liable for the
breach? If the only consideration preventing the supplier from being held
liable is whether they followed the SSDF to the letter of the law – as it would
be in this case – the answer is Yes. It doesn’t matter what the customer did or
didn’t do; the breach is the supplier’s fault.
The only good aspect of the proposal to automatically hold a
supplier liable for a customer breach, unless they can prove they’ve followed the
SSDF or a similar framework, is there’s no way it will ever be implemented; it
is clearly unfair to the suppliers. Liability for any organization, whether
they’re a software supplier, a liquor distributor or a truck driving school,
can only be determined in a court of law. Furthermore, it needs to be
determined by a judge or jury that considers all the evidence, not just
whether the supplier has followed every provision in a document like the SSDF, which
is mostly incomprehensible to both judge and jury.
Of course, this means that cases dealing with software
liability may take a long time to be adjudicated. But there is one way this process
could be expedited without trampling on fundamental rights: The judge or jury
should not be required to make an up-or-down decision on the supplier’s
liability based on their “compliance” with a single document. Instead, there
could be questionnaires available for judges and juries, which could be used in
cases where liability for software defects is in question. The questions would
be about recommended cybersecurity practices for both suppliers and their
customers; the judge or jury could decide whether they were needed in any particular
case.
Both parties would be required to answer the questions that
apply to them. For example, the supplier might be asked how quickly (if ever) they
issued patches for serious vulnerabilities identified in their products. And
the customer might be asked how quickly they applied each patch to the supplier’s
product in their environment (of course, there would need to be at least some evidence
to back up both the supplier’s and the customer’s answers).
Who should develop these guidelines? Maybe NIST. Or maybe
organizations outside of government, like the Linux Foundation or OWASP. Any
party wishing to participate in drawing up the guidelines should be allowed to
do so.
You may wonder (I certainly have) why this idea – that software
developers should be assumed to be liable unless they can prove they complied
with a set of ambiguous safe harbor provisions – was ever taken seriously. I
think it is because some people in government get frustrated by the fact that it
takes so long for cases dealing with issues like software liability to be
decided by the court system. Surely, they think, there must be a more expeditious
way of settling these disputes! And if we need to cut one or two corners with the
legal system, isn’t that a small price to pay for resolving these cases?
Those people are right that there is a more expeditious way
of resolving cases involving software liability – it’s called regulation. If
you’re concerned that software suppliers aren’t following secure development practices
and are therefore putting their customers at risk, then draft a law that requires
that suppliers follow the SSDF religiously and get fined for any violations.
Of course, you’ll need to get that law passed by Congress. Currently,
it’s hard to see Congress agreeing to name a post office after George
Washington, let alone to extend government regulations into a brand new area
(plus probably to create a new agency to enforce the law, since there is
currently no federal agency that I know of, other than the FDA, that has
regulatory jurisdiction over suppliers of products consumed by the private
sector – other than for safety considerations[i]).
Creating regulations is hard, and it’s probably impossible
in the current political environment. But that doesn’t excuse throwing away
time-tested legal concepts like determination of liability in a court of law
and equal treatment of opposing parties in court cases. If it’s a choice
between waiting for a slow judicial system and taking an end run around that
system and singling out a particular class of defendants as liable before a
trial even takes place, I’ll take the former any day.
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.
My book "Introduction to SBOM and VEX" is now available in paperback and Kindle versions! For context, see this post.
[i] This
excludes the nuclear power industry and the military. In both of these “industries”
there are regulations that apply to suppliers for cybersecurity and other areas
of risk.
No comments:
Post a Comment