Power Grids

RTU500 series - Remote Terminal Units

Security Deployment Guideline Release
13
User manual
Revision

Document identity: 1KGT151106 V005 1

Revision Date Description
1 10/2020 Initial version for Release 13
2 02/2021 Updated chapter 'External Certificate' (PI#170985)
3 06/2021 Updated 'Appendix A' (PI#180168)
07/2021 Added chapter 'Backup Management' (PI#181881)
Added chapter 'Decommissioning' (PI#180359)
Reorganized chapter 'Ethernet Interfaces' (PI#181803)
08/2021 Added chapter 'Certificate Revocation List (CRL)
Upload' (PI#183367, PI# 183364)
Updated chapter 'CAM Management' (PI#183361)
Updated chapter 'Virtual Private Network with RTU500 internal Func-
tionality' (PI#183361)
Updated chapter 'Secure Web Server Access' (PI#183359)
Updated chapter ‘Local User Account Management’ and ‘Certificate
Upload’ (PI#183362, PI#183365)
4 09/2021 Added chapter 'Secure Update' (PI#125435)
Updated chapter 'Encryption Algorithm' (PI#184124)
5 05/2022 Added chapter 'Authentication' and 'User Authority Certifi-
cate' (PI#187865)

This product includes software developed by the OpenSSL Project for use in the OpenSSL Toolkit.
(http://www.openssl.org/)

This product includes cryptographic software written by Eric Young (eay@cryptsoft.com)

Contents

Contents

1 Introduction............................................................................................................................. 5
1.1 References..................................................................................................................... 5

2 Secure Access........................................................................................................................ 7
2.1 Secure System Setup....................................................................................................7
2.1.1 Virtual Private Network with external devices............................................... 7
2.1.2 Virtual Private Network with RTU500 internal Functionality.......................... 8
2.2 Ethernet Interfaces.........................................................................................................9
2.2.1 Network Stack................................................................................................9
2.2.2 Denial of Service......................................................................................... 14
2.3 Integrated Firewall....................................................................................................... 14
2.4 Encryption Algorithm....................................................................................................15
2.5 Intended Use................................................................................................................16

3 Local User Account Management...................................................................................... 17

3.1 Design Principles......................................................................................................... 17
3.1.1 Account Information.....................................................................................17
3.1.2 Account Permissions................................................................................... 18
3.1.3 User Roles................................................................................................... 20
3.1.4 Local user accounts.................................................................................... 21
3.1.5 Password File.............................................................................................. 23
3.2 User Interface.............................................................................................................. 24
3.2.1 RTUtil500 configuration............................................................................... 24
3.2.2 User Authentication..................................................................................... 25
3.2.3 Local user account management................................................................ 25
3.2.4 Security Policies.......................................................................................... 26
3.2.5 Modification of User Accounts.....................................................................30
3.2.6 User Roles................................................................................................... 35
3.2.7 Password file management......................................................................... 36
3.2.8 Password file harmonization........................................................................37
3.3 Recommendations....................................................................................................... 40

4 Central user account management.................................................................................... 41

4.1 Design Principles......................................................................................................... 41
4.1.1 Account Information.....................................................................................41
4.1.2 Account Permissions................................................................................... 42
4.1.3 User Roles................................................................................................... 42
4.1.4 User authentication......................................................................................44
4.1.5 CAM server public key certificate................................................................44
4.1.6 CAM integration........................................................................................... 45
4.2 User Interface.............................................................................................................. 47
4.2.1 RTUtil500 configuration............................................................................... 47
4.2.2 User Authentication..................................................................................... 50
4.2.3 CAM Management.......................................................................................50
4.2.4 Change user password............................................................................... 57

1KGT151106 V005 1 I
 Contents

5 Security event logging.........................................................................................................59

5.1 Security event format...................................................................................................59
5.2 Security event types.................................................................................................... 59
5.3 View security events....................................................................................................62
5.4 Supervisory monitoring: security indications and alarms............................................ 64
5.5 External log servers.....................................................................................................64

6 Secure Web Server Access.................................................................................................67

6.1 RTUtil500 configuration............................................................................................... 67
6.2 Web server user authentication...................................................................................69
6.3 HTTPS Web server access......................................................................................... 71
6.4 Certificate handling...................................................................................................... 72
6.4.1 Self-signed certificate.................................................................................. 73
6.4.2 External Certificate...................................................................................... 74

7 Certificate Management....................................................................................................... 77
7.1 Certificate Upload........................................................................................................ 77
7.1.1 Users Authority Certificate...........................................................................80
7.2 Certificate Revocation List (CRL) Upload................................................................... 80

8 IEEE 802.1X Port-based Network Access Control............................................................ 85

8.1 Technology Overview...................................................................................................85
8.2 EAP (Extensible Authentication Protocol)................................................................... 85
8.3 RTUtil500 configuration............................................................................................... 86
8.4 Certificate upload via the RTU500 Web server...........................................................86

9 System Hardening................................................................................................................ 89

10 Patch Management............................................................................................................... 91
10.1 General Information..................................................................................................... 91
10.2 Release Policy............................................................................................................. 91
10.3 Update Policy...............................................................................................................91
10.4 Recommendation by Hitachi ABB Power Grids.......................................................... 92
10.5 Patch installation..........................................................................................................92

11 Secure Update.......................................................................................................................93
11.1 Design Principles......................................................................................................... 93
11.2 Enabling and Management..........................................................................................93
11.3 CMU Firmware Update................................................................................................94
11.4 Vendor Root Certificate Life Cycle.............................................................................. 94
11.5 Reset to Factory Default............................................................................................. 95

12 Backup Management............................................................................................................97

13 Decommissioning................................................................................................................. 99

14 Compliance Statement IEEE 1686.................................................................................... 101

14.1 Electronic Access Control..........................................................................................101
14.2 Audit Trail................................................................................................................... 101
14.3 Supervisory Monitoring and Control.......................................................................... 102

II 1KGT151106 V005 1
Contents

14.4 Cyber Security Features............................................................................................103

14.5 Configuration Software.............................................................................................. 103
14.6 Communications Port Access....................................................................................104
14.7 Firmware Quality Control...........................................................................................104

15 Compliance Statement IEC 62443-4-2.............................................................................. 105

15.1 FR 1 – Identification and authentication control (IAC).............................................. 105
15.2 FR 2 - Use control (UC)............................................................................................105
15.3 FR 3 – System integrity (SI)......................................................................................106
15.4 FR 4 – Data confidentiality (DC)............................................................................... 107
15.5 FR 5 – Restricted data flow (RDF)........................................................................... 107
15.6 FR 6 – Timely response to events (TRE)................................................................. 107
15.7 FR 7 – Resource availability (RA).............................................................................107
15.8 Embedded device requirements (EDR).....................................................................108

16 Appendix A..........................................................................................................................109
16.1 A.1 Export CAM Server Public Key Certificate on Windows..................................... 109

17 Glossary...............................................................................................................................117

1KGT151106 V005 1 III

 Contents

IV 1KGT151106 V005 1
Introduction References

1 Introduction
1.1 References
[1] IEC 62443-4-2

Security for industrial automation and control systems – Part 4-2: Technical security
requirements for IACS components

Edition 1.0 2019-02

[2] IEC 63443-3-3

Industrial communication networks – Network and system security – Part 3-3: System
security requirements and security levels

Edition 1.0 2013-08

[3] IEEE 1686

IEEE Standard for Intelligent Electronic Devices Cyber Security Capabilities

2013-12
[4] IEC 62351-3

Power systems management and associated information exchange – Data and

communications security - Part 3: Communication network and system security – Profiles
including TCP/IP

Edition 1.0 2014-10

[5] IEC TS 62351-5

Power systems management and associated information exchange – Data and

communications security – Part 5: Security for IEC 60870-5 and derivatives

Edition 2.0 2013-04

1KGT151106 V005 1 5
References Introduction

6 1KGT151106 V005 1
Secure Access Secure System Setup

2 Secure Access

2.1 Secure System Setup

As a communication gateway the RTU500 series connects a control system with a directly
connected process or with subordinated devices. The connection to the control system can be
serial point to point or Ethernet network based.

• Only some Ethernet communication protocols supported by the RTU500 series provide
authentication or encryption of the communication (e.g. HCI and BCI IEC60870-5-104 according
to IEC62351-3, HCI DNP3 according to IEC62351-5).
• The access from the Integrated HMI is protected by authentication but the communication is
done with a not encrypted proprietary protocol.

These security drawbacks are acceptable in limited local networks. For wide area networks
in particular with connection to the Internet, additional configurations are required to increase
protection and privacy for the RTU500 series Ethernet communication. This requirement could be
fulfilled by a secure Virtual Private Network (VPN) configured with external devices or RTU500
series internal functionality.

The RTU500 series Web server access is protected by authentication and with secure HTTPS
communication. In the default setup the Web server communication is HTTPS.

The goal of network security is to provide confidentiality, integrity and authenticity:

• Confidentiality (keeping the data secret from the unintended listeners on the network)
• Integrity (ensuring that the received data is the data was actually sent)
• Authenticity (providing the identity of the endpoint to ensure that the end point is the intended
entity to communicate with)

2.1.1 Virtual Private Network with external devices

The figure below shows a possible system setup in schematic form.

1KGT151106 V005 1 7
Secure System Setup Secure Access

Figure 1: RTU500 series secure system setup with external VPN device

In this system setup the achieved protection and privacy is accomplished by

• A secure VPN uses cryptographic tunneling protocols to provide the intended confidentiality
(blocking intercept and thus packet sniffing), sender authentication (blocking identity spoofing),
and message integrity (blocking message alteration).
• A firewall to block unauthorized access while permitting authorized communications.

The security guide line cannot suggest concrete products for a secure system setup. This must
be decided along the specific project, requirements and existing infrastructure. The required
external equipment can separated devices or devices that combines firewall, router and secure
VPN functionality.

2.1.2 Virtual Private Network with RTU500 internal Functionality

The RTU500 series Virtual Private Network protocol implementation provides a standard method for
transporting IP datagrams over a secured communication channel. The used technique for creating
VPNs in RTU500 series is IPsec.

With the help of VPN a RTU can be connected to control system via the public internet. The data
exchange is secured via the VPN connection. From the user point of view it looks like the RTU500
series resides within the NCC network.

The following picture shows a typical configuration:

Figure 2: RTU500 series secure system setup with internal VPN interface

8 1KGT151106 V005 1
Secure Access Ethernet Interfaces

The RTU establishes a VPN connection to the IPsec Router. The VPN tunnel (red line) connects
the virtual RTU network with the NCC network. Therefore a network-to-network connection is
established. This connection is transparent and secured.

If a connection is established, the RTU can be accessed by a control system using the internal
virtual IP address. All IP based protocols can run on this connection.

The RTU500 series supports two authentication methods:

• Pre-Shared Key (maximum length is 64 characters)

• X.509 Certificates

When X.509 Certificates method is used, certificates can be revoked using certificate revocation list
(CRL). If used certificate is revoked during normal operation VPN connection is closed immediately.

The RTU500 series supports the following features:

• Perfect Forward Secrecy: IKE performs a new DH exchange when rekeying the IPsec SAs
• Dead Peer Detection (DPD): a traffic-based method of detecting dead peers
• UDP Encapsulation and NAT-Traversal: enabling IPsec packets to traverse NAT devices

The RTU internal firewall discards all packets which are not related with the VPN tunnel except
HTTPS when enabled.

For more detailed information about VPN functionality in RTU500 series, see RTU500 Series
Function Description - Part 9: Interfaces and networks (1KGT151103).

2.2 Ethernet Interfaces

2.2.1 Network Stack

2.2.1.1 TCP/UDP Ports

To setup an Ethernet firewall the following table summarizes the TCP ports used in the RTU500
series. The ports are listed in ascending order. The column “Default state” defines whether a port
is open or closed by default. All ports that are closed by default are opened by configuration or by
online enabling.

Port Protocol Default state Service Comment

80 TCP closed HTTP Web server
102 TCP closed IEC 61850 Communication protocol
123 UDP closed SNTP Time synchronization
161 UDP closed SNMP Supervision client
443 TCP open HTTPS Web server
500 UDP closed IKE ISAKMP packets
502 1 TCP closed Modbus TCP Communication protocol
514 UDP closed Syslog External security log server
1793 TCP closed RIO server Server for protocol logging
2000 UDP closed DNP3 Communication protocol
2404 TCP closed IEC60870-5-104 Communication protocol
Table 1: Ethernet ports used in RTU500 series

1KGT151106 V005 1 9
Ethernet Interfaces Secure Access

Port Protocol Default state Service Comment

4500 UDP closed IKE ISAKMP NAT-T packets
5007 UDP closed IEC 61850 Debug trace port
5014 TCP closed Syslog/ArcSight External security log server
17185 UDP closed VxWorks Tornado debug port
199981 TCP closed IEC60870-5-104 Secured communication
20000 1 TCP closed DNP 3 Communication protocol
20547 TCP closed ProConOS PLC program
500011 TCP closed HMI Local HMI
Table 1: Ethernet ports used in RTU500 series

1 Configurable
The detail information about each port could be found in the next chapters. The ports are grouped
according the purpose.

2.2.1.1.1 Separation of Network Interfaces

In case the CMU of an RTU500 provides more than one Ethernet interface, a network functionality
can be assigned to a single interface or to several interfaces. In both applications the ports of the
network functionality are opened on the assigned interfaces only. On the other interfaces the ports
are still closed. This behavior is achieved by the internal firewall of the RTU500 series.

2.2.1.1.2 Communication protocols

The RTU500 series supports several Ethernet communication protocols. These protocols are
IEC 61850, Modbus TCP, IEC60870-5-104 and DNP3. All these communication protocols are
enabled by configuration. That means the TCP port of a protocol is closed and not available if
the configuration of the RTU doesn't contain a communication line of the protocol. If a protocol is
configured the corresponding TCP port is open all the time.

Please refer to the RTUtil500 Users Guide and the corresponding protocol documentation on how
to configure a certain communication protocol for the RTU500 series.

There are some restrictions and dependencies:

• The TCP ports used for Modbus TCP, DNP3 and secured IEC60870-5-104 communication line
are configurable (in RTUtil500). The values in the table above are the default values defined in
the protocol standard.
• The TCP ports used for IEC 61850 and IEC60870-5-104 are fixed and could not be changed.
• The communication protocol DNP3 could operate on UDP (default port 2000) or TCP (default
port 20000). It is defined in the configuration which type of Ethernet protocol is used. Only one
type is possible for a specific configuration.
• The debug trace port for IEC 61850 (port 5007) is not required for the normal protocol
communication. That means a firewall can block this port without backlash to the protocol
communication. The trace port is used for commissioning and error detection. The IEC 61850
debug trace port is closed by default and must be opened for logging within the RTU500 web
server.

10 1KGT151106 V005 1
Secure Access Ethernet Interfaces

2.2.1.1.3 Central user account management

Besides the local user account management (LAM) the RTU500 series supports a central user
account management (CAM). In this setup the RTU500 series acts as client to an external CAM
server that manage all user accounts within a system.

The CAM client can be configured as functionality in the RTU. The functionality is assigned to one
or more CMU Ethernet interfaces in a RTU. Only if the CAM client is configured on a CMU module
the TCP port of the LDAP service is open on that CMU interface. On all other CMU interfaces the
port is closed. If a CAM client is configured the corresponding port is open all the time. The default
port for the LDAP service is 389.

Please refer to chapter "Central user account management" for detailed information about the
functionality and the configuration of the central user account management.

2.2.1.1.4 Web Server

The Web server is enabled by default on each Ethernet capable CMU of an RTU. In a multiple CMU
system the Web server can be disabled by configuration on selected CMU’s. In this case the HTTP
and HTTPS TCP ports are closed. At least on one CMU the Web server must be enabled to be able
to access the RTU. This requirement is enforced by the configuration tool RTUtil500.

To provide encryption and secure identification in the communication to the Web server the RTU500
series supports Hypertext Transfer Protocol Secure (HTTPS). This option is enabled by default. See
chapter "Secure Web Server Access" for more information.

The Web server uses only HTTPS port and optional the HTTP and HTTPS port can be activated.
No other ports are required by the RTU500 series Web server.

The Web server requires the following technical features that must be supported and enabled by
the used Web client:
• HTTP 1.1
• HTML5
• CSS3
• JavaScript 1.8
• WebSocket
• HTTP Digest Access Authentication
• HTTP session cookies

In case of HTTPS access the Web client must support:

• HTTPS via TLS 1.2

Recommended as Web clients are:

• Google Chrome 70.0 or higher
• Microsoft Edge 40.0 or higher
• Mozilla Firefox 63.0 or higher
• Opera 53.0 or higher

The access to the RTU500 series Web server is protected by an authentication request for user
name and password. In case the local user account management is used for authentication, HTTP
Digest Access Authentication (DAA) protects the Web server access. DAA ensures that the user
credentials are encrypted secure before sending over the network. Detailed information about DAA
could be found in RFC2617 "HTTP Authentication: Basic and Digest Access Authentication".

1KGT151106 V005 1 11
Ethernet Interfaces Secure Access

If a central user account management server is configured the access to the Web server is
protected by a HTTP form-based login dialog. In this case user credentials are not encrypted
before sending over the network. For this setup secure Web server access via HTTPS is highly
recommended securing the transmission of the user credentials.

When HTTPS is configured it is possible to configure the authentication not only with a password,
but also with a client certificate.

The administration of local user accounts is done in the RTU500 series Web server. See chapter
"Local User Account Management" for more information.

If the Microsoft Internet Explorer is used as Web client the advanced option "Show friendly HTTP
error messages" shall be disabled. Without this option the detailed error information of the RTU500
series Web server are shown. The option can be found in the "Advanced" tab of the "Internet
Options".

2.2.1.1.5 Integrated HMI

The Integrated HMI can be configured as functionality in the RTU. The functionality is assigned to
one or more CMU Ethernet interfaces in a RTU. Only if the Integrated HMI is configured on a CMU
module the TCP port of the HMI is open on that CMU interface. On all other CMU interfaces the port
is closed. If an Integrated HMI is configured the corresponding port is open all the time.

Please refer to the RTUtil500 Users Guide and the Integrated HMI documentation on how to
configure the Integrated HMI for the RTU500 series.

2.2.1.1.6 User logging/debug interface

The RTU provides functionality to support the user in installation and commissioning. These are a
functionality to monitor communication protocols (RIO protocol logging) and a programmable logic
controller (PLC) for user written programs. Both functionalities use an Ethernet connection with the
defined services (see table above). The following rules apply for the connections:

• The access to both functionalities is disabled by default and the corresponding TCP ports are
closed.
• The access could be enabled in the RTU Web server. In this case the TCP port became open
and an online connection could be established. The access is enabled for a specific CMU only.
• The access is disabled again if the online connection is closed or a fix timeout of 30 minutes is
expired. By disabling the TCP port became closed.
• The administrator can prohibit the access to both functionalities. That means it is not possible to
enable the functionality. See chapter "User Interface" for information how to prohibit the access.
• The RIO protocol logging is available on every CMU independent from the configuration.
• The PLC debug interface is available only if a PLC is configured on a CMU. If not access is not
possible and the corresponding Ethernet port is closed.

Please refer to the RTU500 series Web server documentation on how to enable the access to the
RIO protocol logging and the PLC debug interface.

2.2.1.1.7 Time synchronization

The RTU500 series supports SNTP time synchronization as client and server. By configuration
the functionality is assigned to one or more CMU Ethernet interfaces in an RTU. Only if an SNTP
client or server is configured on a CMU module, the TCP port of SNTP is open on that CMU
interface. On all other CMU interfaces the port is closed. If an SNTP client or server is configured
the corresponding port is open all the time.

12 1KGT151106 V005 1
Secure Access Ethernet Interfaces

Please refer to the RTU Function Description for detailed information about the SNTP time
synchronization.

2.2.1.1.8 Network management

For supervision of network devices the RTU500 series support SNMP as client. By configuration the
functionality is assigned to one or more CMU Ethernet interfaces in an RTU. Only if an SNMP client
is configured on a CMU module, the TCP port of SNMP is open on that CMU interface. On all other
CMU interfaces the port is closed. If an SNMP client is configured the corresponding port is open all
the time.

Please refer to the RTU500 series Function Description for detailed information about the SNMP
client functionality.

2.2.1.1.9 External Security Log Server

Security relevant user operations within the RTU are logged as security events. These security
events can be sent to external security log servers. The RTU500 series supports the following
protocols/ports for external log servers:

• Syslog UDP via configurable port (default port = 514)

• Syslog TCP via configurable port (default port = 5014)
• ArcSight TCP via configurable port (default port = 5014)

By configuration the support of external log servers is assigned to one or more CMU Ethernet
interfaces in an RTU. Only if an external log server is configured on a CMU board, the TCP port of
the protocol is open on that CMU interface. On all other CMU interfaces the ports are closed. If an
external log server is configured, the corresponding port is open all the time.

Please refer to chapter 'Security event logging' for detailed information about external security log
servers.

2.2.1.1.10 Developer debug interface

For maintenance purposes the RTU supports two developer debug interfaces. The first is an
interface to the RTU firmware via the operating system VxWorks. The second interface is for
monitoring the IEC 61850 communication (IEC 61850 debug trace interface). These interfaces allow
direct access to the RTU on firmware level. The interfaces permit monitoring and manipulation.
Therefore the interfaces must be handled with extremely caution.

The following rules apply for the developer debug interfaces:

• The debug interfaces are not required for the RTU functionality. Therefore a firewall must block
the corresponding Ethernet ports.
• The access to the debug interfaces is disabled by default and the corresponding TCP ports are
closed.
• The access could be enabled in the RTU500 series Web server. In this case the TCP port
became open and an online connection could be established. The access is enabled for a
specific CMU only. For enabling the debug interfaces administrator permissions are required.
• Once enabled, the debug interfaces must be disabled explicit in the RTU500 series Web server.
This closes the TCP ports. For disabling the debug interfaces administrator permissions are
required.

For more detailed information about protocol logging in RTU500 series, see RTU500 Series
Function Description - Part 9: Interfaces and networks (1KGT151103)

1KGT151106 V005 1 13
Ethernet Interfaces Secure Access

2.2.1.1.11 Virtual Private Network

For a secure system setup over the public internet the RTU500 series supports the Virtual Private
Network protocol IPsec. The VPN functionality could be configured once per CMU (on Ethernet
interface E1 or E2 or PPP interface). Only if the VPN functionality is configured for a CMU interface
the IPsec/IKE TCP ports are open on that interface. On all other CMU interfaces the ports are
closed. If configured the corresponding IPsec/IKE ports are open all the time.

For more detailed information about VPN functionality in RTU500 series, see RTU500 Series
Function Description - Part 9: Interfaces and networks (1KGT151103)

2.2.2 Denial of Service

The denial of service function is designed to limit the CPU load that can be produced by the
Ethernet network traffic to the RTU. The communication facilities must not be allowed to
compromise the primary functionality of the RTU. All inbound network traffic is quota controlled,
so that a too heavy network load can be controlled. Heavy network load might for instance be the
result of malfunctioning equipment connected to the network. In case the limit is exceeding external
rate limiters shall be used.

The denial of service function measures the traffic from an Ethernet port and, if necessary, limits it
from jeopardizing the RTU's functionality due to a high CPU load.

Following limits are applicable:

• 560CMR01/2: 3000 frames/s

• 540CID01, 540CMD01: 3000 frames/s
• 520CMD01: 575 frames/s
• 530CID01: 3000 frames/s

The function has the following outputs:

• Following internal message is displayed in the RTU system diagnosis if the limit is exceed: CMU
x: Rate monitor interface Exchange to polling mode (Count=n)
• Following internal message is displayed in the RTU system diagnosis the traffic is again below
the limit: CMU x: Rate monitor interface Exchange to interrupt mode (Count=n)

How does the function create the diagnosis message:

• If the state is different than 2 seconds before, the function creates 1 diagnosis message
indicating the state change. Any additional state changes in the last 2 seconds are not indicated.
• If the state is the same as 2 seconds before but has changed in between, the function creates 2
diagnosis messages indicating the back and forth state change. In this case both messages get
the same time stamp.
• The last diagnosis message shows the actual state. If there are no further messages the rate
monitor remains in the last indicated state.

2.3 Integrated Firewall

Each CMU has an internal firewall enabled to filter out unintended traffic and therefore reduce the
attack surface for cyber security threats. Depending on the system requirements attack surface can
be reduced to a minimum by limiting the interfaces, IP ports and remote hosts.

The internal firewall cannot be configured directly by the user, but its settings are derived from the
device configuration done by means of RTUtil500. Basically all incoming traffic is blocked by the

14 1KGT151106 V005 1
Secure Access Encryption Algorithm

internal firewall. Only incoming ICMP echo request (PING) and ICMP destination unreachable
messages are allowed. Server IP ports are only opened, if using functionalities are configured with
RTUtil500.

The following paragraphs describe the firewall usage of the individual RTU500 functions:
• HCI, BCI, Integrated HMI:
Further filtering is possible for interfaces, IP protocols and remote hosts configured for each
functionality individually. Remote hosts allowed to connect can be restricted by configuring
explicit IP addresses for hosts/masters/HMI clients. If no explicit IP addresses are configured all
remote hosts are allowed to connect.
• HCI SNMP, HCI IEC 61850, SNTP server:
Only filtering of IP protocols and interfaces is possible depending on the configuration. Generally
all remote hosts are allowed to connect.
• Web server:
By configuration it is possible to disable access to web server ports (HTTPs and HTTP)
individually for each interface of a CMU. If access via an interface is enabled, firewall does not
restrict the remote hosts allowed to connect to RTU500´web server.
• SCIs, SNTP client, SNMP client, External security log client, CAM client:
SCIs open and maintain actively network connections. Firewall is only limiting the interfaces
allowed for configured functions, i.e. connections only sent out via interfaces allowed by
configuration.

2.4 Encryption Algorithm

In the RTU encryption and hash algorithms are used to protect the access to the Web server, for the
VPN communication and to encode the password file.

The algorithms are:

• AES (Advanced Encryption Standard), a block cipher based on a symmetric key algorithm to
encrypt and decrypt information. NIST has defined AES as successing standard of DES. The
effective key length for AES varies between 128 and 256 bits, depending on the algorithm. The
effective key length of the used AES-128 used in RTU500 is 128 bits.
• SHA (Secure Hash Algorithm) a family of cryptographic hash functions published by NIST. In the
RTU500 series the SHA-2 variants SHA-256, SHA-384 and SHA-512 are used.
• RSA Data Security, Inc. MD5 Message-Digest Algorithm, an algorithm for public-key
cryptography using a mathematically related key pair: a secret private key and a published
public key. In the RTU500 RSA with an effective key length of 2048 bits is used.
• 3DES is the common name for the Triple Data Encryption Algorithm (TDEA or Triple DEA)
symmetric-key block cipher, which applies the Data Encryption Standard (DES) cipher algorithm
three times to each data block.
• Blowfish is a symmetric-key block cipher algorithm, designed in 1993. Blowfish has a 64-bit
block size and a variable key length from 32 bits up to 448 bits.
• DES (Data Encryption Standard), a block cipher based on a symmetric key algorithm to encrypt
and decrypt information. The effective key length of DES is 56 bits.
• DH (Diffie–Hellman) key exchange, a cryptographic protocol that allows two parties that have
no prior knowledge of each other to jointly establish a shared secret key over an insecure
communications channel. In the RTU500 Diffie-Hellman with an effective key length of 2048 bits
is used.
• MD5 (Message-Digest algorithm 5), a cryptographic hash function with a 128 bit hash value
(see RFC1321 "The MD5 Message-Digest Algorithm" for detailed information). Used in the
RTU500 series for HTTP Digest Access Authentication with quality of protection (protection of
Web server access).

1KGT151106 V005 1 15
Intended Use Secure Access

• Salsa20, a stream cipher submitted to the eSTREAM project by Daniel Bernstein (see "The
Salsa20 family of stream ciphers" by Daniel J. Bernstein). In the RTU the reduced-round cipher
Salsa20/12 with an effective key length of 56 bits is used. This cipher is included for migration
from older RTU500 firmware version only. In the actual RTU500 firmware version the cipher is
not used for encrypting and decrypting.

In the RTU500 series VPN implementation for IKE the following cryptographic encryption algorithms
are supported:
• 3DES
• AES 128 CBC
• AES 192 CBC
• AES 256 CBC
• Blowfish
• DES

RTU500 series IKE implementation supports the following Diffie-Hellmann groups:

• MODP group 1 (768-bit)
• MODP group 2 (1024-bit)
• MODP group 5 (1536-bit)
• MODP group 14 (2048-bit)
• MODP group 15 (3072-bit)
• MODP group 16 (4096-bit)
• MODP group 17 (6144-bit)
• MODP group 18 (8192-bit)

ADVICE
It's recommended to use AES 256 CBC or higher respectively MODP group 14 (2048-bit) or
higher.

2.5 Intended Use

Details concerning intended use:
• RTU500 modules are intended to be used in private, isolated networks.
• It is not intended to connect the RTU500 modules or the RTU500 web server direct to the
internet.
• In case the RTU500 is using public networks the VPN functionality inside the RTU500 is
available.

16 1KGT151106 V005 1
Local User Account Management Design Principles

3 Local User Account Management

The local user account management in the RTU500 series outlines the functionality to administrate
the persons that access the RTU. The key features provided by the local user account management
are:

• User authentication based on user names and passwords

• User authorization based on roles and permissions
• Support of password policies
• Secure transmission of passwords from Web server and integrated HMI
• Secure storing of passwords on file system
• Download/Upload user account configurations

The following chapters describe first the design principles and later on the concrete user interface of
the local account management."Central user account management"

Users also can be managed by IEC 60870-5-104 protocol.

3.1 Design Principles

3.1.1 Account Information

In the RTU500 series there are user accounts, account permissions and user roles. These terms
have the following meaning:

• The user account represents a person that should access the RTU. The person is identified by a
user name and a password.
• Account permissions are actions that a user could perform and requires authorization.
• User roles are groups of account permissions that could be assigned to users.

The relationship between user, role and permission is shown in the figure below.

User 1 n 1 n Account
User role
account permission

Figure 3: Relationship user, role and permission

A user role can contain several permissions and a user account can be assigned to several user
roles.

The account information are stored in a password file. The password file contains the list of defined
users and their password, the list of user roles, the list of permissions and the assignment of user,
permissions and roles. The permissions available within the RTU500 series are predefined and
cannot be changed (see next chapter 'Account Permissions'). Users, roles and assignments can be
changed according the needs.

1KGT151106 V005 1 17
Design Principles Local User Account Management

3.1.2 Account Permissions

The account permissions available in the RTU500 series are fix defined and cannot be changed.
Each defined account permission allows several actions within the RTU500 series Web server or
Integrated HMI. The table below shows all available permissions and describes the allowed actions
for every permission in detail.

Permission Definition Description

viewData@ABBRTU500 Read and view RTU data:
• View system diagnostics log in Web server.
• View and download system diagnostics file in Web server.
• View RTU500 series process data in hardware tree of Web
server.
• Enable and disable RIO protocol logging mode in the Web
server. Once enabled there is no restriction on the access
to the RIO server. That means the real access is not pro-
tected by user name and password. The RIO protocol log-
ging mode is disabled after a fix timeout of 30 minutes if no
online connection exists.
• View and download process archive information via the Web
server (events and indications, measured values and inte-
grated total).
• Download archived disturbance record files via the Web
server.
• View online parameter changes in the engineering part of
the Web server.
• View online configuration in the engineering part of the Web
server.
config@ABBRTU500 Change configuration files:
• Upload and download all RTU500 series configuration files
via the Web server. This comprises the RTU configuration
and the Integrated HMI configuration. The certificate han-
dling is not included in this permission.
• Restart of RTU500 series via RTU500 series Web server.
firmware@ABBRTU500 Change firmware files:
• Upload and download all RTU500 series firmware files via
the Web server. This comprises the RTU basic firmware, the
communication controller firmware and the Integrated HMI
firmware.
• Restart of RTU500 series via RTU500 series Web server.
• View, upgrade and extend RTU500 series protocol/function
licenses (via Web server).
account@ABBRTU500 User account management:
• Add, modify and delete user accounts (via Web server).
• Add, modify and delete user roles (via Web server).
• Assign and withdraw user accounts to user roles (via Web
server).
• Assign and withdraw account permissions to user roles (via
Web server).
• Change user passwords (via Web server).
• Upload and download password files (via Web server).
Table 2: Account permissions available in the RTU

18 1KGT151106 V005 1
Local User Account Management Design Principles

Permission Definition Description

• Prohibit RIO protocol logging mode (via Web server).
• Prohibit PLC online debug mode (via Web server).
• Prohibit RTU500 series test mode (via Web server).
• Prohibit online configuration changes (via Web server).
• Prohibit online parameter changes (via Web server).
userRole@ABBRTU500 User role management:
• Assign and withdraw user accounts to user roles (via Web
server).
• Assign and withdraw account permissions to user roles (via
Web server).
• Change user passwords (via Web server).
viewEvent@ABBRTU500 View security event logging / audit trails:
• View logged security events in Web server.
• Download logged security events in predefined CSV format
(via Web server).
enableTest@ABBRTU500 Enabling and use simulation and test mode:
• Enable/Disable RTU500 series test mode via the Web
server. The test mode allows the simulation of inputs/outputs
in the test manager of the Web server.
• Enable/Disable time administration test mode to allow set-
ting of the RTU system time via the Web server.
• Enable/Disable IEC 61850 startup logging (via Web server).
• Enable/Disable Ethernet and PPP interface logging (via Web
server).
• Enable/Disable IEC 61850 debug trace interface (via Web
server).
• Enable/Disable VxWorks debug interface (via Web server).
• Simulate inputs, outputs, system events and security events
in the RTU500 series test mode via the Web server (If test
mode is enabled).
• Set system time of RTU via Web server, if time administra-
tion test mode is enabled.
enablePlc@ABBRTU500 Enable and use PLC online debug mode:
• Enable/Disable PLC online debug mode via the Web server.
Once enabled there is no restriction on the access to the
PLC. That means the real access is not protected by user
name and password. The PLC debug mode is disabled after
a fix timeout of 30 minutes if no online connection exists.
onlineConf@ABBRTU500 Online configuration changes:
• Online configuration changes (Engineering via the RTU500
web server)
onlinePara@ABBRTU500 Online parameter changes:
• Online parameter changes (Engineering via the RTU500
web server)
viewDataHmi@ABBRTU500 Read and view data on the Integrated HMI:
• View all configured Integrated HMI pages.
• View and download process archive information in the HMI
event list (events and indications, measured values and inte-
grated total).
Table 2: Account permissions available in the RTU

1KGT151106 V005 1 19
Design Principles Local User Account Management

Permission Definition Description

• Acknowledge alarms in the HMI alarm list.
ctrlOpHmi@ABBRTU500 Control operations on the Integrated HMI:
• View all configured Integrated HMI pages.
• View and download process archive information in the HMI
event list (events and indications, measured values and inte-
grated total).
• Acknowledge alarms in the HMI alarm list.
• Do control operations in the Integrated HMI
certificate@ABBRTU500 Handle certificates for security related functions:
• Access the certificate management in the RTU500 series
Web server and upload certificates for all functionalities that
requires or support them.
• Delete certificates via the certificate management in the
RTU500 series Web server.
• Restart of RTU500 series via RTU500 series Web server.
Table 2: Account permissions available in the RTU

3.1.3 User Roles

The user roles that group several account permissions could be changed according the needs. In
delivery status the RTU500 series contains the following predefined user roles:

User role Role explanation Included permissions Permission description

Viewer Viewer viewData@ABBRTU500 Read and view RTU data
Engineer Engineer viewData@ABBRTU500 Read and view RTU data
config@ABBRTU500 Change configuration files
firmware@ABBRTU500 Change firmware files
enableTest@ABBRTU500 Enabling and use simulation and
test mode
enablePlc@ABBRTU500 Enable and use PLC online debug
mode
onlinePara@ABBRTU500 Online parameter changes
onlineConf@ABBRTU500 Online configuration changes
certificate@ABBRTU500 Certificate handling
Installer Installer viewData@ABBRTU500 Read and view RTU data
config@ABBRTU500 Change configuration files
onlinePara@ABBRTU500 Online parameter changes
certificate@ABBRTU500 Certificate handling
Administrator Administrator account@ABBRTU500 User account management
viewEvent@ABBRTU500 View security event logging / audit
trails
userRole@ABBRTU500 User role management
Operator Operator viewData@ABBRTU500 Read and view RTU data
viewDataHmi@ABBR- Read/view data Integrated HMI
TU500
ctrlOpHmi@ABBRTU500 Control operations Integrated HMI
Table 3: Default user roles in the RTU

20 1KGT151106 V005 1
Local User Account Management Design Principles

User role Role explanation Included permissions Permission description

SECAUD Security auditor viewEvent@ABBRTU500 View security event logging / audit
trails
SECADM Security adminis- account@ABBRTU500 User account management
trator certificate@ABBRTU500 Certificate handling
RBACMNT Role based access viewEvent@ABBRTU500 View security event logging / audit
control manage- trails
ment userRole@ABBRTU500 User role management
Table 3: Default user roles in the RTU

During migration from the previous RTU560 user account management (before release 12) certain
rules apply to convert to the new user roles defined above. These migration rules are:

• Existing user roles (default roles or new created roles) are kept, if there is any user assigned.
• The new user roles Engineer, Installer, SECAUD, SECADM and RBACMNT are added to the
role definition, if not existing. The new roles get the account permissions as defined in the table
above.
• If the user role System Engineer from a former UAM implementation exists, the
account permissions onlinePara@ABBRTU500 (Online parameter changes) and
onlineConf@ABBRTU500 (Online configuration changes) are assigned to this role.
• The account permission userRole@ABBRTU500 (User role management) is assigned to
the existing user role Administrator. The user role Administrator must exist during migration,
because it is not removable.

3.1.4 Local user accounts

The local user account representing a person is identified by a user name and a password. User
name and password are free of choice within defined rules. See chapter "Password policies"
for detailed information about the explicit and implicit rules for user names and passwords. The
maximum number of different local user accounts in the RTU500 series is 100.

Each local user account can be assigned to one or more user roles with different account
permissions. During an online connection with the RTU500 series Web server the user has to select
a role from his assigned user roles. The user role can be changed during the online connection but
at one point in time the user has one role with the defined account permissions, only. After login the
changeable default user role is selected for a user.

In delivery status the RTU500 series contains the following predefined local user accounts, with
their assigned user roles and their defined default user role:

Default Default Assigned user roles Default user role

user name password
Show Show Viewer Viewer
Load Load Installer Installer
Control Control Installer Installer

Engineer
Admin Admin Engineer Engineer

Administrator
Operator Operator Operator Operator
Default Default Viewer Viewer
Table 4: Default user accounts in the RTU

1KGT151106 V005 1 21
Design Principles Local User Account Management

Default Default Assigned user roles Default user role

user name password
Operator

Installer

Engineer

SECAUD

RBACMNT

SECADM

Administrator
Table 4: Default user accounts in the RTU

During migration from the previous RTU560 user account management (before release 12) the
existing local user accounts are taken as they are. That means user names, passwords and role
assignments remains unchanged after the migration.

ADVICE
The predefined superuser Default is added to the local user accounts during migration from
the previous RTU560 user account management. So, if the local user accounts are defined
individual be sure to remove the superuser after the migration.

In delivery status the RTU530 contains the following predefined local recovery user account:

Default Default
user name password
Recover Recover
Table 5: Recovery user account in the RTU

Figure 4: Recovery User Account Management

22 1KGT151106 V005 1
Local User Account Management Design Principles

3.1.5 Password File

All information about account permissions, user roles and local user accounts are stored in a
password file on the memory card of a CMU. Several protection schemes are implemented
according to IEEE 1686 [3] to inhibit reading of the password file information. The handling of the
password file within the RTU500 series is shown in figure below.

The RTU holds the password file in plain text in the RAM as central source. For the upload
and download to the Web server the file is encoded with a symmetric key A provided in the
RTU firmware. This allows exchange of the password file with other RTU's because the file can
be decoded with the same key A in every RTU. A detailed description of encryption and hash
algorithms can be found in chapter "Encryption Algorithm".

For storing on the memory card the password file is encoded with another symmetric key B
calculated from the memory card id (serial number of memory card) and a hardware identifier.
This key depends on the memory card and is individual per CMU. With this method the encrypted
password file on the memory card cannot be copied to other CMU's or used for upload from the
Web server.

Symetric key
defined in firmware
A

Plain text
password file in
RAM
decode

Web Server
encode

XXXXX A
decode

encode

B XXXXX A
RTU500 series XXXXX A
Symetric key
calculated from
memory card ID Encrypted
XXXXXB password file
Encrypted
on local file
XXXXXB password file on
system of PC
memory card
XXXXXB
Figure 5: Encryption of password file

To compare the password files between different CMU's a SHA-256 hash value over the content of
the password file is calculated and appended to the file (before encoding). During initialization the
password file is decoded and the hash value is read.

For information exchange the different CMU's within a RTU560 communicate with each other. In
case another CMU is detected during startup the password file hash value is requested from the
other CMU. The received hash value is compared with the own value and in case of discrepancies
the RTU goes to a restricted mode. In restricted mode all users are logged out and no access is
possible anymore. The only available function is the possibility to harmonize the password files

1KGT151106 V005 1 23
User Interface Local User Account Management

over all CMU modules. This function requires login as user with administrator permissions on all
available CMU modules. For more information see chapter "Password file harmonization".

Migration
Flag
CMU CMU

Internal Flash Internal Flash

Startup 1
B
Memory card Memory card

XXXXX B
encode XXXXX B
XXXXX B
XXXXX B
Default
password file
No password from firmware Encrypted
file password file on
memory card

Figure 6: Migration of password file

If a CMU module is started without password file and set migration flag, no default password file is
created and no login is possible via the Web server. This applies as well for a corrupted password
file (e.g. because of unauthorized modification). In both cases the configured RTU functionality is
still available but there is no access possible via Web server or Integrated HMI. A corresponding
error message is shown to the user.

When password file is migrated the original password file is read and all defined users and roles are
converted to the new account permission structure. The migration of users and roles is described in
detail in the chapters above.

Besides the possibility to exchange the password file between different RTUs, the password file can
be reset to the factory default. In this case all user accounts, user roles and password policies are
reset to the default definition described in the chapters "Local user accounts" and "User Roles".

3.2 User Interface

3.2.1 RTUtil500 configuration

The security relevant configuration parameters are defined for a whole RTU. There is no
configuration per CMU possible. The following parameters are configurable within RTUtil500:

• Maximum number of security events stored in the log. Configurable between 1000 and 10000
events with a default value of 3000.
• Timeout for automatic logout after user inactivity. Could be disabled and is configurable between
1 minute and 24 hours. Set to 60 minutes as default.

24 1KGT151106 V005 1
Local User Account Management User Interface

In RTUtil500 the security parameter are placed in the "Parameter" tap at an RTU (Network or
Hardware tree). The figure below shows the RTUtil500 security parameter user interface.

Figure 7: RTUtil500 security parameter user interface

3.2.2 User Authentication

The information about the user authentication when accessing the RTU500 series Web server can
be found in chapter "Web server user authentication". There the differences between the local and
the central user account management regarding log-in are described.

3.2.3 Local user account management

All modification of local user accounts are done via the RTU500 series Web server. In the Web
server menu the link "User Management" is the entry point for the local user account management.
This link can be found under the menu item "Management" as shown in the figure below. Due to the
sensible information in the user account management the following notice has to be considered.

ADVICE
The web pages of this functionality require secure HTTPS access. It is not possible to open the
web pages with standard HTTP access.

Figure 8: Web server menu user account management

The link starts a user interface to modify the following properties:

• Enable or disable functional policies

• Enable or disable password policies
• Add new or delete existing local user accounts
• Change user account passwords
• Add new or delete existing user roles
• Change assignments of user and permissions to/from user roles

1KGT151106 V005 1 25
User Interface Local User Account Management

The user interface for the account management consists of several menu tabs. The first 3 menu
tabs cover the password policies, the local user accounts and the user roles. On each tab the
corresponding information are shown for display and modification.

Common for all menu tabs are 2 buttons at the top of each tab. These buttons control the changes
done by the administrator. At startup all control elements are disabled showing the current
configuration. If changes shall be done the administrator just start to access the user interface.
Then the both control buttons get active. After finishing the administrator can accept and store the
changes by pressing the button "Save" or returning to the former configuration by declining the
changes with the button "Cancel". It is irrelevant on which tab the control buttons are used. The
change process could be started or finished on each tab.

ADVICE
Be sure to save any wanted modification in the user account management by pressing the
"Save" button.

When the changes are accepted an additional dialog appears to confirm the decision. The changed
account configuration is active right after accepting the changes. There is no need to reset the RTU
but all users are logged out and a re-login is required. During accepting the changes are distributed
within the RTU CMU's which could take a few seconds.

To avoid conflicts no access is possible via the Web server when an administrator has started
the account change process. This compromises the access from other CMU's as well. The next
chapters describe each menu tab in detail.

3.2.4 Security Policies

In the first tab of the user management the security policies of the RTU500 series are defined.
Security policies are general rules, which are valid for all users and for the whole RTU500 system.
As shown in the figure below the security policies are divided into the following two sections:

• Functional policies that define restrictions in the access to the RTU500 series and
• Password policies that define rules that a password must fulfill to get accepted.

26 1KGT151106 V005 1
Local User Account Management User Interface

Figure 9: Menu tab security policies

The following sections describes the functional and password policies in detail.

3.2.4.1 Functional policies

The functional policies define restrictions in the access to the RTU500 series. When activated
certain functionalities are disabled and cannot be used anymore. The following functional policies
can be activated for the whole system:

• PLC online debugging

Disable the access to the PLC online debugging. This includes start/stop of PLC programs,
display and setting of PLC variables.
• COMPROTware RIO Server
Disable the access to the COMPROTware RIO Server. That means disable the possibility to
listening of telegram traffic on serial and Ethernet interfaces.
• Web server Test Mode
Disable the Web server testing and simulation mode. This includes time administration,
simulation of process inputs and commands in the test manager.
• Online parameter change
Disable the possibility to change single parameters online with the Web server.
• Online configuration change
Disable the possibility to change the RTU configuration online with the web server.

See part (1) of the Web server screen shoot "Fig. 9: Menu tab security policies" for the password
policies user interface.

3.2.4.2 Password policies

The password policies define rules that a password must fulfill to get accepted by the RTU500
series. To enable the password policies the check box "Enforce password policies" must be
checked (see figure in last chapter). Changes in the password policies are considered for new
passwords only. That means existing passwords are not checked against the policies and the

1KGT151106 V005 1 27
User Interface Local User Account Management

passwords are still valid and usable. To be sure that all passwords are compliant the passwords
must be changed after defining a password policy.

After enabling the password policies the control elements are enabled and changes could be done.
The following parameters are editable:

• Minimum length of a password. The required length of a password could be set to 0 which
means no required length or to a value between 6 and 31. In case of 0 the password must be at
least 3 characters long (see implicit rules below).
• Maximum lifetime of a password. This parameter defines the time after a password became
invalid and could not be used anymore. The time is configured in days with a range from 0 to
1000. The value 0 means that the password never became invalid.
• Contains lower case characters. If this check box is set the passwords must contains at least
one lower case character.
• Contains upper case characters. If this check box is set the passwords must contains at least
one upper case character.
• Contains numeric characters. If this check box is set the passwords must contains at least one
numeric character '0' to '9'.
• Contains special characters. If this check box is set the passwords must contains at least one of
the listed special character:
" [!£$%^&*@?<>+_]\"

Even when the password policies are not enabled there are certain rules for passwords. These are
minimal rules to ensure proper system functionality. These implicit rules are:

• A password must be at least 3 characters long.

• A password must not be more than 31 characters long.
• A whitespace character is not allowed as part of the password.
• For passwords the following characters are allowed:
"abcdefghijklmnopqrstuvwxyz"
"ABCDEFGHIJKLMNOBQRSTUVWXYZ"
"0123456789"
"[!£$%^&*@?<>+_]\"

Independent from the password policies there are as well implicit rules for user names. These rules
are:

• A user name must be at least 3 characters long.

• A user name must not be more than 31 characters long.
• A whitespace character is not allowed as part of the user name.
• For user names the following characters are allowed:
"abcdefghijklmnopqrstuvwxyz"
"ABCDEFGHIJKLMNOBQRSTUVWXYZ"
"0123456789"
"-.@_"

The number of failed login attempts is tracked per user.

If number of failed login attempts exceeds the defined limit, login of this user is locked for a fixed
time-out of 1 minute and security event 1170 'Log-in failed 3 times' is generated. The function is
activated by default and set to 3. The maximum allowed is 99.

See part (2) of the Web server screen shoot "Fig. 9: Menu tab security policies" for the password
policies user interface.

28 1KGT151106 V005 1
Local User Account Management User Interface

3.2.4.3 Authentication

Various authentication options are available when HTTPS is configured and CAM is disabled.

Authentication options:
• Password based authentication, user will be asked for user name and a password to login.
• Client certificate authentication, during TLS handshake user needs to provide a certificate
signed by User Authority.
• Password or client certificate, if a certificate won’t be provided during TLS handshake, user will
be asked for user name and a password.
• Two factor authentication, user needs to provide correct client certificate and will be asked for
the password.

The authentications based on certificate use TLS functionality that the TLS client can provide
certificate. To use the client certificate it needs to be configured in the browser (or operating
system). The client certificate needs to be signed by Users Authority certificate (see chapter
"Users Authority Certificate"), and contain commonName set to user name of existing in User
Management. The check for certificates is working only if the valid Users Authority certificate is
uploaded.

ADVICE
It is recommended to first try option “Password or client certificate” (see part (3) of the Web
server screenshot) to ensure that Users Authority and user certificate are configured correctly. If
the check for client certificate is enforced, it is not possible to bypass the check.

Figure 10: Web server tab Security Policies

1KGT151106 V005 1 29
User Interface Local User Account Management

3.2.5 Modification of User Accounts

RTU500 series allows modification of user accounts using two methods:

• User management using web server,
• User management using web server with certificates.

3.2.5.1 User Management using Web Server

In the second menu tab the local user accounts are defined. The tab shows in a table the names
of the existing local user accounts (see figure below). The password of a user account can be
changed by selecting the lock symbol at the left side of the table and by selecting the trash can
symbol the local user account can be deleted. Be careful, there is no security query when deleting a
local user account and a once deleted user account could not be restored.

On the right side of the table are the assignments of the user roles. One or several roles can be
assigned to a local user account. The user role can be assigned or withdrawn by selecting the
corresponding checkbox at the user account. The specific permissions assigned to a user role are
defined in the menu tab "User Roles" described in the next chapter.

Figure 11: Menu tab user accounts

At the end of the table of existing local user accounts there is an empty field for adding a new local
user. A new local user account is created by typing a user name and pressing <ENTER>. Then a
dialog appears to set the initial password of the new user account (as shown in the next figure). By
confirming the dialog with "Ok" the user account is created. For information about rules that must be
consider when choosing a user name or password see chapter about the password policies.

When changing a local user password the same dialog appears as when setting the initial
password. In the dialog the affected user name is displayed and 2 text fields to type the new
password. The password must be typed two times to eliminate, unintentional typing errors. The new
password is accepted only if both text fields contain the same password.

The new password is checked against the policies rules when the button "OK" is selected. In case
of violations the password is declined, an error message is shown and a valid password must be
defined. The dialog can be finished by pressing the button "Cancel". In this case the password is
not changed and the old password is still valid.

30 1KGT151106 V005 1
Local User Account Management User Interface

Figure 12: Dialog to change the password of a user

The Administrator can change the passwords of all local user accounts. A normal user can change
the own password, only. To change the own password the user must select the tab "User Accounts"
in the user account management. In this case the user account table shows the logged in user and
the password can be changed by selecting the lock symbol. In the change password dialog the
current and the new password must be typed. By pressing "Ok" the minimum password policies are
checked and if the password is valid the dialog closes. But closing the dialog does not store the new
password on the RTU500 series.

To store the new password the button "Save" must be selected. With this step the new password
is checked against the local defined policies rules and stored when valid. By pressing the button
"Cancel" the password is not changed and the old password is still valid. The following figure shows
the user interface for changing the own password of a CAM user.

Figure 13: Dialog to change the own password of a LAM user

3.2.5.2 User Management using Web Server with Certificates

New users can be added or changed using a certificates in format X509v3 saved as PEM files. User
certificate requires additional attributes with IEC user roles defined in IEC62351-8 [6] and can have
more than one role assigned.

1KGT151106 V005 1 31
User Interface Local User Account Management

In order to add a user certificate additional Users Authority Public Key certificate needs to be
loaded. Users Authority certificate shall be in PKCS#7 format with the file ending '.p7b' and loaded
using Certificate Management:

Figure 14: Certificate user management

Users authority certificate does not require configuration in RTUtil500, its always present in
Certificate Management on first position in the list as shown on figure below. Authority certificate
can be revoked by loading a certificate revocation list (CRL) provided by issuer of certificate. If
certificate is revoked there is no possibility to load add or change users using certificates.

Figure 15: Certificate user management with Users Authority slot

After Users Authority certificate is loaded it’s possible to load a user certificate. If certificate is
revoked there is no possibility to load user certificate.

In user accounts tab option ‘Show Certificate user upload area’ shall be set:

32 1KGT151106 V005 1
Local User Account Management User Interface

Figure 16: Show certificate user upload area

In the new opened area a user certificate can be loaded. RTU is able to process only one certificate
simultaneously so if more than one user is going to be added it shall be loaded one-by-one. RTU
first will validate a new user certificate using User Authority Public key and show assigned user
roles. Expired user certificates are discarded with ab error message ‘Certificate expired’.

Figure 17: Load user certificate

After successful validation ‘Move to user accounts’ button shall be pressed and a new password
shall be assigned to the user.

1KGT151106 V005 1 33
User Interface Local User Account Management

Figure 18: Set password for a new user

When all users are added ‘Save’ button shall be pressed. After saving operation users are stored in
the password file. If RTU560 is used with redundant or multi CMU password file is also distributed
to other boards.

If certificate validation will fail an error message will be displayed and certificate will be discarded.
Mismatch in validation due to wrong or different Authority Certificate(for instance certificate singed
by different issuer) will result in error ‘Invalid signature’.

User operation defined in IEC62351-8 are 'Add/Change/Delete' for user certificates. Certificate
with delete operation is not used in the RTU and normal user delete button shall be used instead
– see figure below. For adding or changing a user, user role used in certificate must exists in user
management. It is also possible to user define role but role shall be define in RTU as well.

Figure 19: Delete user

34 1KGT151106 V005 1
Local User Account Management User Interface

It is not possible to change user roles in User Account section for a user added with certificate. For
that operation another certificate with 'Change' operation shall be used. When 'Change' operation is
used its not required to set a new password for the user.

For renewal of user certificate it operation 'Change' shall be use or 'Add' with deleting previously
define user. If renewed certificate is valid the user is able to log into RTU.

3.2.6 User Roles

In the third menu tab the user roles and there permission assignments are defined. The tab shows
in a table the names of the existing user roles (see figure below). A user role can be deleted by
selecting the trash can symbol on the left side of the table. Be careful, there is no security query
when deleting a user role and a once deleted role could not be restored.

On the right side of the table are the specific permissions assigned to a user role. A permission can
be assigned or withdrawn by selecting the corresponding checkbox at the user role.

Figure 20: Menu tab user roles

There is an empty field at the end of the table of existing roles for adding a new user role. A new
user role is created by typing a role name and pressing <ENTER>. There are the following rules
defined for role names:

• A role name must be at least 3 characters long.

• A role name must not be more than 19 characters long.
• Whitespace characters are allowed as part of the role name
• For role names the following characters are allowed:
"abcdefghijklmnopqrstuvwxyz"
"ABCDEFGHIJKLMNOBQRSTUVWXYZ"
"0123456789 "

For detailed information about the available account permissions see chapter "Account
Permissions".

1KGT151106 V005 1 35
User Interface Local User Account Management

3.2.7 Password file management

The password file of the RTU500 series can be reset to factory default and be exchanged between
different RTUs. For this functionality the password file can be reset, uploaded and downloaded via
the RTU500 series Web server. The corresponding user interface can be found under the link "User
Management" in the menu item "Management". The figure below shows the user interface for the
password file management in the tab "Password File".

Figure 21: Menu tab password file management

To reset the password file to factory default the button "Reset" has to be used. When pressed a
dialog appears to confirm the reset. After confirmation with "Ok" the default password file is active
directly. A reset of the RTU500 series is not necessary, but all users are logged out and a re-login
is required. After the reset all user accounts and passwords are reset to the default values. That
means the re-login must happen with a default user and password.

For the exchange of a password file the file must be downloaded from an RTU first. This is done by
selecting the button "Download" in the tab "Password File". When pressed an information status bar
appears like shown in the figure below. To save the downloaded password file on the host PC select
the button "Save".

36 1KGT151106 V005 1
Local User Account Management User Interface

Figure 22: Download password file

To upload a before downloaded password file on another RTU the file can be dropped to the dotted
area shown in the figures above or the area can be clicked with the mouse. In the second case a
file select dialog appears to choose the password file to upload. In both cases a confirmation dialog
appears to confirm the upload. After confirmation with "Ok" the existing password file is replaced
by the uploaded file. If successful, the new password file is active directly. A reset of the RTU500
series is not necessary, but all users are logged out and a re-login is required.

3.2.8 Password file harmonization

In case the password file is inconsistent between different CMU's the RTU500 series goes into a
restricted mode. In this mode a login is possible but the only function available is the harmonization
of the password file. The harmonization of the password file requires administrator permissions.
In restricted mode the Web server shows after login without administrator permissions the error
message displayed below.

1KGT151106 V005 1 37
User Interface Local User Account Management

Figure 23: Error message administrator permissions required

ADVICE
Be sure to disable the advanced option "Show friendly HTTP error messages" if the Microsoft
Internet Explorer is used as Web client. Without this option the detailed error information of the
RTU500 series Web server are not shown. The option can be found in the "Advanced" tab of the
"Internet Options".

After login with administrator permission the RTU500 series Web Server shows the normal
user interface. But due to the restricted mode each function, besides the harmonization of the
password file, is locked. If a locked function is selected the Web server shows a corresponding error
message, like shown in the next figure.

Figure 24: Error message password file inconsistency

38 1KGT151106 V005 1
Local User Account Management User Interface

To start the password file harmonization the link "User Management", found under the menu
item "Management", must be selected (see figure below). When selected the user interface for
the account management appears. The last tab (called "Harmonization") in the user interface is
used for the password file harmonization by authenticate all available CMU's. Due to the sensible
information in the authentication the following notice has to be considered.

ADVICE
The web pages of this functionality require secure HTTPS access. It is not possible to open the
web pages with standard HTTP access.

Figure 25: Web server menu user account management

Before a harmonization of the password file is possible, the authentication of the administration user
must be provided by the user for all detected CMU's. The provided authentications are compared
with authentications requested from the other CMU modules. Only if all authentications are correct
the password file can be harmonized and distributed to the other CMU modules.

The next figure shows an example for an RTU with 2 CMU's. For each detected CMU the rack and
slot address is shown. Furthermore there are input fields for user name, password and a button
to authenticate each CMU. A CMU is authenticated by typing a user account with administrator
permissions and selecting the button "Authenticate". A correct authenticated CMU is identified by
the check box on the right side.

Figure 26: Password file harmonization

1KGT151106 V005 1 39
Recommendations Local User Account Management

When all CMU's are authenticated the distribution of the password file is started by selecting the
button "Harmonize" at the top of the page. The harmonization distributes the password file of the
connected CMU to all other CMU's. The distribution within the RTU can take a few seconds. If the
distribution was successful, the harmonized password file is active directly. A reset of the RTU500
series is not necessary, but all users are logged out and a re-login is required.

3.3 Recommendations
Recommendation Implementation in the Reference to standards
RTU500 series
All default users and user pass- The RTU system provides
words shall be deleted means to configure individual
secure user accounts.
There shall be individual user The RTU system provides
accounts. No shared user means to configure individual
accounts shall be used. secure user accounts. Only with
individual accounts the trace-
ability in the security logs is
possible.
Users shall only have the mini- The RTU provides a role based
mum rights required. user account management.
New roles can be defines.
All predefined roles can be
deleted.
A strong password policy shall Use the RTU password policy • NERC CIP-007-3a "Cyber
be defined. setting option to enable strong Security - Systems Security
passwords. Management"
• IEC 62443
A maximum lifetime for a user Use the RTU password policy • NERC CIP-007-3a "Cyber
password shall be defined setting option to enable a pass- Security - Systems Security
word lifetime. Management"
• IEC 62443
Login lock shall remain Use the RTU password pol-
enabled. icy setting option to set login
attempts.
Table 6: Recommendations for local user account management

ADVICE
When removing user accounts or roles the RTU500 series firmware ensures that at least one
administrator account remains (user account with permission "account@ABBRTU500"). Be
sure to keep the password of this administrator account because there is no possibility to reset
an administrator password. If the administrator password is lost, a new flash card (with factory
settings) has to be used.

40 1KGT151106 V005 1
Central user account management Design Principles

4 Central user account management

The central user account management (CAM) in the RTU500 series is an extension of the local
account management (LAM) described in chapter "Local User Account Management". In a CAM
setup the user authentication (with user name and password) is done on an external CAM server
that manage all user accounts of a system. The authorization of a user via permissions assigned to
user roles is still performed locally with the definitions in the LAM. That means there is a bisection
between CAM and LAM and both functionalities must be considered when using a central user
account management.

The communication between the RTU and the CAM server is done with the Lightweight Directory
Access Protocol (LDAP). For CAM the RTU500 series supports the following server types:

• ABB IEC 62351 Authentication Server (integrated in SDM600)

• Microsoft Active Directory Server
• Group Based LDAP Authentication Server

For detailed information about the supported CAM server types see the following documentation
links:

• For the ABB IEC 62351 Authentication Server

System Data Manager SDM600 - User Manual
• For the Microsoft Active Directory Server
Microsoft Active Directory Domain Service Documentation
• For the Group Based LDAP Authentication Server
OpenLDAP project and documentation

The following chapters describe first the design principles and later the configuration to setup a
central user account management in the RTU500 series.

4.1 Design Principles

4.1.1 Account Information

In a CAM setup the differentiation between user accounts, user roles and account permissions
are the same as written in chapter "Account Information" of the LAM description. This applies as
well for the relationship between user, role and permission. But in a CAM configuration the account
information are stored and handled in different places as shown in the figure below.

1KGT151106 V005 1 41
Design Principles Central user account management

CAM Server LAM on RTU

User 1 n 1 n Account
User role
account permission

Figure 27: Division of account information between CAM and LAM

The user accounts and roles assigned to that user are stored and managed in the CAM server. The
permissions assigned to user roles are stored and handled in the LAM of the RTU. The intersection
between CAM and LAM is the user roles. This requires that user roles on the CAM server are
defined in the same way as in the LAM of the RTU. A detailed description about this requirement
can be found in chapter "User Roles".

How the user accounts and roles are stored on the CAM server is outside the scope of this
document. Please refer to the documentation of the used CAM server for more information about
the storage of user accounts. The assignment of account permissions and user roles are stored on
the RTU in a local password file (see chapter "Account Information" of the LAM description).

4.1.2 Account Permissions

As described for local account management (LAM), the account permissions available in
the RTU500 series are fix defined and cannot be changed. This applies for central account
management (CAM) setups as well. A detailed overview of all permissions and the allowed actions
for every permission can be found in chapter "Account Permissions" of the LAM description.

4.1.3 User Roles

The user roles that group several account permissions are the boundary point between the central
account management (CAM) server and local account management (LAM). In the CAM server roles
are assigned to user accounts and in LAM permissions are assigned to user roles. For this task
sharing the user roles on the CAM server must be defined in the same way as in LAM. To achieve
this requirement the following rules must be considered depending on the used CAM server type.

With the ABB IEC 62351 Authentication Server the user roles are identified along the role id. The
role id is specified in IEC 62351 for the standard and the user defined roles. The table shown below
contains the role id definitions according to IEC 62351.

User role Role explanation IEC 62351 role id

Viewer Viewer 0
Operator Operator 1
Engineer Engineer 2
Table 7: IEC 62351 user role ids

42 1KGT151106 V005 1
Central user account management Design Principles

User role Role explanation IEC 62351 role id

Installer Installer 3
SECADM Security administrator 4
SECAUD Security auditor 5
RBACMNT Role based access control 6
management
Administrator Administrator -100
<User defined role> <User defined role> -101 (decreasing numbered)
Table 7: IEC 62351 user role ids

For the standard roles from "Viewer" to "Administrator" the role ids are fix defined. This definition is
used by the ABB IEC 62351 Authentication Server and the LAM on the RTU500 series. That means
for the standard roles no adjustments has to be done with this CAM server type.

The user defined roles get a negative role id starting with -101 and are decreasing numbered. To
get the same definition on the ABB IEC 62351 Authentication Server and the LAM the user defined
roles must be created in the same order on the CAM server and the LAM. To check that ids of user
defined roles are the same, the LAM shows the assigned role id in the user interface (see chapter
"User Roles" in the LAM description).

With the Microsoft Active Directory Server and the Group Based LDAP Authentication Server the
mapping of roles between LAM and the CAM server is handled via the name of the role. This kind
of CAM server doesn't support user roles but groups with a similar purpose. The user accounts on
the CAM server can be part of one or more groups comparable to the user roles in LAM. To define a
mapping between the groups and the roles, the naming of both must be the same like shown in the
next table.

LAM user role name Role explanation CAM server group name
Viewer Viewer Viewer
Operator Operator Operator
Engineer Engineer Engineer
Installer Installer Installer
SECADM Security administrator SECADM
SECAUD Security auditor SECAUD
RBACMNT Role based access control RBACMNT
management
Administrator Administrator Administrator
Table 8: Mapping between user roles and groups

This mapping of the standard roles from "Viewer" to "Administrator" is fix defined and cannot be
changed. Be sure to create the groups in the CAM server with the same name as the standard
roles in LAM. Additional groups not named as in LAM are ignored. So, user defined roles are not
supported with the Microsoft Active Directory Server and the Group Based LDAP Authentication
Server.

For all CAM server types the assignment of permissions to user roles can be changed in LAM
according the needs. The predefined assignment of permissions in delivery status can be found in
chapter "User Roles" of the LAM description.

1KGT151106 V005 1 43
Design Principles Central user account management

4.1.4 User authentication

For the user authentication a CAM client runs on the RTU that communicates with the external CAM
server. The protocol used for communication is LDAP (Lightweight Directory Access Protocol) with
additional TLS (Transport Layer Security) extension. The next figure shows the CAM authentication
process in a functional overview.

CAM server
RTU500 with CAM client CAM server certificate

1. Connect to CAM server

2. Present certficate

3. Send user credentials

4. Authentication result

ABCDEF XXXXXX
LDAP protocol over
TLS connection

Public key of Plain text user Hashed user Authentication

CAM server password password database

Figure 28: CAM user authentication process

The different steps to authenticate a user are:

1 As there is no permanent connection to the CAM server, the CAM client in the RTU begins by
connecting to the server using the LDAP protocol. Within this step Transport Layer Security
(TLS) is established on the connection to provide data confidentiality.
2 As response the CAM server presents for identification his certificate to the RTU. The RTU
validates the certificate with the pre-loaded public key of the CAM server.
3 Afterwards the RTU sends the user credentials to the CAM server. In this step the RTU sends
the user password as plain text (over the secure TLS connection of course). The reason for
the plain text is the authentication data base on the CAM server. In this database the user
passwords are stored as hashed values. But the parameters of the hash (algorithm, salt etc.) are
not known by the CAM client. So the passwords have to be sent as plain text to allow hashing
and comparing on the CAM server.
4 In the last step the CAM server compares the received user credentials with his database and
sends the result of the authentication back to the RTU. Finally the connection to the CAM server
is closed.

Besides the user authentication with the CAM client, the local account management can be used as
backup. In this optional configuration LAM is used for user authentication if there is no connection to
the CAM server.

4.1.5 CAM server public key certificate

To ensure the identity of the CAM server the RTU500 series validates the presented end-entity
server certificate with the prior uploaded public key (see chapter "User authentication"). How
the CAM server certificate is generated and signed depends on the server and is not part of this
document. Please refer to the CAM server reference documentation (found here "Central user
account management") for more information about the specific server certificate.

For the public key certificate uploaded to the RTU500 series the following issues has to be
considered:

44 1KGT151106 V005 1
Central user account management Design Principles

• The public key certificate can be extracted from the end-entity CAM server certificate. How this
is done depends on CAM server. Appendix "A.1 Export CAM Server Public Key Certificate on
Windows" shows an example for the Microsoft Windows certificate store.
• The public key certificate must contain the complete certification path. Make sure to extract the
whole certification path, when creating the public key certificate from the end-entity CAM server
certificate. Without the certification path the public key certificate is rejected as self-signed.
• The subject alternative name or the common name of the CAM server certificate must contain
the IP address of the CAM server. This IP address is checked by the RTU500 series during the
certificate validation.
• For uploading the public key certificate must be in PKCS#7 format with the file ending ".p7b".

The upload of a public key certificate is done via the RTU500 series Web server. For detailed
information about the upload process see chapter "Certificate Upload". When the upload is finished
the public key certificate is active and can be used directly. A restart of RTU500 series device is not
required.

4.1.6 CAM integration

In the RTU500 series with Central User Account Management several additional information are
required besides the standard configuration file and the local password file. These information
are provided to the RTU by uploading defined files or by web server user interfaces. For a better
understanding of the following description of configuration options and user interfaces, the figure
below shows for the CAM integration all related files uploaded to or stored on the RTU.

1KGT151106 V005 1 45
Design Principles Central user account management

RTU500

Flash Card

Encrypted
Configuration Communication
CAM Server File (RCD) Parameter
Public Key
XXXXX
XXXXX
RTU500 Firmware XXXXX
Activities XXXXX

Encrypted LAM
CAM Server Password File
Communication
Parameter XXXXX
XXXXX
XXXXX
XXXXX
Certificate Store
Upload files Access stored
information CAM Server
Public Key

XXXXX
XXXXX
XXXXX
XXXXX

Figure 29: CAM related files in the RTU

The tasks of the different files are:

• CAM Server Public Key

To authenticate the CAM server requested for user authentication the public key of the server is
uploaded to the RTU. With the public key the certificate presented by the CAM server is verified
to ensure the server identity. The uploaded public key is stored encrypted in the RTU500 series
certificate store on the flash card.
• CAM Server Communication Parameter
The communication parameters to access the CAM server (e.g. IP address of server) are not
part of the RTUtil500 configuration. This is required to protect editing the parameters and to
allow changes without updating the RTUtil500 configuration. The parameters can be configured
by a corresponding GUI in the web interface or by uploading a structured text file containing
these information. In both cases the communication parameter are stored encrypted on the flash
card for subsequent access.
• Configuration File
The standard RTU configuration file contains the basic CAM setup. This includes the CAM
server type, the fallback options in case the CAM server is not available, the priority within the
RTU in case of multiple CAM servers and the reference to the certificate store for uploading the
CAM server public key.

46 1KGT151106 V005 1
Central user account management User Interface

• Local User Account Password File

As described above the CAM servers covers the authentication of a user only. The authorization
of a user is done with information in the local password file. That means whether a user is
allowed to perform a certain action is not checked by the CAM server but by the role-to-
permission assignments stored in the password file of the Local User Account Management
(LAM). The assignment information can be set by a corresponding GUI in the web interface as
explained in chapter "User Roles" of the LAM description. The LAM password file with the role-
to-permission assignments are stored encrypted on the flash card.

4.2 User Interface

4.2.1 RTUtil500 configuration

To activate the central account management for the RTU500 series a CAM client must be added to
the Ethernet interface of a CMU module. This is done in the hardware tree of the configuration tool
RTUtil500. The figure below shows an example hardware tree with a CAM client added to the first
Ethernet interface of a 560CMR02 CMU module.

For more information about how to use and add functionality to the hardware tree in RTUtil500
please refer to the User Manual RTUtil500 Release 13 (1KGT151107).

Figure 30: CAM client in hardware tree

For redundant setups multiple CAM clients can be configured within an RTU. The limits of multiple
CAM clients are:

• Per CMU module 1 CAM client can be configured.

• Per RTU up to 4 CAM clients can be configured.

In multi CMU configurations, one CAM client on any CMU is sufficient to enable the CAM
authentication for the whole RTU. CMU modules without CAM client are using the internal
communication of the RTU to access the client on another CMU.

The CAM client in the RTU500 series access one logical CAM server that can consists of 1 or more
physical machines. The communication parameters for the CAM server, like IP addresses or base
distinguish names, are not part of the RTUtil500 configuration. These parameters are set in the web

1KGT151106 V005 1 47
User Interface Central user account management

interface as described in chapter "CAM Management". The configuration options at a CAM client in
RTUtil500 are shown in the next figure.

Figure 31: CAM client parameter in RTUtil500

In the RTUtil500 configuration the CAM server type, the CAM server certificate, the priority within
the RTU500 and the fallback option has to be set.

As CAM server type the options “ABB IEC 62351 Authentication Server”, “Microsoft Active Directory
Server” and “Group Based LDAP Authentication Server” are selectable. The CAM server type can
be different for each CAM client within an RTU.

For the CAM server certificate, the certificate store has to be configured first. That means an entry
has to be added to the certificate store representing the public key used to check the identity of the
CAM server (see chapter "User authentication"). The certificate store configuration can be found in
the hardware tree at the general tab of the CMU module (see next figure).

Figure 32: RTUtil500 certificate store configuration

The certificate store configuration opens by pressing the button "Configuration" shown in the figure
above (near the text "Certificate Storage"). When selected a dialog appears with several entries
for certificates. Each entry represents a certificate that shall be transferred to the CMU. To add

48 1KGT151106 V005 1
Central user account management User Interface

a certificate, select the check box at the entry number and give the entry a descriptive name. An
example of the certificate store configuration is shown in the figure below.

Figure 33: RTUtil500 certificate store

The priority of the CAM client is defined between 1 as highest priority and 4 as lowest priority. The
consistency check validates as error whether each CAM client is configured with a different priority.
The set priority is used as well to identify the system event (SEV) used to signalize the CAM server
connection state (see below).

The fallback option when the connection to the CAM server is not available is the local user account
management (LAM) with the local password file. The local password file used for LAM are not
affected by the CAM client configuration. The password file remains on the RTU whether LAM is
selected as fallback option or not. As described above, the password file is necessary because the
included authorization information (role-to-permission assignment) is still required to validate the
user actions.

To avoid unsecure configuration in connection with CAM please consider the following advice.

ADVICE
In a CAM configuration the user credentials are transmitted as plain text from the Web browser
to the RTU500 series. Therefore the secure Web server access via HTTPS shall be enabled
for the RTU500 series if a CAM client is used. This applies for all CMU modules in a multi CMU
setup.

For each CAM client a system event signalize the state of the CAM server connection. The
connection is checked on LDAP protocol level every 30 seconds. The system event is named "CAM
client x online" like shown in the example figure below.

1KGT151106 V005 1 49
User Interface Central user account management

Figure 34: CAM client system event

4.2.2 User Authentication

The information about the user authentication when accessing the RTU500 series Web server can
be found in chapter "Web server user authentication". There the differences between the local and
the central user account management regarding log-in are described.

4.2.3 CAM Management

The central user account management (CAM) in the RTU500 series is enabled by an
according configuration in RTUtil500. This configuration contains the type of CAM server but no
communication related information. These information are set via the RTU500 series Web server to
protect the access and to allow changes without updating the RTUtil500 configuration.

In the Web server menu the link "CAM Management" is the entry point for the communication
configuration of the CAM client. This link can be found under the menu item "Management" as

50 1KGT151106 V005 1
Central user account management User Interface

shown in the next figure. The link is shown if no CAM client is configured, as well. In this case an
error message appears if the menu item is selected.

Figure 35: Web server menu CAM management

Selecting the menu item starts a user interface to perform the following tasks:

• Set the communication parameter of the CAM client

• Sending the communication parameter of the CAM client in a file to the RTU
• Receiving the communication parameter of the CAM client in a file from the RTU
• Activate or deactivate the CAM client
• Test the connection and authentication of the CAM server

The user interface for the central account management consists of several menu tabs. Each menu
tab handles one (or more) of the tasks stated above. The next chapters describe each menu tab in
detail.

The user interface is available on the CMU (none redundant CMU or active CMU of redundant
pair) that contains the CAM client only and the configuration is specific for this CAM client.
On other CMUs without CAM client (in a multi CMU setup), no information are shown in
the CAM management user interface. That means the CAM client must configured on the CMU that
contains the client.

Additional to the communication parameter the CAM server public key certificate must be uploaded
to the RTU. Information about the certificate for the CAM server can be found in chapter "CAM
server public key certificate". CAM certificate can be revoked by loading a certificate revocation
list (CRL) provided by issuer of certificate. If used certificate is revoked connection to CAM server
remains active until deactivation or restart of the RTU.

4.2.3.1 Setting communication parameters

In the first tab of the central user account management the communication parameter of the
CAM client can be set. In a grid view information about the CAM client are shown and specific
communication parameter can be set. An example of the user interface is shown in the figure below.

1KGT151106 V005 1 51
User Interface Central user account management

Figure 36: Menu tab for communication parameter setting

As information, the grid view shows the CAM client number, the actual CAM activation state and
the CAM server type. The client number and the server type are from the RTUtil500 configuration
used. The activation state indicates whether the specific CAM client is active or not. For detailed
information about the possible activation states see chapter . The information part in the grid view is
static and cannot be changed by the user.

The subsequent connection parameters can be set by the user or changed from the default values.
The parameters are up to two IP addresses of the CAM server, the used TCP/IP port and the
communication timeout in seconds. The timeout is required to consider low bandwidth connections.

Besides the connection parameters up to 8 base distinguish names (Base DNs) can be defined.
The base distinguish names defines in which area/domain the CAM server shall search for the
requested user authentications. The area/domain is a classification criterion not related to user
groups or roles. Please refer to the documentation of the used CAM server to determine how the
base distinguish names must be set.

Editing the communication parameters is possible if the CAM client is not active, only. If the client
is active the parameters are shown but cannot be changed. To enable editing again the CAM client
must be deactivated. When editing is finished the changes must be confirmed by pressing the
"Save" button above the grid view. When saved the parameters are checked for validity and stored
on the RTU. In case of invalid parameters an according error message appears and the parameters
are set back to the last values. If the web page is switched without saving the communication
parameters, any changes are lost.

If the parameter changes shall be dismissed and not stored on the RTU, the button "Cancel" can be
pressed. In this case a confirmation dialog appears and if approved the last stored parameter are
reloaded, overwriting any changes.

To be able to activate the CAM client in the RTU500 series the following communication parameters
must be set at least:

• One CAM server IP address. The second IP address can be set for redundant server setups.
• The TCP/IP port. It is recommended to use the standard LDAP port 389 (default value) but this
can be changed if required.

52 1KGT151106 V005 1
Central user account management User Interface

• The communication timeout between 1 and 300 seconds.

• At least one base distinguish name. The other distinguished names can be set if the CAM server
shall search for users in several domains.

4.2.3.2 Upload communication parameters

In the second menu tab the communication parameter of the CAM client can be uploaded to
or downloaded from the RTU. The CAM client communication parameters are included in a
structured XML text file for upload and download. For uploading the RTU500 series supports 2 XML
file formats. First the file format specified for the ABB Authentication Server included in SDM600
(SDM600 format). And second an extend format including all CAM client communication parameter
supported by the RTU500 series (RTU500 format). For detailed information about the file formats
see the paragraphs below.

The user interface for uploading and downloading the communication parameter (see figure below)
are separated in two areas. The upper area contains the communication parameter actually stored
on the RTU500 series and the lower area controls the uploading to the RTU.

Figure 37: Menu tab for upload/download CAM client communication parameter

To download the actual stored communication parameter press the receive button ( ) in the
grid row for the communication parameter (in the upper area). When pressed the actual parameters
are downloaded from the RTU and stored in XML format in the download folder of the host PC. The
XML format used is the extend format including all CAM client communication parameter supported
by the RTU500 series. The received file is a standard text file that can be edit and sent back to the
same or any other RTU with CAM client. The name of the downloaded file is “camComConf.xml”.

To upload the CAM client communication parameter to the RTU, the following steps has to be
executed in the lower area of the user interface:

1 Select in the column for the file description the "CAM client communication parameter". The both
file formats supported by the RTU500 series are automatically detected.

1KGT151106 V005 1 53
User Interface Central user account management

2 Select a file with communication parameter by dropping the file on the lower area or by using the
file open dialog that appears when clicked with the mouse. The XML parameter file must be in
one of the both supported formats. The file to upload can have any name but the extension must
be "*.xml".

When both steps are finished the communication parameter can be uploaded to the RTU by
pressing the send button (see figure below). The send button doesn't appear before all required
information are set. The uploaded file with the communication parameter are checked for
completeness, validity and plausibility by the RTU500 series firmware. If the uploaded file is
not correct the CAM client communication parameter are not set and an according message is
presented to the user.

Figure 38: Example CAM client communication parameter upload

The version number shown in the upper area can be used to check whether different RTUs use the
same CAM client communication parameter. The version number is build according to the following
rules:

• When a parameter file in SDM600 format is uploaded to the RTU the version number is reset to
0. Because the SDM600 format doesn't contain a version information.
• When a parameter file in RTU500 format is uploaded to the RTU the version number is
overwritten by the number stored in the file (see format below).
• Each time the communication parameter are changed and saved in the "Parameter" tab, the
version number is increased by 1.

The both file formats supported for the communication parameters are the SDM600 and the
RTU500 format. In both formats the parameters are described in an XML structure. The difference
between the formats are the available parameters and the used XML tags. The RTU500 format
contains all CAM client communication parameter supported by the RTU500 series including a
version number. The SDM600 format contains besides other definitions a subset of the supported
parameter only. The following section shows an example of the SDM600 format:

<?xml version="1.0"?>
<SDM600_CAM_IED_Configuration

54 1KGT151106 V005 1
Central user account management User Interface

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://abb.com/ConfigurationSchema.xsd">
<IED_information>
<name>Aeroglen</name>
<description>Aeroglen</description>
<address>192.168.0.110</address>
</IED_information>
<BaseDN>ou=CamUsers,dc=vmbox,dc=int</BaseDN>

<Replication_Group>memberOf=cn=RTU_Engineer,ou=Groups,dc=vmbox,
dc=int</Replication_Group>
<Replication_Interval>1440</Replication_Interval>
<CAM_Servers>
<CAM_Server>
<ldapaddress>ldap://192.168.0.201:389</ldapaddress>
</CAM_Server>
</CAM_Servers>
</SDM600_CAM_IED_Configuration>
The parameters relevant for the RTU500 series in the SDM600 format are the base distinguish
name “BaseDN” and the LDAP address “ldapaddress”. The distinguish name is taken as it is and
the LDAP address is parsed for the IP address and port number of the CAM server. The parameter
file in SDM600 format are part of the configuration package generated by SDM600 (see System
Data Manager SDM600 - User Manual). Before uploading the parameter file to the RTU extract the
file from the configuration package (ZIP format) provided by SDM600. The file can be identified by
the extension "*.xml".

The RTU500 format contains all communication parameter shown in the "Parameter" tab and
described in chapter . An example of the RTU500 format is shown in the next section.

<?xml version="1.0" encoding="UTF-8"?>

<rtu500CAMConfiguration version="12">
<camServers>
<camServer>
<ipAddresses>
<ipAddress>192.168.1.1</ipAddress>
<ipAddress>192.168.2.1</ipAddress>
</ipAddresses>
<ipPort>389</ipPort>
<comTimeout>2</comTimeout>
<baseDNs>
<baseDN>ou=CamUsers,dc=vmbox,dc=int</baseDN>
<baseDN>ou=rtuUsers,dc=vmbox,dc=int</baseDN>
</baseDNs>
</camServer>
</camServers>
</rtu500CAMConfiguration>
The parameter file in RTU500 format can be edit by the user or build from scratch with the needed
values. Use the example above as guideline but do not exceed the maximum number of supported
parameters. Two CAM server IP addresses and up to 8 base distinguish names are permitted.
For uploading the parameter file to the RTU make sure the file name extension is "*.xml".

1KGT151106 V005 1 55
User Interface Central user account management

4.2.3.3 Activate CAM client

In the third menu tab the CAM client on the RTU can be activated or deactivated. When the CAM
client is not active, which is the default state after the configuration, the user authentication is done
with the local user account management (LAM). After the activation the user authentication is done
on the CAM server. If the CAM server is not available LAM can be used as fallback, if configured
accordingly The next figure shows the structure of the menu tab for activation/deactivation.

Figure 39: Menu tab for CAM client activation and deactivation

The user interface shows the buttons for activation and deactivation the actual activation state of
the CAM client. The possible activation states are listed below:

• In Configuration
This is the default state indicating that the communication parameters of the CAM client
must be set or send to the device. The CAM client remains in this state as long the required
communication parameter are not set and the CAM server public key certificate is not uploaded
to the RTU. In this state the user interface shows (in this tab) a list of missing information and
configuration mistakes that must be added or solved. Activation of the CAM client is not possible
in this state.
• Ready for Activation
When all required communication parameters for the CAM client are set and the CAM server
public key certificate is uploaded the state change to "Ready for Activation". In this state the
CAM client can be activated by pressing the button "Activate".
• Activated
The state "Activated" indicates that CAM client is active and the user authentication is done
on the CAM server. Activating the CAM client doesn't lead to log-out. That means the actual
existing user session, whether the user is authenticated by LAM or CAM, remains and the user
stays logged-in. When activated the CAM client can be deactivated by pressing the button
"Deactivate".

The buttons for activation and deactivation of the CAM client are enabled according to the actual
state. In configuration both buttons are disabled and cannot be selected. When the CAM client is
activated the "Deactivate" button is enabled and if the state is "Ready for Activation" the button
"Activate" can be selected.

4.2.3.4 Test connection

The last menu tab contains the user interface for testing the CAM server connection. The testing
allows to check the communication setup without the necessity to log-off from the web interface.
The test functionality allows to check the LDAP connection to the CAM server and as well the user
authentication on the CAM server. The figure below shows the user interface for testing the CAM
client.

56 1KGT151106 V005 1
Central user account management User Interface

Figure 40: Menu tab for testing CAM server connection

Testing the server connection is only possible, if the CAM client communication setup is complete
and the CAM client is active. If the client is not active an error message appears when the tests are
executed. To start the tests follow the instructions below:

• Testing the LDAP connection

For testing the LDAP connection to the CAM server the button "Test connection" must be
pressed only. The result of the test is shown with an according message at the bottom of the
browser window. This test doesn't check the uploaded CAM server public key certificate.
• Testing user authentication
To test the user authentication provide a user name and password in the according input
fields and press the button "Test connection". An according message at the bottom of the
browser window shows the result of the test. This test covers the uploaded CAM server public
key certificate. If the user name or the password is missing no authentication but the LDAP
connection is tested, only.

As the CAM client must be active when performing the tests, be sure to consider the following
advice.

ADVICE
If the user authentication test fails with a correct user name and password, deactivate the
CAM client before checking for the reason. Because with activated CAM client and failed user
authentication you may be excluded from the RTU500 series Web server.

4.2.4 Change user password

In the central account management all user accounts and their passwords are stored on the CAM
server. The administrator of the CAM server can enforce the change of a user password by setting
an expiration time for password. In this case the user must change his own password after the set
time interval. This change can be down in the RTU500 series Web interface.

To change the own password the logged-in CAM user must select the menu tab "User Accounts" in
the user account management. As for the local user accounts the appearing table shows the logged
in user and the password can be changed by selecting the lock symbol. In the change password
dialog the current and the new password must be typed. By pressing "Ok" the minimum password
policies are checked and if the password is valid the dialog closes. But closing the dialog does not
store the new password on the CAM server.

To store the new password on the CAM server the button "Save" must be selected. Then the
new password is checked against the policies rules defined on the CAM server and stored when

1KGT151106 V005 1 57
User Interface Central user account management

valid. If changing the password succeeds the user is logged-out. If the new password is invalid or
the current password is incorrect an according error message is shown. By pressing the button
"Cancel" the password is not changed and the old password is still valid. The following figure shows
the user interface for changing the own password of a CAM user.

Figure 41: Dialog to change own password of a CAM user

58 1KGT151106 V005 1
Security event logging Security event format

5 Security event logging

Security relevant user operations within the RTU are logged as security events in a file on the
flash file system. A security event contains an event id (see chapter "Security event types"), a time
stamp, a sequence number, the user name, the severity of the action and the name of the source.

Each CMU in an RTU has an own security event log. In every log the security events of the
complete RTU are stored, but the event log is not equalized between different CMU modules. The
content of security event log could be shown in the RTU500 series Web server. The events shown
are from the CMU module the web server or integrated HMI is connected to.

To ensure integrity of the event log a salted hash value is calculated for the content of the log and
stored together with file. During initialization of the RTU the event log is checked for integrity with
the stored hash value. In case of differences a diagnosis log entry is created and a corresponding
event is written to the log.

The security events logged in an RTU can be sent to external security log servers. The RTU
supports the protocols Syslog UDP, Syslog TCP and ArcSight TCP for external log servers.

5.1 Security event format

The security events in the RTU500 series have a fix format. This format could not be changed and
contains the following attributes:

• Sequence number
• Time stamp with time and date
• Name of user that causes the event
• Event id representing a certain event type (see next chapter)
• Severity of the event. Possible value are "Event" and "Alarm" depending on the importance of
the event
• Source of the event. Defined as name of the RTU taken from the configuration.
• Event text that’s describes the user operation (fix per event type)
• Additional, changing information text (variable per event type)

5.2 Security event types

The RTU500 series supports a defined set of security event types. Each type is identified by a
unique event id. The following list summarizes the supported event types.

Event id Event name Comment

1110 Log-in successful Log in via Web server or Inte-
grated HMI
1120 Log-in failed - Unknown user Reason logged but not shown as
error message
1140 Log-in failed - Wrong password Reason logged but not shown as
error message
1150 Log-in failed - Password expired Logged and shown as error mes-
sage
1170 Log-in failed 3 times
1210 Log-out (user logged out)
Table 9: Security event types in the RTU

1KGT151106 V005 1 59
Security event types Security event logging

Event id Event name Comment

1220 Log-out by user inactivity (timeout) Timeout configurable
1370 Viewed Security Event logs successfully
1670 Viewed security event list failed
1720 User Accounts reset to factory default
2110 User account created successfully
2120 User account deleted successfully
2130 User account creation failed
2140 User account deletion failed
2160 New role assigned to user successfully
2162 Permission added successfully Permission assigned to role suc-
cessfully
2170 User role assignment removed successfully Role withdrawn from user suc-
cessfully
2172 User permission removed successfully Permission withdrawn from role
successfully
2180 New role created successfully
2190 Role deleted successfully
2210 User password changed successfully Own password only or administra-
tor permissions required
2220 Change of user password failed Own password only or administra-
tor permissions required
2230 New user role assignment failed Assigning role to user failed
2232 Addition of permission failed Assigning permission to role
failed
2233 User Password change failed - too short
2235 User Password change failed - policy check failed
2240 User session role changed successfully
2245 User session role change failed
2270 Role assignment removal failed Withdraw role from user failed
2272 User permission removed failed Withdraw permission from role
failed
2280 New role creation failed
2290 Role deletion failed
2510 Password file on CF card corrupted
3210 TCP communication with security log subscriber
failed
3220 Log data hash check failed (Log data altered) Security event log was modified
or deleted
3430 Security log file deleted by system Migration to new version or log
modification
3710 CAM Server communication successful
3810 CAM Server communication failed
4310 VPN Connection successful
4350 VPN Connection failed - Negotiation failed
5110 Manual Reset Restart via Web server
Table 9: Security event types in the RTU

60 1KGT151106 V005 1
Security event logging Security event types

Event id Event name Comment

5160 Gateway/RTU restarted Power off or restart via Web
server
6110 Test Mode started Allow simulation via Web server
6120 Test Mode ended Stop simulation in Web server
6130 Control operation performed successfully Logged once in test mode
6132 Failed to perform a control operation Logged once in test mode
6140 Signal forced - value changed Logged once in test mode
6210 System time set manually successfully System time set via Web server
6310 System time set manually failed
6510 Debug mode started successfully PLC debug mode
6520 Debug mode ended PLC debug mode ended manual
or by timeout
6550 Protocol logging mode started RIO protocol logging
6560 Protocol logging mode ended RIO protocol logging ended man-
ual or by timeout
8030 New certificate generated successfully
8230 New certificate generation failed
13200 Configuration transferred to the device successfully Covers all kind of configuration
files
13220 Configuration changed successfully Online configuration via Web
interface
13250 Entered configuration mode successfully Online configuration via Web
interface
13260 Exited configuration mode successfully Online configuration via Web
interface
13300 Configuration files read/exported from the device Covers all kind of configuration
successfully files
13400 Firmware transferred to the device successfully Covers all kind of firmware files
13500 Firmware files read/exported from the device suc- Covers all kind of firmware files
cessfully
13520 Certificates transferred to the device successfully
13560 Exported/read archive file from the device success- Covers all kind of archive files
fully
13570 Exported/read diagnosis file from the device suc-
cessfully
13580 Exported/read certificates from device successfully Covers all kind of certificates
13900 Security logs read/exported from the device suc-
cessfully
14200 Failed to transfer configuration to the device Covers all kind of configuration
files
14220 Failed to change the configuration Online configuration via Web
interface
14250 Failed to enter configuration mode Online configuration via Web
interface
14260 Failed to exit configuration mode Online configuration via Web
interface
Table 9: Security event types in the RTU

1KGT151106 V005 1 61
View security events Security event logging

Event id Event name Comment

14300 Failed to read configuration files from the device Covers all kind of configuration
files
14400 Failed to transfer firmware to the device Covers all kind of firmware files
14500 Failed to read firmware files from the device Covers all kind of firmware files
14520 Failed to transfer certificates to the device
14560 Failed to read archive file from the device Covers all kind of archive files
14570 Failed to read diagnosis file from the device
14580 Failed to read certificates from the device Covers all kind of certificates
14900 Failed to read security logs from the device
23100 Password file transferred and stored in the device
successfully
23200 Password file read/exported from the device suc-
cessfully
23500 Failed to transfer password file to the device
23600 Failed to read password file from the device
Table 9: Security event types in the RTU

5.3 View security events

To view the security event archive in the RTU500 series Web server the link "Security Archive" must
be selected. This link can be found under the menu item "Operation" as shown in the figure below.

Figure 42: Web server menu security archive

One page of the security event list shows in maximum 50 events. An example of the event archive
is shown in the next figure.

62 1KGT151106 V005 1
Security event logging View security events

Figure 43: Displaying security event archive

To navigate inside the list there are several buttons above the list. The buttons have the following
meanings (from left to right):

•
Go to end of the security event list to show the newest entries.
•
To scroll one page forward in the event list (towards newer entries).
•
To scroll one page backward in the event list (towards older entries).
•
Go to beginning of the security event list to show the oldest entries.
•
Download complete security event list in predefined CSV format.

For displaying and downloading of the security event list the following definitions apply:

• For each security event an event text is shown. The text depends on the specific event id and
is in the language selected for the whole RTU500 series Web server. To change the event text,
the text must be modified in the language file of the Web server (like the other texts in the Web
server as well).
• All time stamps of the security events are shown in local time (local time zone) as defined for the
whole RTU.
• When downloading the security event list the resulting CSV file contains the events in the same
format and language as shown in the Web server display. This applies as well for the time
stamps that are in local time.
• The size of the security event archive is configurable in RTUtil500. If the configured limit is
reached the oldest security events in the archive are overwritten, when new events occur.

For more information about the localization support please refer to the RTU500 series Web server
documentation. For detailed information about the available security event archive limits see
chapter "RTUtil500 configuration".

1KGT151106 V005 1 63
Supervisory monitoring: security indications and alarms Security event logging

5.4 Supervisory monitoring: security indications

and alarms
To be able to monitor security events, map them to any host protocol and to make them available to
the RTU internal functions PLC, logic functions, process archive and integrated HMI, it is possible to
map one or more security events to indications.

Security events can be defined as input parameter of the new logic functions "Security indication"
and "Security alarm". The output parameter of these functions is an indication, which can be
configured and used like any other indication.

For details about the logical functions "Security event" and "Security alarm" see RTU500 Series
Function Description - Part 5: SCADA functions (1KGT151099), chapter "Logic Functions"

5.5 External log servers

To send security events to external log servers the RTU supports up to 3 log servers per Ethernet
interface on a CMU. For each log server an individual type and target IP address/port can be
configured. The following parameters are configurable within RTUtil500:

• Option to enable sending of security events to external log servers. Disabled by default.
• Protocol type of the external log server. The RTU supports the protocols Syslog UDP, Syslog
TCP and ArcSight TCP.
• Target IP address of the external log server.
• Target IP port of the external log server. Each configurable type is defined with a default port that
can be changed (see chapter "TCP/UDP Ports" for the defined default ports).

In RTUtil500 the external security log servers are added at a CMU module for one or more Ethernet
interfaces (Hardware tree only). The figure below shows the RTUtil500 dialog to add an external
security log server at the first Ethernet interface.

64 1KGT151106 V005 1
Security event logging External log servers

Figure 44: RTUtil500 add external security log server

In case the CMU supports more than one Ethernet interface, the external log servers can be
added to all interfaces or to each Ethernet interface individually. To configure the parameters of the
external log servers, the log server has to be selected in the hardware tree (below the CMU) and
the tab "External Security Log Server" has to be opened. The next figure shows these configuration
parameters.

Figure 45: RTUtil500 external log server parameter

In this tab the described parameters for external security log servers are configured. The
consistency check of RTUtil500 displays a warning if an external log server is enabled but no target
IP address or IP port are configured.

1KGT151106 V005 1 65
External log servers Security event logging

The security events are sent to the external log servers at the moment the event occurs. The
security events are sent in the format defined for the supported protocols. Please refer to the
protocol description of Syslog and ArcSight for detailed information about the event format.

If the external log server is not available at the moment an event occurs the handling in the RTU
depends on the type of log server. The following handling is supported:

• Syslog UDP: Due to the unconfirmed UDP protocol the event is send on the network but lost in
case the log server is not available.
• Syslog TCP, ArcSight TCP: An occurred event is stored in a small FIFO queue (maximum
10 entries) before sending to the log server. In case the log server is not available the event
remains stored in the FIFO queue and the RTU tries to send the event to the log server in cyclic
intervals. If the FIFO queue is full new events are lost. After a restart of the RTU the FIFO queue
is erased and not sent events are lost.

66 1KGT151106 V005 1
Secure Web Server Access RTUtil500 configuration

6 Secure Web Server Access

For secure access, the RTU500 series web server supports Hypertext Transfer Protocol Secure
(HTTPS). HTTPS is a combination of the Hypertext Transfer Protocol with the SSL/TLS protocol to
provide encryption and secure identification of the server. Detailed information about HTTPS could
be found in RFC2818 “HTTP Over TLS”.

For the identification the RTU500 series web server uses as default self-signed public key
certificates not issued by a certification authority (CA). The default self-signed certificates are
created at startup depending on the configuration. In addition the RTU500 series web server
supports the upload of external generated HTTPs certificates. This allows to use trusted certificates
issued by a certification authority (CA). Externally generated certificates can be revoked by loading
a certificate revocation list generated by issuer of certificate. If the used certificate is revoked the
RTU switches to self-signed certificate.

Client authentication with user certificates is not supported by the RTU500 series. The
authentication of the user is ensured by a user name and a password.

ADVICE
For security reasons, the web client has to be closed after each working session. This prevents
the usage of supplied user names and passwords by unauthorized persons.

The following chapters describe configuration, access and certificate handling for the secured
RTU500 series web server.

6.1 RTUtil500 configuration

The configuration parameters for the Web server access are defined for each CMU respectively
Ethernet interface within an RTU. The following parameters are configurable within RTUtil500:

• Option to disable the Web server on selected Ethernet interfaces. This is possible in single and
multiple CMU systems. The Web server must be enabled on at least one Ethernet interface
to be able to access the RTU at all. The Web server is enabled on all Ethernet interfaces by
default.
• Option to secure the Web server access with HTTPS. This option can be selected on each
CMU. The HTTPS option is enabled by default
• Define the authentication type for the secure Web server. Possible are the default self-signed
certificate or an uploaded external certificate stored in the certificate store of the CMU.
• Set an entry in the certificate store of the CMU to upload external HTTPS certificates for the
Web server authentication.

In RTUtil500 the option to disable the Web server is placed at the CMU in the configuration tab of
the Ethernet interface, e.g." E1" (Hardware tree only). The figure below shows the option in the
RTUtil500 user interface. The Web server is disabled by deselecting the checkbox "Enable Web
server".

1KGT151106 V005 1 67
RTUtil500 configuration Secure Web Server Access

Figure 46: RTUtil500 Ethernet interface Web server parameter

As shown in the next figure, the configuration parameters related to the secure Web server are
located in the "General" tap at a CMU module (Hardware tree only). To secure the RTU500 series
Web server with a self-signed certificate follows these steps:

1 Select the checkbox "Secure HTTPS Web server".

2 Select the option "Self-created and self-signed certificate" in the drop-down menu "Web-server
authentication" (shall be pre-selected).

Figure 47: RTUtil500 secure Web server parameter

For the usage of an external HTTPS certificate, the certificate store has to be configured at first.
That means an entry has to be added to the certificate store representing the certificate used for the
Web server authentication.

The certificate store configuration opens by pressing the button "Configuration" shown in the figure
above (near the text "Certificate Storage"). When selected a dialog appears with several entries
for certificates. Each entry represents a certificate that shall be transferred to the CMU. To add
a certificate, select the check box at the entry number and give the entry a descriptive name. An
example of the certificate store configuration is shown in the figure below.

68 1KGT151106 V005 1
Secure Web Server Access Web server user authentication

Figure 48: RTUtil500 certificate store

Together with the certificate store the steps to secure the RTU500 series Web server with an
external certificate are:

1 Configure an entry in the certificate store representing the external certificate to upload. Give the
entry a descriptive name like "Web server certificate".
2 Select the checkbox "Secure HTTPS Web server".
3 Select in the drop-down menu "Web-server authentication" the certificate from the store. Here
the name given in the first step is selected.
4 Upload the external HTTPS certificate via the RTU500 series Web server.

Further information about the upload of external HTTPS certificates can be found in the chapters
"External Certificate" and "Certificate Management".

6.2 Web server user authentication

After a successful connection with a Web browser to the RTU500 series Web server, the server
requests a user name and password for log-in. The log-in dialog presented by the Web browser
depends on the configuration of the RTU. With the local user account management (LAM) a
standard log-in dialog, generated by the Web browser itself, appears. Examples for this kind of log-
in dialog are shown in the next figure. The Examples are from the Microsoft Internet Explorer and
the Google Chrome Browser.

1KGT151106 V005 1 69
Web server user authentication Secure Web Server Access

Figure 49: LAM log-in dialog examples

With the central user account management (CAM) a common log-in dialog, generated by the Web
server, is shown (see figure below). Additional to the input fields for user name and password the
dialog contains an information whether the CAM server is available or not. This information named
protection space can have the following values:

• CAM Server
CAM server connection is online. Login via CAM server is required.
• LAM Backup
CAM server connection is offline and LAM is configured as backup. Login is possible via LAM.
• Not available
CAM server connection is offline and LAM is not configured as backup. No login is possible.

70 1KGT151106 V005 1
Secure Web Server Access HTTPS Web server access

Figure 50: CAM log-in dialog

To avoid unsecure configuration in connection with the central user account management (CAM)
the following advice shall be considered.

ADVICE
In a CAM configuration the user credentials are transmitted as plain text from the Web browser
to the RTU500 series. Therefore the secure Web server access via HTTPS shall be enabled
for the RTU500 series if a CAM client is used. This applies for all CMU modules in a multi CMU
setup.

6.3 HTTPS Web server access

To access the RTU500 series Web server via HTTPS the URL given in the Web client must begin
with “https://” followed by the IP address of the RTU. The following figure shows an example.

1KGT151106 V005 1 71
Certificate handling Secure Web Server Access

Figure 51: HTTPS access to an RTU Web server

The default Web server certificates used by the RTU500 series are self-signed and not issued by
a certification authority (CA). As result an actual web client shows a warning messages concerning
the missing CA, if the Web server is accessed with HTTPS. To avoid this warning message a
trusted external certificate must be configured and uploaded to the RTU500 series.

If the Web server is configured for HTTPS a standard access is not possible anymore. In case of
a standard access the Web server redirects the access to the secure pages of the RTU500 series
Web server.

If the Web server is not configured for HTTPS, a secure access is possible as well. There are no
restrictions in this case besides the possible warning message from the self-signed certificate.

See chapter "RTUtil500 configuration" for configuration and chapter "External Certificate" for upload
of external certificates.

6.4 Certificate handling

For encryption and secure identification HTTPS uses public key certificates that bind together a
public key with an identity (information such as the name of an organization, their address and so
on). The certificate is used to verify that a public key belongs to an identity. In case of HTTPS the
Web server presents the certificate to the web client giving the client the public key and the identity
of the server.

The public key is one part of an asymmetric key algorithm, where the key used to encrypt a
message is not the same as the key to decrypt it. Messages encrypted with the public key can only
be decrypted with the other part of the algorithm the private key. Public and private key are related
mathematically and represents a cryptographic key pair. The private key must be kept secret, whilst
the public key may be widely distributed.

This requires for the RTU a public/private key pair and a corresponding public key certificate. There
are two possibilities for this purpose. First the self-signed certificates generated by the RTU500
series firmware can be used or a trusted, extern generated certificate can be uploaded to the RTU.
When uploading, a certificate must be available for each CMU because the Web server can be
accessed on any CMU. Further information about the self-signed and extern generated certificates
can be found in the following two chapters.

72 1KGT151106 V005 1
Secure Web Server Access Certificate handling

6.4.1 Self-signed certificate

In the default setup the RTU500 series Web server uses self-generated and self-signed public key
certificates for encryption and secure identification. As explained above the certificate consists of a
public/private key pair and an identity information. The key pair and the certificate are generated by
the RTU firmware and stored in the internal flash of the CMU (not on the memory card).

The following procedure is executed the first time the RTU firmware starts:

1 Generate an RSA public/private key pair depending on random conditions.

2 Generate a certificate with predefined identity information (see below for more information).
3 Bind together certificate and public key with a digital signature (self-sign certificate).
4 Encrypt the public/private key pair with a symmetric key provided by the RTU firmware.
5 Store the encrypted key pair and the public key certificate in the internal flash of the CMU.

The usage of the private/public key pair and the certificate for the Web server communication are
explained in the following figure.

Figure 52: Usage of key pair and certificate within an RTU500 CMU

As described the internal flash of the CMU contains the encrypted private/public key pair and the
public key certificate. The key pair is read from the flash, decoded with a symmetric key defined
in the firmware and stored in the RAM of the CMU. The certificate is read as it is from the flash
memory and stored in the RAM as well.

The Web server accesses the public key certificate (stored in RAM) and presents it to web client
during the HTTPS protocol. The private key is used by the Web server to decrypt messages,
encrypted by the web client with the public key. For further information about the HTTPS protocol
see RFC2818 “HTTP Over TLS”.

The certificate contains HTTPS protocol specific information like the public key and identity
information. The identity information are set as follows.

• The identity information like country, locality and organization name are predefined to the ABB
AG, Mannheim, Germany. These cannot be changed.

1KGT151106 V005 1 73
Certificate handling Secure Web Server Access

• The common name of the identity is set to the configured IP address of the CMU Ethernet
interface E1. The common name represents the host name (server name) the web client uses to
access the Web server. In case the configuration of the IP address changes a new certificate is
generated and stored in the internal flash (overwrites the existing one).
• In subject alternative name the IP address of the Ethernet interface E1 and the USB interface
are defined. This allows the secure HTTPS access via USB as well.
• The serial number of the certificate is set to 1 for the first created certificate and increased every
time a new certificate is generated due to a configuration change.
• The expiration date of the certificate is set the 1. January 2070.

6.4.2 External Certificate

The RTU500 series supports the usage of external generated and signed public-key certificates
for the encryption and secure identification of the Web server. These certificates can be uploaded
to the RTU500 series via the Web server. When creating an end-entity certificate for the RTU500
series Web server the following issues shall be considered:

• The generated end-entity server certificate shall be signed and issued by a trusted root or
intermediate certificate. This avoids any warning messages in the Web client when accessing
the RTU500 series Web server via HTTPS.
• For a correct end-entity Web server certificate the attribute "keyUsage" must contain the
encryption value "keyEncipherment" at least. And the attribute "extendedKeyUsage" must
contain the server authentication value "serverAuth".
• The common name of the certificate identity must not be set to an IP address used in the RTU. It
is sufficient to set the attribute "IP Address" in the subject alternative name to a used IP address.
Depending on the policies in your organization setting the attribute "DNS Name" might be
necessary as well.
• To use the same certificate for several CMU's or RTU's a list of IP addresses and DNS names
can be defined in the subject alternative name.
• The generated certificate must contain the public/private key pair of the end-entity certificate.
The whole certificate chain, including root and intermediate certificates can be included but this
is not required.
• For uploading the generated certificate must be stored in PKCS#12 format with the file ending
".p12".

After uploading the external generated certificate, the certificate is stored as file on the memory card
of the CMU. In the Web server communication this certificate is used as explained in the next figure.

74 1KGT151106 V005 1
Secure Web Server Access Certificate handling

Figure 53: Usage of uploaded certificate within an RTU500 CMU

At startup the PKCS#12 certificate file stored on the memory card is parsed and first the encrypted
private/public key pair is decoded with a memory card specific key. The resulting plain private/
public key pair is stored in the RAM for the Web server. Then the end-entity certificate and the
CA certificates are extracted from the PKCS#12 file and stored in the RAM as well. At last all CA
certificates are combined to a certificate chain that is presented to the web client.

The Web server accesses the certificates (stored in RAM) and presents it to web client during the
HTTPS protocol. The private key is used by the Web server to decrypt messages, encrypted by
the web client with the public key. For further information about the HTTPS protocol see RFC2818
“HTTP Over TLS”.

The upload of an external generated certificate is done via the RTU500 series Web server. For
detailed information about the upload process see chapter "Certificate Management". When the
upload is finished the RTU500 series has to be restarted to activate the Web server certificate. And
it may be necessary to restart the Web client as well, to recognize the new certificate in the client

1KGT151106 V005 1 75
Certificate handling Secure Web Server Access

76 1KGT151106 V005 1
Certificate Management Certificate Upload

7 Certificate Management
For several security functionalities in the RTU500 series external generated certificates are
required. Examples of these functionalities are the central user account management (see chapter )
and the secure Web server (see chapter ). In either case the external certificates must be uploaded
via the web interface of the RTU500 series. The following chapter describes the process to upload
these certificates.

7.1 Certificate Upload

In the Web server menu, the link "Certificate Management" is the entry point for the certificate
upload. This link can be found under the menu item "Management" as shown in the figure below.
Due to the sensible information in the certificate upload the following notice has to be considered.

ADVICE
The web pages of this functionality require secure HTTPS access. It is not possible to open the
web pages with standard HTTP access.

Figure 54: Web server menu certificate management

In the certificate management, the certificates for different functionalities can be uploaded to the
RTU500 series. Generally there are two types of certificates with the following characteristics:

• Public Key certificates

These certificates contain the public key of a server certificate. The certificate type is used for
client activities in the RTU500 series like the central user account management (CAM). As the
certificates contain public information only, no password is required for the upload. The public
key certificates must in PKCS#7 format and the file extension must be "*.p7b".
• Private Key certificates
These certificates contain end-entity certificate with public/private key pair and possibly the
whole certificate chain. The certificates are used for server activities in the RTU500 series like
the Web server. For the upload the passphrase of the private key is required. The private key
certificates must in PKCS#12 format and the file extension must be "*.p12".

The user interface for the certificate upload is separated in two areas. The upper area contains the
certificates actually uploaded to the RTU500 series and the lower area controls the upload. The
following figure shows an example with two certificates to upload. One public key certificate for
CAM and a private key certificate for the Web server. As there is no trusted, certificate for the Web
server uploaded in the example, a certificate error is shown. This error is dissolved after the upload
of the Web server certificate (see last figure in this chapter).

1KGT151106 V005 1 77
Certificate Upload Certificate Management

Figure 55: Certificate management user interface

To upload a certificate the following steps has to be executed in the lower area of the user interface:

1 Select the description of the certificate to upload in the column "Certificate description". In
the selection all in RTUtil500 configured entries of the certificate store appear. The selection
text is the descriptive name set in RTUtil500 as explained in the chapter about the RTUtil500
configuration. The type of certificate to upload is written in the column "Certificate Type" of the
upper area.
2 Select a certificate file by dropping the file on the lower area or by using the file open dialog
that appears when clicked with the mouse. Depending on the certificate type, the file must be in
PKCS#7 or PKCS#12 format.
3 If a private key certificate is uploaded the password respectively passphrase of the private key
is required. To enter the passphrase select the lock symbol on the left side. When pressed a
dialog appears to enter the passphrase. The passphrase is used to decrypt the private key of
the certificate after the upload. For storing on the memory card the private key is re-encrypted
with a memory card specific key. The entered passphrase is not stored on the RTU500 series.
For public key certificates no passphrase is required.

When all steps are finished the certificate can be uploaded by pressing the upload button (see
figure below). The upload button appears not before all required information are set.

78 1KGT151106 V005 1
Certificate Management Certificate Upload

Figure 56: Start certificate upload

Check system log for additional information if certificate upload fails.

Depending on the activity that uses the uploaded certificate, it may be necessary to restart the
RTU500 series for activation of the certificate. Please refer to the specific activity documentation to
find the information whether a restart is required or not. In the example shown here the Web server
certificate requires a restart but the CAM certificate not.

After a successful upload and activation the certificate management looks like shown in the next
figure. The upper area contains now the information about the uploaded certificates. The certificate
error due to the missing trusted Web server certificate is not shown anymore.

1KGT151106 V005 1 79
Certificate Upload Certificate Management

Figure 57: Certificate upload successfully finished

System log contains diagnostic information about changes in current certificates state:
• Deleted,
• Added,
• Updated,
• Not available,
• Revoked.

7.1.1 Users Authority Certificate

The position for the Users Authority certificate PKCS#7 is preconfigured and always visible in
the first position. The certificate can be used for verification of user certificate for adding users
by certificates (see chapter "User Management using Web Server with Certificates"), verification
of asymmetric operations in HCI IEC60870-5-104 and authentication with client certificates
(see chapter "Authentication"). Only user with roles which have usrAccount@ABBRTU500 and
certificate@ABBRTU500 permissions can upload or removed the Users Authority certificate.

7.2 Certificate Revocation List (CRL) Upload

In the Web server menu, the link 'Certificate Management' is the entry point for the CRL file upload.
This link can be found under the menu item 'Management' as shown in the figure below. Due to the
sensible information in the CRL upload the following notice has to be considered.

ADVICE
The web pages of this functionality require secure HTTPS access. It is not possible to open the
web pages with standard HTTP access.

80 1KGT151106 V005 1
Certificate Management Certificate Revocation List (CRL) Upload

Figure 58: Web server menu certificate management

In the certificate management, the CRL can be uploaded to the RTU. In general, Certificate
Revocation Lists are expected in PEM format.

Figure 59: Certificate management user interface

The user interface for the certificate or CRL upload is separated in two areas. The upper area
contains the certificates and CRLs already uploaded to the RTU. The lower area controls the
upload. The following figure shows an example with one CRL to upload.

Figure 60: Select a place for CRL before upload

To upload a CRL the following steps have to be executed in the lower area of the user interface:
1 Select the description of the CRL to upload in the column 'Certificate description'. In the
selection all in RTUtil500 configured entries of the CRL store appear ('CRL_File'). The type of
CRL to upload is written in the column 'Certificate Type' of the upper area.
2 Select a CRL file by dropping the file on the lower area or by using the file open dialog that
appears when clicked with the mouse. The file must be in PEM format.
3 The password respectively passphrase is not required.

1KGT151106 V005 1 81
Certificate Revocation List (CRL) Upload Certificate Management

When all steps are finished the CRL can be uploaded by pressing the upload button (see figure
below). The upload button appears not before all required information are set ('Certificate
description').

Figure 61: CRL upload button

The RTU validates the uploaded certificate revocation list. If system time is set on device and CRL
list is outdated red exclamation mark will be displayed.

Figure 62: Outdated CRL

Next step of validation is an issuer certificate check. Following states are applicable for CRL
validation:
• 'valid' if any certificate bundle loaded contain issuer certificate and CRL signed by the issuer,
• 'invalid' no certificate to validate CRL but at least one certificate subject equal to CRL issuer,
• 'uploaded' no certificate to validate CRL.

After a successful CRL upload the certificate management looks like shown in the next figure. The
upper area contains now the information about the uploaded certificates and which one are revoked
by uploaded CRL. If intermediate CA is revoked all subordinates certificates are revoked as well.

Figure 63: CRL file upload successfully finished. One certificate ('CERT') is revoked

Information about revoked certificate is included in system log and Security Archive. For RTU560
with multi CMU or configured in redundant mode CRL is automatically distributed between the
boards.

82 1KGT151106 V005 1
Certificate Management Certificate Revocation List (CRL) Upload

ADVICE
If Certificate Revocation List file was generated by other certificate authority than currently
loaded CRL is needed to remove the previous one before upload the new one (transfer error
appears).

1KGT151106 V005 1 83
Certificate Revocation List (CRL) Upload Certificate Management

84 1KGT151106 V005 1
IEEE 802.1X Port-based Network Access Control Technology Overview

8 IEEE 802.1X Port-based Network

Access Control
8.1 Technology Overview
IEEE 802.1X is a security standard for port-based network access control that secures wired
networks against unauthorized access by requiring authentication with a central server before
network access and data transmission are allowed.

A port is a point of attachment to a network. IEEE 802.1X provides port-based network access
control that allows network access decisions made at the port, on a per-port basis using the EAPOL
(Extensible Authentication Protocol Over LAN). For a wired network, a port could be where the MAC
(Media Access Control) physically attaches to the network, such as a switch port.

The purpose of IEEE 802.1X is authentication of Ethernet network equipment. Equipment that is not
authenticated will not even receive link. Only equipment that is authenticated should get network
access when connected to an Ethernet switch.

There is a client implementation of IEEE 802.1X in RTU500. That means RTU500 provides IEEE
802.1X supplicant role on Ethernet interface E1 and if present on E2 of a CMU module. The
RTU500 sends authentication information in the form of a X.509 certificate or username/password
to the authenticator and requests access to the network.

The supplicant uses EAPOL that uses data link layer (Layer 2) for communication with the
authenticator. The authenticator is the switch in the substation that controls access to the network.
The authenticator forwards authentication requests from the supplicant to the authentication server.
When the authenticator receives an EAPOL packet from the supplicant it packets them in a radius
format and then forwards them to the authentication server. The authentication server checks if the
supplicant should be allowed network access and reports this back to the authenticator.

Before the RTU500 has allowed access the authenticator puts the access port in unauthorized
mode. In this mode only EAPOL traffic is allowed on the port. As soon as the RTU500 has allowed
access the port changes to authorized mode and other traffic is allowed.

8.2 EAP (Extensible Authentication Protocol)

IEEE 802.1X uses EAP to define how messages used for authentication are sent between devices.
EAP is using layer 2 (data link) and can therefore send information without valid IP address.

RTU500 supports the following EAP types:

• EAP-TLS (X.509 certificate-based authentication)

• EAP-PEAPv0 with EAP-MSCHAPv2

EAP-TLS (Transport Layer Security) is an IETF (Internet Engineering Task Force) open standard
that uses the TLS protocol, and is well-supported among vendors. RTU500 EAP complies with the
IETF RFC 5216: The EAP-TLS Authentication Protocol. EAP-TLS is an EAP type that make use
of TLS to perform mutual authentication between the client and server. TLS exploits the properties
of asymmetric cryptography by means of certificate exchange between peers. EAP-TLS requires
that both server-side and client-side certificates are deployed. EAP-TLS uses PKI (Public Key
Infrastructure) to secure communication to a RADIUS (Remote Authentication Dial-In User Service)
authentication server.

1KGT151106 V005 1 85
RTUtil500 configuration IEEE 802.1X Port-based Network Access Control

EAP-PEAPv0 (Protected EAP) uses server-side public key certificates to authenticate the server.
It then creates an encrypted TLS tunnel between the client and the authentication server. The
ensuing exchange of authentication information to authenticate the client is then encrypted and
user credentials are safe from eavesdropping. EAP-MSCHAPv2 (Microsoft-Challenge-Handshake
Authentication Protocol version 2) is tunneled through TLS as inner authentication type for EAP-
PEAPv0.

8.3 RTUtil500 configuration

The configuration parameters for IEEE 802.1X Port-based Network Access Control are defined for
each Ethernet interface within an RTU.

A checkbox "IEEE 802.1X Authentication" is available on Ethernet interface E1 and if present E2

tab of a CMU module to enable the supplicant functionality.

Parameter name Default Parameter location

IEEE 802.1X Authentication disabled CMU - Network Interfaces

If the option is checked,
IEEE 802.1X Port-based Network Access Control will be enabled.

The following parameters are configured in a separate dialog accessible via "Configuration" button.

Parameter name Default Parameter location

EAP Identity CMU - Network Interfaces

The identity sent in response messages to the authenticator.
EAP-TLS disabled CMU - Network Interfaces
If the option is checked,
Extensible Authentication Protocol type Transport Layer Security (TLS) will be enabled.
Certificate-based authentication CMU - Network Interfaces
Select a certificate used for IEEE 802.1X authentication.
List items depend on certificate store configuration, that means prior to that list selection set an entry with descriptive text in the
certificate store of the CMU module to upload external certificates for the IEEE 802.1X authentication.
EAP-PEAPv0 disabled CMU - Network Interfaces
If the option is checked,
Extensible Authentication Protocol type Protected EAP (PEAPv0) will be enabled.
EAP-MSCHAPv2 disabled CMU - Network Interfaces
If the option is checked,
Extensible Authentication Protocol type Microsoft-Challenge-
Handshake Authentication Protocol version 2 (MSCHAPv2) will be enabled.
MSCHAPv2 User ID CMU - Network Interfaces
The user-id used in MSCHAPv2 handshakes.
MSCHAPv2 Password CMU - Network Interfaces
The password used in MSCHAPv2 handshakes.

8.4 Certificate upload via the RTU500 Web server

A digital certificate is used to prove that someone is who they say they are. In an 802.1X
negotiation, the authentication server uses certificates to prove its identity to the supplicant. The
certificates used by the authentication server are called server certificates. The certificates used by
the supplicant are called client certificates. Server certificates are required for EAP-TLS and EAP-
PEAPv0. EAP-TLS requires that the RTU500 prove its identity with a client certificate as well.

86 1KGT151106 V005 1
IEEE 802.1X Port-based Network Access Control Certificate upload via the RTU500 Web server

EAP-TLS requires an uploaded external certificate stored in the certificate store of the CMU
module. The web pages for certificate configuration require secure HTTPS Web server access. It
is not possible to open the web pages with standard HTTP access. For uploading the generated
certificate must be stored in PKCS#12 format.

The upload of an external generated certificate is done via the RTU500 Web server. In the Web
server menu the link 'Certificate Management' is the entry point for the certificate upload. This link
can be found under the menu item 'Management'.

To upload a certificate the following steps have to be executed:

• Select the description of the certificate to upload in the column 'Certificate description'. In the
selection all in RTUtil500 configured entries of the certificate store appear. The selection text is
the descriptive name set in RTUtil500.
• Select a certificate file.
• Enter the private key password by pressing the lock symbol.

When all steps are finished the certificate can be uploaded by pressing the button 'Send file to
device'. This button appears not before all required information are set.

Further information about the upload of external certificates can be found in User Manual RTU500
series Web Server Release 13 (1KGT151108).

1KGT151106 V005 1 87
Certificate upload via the RTU500 Web server IEEE 802.1X Port-based Network Access Control

88 1KGT151106 V005 1
System Hardening

9 System Hardening
Hitachi ABB Power Grids strives to improve the security and robustness of its products by
performing security testing and hardening. RTU500 series has been systematically hardened,
e.g. unused services have been removed and unused ports closed. Furthermore RTU500 series
has been thoroughly tested at Hitachi ABB Power Grids‘s dedicated, independent security test
center using state-of-the-art commercial and open-source security testing tools. Security testing and
hardening are integral parts of the development process.

1KGT151106 V005 1 89
 System Hardening

90 1KGT151106 V005 1
Patch Management General Information

10 Patch Management
10.1 General Information
This chapter describes the patch management for the RTU500 series and how to keep the system
up to date.

Three categories of updates are available for the RTU500 series:

• Patches (cyber security updates)
• Bug fixes (available for the latest minor release)
• Minor/Major releases (new functions)

Most of the cyber security issues can be solved by patches (e.g. OS patches, fixes in protocols).

Partly minor/major release change is required (e.g. new encryption, new OS versions, new cyber
security functions).

Firmware updates and patches are available via the local service partner

10.2 Release Policy

The release policy of the RTU500 series is as follows:
• Patches based on security vulnerability on request.
• Bug fix releases on request (typically every 6-10 weeks).
• Project specific developments are tested as beta version and will be released with the next
minor or major release.
• Two minor/major releases per year with functional improvements.

10.3 Update Policy

The Update Policy of the RTU500 series is as follows:

Patch: Updates in cyber security functions

• No changes in configuration
• Test recommendation in the release note

Bug fix: Error corrections

• No changes in configuration
• Functional test of corrected function is recommended

Minor release:
• New device and for new cyber security functions
• Automatic update of configurations if required
• Functional test of updated/new function is recommended

Major release:
• New device and for new cyber security functions
• Automatic update of configurations
• Functional test of updated/new function is recommended

1KGT151106 V005 1 91
Recommendation by Hitachi ABB Power Grids Patch Management

10.4 Recommendation by Hitachi ABB Power Grids

We recommend to implement cyber security patches as soon as possible.

Information are available at:

• Cyber security alerts and notifications
• Hitachi Power: Internal announced findings and solutions
• hitachiabb-powergrids.com/rtu: Official information for end customers

Bug fixes have to be implemented only if it is relevant for the running system.

Annual minor/major release updates are recommended:

• At least minor release update
• Major release updates shall be considered

10.5 Patch installation

For patch installation please consider following points:

• Login to the RTU with required user rights.

• Download the new firmware version via web server.
• Configuration file stays unchanged.
• Restart the RTU.
• You can find logged installation procedure in the security log.

92 1KGT151106 V005 1
Secure Update Design Principles

11 Secure Update
To prevent unauthorized program code from being executed on RTU500 CMU hardware, secure
update feature is provided by RTU500 series. This feature creates a first border against system
attacks manipulating program code and enabling these in the field. If an attacker does not have
physical access to the device or a high degree of knowledge and computation power, this feature
makes it very hard to execute manipulated program code on RTU500 series.

11.1 Design Principles

CMU firmware files are signed with an asymmetric cryptographic key. The certificate used for
signing is issued by the vendor root certificate of Hitachi ABB Power Grids which´s public key
certificate can be loaded to a CMU by the user to enable secure update. This signature of a CMU
firmware is attached to the file together with the files' SHA256 hash and the public key certificate
derived from the certificate used for signing. Before verification of the signed file, it is checked, if
the attached public key certificate was issued by the vendor root certificate. For this purpose, the
secure update vendor root public key certificate stored on the CMU hardware is used. Finally, the
attached signature is verified using the attached public key certificate.

Uploaded secure update vendor root certificate is stored on the CMU hardware itself and bound to
the hardware of the CMU. Removing or manipulating the stored certificate is detected at start up
and signalized.

Vendor site
Vendor root cerficate

CMU Firmware

Binaries and Resources

issued by

CMU hardware

Aachment
Signing cerficate Signing public key Vendor root public key
cerficate cerficate

verify
verified by issued by

Signature:
XXXX XXXX XXXX XXXX
signed by
: Private key
: Public key
Figure 64: Secure update design

11.2 Enabling and Management

Secure update feature must be enabled individually on each CMU by uploading an appropriate
initialization file containing an X.509 vendor root certificate with a public key provided by Hitachi
ABB Power Grids. The certificate management of RTU500 series Web server supports this upload

1KGT151106 V005 1 93
CMU Firmware Update Secure Update

functionality and shows status and details of the vendor root certificate stored on a CMU. To
perform the upload, the user must be connected to the CMUs local USB interface with HTTPS.
Update from remote via Ethernet interfaces is because of security reasons not supported. During
the upload process of the vendor root certificate, all HTTP/HTTPS connections via other interfaces
than the local USB interface are blocked.

Figure 65: Upload vendor root certificate

Vendor root certificate files to enable secure update are provided by Hitachi ABB Power Grids.
These files are CMU type specific. Only the file for a certain CMU type can be used to enable
secure update.

Figure 66: Certificate uploaded

During the enabling process, security events are logged

ADVICE
Once enabled on a CMU, only signed CMU firmware versions are accepted during upload.

ADVICE
It is not possible to deactivate the 'Secure Update' functionality.

11.3 CMU Firmware Update

CMU firmware files are uploaded to CMUs using RTU500 series Web server 'Firmware
management'. Once secure update feature is enabled on a CMU, only CMU firmware files
generated and signed by Hitachi ABB Power Grids are accepted. CMU firmware files without or
manipulated signatures attached are rejected after upload to the CMU without being executed with
error message 'CMU firmware signature invalid'.

Figure 67: CMU firmware signature invalid

11.4 Vendor Root Certificate Life Cycle

The validity time of the secure update vendor root certificate is 20 years. Within this time span
Hitachi ABB Power Grids uses certificates issued by this certificate to sign generated CMU firmware
versions. Once the secure update vendor root certificate is expired, it will be replaced and the new
vendor root certificate is from this time on used for signing of new CMU firmware versions. Update
to older CMU firmware versions matching to the previous, now expired secure update vendor root
certificate is still possible after expiration.

94 1KGT151106 V005 1
Secure Update Reset to Factory Default

For updating the secure update vendor root public key certificate stored on CMUs, an update file
will be provided by Hitachi ABB Power Grids. This update file can be applied to CMUs in the same
way as described in the enabling process.

11.5 Reset to Factory Default

During the reset to factory defaults, also the vendor root public key certificate stored on the CMU
hardware is reset to its defaults.

1KGT151106 V005 1 95
Reset to Factory Default Secure Update

96 1KGT151106 V005 1
Backup Management

12 Backup Management
The product lines RTU530 and RTU540 support a feature called backup management which offers
backup and restore functionality.

It is possible at any time on a running system to create a full backup of the system. The backup
contains everything required to restore it later: firmware, configuration, archives, license, PLC, HMI,
etc.

The backup is stored on the CMU but also can be transferred to the local PC and archived. It is
possible at any time on a running system to restore a backup in order to get a system of an earlier
point in time.

The Backup file is signed during creation with a CMU specific key. The signature is verified before
restore to increase security.

ADVICE
In case of a hardware fault, it is possible to restore the backup on a spare part CMU as well.

ADVICE
Backup management is a feature of the RTU530 and RTU540 product lines.

1KGT151106 V005 1 97
 Backup Management

98 1KGT151106 V005 1
Decommissioning

13 Decommissioning
When decommissioning an RTU, it should be reset to the factory settings or the memory card
should be safely deleted.

For the RTU, perform following steps to delete the data:

• Decommissioning RTU530:
For RTU530 CMUs a reset to factory default removes all customer specific information. No
further actions are required.
• Decommissioning RTU540 and RTU560:
Removing and deleting memory card is sufficient. Even if some information are stored in
onboard flash memory, these does not contain customer information. Is feature secure firmware
update enabled, a vendor (HAPG) public key certificate is stored in the onboard flash, which
does not contain sensitive information. Self-signed web server certificates are also stored in
onboard flash, but this does only contain IP addresses and a vendor (HAPG) information, so no
sensitive information are included here too.

1KGT151106 V005 1 99
 Decommissioning

100 1KGT151106 V005 1

Compliance Statement IEEE 1686 Electronic Access Control

14 Compliance Statement IEEE 1686

This chapter contains a compliance statement of the RTU500 series security functionality against
IEEE 1686 standard. Considered is the chapter "IED Cyber Security Features".

14.1 Electronic Access Control

IEEE chapter IEEE chapter name Compliance
no
5.1 Electronic Access Control Comply
5.1.1 IED Access Control Overview Comply
5.1.2 Password Defeat Mechanisms Comply
5.1.3 Number of Individual Users Comply
5.1.4 Password construction Comply
5.1.5 IED access control Comply
5.1.5.1 Authorization Levels by Password Comply
5.1.5.2 Authorization using role-based access control (RBAC) Comply
5.1.6 IED main security functions Comply
5.1.6 a) View Data Comply
5.1.6 b) View Configuration Settings Comply
5.1.6 c) Force Values Comply
5.1.6 d) Configuration Change Comply
5.1.6 e) Firmware Change Comply
5.1.6 f) ID/Password Management Comply
5.1.6 g) Audit trail Comply
5.1.7 Password Display Comply
5.1.8 Access Timeout Comply1
Table 10: IEEE 1686 compliance "Electronic access"

1 The access time-out is retriggered with every user action. The time-out is configurable in a
range between 1 minute and 24 hours. The time-out can be disabled by setting to 0.

14.2 Audit Trail

IEEE chapter IEEE chapter name Compliance
no
5.2 Audit Trail Comply
5.2.2 Storage Capability Comply1
5.2.3 Storage Record Comply
5.2.3 a) Event Record Number Comply
5.2.3 b) Time and Date Comply
5.2.3 c) User Identification Comply
5.2.3 d) Event Type Comply
5.2.4 Audit Trail Event Types Comply
Table 11: IEEE 1686 compliance "Audit trail"

1KGT151106 V005 1 101

Supervisory Monitoring and Control Compliance Statement IEEE 1686

IEEE chapter IEEE chapter name Compliance

no
5.2.4 a) Login Comply
5.2.4 b) Manual Logout Comply
5.2.4 c) Timed Logout Comply
5.2.4 d) Value Forcing Comply2
5.2.4 e) Configuration Access Comply
5.2.4 f) Configuration Change Comply
5.2.4 g) Firmware Change Comply
5.2.4 h) ID/Password Creation and Modification Comply
5.2.4 i) ID/Password Deletion Comply
5.2.4 j) Audit-Log Access Comply
5.2.4 k) Time/Date Change Comply3
5.2.4 l) Alarm Incident Exception4
Table 11: IEEE 1686 compliance "Audit trail"

