Transport Layer Security (TLS)

Transport Layer Security (TLS) is a cryptographic protocol that is designed to provide communications security over a reliable computer network (such as TCP).

The TLS protocol aims primarily to provide security, including privacy (confidentiality), integrity, and authenticity through the use of cryptography. This includes the use of certificates during the communications establishment phase to initiate a secure connection between two or more communicating devices. Each end then encrypts the information in an agreed format that the other end is able to decrypt.

The closely related Datagram Transport Layer Security (DTLS) is a communications protocol that provides security to datagram-based communications (such as UDP). In the Geo SCADA Expert documentation, references to 'TLS' often apply to both protocols.

TLS builds on the now deprecated Secure Sockets Layer (SSL) security protocol.

In Geo SCADA Expert, advanced drivers can use TLS to provide secure network communication to various outstations, devices, and applications. The drivers can only use TLS when all of the outstations, devices, and applications at the other end of the connection also support, and are configured to use, TLS.

With TLS, each network connection is between a TLS client at one end and a TLS server at the other end:

  • TLS clients initiate TCP connections (or send the first datagram for DTLS).

  • TLS servers listen for and accept TCP connections (or receive the first datagram for DTLS).

TLS provides security in the form of:

  • Encryption—This protects against unintentional information disclosure by providing data confidentiality and protection against evesdropping.

  • Integrity—This provides confidence that the data that is received is the actual valid data from the sender, and has not been tampered with or manipulated.

  • Authentication (optional, but strongly recommended for SCADA)—This validates the identity of the other party before communications commence between Geo SCADA Expert and the other device or application. This helps to protect against impersonation, for example, whereby malicious actors attempt to impersonate the server to control an outstation's output points and therefore the plant that it is controlling. Authentication is therefore very important in SCADA, with a lack of authentication typically being a much higher risk than lack of encryption.

    With TLS, each network connection is between a TLS client at one end and a TLS server at the other end (see above). The TLS client can authenticate the TLS server. Additionally, or alternatively, the TLS server can authenticate the TLS client. So, for example, Geo SCADA Expert can authenticate an outstation to ensure that any data that it receives is from the genuine outstation. Likewise, an outstation can authenticate Geo SCADA Expert to ensure that any commands, controls, or configuration changes that it receives are from the genuine server. You can apply authentication at the TLS client, at the TLS server, at neither, or at both. We strongly recommend that you apply authentication at both ends; this is known as 'mutual authentication'.

IEC 62351-3 defines standards for using TLS in SCADA. We strongly recommend that you configure your systems to be compliant with these standards; this includes using mutual authentication in addition to encryption.

TLS Support for Advanced Drivers in Geo SCADA Expert

The advanced drivers in Geo SCADA Expert use one of several implementations of the TLS and DTLS protocols:

  • Microsoft Secure Channel (known as Schannel), which is part of the Windows operating system.

  • OpenSSL which is an open source library (see https://www.openssl.org/)

Geo SCADA Expert supports the following TLS implementations:

Certificates and Keys

If you choose to use TLS to provide a secure connection, you will need a set of certificates and private keys for Geo SCADA Expert and for the device or application at the other end of the connection (see What Certificates do I Require?).

The recommended approach is to use your organization’s private certificate authority (CA) to issue the certificates. Alternatively, you might choose to use self-signed certificates.

The certificates and private keys are stored in files. There are several different file types, some of which are encrypted. The certificate and private key file types that are supported vary per driver, device, and application (see Which SSL Certificate File Types does my Driver Support?). The certificates and private key for the Geo SCADA Expert driver, outstation, device, or application at each end of the TLS connection are independent of each other. Each Geo SCADA Expert driver, outstation, device, or application has its own files for the certificate and private key. So, for example, you might use an encrypted private key for the Geo SCADA Expert server at one end and an unencrypted private key for the device at the other end of the connection.

WARNING

POTENTIAL security BREACH

You MUST ensure that private keys are kept and transferred securely. Failure to do so could compromise the security of your system; potentially, it could lead to unauthorized access to your system.
Failure to follow these instructions can result in death, serious injury, or equipment damage. The breach in system security could leave the database vulnerable to unauthorized and potentially malicious use.

When there is a choice, we recommend that you use encrypted PFX files, or encrypted private keys, as this provides an additional layer of protection. If you choose PFX, it also has the convenience of the certificates and private key being stored together in a single file.

You import and store the certificates and private keys in SSL Certificate and Key and SSL Certificate database items. You use an SSL Certificate and Key database item to store the certificates and private key for the Geo SCADA Expert end of the network connection. You use an SSL Certificate database item to store the trusted certificates for authenticating the device or application at the other end of the network connection. For more information, see Use SSL Certificates for Driver Communications.