It has always amazed me how the application vendors for control systems software will speak about implemented architectures differently depending on who they are addressing. When talking about security they will clearly hype the "closed nature" of the environments and describe the barrier that should be deployed to prevent exposure, yet when talking to the business and information management folks they describe the open accessibility and features for virtually unrestricted information flow. After all, ICCP was designed to bridge systems to allow control centers, often from different companies or organizations, to share supervisory and control data records across disparate networks and telecommunications architectures. So, the argument that the industry needs to build barriers and then fix the problems is short sighted.

As for the "obscurity" part of the problem... It's a myth that should be shattered so that real discussions can continue. These systems are only obscure and unknown to someone who hasn't researched them. Standards are published for protocols. Many vendors provide reference implementations, api's, software libraries, and documentation. In many cases these things are available on websites. Regardless of whether the information is limited to customers only it should be assumed that these things are available to anyone that really wants them. Additionally, SCADA, Process Control (PCS) and Distributed Control Systems (DCS) are used so widely that anyone that wants to can get access to some version of the target system to work with most certainly can. As the article implies, utility companies and medical equipment use these technologies. But they didn't mention building environmental controls, gas stations, waterways management, shipping companies, airports, and just about any other large automated system that bridges the human world with the electronic. Most municipalities in the modern world having some connection to a water company, sewage treatment facility, electric company, gas company, etc., all using SCADA technology. There are too many people and points of access to honestly believe that any type of system can remain obscure. There should be no doubt that a determined attacker can become knowlegeable by compromising the trust boundaries of those facilities. They can become employed, break-in and steal necessary information/access. They can hack systems and remotely access the necessary systems. Regardless of how it can be done, it is easily done by a determined attacker. The only thing that obscurity provides for security is reduce the inadvertent compromises that occur. I'm ashamed that anyone would even acknowlege this to be of some benefit to the security of the system.

When we assume that an attacker doesn't already know more about the vulnerabilities in our systems then we do, then we set ourselves up for making bad security architecture decisions and losing the edge that comes from an appropriate level of paranoia.

As for the disclosure issue, when companies choose to keep vulnerabilities secret and not discuss them with the oversight organizations responsible for monitoring networks for potential attacks they eliminate the ability to be warned when an attack is occuring. And it will occur. I can appreciate limits on public disclosure, but I thought that this was the exact problem that the ISACs were supposed to resolve. That is, allowing organizations: law enforcement, counter-intel, industry groups, etc., to be able to have open discussions about security issues, including vulnerabilities.

In all, we've come a long way, but there is so much more to learn. SCADA Vendors would do good to look to the models of companies like Cisco, Oracle, Sun, Microsoft (man I hate including them, and IBM. These companies have all wrestled with these problems and most have come up with workable solutions. Clearly some have done better then others, but the SCADA vendors need to get out of the 1980's and join the modern world here.

Dion

[ reply ]

Link to this comment: http://www.securityfocus.com/comments/articles/11396/33901#33901