WHITEPAPER
SECURITY CONCEPT FOR SICK REMOTE SERVICE
L i f e T i m e S er v i c es , 2 0 1 3 - 0 3
EDITOR:
TA B L E O F C O N T E N T S
Lifetime Services,
SICK AG in Waldkirch / Germany
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Protocols Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
User Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Connection Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Machine PCs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Meeting Point Router mpr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Service Technicians . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Potential Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Attacks on the Connection Technology . . . . . . . . . . . . . . . . . . . . . . . . 6
Attacks on the Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Risk Assessment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
SECURITY CONCEPT FOR SICK REMOTE SERVICE
Introduction
The SICK Meeting Point architecture was designed with the goal of ensuring maximum security while keeping operating complexity
to a minimum. The architecture is aligned with the recommendations and the catalog of measures provided by the BSI (German
Federal Office for Information Security) for securing remote maintenance (M5.33).
These include:
•• Always initiating remote maintenance access only from the local IT system
•• Adequately logging the performance of the remote maintenance
•• Adhering to the dual-control principle (no remote maintenance without customer approval)
The following sections describe how these specifications have been incorporated technically into the Meeting Point architecture
and provide detailed information for ensuring secure remote maintenance.
Protocols Used
Two communications channels are used in the Meeting Point architecture (MPA):
•• HTTPS (port 443)
•• SSH (port 22)
HTTPS
HTTPS is generally used for encrypted communication between browsers and Web servers in applications such as online banking,
in various purchasing portals, and in many portals that store personal data. In such applications, the Web server uses an x.509
certificate that provides the user with the assurance of being connected to the desired server. In addition, the name under which
the server can be accessed in the Internet is stored in the certificate, and this information is signed by a certification authority (CA).
A browser provides a list of trusted CAs which are expected to sign only if the information for the server name is correct. However,
past experience has shown that this cannot always be ensured. For example, gaps in the Web portals used by the CAs for managing certificates may allow any server names to be stored in a certificate, or normally functioning CAs listed in the browsers may
write almost any desired server name into a certificate without conducting thorough checks.
An mpa server therefore uses its own CA, which means that the server is able to issue its own certificates. This makes it possible to
provide the Web server with a certificate and also for individual users to obtain an x.509 certificate, thus allowing them to identify
themselves to the Web server in a secure manner. These user certificates are installed in the customer browser, which presents
them every time the mpa server is visited. By in turn securing the certificate store in the browser with a password, two-factor
authentication is achieved, since the certificate and the password are required to log on to the server. User certificates provide a
convenient and secure way to authenticate users, especially on computers that are used for machine control and on which several
employees frequently work in alternation. When using a browser, if an HTTPS Web server is activated that produces a certificate
that is not signed by one of the stored trusted CAs, warning messages are generally issued. Once the CA certificate of the mpa
system has been added to the list of trusted CAs, the browser henceforth accepts the server certificate like all other certificates of
preinstalled CAs. In principle, accepting certificates is a matter of trust. Due to the fact that many certificates are preinstalled in the
browser, meaning that the chain of trust from the CA operator via the browser vendor and the software distribution is not transparent, as well as the potential for manipulation after installation, it is recommended to delete the supplied list of trusted CA certificates. By adding certification authorities to the CA list individually, only those that are actually required for the pages activated by
the user are trusted.
2
W H I T E PA P E R | S I C K
Further Information about the Security Concept on www.sick.com/Service & Support.
LifeTime Services, 2013-03
Subject to change without prior notice. Errors and omissions excepted.
SECURITY CONCEPT FOR SICK REMOTE SERVICE
Experience gleaned from cases such as DigiTrust has shown that it is possible to compromise officially listed certification authorities and thus to issue any desired certificates, which makes it much easier to launch “man-in-the-middle” attacks. Adding CAs
individually to the list of trusted CAs substantially reduces the risk of successful attacks of this kind. With current browsers, HTTPS
uses the AES encryption algorithm with a 256-bit key length. The mpa server uses the popular Apache Web server as a communication endpoint. The OpenSSL libraries are used for encryption.
SSH
Secure Shell (SSH) is a popular protocol for ensuring access to Unix servers via the network. The OpenSSH implementation that
is used on the server side is based on the development environment of OpenBSD, a Unix derivative devised with security in mind,
which is used in many hardware firewalls. In addition to OpenSSH, Plink from the Putty package is also used in the Meeting Point
architecture on Windows systems. In addition to authentication with user names and passwords, the SSH protocol also allows the
use of public keys, which are exchanged in advance and presented to the server when establishing a connection, as well as others,
such as Kerberos. The mpa server uses only public key authentication. The use of user names/passwords is deactivated to prevent
automated programs on the Internet from testing them automatically and possibly encountering a weak password. Before the SSH
connection is established, the public keys are dynamically generated by the system and exchanged via HTTPS. The validity of a
key pair generated in this way is limited to a maximum of 10 minutes. After authentication, a session key is generated in the SSH
protocol, which is used for further data exchange and is periodically changed. Encryption is implemented via AES with a key length
of 128 bits.
User Authentication
User authentication can be performed via client-side x.509 certificates, which can be stored in the browser. This procedure causes
a random session cookie to be passed to the user, which is subsequently used to identify the user. This cookie is exchanged at regular intervals so that there is only a limited time window in which to exploit the obtained information in the event of a “man-in-themiddle” attack. In order to defend against brute-force attacks on user name/password combinations, accounts are automatically
blocked after five unsuccessful attempts and must be reactivated by an administrator. Unsuccessful attempts are logged in the
system independently of the application and can be analyzed by the system administrator.
Connection Topology
mpa uses a star connection topology, meaning that all connections are established via the central MPA server. Only this server provides the above-mentioned HTTPS and SSH services on the Internet. All other components utilize them and thus use only outgoing
connections. In particular, there are no direct connections between service technicians and machines. Events involving changes in
authorizations, such as the loss of laptops or changes in employees, or detected security gaps, can be handled centrally. With this
architecture, it is no longer necessary to perform administrative actions on client devices.
3
W H I T E PA P E R | S I C K
Further Information about the Security Concept on www.sick.com/Service & Support.
LifeTime Services, 2013-03
Subject to change without prior notice. Errors and omissions excepted.
SECURITY CONCEPT FOR SICK REMOTE SERVICE
Customer
Database administration of
forwarded ports, adaptable
via web application
Production Control Station / SPS
d
de the
ar
rw via C
Fo rts ay-P
po tew
Ga
)
SH
Controller with
SPS- and CANBus control
Advantages
Meeting Point Server
S)
S
P
n
2 ( (HTT
tio
rt 2
ec
Po t 443 onn
c
r
o
e
P
rs
ve
Re
SH
S
via
Port 22 (SSH)
Port 443 (HTTPS)
Connection via
SSH tunnel
el
n
tun
Service
SSH authentication by dynamic
one pass keys
HTTPS authentication via x509
certificates
DB based administration
Minimal requirements for router
and firewall
Gateway-PC
or
Meeting Point Router
(MPR)
Internet
Port 22 (SSH)
Port 443 (HTTPS)
Connection via
SSH tunnel
ServiceTechnician
Meeting-Point architecture
Machine PCs
The “machine account” account type is provided for control PCs that are used on machines as operator terminals for mpa. This
account type provides access to exactly one machine file and allows the establishment of a remote connection.
The SSH connection configuration generated in the mpa server allows only SSH reverse tunnels for machine accounts. Thus, resources can be activated on the machine computer, but not in the opposite direction.
Meeting Point Router mpr
The mpr is based on a simple industrial PC that is equipped with two network interfaces and is used for separating the machine
network and the customer network. An integrated packet firewall specifically activates only the required communications channels
between the customer network and the machine network, as well as from the machine network to the Internet. Here as well, only
outgoing connections via HTTPS and SSH are used for remote access via the mpa server. During the rollout of the mpr, a unique
identifier is stored on the system for authentication, which is transmitted during MPR activation. This identifier replaces the use of
user names and passwords for the MPR and must therefore be kept secret. However, if an MPR identifier is stolen from the MPR,
it can be used to gain access to the MPR-specific pages of the mpa server. These pages allow establishing a remote connection
which, however, can comprise only reverse ports (ensured by server-side limitation), so that a potential attacker would only be able
to make its own resources accessible, but particularly cannot gain access to resources of other MPR devices that are currently
connected.
4
W H I T E PA P E R | S I C K
Further Information about the Security Concept on www.sick.com/Service & Support.
LifeTime Services, 2013-03
Subject to change without prior notice. Errors and omissions excepted.
SECURITY CONCEPT FOR SICK REMOTE SERVICE
Meeting Point Router: Security through separation of Machine Network and Customer Network.
In addition to the normal ports that are forwarded via SSH, the mpr also provides the option of establishing a full VPN connection
between the service technician and the machine network as required. To do this, a network link is also established on Layer 2 via
an SSH tunnel of a remote connection using OpenVPN, so that the service technician can, for example, use broadcast-based or
UDP-based services. The OpenVPN option can be used only via an existing SSH remote connection, so that the authentication and
encryption of the VPN connection does not constitute a new point of attack.
5
W H I T E PA P E R | S I C K
Further Information about the Security Concept on www.sick.com/Service & Support.
LifeTime Services, 2013-03
Subject to change without prior notice. Errors and omissions excepted.
SECURITY CONCEPT FOR SICK REMOTE SERVICE
Service Technicians
Service technicians have access to all machine files and can connect to all machines currently connected via a remote connection.
A connection made by a service technician is always logged in the machine file as information. The server-side generation of the
SSH configuration allows only forward tunnels in this case. Thus, a service technician can activate services on the customer side,
but not in the other direction. The limitation of port forwarding to the ports provided for the machine takes place in two stages.
First, these ports are provided to the SSH client configuration. Parallel to this, a list of allowed ports is stored on the mpa server on
the server side for the relevant SSH key, which is checked by the SSH server when establishing a connection.
Potential Attack Scenarios
The limitation to exactly two connection mechanisms also limits the possibility of attacking them from the outside.
Since only the mpa server is active for connections to these ports, the necessity of making regular security updates is largely limited to this server.
Attacks on the Connection Technology
SSH is operated in a configuration having maximum security (access possible only for the required users, exclusively via public
key authentication, no root access, only SSH2 protocol), which is used in this way throughout the world in many forms to provide
remote administrative access. Successful attacks on servers configured in this way are unknown.
In addition, we use key pairs that are dynamically generated and only time-limited, so that even brute-force attacks on the keys
are not likely to succeed. The HTTPS server provides end-to-end encryption between the browser and Web server, which cannot be
compromised by conventional means. Nonetheless, as with any HTTPS communication, the potential exists for compromising the
communication between the browser and server using a “man-in-the-middle” attack. However, the manipulations required to do
this always necessitate tampering with the basic IT infrastructure such as the DNS server or the proxy infrastructure. In addition,
when carrying out such an attack, either the list of trusted certification bodies in the browser or a trusted certification body must
be directly manipulated. In any event, in the interest of IT security within the company, this should be prevented administratively.
However, some companies exploit this opportunity supposedly in the interest of their own IT security (which is relatively easy since
all above-mentioned components can be influenced by their own IT) in order to investigate HTTPS-encrypted data exchange with
malware. Although this is well-intended, it effectively breaches the concept of end-to-end encryption and thus undercuts the trust
of users, who assume that HTTPS provides secure communication.
Attacks on the Application
In addition to attacks on the connection technology, there is also the potential for attacks on the Web application itself. The
software components and the implementation of the Web application on the mpa server should be well maintained and regularly
checked for known security gaps. By forming a service level agreement, you can ensure that you will receive a rapid and professional response to such an event. The internal security architecture of the Web application strictly separates the individual areas from
each other. Areas that grant user-dependent access to user data are protected by gatekeepers that first check that the passed
parameters are valid within the context of the user when calling a corresponding path. These include machine files, documents,
and connections, among others.
6
W H I T E PA P E R | S I C K
Further Information about the Security Concept on www.sick.com/Service & Support.
LifeTime Services, 2013-03
Subject to change without prior notice. Errors and omissions excepted.
SECURITY CONCEPT FOR SICK REMOTE SERVICE
Risk Assessment
The centralized structure of the Meeting Point architecture concentrates the potential for attacks on one server and the connections to it. Compared to widely deployed remote VPN or dial-in architectures, it is possible to react quickly from a central location to
events such as lost laptops and to block user access. In particular, by avoiding direct communication between service technicians
and customers as well the associated required distribution of access data to the service technicians, potential attack scenarios
can be substantially reduced.
The above-mentioned potential for attacks on the HTTPS connections would make it possible to display manipulated pages to the
user or to gain access to entered information. However, it is not possible to deceive the server about one’s own identity and thereby
gain access to information that is not intended for the user.
The procedure for blocking user accounts after five failed attempts creates the potential for a denial-of-service attack that attempts
to block as many accounts as possible. In this case, the administrator must reactivate these accounts and should take additional
measures (such as setting up firewall barriers to the source of the attack) if they occur frequently.
Conclusion
The remaining risks are manageable. The potential attack scenarios are concentrated on a few points that can be monitored well
due to the centralized structure. Comprehensive system logging can be used to ensure that attacks are logged and do not go unnoticed during the regular system reviews that take place under the service level agreement.
7
W H I T E PA P E R | S I C K
Further Information about the Security Concept on www.sick.com/Service & Support.
LifeTime Services, 2013-03
Subject to change without prior notice. Errors and omissions excepted.
8016208/2013-03 ∙ DIV03 (15.04.13) ∙ WB USmod int37
SECURITY CONCEPT FOR SICK REMOTE SERVICE
REFERENCES
Package of measures for secure Remote Services of the BSI (German Federal Office for Information Security) (M5.33)
SICK AG |Waldkirch|Germany| www.sick.com