Securing IACS based on ISA/IEC 62443 – Part 1: The Big Picture

For many years, industrial automation and control systems (IACS) relied on the fact that they were usually isolated in physically secured areas, running on proprietary hardware and software. When open technologies, standard operating systems and protocols started pushing their way into IACS replacing proprietary solutions, the former “security through obscurity” approach did no longer work. Connecting operational technology (OT) networks to information technology (IT) networks had the benefit of making central monitoring and improvement of industrial processes easier – but all these changes also brought new threats and the question of how to properly secure control systems did arise.

This is where ISA/IEC 62443 comes into the picture. The attempt to provide guidance on how to secure IACS against cyber threats reaches back to 2002 when the International Society for Automation (ISA) started creating a series of standards referred to as ISA-99. In 2010, ISA joined forces with the International Electrotechnical Commission (IEC) which lead to the release of the combined standard ISA/IEC 62443 that integrates the former ISA-99 documents.

ISO 27001 vs IEC 62443 – same but different?

But why is there the need for a separate standard at all? Does it not suffice to simply apply security measures that have already been established for IT systems, for example by implementing the requirements of ISO 27001? As a company responsible for designing, implementing, or managing IACS, you might face exactly this question, especially if you want to achieve an official certification.

Despite some similarities, OT systems and IT systems do have fundamental differences. One of the most significant differences is probably that failures in industrial processes usually impact the physical world, i.e. they could harm human health and welfare, endanger the environment by spilling hazardous materials or impact the local economy, for example in case of massive power outages. Also, the focus on core security objectives – such as confidentiality, integrity and availability – is different: While IT prioritizes confidentiality of data, OT focuses on availability of systems; the security objectives of both areas are thus diametrically opposed.

IEC 62443 outlines the unique requirements of IACS while also building on top on already established practices. This means that parts of IEC 62443 were developed with reference to ISO 27001 but also address the differences between IACS and IT systems. Also, the standard does not only outline the implementation of a management system but defines detailed functional and process requirements for both individual IACS components and entire control systems. IEC 62443 thus has a far broader range than ISO 27001 and is more tailored to the specifics of IACS.

IEC 62443 at a glance

The IEC 62443 standard is targeted at three main roles:

• Product suppliers that develop, distribute and maintain components or systems used in automated solutions.
• System integrators that design, deploy and commission the automated solution.
• Asset owners that operate, maintain and decommission the automated solution.

These roles could reside in the same organization or be fulfilled by different organizations. Asset owners might, for example, have an own department responsible for system integration. In another scenario, the asset owner might delegate the task to maintain an automation solution to an external service provider.

The structure of the standard reflects this role definition by grouping related documents accordingly. As a result, IEC 62443 comprises four chapters, each with multiple documents. Some of the documents are currently still in development and have not been released yet. The current status can be tracked at: https://www.isa.org/isa99/

The first chapter, General, provides an overview of main concepts and models applied within the standard. At the time of this post, most documents of this chapter are still under development.

The second chapter, Policies and Procedures, covers requirements and measures for establishing a Cyber Security Management System. In the first two parts you will see many references to ISO 27001 and even a mapping of the requirements in both standards. The other parts focus on the processes involved in operating and maintaining IACS and are thus mainly directed at asset owners or – if these tasks are outsourced – at service providers.

The third chapter, System, is mainly directed at system integrators. It provides an overview and assessment of different security measures ranging from authentication techniques and encryption to physical security controls. Furthermore, it guides through the risk assessment process for IACS environments and outlines specific technical requirements for control systems.

The last chapter, Component, focuses on requirements for product suppliers. It covers both procedural aspects such as setting up a secure development lifecycle and technical requirements that a component should meet.

One standard for the entire lifecycle

With regard to IACS, we can distinguish between the lifecycle of a single component that is part of a control system and the lifecycle of the control system itself. Both lifecycles overlap at the point where components get integrated into an automation solution and need to be operated and maintained.

Product suppliers are responsible for all phases within their products’ lifecycle. Part 4-1 provides guidance on how to set up development processes that integrate security-related activities right from the start of product development. Part 4-2 focuses on the product itself and defines specific requirements a product must meet in order to achieve a certain degree of security. Another relevant part especially in the maintenance phase is part 2-3 that outlines a structured process for managing patches.

In the first phase of the IACS lifecycle, the main objective is creating the functional specification. Part 2-1 provides the asset owner with a framework for setting up organizational structures and processes that will ensure that all security dimensions are considered when creating the specification and defining security targets for the IACS.

