BDEW White Paper in practice: IT security in the secondary systems

Dr.-Ing. Michael Conrad, IDS GmbH, D- 76275 Ettlingen, Germany

Dr.-Ing. Ralf Thomas, IDS-Gruppe Holding GmbH, D-76275 Ettlingen, Germany

Summary / Abstract
The extensive use of automation systems for monitoring / controlling hundreds of thousands of devices for the produc-
tion, transport and distribution of energy is a result of the growth of the renewable energy sector in Germany. Exchange
of data between field units and central control centers will be carried out on IP-based infrastructure. Those units are a
new part of the critical infrastructure in terms of IT security.
This paper provides a practical insight into the implementation of IT security mechanisms for remote terminal units and
SCADA systems (secondary equipment) in accordance with the BDEW white paper "Requirements for Secure Control
and Telecommunication Systems" [1]. It also presents an evaluation of a variety of tools, protocols and procedures in
terms of technical and organizational feasibility.

1 Introduction and Motivation

Smart Grid and smart metering are based on society’s ef-
forts to replace nuclear power, the development of renew-
able energy and the liberalisation of energy markets. High
investments into decentralised power systems, substation
automation and the monitoring of distribution networks
are expected for the next years. This calls for the ability to
control network components for the purpose of optimal
power management, taking into account the volatility of
the renewable energy systems. Therefore a comprehen-
sive expansion of IP-based communication structures is
necessary. Due to the requirement for low infrastructure
costs, the use of existing public communication networks Figure 1 Structure of future telecontrol systems
and protocols is recommended.
Secondary equipment of distribution network operators Existing telecontrol systems, as shown on the left, for the
becomes part of the critical infrastructure and must be monitoring and control of classic utility systems (electric-
protected against manipulation by external attackers. In ity, gas, water) usually have a multi-layer and strictly hi-
document [1], the basic requirements for IT security are erarchical structure. At the head of the system are one or
defined by German energy suppliers. This leads to formal several SCADA systems which contain the central moni-
requirements for communication security, data security toring and control functions and which act as interface to
and system security for secondary equipment. The white humans. The SCADA systems are connected to the RTUs
paper does not provide instructions and concrete solutions via one or several telecontrol gateways. A telecontrol
(tools, protocols, procedures). Implementations made by gateway acts as communication link to the higher-level
RTUs and carries out the aggregation of process data.
manufacturers need to be evaluated by experts with par-
There are usually several levels of RTUs below the tele-
ticular emphasis on security, until standard specifications
control gateway. These levels are based either on the
(e.g. ISO 27019 [2]) become available.
structure of the communication systems in use, or on
functional interdependencies. A typical example of func-
2 Structure of existing and future tional interdependencies is the substation automation of
power grids: e.g. there are several RTUs in a transformer
telecontrol systems station which also exchange information amongst each
The significant increase in renewable and decentralized other. Usually one RTU acts as data exchange frontend
energy suppliers and the need for the monitoring and con- for all RTUs of the substation.
trol of power systems is leading to changes in the struc- In the past, security requirements on the classic telecon-
ture of the associated telecontrol systems. The structure of trol systems were usually rather modest because those
“classical” and of future telecontrol systems is shown side systems were installed and operated in a secure environ-
by side in Fig. 1. ment, using a purely private communication infrastructure
for data exchange. The current security discussion has 3.1 Relevant aspects
highlighted the increasing security requirements even for
Apart from general security demands on organization,
those telecontrol systems; an upgrade of those systems in
documentation and emergency planning, especially para-
terms of security, however, has not yet been demanded.
The expansion of renewable energy and the concomitant graphs 2.2, 2.3 and 2.4 of the BDEW white paper contain
emergence of distributed energy resources (DER) is in- a number of technical security requirements that are par-
creasing the likelihood of less complex telecontrol sys- ticularly important for RTUs and SCADA systems. These
tems, as shown on the right-hand side of Fig. 1. Instead requirements, in terms of functionality, can be subdivided
of a multi-layer hierarchical structure, the new telecontrol into three groups (see [1] section):
systems usually have a very flat structure. At the head, Device security (2.2.1, 2.2.2, 2.4.1, 2.4.2)
there are still SCADA systems; communication with the Communication security (2.3.1, 2.3.2, 2.3.3, 2.4.3)
different RTUs also takes place via telecontrol gateways. Data security (2.1.1.6, 2.1.1.10, 2.4.5, 2.4.6)
Below these gateways, however, there is no further hier- The term “device security” refers to the protection of the
archical grading – in terms of communication, all RTUs actual RTUs or the SCADA system. It is important to
are arranged directly below the telecontrol gateway. Fur- prevent attackers from obtaining unauthorized access to
thermore, there is no functional interdependence between systems or subsystems. This applies both to process inter-
the different RTUs. faces and to service and diagnostic interfaces. The device
In contrast to existing telecontrol systems, it is safe to as- in question has to provide protective mechanisms against
sume – due to the high number and geographic distribu- simple denial-of-service attacks, otherwise the attacker
tion of distributed systems – that future telecontrol sys- may be quick in preventing the execution of planned
tems will include a considerably higher number of RTUs. functions.
For reasons of economy they will be based on public IP- “Communication security” refers to protective measures
based communication infrastructures (internet, mobile for the exchange of data between RTUs or between RTUs
networks). One can expect that the demands on operation and SCADA systems. The two foremost requirements are
security for those systems will increase considerably. On
the integrity and authenticity of data; it must be possible
the one hand, the distributed structure of RTU systems in
to detect without a doubt whether data have been manipu-
some cases precludes their operation in a secure environ-
lated or whether data have been exchanged with unauthor-
ment. On the other hand, the fact that communication be-
tween the telecontrol gateways and the different RTUs ized communication partners. Depending on the applica-
takes place via public communication infrastructure sig- tion scenario, the confidentiality of data may also be an
nificantly reduces information security and renders it vul- issue.
nerable to attacks. Apart from device and communication security, data se-
Our analysis shows a high security demand for both types curity will also play a major role in the future. Data secu-
of telecontrol systems. Existing telecontrol systems oper- rity includes protection of data outside a secure transmis-
ated in a secure environment have to be protected also sion environment, which is the case, for instance, with the
against attackers as future large distributed telecontrol persistent storage of data or event logging. Similar to the
systems using public communication infrastructure. protection of data during transmission, it is vital to ensure
the integrity, authenticity and confidentiality of data.
Further security requirements, such as the availability and
3 BDEW White Paper robustness of the communication infrastructure, are not
Subsequent to preparatory work by the energy supply highlighted in this paper because those security require-
company RWE AG, the German Association of Energy ments have to be fulfilled by the respective infrastructure
and Water Industries (BDEW) published the BDEW itself.
white paper “Requirements for Secure Control and Tele-
communication Systems” [1] in 2008. This document 4 Device security
contains security requirements from different realms
(computer systems, communication, application and de- Device security is the main security objective. If device
velopment). Additionally, it includes requirements on the security is insufficient, even a high degree of communica-
documentation of various processes, such as data backup, tion or data security becomes useless. Attackers could
data restoration and emergency planning [3]. compromise the respective device and directly read or
Taking the requirements of this white paper into account, manipulate data. To ensure a sufficient degree of device
the owners of telecontrol systems shall be enabled to pro- security, at least the following demands must be fulfilled:
tect their systems against typical attacks and to issue con- System hardening
trolled responses to security incidents [4]. In contrast to Access control
existing norms or standards, the BDEW white paper does Communication control
not prescribe any special procedures or protocols, giving
greater leeway for the fulfilment of the outlined security
requirements.
4.1 System hardening Apart from ensuring a viable access control, it is of fore-
The objective of system hardening is to minimize the vul- most importance to deactivate or delete unused service
nerability of RTUs or SCADA systems and to provide a access to ensure a high degree of device security.
maximum degree of basic security.
As part of the development process, it must be verified 4.3 Communication control
whether security gaps are known with regard to the appli- In contrast to access control, communication control is
cation components to be installed; if this is the case, it another way of increasing device security. For this pur-
must be checked whether a newer version for the compo- pose, the communication capabilities of a device within a
nent in question is available. This check should be carried telecontrol system are reduced to such an extent that
out at recurring intervals and should therefore be included communication can be established only with specified
in the development process. Additionally, it is necessary communication partners. Although this no absolute pro-
to check for security gaps in operating system compo- tection against attackers, this measure makes attacks sub-
nents. If desired, the typical server systems (Windows, stantially more difficult because intruders can no longer
Linux) automatically provide security updates of operat- initiate their attacks from any given position within the
ing system components. However, these functions are of- network.
ten not available for embedded systems used by RTUs. The limitation of the communication capabilities of a de-
Prior to their application, all services there are not re- vice can be easily implemented by means of a packet-
quired for specific tasks within a telecontrol system must based firewall which is executed on the device itself. Con-
be deactivated on the respective devices. This includes, on figuration of the firewall can be done in two different
the one hand, general services which are usually never ways. With a static configuration, and depending on the
required anyhow; on the other hand, it is also possible to application scenario, access to specific services is limited
activate or deactivate services depending on the respec- using port numbers and network interfaces. If access to a
tive application scenario. service via a specific network interface is permitted, this
Ensuring the system and application components and the service can be used by any given communication partner.
active services are up to date, system hardening also in- With a dynamic configuration, services are enabled in the
cludes making security-relevant system settings, such as, firewall only for the respective communication partners
for instance, prescribed authentication procedures, per- that are identified by means of their IP address. The bene-
missible protocol versions or settings regarding the scope fit of this method is that the service in question cannot be
and complexity of user passwords. used by any communication partner at will.
For Windows-based systems, Microsoft offers different Moreover, a firewall can also be used to restrict access to
profiles of system settings with graded security settings insecure services which may not include a functional ac-
which can be used as required or can be expanded in ac- cess control themselves.
cordance with one’s own regulations. Additionally, tools
are available for standard server systems that enable the
administration and integration into systems of the respec- 5 Communication security
tive profiles. Unfortunately, the communication protocols used in cur-
rent IP-based telecontrol systems (e.g. IEC 60870, IEC
4.2 Access control 61850, Modbus TCP) do not provide their own security
Apart from system hardening, access control to all ser- functions which fulfil the requirements on authenticity,
integrity and confidentiality. In order to ensure the re-
vices provided by a device is an important aspect when it
quired communication security despite these shortcom-
comes to ensuring a high degree of device security. The
ings, it is necessary to employ extra methods. One obvi-
task of access control is to permit the utilization of a
ous method is therefore the use of existing and well-
given service only to authorized persons or communica- proven security protocols which ensure the secure trans-
tion partners. mission of data via insecure communication infrastruc-
In the case of RTUs where no interactive access is made tures.
during normal operation, access control has to regulate Possible candidates to ensure the security of insecure
access of other RTUs or SCADA components. communication procedures are the following protocols:
Unfortunately, the majority of telecontrol protocols that IPsec
are in use nowadays are not include access control func- OpenVPN
tions. Therefore, access control often can only be imple- TLS
mented in connection with additional security protocols The well-known and widely used point-to-point tunnel-
(e.g. TLS). Furthermore, it is vital to ensure sufficient ac- ling protocol (PPTP), in connection with the authentica-
cess control for the available service and diagnostic inter- tion method MS-CHAPv2 was not considered in this pa-
faces. With SCADA systems, access control of users is as per due to security gaps with regard to authentication. The
necessary as is access control of other SCADA compo- examined protocols hardly differ from the purely crypto-
nents. For the access control of users, it is important to graphic methods. All those methods are capable of using
ensure suitable authentication procedures. standard algorithms (e.g. AES, SHA) for the encryption
and security of data. However, these protocols differ with
regard to their scope of functions and the administrative Unlike IPsec and OpenVPN, the focus with TLS is on the
effort. protection of individual TCP-based communication con-
nections; this protocol, however, does not enable the es-
5.1 IPsec tablishment of virtual private networks. For UDP-based
The security extension IPsec of the well-known Internet communication, the protocol Datagram Transport Layer
Protocol (IP) was introduced in 1998, last revised in 2005 Security (DTLS) - based on TLS – is available.
and published as RFC 4301 [5]. In contrast to most other TLS operates between the transport layer (TCP) and the
methods for secure data transmission, IPsec operates di- application layer, thus protection extends only to the ap-
rectly at the network layer of the ISO/OSI reference plication data. However, this has the advantage that TLS
model and thus allows for a completely transparent ap- can be implemented directly within the application and is
proach to secure data communication. IPsec defines sev- not dependent on the support of the subordinate operating
eral protocol headers that are inserted after the IP protocol system. In addition, when using TLS, no administrative
header. access to the operating system is required.
IPsec supports secure data exchange between several IP Therefore, TLS is ideally suited to upgrade existing tele-
networks to build a virtual private network (VPN), as well control protocols to achieve the desired security features,
as the protection of individual communication connec- without having to make major changes to the basic sys-
tions. Due to the implementation within the network tem. The use of TLS for TCP-based telecontrol protocols
layer, there are problems in connection with NAT (Net- is described in the standard IEC 62351 [7].
work Address Translation), which can be solved only by When establishing a TLS connection, the two communi-
an additional encapsulation of IPsec traffic within a UDP cation partners negotiate the cryptographic method to be
communication connection. In addition to the IP protocol used (so-called cipher suite) and authenticate to each
stack, the deep integration of IPsec requires an extensive other based on X.509 certificates. The authentication the
administrative access to the operating system. server to the client is mandatory, the authentication of the
Unfortunately, IPsec itself does not contain mechanisms client as against the server is optional. At the same time
for the authentication of communication partners and ne- the connection-specific pre-master secret is generated dur-
gotiation of key material in establishing a secure connec- ing the negotiation. From this, the key material is derived
tion. For this task, the Internet Key Exchange protocol subsequent to protect the application data.
(IKE) is normally used. It supports the negotiation of key
material and the password- or certificate-based authenti- 5.4 Conclusion
cation. The older version IKEv1 in turn has problems with To fulfil the requirements of communication security
NAT scenarios, but in the current IKEv2 these problems there are multiple options. The use of VPN tunnels to se-
have been remedied. cure data transmissions is transparent to applications, but
requires administrative access to the operating system. In
5.2 OpenVPN contrast to VPN tunnel TLS or DTLS will be applied on
OpenVPN provides an alternative to the rather complex application level and do not require administrative access
combination of IPsec and IKE. OpenVPN also allows the to the operating system, but can only secures a dedicated
construction of secure virtual private networks; however, communication channel.
it uses TCP or UDP for data exchange, therefore the NAT At the beginning of implementing communication secu-
problem is eliminated. For the connection of secure com- rity for telecontrol components, it is easier to use VPN
munication channels, OpenVPN uses the TLS protocol, tunnels. All communication connections using the VPN
which is briefly introduced in the following section. tunnel will be protected and no changes to the different
Through the use of the TLS protocol, OpenVPN - unlike applications are necessary. For dedicated protocols (i.e.
IPsec - already includes mechanisms for authentication IEC 60870-5-104) an implementation of (D)TLS makes
and key negotiation and therefore requires no additional sense in a second step.
components or protocols. Integration into the respective
operating system takes place by means of a virtual net- 6 Data security
work interface. For this purpose, administrative access to
the operating system is needed; this procedure, however, Even though data security currently is not regarded as im-
is not as deep as when using IPsec. portant as device and communication security, its impor-
tance is expected to increase in the future. Data security
refers to the protection of data that are stored or processed
5.3 TLS
on the systems that are being considered. In contrast to
Originally developed under the name Secure Socket device and communication security, there are practically
Layer (SSL), this protocol has been developed since the no common procedures or standards for the implementa-
late nineties by the IETF under the name of Transport tion of data security, therefore scenario-specific solutions
Layer Security (TLS) and is currently available in version are usually employed.
1.2 in RFC 5246 [6].
In the application scenario of a telecontrol system, the fol- thus making sure that they can be unambiguously as-
lowing data requiring an increased degree of protection signed at all times.
could be identified:
Configuration data
System and application files 7 Implementation and experience
Event data The following chapter provides a brief description of ex-
periences made in the course of the preparation and audit-
6.1 Protection of configuration data ing of a telecontrol system that consists of SCADA and
In our present application scenario, configuration data are telecontrol components, in accordance with the BDEW
understood to mean information that is used for the con- white paper. In the security audit an application scenario
figuration of an RTU or of a SCADA system. In order to of a substation automation system consisting of several
ensure sufficient protection against attacks on configura- field units of type ACOS 750 and the SCADA system
tion data, it is vital to ensure the authenticity and integrity HIGH-LEIT from the company IDS GmbH was in-
of the data in question. In some instance, it may also be spected. Furthermore, the findings made during this proc-
necessary to ensure confidentiality of the data. ess and the future proceedings based on these findings are
There are two different approaches to ensure data authen- illustrated.
ticity and integrity. Exclusively on the basis of crypto-
graphic hash functions, it is possible to use a simple ap- 7.1 Auditing in accordance with the BDEW
proach which includes a secret in the calculation of the white paper
hash value (HMAC), thereby ensuring the authenticity
In the course of an auditing procedure in accordance with
and integrity of the data. A likelier approach, however, is
the BDEW white paper through a German transport net-
based on asymmetric encryption methods. Here, the au-
work operator (TNO), the software development also fo-
thenticity and integrity of data is ensured by means of a
cussed on the implementation of the necessary security
digital signature. In both cases, data confidentiality can be
functions as per the middle of 2012. The first step in-
realized through the use of a symmetrical encrypting
cluded analysis of the actual status in comparison to the
method.
requirements of the BDEW white paper, both with regard
to the installed SCADA system components and the tele-
6.2 System integrity control components. Initially, the emphasis was on device
The concept of data security stipulated by the BDEW and communication security.
white paper is not limited to the data that are processed or To increase the security device was also tested in addition
stored in an RTU, but also applies to the RTU’s software to the timeliness of the software components used, if rele-
components because otherwise attackers would be able to vant vulnerabilities were known. If necessary, compo-
able to modify the respective components without being nents were updated or the affected functions were deacti-
noticed, and to successfully start and attack directly from vated if they were not required for operation. Whereas
the RTU. system hardening on the Windows-based SCADA com-
For this reason, it is important to perform a periodical in- ponents was comparatively easy thanks to given and
tegrity check of software artefacts on the devices, for in- manually expanded system profiles and already existing
stance by means of the OSSEC software. This software is tools, it required significantly more effort on the embed-
available for a number of operating systems, enabling – ded telecontrol components. On both systems, services
amongst others – integrity checks of system components. that were no longer required were deactivated, and all un-
Moreover, it supports the secure transmission of integrity used user accesses were checked and – wherever possible
check results to a central system where these results can – removed. To reduce communication capabilities, fire-
be further processed. walls were used both for the SCADA and the telecontrol
system components. For the firewall on the RTUs, a static
6.3 Event data protection configuration was used initially because this method
Apart from ensuring the security of configuration data and could be implemented without major interventions into
software components, the secure storage of event data is the telecontrol software and the configuration tool.
also of vital importance. Event data refer to incidents (e.g. To archive communication security, a VPN solution was
failed log-in attempts) during normal operation. These favoured to protect access to service and diagnostic inter-
data must be stored and secured against modification, faces; this solution realizes protection independently of
since otherwise attackers are able to delete or modify the current application and thereby renders modifications
them, thereby suppressing the registration of attacks. of the existing software systems unnecessary. Further-
Similar to the protection of configuration data, it is advis- more, the secure VPN tunnel enables the simultaneous
able to use digital signatures to ensure the authenticity protection of several communication links. The VPN so-
and integrity of event data. For this purpose, event data lution was also favoured for communication links for the
are signed using the key material of the respective device, exchange of process data because the use of an external
VPN component also ensures backward compatibility
with already existing systems.
With regard to data security, the existing integrity check 8 Summary
designed for the detection of errors during the transmis-
sion and storage of configuration data was expanded by a The above actions and moderate cost system security in
secure authenticity and integrity check. Even though the several layers can be significantly increased (Fig. 2).
device configuration could be viewed via the plain text, it
was possible to clearly detect any unauthorised modifica-
tions.
In the course of further product development of the tele-
control components, the static configuration of the fire-
wall was replaced by a dynamic configuration in 2013;
with this new configuration, the firewall rules were
matched exactly to the actual communication relation-
ships of the respective devices. Furthermore, protection of
the device configuration was expanded to ensure confi-
dentiality. In this context, the initial operation process had
to be expanded by a secure initial configuration in order
to enable the secure installation of key material on RTUs.

