.

I authored this article to provide a broader perspective and some clarity when working with zones and conduits of a certain system under consideration.

Whether you are working on an existing system which can be a very old one with urgent need of security (better late than never), or you are working in the early stages of engineering of a new system that requires proper definition of zones and conduits (the sooner the better), you need to understand zones and conduits and how to deal with the new security context.

Every professional who designs configure and maintain any type of control systems, need to learn about zones and conduits and manage the new security requirements and develop necessary skills according to their function, even if they are not into industrial cybersecurity.

Understanding zones and conduits is not exclusive to an industrial cybersecurity expert. If you are dedicated to control systems, you must learn what zones and conduits are, why they are necessary, how to implement the requirements, since they currently form a fundamental, intrinsic part of the control system, which will have a significant contribution to the security of the system and safety of the plant.

Cybersecurity in industrial systems is no longer an exception, nor an option where we can get away with it. There is no choice, no escape. Automation professionals must develop the competencies and incorporate the knowledge of the zones and conduits, even if they are electrical engineers of the old school of relays.

At the beginning it requires a little imagination, patience, and practice.

When working with a new system in preliminary stages of engineering, the situation is a lot easier and better, because we are starting from nothing, the zones and conduits must be defined from the outset and are developed throughout the life cycle of the control system. This also requires knowledge, but certainly you can create perfect zones and conduits. At this moment, not even the plant exists!

Let’s look at the zones and conduits from a very practical perspective, avoiding entering the hard print of the ISA/IEC-62443 series of standards. We have the following definitions.

Zone: is a set or group of cyber-sensitive devices, or simply component or assets, which share the same cybersecurity requirements, or more specifically the same level of security (SL-T).

Examples of components in Zones: PLC, RTU, HMI, Historian, Flow Computer, Frequency Inverter, Chromatograph, OPC Server, Web Server, Intelligent instrument (TT, PT, FT,..) etc.

Conduit: is a set or group of cyber sensitive devices, or simply components – dedicated exclusively to communications -, that share the same cybersecurity requirements, or more specifically the same level of security (SL-T).

Examples of components in Conduits: switch, router, hub, modem, IDS (Intrusion Detection System), security system, etc.

A zone can have communication devices since the devices within a zone may or may not have communication channels. A zone can have no communication because these devices are not connected to each other, or it can have one or more communication channels.

However, new concepts appear, which are: security levels, security requirements (SL, Security Level), and requirement enhancements (RE). Without these definitions the zones and conduits are meaningless.

The ISA/IEC-62443-3-3 standard defines for each of the security levels (0, 1, 2, 3, and 4) a list of applicable security technology requirements on cyber assets (components).

• SL = 0, has no requirements.
• SL = 1, has several security requirements that provide protection against occasional, generic, casual, and unintentional security breaches.
• SL = 2, has more security requirements and requirements enhancements to provide protection against intentional events with low motivation, generic skills, and simple means.
• SL = 3, introduces more security requirements and requirements enhancements to provide protection against intentional violation using sophisticated means with moderate resources, IACS specific skills, and moderate motivation. This considers specific knowledge of technology and plant design.
• SL = 4, introduces even more security requirements and requirements enhancements, to provide protection against intentional violations using sophisticated means with extended resources, IACS specific skills and high motivation.

These requirements are organized around 7 foundational requirements (FR1, FR2, FR3, FR4, FR5, FR6, and FR7). The ISA99 committee, responsible for the development of the ISA/IEC-62443 series of standards, identified, after much analysis and debate, that the triad (Confidentiality, Integrity, and Availability), traditionally used for information security, is insufficient or incomplete to be used within control systems, and for this reason they created the Foundational Requirements (FR, Foundational Requirements). These are:

• FR1 = Access Control (IAC)
• FR2 = Usage Control (UC)
• FR3 = System Integrity (SI)
• FR4 = Data Confidentiality (DC)
• FR5 = Restrict Data Flow (RDF)
• FR6 = Timely Event Response (EROI)
• FR7 = Resource Availability (RA)

Furthermore, the SL-T of a zone or a conduit is not a single number, because the security requirements may move freely based on its essential functions and particular results obtained after a detailed risk assessment. Engineers need to go through a design process.