1 The event log with 2048 events is available. Removing the storage media will halt the
device. After reinserting of the storage media, the device must be rebooted but will then
function properly unless the storage media was damaged.
2 Comply if the PLC online debug mode is disabled during normal operation (requires
administrator permission). PLC online debug mode is disabled by default.
3 Comply if the test mode is disabled during normal operation. Test mode is disabled by
default.
4 Not supported.

14.3 Supervisory Monitoring and Control

IEEE chapter IEEE chapter name Compliance
no
5.3 Supervisory Monitoring and Control Comply1
5.3.1 Overview of Supervisory Monitoring and Control Comply1
5.3.2 Events Comply1
5.3.3 Alarms Exception2
5.3.3 a) Unsuccessful Log In Attempt Exception4
5.3.3 b) Reboot Comply
5.3.3 c) Attempted Use of Unauthorized Configuration Software Comply5
5.3.3 d) Invalid configuration or firmware download Exception6
5.3.3 e) Unauthorized configuration or firmware file Exception6
5.3.3 f) Time signal out of tolerance Comply
5.3.3 g) Invalid field hardware changes Comply
5.3.4 Alarm Point Change Detect Comply
5.3.5 Event and Alarm Grouping Exception3
5.3.6 Supervisory Permissive Control Exception3
Table 12: IEEE 1686 compliance "Supervisory monitoring and control"

