This page describes how a CDP system should be isolated from a Wide Area Network, such as the Internet, to reduce risks related to unauthorized access and viruses. For even better protection against cybersecurity breaches, we highly recommend that systems are set up according to ISO/IEC 62443, as outlined in the CyberSecurity Requirements. We also recommend that the company operates according to accepted international standards, such as ISO/IEC 27001.

Network Intrusion

The key element when it comes to how secure a system is is that any given system is only as secure as its weakest link. Should an intruder gain access to a network in the first place, the precautions one can take within that network preventing the intruder to do malevolent actions are limited.

Setting up a network doesn't relate much to whether there is a CDP based control system running on that network, or something else. The precautions that must be taken and the barriers that should be in place to prevent intruders from gaining access to the network are the same regardless of what the network is used for.

To be able to compromise a system, an intruder needs to gain access to it by breaching the network's barriers. Access can be gained through open connections into the system, or physical access to the system on-site. By increasing the number of barriers that need to be broken, the risk of a breach can be reduced. Routines for physical access to the network must be enforced by the system owner.

CDP based control systems run as applications on Linux or Microsoft Windows operating systems. If an intruder gains access to the operating system on the processing controller through the network, an intruder might be able to influence the control system, just as he would be able to influence any other applications running on the operating system.

Barriers and Network Advisories

CDP control systems control business-critical and safety-critical operations. As a result of that we have assembled an advisory list of recommended practices for networks running CDP control systems.

The Network and its Interfaces

The most important barriers against unauthorized access are the network interfaces.

1. A CDP control system should run on an isolated Local Area Network (LAN), with dedicated controllers and network switches. We recommend using Industrial PCs (IPC) and industrial network switches. These units should be physically located inside a key-locked controller cabinet, and all units should be password protected through their operating systems.
2. The usernames and passwords to access the units in the network should be unique for each unit and not easily deducible. The usernames and password credentials should be stored in a separate location that is considered safe from unlawful access. Removing standard root access passwords, e.g. username:root, password:root, should be enforced.
3. The Operating System should be set up to restrict successive failed logins so that when a number of logins have failed, there will be a lockout time for that user.
4. Non-standard port numbers should be used for standard network services if possible, to lower the risk of someone stumbling upon a connection to the system.
5. Connections to other external systems should go through a rate-controlled dedicated connection on a dedicated network switch. Rate-controlled means that there are configurable limits allowing the system to recognize if the amount of traffic is normal or if it is suspiciously high. This will enable safe decisions as to whether the network interface should be taken down before the network itself is compromised, in case of e.g. a Denial Of Service attack.
6. If the LAN running a CDP control system is connected to a Wide Area Network (WAN) such as the Internet, the connection point should pass through a dedicated remote-access controller. These should only be interfaced from outside the network through SSH v2 or another reliable cryptographic network protocol.
7. An alternative to using SSH v2 is to set up a VPN solution to connect into the network that connects to the LAN the control system runs on.
8. Access connections to a remote-access controller should be verified in a firewall filter in the remote access controller, or in a router before it. To be able to gain a connection to the remote access controller, the originating IP must be let through this firewall filter. This will assure that only predefined IP addresses are allowed to access the network remotely.
9. If a complete separation between the LAN running the control system and the WAN/Internet is required, the remote-access controller can be physically disconnected from the WAN/Internet while not in use. This means that to be able to access the network through the remote-access controller, a person on-site needs to physically connect the remote-access controller to the WAN/Internet. This gives very high security while remote-access operations are not ongoing, which is normally most of the time. Such an option may be considered for systems with high demands for security. It is also an easy-to-implement option for any network, no matter what security demands there are.
10. Communication to the outside world should preferably be set up as 'dial out' instead of 'dial in'. This will lower the risk of a breach from the outside. Note that DNS lookups could be spoofed, so barriers should be set up to mitigate that attack vector.

If following the above-mentioned advisories, it will be very difficult for an intruder to gain unauthorized access to the network remotely. The more barriers that are imposed, the more secure the system will be.

Inside the Network

In addition to the network barriers described in the above advisories, there are further barriers in the local system that should be considered by the system owner.

• Operating systems running on the remote access controllers should be configured with care to prevent unauthorized access. Username and password policy as described in bullet #2 applies.
• Operating systems running on the remote access controllers should be configured with state-of-the-art anti-virus software. Updating the anti-virus definitions should be done in a secure manner not compromising the network.
• The control system should be set up with IPSec or similar to protect the traffic going between nodes in the system.
• In CDP Studio, the StudioAPI protocol is used for communicating in and out of a CDP system. It should be configured according to the Security Manual for greater protection.
• It is recommended to install and operate a SIEM (Security Information and Event Management) system to be able to monitor and detect breaches in the system.

Summary

As explained in this advisory document, the most important security barriers for a CDP control system is the network and operating systems the control system runs on. Systems should be built and set up adhering to applicable security standards like ISA/IEC 62443 Standards for automation and Control systems (See also CyberSecurity Requirements)

Physical access to the system itself should be regulated by the system owner. It is virtually impossible to ensure via the control system software itself, that no harm can be done to the system if an intruder has physical access to the controller (for example, the intruder can turn the system off).

If a system owner follows the advisories given in this document, the safety of a system running a CDP control system is preserved by today's standards.

There will often be practical demands that will not make all of the described advisories feasible for a given system. For each system, the benefits of additional security as described in these advisories should be analyzed against the disadvantages of making it too difficult for an actual authorized user to access the system. Such decisions and risk analyses must be made by the system owner.

Should the system owner be in doubt on any of the advisories, CDP Technologies AS recommends the system owner to bring up the matter with us for further discussions.