Four recommendations for a secure Topkapi SCADA architecture

Cyber threats pose a major risk to industrial information systems (IS). SCADA systems, which monitor industrial equipment, are naturally affected as an integral part of the industrial IS. Security is therefore a key factor to be taken into account when designing a SCADA architecture.
For several years now, AREAL has placed cybersecurity at the heart of its priorities. This commitment is reflected in the enhancements introduced across the various versions of Topkapi. These are based on the latest recommendations from ANSSI*.
What specific measures can be taken to secure a Topkapi SCADA architecture? We asked this question to Julien BENNET, the manager of security-related projects for Topkapi, who sets out below four recommendations and the risks they help to mitigate.

1. Physically protect the heart of the system

If someone can physically access a machine (server, PC), software security measures alone are not sufficient. The Topkapi server is the heart of the SCADA system. It must therefore be installed in a secure room with access control, for example in a computer room with controlled access or in a data center. Physical protection is a fundamental level of security for a secure SCADA architecture.

2. Secure access to the SCADA application 

 Access to the SCADA application must be secure, whether it is accessed from within or outside the industrial IS. 

a. Connections from the Industrial IS

Firstly, the Topkapi application must not be run directly on the machine hosting it, but via a fat client (Netview or Open Client) or a light client (RDP or Webserv). To be noted: client/server communications are natively encrypted.
To enhance this protection, access to the Topkapi server can be routed via an intermediate access point known as a bounce server. On this server is installed the following:

• Either a Netview fat client accessible via RDP.
• Or a Webserv server accessible via a web browser.

In the architecture recommended by AREAL, this intermediate access server is located in a DMZ (demilitarised zone) between the clients and the Topkapi SCADA server. Firewalls are used to control communications on either side of this zone. Should the bounce server be compromised, this segmentation reduces the potential for access to the core of the system.

b. Connections from outside the Industrial IS

For remote connections, the use of a VPN (Virtual Private Network) is an essential security measure:

• It prevents the IP address of the SCADA access server from being directly exposed on the internet.
• The potential for attacks is limited by restricting access to the SCADA system to authorised personnel.
• Data confidentiality is guaranteed through encryption.

To take this a step further, a PAM (Privileged Access Management) solution known as Bastion enables very granular management of access rights per user to the industrial IS and, consequently, to the SCADA application. PAM also ensures the traceability of access: who logged in, when, and what actions were carried out. This solution is strongly recommended when an integrator or service provider works remotely on the configuration of a Topkapi application.

3. Separate functions to enhance security

A SCADA system is based on three main functions: data acquisition, data exploitation and application configuration. To secure the SCADA architecture, each function must have a suitable environment and access method:

• Data acquisition and processing: carried out by a Topkapi server installed on a dedicated machine.
• Data exploitation: carried out via a fat or light client, possibly via a bounce server.
• Configuration: carried out from a workstation dedicated to this purpose within the industrial IS and possibly accessible remotely in a secure manner as outlined previously (VPN or Bastion + RDP).

The aim? To ensure there is no interaction between these three functions: a breach of one must not allow the others to be compromised.

4. Protect communications with equipment

Unsecured communications expose the data stream to risks of interception, disruption or tampering. An attacker could, for example:

• Intercept information as it passes through.
• Alter data sent from the equipment to the SCADA system.
• Send a command in place of the SCADA system.

The use of secure protocols helps to protect the confidentiality, availability and integrity of data exchanged with the SCADA system. Many secure communication protocols are compatible with Topkapi, such as OPC UA and SOFREL LACBUS (read our article on this subject).

 
* French National Agency for Information Systems Security
 

Request the diagram of the secure SCADA architecture based on Topkapi >>