1 Audit trail events (security events) can be monitored at supervision and control systems
with a Web client.

102 1KGT151106 V005 1

Compliance Statement IEEE 1686 Cyber Security Features

2 Available only for monitoring and control events like control outputs, status changes,
measured values and integrated totals.
3 Not supported.
4 An unsuccessful log in attempt is detected and logged every time a wrong user credential is
given.
5 All configuration and firmware changes are handled in the RTU Web server with
authentication control. The PLC online debug connection is also controlled by the Web
server (access deactivated by default).
6 The download of configuration and firmware is protected by user authentication, but the
configuration or firmware file itself is not checked for validity and authentication.

14.4 Cyber Security Features

IEEE chapter IEEE chapter name Compliance
no
5.4 IED cyber security features Comply
5.4.1 IED functionality compromise Comply
5.4.2 Specific crytographic features Comply
5.4.2 a) Webserver functionality Comply
5.4.2 b) File transfer functionality Comply1
5.4.2 c) Text-oriented terminal connections Not applicable2
5.4.2 d) Full Access Comply
5.4.2 e) Network time synchronization Comply
5.4.2 f) Secure tunnel functionality Comply
5.4.3 Cryptographic techniques Acknowledge
5.4.4 Encrypting serial communications Exception3
5.4.5 Protocol-specific security features Exception4
Table 13: IEEE 1686 compliance "Cyber security features"

