Last year’s incident involving the Stuxnet malware showed
that a typical automation architecture has weak points and
vulnerabilities when it comes to security. This is leading
many companies to question the traditional methods used
to move information around and from plant/asset to
enterprise level. Chris Evans of Mitsubishi Electric explains

While Stuxnet was targeted at one
particular plant, it has far wider
implications. It has given us a
wake-up call and we now need to take a fresh
approach to how data is transferred and
managed within all industrial control
systems. 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.

While most incidents are not as
sophisticated as Stuxnet, they can still have
wide ranging consequences for the business
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.

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 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 been poorly
maintained in terms of security patches and
often contain unsupported legacy versions of
operating systems, raising the risk factor.

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. From an operational point of view,
these requirements are still fundamental
delivery points for any system architecture,
but now there are alternatives.

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.

New way forward
Over the last few years some companies have
been developing technology that challenges the
traditional automation architecture, so that they
can offer a robust environment while 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
rugged 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. 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
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, while protecting vital information
in a 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 appears that the best approach to this new
generation of malware threat is a multi-threaded
combination of a good set of mitigation
techniques and best practices with a willingness
to look at new architectures to achieve the
operational requirements and reduce the
inherent risk. Good advice from acknowledged
experts, an open mind, and awareness of
current and potent new issues are critical.