Securing Your Industrial Systems with IEC 62443

Industrial Internet-of-Things (IIoT) technologies form the foundation of the Industry 4.0 revolution. Smart technologies increase productivity, efficiency and reduce costs in manufacturing. However, their autonomous nature also increases the potential attack surface if not secured correctly.

Each of the interconnected devices is a potential entry point for an attacker to enter the industrial system. Take ransomware as an example. The downtime of a halted production line can run to many thousands of dollars per minute. Studies have shown that more than half of ransoms are paid in the event of a successful ransomware cyberattack, and more than half of those paid at least $500,000. Other types of cyber-terror attack, mounted on these same industrial sectors, could result in catastrophic environmental impact or even loss of life. Clearly, as our world becomes increasingly digital, the sphere of industrial cybersecurity is one of great importance.

The Importance and Structure of IEC 62443

This is where IEC 62443  comes in. IEC 62443 is a set of standards, developed by security experts, to provide a holistic, risk-based approach for the cyber security of Industrial Automation and Control Systems (IACS) and Operational Technology (OT) environments. IEC 62443 standards are designed for versatility, and can be applied either to components in a system or to the embedded parts within a more elaborate device (a single microprocessor, for example). However, the standards also describe how to secure entire systems and facilities, regardless of whether those facilities are factories, processing plants, building-automation systems, chemical facilities, or medical systems or facilities.

The standards are divided into four sections, with each addressing a separate aspect of security for IACS and other OT environments. Here’s a closer look:

1. The first section defines the terminology, concepts and models used throughout other sections of the standard. It provides a common ground for stakeholders working together throughout the different phases of IACS lifecycle. The terminology and concepts defined in this section support efficient communication between interested parties.
2. The second section describes roles and requirements for methods and processes associated with IACS security. The text specifies how asset owners can establish an IACS security program, how to evaluate the security protection of an IACS and how to patch an IACS. It also provides a set of requirements for security capabilities to be supported by the security programs of integrators and maintenance service providers.
3. Section three focuses on cybersecurity requirements at the system level. It uses the concepts of zones and conduits as defined in the first section. Separating a system into smaller zones based on security risk helps focus protection efforts on parts of the system that pose the highest risk. The level of risk is determined by how serious the effects of compromise would be.
4. The fourth section describes the technical requirements for the secure development of components, as well as the security functionalities of each component, to ensure products used in industrial systems will operate securely. In addition to defining technical requirements for components, the fourth section also discusses the four Common Component Security Constraints (CCSC) a component must meet to comply with IEC 62443-4-2. In particular, CCSC 4 states that the product must be developed with a process that complies with IEC 62443-4-1.

IEC 62443 also describes the different security levels an IACS system can aim to achieve. For each security level, there is a set of requirements that a system or component must fulfill. The lowest level, SL0, describes a system that requires no special protection. In contrast, the highest level, SL4, describes a system that requires protection against intentional security violations using sophisticated means and extended resources. For example, SL4 might be recommended for a system that is vulnerable to ransomware attacks mounted by professional hackers with advanced equipment or other resources.

Security levels are used to decide whether a product or component satisfies the security needs of a system or a zone inside a system. For example, an SL2 62443-4-2-compliant product cannot be used in a system or in a zone inside a system for which SL3 is the minimum required security level. This dependence may influence product development, since customers with a system that needs SL3 protection, for example, will choose products or components that meet SL3 expectations.

How NXP Supports Customers to Achieve 62443 Compliancy

Planning and designing a product that complies with IEC 62443 can be time-consuming and costly, since it requires knowledge of both the standard and the product in a cybersecurity context. That means it’s important for developers to think about security from the very start, and to follow the security-by-design paradigm. This process can be sped up by using components that match the security-related requirements of a product.