1 The file transfer functionality in the RTU is implemented with Hypertext Transfer Protocol
Secure (HTTPS) equal secure as Secure File-Transfer Protocol (SFTP).
2 The RTU doesn't provide any text oriented terminal connection.
3 Not supported.
4 The RTU supports IEC 62351-3 transport layer security for IEC 60870-5-104 and IEC
62351-5 secure authentication for DNP3 LAN/WAN.

14.5 Configuration Software

IEEE chapter IEEE chapter name Compliance
no
5.5 Configuration Software Acknowledge
5.5.1 Authentication Comply1
5.5.2 Digital signature Exception3
5.5.3 ID/Password Control Not applicable2
5.5.4 ID/Password Controlled Features Not applicable2
5.5.4.1 View Configuration Data Not applicable2
Table 14: IEEE 1686 compliance "Configuration software"

1KGT151106 V005 1 103

Communications Port Access Compliance Statement IEEE 1686

IEEE chapter IEEE chapter name Compliance

no
5.5.4.2 Change Configuration Data Not applicable2
5.5.4.2 a) Full Access Not applicable2
5.5.4.2 b) Change tracking Not applicable2
5.5.4.2 c) Use monitoring Not applicable2
5.5.4.2 d) Download to IED Not applicable2
Table 14: IEEE 1686 compliance "Configuration software"

