Revision as of 22:30, 16 December 2021 editConan (talk | contribs)Extended confirmed users2,323 editsm Aready in Category:Computer security standards← Previous edit | Latest revision as of 12:51, 27 December 2024 edit undoMmu12345 (talk | contribs)16 edits Fix naming. IEC 62443 is an international standard published by IEC without the addition of ISA.Tag: Visual edit | ||
(81 intermediate revisions by 38 users not shown) | |||
Line 1: | Line 1: | ||
{{Short description|International cybersecurity standard}} | |||
{{Short description|cybersecurity standard}}'''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. | |||
'''IEC 62443''' is a series of standards that address security for ] in ] and ]. The series is divided into different sections and describes both technical and process-related aspects of automation and control systems security. | |||
== History == | |||
In 2002, the ] (ISA), a professional automation engineering society and ]-accredited standards development organization (SDO) established a standards committee (ISA99). This committee developed a multi-part series of standards and technical reports addressing the cybersecurity of Automation and Control Systems. These standards were initially published as ''ANSI/ISA-99'' or ''ISA99'' standards. | |||
Around 2010, ISA99 strengthened its relationship with the ] (IEC), leading to the renaming of the standards to ''ANSI/ISA-62443''. The available content was submitted to and used by IEC working groups. Since then, the series has been commonly referred to as IEC 62443. | |||
Meanwhile, the German engineering associations ] and ] released the ''VDI/VDE 2182'' guidelines in 2011. The guidelines describe how to handle ] in industrial automation environments and were also submitted to and used by the IEC working groups. | |||
== Current Situation == | |||
The IEC 62443 series of standards is maintained by the ] Technical Committee 65 Working Group 10 (IEC TC65 WG10). The IEC working group and ISA99 committee continue to collaborate, creating joint leadership and project teams to develop the standards in the IEC 62443 series. Their collaboration integrates the processes and procedures of both ISA and IEC Directives, ensuring alignment in the development process. | |||
The resulting standards are published by ISA as ANSI/ISA 62443 in the United States and by IEC as IEC 62443 internationally. For any given part of the series, the technical content of the ISA and IEC editions is identical where both organizations have accepted the content. | |||
== Relationship between IEC and ISA == | |||
The relationship between IEC and ISA in the development of the IEC 62443 series is characterized by complementary roles. IEC serves as the global standardization body responsible for publishing and maintaining the IEC 62443 series, while ISA contributes significant technical expertise, industry insight, and foundational drafts through its ISA99 committee. | |||
ISA primarily focuses on the U.S. market and publishes standards under the ANSI/ISA 62443 designation. IEC, on the other hand, ensures global adoption and harmonization of the standards as IEC 62443. | |||
While both organizations collaborate on the majority of standards, they retain the independence to develop and publish standards separately when consensus cannot be reached. For example, IEC developed and published IEC 62443-6-1<ref name=":4" /> independently without ISA involvement. | |||
== Industry Application == | |||
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 security in those standards. This approach serves to avoid the proliferation of partial and/or conflicting requirements for addressing security of automation and control systems across industry sectors where the same or similar technology or products are deployed at operating sites. | |||
== Structure == | == Structure == | ||
IEC 62443 ''Industrial communication networks - Network and system security'' series of standards consists of several parts, which are divided into six areas: | |||
# General: Parts in this category describe the basic terms, concepts and models. | |||
The IEC 62443 Industrial communication networks - Network and system security series of standards consists of the following parts: | |||
# Policies and Procedures: This primarily describes a system for managing industrial IT security. | |||
* Part 1-1: Terminology, concepts and models (Technical Specification, Edition 1.0, July 2009)<ref></ref> | |||
# System: Various specifications for security functions of control and automation systems are described here. | |||
* 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).<ref></ref> | |||
# Components and Requirements: The requirements for product development processes for components of an automation solution are described here. | |||
# Profiles:This section is intended to define industry-specific cybersecurity requirements and provide a structured approach to implementing measures based on the cybersecurity profiles described in IEC 62443-1-5. | |||
# Evaluation: This section describes assessment methodologies that ensure that assessment results are consistent and reproducible with regard to the requirements of the individual parts. | |||
The following table lists the parts of the IEC 62443 series of standards published to date with their status and title. | |||
* Part 2-3: Patch management in the IACS environment (Technical Report, Edition 1.0, June 2015)<ref></ref> | |||
{| class="wikitable" | |||
* 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.<ref></ref> | |||
|+ | |||
!Standard | |||
!Title | |||
!Status | |||
!Description | |||
|- | |||
|IEC 62443-1-1 | |||
|Concepts and models | |||
|Technical Specification, Edition 1.0, July 2009<ref>{{Cite web |title=IEC TS 62443-1-1:2009 |url=https://webstore.iec.ch/en/publication/7029 |access-date=2024-12-27 |website=webstore.iec.ch |language=en}}</ref> | |||
|This standard introduces the set of main cybersecurity elements (e.g., terms, figures, requirements, and concepts) that apply across the series and notably those that appear in two or more parts of the series. | |||
|- | |||
|IEC 62443-1-5 | |||
|Scheme for IEC 62443 security profiles | |||
|Technical Specification, Edition 1.0, September 2023<ref>{{Cite web |title=IEC TS 62443-1-5:2023 |url=https://webstore.iec.ch/en/publication/67461 |access-date=2024-12-27 |website=webstore.iec.ch |language=en}}</ref> | |||
| | |||
|- | |||
|IEC 62443-2-1 | |||
|Security program requirements for IACS asset owners | |||
|Edition 2.0, 2024<ref name=":0">{{Cite web |title=IEC 62443-2-1:2024 |url=https://webstore.iec.ch/en/publication/62883 |access-date=2024-12-27 |website=webstore.iec.ch |language=en}}</ref> | |||
|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). | |||
|- | |||
|IEC 62443-2-3 | |||
|Patch management in the IACS environment | |||
|Technical Report, Edition 1.0, June 2015<ref>{{Cite web |title=IEC TR 62443-2-3:2015 |url=https://webstore.iec.ch/en/publication/22811 |access-date=2024-12-27 |website=webstore.iec.ch |language=en}}</ref> | |||
| | |||
|- | |||
|IEC 62443-2-4 | |||
|Requirements for IACS service providers | |||
|Edition 2.0, December 2023<ref name=":3">{{Cite web |title=IEC 62443-2-4:2023 |url=https://webstore.iec.ch/en/publication/67631 |access-date=2024-12-27 |website=webstore.iec.ch |language=en}}</ref> | |||
|This part defines requirements ("capabilities") for integrators. These requirements are divided into 12 topics: Assurance, architecture, wireless, security engineering systems, ], remote access, ], user management, malware protection, ], backup & recovery, and project staffing. | |||
|- | |||
|IEC 62443-3-1 | |||
|Security technologies for industrial automation and control systems | |||
|Technical Report, Edition 1.0, July 2009<ref>{{Cite web |title=IEC TR 62443-3-1:2009 |url=https://webstore.iec.ch/en/publication/7031 |access-date=2024-12-27 |website=webstore.iec.ch |language=en}}</ref> | |||
| | |||
|- | |||
|IEC 62443-3-2 | |||
|Security risk assessment and system design | |||
|Edition 1.0, June 2020<ref>{{Cite web |title=IEC 62443-3-2:2020 |url=https://webstore.iec.ch/en/publication/30727 |access-date=2024-12-27 |website=webstore.iec.ch |language=en}}</ref> | |||
| | |||
|- | |||
|IEC 62443-3-3 | |||
|System security requirements and security levels | |||
|Edition 1.0, August 2013<ref>{{Cite web |title=IEC 62443-3-3:2013 |url=https://webstore.iec.ch/en/publication/7033 |access-date=2024-12-27 |website=webstore.iec.ch |language=en}}</ref> | |||
| | |||
|- | |||
|IEC 62443-4-1 | |||
|Secure product development lifecycle requirements | |||
|Edition 1.0, January 2018<ref name=":1">{{Cite web |title=IEC 62443-4-1:2018 |url=https://webstore.iec.ch/en/publication/33615 |access-date=2024-12-27 |website=webstore.iec.ch |language=en}}</ref> | |||
|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. | |||
|- | |||
|IEC 62443-4-2 | |||
|Technical security requirements for IACS components | |||
|Edition 1.0, February 2019<ref name=":2">{{Cite web |title=IEC 62443-4-2:2019 |url=https://webstore.iec.ch/en/publication/34421 |access-date=2024-12-27 |website=webstore.iec.ch |language=en}}</ref> | |||
|This part 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. | |||
|- | |||
|IEC 62443-6-1 | |||
|Security evaluation methodology for IEC 62443-2-4 | |||
|Technical Specification, Edition 1.0, March 2024<ref name=":4">{{Cite web |title=IEC TS 62443-6-1:2024 |url=https://webstore.iec.ch/en/publication/67462 |access-date=2024-12-27 |website=webstore.iec.ch |language=en}}</ref> | |||
|} | |||
== Developments and Activities == | |||
* Part 3-1: Security technologies for industrial automation and control systems (Technical Report, Edition 1.0, July 2009)<ref></ref> | |||
The standards in the IEC 62443 series of standards evolve constantly. According to IEC guidelines, all published standards will be periodically reviewed and either be confirmed to be current, updated (resulting in a new edition), or withdrawn.In addition, several parts of the series are under development<ref>{{Cite web |title=TC 65 Project Plans |url=https://www.iec.ch/dyn/www/f?p=103:262:702462499434137::::FSP_ORG_ID,FSP_LANG_ID:1250,25}}</ref>, including new editions of: | |||
* Part 3-2: Security risk assessment for system design (International Standard, Edition 1.0, June 2020)<ref></ref> | |||
* 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.<ref></ref> | |||
* IEC 62443-1-6: Applying the 62443 series to the industrial internet of things | |||
* 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.<ref></ref> | |||
* IEC 62443-2-2: IACS Security Protection | |||
* IEC 62443-6-2: Evaluation Methodology for IEC 62443-4-2 | |||
== Foundational Concepts == | |||
* 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.<ref></ref> 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: | |||
There are several concepts that form the foundation of the IEC 62443 series. | |||
**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. | |||
=== Principal Roles === | |||
== Maturity and Security Level == | |||
Standards in the series addresses the implications for several principal roles, including: | |||
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. | |||
* 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. | |||
=== Maturity Level === | === Maturity Level === | ||
The standards describe 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: | The maturity levels are described as follows: | ||
Line 43: | Line 137: | ||
* Security Level 1: Protection against unintentional or accidental misuse. | * 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 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, |
* Security Level 3: Protection against intentional misuse by sophisticated means with moderate resources, automation-specific knowledge and moderate motivation. | ||
* Security Level 4: Protection against intentional misuse using sophisticated means with extensive resources, |
* Security Level 4: Protection against intentional misuse using sophisticated means with extensive resources, automation-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. | |||
=== |
=== System Segmentation === | ||
Application of this concept involves grouping the systems and components of the automation and control system into a set of zones and 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. | 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. | 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. | ||
== |
== Conformance certification == | ||
Processes, systems and products used in |
Processes, systems and products used in automation and control environments can be certified as conforming 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 requirements for IEC 62443 certifications which elevates the usefulness of the resulting certificates of conformance. | ||
=== Accredited |
=== Accredited certification schemes === | ||
IEC 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. Security certification programs for IEC 62443 standards are being offered globally by many recognized Certification Bodies (CB), including ], ], ], ] and ]. | |||
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 ] for work in ], products, services, and personnel accreditation or the ] for laboratory accreditation. A Multilateral Recognition Arrangement (MLA) between ABs will ensure global recognition of accredited CBs. | |||
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 ], ], ] and ]. | |||
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. | |||
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 === | === IECEE CB Scheme === | ||
The IEC System for Conformity Assessment Schemes for Electrotechnical Equipment and Components (]) Certification Body 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 IEC System for Conformity Assessment Schemes for Electrotechnical Equipment and Components (]) Certification Body 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. | 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 === | === ISCI ISASecure === | ||
The |
The ISA Security Compliance Institute (ISCI), a wholly owned subsidiary of the ISA, created an industry consensus conformity assessment scheme that certifies to the 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: | The ISCI offers multiple certifications under the ISASecure brand: | ||
* SSA (System Security Assurance) certification of systems according to IEC 62443-3-3 | * 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 | * 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 | * 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 |
* 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 == | == See also == | ||
Line 86: | Line 177: | ||
* ] | * ] | ||
* ] | * ] | ||
* ] | |||
== References == | == References == |
Latest revision as of 12:51, 27 December 2024
International cybersecurity standardIEC 62443 is a series of standards that address security 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 security.
History
In 2002, the International Society of Automation (ISA), a professional automation engineering society and ANSI-accredited standards development organization (SDO) established a standards committee (ISA99). This committee developed a multi-part series of standards and technical reports addressing the cybersecurity of Automation and Control Systems. These standards were initially published as ANSI/ISA-99 or ISA99 standards.
Around 2010, ISA99 strengthened its relationship with the International Electrotechnical Commission (IEC), leading to the renaming of the standards to ANSI/ISA-62443. The available content was submitted to and used by IEC working groups. Since then, the series has been commonly referred to as IEC 62443.
Meanwhile, 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.
Current Situation
The IEC 62443 series of standards is maintained by the International Electrotechnical Commission (IEC) Technical Committee 65 Working Group 10 (IEC TC65 WG10). The IEC working group and ISA99 committee continue to collaborate, creating joint leadership and project teams to develop the standards in the IEC 62443 series. Their collaboration integrates the processes and procedures of both ISA and IEC Directives, ensuring alignment in the development process.
The resulting standards are published by ISA as ANSI/ISA 62443 in the United States and by IEC as IEC 62443 internationally. For any given part of the series, the technical content of the ISA and IEC editions is identical where both organizations have accepted the content.
Relationship between IEC and ISA
The relationship between IEC and ISA in the development of the IEC 62443 series is characterized by complementary roles. IEC serves as the global standardization body responsible for publishing and maintaining the IEC 62443 series, while ISA contributes significant technical expertise, industry insight, and foundational drafts through its ISA99 committee.
ISA primarily focuses on the U.S. market and publishes standards under the ANSI/ISA 62443 designation. IEC, on the other hand, ensures global adoption and harmonization of the standards as IEC 62443.
While both organizations collaborate on the majority of standards, they retain the independence to develop and publish standards separately when consensus cannot be reached. For example, IEC developed and published IEC 62443-6-1 independently without ISA involvement.
Industry Application
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 security in those standards. This approach serves to avoid the proliferation of partial and/or conflicting requirements for addressing security of automation and control systems across industry sectors where the same or similar technology or products are deployed at operating sites.
Structure
IEC 62443 Industrial communication networks - Network and system security series of standards consists of several parts, which are divided into six areas:
- General: Parts in this category describe the basic terms, concepts and models.
- Policies and Procedures: This primarily describes a system for managing industrial IT security.
- System: Various specifications for security functions of control and automation systems are described here.
- Components and Requirements: The requirements for product development processes for components of an automation solution are described here.
- Profiles:This section is intended to define industry-specific cybersecurity requirements and provide a structured approach to implementing measures based on the cybersecurity profiles described in IEC 62443-1-5.
- Evaluation: This section describes assessment methodologies that ensure that assessment results are consistent and reproducible with regard to the requirements of the individual parts.
The following table lists the parts of the IEC 62443 series of standards published to date with their status and title.
Standard | Title | Status | Description |
---|---|---|---|
IEC 62443-1-1 | Concepts and models | Technical Specification, Edition 1.0, July 2009 | This standard introduces the set of main cybersecurity elements (e.g., terms, figures, requirements, and concepts) that apply across the series and notably those that appear in two or more parts of the series. |
IEC 62443-1-5 | Scheme for IEC 62443 security profiles | Technical Specification, Edition 1.0, September 2023 | |
IEC 62443-2-1 | Security program requirements for IACS asset owners | Edition 2.0, 2024 | 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). |
IEC 62443-2-3 | Patch management in the IACS environment | Technical Report, Edition 1.0, June 2015 | |
IEC 62443-2-4 | Requirements for IACS service providers | Edition 2.0, December 2023 | 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. |
IEC 62443-3-1 | Security technologies for industrial automation and control systems | Technical Report, Edition 1.0, July 2009 | |
IEC 62443-3-2 | Security risk assessment and system design | Edition 1.0, June 2020 | |
IEC 62443-3-3 | System security requirements and security levels | Edition 1.0, August 2013 | |
IEC 62443-4-1 | Secure product development lifecycle requirements | Edition 1.0, January 2018 | 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. |
IEC 62443-4-2 | Technical security requirements for IACS components | Edition 1.0, February 2019 | This part 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:
|
IEC 62443-6-1 | Security evaluation methodology for IEC 62443-2-4 | Technical Specification, Edition 1.0, March 2024 |
Developments and Activities
The standards in the IEC 62443 series of standards evolve constantly. According to IEC guidelines, all published standards will be periodically reviewed and either be confirmed to be current, updated (resulting in a new edition), or withdrawn.In addition, several parts of the series are under development, including new editions of:
- IEC 62443-1-6: Applying the 62443 series to the industrial internet of things
- IEC 62443-2-2: IACS Security Protection
- IEC 62443-6-2: Evaluation Methodology for IEC 62443-4-2
Foundational Concepts
There are several concepts that form the foundation of the IEC 62443 series.
Principal Roles
Standards in the series addresses the implications for several principal roles, 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.
Maturity Level
The standards describe 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, automation-specific knowledge and moderate motivation.
- Security Level 4: Protection against intentional misuse using sophisticated means with extensive resources, automation-specific knowledge and high motivation.
System Segmentation
Application of this concept involves grouping the systems and components of the automation and control system into a set of zones and 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.
Conformance certification
Processes, systems and products used in automation and control environments can be certified as conforming 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 requirements for IEC 62443 certifications which elevates the usefulness of the resulting certificates of conformance.
Accredited certification schemes
IEC 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. Security 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
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 ISA Security Compliance Institute (ISCI), a wholly owned subsidiary of the ISA, created an industry consensus conformity assessment scheme that certifies to the 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
- Cybersecurity standards
- Functional safety
- International Electrotechnical Commission
- Cyber Security Management System
References
- ^ "IEC TS 62443-6-1:2024". webstore.iec.ch. Retrieved 2024-12-27.
- "IEC TS 62443-1-1:2009". webstore.iec.ch. Retrieved 2024-12-27.
- "IEC TS 62443-1-5:2023". webstore.iec.ch. Retrieved 2024-12-27.
- "IEC 62443-2-1:2024". webstore.iec.ch. Retrieved 2024-12-27.
- "IEC TR 62443-2-3:2015". webstore.iec.ch. Retrieved 2024-12-27.
- "IEC 62443-2-4:2023". webstore.iec.ch. Retrieved 2024-12-27.
- "IEC TR 62443-3-1:2009". webstore.iec.ch. Retrieved 2024-12-27.
- "IEC 62443-3-2:2020". webstore.iec.ch. Retrieved 2024-12-27.
- "IEC 62443-3-3:2013". webstore.iec.ch. Retrieved 2024-12-27.
- "IEC 62443-4-1:2018". webstore.iec.ch. Retrieved 2024-12-27.
- "IEC 62443-4-2:2019". webstore.iec.ch. Retrieved 2024-12-27.
- "TC 65 Project Plans".