Why Stuxnet has changed the security landscape

Author : Chris Evans, Mitsubishi UK

03 May 2011

In the past, there was often a divide between the IT department and the control engineering department in a typical end user business.

Moreover, control engineers were able to operate largely ‘under the radar’ as long as they followed some basic configuration rules as set down by their IT counterparts.
The IT department in most large businesses would claim to have made the ‘business systems end’ of the enterprise secure to the outside world. Often the control level could operate in its own world, maybe with dedicated LANs connecting the control system level to the visualisation or gateway level (often called the MES Level).

It was only above the MES level that the IT department would be interested and would dictate how and in what format data would be transferred from the gateway PC to the business level systems.

Maybe the theory had always been that any malicious attack on the business would enter from the ‘top down’ and the IT department would be confident that they had enough measures in place at the top to stop this happening.

However, the same level of IT security was not always deployed at the control level due to issues of performance etc. Once a control level project has been implemented, for example on a typical manufacturing plant, it is generally left alone especially if it continues to operate day in day out. This can leave legacy operating systems on gateway PCs that do not carry the latest service packs to keep the operating systems up to date from a security standpoint.

What has changed our perception of business security and the way we deal with a malicious attack has been the experience gained from the Stuxnet malware incident.
Because the target of this attack was the automation system components the point of entry was not the business level but the MES Level.

It is common practice for an MES level gateway PC to have a SCADA system installed, but equally these control stations can contain the programming environment for the PLCs down on the plant. If the malware writer can infiltrate this level and corrupt the actual PLC program then they have the ability to disrupt the operation at the plant level.

This has moved the focus of the issue of security firmly into the control level environment and at first glance, equally between the automation engineers and their colleagues in IT. This will not sit well with either group, as one group does not want to interfere and one group does not want interference.

The challenge for automation suppliers in the future will be to offer solutions which are not susceptible to these attacks. We need to challenge the typical topology of the typical manufacturing environment. Why is it necessary to have a PC with a Windows operating system acting simply as a bridge between the plant and enterprise levels? The answer normally is that we need SCADA and we need data collection, data logging and links to the enterprise level that a typical control system cannot usually provide, or certainly not in a cost effective way.

When we analyse those requirements it really means that we need visualisation and we need methods of data collection and logging, plus the ability to present the data in a suitable way to the enterprise level.

There are various ways to realise those requirements that don’t necessarily require a PC and Windows. It is fair to say that if other solutions can be found that are more hardware based then they offer a system that is inherently more robust and less susceptible to malware writers who naturally favour standard operating systems such as Windows as they represent easier targets.

It will be very interesting to see how automation suppliers react in the coming months and the smart companies either already have these alternative solutions or are currently developing them.


Contact Details and Archive...

Related Articles...

Additional Information...

Print this page | E-mail this page