Security Requirements are not Controls, as many people get confused about this. A security requirement is a specification that needs to be met by the zone or conduit, and a control is something that we are going to use to verify, confirm, or audit that the requirement is being met. There will be diverse ways to meet the requirements as there will be diverse ways to control that the requirement is being met.

Everyone within industrial automation systems and industrial cybersecurity must get familiar with the Foundational Requirements in detail. As a designer of control systems or a person responsible for its security you need to understand how these requirements can be met. And as a provider of controls systems, you need to know what are the capabilities of the system that you are providing. If you don’t understand this, the requirements won’t be met. It can become a very painful project for the end user and the solution provider.

This is the situation of many, …

After taking official ISA courses, studying the series of standards, mixing with the other information security standards, and regulations, trying to understand them too, certifying yourself as an ISA expert professional, you stand in front of an existing control system, and you ask yourselves repeatedly, where are the zones and conduits?  OMG, I can’t see them! You look again, ask a colleague, you still don’t see them! That feeling of total loss is usually real and demoralizing. You invested hours, days, weeks, years of your life, and you still don’t see the zones and conduits. I’m a donkey, I didn’t learn anything, or the norm doesn’t work, this is crazy, and okay, I better continue with the triad of IT and information security standards.

The reason for that feeling is because existing systems are imperfect, in terms of security, they were designed without the zones and conduits in mind. You are not going to find perfectly implemented security zones and conduits on almost any existing system. You are most probably going to find a functional proven robust system architecture but a messy and often confusing in terms of security.

We use the zones and conduits model on existing systems as a method to interpret and understand the reality “As Is” of the system under consideration (SUC). Like it or not, the system is what it is, with its irregular zones and conduits. You must accept it; your system needs security. The safety of the plant might be under risk.

Here comes the first lesson learned. It’s not about “seeing,” it’s about “understanding.” Many people like to say: “We can’t protect what we don’t see,” in industrial cybersecurity we should say, “We can’t protect what we don’t understand.” It’s not a matter of seeing, it’s a matter of understanding.

Many people read the ISA/IEC-62443 series of standards, or at least one of them, and interpret them wrongly, and arrive at wrong conclusions. The best way to learn about the ISA/IEC-62443 series of standards is to take official ISA training courses. This is my best recommendation.

From now on, instead of continuously repeating “Zones and Conduits”, we will simply say “Nodes”, which is a way of referring to zones and conduits in a general way. A Node can be a Zone or a Conduit.

Many professionals find similarities between “Functional Security” and “Industrial Cybersecurity”. “Functional Safety” is developed on the failure theory of cybernetic, physical, and mechanical components leading to one or more consequences; while “Industrial Cybersecurity” is developed around cyber-incidents that can occur on cyber-sensitive components leading to one or more consequences.

While it is true that there are analogies and similarities, there are also differences and particularities specific to each of the industrial risk disciplines and models.

In the case of “Functional Safety”, experts in control systems, automation of industrial processes can continue with their professional development and their daily responsibilities without the need to incorporate the definitions, concepts, and specific knowledge of “Functional Safety”, or knowing very little. This is because control systems and safety instrumented systems are independent. For this there are the experts in “Functional Safety”. In the case of industrial cybersecurity, this is no longer the case.

In the case of “Industrial Cybersecurity” experts in control systems, automation of industrial processes cannot ignore the fundamental concepts and governance requirements and security that apply to the Nodes. To say that cybersecurity professionals are there for this, or perhaps this is a problem that must be solved by the information security department, which does not apply.

Many believe that a Node is a nice loop shown on an architecture or network diagram. It is a lot more than just that, and each node should have at least:

• ID. Unique identification.
• Name, Definition or Title. Quick reference.
• Description. Descriptive memory of the node.
• Inventory of Cyber Assets, with their additions, deletions, and modifications.
• Essential functions. Each cyber asset serves an essential function in the node for that plant and process.
• Its physical location or the physical location of each device.
• Inventory of technological, physical, and procedural vulnerabilities.
• Inventory of Physical Assets that it controls, operates, protects, supervises, monitors, etc. (Essential Functions). It is determined by the related industrial process(es).
• Inventory of Potential Consequences that could occur if the cyber assets (one or more) are cyber-compromised, also called cyber-incident.
• Objective Security Level. Security requirements that arise because of a risk assessment with a specific methodology.
• Current Security Level. Security requirements that the node in question currently meets. It is usually below the necessary unless the SL-T is 0 (zero).
• Security Alerts (Similar to Process Alarms). Security alerts must follow a rational, false positive basis and must define clear and unambiguous response actions.
• Its history over time, KPIs, changes, and others.