1 All configuration and firmware changes are handled in the RTU Web server with
authentication control. The exception is the PLC online debug connection which is
controlled by the Web server as well.
2 Not required for RTUtil500 because every access is handled via RTU Web server.
3 Not supported.

14.6 Communications Port Access

IEEE chapter IEEE chapter name Compliance
no
5.6 Communications Port Access Comply
Table 15: IEEE 1686 compliance "Communications port access"

14.7 Firmware Quality Control

IEEE chapter IEEE chapter name Compliance
no
5.7 Firmware Quality Control Exception1
Table 16: IEEE 1686 compliance "Firmware quality control"

1 Quality control is handled according to ISO9001

104 1KGT151106 V005 1

Compliance Statement IEC 62443-4-2 FR 1 – Identification and authentication control (IAC)

15 Compliance Statement IEC 62443-4-2

This chapter contains a compliance statement of the RTU500 series security functionality against
the standard IEC 62443-4-2 Security for industrial automation and control systems – Part 4-2:
Technical security requirements for IACS components.

RTU500 series devices are considered as embedded devices, so "13 - Embedded device
requirements" have been selected.

Following requirement selections from the standard are not considered:

• 12 - Software application requirements
• 14 - Host device requirements
• 15 - Network device requirements

15.1 FR 1 – Identification and authentication control

