The Ultimate Guide to Protecting OT Systems with IEC 62443

What is IEC 62443?

While many cyber security standards enjoy success in enterprise IT environments, the ISA/IEC 62443 standards were purpose-built to address security issues unique to industrial automation and control systems (IACS) and operational technology (OT). As such, they can be an extremely valuable resource for organizations looking to strengthen defenses and corral risk in specialized industrial systems.

Unlike the more general NIST Cybersecurity Framework (CSF) or ISO 2700x guidelines, ISA/IEC 62443 (IEC 62443, for short) provides a series of requirements and methods to manage security challenges in IACS and industrial environments.  Such challenges include:

• The relative criticality of data confidentiality in facilities operations or functions.
• Potential dangers to personnel, the environment, and society in the event of cyber-physical failures.
• The increased need for compensating controls to protect legacy IACS/OT systems.
• The relative difficulty of applying common IT security techniques without severe systems modifications.
• Prospects for financial loss due to an incident-related drop in productivity.
• Unique approaches to ensuring systems reliability and integrity in industrial environments.

Originally developed by the International Society of Automation (ISA) ISA 99 standards committee and adopted by the International Electrotechnical Commission (IEC), these non-regulated standards are consensus-based. The standards body regularly consults IACS security experts were to maintain relevant guidance that applies to all industry sectors and critical infrastructure.

The result is a family of documents that illustrates a defense-in-depth model via “zones” and “conduits,” describes how to build a cybersecurity management system (CSMS), and offers instruction for performing risk assessments in IACS/OT environments. The IEC 62443 helps organizations define IACS security maturity and posture and offers selection criteria security products, programs and service providers. IEC 62443’s core guidance is also routinely supplemented with technical reports covering specific technological situations and solutions.

The IEC 62443 documents are structured into a multi-tier grouping of four layers.

The four logical groupings and their associated contents include:

• General: Introductory information, vocabularies, concepts, and example use cases.
• Policies and Procedures: Program requirements, patching, implementation guidance, etc.
• System: Assessment approaches, security requirements levels and technologies.
• Component: Product lifecycle and technical requirements for components used within a system.

The ISA/IEC 62443 standards do not directly supersede nor replace the ISA95 and Purdue models.  Instead, they leverage previous concepts, and divide security and management of cyber risk into several areas. These cover not only cyber security reference architectures, but also guidance for security processes, requirements, technology, controls, security acceptance/factory testing, product development, security lifecycles, and a cybersecurity management system (CSMS).

The 62443 standards reach beyond ISA95 in terms of coverage, cybersecurity and modern concepts, but ISA95 and the Purdue models may still have value for organizations that have specific security requirements, for example when Industrial Internet of Things (IIoT) devices are connected directly to the Internet or the cloud.

Focus on Basics: The IEC 62443 Checklist

IEC 62443 was purpose-built to guide the development of IACS components to be secure-by-design and to be governed by an OT/IACS-centric security management system that has policies, procedures, periodic review, specific requirements and instill best practices. However, its hefty, comprehensive collection contains many documents and a trove of information that can be intimidating to new users. To get started, focus on these core document:

ISA/IEC 62443-1-1: Security for Industrial Automation and Control Systems Part 1-1: Terminology, Concepts, and Models

Defines IACS as a “collection of processes, personnel, hardware, and software that can affect or influence the safe, secure and reliable operation of an industrial process.”  This document establishes the fundamental taxonomy and basic concepts for the standards collection at large and should be read first before diving into the other standards components.

ISA/IEC 62443-2-4: Security for Industrial Automation and Control Systems – Part 2-4: Security Program Requirements for IACS Service Providers

Specifies a comprehensive set of requirements covering IACS service providers that can be used during integration and maintenance activities.  It also provides the basis for a larger IEC 62443 initiative to develop “profiles” that address the nuances and realities in different industrial environments, for example, the unique requirements of oil and gas producers versus those of electricity generation and distribution.

