IEC 62443

IEC 62443 is an international series of standards on "Industrial communication networks - IT security for networks and systems". The standard is divided into different sections and describes both technical and process-related aspects of industrial cybersecurity. It divides the industry into different roles: the operator, the integrators (service providers for integration and maintenance) and the manufacturers. The different roles each follow a risk-based approach to prevent and manage security risks in their activities.

History

As an international standard, the IEC 62443 is the result of the IEC standards creation process where all national committees involved agree upon a common standard. Multiple organizations and committees submitted input to the IEC working groups and helped shape the IEC 62443.

Starting in 2002, the Industrial Automation and Control System Security Committee (ISA99) of the International Society of Automation developed a multi-part series of standards and technical reports on the subject of IACS security. These work products were submitted to the ISA for approval and then publishing under ANSI. The documents originally referred to as ANSI/ISA-99 or ISA99 standards and were renumbered to be the ANSI/ISA-62443 series in 2010. The content of this series was submitted to and used by the IEC working groups.

Similarly, the German engineering associations VDI and VDE released the VDI/VDE 2182 guidelines in 2011. The guidelines describe how to handle information security in industrial automation environments and were also submitted to and used by the IEC working groups.

Structure

The IEC 62443 Industrial communication networks - Network and system security series of standards consists of the following parts:

• Part 1-1: Terminology, concepts and models (Technical Specification, Edition 1.0, July 2009)
• Part 2-1: Establishing an industrial automation and control system security program (International Standard, Edition 1.0, November 2010) This section of the standard is aimed at operators of automation solutions and defines requirements for how security during the operation of plants is to be considered (see ISO/IEC 27001).

• Part 2-3: Patch management in the IACS environment (Technical Report, Edition 1.0, June 2015)
• Part 2-4: Security program requirements for IACS service providers (Technical Report, Edition 1.1, August 2017) This part defines requirements ("capabilities") for integrators. These requirements are divided into 12 topics: Assurance, architecture, wireless, security engineering systems, configuration management, remote access, event management and logging, user management, malware protection, patch management, backup & recovery, and project staffing.

• Part 3-1: Security technologies for industrial automation and control systems (Technical Report, Edition 1.0, July 2009)
• Part 3-2: Security risk assessment for system design (International Standard, Edition 1.0, Juni 2020)
• Part 3-3: System security requirements and security levels (International Standard, Edition 1.0, August 2013) Technical requirements for systems and security levels are described in this part.

• Part 4-1: Secure product development lifecycle requirements (International Standard, Edition 1.0, January 2018) Section 4-1 of IEC 62443 defines how a secure product development process should look like. It is divided into eight areas ("Practices"): management of development, definition of security requirements, design of security solutions, secure development, testing of security features, handling of security vulnerabilities, creation and publication of updates and documentation of security features.

• Part 4-2: Technical security requirements for IACS components (International Standard, Edition 1.0, February 2019) This section defines technical requirements for products or components. Like the requirements for systems (Section -3-3), the requirements are divided into 12 subject areas and refer to them. In addition to the technical requirements, common component security constraints (CCSC) are defined, which must be met by components to be compliant with IEC 62443-4-2:
  • CCSC 1 describes that components must take into account the general security characteristics of the system in which they are used.
  • CCSC 2 specifies that the technical requirements that the component cannot meet itself can be met by compensating countermeasures at system level (see IEC 62443-3-3). For this purpose, the countermeasures must be described in the documentation of the component.
  • CCSC 3 requires that the "Least Privilege" principle is applied in the component.
  • CCSC 4 requires that the component is developed and supported by IEC 62443-4-1 compliant development processes.

Maturity and Security Level

IEC 62443 describes different levels of maturity for processes and technical requirements. The maturity levels for processes are based on the maturity levels from the CMMI framework.

Maturity Level

Based on CMMI, IEC 62443 describes different maturity levels for processes through so-called "maturity levels". To fulfill a certain level of a maturity level, all process-related requirements must always be practiced during product development or integration, i.e. the selection of only individual criteria ("cherry picking") is not standard-compliant.

The maturity levels are described as follows:

• Maturity Level 1 - Initial: Product suppliers usually carry out product development ad hoc and often undocumented (or not fully documented).
• Maturity Level 2 - Managed: The product supplier is able to manage the development of a product according to written guidelines. It must be demonstrated that the personnel who carry out the process have the appropriate expertise, are trained and/or follow written procedures. The processes are repeatable.
• Maturity Level 3 - Defined (practiced): The process is repeatable throughout the supplier's organization. The processes have been practiced and there is evidence that this has been done.
• Maturity Level 4 - Improving: Product suppliers use appropriate process metrics to monitor the effectiveness and performance of the process and demonstrate continuous improvement in these areas.

Security Level

Technical requirements for systems (IEC 62443-3-3) and products (IEC 62443-4-2) are evaluated in the standard by four so-called Security Levels (SL). The different levels indicate the resistance against different classes of attackers. The standard emphasizes that the levels should be evaluated per technical requirement (see IEC 62443-1-1) and are not suitable for the general classification of products.

