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:
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.
Post a Comment