ISA/IEC 62443 is a standard focusing on cyber security in industrial control systems. It is comprised of a suite of specifications including policies, procedures, and requirements for system-level installations as well as industrial control systems and devices.

One part of ISA/IEC 62443, specifically ISA/IEC 62443-4-2, contains detailed technical requirement for industrial control systems and devices.

Security requirements/levels

IEC 62443 utilizes the concept of Security Requirements as well as Security Levels to classify the security features and security functionality for industrial control systems and devices. Devices fulfilling those Security Requirements and Security Levels may achieve a security certificate if reviewed by an accredited auditor.

In this article we will look at how the feature set of CIP Security, both the existing CIP Security EtherNet/IP Confidentiality Profile as well as the in-development CIP Security User Authentication Profile, maps to and fulfills requirements defined in IEC 62443-4-2. The Security Requirements in IEC 62443-4-2 have been reviewed and we can present an investigation on which security requirements are fulfilled by CIP Security, and which are out of scope and need to be fulfilled by other means.

A company developing products intended to be certified against a security level in IEC 62443-4-2 can leverage the information in this article to facilitate their investigation and design. The investigation done in this paper can reduce the effort needed to achieve a certification. Beyond IEC 62443-4-2, this analysis can also aid in vendors seeking IEC 62443-3-3 certification, as that is a certified system rather than a single product. For IEC 62443-3-3, this analysis can show what capabilities a CIP Security enabled product can provide to the system, which can help in constructing an IEC 62443-3-3 argument.

Introduction

Concept of trust boundary is part of CIP Security.

IEC 62443 is an international standard around the security of industrial control systems. Over the last several years this standard has grown in prominence to become a highly recognized, ascendant standard for industrial control system security. The standard itself contains several parts, with part 4-2 focused specifically on the security requirements an individual product must satisfy in order to be certified. CIP Security is the ODVA standard for securing CIP and EtherNet/IP, with reliance on widespread and robust technologies such as TLS, DTLS, OpenID Connect, and OAuth 2.0.

This article analyses CIP Security and the IEC 62443 requirements to determine which requirements are satisfied, either partially or fully by CIP Security.

It is important to keep in mind that certification of a product to IEC 624434-2 is an intensive process that requires formal threat modeling and analysis of the product. Given this, it is not possible to make claims that CIP Security will satisfy IEC 62443 requirements in all possible cases and all possible implementations. This article is intended to be a guide for those seeking IEC 62443-4-2 certification and leveraging CIP Security for meeting some of the requirements. Necessarily, some assumptions must be made for this analysis, and those assumptions do not necessarily apply in all scenarios.
For the purpose of this article, the product under consideration is assumed to be a simple device with one physical Ethernet port. That port allows for EtherNet/IP and CIP communications (other communication protocols are not considered). CIP Security has been implemented, which includes the EtherNet/IP Confidentiality Profile and the User Authentication Profile. That is, the trust boundary is drawn around the device, with the data coming in from or going out to the Ethernet port crossing the trust boundary. Many devices that will be certified to IEC 62443-4-2 will have other ports and more complex trust boundaries, however the device and trust is assumed to be this simple, illustrative case.

CIP Security overview

CIP Security has two main profiles: the EtherNet/IP Confidentiality Profile and the User Authentication Profile. The former is focused on transport level security for EtherNet/IP, and the latter is focused on providing user authentication and basic authorization. A brief description of these two profiles is given, for more information please see Volume 8 of the CIP networks specification.

The EtherNet/IP Confidentiality Profile makes use of the IETF-standard TLS (RFC 5246) and DTLS (RFC 6347) protocols in order to provide a secure transport for EtherNet/IP traffic. TLS is used for the TCP- based communications (including encapsulation layer, unconnected messaging, transport class 3), and DTLS for the UDP-based transport class 0/1 communications. This approach is analogous to the way that HTTP uses TLS for HTTPS. Certificate management is also provided by this profile. Certificates can be managed over the standard EST protocol, or over CIP via defined attributes and services.

Profile provides these security attributes:

• Authentication of the endpoints: ensuring that the target and originator are both trusted entities. End point authentication is accomplished using X.509 certificates or pre-shared keys.
• Message integrity and authentication: ensuring that the message was sent by the trusted endpoint and was not modified in transit. Message integrity and authentication is accomplished via TLS/DTLS hashed message authentication code (HMAC).
• Message encryption: optional capability to encrypt the communications, provided by the encryption algorithm that is negotiated via the TLS/DTLS handshake.

