Curing a SCADA Trojan

There is an interesting article over on HomelandSecurityNewsWire.com about some recent (7-22-10) information from Siemens on the Stuxnet Trojan. It includes a valuable link to the Siemens web site on the problem, but that is not what people are going to remember this article for. The title is what all of the non-SCADA folks are going to target on; “Removing SCADA trojan may disrupt power plants”. Update Testing This is based upon the simple comment from the Siemens web site that says: “As each plant is individually configured, we cannot rule out the possibility that removing the virus may affect your plant in some way.” Of course, anyone that knows anything about industrial control systems knows that this is one of the main problems with installing any kind of update on the system. Every facility should have a virtual image of their ICS on a stand-alone system to test the installation of any update to see how it will interact with the various devices installed at that facility. This is one of the basic problems that IT folks have with understanding control systems. There are just too many devices that rely on specific links, channels and protocols to operate properly to allow an untested change to be made on the system. In an IT system if an update wipes out an IP address for a printer, there will be no production down time while it is re-installed. That is not the case with an ICS. Software Security Testing The other comment that should draw some attention in this article is this quote from Chris Wysopal of Veracode “Software customers that are operating SCADA systems on critical infrastructure or their factories with the WinCC software had a duty to their customers and shareholders to not purchase this software without proper security testing.” This, of course, begs the question of what protocol or standard should a facility use to conduct such ‘security testing’. While I understand that there may be methods to conduct such testing (don’t ask me what, how I’m a chemist) most facilities do not have in-house software engineers to conduct the testing. Even if there were a legal requirement for facilities to conduct such testing, I don’t believe that there are enough qualified personnel in the world to conduct such evaluations at the facility level. What is needed is the establishment of an industry wide standard for SCADA software security. Software producers could then certify their software against that standard and facilities could require that certification as part of their software purchase requirements. Failure of the software to provide that level of security protection would allow action against the supplier. While there are a variety of efforts to accomplish the standard setting, there has been little push by users to require the second. One of the advantages of having the very public discussion about the Stuxnet Trojan is that there should be more of a customer interest in SCADA security. Another way to accomplish this end is for the government to require such certification of control system software in regulated industries. While this is in process (?) for the power industry there has been little movement in this direction for high-risk chemical facilities mainly because DHS lacks the authority to do so.