ISA/IEC 62443-4-2: Security for Industrial Automation and Control Systems: Technical Security Requirements for IACS Components

Provides the cybersecurity technical requirements for components that make up an IACS, specifically the embedded devices, network components, host components, and software applications. The standard sets forth security capabilities that enable a component to mitigate threats for a given security level without the assistance of compensating countermeasures.

ISA/IEC 62443-4-1: Product Security Development Life-Cycle Requirements

Specifies process requirements for the secure development of products used in an IACS and defines a secure development lifecycle for developing and maintaining secure products. The lifecycle includes security requirements definition, secure design, secure implementation (including coding guidelines), verification and validation, defect management, patch management, and product end-of-life.

These requirements can be applied to new or existing processes for developing, maintaining, and retiring hardware, software, or firmware. Mostly aimed at developers and vendors, the ISA-62443-4-1 lifecycle requirements can also apply to integrators handling systems creation, implementation, and maintenance.

ISA/IEC 62443-3-2:  Security Risk Assessment, System Partitioning, and Security Levels

Based on the understanding that IACS security is a matter of risk management. IACS customizes risk to an organization depending on the relevant threat, risk exposure, the likelihood of an event, inherent vulnerabilities, and consequences of compromise. Each organization that owns and operates an IACS has its own tolerance for risk, and organizations are required to provide inputs used to assess the risk of a particular IACS.  Based on those inputs, ISA/IEC 62443-3-2 can help when engineering a solution by guiding the identification/application of security countermeasures to reduce that risk to tolerable levels with respect to defined security levels, zones, conduits, and other security fundamentals.

ISA/IEC 62443-3-3: System Security Requirements and Security Levels

Defines the security assurance levels of the IACS components. Security levels define the cybersecurity functions embedded in the products to be used in industrial and critical infrastructure environments; they are crucial to achieve product robustness and add resistance to accidental or malicious cyber threats.

Reviewing the relevant standards based on needs, then diving into appropriate specifics is a  solid approach for organizations readying an IEC 62443-orientated security program.

Taking advantage of IEC 62443’s broad applicability and inclusiveness

IEC 62443 is growing in popularity and many countries are adopting the collection in what is rapidly becoming a global set of standards. These guidelines specifically target ICS/IACS/OT security and feature a wealth of knowledge focused on action items such as:

• Performing OT cyber risk assessments
• Building OT cyber security management teams
• Driving patching and other protective controls/capabilities
• Framing requirements in both solutions and products
• Considering asset and system security lifecycle
• Isolating, segmenting, and securing network zones and conduits
• Deriving processes and governance
• Creating appropriate roles and responsibilities for users or resources
• Evaluating cyber risk reduction factors (CRRFs)

The standards provide excellent, centralized knowledge to supplement existing guidance, create net new programs, and define security conversations. They also deliver a turnkey resource that can be used unaltered for a foundational OT program.  The IEC 62443 standards are regularly updated, modified, and expanded and all are welcome to join the community or serve on its various subcommittees.

Organizations looking to tackle cyber security in the ISA or engineering-centric way can make good use of IEC 62443 standards in whole or in part based on their current and future needs. Vendors, product owners, IT professionals, engineers, risk management analysts, and security professionals will all find  substantial value in IEC 62443, even if only as a secondary information source

Examining IEC 62443 Zones, Conduits and Security Levels

In addition to overall ICS-specific security guidance, IEC 62443 is built on core concepts of identifying systems under consideration (SuCs), security levels (SLs), and so-called “zones”, and “conduits.”  It is this taxonomy that helps ICS/OT security professionals assess, design, and implement cybersecurity architectures and solutions as well as manage cyber-related risk through traditional FMEA, HAZOP, and LOPA study inputs.

To begin, asset owners select a system under consideration (SuC) and use pre-defined SLs to describe the desired target security levels (SL-Ts), achieved levels (SL-As), and capability levels (SL-Cs) for the SuC or for subsystems within it.

