Security in PLCnext Engineer

You have to protect components, networks and systems against unauthorized access and ensure the integrity of data.

This chapter describes the following:

The security-related features implemented in PLCnext Engineer that help protecting the engineering system, your solution as well as the automation system.
The measures to protect network-capable devices with communication interfaces, solutions, and PC-based software against unauthorized access. It is mandatory to take suitable measures where applicable to protect your system and data.

General security-related procedures, rules and recommendations

PLCnext Engineer implements important security-related features. These features are described below.
In addition, you as a user have to observe particular security rules and take suitable organizational and technical measures to protect PLCnext Engineer, controllers, bus couplers, switches, solutions and project/configuration data against malicious or erroneous change.

Phoenix Contact strongly recommends the following:

Use an Information Security Management System (ISMS) to manage all of the infrastructure-based, organizational, and personnel measures that are needed to ensure compliance with information security directives.
Observe the information given in the Security Guideline for PLCnext Engineer.
At least take all the measures described in the topic "Recommended measures for devices and solutions" into consideration.
Read and take the Phoenix Contact Security Advisories into consideration.

Further Info
Also refer to the security-related information in the PLCnext Info Center which provides many information and practical user tips on the PLCnext Technology control platform and PLCnext Engineer.

Security features implemented in PLCnext Engineer

PLCnext Engineer implements security-related features in several aspects. These features are described in separate chapters or in the context of the corresponding software component. Here, an overview on this security-related implementation is given. Follow the links to get details.

Protection of the PLCnext Engineer installation

Type of protection Description/implementation

Tamper detection When installing PLCnext Engineer, checksums are calculated over the installation. By verifying these checksums, manipulations and data corruption can be detected.
For that purpose, the tool ChecksumCalculator is available which has to be executed regularly to monitor the integrity of the PLCnext Engineer installation. See topic "Security Guideline for PLCnext Engineer" for further information.

Note
By default, access to the PLCnext Engineer installation folder is restricted to Windows admin users.

Licensing of PLCnext Engineer The basic version of PLCnext Engineer comes with a permanent license which is free of charge.
For chargeable Add-Ons to PLCnext Engineer, a license has to be activated. In such a case, you will be delivered a license ticket ID per e-mail. Licenses for software from Phoenix Contact are always hardware-bound licenses. The registration for a permanent license has to be done using the software tool Activation Wizard.

Further Info
Please refer to the Activation Wizard online help for further information on PLCnext Engineer licensing. The online help also describes how to deactivate a license (i.e., move the license back to the Phoenix Contact license server).

Protection of the communication

Type of protection Description/implementation

Secured data transmission with TLS Data transmission is protected by means of TLS. Transport Layer Security is a hybrid encryption protocol which secures the Internet data transfer.

Secured communication between PLCnext Technology controllers and PLCnext Engineer Certificates ensure secure communication connections between PLCnext Technology controllers and PLCnext Engineer.
Note that the communication of the integrated OPC UA server is secured by a separate certificate (see following table row).
The preinstalled manufacturer-defined certificate on the controller can be replaced by a customer-specific certificate. Afterwards, the relevant certificate(s) (at least the root certificate) must be installed in PLCnext Engineer in order to validate the controller as trusted device.
By securing the communication connection this way, also potential man in the middle attacks between the PLCnext Engineer and the PLCnext Technology controller are recognized by the PLCnext Engineer. If such an attack is detected, you have the choice to stop the connection or to continue if the communication breach is intended and needed to support the chosen network architecture.

Secured OPC UA server-client communication The communication of the integrated OPC UA server is secured by a separate certificate. This affects data exchange with OPC UA clients. See topic "OPC UA Security Settings" for details.

Secured communication between PLCnext Engineer ACI and ACI client app To prevent an unauthorized communication via the ACI interface, the connection between an ACI client and PLCnext Engineer is secured by means of a cookie which is stored on the engineering PC. This cookie is encrypted (using Windows Data Protection API) and is afterwards specifically bound to the user login. By verifying the cookie on connection establishment, the authenticity of the ACI client and PLCnext Engineer can be verified thus ensuring that the connection is authorized. Refer to section "Security-related particularities regarding the Application Control Interface (ACI)" for details.

