IEC 62443 is a series of standards that address cybersecurity for operational technology in automation and control systems. The series is divided into different sections and describes both technical and process-related aspects of automation and control systems cybersecurity. The series is also known as ISA/IEC 62443 in recognition of the fact that much of the initial development was done by the ISA99 committee of the International Society for Automation.
It divides the cybersecurity topics by principal role including:
- the Asset Owner,
- the Product Supplier, and
- the Service Providers (integration and for maintenance)
The different roles each follow a risk-based approach to prevent and manage security risks in their activities.
History
editIn 2002, the International Society of Automation (ISA), a professional automation engineering society and ANSI-accredited standards development organization (SDO) established standards committee (ISA99), which went on to develop a multi-part series of standards and technical reports about Industrial Automation and Control System (IACS) cyber security. These work products were submitted by ISA for approval and then published as North American ANSI standards using the designation ANSI/ISA-99 or ISA99 standards. They 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. Since then, the series has been commonly referred to as ISA/IEC 62443.
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.
The IEC 62443 family of standards is the result of the International Electrotechnical Commission (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 family of standard.
The IEC has approved the IEC 62443 family of standards as 'horizontal standards'. This means that when sector specific standards for operational technology are being developed by subject matter experts, the IEC 62443 standards must be used at the foundation for requirements addressing cybersecurity in those standards. This approach serves to avoid the proliferation of partial and/or conflicting requirements for addressing cybersecurity of operational technology across industry sectors where the same or similar technology or products are deployed at operating sites.
Most recently, the responsible committees (ISA99 and IEC TC65 WG10) now have a comprehensive collaboration relationship that includes joint leadership teams and joint project teams for each part of the 62443 series.
Structure
editIEC 62443 Industrial communication networks - Network and system security series of standards is organized as per the following table:
General | Policies and Procedures | System | Components and Requirements | ||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
1-1 | Technical Specification, Edition 1.0, July 2009[1] | Concepts and models | 2-1 | Edition 2.0, 2024[2] | Security program requirements for IACS asset owners | 3-1 | Technical Report, Edition 1.0, July 2009[3] | Security technologies for industrial automation and control systems (IAC) | 4-1 | Edition 1.0, January 2018[4] | Secure product development lifecycle requirements |
2-3 | Technical Report, Edition 1.0, June 2015[5] | Patch management in the IACS environment | 3-2 | Edition 1.0, June 2020[6] | Security risk assessment and system design | 4-2 | Edition 1.0, February 2019[7] | Technical security requirements for IACS components | |||
2-4 | Edition 2.0, December 2023[8] | Requirements for IACS service providers | 3-3 | Edition 1.0, August 2013[9] | System security requirements and security levels | ||||||
1-5 | Technical Specification, Edition 1.0, September 2023 | Scheme for IEC 62443 security profiles |
- Part 2-1: This part 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).[2]
- Part 2-4: 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.[8]
- Part 4-1: This part 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.[4]
- Part 4-2: This part defines technical requirements for products or components.[7] 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
editIEC 62443 describes different levels of maturity for processes and technical requirements.
Maturity Level
editIEC 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
editTechnical 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
editThe standard explains various basic principles that should be considered for all roles in all activities.
Defense in depth
editDefense 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 and conduits
editZones 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 to standards
editProcesses, systems and products used in industrial automation environments can be certified according to IEC 62443. Many testing, inspection, and certification (TIC) companies offer product and process certifications based on IEC 62443. By accrediting according to the ISO/IEC 17000 series of standards, the companies share a single, consistent set of certification requirements for IEC 62443 certifications which elevates the usefulness of the resulting certificates of conformance.
Accredited certification schemes
editIEC 62443 certification schemes have been established by several global testing, inspection, and certification (TIC) companies. The schemes are based on the referenced standards and define test methods, surveillance audit policies, public documentation policies, and other specific aspects of their program. Cybersecurity certification programs for IEC 62443 standards are being offered globally by many recognized Certification Bodies (CB), including Bureau Veritas, Intertek, SGS-TÜV Saar, TÜV Nord, TÜV Rheinland, TÜV SÜD and UL.
A global infrastructure of national accreditation bodies (AB) ensures consistent evaluation of the IEC 62443. 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 IAF for work in management systems, products, services, and personnel accreditation or the ILAC for laboratory accreditation. A Multilateral Recognition Arrangement (MLA) between ABs will ensure global recognition of accredited CBs.
TIC companies are accredited by an AB to provide inspection according to the ISO/IEC 17020, testing laboratories according to ISO/IEC 17025 and certification of products, processes, and services according to ISO/IEC 17065.
IECEE CB Scheme
editThe 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
editThe ISA Security Compliance Institute (ISCI), a wholly owned subsidiary of the ISA, created an industry consensus conformity assessment scheme that certifies to the ISA/IEC 62443 standards and operates under the ISASecure brand. This scheme is used to certify automation control systems, components and processes. ISASecure certifications were expanded to include the Industrial IOT component certification (ICSA) in December 2022. Certification Bodies in the ISASecure certification scheme are independently accredited by ISO 17011 Accreditation Bodies to the ISASecure technical readiness requirements and the ISO 17025 and ISO 17065 standards. Multilateral recognition agreements under the IAF ensure that the ISASecure certifications are mutually recognized by all global IAF signatories.
The ISCI offers multiple certifications under the ISASecure brand:
- SSA (System Security Assurance) certification of systems according to IEC 62443-3-3 and IEC 62443-4-1
- CSA (Component Security Assurance) certification of automation components according to IEC 62443-4-1 and IEC 62443-4-2
- ICSA (IIOT Component Security Assurance) certification of IIOT automation components according to IEC 62443-4-1 and IEC 62443-4-2 with four exceptions and seventeen extensions to the IEC 62443-4-2 standard to account for unique characteristics of IIOT components
- 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 was offered in 2010 and phased out when the IEC 62443-4-2 standard was formally approved and published in 2018.
- In 2023, ISASecure announced the development of a new certification for assessing and certifying automation and control systems in operation at asset owner sites. It is named the Automation and Control System Security Assurance (ACSSA) certification. It is slated for completion at the end of 2024.
See also
editReferences
edit- ^ IEC 62443-1-1, Industrial communication networks – Network and system security – Part 1-1: Terminology, concepts and models
- ^ a b IEC 62443-2-1:2024, Security for industrial automation and control systems - Part 2-1: Security program requirements for IACS asset owners
- ^ IEC 62443-3-1, Industrial communication networks – Network and system security – Part 3-1: Security technologies for industrial automation and control systems
- ^ a b IEC 62443-4-1, Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements
- ^ IEC 62443-2-3, Security for industrial automation and control systems – Part 2-3: Patch management in the IACS environment
- ^ IEC 62443-3-2, Security for industrial automation and control systems – Part 3-2: Security risk assessment for system design
- ^ a b IEC 62443-4-2, Security for industrial automation and control systems – Part 4-2: Technical security requirements for IACS components
- ^ a b IEC 62443-2-4:2023, Security for industrial automation and control systems – Part 2-4: Security program requirements for IACS service providers
- ^ IEC 62443-3-3, Industrial communication networks – Network and system security – Part 3-3: System security requirements and security levels