Four levels are assigned to evaluate the SL-A, SL-C and SL-T vectors :

• SL 4: Protection against intentional violation using sophisticated means with extended resources, IACS specific skills, and high motivation
• SL 3: Protection against intentional violation using sophisticated means with moderate resources, IACS specific skills, and moderate motivation
• SL 2: Protection against intentional violation using simple means with low resources, generic skills, and low motivation
• SL 1: Protection against casual or coincidental violation

Asset owners can apply these levels in various ways assuming that the SuC was also separated into “zones” and “conduits” which are defined as:

• Zones: A grouping of logical or physical assets that share common security requirements based on factors such as criticality and consequence.
• Conduits: Groupings of assets dedicated exclusively to communications and which share the same security requirements. Conduits can also be used to describe tunnels communicating between zones.

This taxonomy allows architects, engineers, and security professionals to describe desired risk levels and mechanisms required to achieve specific security objectives or cyber risk reduction factors (CRRFs).

While there are similarities to ISA 95 layers, the overlap is mostly just an homage to IEC 62443’s predecessor. What matters is that IEC 62443 standards demonstrate solid guidance asset owners can use as a basis for building a comprehensive OT/IACS program, and to standardize their security taxonomy, design elements, and requirements.

The IEC 62443 aligned Cybersecurity Management System (CSMS)

In keeping with language similar to that of ISO 27001, the IEC 62443 standards lay out a comprehensive process for creating an OT/IACS/ICS security program, also known as a cybersecurity management system, or CSMS.  A CSMS is categorized into three areas: risk analysis; addressing risk; and monitoring and improving the CSMS itself.

Inside each of the top levels reside elements to define: business rationales; risk identification; classification and assessment; policy, organization and awareness; countermeasures; program implementation; conformance; and performance review.

For example, an excerpt from the distilled IEC 62443-4-2 CSMS requirements under risk analysis lists numerous requirement areas and values associated with measuring an organization’s conformance to them.  IEC 62443 does not define the conformance values per se, but most organizations tend to use a CMMI rating, or some other, less formal alternative such as FULLY, PARTIALLY, MINIMAL, NONE, and N/A.

Overall, there are approximately 127 requirements in the IEC 62443 CSMS standard document, and not all of those need to be met immediately.  Some of the requirement areas lean heavily on policy writing, for example, or require advanced implementation efforts and organizational commitment.  Other examples targeted at more mature IEC 62443 CSMS users include:

• 2.3.12 Conduit risk assessments throughout the lifecycle of the IACS.
• 3.2.3.2 Establish the security organization(s).
• 3.2.5.3 Develop and implement business continuity plans.
• 3.3.2.4 Address security responsibilities.
• 3.4.3.1 Define and test security functions and capabilities.

Security is both a sprint and a marathon.  Organizations need budget, commitment, resourcing, road mapping, and strategic initiatives in order to achieve an appropriate level of maturity and desired security posture.  The IEC 62443 CSMS covers most foundational areas ranging from assessing risk, resourcing, policies, procedures, technology, and the monitoring and evolution of the CSMS.

Guiding risk assessment with IEC 62443

IEC 62443 assessments follow a well-defined process once SuC is determined.  Following the process outlined in ISA-62443-3-2 — or creating a version modeled after it but specific to the organization or client — offers an effective way to discover, derive risks, and determine recommendations or work packages for controlling risk levels.

Assuming there are competent assessors, the IEC 62443 process for performing an OT security risk assessment (SRAs) is well thought out, can leverage past assessments (e.g., gap assessments, cyber maturity reviews, PHAZOPs, LOPA reviews, etc.), and can be performed consistently and repeatably.  It can be high level (see blue process) or detailed (see orange process), or some combination of the two.

However, academic or paper-based assessments are only as good as:

Using IEC 62443 to secure product development lifecycles