A Node is not simply a loop that looks pretty in diagram nor conveniently chosen by IP range. Each Node is unique. A Node gathers an amount of information that is required to understand to manage industrial cyber risk correctly and thus be able to mitigate all risks that are intolerable for the organization.

Let’s go back to the million-dollar question. Where are the zones and conduits?

The grouping of these cyber assets into their respective zones and conduits can be through physical or logical criteria. But which one to use? Or what is the correct criterion?

The Zones and Conduits model is used to design security and mitigate industrial cyber risks in an intelligent and optimal way without overspending on unnecessary and non-contributing security actions, and without underinvesting in security actions that are necessary to avoid the occurrence of potential consequences. Mitigate risks through the implementation of those security actions that are effective, efficient, and sufficient.

Zones and conduits can be defined logically, logical criteria, or physically, physical criteria, or a combination of both. This is what we say, the instructors in the official ISA courses. However, it is not a matter of choosing the one we like the most, the criterion that I want, or the one that is most comfortable for me.

Identifying the zones and conduits of a given system under consideration (SUC), requires understanding, understanding the system, its installation, and the process that is being controlled. Modeling the zones and conduits of a certain system is an interpretation of reality. To interpret reality requires understanding the control system, and the industrial process.

Now, how do we identify the zones and conduits? Do we stay with the logical or physical criteria? We must stick with the criteria that best interpret reality. We must use the criteria that prevail over the imperfections of the existing system. Let’s look at two examples.

Example #1: We have a control system in which we have several cyber assets communicating over an ethernet network, where all cyber assets use the same network segment or IP range. However, these cyber assets are in different, physically different rooms, Room A and Room B. Each of the rooms has its physical perimeter, access controls, electrical power system, they are located two hundred meters away, or maybe one thousand meters away, etc. In this case the segmentation is given by physical differences. Adding logical segmentation into this architecture is quite simple and straightforward to perform.

Example #2: The same amount of cyber assets is in the same Room A. however half of them communicate through one network segment X and the other half communicate through another network segment. They have no way to exchange information in the current architecture. Although they are physically in the same room, one cabinet next to the other. In this case, even though the cyber assets share the same physical characteristics, they are in different Zones, in this case logically separated.

These are just two examples. We can spend days listing and showing different examples of situations. Once you have a good understanding of the control system and the industrial processes it controls, zone and conduits segmentation will arise naturally. To model the zones and conduits well, it is necessary to know the details of the control system and the process, and fundamentally to understand them.

When we are working with an existing system installed in the plant, very possibly complex, which can be small, medium, large, or even the integration of several systems of all sizes, brands and suppliers, the subject becomes even more interesting and challenging.

The first thing we must do is to accept reality. Systems are what they are. You can be comfortable or not. Especially if you are not from the plant. If you must analyze the control system for the first time. Avoid expressions like who put things like this, who produced the idea of selecting this model, who put this crap, or all kinds of unconstructive comments, which does not produce any good. Every system and every plant have a story to tell. We must listen to it passively and non-intrusively.

The plant is 30, 40 or even 50 years old, producing essential products for the population, generating many jobs, and profits for its owners. It deserves respect. Finally, what counts will be the result of the risk assessment and the risks that need to be mitigated.

Let’s go back to the zones and conduits. The ISA/IEC-62443-3-2 standard says that to analyze the industrial cyber risk of a given SUC, we must segment it into zones and ducts. This initial segmentation will be the result of the best interpretation of reality that we have managed to make. The better we understand it, the better our model of zones and conduits will be.

Of course, this existing system, from the point of view of cybersecurity is imperfect, and very possibly the initial segmentation is incomplete or has imperfections. If we want to match all the technical characteristics of the foundational requirements of the ISA / IEC-62443-3-3 standard, to find the zones and conduits, we will never make it fit. This is going to happen in all existing industrial systems.

In my case, I have already modeled more than two hundred control systems, and after having led the respective risk assessments, I must say that every so often I find a control system (or several control systems) that surprises me with something new. Something I hadn’t encountered before.