7.2 Public key infrastructure Figure 2 Layers of security for secure communication
During the implementation of the various security func-
In particular, the main tasks of device security and com-
tions for the auditing of SCADA and telecontrol compo-
munications security could be implemented with stan-
nents, it quickly became clear that the use of crypto-
dardized and available methods. There are open questions
graphic certification material was an unavoidable neces-
in the field of data security, since no common standards
sity. Although it is true that several protocols provide
are available and questions about the provability of proc-
mechanisms for the authentication of communication
ess actions (e.g. command output to switchgear) are to be
partners without certification material, they require, on
expected in the future.
the whole, more costs and effort for the administration
and storage of authentication information. Moreover, it is
possible to archive a number of security requirements for 9 References
data security on the basis of certificates.
[1] White Paper "Requirements for Secure Control and
Therefore – and despite the complexity of certificate-
Telecommunication Systems", BDEW - Federal As-
based systems – it was decided to prefer the aforemen-
sociation of Energy and Water Industries, Berlin,
tioned authentication approaches. For this purpose, X.509
06/2008
was selected as a suitable certification standard because it
[2] ISO / IEC TR 27019 - Information technology - Se-
is supported by several authentication methods (e.g.
curity techniques - Information security management
HTTPS, IPsec/IKE, OpenVPN, TLS) and because there
guidelines based on ISO / IEC 27002 for process
are commercial providers for certificates and the neces-
control systems specific to the energy industry
sary administration software. (DRAFT), Geneva / Switzerland: Bureau Central de
Unfortunately, an analysis of existing providers for X.509 la Commission International Electrotechnical
certificates has shown that the certificates offered by them
[3] Execution instructions on use of the BDEW White
are not suitable for telecontrol systems. Apart from the
Papers "requirements for safe control and telecom-
costs, the main point of criticism is the short validity pe- munication systems" in the field of protection and
riod of a public X.509 certificate. This period covers only control systems, Dortmund: Amprion GmbH, 2010
a few years and is in conflict with the planned product
[4] Testing Guide for BDEW white paper "requirements
lifecycle of telecontrol systems. Whereas an exchange of
for safe control and telecommunication systems" in
the existing certification material every 24 months might the field of protection and control systems, Dort-
be acceptable for central control system components, this mund: Amprion GmbH, 08/2010
is absolutely not feasible with regard to distributed RTUs,
[5] RFC 4301 - "Security Architecture for the Internet
both with regard to time and costs.
Protocol", IETF, 12/2005
An alternative would be to use of certificates provided by
[6] RFC 5246 - "The Transport Layer Security (TLS)
a self-operated certificate authority or to choose a special
Protocol Version 1.2", IETF, 08/2008
certificate provider who offers suitable certification mate-
rial with a sufficiently long validity period. The operation [7] ISO / IEC TS 62351:2007 - Power systems man-
of one’s own certification infrastructure, however, causes agement and associated information exchange –
Data and communications security, Geneva / Swit-
considerable problems, particularly for the owners of
zerland: Bureau Central de la Commission Interna-
small-scale telecontrol systems.
tional Electrotechnical