| Revision as of 03:51, 1 August 2024 editEccosman (talk | contribs)14 editsNo edit summary← Previous edit | Latest revision as of 02:37, 22 December 2024 edit undo2603:8080:e900:2af7:2048:8fe1:80fd:c215 (talk) →Current SituationTags: Mobile edit Mobile web edit | ||
| (27 intermediate revisions by 7 users not shown) | |||
| Line 1: | Line 1: | ||
| {{Short description|International cybersecurity standard}} | {{Short description|International cybersecurity standard}} | ||
| '''IEC 62443''' is a series of standards that address |
'''ISA/IEC 62443''' is a series of standards that address security for ] in ] and ]s. It is maintained as a collaboration between the of the and IEC WG10. | ||
| The series is divided into different sections and describes both technical and process-related requirements automation and control systems security. | |||
| It divides the cybersecurity topics by stakeholder category / roles including: | |||
| * the operator, | |||
| ⚫ | * the |
||
| * the component/system manufacturers. | |||
| ⚫ | The different roles each follow a risk-based approach to prevent and manage security risks in their activities. | ||
| == History == | == History == | ||
| ⚫ | In 2002, the ] (ISA), a professional automation engineering society and ANSI-accredited standards development organization (SDO) established a standards committee (ISA99), which went on to develop a multi-part series of standards and technical reports addressing the security of Automation and Control System cyber security. These work products were submitted by ISA for approval and then published as North American ] standards using the designation ''ANSI/ISA-99'' or ISA99 standards. | ||
| As an international standard, the IEC 62443 family of standards 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 family of standard. | |||
| In c. 2010 the ISA99 committee strengthened its relationship with IEC TC65 WG10, resulting in a renaming of the standards to ANSI/ISA-62443. The available content was submitted to and used by the IEC working groups. Since then, the series has been commonly referred to as ISA/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 == | |||
| ⚫ | |||
| ISA99 and IEC TC65 WG10 have strengthened and formalized their collaboration, creating a series of joint leadership and project teams to continue development of the standards in the 62443 series. The collaboration employs processes and procedures that conform to both the ISA Standards and Practices procedures and the IEC Directives. | |||
| In the ] (IEC) standards creation allows all national committees involved to agree upon a common standard. The development method in ISA is somewhat different, involving contributions from individual experts. Taken together, the combination of these methods produces standards that represent a broad view of common industry practice. | |||
| ⚫ | == Structure == | ||
| IEC 62443 ''Industrial communication networks - Network and system security'' series of standards is organized into four parts:<ref>{{Cite web |title=Understanding IEC 62443 |url=https://www.iec.ch/blog/understanding-iec-62443 |access-date=2022-09-02 |website=www.iec.ch |language=en}}</ref> | |||
| The resulting standards are published by ISA as ANSI/ISA 62443 and by IEC as IEC 62443. For a given part of the series the technical content of the ISA and IEC editions is identical. | |||
| # General: This part covers topics that are common to the entire series. | |||
| # Policies and Procedures: This part focuses on methods and processes associated with IACS security. | |||
| # System: This part is about requirements at the system level. | |||
| # Components and Requirements: This part provides detailed requirements for IACS products. | |||
| == Industry Application == | |||
| The following table lists the parts of the IEC 62443 series of standards published to date with their status and title. | |||
| ⚫ | The IEC has approved the ISA/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 ISA/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. | ||
| In ISA these standards have been viewed as "horizontal" since the ISA99 committee was formed. The scope of the series is described in terms of potential consequences of security incidents, and not as applying to specific industry sectors. | |||
| ⚫ | == Structure == | ||
| ISA/IEC 62443 ''Industrial communication networks - Network and system security'' series of standards is organized as per the following table: | |||
| {| class="wikitable" | {| class="wikitable" | ||
| |+ | |+ | ||
| Line 34: | Line 32: | ||
| ! colspan="3" |Components and Requirements | ! colspan="3" |Components and Requirements | ||
| |- | |- | ||
| |1-1 | |62443-1-1 | ||
| |Technical Specification, Edition 1.0, July 2009<ref></ref> | |Technical Specification, Edition 1.0, July 2009<ref></ref> | ||
| |Concepts and models | |Concepts and models | ||
| |2-1 | |62443-2-1 | ||
| |Edition |
|Edition 2.0, 2024<ref name=":0" /> | ||
| |Security program requirements for IACS asset owners | |Security program requirements for IACS asset owners | ||
| |3-1 | |62443-3-1 | ||
| |Technical Report, Edition 1.0, July 2009<ref></ref> | |Technical Report, Edition 1.0, July 2009<ref></ref> | ||
| |Security technologies for industrial automation and control systems ''(''IAC) | |Security technologies for industrial automation and control systems ''(''IAC) | ||
| |4-1 | |62443-4-1 | ||
| |Edition 1.0, January 2018<ref name=":1" /> | |Edition 1.0, January 2018<ref name=":1" /> | ||
| |Secure product development lifecycle requirements | |Secure product development lifecycle requirements | ||
| Line 50: | Line 48: | ||
| | | | | ||
| | | | | ||
| |2-3 | |62443-2-3 | ||
| |Technical Report, Edition 1.0, June 2015<ref></ref> | |Technical Report, Edition 1.0, June 2015<ref></ref> | ||
| |Patch management in the IACS environment | |Patch management in the IACS environment | ||
| |3-2 | |62443-3-2 | ||
| |Edition 1.0, June 2020<ref></ref> | |Edition 1.0, June 2020<ref></ref> | ||
| |Security risk assessment and system design | |Security risk assessment and system design | ||
| |4-2 | |62443-4-2 | ||
| |Edition 1.0, February 2019<ref name=":2" /> | |Edition 1.0, February 2019<ref name=":2" /> | ||
| |Technical security requirements for IACS components | |Technical security requirements for IACS components | ||
| Line 63: | Line 61: | ||
| | | | | ||
| | | | | ||
| |2-4 | |62443-2-4 | ||
| |Edition |
|Edition 2.0, December 2023<ref name=":3" /> | ||
| |Requirements for IACS service providers | |Requirements for IACS service providers | ||
| |3-3 | |62443-3-3 | ||
| |Edition 1.0, August 2013<ref></ref> | |Edition 1.0, August 2013<ref></ref> | ||
| |System security requirements and security levels | |System security requirements and security levels | ||
| | | | | ||
| Line 73: | Line 71: | ||
| | | | | ||
| |- | |- | ||
| |1-5 | |62443-1-5 | ||
| |Technical Specification, Edition 1.0, September 2023 | |Technical Specification, Edition 1.0, September 2023 | ||
| |Scheme for IEC 62443 security profiles | |Scheme for ISA/IEC 62443 security profiles | ||
| | | | | ||
| | | | | ||
| Line 86: | Line 84: | ||
| | | | | ||
| |} | |} | ||
| * 62443-1-1: 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. | |||
| * 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).<ref name=":0"></ref> | |||
| * |
* 62443-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).<ref name=":0"></ref> | ||
| * |
* 62443-2-4: 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.<ref name=":3"></ref> | ||
| * |
* 62443-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.<ref name=":1"></ref> | ||
| * 62443-4-2: This part defines technical requirements for products or components.<ref name=":2"></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 ISA/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 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 2 specifies that the technical requirements that the component cannot meet itself can be met by compensating countermeasures at system level (see ISA/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 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. | **CCSC 4 requires that the component is developed and supported by ISA/IEC 62443-4-1 compliant development processes. | ||
| == |
== Developments and Activities == | ||
| The standards in the ISA/IEC 62443 evolve constantly. Those published are updated with newer editions and additional standards are considered for inclusion. Developments in 2024 include: | |||
| 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 second edition of ISA/IEC 62443-2-1 (Security program requirements for asset owners) has been approved and published. | |||
| * Technical specification IEC 62443-6-1 was completed and published. | |||
| Several parts of the series are under revision or development: | |||
| * A second edition of 62443-1-1. The title has changed to "Overview and Guidance for the IEC 62443 Series." | |||
| * A first edition of 62443-1-6 (Applying the 62443 series to the industrial internet of things). | |||
| * A second edition of 62443-2-3 (Software update and patch management). | |||
| * A third edition of 62443-2-4 (Security program requirements for service providers). | |||
| * A new edition of 62443-3-1 (Use of security technologies) | |||
| * A second edition of 62443-3-2 (Security risk assessment for system design) | |||
| * A second edition of 62443-3-3 (Technical security requirements for systems) | |||
| * A second edition of 62443-4-1 (Secure product development lifecycle requirements) | |||
| * A second edition of 62443-4-2 (Technical security requirements for IACS components) | |||
| All of this work occurs in a collaboration between ISA99 and IEC TC65 WG10. | |||
| == Foundational Concepts == | |||
| There are several concepts that form the foundation of the ISA/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 === | === 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 109: | Line 136: | ||
| === Security Level === | === 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. | Technical requirements for systems (ISA/IEC 62443-3-3) and products (ISA/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 ISA/IEC 62443-1-1) and are not suitable for the general classification of products. | ||
| The levels are: | The levels are: | ||
| Line 116: | Line 143: | ||
| * 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. | ||
| == |
=== 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. | |||
| The standard explains various basic principles that should be considered for all roles in all activities. | |||
| ⚫ | 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. | ||
| === 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 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. | 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 ISA/IEC 62443. Many testing, inspection, and certification (TIC) companies offer product and process certifications based on ISA/IEC 62443. By accrediting according to the ISO/IEC 17000 series of standards, the companies share a single, consistent set of requirements for ISA/IEC 62443 certifications which elevates the usefulness of the resulting certificates of conformance. | ||
| === Accredited certification schemes === | === 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. |
ISA/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 ISA/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 management systems, products, services, and personnel accreditation or the ] for laboratory accreditation. A Multilateral Recognition Arrangement (MLA) between ABs will ensure global recognition of accredited CBs. | A global infrastructure of national accreditation bodies (AB) ensures consistent evaluation of the ISA/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. | ||
| 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. | 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 === | === 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 ISA/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 ISA/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 === | ||
| Line 151: | Line 172: | ||
| 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 and IEC 62443-4-1 | * SSA (System Security Assurance) certification of systems according to ISA/IEC 62443-3-3 and ISA/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 ISA/IEC 62443-4-1 and ISA/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 | * ICSA (IIOT Component Security Assurance) certification of IIOT automation components according to ISA/IEC 62443-4-1 and ISA/IEC 62443-4-2 with four exceptions and seventeen extensions to the ISA/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 ISA/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. | * 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 ISA/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. | * 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 163: | Line 183: | ||
| * ] | * ] | ||
| * ] | * ] | ||
| * ] | |||
| == References == | == References == | ||
Latest revision as of 02:37, 22 December 2024
International cybersecurity standardISA/IEC 62443 is a series of standards that address security for operational technology in automation and control systems. It is maintained as a collaboration between the ISA99 committee of the International Society for Automation and IEC TC65 WG10.
The series is divided into different sections and describes both technical and process-related requirements 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), which went on to develop a multi-part series of standards and technical reports addressing the security of Automation and Control System 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.
In c. 2010 the ISA99 committee strengthened its relationship with IEC TC65 WG10, resulting in a renaming of the standards to ANSI/ISA-62443. The available content was submitted to and used by the IEC working groups. Since then, the series has been commonly referred to as ISA/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
ISA99 and IEC TC65 WG10 have strengthened and formalized their collaboration, creating a series of joint leadership and project teams to continue development of the standards in the 62443 series. The collaboration employs processes and procedures that conform to both the ISA Standards and Practices procedures and the IEC Directives.
In the International Electrotechnical Commission (IEC) standards creation allows all national committees involved to agree upon a common standard. The development method in ISA is somewhat different, involving contributions from individual experts. Taken together, the combination of these methods produces standards that represent a broad view of common industry practice.
The resulting standards are published by ISA as ANSI/ISA 62443 and by IEC as IEC 62443. For a given part of the series the technical content of the ISA and IEC editions is identical.
Industry Application
The IEC has approved the ISA/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 ISA/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.
In ISA these standards have been viewed as "horizontal" since the ISA99 committee was formed. The scope of the series is described in terms of potential consequences of security incidents, and not as applying to specific industry sectors.
Structure
ISA/IEC 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 | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 62443-1-1 | Technical Specification, Edition 1.0, July 2009 | Concepts and models | 62443-2-1 | Edition 2.0, 2024 | Security program requirements for IACS asset owners | 62443-3-1 | Technical Report, Edition 1.0, July 2009 | Security technologies for industrial automation and control systems (IAC) | 62443-4-1 | Edition 1.0, January 2018 | Secure product development lifecycle requirements |
| 62443-2-3 | Technical Report, Edition 1.0, June 2015 | Patch management in the IACS environment | 62443-3-2 | Edition 1.0, June 2020 | Security risk assessment and system design | 62443-4-2 | Edition 1.0, February 2019 | Technical security requirements for IACS components | |||
| 62443-2-4 | Edition 2.0, December 2023 | Requirements for IACS service providers | 62443-3-3 | Edition 1.0, August 2013 | System security requirements and security levels | ||||||
| 62443-1-5 | Technical Specification, Edition 1.0, September 2023 | Scheme for ISA/IEC 62443 security profiles | |||||||||
- 62443-1-1: 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.
- 62443-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).
- 62443-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.
- 62443-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.
- 62443-4-2: 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 ISA/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 ISA/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 ISA/IEC 62443-4-1 compliant development processes.
Developments and Activities
The standards in the ISA/IEC 62443 evolve constantly. Those published are updated with newer editions and additional standards are considered for inclusion. Developments in 2024 include:
- The second edition of ISA/IEC 62443-2-1 (Security program requirements for asset owners) has been approved and published.
- Technical specification IEC 62443-6-1 was completed and published.
Several parts of the series are under revision or development:
- A second edition of 62443-1-1. The title has changed to "Overview and Guidance for the IEC 62443 Series."
- A first edition of 62443-1-6 (Applying the 62443 series to the industrial internet of things).
- A second edition of 62443-2-3 (Software update and patch management).
- A third edition of 62443-2-4 (Security program requirements for service providers).
- A new edition of 62443-3-1 (Use of security technologies)
- A second edition of 62443-3-2 (Security risk assessment for system design)
- A second edition of 62443-3-3 (Technical security requirements for systems)
- A second edition of 62443-4-1 (Secure product development lifecycle requirements)
- A second edition of 62443-4-2 (Technical security requirements for IACS components)
All of this work occurs in a collaboration between ISA99 and IEC TC65 WG10.
Foundational Concepts
There are several concepts that form the foundation of the ISA/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 (ISA/IEC 62443-3-3) and products (ISA/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 ISA/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 ISA/IEC 62443. Many testing, inspection, and certification (TIC) companies offer product and process certifications based on ISA/IEC 62443. By accrediting according to the ISO/IEC 17000 series of standards, the companies share a single, consistent set of requirements for ISA/IEC 62443 certifications which elevates the usefulness of the resulting certificates of conformance.
Accredited certification schemes
ISA/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 ISA/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 ISA/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 ISA/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 ISA/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 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 ISA/IEC 62443-3-3 and ISA/IEC 62443-4-1
- CSA (Component Security Assurance) certification of automation components according to ISA/IEC 62443-4-1 and ISA/IEC 62443-4-2
- ICSA (IIOT Component Security Assurance) certification of IIOT automation components according to ISA/IEC 62443-4-1 and ISA/IEC 62443-4-2 with four exceptions and seventeen extensions to the ISA/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 ISA/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 ISA/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
- ISA/IEC 62443-1-1, Industrial communication networks – Network and system security – Part 1-1: Terminology, concepts and models
- ^ ISA/IEC 62443-2-1:2024, Security for industrial automation and control systems - Part 2-1: Security program requirements for IACS asset owners
- ISA/IEC 62443-3-1, Industrial communication networks – Network and system security – Part 3-1: Security technologies for industrial automation and control systems
- ^ ISA/IEC 62443-4-1, Security for industrial automation and control systems – Part 4-1: Secure product development lifecycle requirements
- ISA/IEC 62443-2-3, Security for industrial automation and control systems – Part 2-3: Patch management in the IACS environment
- ISA/IEC 62443-3-2, Security for industrial automation and control systems – Part 3-2: Security risk assessment for system design
- ^ ISA/IEC 62443-4-2, Security for industrial automation and control systems – Part 4-2: Technical security requirements for IACS components
- ^ ISA/IEC 62443-2-4:2023, Security for industrial automation and control systems – Part 2-4: Security program requirements for IACS service providers
- ISA/IEC 62443-3-3, Industrial communication networks – Network and system security – Part 3-3: System security requirements and security levels