The CIP Security User Authentication Profile provides mechanisms to authenticate users and to limit access to the least privilege appropriate for a given role. The User Authentication Profile again takes advantage of IETF standard technology, such as JWTs, OAuth 2.0 and OpenID Connect to authenticate the user and grant the appropriate level of access to protected resources. This profile allows for a CIP target to act as an identity authority itself, containing a database of users and their associated claims, or allows devices to integrate into a third-party identity management system.

This integration is achieved through the standard OpenID Connect technology, commonly leveraged throughout the Internet and in enterprise systems and IT systems. A basic level of authorization is also defined by the User Authentication Profile, although for most actions it is up to the vendor to determine what roles have appropriate privilege.

Local Authentication.

IEC 62443

The IEC 62443 series have been developed to address the need for cyber security and robustness in industrial control systems. Some general background information will be given here on the IEC 62443 specification, and especially the IEC 62443-4-2 specification. However, the IEC documents remain the authoritative reference; understanding of the IEC documents is necessary for a full interpretation of the information presented.

The family of the IEC 62443 standards is divided into 4 parts, General, Policies & Procedures, System, and Components. Within each part there are several elements that address specific topics related to the specific part of the standard. The standard in the series have the name of IEC 62443-X-Y. Figure 4 shows the groups and the individual elements of IEC 62443.

Each part deals with information related to the focus of that part and its intended audience. The parts refer to the X in the naming of the standard and the four are:

• General: this group provides elements that discuss items that are common and general for the whole series.
• Policies & Procedures: items address policies and procedures to implement a cybersecurity management system.
• System: elements describe requirements and management of systems.
• Components: requirements for components used in industrial systems.

IEC 62443-4-1

IEC 62443-4-1 introduces an established secure development process, and this is the basis for developing products that comply to IEC 62443-4-2. For the purposes of this article, IEC 62443-4-1 and the associated processes are outside of scope.

IEC 62443-4-2

In IEC 62443-4-2 functional requirements for components that are to be used in industrial control systems are defined. Although the term component is quite general, it can naturally be applied to a singular product or device. The document defines requirements for different types of components: software applications, embedded devices, host devices, and network devices.

Each component type has its individual set of requirements defined, however most of the requirements that are defined within IEC- 62443-4-2 are generic for all types of components.

The cyber security requirements that are defined in the specification for the different components are derived from the industrial control system requirements defined within IEC 62443-3-3. This is derived from the intention of the IEC 62443 series to provide a flexible framework that assists in addressing existing and future cyber security vulnerabilities in industrial automation control systems by applying necessary mitigations for defense. IEC 62443-3-3 defines the concept of system requirements which IEC 62443-4-2 then expands into a series of component-level requirements; these two portions of the IEC 62443 specification align with one another.

The component-level requirements are a technical description of the cyber security requirements in an industrial control system device. Those descriptions give the implementor an understanding about the requirements and what they are intended to protect against. It does not give any direct guidance on how to implement and apply the specific requirement in a product; this is left to the discretion of the implementer.

The component-level requirements are derived from foundational requirements in IEC 62443-1-1; there are a total of seven foundational requirements. Within each foundational requirement group there are a set of component-level requirements. The foundational requirements are used for grouping the component-level requirements as follows:

• Identification and authentication control
• Use control
• System integrity
• Data confidentiality
• Restricted data flow
• Timely response to events
• Resource availability

Central Authentication.

Each component-level requirement has a defined component security level, described with a value of 0 through 4. The value of 0 for a component-level requirement indicates that it is not defined as a requirement. A higher value denotes a higher and more stringent requirement. A brief description of the different security levels is:

• SL 1 – Focused on actors who unintentionally cause security events
• SL 2 – Focused on motivated attackers with basic skills and resources
• SL 3 – Focused on advanced attackers with moderate resources
• SL 4 – Focused on the highest level of attackers with significant skills and resources

The evaluation done is targeting an SL 3 level attacker; therefore SL 4 capabilities are outside the scope of this evaluation.

CIP Security map to requirements

This section details how CIP Security maps to and fulfills the individual component-level requirements. Each IEC 62443-4-2 component-level requirement is listed, along with the relevant CIP Security functionality that covers the requirement.

CR 1.1 Human user identification and authentication: Devices that implement the CIP Security User Authentication Profile will be able to identify and authenticate human users requesting access to the device using CIP Security. CIP Security User Authentication Profile makes use of OpenID Connect when integrating with an external authority. Beyond OpenID Connect integration, the User Authentication Profile also provides the option for the device to store the user account information locally, in which case no authority external to the device is needed. In either case JWTs are used for identification of the users.

CR 1.1 RE-1 Unique identification and authentication: The User Authentication Profile allows for unique identification and authentication through tokens (JWTs). Each JWT is unique and provides proof of authentication, either via a central mechanism like OpenID Connect, or locally to the device’s database of users.

