Security for automation systems using risk analysis techniques
Linking, open standards, interfaces and PC based technologies are constantly increasing in industrial automation.
The threat potential of attacks and malware - such as Stuxnet and many others - is increasing at the same time,
making security very important in both office IT and industrial networks. Risk analyses, writes Franz Köbinger, help
you decide which protection is sufficient at which cost without limiting availability and manageability.
EXPERIENCED SECURITY experts are stressing
the fact that security is not a single feature
but a complete process. This means that
individual security measures, security functions
or devices do not offer comprehensive
protection but several components usually have
to act in unison. These components have to
be amended and supported by organisational
and possibly physical protection measures, such
as access controls. Even comprehensive security
measures have to be evaluated and adjusted
from time to time to adapt to the changing
The same applies to network security and that
includes all networks, regardless of whether
they are office, automation or infrastructure,
such as the energy industry.
Because the threats and risks are different in
each system and network because of their
different designs, tasks and operating
conditions, there are differences in the type
and priority of protection targets, and in the
protection measures chosen as a result.
To make a sound decision about which
security measures will be implemented, it is
first necessary to analyse those existing risks
that cannot be tolerated. It is then necessary
to derive protection targets, and from these,
the concrete measures that can and should be
implemented. If risk analysis and determination
of the protection targets are neglected or
not carried out, there is a great risk that inappropriate,
overpriced and ineffective measures
are taken, while weak points are not detected
Fig. 1. Plant security acceptable risk v unacceptable
risk: This shows a decision matrix for the evaluation of
risks following a plant-specific risk analysis.
The typical contents of a risk analysis (see
Figure 1) include:
• Identification of threatened objects
• Analysis of value and damage potential
• Threat and weak point analysis
• Identification of existing security measures
• Risk evaluation
Identified and unacceptable risks must be
excluded and reduced using suitable measures.
Which remaining risks are finally acceptable
must be determined individually for each application,
because there is no absolute security
without risk. The goal must be to minimise the
risks in an appropriate and affordable way.
Security and automation
The special requirements of automation systems
must be taken into consideration when
designing security measures. Typically, the
'Security Policies' of commercial IT environments
cannot easily be implemented into the
automation arena because there are significant
differences between office and industrial environments.
Availability is usually the first security goal
in an automation environment. Confidentiality
is usually less important, because plant
standstill or downtime generally have far more
serious consequences than the possible loss of
data. For the same reason, the timely patching
of automation computers is often problematic.
A patch must be tested for compatibility, which
is time-consuming. Even then, the patch
cannot necessarily be uploaded when needed,
or when the plant is operating.
Another example of the differences is the fact
that the life cycles of production plants are
much longer than those of classical IT.
Automation life cycles can be 10, 15 or even
30 years, so updates and the removal of
security gaps and the necessary support of
manufacturers for these devices is often no
longer available and weak points can no longer
be removed. This clearly calls for other external
protection measures to be established in
production plants, which means that the
requirements regarding availability and performance
limit the use or acceptance of security
policies from classical IT networks - and to
some extent even requires new or partially
Industrial security concepts
A number of threats exist for automation
networks: viruses, worms, trojans, so-called
malware, access violations to networks and
devices by (internal and external) unauthorised
personnel, espionage and manipulation of data
during transmission or in devices. Each of these
threats requires special countermeasures.
Virus protection. Virus scanners are usually
deployed against malware, but they cannot
guarantee complete protection because no virus
scanner can detect all viruses. In addition,
where new viruses are concerned - especially
in connection with zero-day exploits, which
take advantage of a security vulnerability - it
always takes time for the corresponding
updates to be made available for virus scanners.
Then there is the problem that automation
computers cannot be updated at just any time,
for example, during ongoing operation, and
that compatibility with used applications must
be ensured, which usually results in further
delays. Depending on the maintenance cycle,
it may be months before an update can be
Because of such virus scanner limitations,
whitelisting systems represent an alternative.
Whitelisting means that only specific, approved
applications and services may run on a
computer. Even if a virus enters a computer
unnoticed, any action of the virus is blocked
because its actions are not listed as permitted
(whitelisted) operations. This approach offers
protection even against unknown viruses.
Computers in an automation environment are
not updated with new applications as frequently
as in a classic IT environment, which means it
is even easier to update whitelisting systems.
Network segmentation/cell protection. Only
a few automation devices offer sufficient
integrated security functions; a fact that will
not change any time soon because of their long
life cycles. Even though ever more devices are
being equipped with security functions by
manufacturers, there will always be devices
that do not offer any security functions for cost
optimisation or other reasons.
Additionally, there may be some cases in
which real-time requirements do not allow the
use of performance-intense security functions
such as encoding or secure authentification.
Even so, such devices must also be protected.
As early as 2005, the PNO recommended the
cell protection concept in its Profinet Security
Guideline to meet these requirements.
The idea is simple. Use a security appliance,
which is an especially toughened network
component that comes equipped with security
functions including firewall and VPN. These
appliances, also referred to as security modules,
protect automation devices by being installed
upstream and representing the only access to
the protected equipment. The secured area is
also referred to as a cell and corresponds to a
network segment, usually an independent
subnet. This approach segments the network
for security reasons.
The firewall can now control access to the
cell and users can specify which network participants
can communicate with each other, and
perhaps even the protocols they use in the
process. Such an approach prevents unauthorised
access and reduces the network load
because not all communication, e.g.,
broadcasts (messages to all network participants),
may take place.
The security modules can also set up secured
VPN channels with each other so that communication
from and to the cells is encrypted and
subject to secure authentification. This
approach protects data transmissions against
manipulation and espionage.
The advantages are obvious - a security
module can protect several other devices, which
means that users don't have to install and
administer this function in each device. Realtime
communication within the cell is not affected by
performance-intense security functions and
access to the cell is still protected.
The size of a cell or the type of network
segmentation depends on the network design
or topology, as well as the risks and protection
targets. These should be determined using a
risk analysis. Bear in mind that the security
module cannot control the data traffic within
the cell, so local access within the cell must
not happen or must only be used by authorised
personnel, which means that it must be
protected by other means.
Figure 2 shows the protection of automation
devices with the through cell protection
concept using security modules.
Fig. 2. The protection of automation devices: the through-cell protection concept using security modules
All access to a network must be checked so
that unauthorised people cannot gain entry.
In addition to secure remote maintenance
access and secure connections to other
networks, it is also necessary to take into
consideration the ports of switches and routers
- these must at least have appropriate access
lists that specify which devices, or which MAC
or IP addresses, may connect to which ports.
Many switches support the IEEE 802.1x
standard in which an authentication server
queried by the switch checks the authentication
of participants wanting to connect to a
port. Depending on the access right(s), the
network component can grant access to the
authenticated participant - even to a specific
VLAN - if necessary, so that the participant does
not have access to all devices in the network.
Terminal security. It is not always possible
to use the same cell protection concept. This
may be because of the network topology or
specifically created application-specific access
rights. Some devices have to be able to protect
themselves for this reason. Communication
participants wanting to communicate with the
device have to authenticate themselves directly
on the device in this case, for example, using
Application-specific access rights can be
implemented in the form of several protection
levels that can distinguish between read-only
and write access, for example, by assigning
different passwords for each protection level.
Fig. 3. A model of a multi-level security concept: This
creates as many layers as possible between the outside
world and the machine/plant to be protected, and
combines several security measures
Toughening of products
The measures described above are all 'active',
meaning that they correspond to specific
security functions. However, even more security
can be added by using only toughened
products. Toughened here means products that
had been checked for possible weak points
during development by the manufacturer, with
those weak points being subsequently removed
so that hackers or malware cannot take
advantage of them.
Several security measures are required to reduce
the risks. They are used as supplements,
because not every measure works against every
threat, and because they set up more hurdles
that possible attackers will have to overcome.
Such a strategy is referred to as 'defence in
depth'. However, all these measure are not
going to be very effective if they do not work
alongside appropriate organisational measures
which control the physical access, for example,
or prescribe the use of secure passwords.
Franz Köbinger is system manager for security at
Siemens Industrial Communication and head of the
Profinet Security working group.