The commissioning of an IACS usually lies within the responsibility of the system integrator. Based on the previously defined security targets, the system integrator must develop a protection concept in cooperation with the asset owner. Part 3-2 outlines requirements for conducting a risk assessment in order to establish a proper segmentation of the system architecture. Part 3-3 defines which requirements a system must meet in order to achieve a certain level of security. By implementing these requirements, system integrators can prove that their solution meets the security targets defined by the asset owner.

The main responsibility for operating and maintaining the automation solution lies with the asset owner. Part 2-1 provides guidelines how to implement a security management system in order to continuously maintain and improve security. More specific requirements, for example on how to manage accounts or remote access on systems, are outlined in part 2-4; this part should also be considered by system integrators and any service provider supporting the asset owner in the operating phase.

Finally, both parts 2-1 and 2-4 also define requirements for decommissioning single components or the complete automation solution.

Defence in depth

IEC 62443 builds upon the defence in depth principle involving all stakeholders. Defence in depth means that multiple layers of security controls are applied: In case one security control fails, another control ensures that this will still not cause any greater harm.

With regard to IACS, this means that the first layer of defence are measures implemented by the asset owner. This can be for example security policies and procedures or physical controls protecting the perimeter. Further layers of defence are then created in the design of the automation solution by the system integrator, for example by enforcing network segmentation and deploying firewalls. The inner defence layer is realized by the functional security capabilities of components and systems in use. They are developed by the product supplier who is responsible for integrating proper security functions.

Security levels

The number of requirements and security functions to implement depends on the level of security that has been specified by the asset owner. IEC 62443 defines four Security Levels (SL) with increasing protection requirements.

The standard further defines three different types of security levels:

• Target Security Level (SL-T) is the desired level of security that is usually determined by performing a risk assessment.
• Achieved Security Level (SL-A) is the degree of security achieved with the currently implemented measures. It can be determined through an audit, for example, after the design is available or when the system is in place in order to verify that the implementation meets the previously defined requirements.
• Capability Security Level (SL-C) is the highest possible security level that a component or system can provide without implementing additional measures.

A simple example illustrates how these three types of security levels play together: We want to protect our orchard against kids stealing apples. This objective is our target security level (SL-T) corresponding to Security Level 2. There are different means available that could help us achieve our goal such as putting up a sign or a fence or buying a watchdog. A sign might not be very effective, i.e. it does not really provide any protection, so its capability security level is 0. Fence or watchdog can ensure better protection, meaning they have higher capability security levels. We now decide which means of protection we set up and then measure how well we are protected, i.e. which security level we have achieved with these measures (SL-A).

Translating this example to the IACS lifecycle, this means that the different types of security levels are applied at different phases of the system lifecycle:

• The asset owner will first specify the target security level required for a particular automation solution.
• The system integrator will design the solution to meet those targets. In an iterative process the currently achieved security level (SL-A) is measured and compared to the target security level  (SL-T) – also after the solution is put into operation to ensure that the achieved security level does not decrease over time.
• As part of the design process the system integrator will select systems and components with the necessary capability security level (SL-C).

Getting certified

After having gained a basic understanding of what IEC 62443 comprises, let us come back to the initial question on how you can achieve an official certification. One misconception is that there is just one IEC 62443 certification as is the case for ISO 27001. Given the broad range of the standard and the multiple stakeholders addressed, the question you should pose is not: Should I get an IEC 62443 certification? but rather Which IEC 62443 certification should I get?

As outlined before, from the stakeholders’ perspective, some parts of the standard are more relevant than others. As a result there are different IEC 62443 certifications focusing on different parts of the standard. For example, most certification programs for product suppliers only consider the requirements outlined in parts 4-1 and 4-2 while certifications for system integrators focus on parts 2-4 and 3-3.

As the market for IEC 62443 certification programs is still less mature when compared with ISO 27001 certifications, the number of organizations offering such a certification is also smaller; some of the most prominent players are TÜV, exida, CertX, UL, DEKRA and ISASecure.

Conclusion

IEC 62443 might be confusing at first glance and the sheer number of documents and requirements may seem intimidating. However, most likely just a small part of the standard will be actually applicable to your organization. The upcoming parts of this blog series on IEC 62443 will outline the specific requirements for each stakeholder in more detail. At the end, you will hopefully have a better understanding on how the standard helps you improve the security of your components or systems and which steps you need to take to get closer to an IEC 62443 certification.

If you need further guidance and support in preparing for an IEC 62443 certification, please contact info@nviso.eu.

About the author

Claudia Ully is a penetration tester working in the NVISO Software and Security Assessments team.
Apart from spotting vulnerabilities in applications, she enjoys helping and training developers and IT staff to better understand and prevent security issues.
You can find Claudia on LinkedIn.