(IAC)
CR Security requirement Security level
CR 1.1 Human user identification and authentication SL-C 2
CR 1.2 Software process and device identification and authentica- SL-C 2
tion
CR 1.3 Account management SL-C 4
CR 1.4 Identifier management SL-C 4
CR 1.5 Authenticator management SL-C 2
CR 1.6 Wireless access management Not applicable for
embedded devices
CR 1.7 Strength of password-based authentication SL-C 2
CR 1.8 Public key infrastructure certificates SL-C 2
CR 1.9 Strength of public key authentication SL-C 2
CR 1.10 Authenticator feedback SL-C 4
CR 1.11 Unsuccessful login attempts SL-C 4
CR 1.12 System use notification Not supported
CR 1.13 Access via untrusted networks Not applicable for
embedded devices
CR 1.14 Strength of symmetric key-based authentication SL-C 2
Table 17: FR 1 – Identification and authentication control (IAC)

15.2 FR 2 - Use control (UC)

CR Security requirement Security level
CR 2.1 Authorization enforcement SL-C 2
CR 2.2 Wireless use control Not applicable
CR 2.3 Use control for portable and mobile devices Not applicable
CR 2.4 Mobile code see "Tab. 24:
Embedded device
Table 18: FR 2 - Use control (UC)

1KGT151106 V005 1 105

