Bundled Software Issues

Earlier today I did a blog post on the updated advisory for the multiple vulnerabilities for the ClearSCADA software package. The update was necessary, not because of a change in knowledge about the vulnerability or its mitigation, but because ICS-CERT became aware that the ClearSCADA software had been bundled into another ICS package, extending the vulnerabilities to a new system. This raises a whole host of potential issues that need to be addressed in the ICS security community.

Identifying Bundled Software

Back in the good-ole days software was not complex; a program did only one thing; data processing. The first program that I wrote (okay I was part of a six kid programming team) was in 1964 and we wrote a program to print out the ‘n’ powers of 2 in decimal and binary notation from n = 0 to 100. We watched the code being punched into the cards, the code compiled in a card reader and then run on a huge computer two rooms distant from where we pushed our noses up against the glass.

I learned about running routines when I progressed to Basic, calling sub-routines in Fortran and then using libraries in C++. That was the last of my programming and the world has changed much in the decade and a half since then. Now systems engineers, particularly in control systems, bundle a number of different programs together, each one doing a different job, or handling a different piece of equipment or interface with another system. The larger companies use mainly their own software, smaller companies buy programs from what ever provider gives them the best price. The pieces of the equipment are wired together and the software is virtually connected to every other piece of software in the system. From that point forward the users and owners are unlikely to know who supplied what part of the bundle; most won’t even know there is a bundle.

This system obviously works pretty well because most people don’t even realize that it is there. Unfortunately, when one piece of the bundle is susceptible to an attack because of an internal vulnerability, it most likely makes the entire bundle potentially subject to that attack. When a software developer writes a patch for a piece of software it is unlikely to address downstream issues or connectivity issues driven by the vulnerability.

So for example when the Serck realized that one of the components of their bundled SCX software (ClearSCADA) had an identified vulnerability, they could not just tell their customers to download the patch for that component. While it might still mitigate the vulnerability, ClearSCADA would have no way of knowing how that update might affect the remaining elements of the bundle. So Serck had to take the ClearSCADA patch, apply it to their bundle and ensure that it didn’t cause any problems for the system. They also may have had to make modifications to make it (or their system) compatible with the newly patched bundle.

Who’s Responsible for Updating the Bundle?

In this case someone obviously stepped forward and notified ICS-CERT that Serck bundled ClearSCADA in their SCX package. It could have been Control Microsystems (ClearSCADA), knowing that they sold ClearSCADA to Serck. It could have been Serck once they became aware of the ClearSCADA vulnerability. It could have been the third party security researcher who identified the ClearSCADA vulnerability. Or it could even have been ICS-CERT that became aware of the interconnection and shared vulnerability. The updated advisory doesn’t tell us.

In this instance whom ever did the notification, the system apparently worked and fairly quickly at that. The original advisory was published on February 1st and this one just barely more than 2 weeks later; and with a working patch. Halleluiah, the System Works.

Or does it? How many other control systems include ClearSCADA in their software bundle? How many SCADA components that have been identified in the last six months as having identified vulnerabilities are included in bundles that have not been updated?

So the question is, who is responsible for initiating the chain of events that ends up with all bundled software being updated whenever a component vulnerability is identified and patched? Right now no one really is required to initiate that notification. So, who should be?

The easy answer is that the company with the initial vulnerability should be required to ‘push’ the information to all customers that use that software/equipment. That is what the automotive recall procedure attempts to do for car defects. Unfortunately, there is no legislation or rule that mandates a similar recall procedure for ICS systems. Perhaps that ought to be considered in any ICS cyber security legislation. At the same time it could make ICS-CERT the legal clearing house for the vulnerability information.