CR 1.1 RE-2 Multifactor authentication for all interfaces: The User Authentication Profile supports integration into a third-party identity provider via OpenID Connect and OAuth 2.0, which can support multifactor authentication. CIP Security devices will not support multifactor authentication within the device itself, although they will fully integrate into third-party systems supporting OpenID Connect, which can support multifactor authentication. However, it is also possible for a vendor to extend the User Authentication Profile to support multifactor authentication locally within the device if they wish to do so.

CR 1.2 Software process and device identification and authentication: Devices implementing CIP Security use either X.509 certificates or pre-shared keys as a proof of their identity. The X.509 certificates or pre-shared keys are also used when devices authenticate themselves within a system, via the CIP Security User Authentication Profile. In the User Authentication Profile, JWTs are used as proof of authentication and allow integration into central identity management solutions. JWTs can be utilized by software processes, devices, and human users.

CR 1.2 RE-1 Unique identification and authentication: JWTs and X.509 certificates both provide unique identification for components. PSKs do not, and should not be selected as the authentication mechanism for users wishing to meet this requirement.

CR 1.3 Account management: CIP Security User Authentication profile defines the functionality for CIP Security devices to manage accounts either locally using username and password or certificates or integrate in an OAuth 2.0/OpenID Connect system for a centralized account management.

CR 1.4 Identifier management: For locally stored users in the CIP Security Authentication profile the device must keep a list of all usernames and to be able to identify the account via a unique username. In the case where the CIP Security device integrates with an OAuth 2.0/OpenID Connect system, the system identity provider ensures that the user identifier is unique.

CR 1.5 Authenticator management: The CIP Security User Authentication Profile allows for optional implementation of initial authenticators. This is meant to bootstrap the system for trust provisioning of the user’s preferred authenticators; the user is prevented from using the default authenticator for any activity outside of provisioning user-controlled authenticators. The User Authentication Profile also allows for updates of the authenticators, whether stored locally or managed externally via OpenID Connect/OAuth 2.0.
When used with EtherNet/IP the authenticators are required to be transmitted over TLS/DTLS with a confidentiality-based cipher suite, ensuring protection from disclosure and modification. Storage of the authenticators internally is not specified by CIP Security, although the specification notes that best practices should be followed to prevent any vulnerabilities that may compromise the authenticator. Other than the internal storage of authenticators, which is outside of scope of the specification, this requirement is met by the User Authentication Profile.

CR 1.7 Strength of password-based authentication: For locally authenticated users, the CIP Security User Authentication Profile provides functionality to enforce the length and complexity of the password. In the case when integrating with an OAuth 2.0/OpenID Connect system it is up to the system to enforce this requirement; many OpenID Connect systems provide support for this.

CR 1.7 RE-1 Lifetime Restrictions for Human Users: For this requirement again OpenID Connect/OAuth 2.0 servers can be configured for this. For locally stored passwords the CIP Security User Authentication Profile provides the option to prevent previously used passwords for a configurable number of generations.

CR 1.7 RE-2 Password Lifetime Restrictions for all Users: CIP does not differentiate between human users and non-human users; this requirement is met using the same rationale as CR 1.7 RE-1.

CR 1.8 Public key infrastructure certificates: The CIP Security public key infrastructure integration is based on EST (Enrolment over Secure Transport) which is an established standard from the IETF. EST relies on X.509 certificates which represent the industry standard defining digital certificates. Using EST a number of workflows and processes can be used to deploy certificates; some of the most common are described in the Pull Model paper presented at the ODVA 2018 Industry Conference. Certificates may also be managed over CIP, through which integration with a PKI can be achieved using CIP client software that can manage certificates on CIP endpoints and can be designed to interact with the PKI.
CR 1.9 Strength of public key-based authentication: This requirement has a number of sub requirements:

• Validate certificates by checking the validity of the signature of a given certificate.
• Validate the certificate chain or, in the case of self-signed certificates, by deploying leaf certificates to all hosts that communicate with the subject to which the certificate is issued.
• Validate certificates by checking a given certificate’s revocation status;
• Establish user (human, software process or device) control of the corresponding private key.
• Map the authenticated identity to a user (human, software process or device).
• Ensure that the algorithms and keys used for the public key authentication conform to CR 4.3 Use of Cryptography.

CR 1.11 Unsuccessful login attempts: When using the centralized authentication scheme of the CIP Security User Authentication Profile this is covered by using an OpenID Connect Authority which enforces limits on unsuccessful login attempts. When using local authentication this is achieved via setting an attribute in the Password Authenticator Object to enforce the number of allowed unsuccessful login attempts.

CR 2.1 Authorization enforcement: CIP Security User Authentication Profile mandates authorization enforcement based on roles. CIP Security specifies role assignments that are required to perform specific security-related operations. For other operations, general guidance is provided by the in the CIP Security Specification as to what is appropriate for a given role.