FR 3 – System integrity (SI) Compliance Statement IEC 62443-4-2

CR Security requirement Security level

requirements
(EDR)"
CR 2.5 Session lock SL-C 4
CR 2.6 Remote session termination SL-C 4
CR 2.7 Concurrent session control SL-C 4
CR 2.8 Auditable events SL-C 4
CR 2.9 Audit storage capacity SL-C 2
CR 2.10 Response to audit processing failures SL-C 4
CR 2.11 Timestamps SL-C 3
CR 2.12 Non-repudiation SL-C 4
CR 2.13 Use of physical diagnostic and test interfaces see "Tab. 24:
Embedded device
requirements
(EDR)"
Table 18: FR 2 - Use control (UC)

15.3 FR 3 – System integrity (SI)

CR Security requirement Security level
CR 3.1 Communication integrity SL-C 4
CR 3.2 Malicious code protection see "Tab. 24:
Embedded device
requirements
(EDR)"
CR 3.3 Security functionality verification SL-C 3
CR 3.4 Software and information integrity SL-C 1
CR 3.5 Input validation SL-C 4
CR 3.6 Deterministic output SL-C 4
CR 3.7 Error handling SL-C 4
CR 3.8 Session integrity SL-C 1
CR 3.9 Protection of audit information SL-C 3
CR 3.10 Support for updates see "Tab. 24:
Embedded device
requirements
(EDR)"
CR 3.11 Physical tamper resistance and detection see "Tab. 24:
Embedded device
requirements
(EDR)"
CR 3.12 Provisioning product supplier roots of trust see "Tab. 24:
Embedded device
requirements
(EDR)"
CR 3.13 Provisioning asset owner roots of trust see "Tab. 24:
Embedded device
requirements
(EDR)"
Table 19: FR 3 – System integrity (SI)