IEC 62443 standards provide a high-level set of prescriptive requirements and processes for secure product development lifecycles (SDLCs) fit for IACS/ICS/OT environments.  They are, however, less detailed than, for example, a NIST special publication (SP) that enumerates a number of technical capabilities and best practices for user or encryption management.

Despite that shortcoming, IEC 62443-3-3 defines the security Foundational Requirements (FRs) and includes processes for user authentication, enforcement of roles and responsibilities, change management, encryption, network segmentation, audit logs, and system backup and recovery.  Using IEC 62443-4-2 as a CSMS delivers another full list of sub-requirements, all of which are grouped by the IEC 62443-3-3’s seven FR areas.

During product development, however, hitting a specific security level target (SLT) involves meeting and designing for a specific set of requirements.

Creating a secure product demands more than simple checkbox ticking, however. Product vendors must take action on desired sets of requirements as well as implement a multi-phase development lifecycle.

The majority of a product’s lifecycle is spent in the design, develop, verify, release, deploy, and respond phases.  There’s a good reason for this.

Industrial products are developed like most other technology wares. However, the majority of an industrial product’s lifetime is not spent in development, but rather in maintenance, updating, and bug fixing. The post-release period is poorly accounted for in terms of tracking costs or efforts, but remains critical for maintaining a robust, durable, secure-by-design systems.

Many vendors and OEMs think of a product as a one-time endeavor to create products according to the requirements defined by sales or by implementations.  This mindset, and the myth that security adds costs, results in insecure-by-design products.  In fact, security does not cost more, and does not necessarily add time or complexity to deployment and use. The majority of vulnerabilities in ICS/OT devices or applications are the result of poor engineering, lack of comprehensive testing, and mediocre component maintenance.

IEC 62443 standards outline processes and requirements to securely design and develop products, define basic security requirements, detail better coding practices, and describe risk-aware deployments.  Organizations already performing or implementing SDLC functions can use IEC 62443 to augment current practices.

Leveraging IEC 62443 in product selection and procurement

Like most standards and frameworks, IEC 62443 offers guidance to improve existing processes for technology project scoping, vendor selection and procurement.

For example, an organization that wants to create a machine cell for a new process with a minimum level of security (e.g., SLT-1) to prevent accidental issues can reference the requirements in ISA-62443-3-3 and other sibling documents to develop pre-selection criteria and achieve its objective. The standards can also be used to dictate how factory and site acceptance testing includes security verification before handoff.

While there are numerous requirements for each security level, an informed individual or team can create a subset of requirements and map the standard to a minimum set of viable guidelines for re-use across the organization.

Meeting and validating the requirements before the design phases reduces the security burden and lowers the total cost of ownership (TCO) over the system’s lifetime.

Blending IEC 62443 with other frameworks and standards

IEC 62443 standards are fully compatible and mostly map directly with other well-known guidance such as the NIST CSF.  There can be, however, substantial differences in language and application that require the use of OT-specific overlays and adaptation of IT variations in order to manage exceptions in a converged OT/IT environment.  Getting the best of both worlds requires organizations to get a little creative.

In the enterprise, for example, the common ISA27001 standard is highly prescriptive as a security system and orientated towards processes and IT.  Meanwhile, the NIST CSF and its OT supplement (NIST-SP800-82) can be made OT acceptable across its five functional areas.  Any standard that works for the organization is better than no standard or direction, and that these can be made to work for OT depending on audience, business culture, engineering strategies, and industry.

Acknowledging IEC 62443’s cyber-physical limitations

IEC 62443 makes excellent companion for the security of cyber-physical systems, but they are not designed to replace ISA84/SIL or PHAZOPS.  Where some of the SIL and relevant ISA standards are lack specific language or guidance for electronic/networked/computerized systems, IEC 62443 makes an ideal complement.

IEC 62443 cannot be used in place of extensive safety and reliability standards or proper PHAZOP study, however. All should all be used together to identify risks and potential impact to ensure the organization stays running and avoids a negative Health-Safety-Environment (HSE) event.

