A Guide to Protecting Industrial Automation and Control Systems with the IEC 62443

What is the IEC 62443 standard series?

The ISA/IEC 62443 standard series, developed by the International Society of Automation (ISA) ISA99 committee, and adopted by the International Electrotechnical Commission (IEC), was purpose-built to address security issues in Industrial Automation and Control Systems (IACS). It offers a family of documents that describes a defense-in-depth strategy for the security of IACS, including how to build a cybersecurity management system (CSMS), perform risk assessment, manage the supply chain, or the security and technical requirements of industrial systems and components. The IEC 62443 series is structured into four sections; General, Policies and Procedures, System, and Component.

In its first part (1-1), the standard defines the terminology, concepts, and models for IACS, as well as seven Foundational Requirements (FR), which are referenced throughout the entire series:

Identification and Authentication Control.
Use Control.
System Integrity.
Data Confidentiality.
Restricted Data Flow.
Timely Response to Events.
Resource Availability.

For each of these foundational requirements, there are a number of technical system requirements (SR) or component requirements (CR), along with requirement enhancements (RE) that are assigned to four security levels (SL) representing the appropriate level of threat mitigation for the system or components.

The IEC 62443 is growing in popularity and becoming the gold standard in guiding the development of IACS systems to be secure by design. These guidelines aim at a holistic and integrated approach to security by covering the following items:

Building a security program for site owners,
Security lifecycle management for processes and products, and supply chain management.
Performing risk assessment and building a vulnerability management program,
Security controls and protective capabilities,
Segmenting and securing networks (via zones and conduits) as well as putting in a particular focus on roles and responsibilities (for users or resources),
Detailed technical requirements, along with the concept of security maturity levels for more flexibility.

Its broad applicability

The IEC 62443 is the reference for cybersecurity in a range of domain areas in IACS and operational technology, including manufacturing, transportation, oil & gas, the health industry, etc. There are also a number of standards specifically tailored to certain domain areas that are derived from the IEC 62443, e.g., The CLC/TS 50701 in railways or the IEC 60601-4-5 for medical devices. The following table provides a few examples of IEC 62443-certified companies and their industry.

Table 1. The IEC 62443’s broad applicability.

IEC 62443 certified organization	Industry
Schneider Electric	Digital automation and energy management
Otis	Elevators, escalators, moving walkways, and related equipment
Valmet	Digital automation for manufacturing and energy
Johnson Controls	Smart buildings
Honeywell	Digital automation for transportation, energy, healthcare, urbanization, etc.
Siemens	Industrial manufacturing and automation solutions in a wide range of industries, including smart mobility, energy, and healthcare
Eurotech	Edge computing systems for IIoT
Cisco	Networking devices, and cloud/security solutions

Build an IACS cybersecurity program with the IEC 62443

Organizations need to use a structured approach and well-defined processes to ensure it is secure and resilient to cyber threats. The IEC 62443 standard series provides a holistic approach that englobes all aspects (People, Process, and Technology) needed to build a security strategy and program. The standard’s documents cover a lot of ground providing recommendations and guidelines to both service providers and asset owners. Part 2-1 of the standard defines the elements necessary to establish a cybersecurity management system (CSMS) for asset owners.

Similar to an ISMS in information security, the CSMS covers processes used to identify the organization's assets, services, and functions, assess related risks, determine the necessary protections, and monitor and approve those processes. The focus is, however, slightly different, with more emphasis on protecting physical assets and the availability of the system. Part 3-2 of the standard establishes requirements for risk assessment with respect to the system, its partition (zone and conduits), and appropriate security levels. For vendors/service providers, part 2-4 specifies requirements and security capabilities that can be used during the integration of automation solutions and maintenance activities. The requirements for the secure development of products are defined in part 4-1. It includes secure design and implementation (including coding guidelines), verification and validation, product end-of-life, among others.

Assuming the security program has been established and is being operated in accordance with part 2‐1, detailed technical requirements for control systems and components are provided in parts 3-3 and 4-2. Part 3-3 defines control system requirements, which are expanded by part 4-2 into a series of component-level requirements, covering embedded devices, network components, host components, and software applications. These two portions of the IEC 62443 series align with one another. At this stage, it is also assumed that patch/vulnerability management is implemented according to the recommendations detailed in part 2‐3.

The IEC 62443 series provides a wide-ranging framework to address current and future security issues in IACS and apply necessary mitigations. The intention is also to build extensions to enterprise security that adapt and combine the requirements for business IT systems with the unique requirements necessary for the strong availability needed in IACS.

Getting started with threat modeling using the IEC 62443

Part 4-1 of the standard (secure product development life-cycle requirements) defines threat modeling guidance as part of the ‘specification of the security requirements’ practice. It states that ‘a process shall be employed to ensure that all products shall have a threat model’. The guidance specifically mentions the following characteristics to take into consideration (Table 2).

Table 2. Threat modeling guidance in the IEC 62443-4-1.

Characteristic	Description
Dataflows	The flow of information (source & destination) throughout the system.
Trust boundaries	Zones of trust and boundaries at appropriate levels; process, plant, corporate, internet, cloud, etc.
Processes	Type of running processes; upload/download, OEM processes or connections, etc.
Data stores	Plant control data, telemetry, backups, identity data, etc.
Third-party interactions	Define all interactions with external entities and processes, e.g., for updates or maintenance.
Communication protocols	What protocols are parts of internal and external communications; FTP, Telnet, SSH, RDP, Modbus, etc.
Physical connectivity	What externally accessible physical ports/interfaces, including debug ports.
Threats and attack vectors	What potential threats are relevant to the system, and what methods or vulnerabilities can be used to achieve that.
Mitigations	Defined in parts 3-3 and 4-2 (SRs and CRs, respectively).
Security-related issues	Other potential security issues, including physical or governance.
Dependencies and supply chain	What third-party applications are used (e.g., refer to "Software Bill Of Materials" - SBOM).

Using IriusRisk to threat model with the IEC 62443

All of the characteristics described in the IEC 62443 threat modeling methodology can be modeled in IriusRisk, along with the full coverage of the controls in parts 3-3 and 4-2, which define the technical requirements for systems and components, for each of the seven foundational requirements. Table 3 gives an example set of SRs, for FR1. IriusRisk has also mapped these requirements to a range of components, such as controllers, sensors, actuators, HMI, networking devices, etc. Figure 2 presents an example of a threat model of a generic plant architecture using a few IEC 62443 components in IriusRisk, in addition to interactions with external systems including the AWS cloud. Security requirements are then automatically generated. The threat view in Figure 2 shows part of the security requirements of the HMI PCB component.

Table 3. Example system requirements, for FR1.

Figure 2. Example threat model with the IEC 62443.

IriusRisk already supports a number of industrial organizations to secure their critical systems and components against attacks. We look forward to the opportunity to share more information about the platform and its content, including the IEC 62443 as well as MITRE ATT&CK for ICS.