Saturday, 24 September 2011

FACT CHECK - SCADA is online now

A recent "Fact Check" by Scot Terban requires some fact checking.

In his post, he basically shows that he has no idea how many SCADA systems are online. Scot stated "How about the fact that said systems are connected to the internet on a regular basis and SCADA aren’t", well this is a flaw and error of epic magnitude.

The fact is, nearly everything is connected now.

In 2000 I contracted to the Sydney Olympic authority. To make the Olympics run smoothly, they NSW government officials decided to connect control systems into a  central head-quarters. We linked:
  •          Traffic systems
  •          Rail systems
  •          Water systems
  •          Power systems
  •          Emergency response systems / Police
  •          Sewerage systems
That was only the tip of the iceberg. The rail systems had been connected to report on rail movements. They used a Java class file that was set to read the signals devices. The class was not protected, but the read only status was considered sufficient (despite protests to the contrary).

The control class file was easy to reverse engineer and it was simple to toggle the controls in order to make it into a system that could send signals as well as report them. When I noted that I could reverse engineer the class file, the comment was "not everyone has your skills Craig, we do not think others can do this". Yet it is simple to reverse engineer a Java class file.

Once the Olympics ended, so did any funds to maintain the system. Nothing was done to remove the inter-connectivity, it was considered valuable, but like all systems that are not maintained, it has slowly become less and less secure.

These network remain connected even now, though many of the people involved in setting them up have left. In fact, many of these networks are not even documented and known by the current people in the various departments.

Two years ago, I was involved in a project to secure SCADA systems that run and maintain a series of power plants. This was canned. Not for funds, but as the SCADA engineers did not trust that firewalling their network would not have a negative impact. Right now, the only controls are routing based. Unfortunately, they also allow ICMP route updates, access from the file servers and source routing. Some of the systems are running on Windows 98, not XP, 98. The need for a zero-day does not exist, just some knowledge of the internal routes in the system.

Unfortunately the routes and network design of this organization (running a large percentage of power stations in NSW) was leaked in a vendor presentation - so it is also not difficult to obtain. It does take some effort to become knowledgeable about the systems and how they are run (and to not simply crash them) but the ISO 20000 processes are stored on the same network.

Let us see some other systems.

A while back now, but many of the same systems are in place in the same way, I was contracted to test the systems on a Boeing 747. They had added a new video system that ran over IP. They segregated this from the control systems using layer 2 - VLANs. We managed to break the VLANs and access other systems and with source routing could access the Engine management systems.

The response, "the engine management system is out of scope."

For those who do not know, 747's are big flying Unix hosts. At the time, the engine management system on this particular airline was Solaris based. The patching was well behind and they used telnet as SSH broke the menus and the budget did not extend to fixing this. The engineers could actually access the engine management system of a 747 in route. If issues are noted, they can re-tune the engine in air.
The issue here is that all that separated the engine control systems and the open network was NAT based filters. There were (and as far as I know this is true today), no extrusion controls. They filter incoming traffic, but all outgoing traffic is allowed. For those who engage in Pen Testing and know what a shoveled shell is... I need not say more.


Nearly all SCADA systems are online. The addition of a simple NAT device is NOT a control. Most of these systems are horribly patches and some run DOS, Win 95, Win 98 and even old Unixs. Some are on outdated versions of VMS. One I know of is on a Cray and another is on a PDP-11. The last of these has an issue as they do not believe it will ever restart if it goes down. So that PDP-11 is not touched. We scanned a system at that network a couple years back and it crashed, the answer was that we could not ever ping the PDP-11 as it was thought it could also crash.

Yes Scot, Windows XP and unpatched networks are a concern, but they are less of a concern than those systems that are connected to the world and which control physical systems.

Right now, the Commonwealth government here in Australia has a project to connect to IPv6 by next year. It is mandated. I have been traveling and presenting to many departments in the last few months for this reason. Even with all the good standards from DSD, few of the people who are tasked with implementing these systems knew that IPSec supports a NULL cipher. The DSD standards do say that you cannot use NULL as a cipher, but the awareness is only starting to grow (hence a very busy schedule actually talking to people in a number of government departments and letting them know these things).
Next year, we will have IPv6 starting to become the norm in the Australian Commonwealth Government and in time, it will be all there is. This starts with a IPv4-IPv6 gateway and transition project, but that is only the start and soon others will have to switch as well. Soon (and this is within 5 years), SCADA systems will be connected on IPv6 networks here in Australia. 

IPv6 is distributed. There are no crunchy firewalls on the outside and even NAT offers little. Scott (and others who run some of these systems), I suggest that you have a look at how things are really configured.

On another note, I look forward to seeing those in Melbourne next week at BOM when we have our IPv6 workshop. If you have a read of the DSD guidelines first, it will add further value to the session.

About the Author:
Craig Wright is the VP of GICSR in Australia. He holds both the GSE, GSE-Malware and GSE-Compliance certifications from GIAC. He is a perpetual student with numerous post graduate degrees including an LLM specializing in international commercial law and ecommerce law, A Masters Degree in mathematical statistics from Newcastle as well as working on his 4th IT focused Masters degree (Masters in System Development) from Charles Sturt University where he lectures subjects in a Masters degree in digital forensics. He is writing his second doctorate, a PhD on the quantification of information system risk at CSU.

1 comment:

Keith said...

Great rant. I've run into the same thing many times over. The words physical and logical have lost meaning for a lot of people today.

I worked in an environment where there was one 'physically separate' network. As I came to know the network administrator better over time and continued to work with him on the connectivity I had a need to put a device on that network to provide monitoring. Lo and behold he let me know I could save some money and he could put a firewall rule in place to allow the device back to the main network.

A simple explanation of the difference between a firewall (logical) and air-gap (physical) brought the language in line but it took a lot longer to air gap the network.