Sunday, May 13, 2018

3rd Party Software Strikes Again

There is an interesting post by Jake Brodsky over on the SCADASEC list server about this weeks ICS-CERT advisory on the MatrikonOPC Explorer vulnerability. While it is not too techy, I’ll leave the details of the discussion to Jake. The interesting take away from my point of view is that we continue to see the very common (and probably unavoidable) practice of software bundling creating an expanding cloud of system vulnerabilities.

In this case we start with an old Microsoft library problem that was identified and patched some time ago. Unfortunately, between the time the library was published and the problem was identified, MatrikonOPC apparently incorporated the vulnerable library in their OPC Explorer. For whatever reason, the original MS patch did not make it into the affected versions of the OPC Explorer.

Now Jake tells us that there is a good chance that other vendors have been bundling the MatrikonOPC Explorer with their control system packages (because it is easier to buy a MatrikonOPC license than it is to write fresh software to do what Explorer does so well). It is unlikely that the ICS vendors have told their customers that they have the MatrikonOPC software. Even if they did, could the ICS package customers apply the MatrikonOPC patch to the other vendor’s software (VERY UNLIKELY)?

This now brings up a number of interesting questions:

• Who keeps track of all of the third-party software included in a product?
• Who monitors all of the sources of that third-party software for reported vulnerabilities?
Who applies patches/upgrades/updates of third-party software to their product?

It is becoming increasingly evident that the answer to the above questions is probably very close to “NO ONE”. But, it would seem to me that in a truly secure software development cycle the answer should be “EVERYONE”.

Now, this problem is certainly not unique to the industrial control system marketplace. I would be surprised if there were a single piece of commercially available software on the market that did not use any third-party code. But, as we are becoming increasingly aware of the potential for catastrophic physical consequences for exploitation of software vulnerabilities in ICS systems this has the potential to be a very serious problem.

And always keep in the back of your mind; if this becomes the basis of a public exploit of a control system with catastrophic physical consequences there is a very real probability that the politicians will step in to ‘Solve The Problem’.

1 comment:

Jake Brodsky said...

Most of the effort required for a better security posture is keeping track of what you have identifying patches and then deploying those patches.

It seems to me that if vendors and integration firms want to bundle packages together, why not also do the patch testing and bundle a patch service to go with it? I suspect many client companies would be happy to pay for such a service.

/* Use this with templates/template-twocol.html */