Getting started with IEC 62443

At the outset, IEC 62443 should be viewed less as a replacement for current security schemas and more as a way to identify gaps, needs, and potential enhancements to existing programs. It is also useful for taking into account the security impact of digitalization on traditional, mechanical processes and protocols covering areas such as disaster recovery.

One approach might include:

• Identifying security gaps and reviewing findings from previous risk assessments
• Prioritizing problem areas by cost, efforts, relevancy and potential risk reduction
• Determining the correct IEC 62443 requirements or work packages needed
• Completing relevant work packages and verifying they’re operationalized

From another perspective, organizations already leveraging NIST CSF-style framework in place might use IEC 62443 standards to:

• Establish an IT-to-OT mappable security program, ensuring correct terminology is used and ICS concerns are covered
• Define security requirements for new product procurement and their factory/site acceptance testing
• Validate current policies and processes for sufficient OT security and domain relevancy
• Provide guidance when selecting firewalls and creating patch management regimes for OT/ICS systems
• Create an OT/IACS risk management and assessment process

There are many ways to map/implement the standards conveniently but also to establish the security language required to speak amongst the communities within your organization, or at large!

IEC 62443-specific certifications and source material

As with other standards such as ISO 27001, individuals and organizations can take advantage of certifications purpose-built for IEC 62443, including:

• Individuals can take one or all of ISA’s four exams to be certified on the standards collection’s core concepts covering fundamentals, risk assessment, design and maintenance. Completing all four earns the taker a designation of ISA/IEC Cybersecurity Expert
• Vendors can certify their products as IEC 62443 compliant for various security levels
• Asset owners can certify their sites or systems with respect to the IEC 62443 standards

More information on all of the IEC 62443 certification options is available on the ISA website; the standards are also free for online viewing for ISA members.

How Verve aligns to IEC 62443

Verve was built on a foundation of OT knowledge from their 30 years of history working in the process control/OT environment. This expertise ensures that both our dedicated services and the Verve platform are safe to operate with all brands of OEM equipment, allowing us to help nearly any OT/ICS organization achieve higher levels of security even within proprietary, embedded controls devices.

Verve’s asset management, detection, compliance, and protection capabilities create an informational hub that can inform you on the potential risk and assessment activities within your organization. Within one platform, effective in both IT and OT environments, we can determine whether your organization uses NIST CSF, IEC 62443, or CSC20 (now rebranded as the CSC18) – the Verve platform can suit your organization’s needs.

With our deep OT knowledge along with the comprehensive platform, Verve provides a range of benefits over alternative solutions and cybersecurity services organizations.

To be fair though, one of the biggest challenges in complying with security requirements for industrial organizations is the labor and knowledge shortages both within the organizations as well as in the market. Tools are critical, but people are necessary to achieve ongoing compliance. Verve recognizes this which allows us to combine our unique platform with a range of options for enabling clients to assess, remediate and maintain compliance with security standards.

Verve offers a range of managed services designed specifically for operational environments for clients who are budget conscious. Starting with our subscription services, we provide low-cost, high-value services from our highly skilled team. Our ability to watch all third-party and vendor-related apps allows for sharing of research across our clients, thus distributing the cost across a fleet of clients.

We also offer ‘boots on the ground’ services to help backup, test, rollout, and restore systems when performing tasks such as patching, updates, and assessments (including mandates that are IEC 62443 based). These services can be scheduled or ad-hoc service as needed. Finally, Verve provides 24/7 emergency technical support and accessibility. In all cases, Verve delivers the ‘best of the best’ skillsets to benefit your organization.

The following table breaks down our managed services capabilities.

Verve is pleased to support industrial organizations in securing our critical infrastructure against attacks. We look forward to the opportunity to share more about our platform and services with you. Read more about specific alignment between Verve Industrial for IEC 62443.