×
Hidden Message here.

PLCnext on LinkedInPLCnext on Instagram  PLCnext on YouTube Github PLCnext CommunityStore PLCnext Community

Security-by-Design according to IEC 62443 in product development

5 THings your PLC can't do but should

 

Dipl.-Ing. Boris Waldeck

Senior Project Manager Software

 

Today, the comprehensive protection of machines and systems against unauthorized access is an important requirement for automation systems. Is it enough here to extend devices with security functions? Or is security a function of the entire automation solution? The IEC 62443 standard specifies the security processes and functions required for this. Read the following blog post to find out what you need to consider when implementing this standard in your automation system.

The worldwide security standard IEC 62443 aims for a holistic approach to cyber security in automation technology. For this purpose, it describes three roles (operator, integrator and component manufacturer) and defines the necessary measures. For all roles, security-by-design proves to be an essential framework condition. The IEC 62443 series of standards consists of 13 parts in which the security requirements for processes, the functional measures and the state of the art are specified for each role

When developing automation devices, their function can only be secured through security-by-design. Once the foundation has been laid, the security of the individual integration phases defined in IEC 62443 is transformed into a secure-by-design solution that is suitable for numerous use cases.

 

Track implementation and verify all security requirements

 

00017262IEC 62443-4-1 describes the safe product development process. The central element is a process that ensures that all security requirements have been implemented and verified. It is completed by additional features for the realization of security. In particular, this includes a threat analysis based on the security context (the application scenarios of the product), the concept of "Defense in depth" as well as measures for the protection of private keys. All approaches are necessary for a product to meet the Secure-by-Design requirement. Another important aspect is the ability of the device manufacturer to react appropriately to security vulnerabilities and to publish reliable security updates. Today, these requirements are usually executed by a Product Security Incident Response Team (PSIRT).

IEC 62443-4-2 defines the technical framework conditions. Security threats are used to define security levels (SL) from 0 to 4, which are tailored to the capabilities of the attacker. The standard defines seven foundational requirements (FR):

  • FR1 IAC – Identification and authentication control
  • FR2 UC – Use control
  • FR3 SI – System integrity
  • FR4 DC – Data confidentiality
  • FR5 RDF – Restricted data flow
  • FR6 TRE – Timely response to events
  • FR7 RA – Resource availability

The implementation of these prerequisites shall be performed according to the secure development process specified in Part 4-1.

 

Measures for implementing a secure architectural design

 

In the conception of the solution, security-by-design is an important framework condition of the architectural design. This can result in the following measures, among others:

  • Use of Trusted Platform Modules (TPM) as hardware protection for the private vendor keys
  • Use of a configurable Linux kernel, which can be secured and maintained specifically with regard to security
  • Authentication and authorization of human users and software processes on all communication channels
  • Implementation of a Crypto Store for certificates, keys and identities of system integrators and operators
  • Use and configuration of VPN (Virtual Private Network) communications
  • Support of the OPC UA interface with security profiles, a UA role and rights system, X.509 certificates and an interface to the global discovery server for certificate distribution
  • Programmable TLS communication (Transport Layer Security) for application-specific solutions, for example as function blocks according to IEC 61131 or high-level language interface
  • Use and configuration of the Linux firewall
  • Use and configuration of logging mechanisms with a synchronized time base
  • Device management interface for updating firmware components

 

Preparation of an industry-specific blueprint

 

The system integrator plays an essential role in IEC 62443. Together with the operator, he determines the protection requirements and selects the suitable components for the system solution. The standard defines security levels for each role:

  • Capability SL (SL-C) - achievable SL for components and systems
  • Achieved SL (SL-A) - achieved SL for the automation solution
  • Target SL (SL-T) - SL to be achieved for the automation solution as requirement of the operator

Once the solution has been set up, its suitability is verified in cooperation with the operator based on the required security level (SL-A/SL-T) and, if necessary, additional measures are taken. To simplify this procedure, it is recommended that device manufacturers and system integrators prepare industry-specific blueprints (reference systems) that can be adapted to the operator's requirements if necessary. In this way, a portfolio of devices or subnetworks can be compiled in advance with SL-C/SL-A for different applications.

The procedures are described in the standard in two parts. Part 3-3 outlines and evaluates the supported security measures and levels at the interface between system integrator and product manufacturer. On this basis, the devices required to achieve SL-T are selected. Part 2-4 defines the processes for integration, commissioning and maintenance of the automation solution.

 

00005456Systemic cooperation of the installed devices

 

It is not enough if only the devices meet the security requirements. They must also work together systemically so that the solution is easy to configure and maintain. From the systemic point of view, there are additional requirements and interfaces:

  • Network architecture of the automation solution
  • Configuration of the automation solution
  • Administration of user accounts and certificates
  • Firewall settings management
  • Treatment of results
  • Device and patch management
  • Remote maintenance

The following aspects can support this framework:

  • Network segmentation: The data exchange between different internal system parts (zones) can be configured.
  • Encrypted data transmission: Incoming and outgoing communication can be encrypted by VPN, for example via IPsec or OpenVPN.
  • Integration into central user administrations: Through a network-wide configuration of users, individual access for each employee can be assigned and managed.
  • Integrated device and patch management: For the administration of multiple devices in the automation solution, intelligent and efficient device and patch management is provided as a solution or interface. It enables the central creation and administration of all security-relevant device settings and supports firmware upgrades.
  • Secure remote access: The use of additional security appliances (e.g. mGuard from Phoenix Contact) is useful for remote maintenance of machines via insecure networks. It is important here that the configuration of devices is coordinated.

 

Conclusion

 

For a security-by-design solution according to IEC 62443 it is not enough to extend existing devices with security functions. From the development processes to the device function to the solution, security must be considered from the very beginning. It is recommended to use appropriate devices as far as possible when designing solutions. These solutions are secured with secure network zone concepts. A further opening of the zones necessary for flexible automation can be achieved step by step with individual devices. PLCnext Technology already opens new possibilities for this because when it was conceived as an open ecosystem, security-by-design was an important basic condition.