If they are running their Industrial systems on Windows then this bug is hardly something to be worried about compared with the well known risk of their whole system crashing or freezing.

A SCADA network can be compromised by either a technical DOS attack on core software or by a compromised control computer (or even operator)

A reliable solution to the problem is isolating the SCADA network from externalities that can compromise the system. This means control computers for a SCADA system have no electronic path to non-SCADA system networks and that SCADA network control computers have no means to load/run unauthorized software.

If these ideals are realized then the only risk is compromised operators.

Now the reality may well be that most SCADA networks have security holes. This is the more interesting story, not the vulnerability of a specific software application to failure due to compromised control computers.

lol windows, nuff said really.

True - but most ethernet HMI interfaces and PLCs can be now be remotely edited, (rockwell studio se for instance), which leads to the boxes running them being on the corporate net, so the lazy automation engineer can do it from his desk. So you may not be able to crash the actual IO networks, but you can certainly get to processors and HMIs.

I've worked on just about the largest scada systems in the world, and not ever, ever, ever, after working in Georgia, Kazakhstan, Azerbaijan, Turkey, UK, UAE etc etc have I EVER EVER encountered a system that is connected to any kind of public network - be that Internet or Intranet. They always run on totally closed private networks.

This is a minor minor minor issue. There's more risk from a fuse blowing in a switch than there is from this. No news here. Move along please.

Guys,

There has already been a patch released for this issue, this can be grabbed from the Wonderware website.

You are quite correct, most are private networks, all the rest are usually behind a few very tightly controlled firewalls (cross-system communicates for example) and providing they haven't been designed/implemented by muppets should be relatively secure from outside influences, but there are always exceptions, so ideally the software should still be secure.

More concerning in my view is the serial protocols mangled for use on TCP/IP usually without using SSL or similar, and the physical security of the RTUs/PLCs as a lot are on unmanned sites and the security of the devices are not usually as secured as the masterstations are (the device and comms lines may be in some secure place however).

Upgrading may not always be the easiest thing, which may explain why some systems are running "old" versions, depending on if the software used supports redundant masters across different versions the whole system may have to be taken down for an upgrade. Sometimes downtimes for upgrades need to be planned well in advance as so what could be described by someone as a "simple security fix" may not get the attention it perhaps should get.

Bollocks on the Bollocks.

I'm sorry to flame, but I've encountered a number of SCADA systems connected to intranets and (stating the obvious) said intranets were connected to the internet. Yes, the regulatory (control networks) are generally segregated, but the supervisory (SCADA) is on the corporate intranet all the time. I'll grant you that traditionally, we as automation professionals (especially back in the DCS world of 10 years ago) generally discouraged customers from having interconnected networks. However, times have changed and I would be surprised if more than 20% of new installations (and that 20% would just about all be small stand-alone facilities) are built based on a closed network. The genie has been out of the bottle a while here and the OEMs have been playing (much-needed) catchup to adjust to the changes in the way automation solutions are implemented. Large corporations want (and need) access to the data provided via their SCADA systems for real-time applications such as MES/ERP, dash-boards, etc.

Thankfully, most of the integrated networks of any size are implemented with network segregation via routers, layer 3 switches, etc., - that should generally prevent DOS attacks from an outside source (assuming your network equipment hasn't been penetrated).

The key is to use some intelligence in implementing your network solution. Well, that and screaming at the OEMs to actually hire protocol & security experts for their software development. Now that the networks are integrated, the OEMs have to fight the same IT battles as anyone else. Similarly, automation professionals have to be even more dilligent to make sure that the code in their DCS/PLC/PAC is capable of running independently/safetly if the SCADA fails.

P.S. - PLCs/PACs/DCSs have Ethernet ports (and associated vulnerabilities too).

P.P.S. - To the MS haters - Oddly enough, SCADA workstations running on MS Windows rarely crash as long as they are only running OS + SCADA software. The issues normally only arise when the operator loads other crap on the machine and tries to run it simultaneously... Less MS's issue - more 3rd party apps.

2 Cents Delivered. Flame away.

Well said!

My own employer simply changes the terms of warranty for network-connected boxes to exclude unknown/internet attacks. Let the owner beware.

What should also be noted is that this is only for the HMI - the actual control and monitoring tends to be done in a different box running an appropriate OS (OK I've only ever used Wonderware to monitor Triconex ESD systems). The result of crashing the Wonderware instance is similar to turning the monitor off on your PC - irritating but hardly critical.

When exploits start appearing for the DCS or ESD logic solvers, then I'll panic.

Cimplicity FTW

The one with GEF on the back