LinkedIn Comments – Paying for Security Patches

I’ve had an interesting conversation with David Spinks, the owner of the Cyber Security in Real-Time Systems group on LinkedIn® concerning my comments last week about the EOScada advisory from DHS ICS-CERT. Concerning my comments about owners that did not have service agreements having to pay for security patches, David posted the following comment on the CSIRS group site:

“Personnally I think it is reasonable that any vendor charges to issue a patch to organisations that have purchased software and hardware but decide not to take out a maintenance contract. As I have said in other recent discussions the age of ICS on the cheap has gone .... organisations (in particular executive boards) need to beging to invest in security this includes spending on ongoing support and maintenance of the systems they are responsible for .... equipment and softwre refreash should be included in any new budget submissions for ICS systems.”

I replied that:

“I disagree, David. I look at security vulnerabilities in ICS much the same way that the US Government looks at safety defects in automobiles. They are something that the vendor is responsible for providing a fix for, free of charge. Now I would certainly agree that at some point in the life cycle of the product it makes more sense to update/replace than to patch, but given the long life-cycle of these products in the plant environment, this is probably at some significant number of years down the road.”

Now, both of those comments are rather brief, but they do address a very important issue in ICS security; an issue that deserves more than a paragraph describing each of the opposing sides of the disagreement.

To Pay or Not To Pay

First off, let’s clear up a common misconception; the customers are going to pay for patches. A company is going to expend time and materials developing patches. As with any expenses that a for-profit organization expends, the costs are recouped through sales; either directly as a service charge or indirectly through the cost of the products sold. If the costs are not recovered the company goes out of business.

A simplistic view of the above would lead one to believe that the service charge point of view taken by C3-ilex on their EOScada patch is a ‘fairer’ way to pass along the cost of the patch as the current owners are the ones receiving the benefit of the patch, so they should be paying the cost, either through an on-going service contract or a fee-for-patch.

This narrow view ignores the fact that future buyers will also benefit from the patch as it will, hopefully, be applied to future versions of the product. Another method could apply a portion of the current patch development costs to expected future product sales and allow the remainder to be charged to current customers. This may, in fact, be what C3-ilex is doing with this product; they haven’t commented on the effect of this patch on future product pricing.

Fitness for Use

So far this discussion has not looked at product liability issues. Let’s start here with the concept of ‘fitness for use’. This is a legal term that, according to BusinessDictionary.com, means:

“Effectiveness of a design, manufacturingmethod, and support process employed in delivering a good, system, or service that fits a customer's defined purpose, under anticipated or specified operational conditions [emphasis added]. Also called fitness to use.”

Product liability law generally holds that a seller guarantees fitness for use unless they specifically state otherwise. This is the reason that we see the terms ‘limited warranty’ or ‘no warranty implied’ on so many sales advertisements and contracts. The seller is legally proclaiming the fact that they are specifically limiting or declining to guarantee fitness for use.

The big problem here is the phrase ‘under anticipated or specified operational conditions’. Back in the bad-old-days when control systems were assumed to be protected-by-obscurity or air-gapped, no one made any pretenses that there was a need to offer security features on a control system beyond, perhaps, a password for access to work stations. After the twin tower attacks in 2001 we began to see a realization in more control system owners that they had a certain amount of responsibility for security their production systems, particularly in critical infrastructure industries.

Even so, Pre-Stuxnet (PS), there was still a general industry belief that control systems were protected by their complexity and isolation. Ante-Stuxnet (AS) a consensus is developing that there is much more that has to be done to protect control system security than just hide behind the myth of isolation and the faded hope of complexity. I think that a vendor would now have a hard time convincing a product liability jury that basic security measures were not covered under ‘anticipated operational conditions’ on systems sold AS; the question would be more open on PS systems.

Of course, there still remains the problem of deciding which security measures are basic enough to automatically be considered responses to ‘anticipate operational conditions’ or which are problems that could not have been anticipated by a reasonable person. This will have to be decided by case law or legislation.

The Court of Public Opinion

On the other hand, in the court of public opinion, the expectation of free security updates has already been established as the cyber-industry gold standard. In the IT side of the house that standard was clearly established by Microsoft. Their Tuesday push of security patches to the field has caused everyone else to fall into step in pushing free patches to customers; no one does it as effortlessly as MS, but they all silently follow suit.

On the ICS side the major players have all followed the MS example, except they are not actively pushing patches to the field for rather obvious reasons. Thus the standard of free patches has been clearly established in the control system market place. The current case of C3-ilex is an anomaly that will probably not be repeated.

Product Liability Legislation

Let us not forget that when Congress gets sufficiently agitated, they can wield a powerful legislative storm. Earlier I mentioned the special product liability rules that apply to the automotive industry. Largely because of the book, Unsafe at Any Speed, Congress set up the National Highway Traffic Safety Administration (NHTSA) to regulate safety recalls of automobiles. After the Ford-Firestone rollover fiasco, the rules about reporting of safety defects were further strengthened, expanding the rules of what was considered a safety defect.

The NHTSA rules set up a strict regulatory program for vendor reporting of manufacturing defects. Manufacturers are required to report any customer complaint or warranty repair to a wide variety of safety systems on motor vehicles. Additionally, there is a public hotline for direct to the government complaints about suspected safety defects while law enforcement and insurance companies also report suspected defects to NHTSA.

While the vast majority of automotive safety recalls are voluntarily initiated by industry, NHTSA does have the authority to order a manufacturer to initiate a recall. Furthermore, NHTSA receives quarterly reports on the progress of all recalls, voluntary and directed, to establish that the manufacturer is making a good faith effort to contact all owners of the affected models.

Imagine what an Industrial Control System Security Administration might look like if there is a major critical infrastructure incident that is traced back to security vulnerabilities in a control system. Congress may often be slow to act, but it is quick to over react. When its ire is raised, when the general public is grossly offended, Congress legislates with a broad and freely sweeping pen; frequently extending existing regulatory models into uncharted areas. If it is good enough for the auto industry it should be good enough for the control system industry; this is a response that is well understood by politicians.

No Fee for Patches

So no, I don’t see the C3-ilex fee-for-patching model catching on in the industrial control sector. Fortunately they are a small enough player that they are unlikely to attract the ire of Congress and cause legislation to be written to prohibit the practice. Unless, of course, one of the owner operators that has to pay for the current patch has the ear of an influential congresscritter. Then it would be easy enough to slide such a prohibition into a cybersecurity or spending bill. Similar things have happened before.