Due to the wide variety of functions a product which implements CIP can perform it is ultimately up to the vendor to decide what roles can perform what operations on a given product, although CIP Security requires that these decisions be made and enforced via the product’s access policy.

CR 2.1 RE-1 Authorization enforcement for all users: CIP Security User Authentication Profile does not differentiate between humans, software processes, and devices. All of these types of users are subject to authorization controls.

CR 2.1 RE-2 Permission mapping to roles: CIP Security User Authentication Profile provides well-defined roles, with the possibility for a vendor to add more. The roles are not strictly hierarchical and apply to humans as well as software processes and devices.

CR 2.1 RE-3 Supervisor Override: CIP Security User Authentication Profile provides a service allowing for a temporary escalation of privilege. This escalation lasts for a configurable amount of time.

CR 2.4 Mobile code: Given the assumption that only CIP and EtherNet/IP is used for data communication, then mobile code is transmitted using CIP Security. Therefore, mobile code is protected in transit via TLS or DTLS, and only an authorized user via the User Authentication Profile can transmit Mobile Code (Engineer or Administrator). This requirement is met via CIP Security.

CR 2.6 Remote session termination: Remote sessions are terminated automatically after inactivity time. This applies to TLS sessions, DTLS sessions, and User Authentication sessions, each having its own configurable inactivity time.

CR 2.7 Concurrent session control: CIP Security devices support and Electronic Data Sheet (EDS) file which includes information on connection capacity. This defines limits on number of CIP sessions as well as I/O sessions.

CR 3.1 Communication integrity: Integrity of communications is provided by HMAC on TLS/DTLS sessions, using SHA-2 family algorithms. This provides best-in-class integrity protections for data in transit via internationally recognized and well-vetted cryptography and security protocols.

CR 3.1 RE-1 Communication authentication: Authenticity of communications is provided by HMAC on TLS/DTLS sessions, using SHA-2 family algorithms. This provides best-in-class integrity protections for data in transit via internationally recognized and well-vetted cryptography and security protocols.

CR 3.7 Error handling: Generally, CIP provides a rich set of error handling and feedback in order to allow integrators and users to commission a device within a system. However, this information is application related information. CIP Security has specifically been designed not to disclose or reveal any information that can be used to exploit the device or system; the error codes defined do not leak sensitive information.

CR 3.8 Session integrity: This requirement has a number of sub requirements:

• The capability to invalidate session identifiers upon user logout or other session termination;
• The capability to generate a unique session identifier for each session and recognize only session identifiers that are system-generated; and
• The capability to generate unique session identifiers with commonly accepted sources of randomness.

CR 3.12 Provisioning product supplier roots of trust: CIP Security defines the use of vendor certificates, which includes a root of trust managed by the vendor. Those certificates and associated root of trust can be used as the key to perform the integrity check and offer a way to prove it is a genuine device that has not been tampered with. However, it is up to the vendor to securely store the vendor certificate and provide means to use the vendor certificates.

CR 3.13 Provisioning asset owner roots of trust: CIP Security provides interfaces to commission user-defined certificates used for secure communication between devices in a system. Besides this the User Authentication Profile adds interfaces and capabilities to authenticate users that have access to the device or system as a whole.

CR 4.1 Information confidentiality: Protecting the data at rest is out of the scope for CIP Security as this is not related to the communication protocol. However, for data in transit CIP Security fully covers this requirement via the CIP Security EtherNet/IP Confidentiality Profile. This profile is built on TLS and DTLS which has the capability to provide confidentiality to the data in transit. The protection of data is done via TLS and DTLS confidentiality-based cipher suites.

CR 4.3 Use of cryptography: As noted before data at rest is out of scope for CIP Security. To protect data in transit CIP Security is built using standards such as TLS and DTLS, OpenID Connect, X.509, OAuth 2.0, RSA, ECC, AES, SHA-2, which represent widely accepted and widely used, well-vetted and well- tested algorithms and technologies.

CR 7.6 Network and security configuration settings: CIP Security provides the ability to configure a device according to recommendations provided by documents such as The Converged Plant-Wide Ethernet guide.

CR 7.6 RE-1 Machine-readable reporting of current security settings: The Get Attributes service of the CIP Security Objects allow for security settings to be read out of a device in a machine-readable format.

CR 7.7 Least functionality: CIP Security includes options to close TCP and UDP ports not in use, the same option is provided to close down IANA protocols such as ICMP.

Jack Visoky, Security Architect and Sr. Project Engineer, Rockwell Automation and Joakim Wiberg, Manager Technology and Platforms, HMS Networks.