NXP has defined a set of security primitives to establish common grounds for security nomenclature in the IIoT sphere. The document describes security features on multiple levels and explains a framework that allows developers to think about the security requirements of their products in a structured way. System designers can use this method to map certification and standard criteria, as well as use-case requirements, to product capabilities, and vice versa. The framework aids engineers in selecting and integrating solutions that meet their requirements, while achieving IEC 62443-4-2 compliance in an automated way.

As well as helping engineers find components that match their security-related requirements, NXP also advances IIoT security by actively practicing a security-centered culture in production. For example, NXP’s processes for security maturity business and incident response have been certified under IEC 62443-4-1: Secure product development lifecycle requirements. NXP products that are designed and developed according to the 62443-4-1 standard can be integrated into products that aim for 62443-4-2 compliancy, since they already meet CCSC 4 requirements.

Certain NXP products, designed and developed according to the 62443-4-1 certified process, have security capabilities that already satisfy requirements of 62443-4-2. As a result, products aiming for 62443-4-2 compliancy can meet various requirements of the updated standards by simply integrating an NXP product as a component. Our application note, titled “ Ease ISA/IEC 62443 compliance with EdgeLock SE05x ”, gives an overview of how an NXP product can help obtain 62443-4-2 compliancy.

In addition, specific NXP components, such as the EdgeLock SE051 secure element, are certified for 62443-4-2 (technical security requirements for IACS components). Using methods and components that are already certified facilitates compliance, especially for more complex end-products that integrate these components.

In summary, growing industry 4.0 adoption means that cyberattacks are an ever-growing threat to every modern company. These cyberattacks are common, and recovery is often non-trivial, lengthy and costly. IEC 62443 is a versatile set of standards, introduced to respond to the constantly increasing threat of cyberattacks in various institutions, ranging from industrial facilities to medical use cases. To aid engineers in reaching IEC 62443 compliance, NXP offers a framework that maps certification and standard criteria, as well as use-case requirements, to product capabilities, and vice versa. In addition, a number of NXP production processes and devices are already certified under IEC 62443, which further reduces development time and simplifies efforts required to reach IEC 62443 certification.

If you are interested in this security standard or security aspects of industrial IoT you can learn more about IEC 62443 for Industrial Cyber Security in this video.

Authors

Joppe W. Bos

Joppe W. Bos is a Technical Director and cryptographer at the Competence Center Crypto and Security (CCC&S) in the CTO organization at NXP Semiconductors. Based in Belgium, he is the technical lead of the Post-Quantum Cryptography team, and has authored over 20 patents and 50 academic papers. He is the co-editor of the IACR Cryptology ePrint Archive.

Christine Cloostermans

Christine Cloostermans is a senior cryptographer at the Competence Center for Cryptography and Security (CCC&S) in the CTO organization at NXP Semiconductors. She acquired her doctorate from TU Eindhoven on topics related to lattice-based cryptography. Christine is a co-author on 10+ scientific publications, and has given many public presentations in the area of post-quantum cryptography. Beyond PQC, she is active in multiple standardization efforts, including IEC 62443 for the Industrial domain, ISO 18013 for the mobile driver’s license, and the Access Control Working Group of the Connectivity Standards Alliance.

Aylin Buyruk

Sara Aylin Buyruk is a member of the Competence Center Crypto and Security (CCC&S) in the CTO organization at NXP Semiconductors. Based in the Netherlands, she completed a master's degree in cybersecurity at the Eindhoven University of Technology and now works in security for Industrial and Internet of Things.

Daniel Kiraly

Daniel Kiraly is a Security Manager for Site and Process Certification at the Competence Center Crypto and Security (CCC&S) in the CTO organization at NXP Semiconductors. Based in Austria, he is responsible for ensuring compliancy to multiple site and process certifications, including ISO/IEC 62443-4-1, ISO/SAE 21434, TISAX, ISO 27001. He was previously a Qualified Evaluator certified by the Italian IT Security Certification Body (OCSI) and he successfully passed the Certified Common Criteria Evaluator exam of the German Federal Office for Information Security (BSI).