How secure is your Automation System architecture?

Last year’s incident involving the Stuxnet malware has shown that a typical automation architecture has weak points and vulnerabilities when it comes to security and this is leading many companies to question the traditional methods used to move information around and from the plant/asset to the enterprise level. While Stuxnet was targeted at one particular plant, it has far wider implications.

The stuxnet virus changed the point of attack in the business from the seemingly very secure top end to the somewhat vulnerable middle ground. So, are we seeing the start of a revolution?

Certainly, when business managers understand the implications of “doing nothing” then it is inevitable that changes to system architectures will follow.

Stuxnet was a malicious and targeted attack, which is very difficult to protect against.

The structure of the virus is now in the public domain, so mutations of stuxnet remain a threat and it is realistic to assume that ‘copycat’ malware will appear in the coming years targeted at a whole range of plant and applications.

However most incidents are not as sophisticated as Stuxnet, but they can still have wide ranging consequences for the businesses under attack.

There are two fundamental factors to consider, “probability” and “risk” and it is the analysis of these two elements which should shape any organisation’s security strategy going forward.

It is generally accepted that “gateway PCs” found in many automation architectures, represent weak points and are vulnerable to potential malware attacks from “the outside” and also from CDs and USB sticks.

Many of these PCs are used as networked workstations and therefore often contain the software to change and program the PLCs beneath this layer. This makes them an attractive target for anyone wishing to disrupt operations. Couple to this is the fact that many of these PCs have in the past been poorly maintained in terms of security patches and often contain unsupported legacy versions of operating systems, raising the risk factor considerably.

These gateway PCs were originally included to provide visualisation/control (SCADA etc), data/alarm logging and the link between the plant/asset and the enterprise systems. Initially PLC technology was not capable of delivering these requirements in an acceptable way, in other words, there was no alternative to this architecture.

Clearly from an operational point of view, these requirements are still fundamental delivery points for any system architecture but there are now alternatives to the traditional methods.

Mitigation or Change?:
Many IT security companies can provide products and services to mitigate against attacks on PC based systems. These solutions are fine and coupled with a good business security regime can help protect the perceived weak points in any architecture.

However it is important to understand that many of the recent cyber security offerings in the automation arena have concentrated on dealing with the problem rather than exploring how to minimise the problem happening in the first place!

A New Way Forward:
Over the last few years the more innovative companies have been developing technology which challenges the traditional automation architecture, so that they can offer a robust environment whilst delivering the operational requirements needed.

The basis of the new approach is to develop a solution which offers direct connection from the plant/asset to the enterprise systems within a ruggedized industrial form factor.

These systems are non PC based and are therefore not susceptible to the same operating system legacy issues that are found in a traditional PC based system.

This is complemented by the simultaneous development of intelligent solutions to provide data and alarm logging to be carried out locally at the PLC.

This technology has created the possibility of removing the gateway PC from the topology altogether. “But what about visualisation and control?” I hear you ask.

Well this is a fair question and there is no crusade here to remove SCADA/visualisation from the system but there are other ways of achieving the same criteria.

If data and alarm logging is happening directly at the PLC, then visualisation and control could be achieved by intelligent HMIs. Significantly, these HMIs do not have to be running a Windows operating system.

If SCADA PC nodes simply must exist, then moving the critical data/alarm logging to the local PLC means that the SCADA node can be the control and visualisation element of the system, whilst protecting this vital information in a more robust PLC environment. This is a simple but effective change in architecture that offers a viable alternative to traditional methods.

Mitigation techniques can then be deployed to minimise the risk with respect to the PC based SCADA or visualisation system. By using these techniques and technology the link between plant/asset and the enterprise can be achieved directly from the PLC level, thus minimising the risk.

Best of Both Worlds:
It would appear that, as is often the case, the best approach to this new generation of malware threat is a multithreaded combination of a good set of mitigation techniques and “best practices” with a willingness to look at new innovative architectures to achieve the operational requirements but also reduce the inherent risk. Perhaps more than ever, good advice from acknowledged experts, an open mind, and awareness of current and potent new issues are critical.