Type of protection	Description/implementation
Secured data transmission with TLS	Data transmission is protected by means of TLS. Transport Layer Security is a hybrid encryption protocol which secures the Internet data transfer.
Secured communication between PLCnext Technology controllers and PLCnext Engineer	Certificates ensure secure communication connections between PLCnext Technology controllers and PLCnext Engineer. Note that the communication of the integrated OPC UA server is secured by a separate certificate (see following table row). The preinstalled manufacturer-defined certificate on the controller can be replaced by a customer-specific certificate. Afterwards, the relevant certificate(s) (at least the root certificate) must be installed in PLCnext Engineer in order to validate the controller as trusted device. By securing the communication connection this way, also potential man in the middle attacks between the PLCnext Engineer and the PLCnext Technology controller are recognized by the PLCnext Engineer. If such an attack is detected, you have the choice to stop the connection or to continue if the communication breach is intended and needed to support the chosen network architecture.
Secured OPC UA server-client communication	The communication of the integrated OPC UA server is secured by a separate certificate. This affects data exchange with OPC UA clients. See topic "OPC UA Security Settings" for details.
Secured communication between PLCnext Engineer ACI and ACI client app	To prevent an unauthorized communication via the ACI interface, the connection between an ACI client and PLCnext Engineer is secured by means of a cookie which is stored on the engineering PC. This cookie is encrypted (using Windows Data Protection API) and is afterwards specifically bound to the user login. By verifying the cookie on connection establishment, the authenticity of the ACI client and PLCnext Engineer can be verified thus ensuring that the connection is authorized. Refer to section "Security-related particularities regarding the Application Control Interface (ACI)" for details.

Protection of devices

Type of protection Description/implementation

Secured network devices Secure device concept with user roles and password for PLCnext Technology controllers.
Further protection measures are described in the topic "Recommended measures for devices and solutions".

Type of protection	Description/implementation
Secured network devices	Secure device concept with user roles and password for PLCnext Technology controllers. Further protection measures are described in the topic "Recommended measures for devices and solutions".

Protection of libraries

Type of protection Description/implementation

Tamper protected libraries When releasing a library, PLCnext Engineer calculates checksums over the contained components which are then used as signature. By means of this signature the library can be uniquely identified. If included in a project, the signature is verified each time the project is loaded. This way, any modifications (e.g., new version) or data corruptions are recognized.
See topic "Tamper Protection of Libraries" for further details.

Know-how protected libraries When releasing a library, you can protect the contained know-how by defining the visibility of each user-defined POU and data type. Possible protection settings for user library elements are 'Visible', 'Restricted' or 'Hidden'. Furthermore, the redistributability of user libraries can be restricted (setting 'Redistribution = One level only').
See the topic "Releasing Libraries" for further details.

Type of protection	Description/implementation
Tamper protected libraries	When releasing a library, PLCnext Engineer calculates checksums over the contained components which are then used as signature. By means of this signature the library can be uniquely identified. If included in a project, the signature is verified each time the project is loaded. This way, any modifications (e.g., new version) or data corruptions are recognized. See topic "Tamper Protection of Libraries" for further details.
Know-how protected libraries	When releasing a library, you can protect the contained know-how by defining the visibility of each user-defined POU and data type. Possible protection settings for user library elements are 'Visible', 'Restricted' or 'Hidden'. Furthermore, the redistributability of user libraries can be restricted (setting 'Redistribution = One level only'). See the topic "Releasing Libraries" for further details.

Protection of safety-related data

Note
The protection of safety-related data and therefore the integrity of the safety function is of particular importance.
The manipulation of the safety-related application program may result in:

triggering the safety function without a request having occurred in the application.

the unavailability of the safety function so that it is no longer triggered when requested.

the unavailability of the safety function with a simultaneous deliberate causing of the request case.

Type of protection Description/implementation

Protection of safety data integrity/consistency Safety-related data is continuously verified regarding its consistency and integrity. This verification includes:

SNOLD code.

Declarations in variables tables of safety-related POUs and in the Data List of the Safety PLC.

Parameterization/configuration data of the Safety PLC and the safety-related devices/modules.

Any detected inconsistency (i.e., possible data corruptions) results in an editor error and a safety violation notification is output in the MESSAGES window.

Protection of integrity and authorship of safety-related, loadable C functions Security mechanisms ensure the integrity and authorship of safety-related, loadable C functions: When releasing a safety-related function block library with loadable C code, you must provide a file that contains a signature certificate as well as the relating issuer certificates and the corresponding private key (signature key). The root certificate must have been previously announced in PLCnext Engineer. The private key is used for generating the signature of the safety inventory. As a result, this inventory signature then contains the signature certificate including the relating issuer certificates and can be used to proof the integrity of the library and the authorship of the library releaser.

Note
Due to the particular requirements which apply to such a library and the contained C functions, the library creation is restricted to customers who purchased a special license.