WHITEPAPER SECURITY CONCEPT FOR SICK REMOTE SERVICE. Lifetime Services, SICK AG in Waldkirch / Germany. Introduction Protocols Used...

Transcription

1 WHITEPAPER SECURITY CONCEPT FOR SICK REMOTE SERVICE L i f e T i m e S er v i c es, EDITOR: TA B L E O F C O N T E N T S Lifetime Services, SICK AG in Waldkirch / Germany Introduction Protocols Used HTTPS SSH User Authentication Connection Topology Machine PCs Meeting Point Router mpr Service Technicians Potential Attack Scenarios Attacks on the Connection Technology Attacks on the Application Risk Assessment Conclusion

2 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

3 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

4 Customer Production Control Station / SPS Meeting Point Server Database administration of forwarded ports, adaptable via web application Service Advantages SSH authentication by dynamic one pass keys Forwarded ports via the Gateway-PC Controller with SPS- and CAN- Bus control Port 22 (SSH) Port 443 (HTTPS) Reverse connection via SSH tunnel Port 22 (SSH) Port 443 (HTTPS) Connection via SSH tunnel 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 Service- Technician 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

5 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

6 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

7 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

8 / DIV03 ( ) WB USmod int37 REFERENCES Package of measures for secure Remote Services of the BSI (German Federal Office for Information Security) (M5.33) SICK AG Waldkirch Germany