Smarter Grid … Struggling SCADA?

In June of this year, the FBI arrested a hacker named Jesse McGraw (aka "GhostExodus") for installing malicious software on a couple of systems at a hospital in Texas. He didn't crack some protocol or breach a server, he allegedly walked around in his security guard uniform and a "hoodie" with a USB drive carrying malware. An ultimate insider.

The entire episode can be found in a very readable account at the website of the somewhat eponymously named Wesley McGrew, who actually located and identified McGraw after a relatively short period of social network mashing, Googling, and just good, old-fashioned rational thinking. (For those of you with eye-strain from concentrating on the Smart Grid Security Blog, there is also a very good podcast interview with McGrew by Michael Farnum at An Information Security Place.)

The story has been told in multiple places, and was widely covered in local media at the time, but in doing some research today on SCADA vulnerability and exploitability, there were items in the complaint, in the write-up, and in the comments (some of them quite scathing) from the hacker's cohorts to McGrew's account of the events, that made me think of the SCADA security challenges associated with the new Smart Grid environment in some different and more urgent ways.

What Once Was Old Is Old Again
It is not news that components of SCADA systems can be older and have been designed for reliability and stability on mainly protected networks populated with trusted people. In discussing his motivations for researching the attacker, and for calling the authorities, McGrew cites his current doctoral research in information security, particularly in SCADA security. When he discovered that the attacker had installed botnet software on a hospital HVAC system, his level of urgency shot up. He feared that even modest corruption of that system could cause real danger to patients, at one point referring to SCADA systems of the type as a sort of "rickety ensemble" of old and new pieces, which could not be expected to withstand much tinkering.

He is not alone in this expectation. In a presentation back in 2007, delivered at HITBSecConf2007 Malaysia, called "Hacking Scada," other statements supported this fear, including the fact that ordinary antivirus software could be expected to crash many SCADA systems due to the increased load, and that simple utilities like "ping" had been shown to bring those assets down.

As an IT person coming to utilities, I had expected vulnerability, but did not expect the real fragility in these important systems.

HMI by DIY
I was also surprised to learn that many of the front-ends (HMI or Human-Machine Interface systems) of these newer SCADA implementations are actually created on-site. Think of it as a Do-It-Yourself graphical user interface. This is necessary, in as much as most of them are actually doing extremely custom things. The presence of different sensors, different arrangements, different control structures, demand that the interface itself be created in a way that is very much tailored to the environment that is actually going to be managed.

I learned this while researching the new importance of the Internet protocol and even web-oriented interfaces, as components in the HMI interfaces of these systems. Packages actually ship with IDEs (Integrated Development Environments) containing libraries and widgets necessary to create useful, functional, and hopefully intuitive representations of the complex system of sensors, RTUs, PLCs, and more. It is not clear how seriously security is regarded in the creation of these custom interfaces, or how simple it can be to enable security controls available through the IDEs. It appears that there exist few standards and fewer tools relating to their certification.