The levels are:

• Security Level 0: No special requirement or protection required.
• Security Level 1: Protection against unintentional or accidental misuse.
• Security Level 2: Protection against intentional misuse by simple means with few resources, general skills and low motivation.
• Security Level 3: Protection against intentional misuse by sophisticated means with moderate resources, IACS-specific knowledge and moderate motivation.
• Security Level 4: Protection against intentional misuse using sophisticated means with extensive resources, IACS-specific knowledge and high motivation.

Concepts

The standard explains various basic principles that should be considered for all roles in all activities.

Defense in Depth

Defense in Depth is a concept in which several levels of security (defense) are distributed throughout the system. The goal is to provide redundancy in case a security measure fails or a vulnerability is exploited.

Zones & Conduits

Zones divide a system into homogeneous zones by grouping the (logical or physical) assets with common security requirements. The security requirements are defined by Security Level (SL). The level required for a zone is determined by the risk analysis.

Zones have boundaries that separate the elements inside the zone from those outside. Information moves within and between zones. Zones can be divided into sub-zones that define different security levels (Security Level) and thus enable defense-in-depth.

Conduits group the elements that allow communication between two zones. They provide security functions that enable secure communication and allow the coexistence of zones with different security levels.

Certification Schemes

Processes, systems and products used in industrial automation environments can be certified according to IEC 62443. Accredited schemes as well as the international IECEE CB scheme are fully compliant with IEC 62443, whereas the proprietary ISCI ISASecure is not.

Accredited Certification Schemes

IEC 62443 certification schemes have been established by several global Certification Bodies (CB). The schemes are based on the referenced standards and procedures which describes their test methods, surveillance audit policy, public documentation policies, and other specific aspects of their program. Cybersecurity certification programs for IEC 62443 standards are being offered globally by several recognized CBs including Intertek, SGS-TÜV Saar, TÜV Nord, TÜV Rheinland, TÜV SÜD, CertX and UL.

A global infrastructure has been established to ensure consistent evaluation of the IEC 62443. Impartial third-party organizations called Certification Bodies (CB) are accredited according to ISO/IEC 17065 and ISO/IEC 17025. Certification Bodies are accredited by national Accreditation Bodies (AB) to perform the auditing, assessment, and testing work. The ABs operate per the requirements of ISO/IEC 17011, a standard that contains requirements for the competence, consistency, and impartiality of accreditation bodies when accrediting conformity assessment bodies. ABs are members of the International Accreditation Forum (IAF) for work in management systems, products, services, and personnel accreditation or the International Laboratory Accreditation Cooperation (ILAC) for laboratory accreditation. A Multilateral Recognition Arrangement (MLA) between ABs will ensure global recognition of accredited CBs.

IECEE CB Scheme

The IEC System for Conformity Assessment Schemes for Electrotechnical Equipment and Components (IECEE) Certification Body Scheme (CB Scheme) is a multilateral agreement that facilitates market access for manufacturers of electrical and electronic products. Under the CB Scheme processes, products and systems can be certified according to IEC 62443.

The origin of the CB Scheme comes from the CEE (former European "Commission for Conformity Testing of Electrical Equipment") and was integrated into the IEC in 1985. Currently, 54 Member Bodies are in the IECEE, 88 NCBs (National Certification Bodies), and 534 CB Test Laboratories (CBTL). In the field of product certification, this procedure is used to reduce the complexity in the approval procedure for manufacturers of products tested and certified according to harmonized standards. A product that has been tested by a CBTL (certified testing laboratory) according to a harmonized standard such as the IEC 62443, can use the CB report as a basis for a later national certification and approval such as GS, PSE, CCC, NOM, GOST/R, BSMI.

ISCI ISASecure

The International Security Compliance Institute (ISCI) created a conformity assessment scheme for the national ANSI/ISA 62443 standards. This scheme can be used to certify industrial automation control systems, components and processes. The ISASecure scheme is partly based on the IEC 62443 and ISCI development processes include maintenance policies to ensure that the ISASecure certifications remain in alignment with the IEC 62443 standards as they evolve.

The ISCI offers multiple certifications under the ISASecure brand:

• SSA (System Security Assurance) certification of systems according to IEC 62443-3-3
• CSA (Component Security Assurance) certification of automation components according to IEC 62443-4-1 and IEC 62443-4-2
• SDLA (Secure Development Lifecycle Assurance) certification of automation systems development organizations according to the IEC 62443-4-1
• EDSA (Embedded Device Security Assurance) certification of components based on the IEC 62443-4-2. This certification is not fully compliant with IEC 62443-4-2. The IEC 62443-4-2 requires components to be developed according to a IEC 62443-4-1 compliant development lifecycle, which EDSA does not require.

See also

• Cybersecurity standards
• Functional safety
• International Electrotechnical Commission

External links

• IEC website
• IECEE website