SCADA Vendors and Security: It’s Time for Improvement
I recently read with dismay a news story that said that exploit code for a well-known vulnerability in CitectSCADA software has been posted to the Internet. This code’s author said that his motivation was to stir up greater awareness of vulnerabilities in SCADA (Supervisory Control and Data Acquisition Systems) systems because SCADA vendors are not being sufficiently responsible in fixing these vulnerabilities. The vulnerability in question became public knowledge approximately three months ago and at the same time a patch became available.
Software vulnerabilities are nothing new, and many of them are not critical in severity. SCADA systems vulnerabilities are, however, especially significant because these systems are used in settings in which safety-related risk is generally much higher than normal. SCADA systems are, for example, endemic to both traditional electrical power and nuclear power plants. Malfunction or failure in these systems can readily produce catastrophic conditions that can readily threaten human life. The fact that SCADA and other similar systems are more and more being used in a way that leaves them vulnerable to unauthorized external access exacerbates security-related risk even more. So a vulnerability that would normally be considered only moderate in severity is likely to be considered critical if it were in a SCADA system.
The exploit code author is completely correct in saying that SCADA vendors have not in general been sufficiently responsible in patching vulnerabilities found in their products. In many cases they act like an ostrich with its head in the sand, letting time go by without ever producing a patch for a given vulnerability. The fact that creating workarounds for SCADA system vulnerabilities is usually much more difficult because there are relatively few SCADA systems and their code is highly proprietary greatly compounds the problem. Another problem with many SCADA system vendors is just as serious, however—many have overlooked security considerations in the design, implementation of their software, resulting in a lack of inherent security control functionality in their products. Furthermore, SCADA vendors have not done enough to produce baseline security standards for these systems. The result is widespread confusion regarding applicable security standards for these systems. Those who deploy these systems are thus much more likely to deploy them in a manner that makes them even more vulnerability to attack.
There are no easy solutions for the problems with SCADA vendors that I have described. The best approach would be for SCADA system customers to deal with SCADA system vendors with a unified voice. At a minimum, organizations that deploy these systems must exert much greater pressure on vendors to do better when it comes to security in their products. When potential customers are evaluating potential products, security-related selection criteria must be included, and these criteria must also be sufficiently heavily weighted. Insisting on indemnity clauses in purchase contracts would also go a long way in increasing vendor responsibility with respect to responding to vulnerabilities. And if vendors remain unresponsive, the US government needs to step in by creating and enforcing special regulations that apply to the SCADA arena to protect public safety. We’re sitting on a time bomb here, so to speak, leaving little room for more vendor indifference and inaction regarding security issues.