SCADA (or Supervisory Control and Data Acquisition) software is used in a large number of industrial situations to manage infrastructure. The software controls the processes of organisations as diverse as mine sites, biscuit manufacturers, public aquariums and even a well-known Australian media personality (for their garden watering system).
Cognisant of the risks of exposing such critical infrastructure to the “naughty lads of the Internet,” pretty-well every user of SCADA systems makes very sure that they are not exposed. Normally this involves an air-gap: the industrial systems are simply not connected to anything else. More recently, with an increasing interconnectedness, users are finding that their industrial systems are connected to their business management systems – but (obviously) still remaining behind the corporate firewalls.
In the oft-republished Associated Press article (here for instance) regarding the buffer-overflow in CitectSCADA, a naÃ¯ve person might think that the sky was about to fall and the nearest water treatment plant was about to fail.
Nothing could be farther from the truth.
Yes, a vulnerability was discovered by Core Security Technologies and reported in detail to Citect on February 6th 2008. After analysis of the issue, Citect responded to Core that, in effect, they could not determine how the vulnerability might affect their customers as the software was specifically designed and implemented to be well-separated from the internet, and as far as Citect knew, that was how it was being implemented. Citect added that it would be addressed in the next release of the software.
Specifically, the only way a user of the software could be vulnerable is to have active ODBC interfaces and to be directly connected to the internet without any security. Seems to me that for computers in such a situation (ignoring the ODBC factor), SCADA vulnerabilities would be the least of their problems!
Read on to the next page...
Just a note at this point, I actually work for Citect as a training developer – however, I have no connection with software development, management or sales.
Much of this boils down to two issues. Firstly whether it is a “real” vulnerability and secondly, what an appropriate response should be.
Considering a ‘normal’ installation of CitectSCADA, this is probably not a real vulnerability. As mentioned on the previous page, the only way a site could be exposed to the problem is to have their SCADA system connected directly to the Internet without any form of protection.
I recall reading a long time ago about one of the Australian PC magazines building a ‘bare’ Windows XP machine and exposing it to the internet. Over a number of trials, if I recall correctly, the shortest length of time a PC survived until infected by some kind of malware was 6 seconds! The longest maybe 30 minutes.
With this in mind, I can’t see that an ODBC vulnerability is particularly significant!
So, given this, what should the response be?
Citect’s role is to examine the vulnerability report and determine the real impact upon their customers. Having done that, they should then determine whether an urgent patch is required or whether the issue can be dealt with in the normal product development cycle.
Citect initially chose the latter course of action, but also developed a patch to be made available to sites should they insist on applying it.
Given the provenance of the problem, this seemed to be entirely reasonable. However once various members of the ‘chattering press’ took hold of it, nothing short of a 2-year back-dated patch would have pleased them!
Nothing is simple any more!