106 1KGT151106 V005 1

Compliance Statement IEC 62443-4-2 FR 4 – Data confidentiality (DC)

CR Security requirement Security level

CR 3.14 Integrity of the boot process see "Tab. 24:
Embedded device
requirements
(EDR)"
Table 19: FR 3 – System integrity (SI)

15.4 FR 4 – Data confidentiality (DC)

CR Security requirement Security level
CR 4.1 Information confidentiality SL-C 4
CR 4.2 Information persistence SL-C 2
CR 4.3 Use of cryptography SL-C 4
Table 20: FR 4 – Data confidentiality (DC)

15.5 FR 5 – Restricted data flow (RDF)

CR Security requirement Security level
CR 5.1 Network segmentation SL-C 4
CR 5.2 Zone boundary protection Not applicable for
embedded devices
CR 5.3 General purpose person-to-person communication restric- Not applicable for
tions embedded devices
CR 5.4 Application partitioning not required by the
standard
Table 21: FR 5 – Restricted data flow (RDF)

15.6 FR 6 – Timely response to events (TRE)

CR Security requirement Security level
CR 6.1 Audit log accessibility SL-C 4
CR 6.2 Continuous monitoring SL-C 4
Table 22: FR 6 – Timely response to events (TRE)

15.7 FR 7 – Resource availability (RA)

CR Security requirement Security level
CR 7.1 Denial of service protection SL-C 4
CR 7.2 Resource management SL-C 4
CR 7.3 Control system backup SL-C 4
CR 7.4 Control system recovery and reconstitution SL-C 4
CR 7.5 Emergency power Not applicable
CR 7.6 Network and security configuration settings SL-C 2
Table 23: FR 7 – Resource availability (RA)

1KGT151106 V005 1 107

Embedded device requirements (EDR) Compliance Statement IEC 62443-4-2

CR Security requirement Security level

CR 7.7 Least functionality SL-C 4
CR 7.8 Control system component inventory Not applicable
Table 23: FR 7 – Resource availability (RA)

15.8 Embedded device requirements (EDR)

EDR Security requirement Security level
EDR 2.4 Mobile code Not applicable
EDR 2.13 Use of physical diagnostic and test interfaces SL-C 4
EDR 3.2 Malicious code protection SL-C 4
EDR 3.10 Support for updates SL-C 4
EDR 3.11 Physical tamper resistance and detection SL-C 1
EDR 3.12 Provisioning product supplier roots of trust SL-C 1
EDR 3.13 Provisioning asset owner roots of trust SL-C 1
EDR 3.14 Integrity of the boot process Not supported
Table 24: Embedded device requirements (EDR)

108 1KGT151106 V005 1

Appendix A A.1 Export CAM Server Public Key Certificate on Windows

16 Appendix A
16.1 A.1 Export CAM Server Public Key Certificate on
Windows
To export the public key certificate of a CAM server running on Windows the Microsoft Management
Console can be used. To start the console click on the Start menu and search for 'mmc'. Then
execute the appearing program 'mmc.exe' to start the management console. In the console window
(shown below) select the File menu and click 'Add/Remove Snap-in...'.

In the dialog 'Add or Remove Snap-ins' select 'Certificates' from the available snap-ins. The click
'Add >' to start the certificate snap-in wizard dialog.

1KGT151106 V005 1 109

A.1 Export CAM Server Public Key Certificate on Windows Appendix A

At first select for the certificates to manage by the snap-in the 'Computer account' as shown in the
next figure.

As computer for the certificate snap-in select the 'Local computer (the computer this console is
running on)'. Then press 'Finish' in the wizard and 'Ok' in the dialog 'Add or Remove Snap-ins'.

110 1KGT151106 V005 1

Appendix A A.1 Export CAM Server Public Key Certificate on Windows

Now the management console shows the different certificate stores on the local computer. The
certificate of the CAM server should be found in the Personal store (see next figure).

Select the CAM server certificate and start the export wizard in the Action menu, then 'All Tasks >'
and finally 'Export...'. The Certificate Export Wizard starts with a welcome dialog that are skipped
by clicking 'Next'. In the following dialog choose to not export the private key (see figure below).
Depending on the server certificate it may be possible to export the private key, but this is not
required. Continue with the next wizard step by clicking 'Next'.

1KGT151106 V005 1 111

A.1 Export CAM Server Public Key Certificate on Windows Appendix A

In the next wizard step select the export format 'Cryptographic Message Syntax Standard –
PKCS#7 Certificates (.P7B)'. The certification path must be exported. So, make sure to set the
according check box as shown below. Continue with the next wizard step by clicking 'Next'.

112 1KGT151106 V005 1

Appendix A A.1 Export CAM Server Public Key Certificate on Windows

In the following wizard step define the name of the file to export. Be sure that the extension of the
export file is '*.p7b' (see next figure). Then continue with the next wizard step by clicking 'Next'.

1KGT151106 V005 1 113

A.1 Export CAM Server Public Key Certificate on Windows Appendix A

In the final step of the export wizard an overview about the specified parameter are shown (see
below). Check the configuration for correctness and press the button 'Finish' to start the certificate
export. If successful the resulting file containing the CAM server public key certificate, can be
uploaded to the RTU500 series.

114 1KGT151106 V005 1

Appendix A A.1 Export CAM Server Public Key Certificate on Windows

1KGT151106 V005 1 115

A.1 Export CAM Server Public Key Certificate on Windows Appendix A

116 1KGT151106 V005 1

Glossary

17 Glossary
AES Advanced Encryption Standard

BCI Bidirectional Communication Interface

CA Certificate Authority

CAM Central User Account Management

CF Compact Flash

CMU Communication and Data Processing Unit

CRL Certificate Revocation List

DES Data Encryption Standard

DH Diffie–Hellman key exchange

DNS Domain Name System

HCI Host Communication Interface

HMI Human Maschine Interface (here Integrated HMI function of the

RTU500 series)

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

IEC International Electrotechnical Commission

IED Intelligent Electronic Device

IEEE Institute of Electrical and Electronics Engineers

IKE Internet Key Exchange

LAM Local User Account Management

LDAP Lightweight Directory Access Protocol

NCC Network Control Center

NIST National Institute of Standards and Technology

PC Personal Computer

PEM Privacy Enhanced Mail

PLC Programmable Logic Control

PPP Point to Point Protocol

RADIUS Remote Authentication Dial-In User Service

RFC Request for Comments

RSA Rivest–Shamir–Adleman

RTU Remote Terminal Unit

SCADA Supervision, Control and Data Acquisition

1KGT151106 V005 1 117

 Glossary

SHA Secure Hash Algorithms

SNMP Simple Network Management Protocol

SNTP Simple Network Time Protocol (according to RFC 4330)

TCP/IP Transmission Control Protocol / Internet Protocol

UAM User Account Management

UDP User Datagram Protocol

USB Universal Serial Bus

VPN Virtual Private Network

118 1KGT151106 V005 1

1KGT151106 V005 1 119
 Note:

The specifications, data, design or other information contained in this document (the “Brochure”)
- together: the “Information” - shall only be for information purposes and shall in no respect be
binding. The Brochure does not claim to be exhaustive. Technical data in the Information are only
approximate figures. We reserve the right at any time to make technical changes or modify the
contents of this document without prior notice. The user shall be solely responsible for the use of
any application example or information described within this document. The described examples
and solutions are examples only and do not represent any comprehensive or complete solution.
The user shall determine at its sole discretion, or as the case may be, customize, program or add
value to the Hitachi ABB Power Grids products including software by creating solutions for the
end customer and to assess whether and to what extent the products are suitable and need to be
adjusted or customized.

This product is designed to be connected to and to communicate information and data via a network
interface. It is the users sole responsibility to provide and continuously ensure a secure connection
between the product and users or end customers network or any other network (as the case may
be). The user shall establish and maintain any appropriate measures (such as but not limited to the
installation of firewalls, application of authentication measures, encryption of data, installation of
anti-virus programs, etc) to protect the product, the network, its system and the interface against
any kind of security breaches, unauthorized access, interference, intrusion, leakage and/or theft of
data or information. Hitachi ABB Power Grids is not liable for any damages and/or losses related
to such security breaches, any unauthorized access, interference, intrusion, leakage and/or theft of
data or information.

Hitachi ABB Power Grids shall be under no warranty whatsoever whether express or implied and
assumes no responsibility for the information contained in this document or for any errors that
may appear in this document. Hitachi ABB Power Grids's liability under or in connection with this
Brochure or the files included within the Brochure, irrespective of the legal ground towards any
person or entity, to which the Brochure has been made available, in view of any damages including
costs or losses shall be excluded. In particular Hitachi ABB Power Grids shall in no event be liable
for any indirect, consequential or special damages, such as – but not limited to – loss of profit,
loss of production, loss of revenue, loss of data, loss of use, loss of earnings, cost of capital or
cost connected with an interruption of business or operation, third party claims. The exclusion of
liability shall not apply in the case of intention or gross negligence. The present declaration shall
be governed by and construed in accordance with the laws of Switzerland under exclusion of its
conflict of laws rules and of the Vienna Convention on the International Sale of Goods (CISG).

Hitachi ABB Power Grids reserves all rights in particular copyrights and other intellectual property
rights. Any reproduction, disclosure to third parties or utilization of its contents - in whole or in part -
is not permitted without the prior written consent of Hitachi ABB Power Grids.

ABB is a registered trademark of ABB Asea Brown Boveri Ltd.

Manufactured by/for a Hitachi Power Grids company.

© 2022 Hitachi Energy.

All rights reserved.

120 1KGT151106 V005 1

1KGT151106 V005 1 121
Visit us

Hitachi Energy Germany AG

P.O. Box 42 01 30
68280 Mannheim, Germany

hitachienergy.com/rtu

1KGT151106 V005 1