Establishing Zones and Conduits

INDUSTRIAL CYBERSECURITY CENTER
ICC working paper series.
ESTABLISHING ZONES
AND CONDUITS
In accordance with the
isa99/iec 62443 standard
Consejos
Alt + left arrow to return to the previous view after going to a hyperlink
Click on icon and visit our website
Clicking on the flags of the cover you can see the activity of CCI in each of those countries
Patrocinadores del CCI
Platinum
Gold
Silver
Bronze
The Industrial Cybersecurity Center (known by its initials in Spanish, CCI), is an independent, non-profit
organisation whose mission is to promote and contribute to the improvement of Industrial Cybersecurity in a context
in which organizations from industrial sectors such as manufacturing and energy play a critical role in the society.
CCI strives to meet its mission by developing research and analysis activities, generating opinion, publishing
studies and tools, and exchanging information and knowledge. CCI’s main focus is on the influence of both
technology -including its processes and practices- and individuals, with regard to the risk derived from the
integration of industrial processes and related infrastructure within cyberspace.
Today, CCI is the meeting point for entities –both private and public- and professionals who work in Industrial
Cybersecurity or feel impacted or concerned by it. CCI is the Spanish-speaking world leader in exchanging
experiences and promoting the sectors involved in this field.
Edition: july 2018

ISBN: El ISBN es 978-84-947727-4-0 Paseo de las Delicias, 30 · 2º piso
28045 MADRID
Any form of reproduction, distribution, public sharing or +34 910 910 751
transformation of this content is strictly prohibited and will be info@CCI-es.org
subject of sanctions according to the law in force. Only the www.CCI-es.org
author (Industrial Cybersecurity Center, www.cci-es.org), can blog.CCI-es.org
authorize the copy or scan of any part. @info_CCI
Kaspersky Lab is a global cybersecurity company which has been operating in the market for over 20 years.
Kaspersky Lab’s deep threat intelligence and security expertise is constantly transforming into next generation
security solutions and services to protect businesses, critical infrastructure, governments and consumers
around the globe. The company’s comprehensive security portfolio includes leading endpoint protection and a
number of specialized security solutions and services to fight sophisticated and evolving digital threats. Over
400 million users are protected by Kaspersky Lab technologies and we help 270,000 corporate clients protect
what matters most to them.
To help industrial enterprises protect their Operational Technology layers and elements, Kaspersky Lab designed
a dedicated portfolio of technologies and services - Kaspersky Industrial Cybersecurity. It provides a holistic
approach to industrial cybersecurity: from industrial endpoint protection and industrial network monitoring to
training programs and expert services.
ics@kaspersky.com
www.ics.kaspersky.com
@KasperskyICS
Contents
1 FOREWORD 9
2 INTRODUCTION 11
3 ZONES AND CONDUITS 15
4 SECURITY LEVELS 27
5 GUIDE FOR THE DEFINITION OF SECURITY LEVELS 31
6 FINAL COMMENTS AND CONCLUSION 37
7 GLOSSARY OF TERMS AND ACRONYMS 39
8 BIBLIOGRAPHY 41
Establishing Zones and Conduits in accordance with the IEC 62443 7
Expert in industrial cybersecurity with demonstrable

experience in the oil & gas and electric power industry.
Skills in business processes, enterprise risk management,
internal audit, ITIL methodologies, ISO 27001, ISA99/IEC
62443, NERC-CIP, AGA, TSA and NIST800-82 principles
and standards,among others.Engineering professional with
multiple international certifications in industrial networks,
industrial cybersecurity and risk analysis, including “Cisco
Industrial Networking Specialist”, “IoT Industry Expert
Systems Engineer Representative”, “ISA99/IEC 62443
Cybersecurity Fundamentals Specialist”, “ISA99/IEC
62443 Cybersecurity Risk Assessment Specialist” and
“CSSA Certified SCADA Security Architect” granted by the
Information Assurance Certification Review Board. From
2016, he has been an “Information Member of the ISA99/
IEC 62443 Committee” within the working groups “WG2
- Focusing on the description of an effective cybersecurity
management system in the ISA-62443-2-1 standard
Security Management System)”, “WG3 - Preparing of a
second edition of the ISA-62443-1-1 standard (Models
and Concepts)” and “WG4 TG3 - Working on the standard
ISA-62443-3-2 (Security Risk Assessment and System
Design)”. In addition, since 2018 he has participated as a
technical representative within ISA-Secure for a major oil
company in Argentina.
He is an active member of Spain’s Industrial Cybersecurity
Centre (ICC) ecosystem, and has participated as a
reviewer and collaborator in the publication of documents
by this body since 2015.
Author
Mr. Javier F. Castillo
Computer Engineer, Faculty of Exact Sciences and Technology,
Universidad Nacional de Tucumán, Argentina.
1
Foreword
As is the case for technical assessments, capability assessments or incident analysis, the analysis of technological risks is a tool
which helps us to establish or update our cybersecurity programmes.
It is important to base such programmes on agile tools that enable better decision-making to protect and respond to incidents in
rapidly changing settings such as technological environments, especially in an industrial context where the integration between
information technologies (IT) and operational technologies (OT), which is essential for current business needs, generates an
increased level of exposure, points of failure and actors in the value chain.
The approach of IEC 62443, based on zones, conduits and security levels, enables a basis for the protection of operating and
information systems in an industrial environment to be established in an agile way, but above all, it provides a common language
between technology owners, integrators and manufacturers when establishing protection requirements in an industrial automation
and control environment.
In this excellent document, written by engineer Javier F. Castillo, you will find orderly, educational and practical information
regarding how zones and conduits should be established for a particular scope. The document also explains how to set security
levels on the five-point scale established by IEC 62443, as well as the requirements of each security level grouped into the seven
fundamental cybersecurity requirements.
This is the first publication of this new ICC working paper series, whose objective is to cover specific aspects of industrial
cybersecurity in an educational and practical manner, based on the experience of professionals, such as Javier F. Castillo in this
case, who has decided to share this document.
José Valiente
ICC Director
2
Introduction
Industry in general, and particularly what is commonly referred to as industry 4.0, faces multiple challenges, among which
industrial cybersecurity emerges as a key topic to consider in the technological evolution of industrial processes. Knowing where
and when to make investments in industrial cybersecurity may result in a competitive advantage for those companies that are
aiming to obtain greater availability, quality and performance in order to improve the efficiency of their business processes or
comply with the regulations of the market to which they belong.
What is industry 4.0? Industry 4.0 involves taking advantage of digitalisation in industrial processes through increasingly frequent
use of sensors and actuators that progress in the incorporation of “smart” technologies and complementary information systems
which enable production processes to be transformed and made more efficient.
The figure below clearly shows the evolution of industrial automation from the incorporation of mechanical equipment in industrial
processes to what is known today as the fourth industrial revolution, where cyber-physical systems play a leading and differentiating
role in improving the management and efficiency of industrial processes.
From industry 1.0 to industry 4.0 Degree of complexity
First Industrial Second Industrial Third Industrial Fourth Industrial

Revolution Revolution Revolution Revolution
Based on the Based on mass Based on the use Based on the use
introduction of production achieved of electronics of cyber-physical
mechanized production thanks to the and information systems (CPS)
equipment powered by concept of division of technology (IT) to
water and steam energy labour and the use of promote automated
electrical power production
First programmable logic

First conveyor belt, Cincinnati controller (PLC) Modicon
First mechanized loom (1784) slaughterhouse (1870) 084 (1969)
1900 2000 Present
Figure 1. Evolution of industrial automation.
Like any cybersecurity programme, the starting point to manage The ISA99/IEC 62443 standard constitutes the main
this issue is to carry out a risk analysis. Once we have proposed international reference framework for cybersecurity in industrial
this objective, the next question that arises is, ‘what are we systems where availability and integrity are the most important
going to analyse?’ Each industry has its own characteristics factors for the adoption of protective measures against cyber
and as such different elements should be assessed depending threats, but also to reduce unintended technological incidents.
on the level of detail that we hope to obtain. For example, in The ISA99 committee that initially developed the IEC 62443
the oil & gas industry, a refinery comprises multiple processes schema is composed of a series of members including
(separation, transformation, purification, etc.) through which owners, equipment and service providers (manufacturers and
crude oil is converted into a variety of end products. Within integrators), governments, educational institutions and various
each of these processes, more than one industrial system research groups.
is involved, and these systems in turn are composed of an
extensive variety of components (sensors, actuators, PLCs,
RTUs, HMIs, etc.). We can then choose to analyse a process, a
sub-process, an industrial system or each of its components.
It’s quite a challenge ...
12 Establishing Zones and Conduits in accordance with the IEC 62443
According to this standard, the industrial cybersecurity The importance of this definition lies in the premise that each
lifecycle consists of three phases: Assessment, Development & specific scenario has different security levels associated with the
Implementation, and Maintenance. tolerable risk for each organisation. For large-scale or complex
industrial systems, it may not be recommendable or necessary
Each of these phases forms part of the methodology proposed to apply the same security level to all of their components. For
by the standard for the protection of industrial systems against this reason, the concepts of zone and conduit were created,
incidents, whether intentional or otherwise. When we refer to which should be identified within the SuC.
“lifecycle”, it is essential to understand that in cybersecurity
the state of “guaranteed” security does not exist. Rather, each A zone is defined as the logical or physical grouping of
of these phases must be carried out in an iterative manner, industrial assets (which may be physical assets, applications or
feeding off the previous phase and adding value to the next. In information) that share the same security requirements.
this way, we can improve the countermeasures implemented
until a tolerable risk level is achieved. A conduit is a specific type of zone that groups the
communications which enable information to be transmitted
As a starting point, the standard proposes the clear between different zones.
identification of the “System under Consideration”
(SuC), which consists of all infrastructure that will be the Finally, the concept of channel is incorporated, which is defined
subject of the analysis. This can include control networks, as a specific communication link established within a conduit.
tele-supervision, communications infrastructure and The objective of industrial cybersecurity is to provide the SuC
security (routers/firewalls), and may even incorporate with two key concepts: robustness and resilience.
computer networks, depending on the services that they
provide to the industrial process and vice versa. Once the The concept of robustness is defined as the capacity to
SuC has been identified, the “Assessment” phase is operate in the face of a certain level of disturbance produced
initiated, which includes the “Allocation of assets to zones by cyber threats, and resilience is defined as the capacity to
& conduits” stage (see figure 3). In this document, we will reset or restore the system after an undesired event occurs
focus on that stage, leaving matters related to risk analysis with the minimum possible impact, according to the tolerable
for subsequent publications. risks defined by the organisation.
ASSESSMENT
HIGH-LEVEL RISK ASSESSMENT
ASSESSMENT
ALLOCATION OF ASSETS TO ZONES
& CONDUITS
DEVELOPMENT &
MAINTENANCE
IMPLEMENTATION
DETAILED RISK ASSESSMENT
Figure 2. Industrial cybersecurity lifecycle. Figure 3. Assessment phase.

3
Zones and
Conduits
3.1. ZONES Each defined zone must contain a document describing its
security requirements and how to ensure that tolerable
During the creation of a cybersecurity programme, the concept risk levels are achieved. This document should include,
of “zones” is one of the most important resources and its among other details, the scope of the zone, its security
definition constitutes a fundamental aspect for the success of level, the organisational structure to which it belongs and its
this process. responsibilities, the risks associated with the zone, the security
strategy adopted, the types of activities that are permitted
Zones can be a grouping of independent assets, a group of within it, etc. All this information must be documented for
sub-zones or a combination of both. In turn, zones possess each zone, as it serves as a guide for the construction and
inheritance attributes, which means that the “child” zones (or maintenance of the assets contained within the zone.
sub-zones) must comply with all security requirements of the
“parent” zone. When we refer to assets, we are referring to The asset inventory constitutes a decisive factor in
“the assets necessary for the industrial process”, which we will achieving the objectives defined in the security policy. A
define as “all elements belonging to an industrial system (PLCs, document must be created that specifies all logical and
RTUs, operator and engineering workstations, communications physical assets that form part of the zone. This document
equipment, etc.) that has value or potential value for an includes an example of an asset matrix (for reference
organisation”. The value threshold from which an element is purposes) which facilitates the definition of a zone, as well
considered an asset varies depending on the organisation and as cataloguing, with some minor changes, the industrial
its size. systems associated with an industrial process.
Each zone has a set of characteristics and security requirements Although obtaining the information detailed in the “reference
that constitute its attributes: matrix” usually requires a significant initial effort, this must
be carried out in the greatest possible detail, given that, as
› Security policies and security levels mentioned previously, it constitutes a fundamental element
› Asset inventory when creating an industrial cybersecurity programme. In
› Access requirements and controls addition, due to the nature of industrial systems, it is well
known that their lifecycle is in the range of 15 to 20 years.
› Threats and vulnerabilities
As such, a significant initial workload is expected, with few
› Consequences of a security breach modifications for prolonged periods of time. Furthermore,
› Authorised technology we should mention that there are currently automated tools
› Change management process which, although they were not specifically designed to meet
this requirement, significantly speed up its implementation.
Table 1. Example of a zone asset inventory.
1
GENERAL SUPERVISION AND CONTROL SYSTEM 2 3
SECURITY LEVELS
SL-T SL-A SL-C

TELEMONITORING COMPONENT COMMUNICATION COMPONENTS CONTROL COMPONENTS
Industrial sector
Zone to which it Geographic Industrial Contact System type Product Version
location process
belongs
Device Operating IP-NAT Brand and IP-NAT
Type name system IP address address Anti-virus Type Brand and model Type model Protocol IP details address
Name of
the device IP address IP address
Unique Brief description SCADA, HMI, Engineering in the Switch, PLC, in the Target Achieved Capability
Province, state, DCS, data Commercial xxx station, operating which OS version Device IP case NAT Anti-virus router, Brand and model Brand and Communication Component IP case NAT security security security
identifier of Industrial sector of the industrial Supervisor name name executes address brand model protocol used address
region, etc. acquirer, other station, server protocol is modem KTU, etc. protocol is level level level
the zone process the
used used
system
1 3
GENERAL SECURITY LEVELS
Industrial sector SL-T SL-A SL-C
Geographic Industrial
Zone to which it Contact
location process
belongs
Target Achieved Capability
Unique Brief description security security security
Province, state,
identifier of Industrial sector of the industrial Supervisor name level level level
region, etc.
the zone process
2
SUPERVISION AND CONTROL SYSTEM
TELEMONITORING COMPONENT COMMUNICATION COMPONENTS CONTROL COMPONENTS

System type Product Version
Device Operating IP address IP-NAT Brand and IP-NAT
Type Anti-virus Type Brand and model Type Protocol IP details
name system address model address
Name of IP address IP address

SCADA, HMI, Engineering the device in the Switch, PLC, KTU, in the
Commercial OS Device IP Anti-virus Brand and Communication Component IP
DCS, data name xxx station, operating which case NAT router, Brand and model case NAT
version address brand etc. model protocol used address
acquirer, other station, server executes protocol is modem protocol is
the system used used
When defining a zone, we are clearly delimiting a specific

segment within the industrial system and/or process. In
consequence, there should be a small number of requirements
and means to obtain access to this zone. An access policy
must establish with precision the staff who is authorised
to access each zone, the means through which access is
performed and the access control mechanisms. It is here that
the concept of conduit, which we will develop later in this
document, gains relevance.
A zone has its own vulnerabilities, and is exposed to a
specific number of threats. That is why regularly carrying out
a vulnerability analysis on zones (or on the industrial process as
a whole) is essential to identify potential threats which prevent
the industrial assets from fulfilling their business objectives.
Industrial systems, in general, must accompany the changes
in the requirements and rules of the business to which they
belong. These changes may impact on different identified
zones through the incorporation of new technologies, additional
access requirements and the creation of new conduits, among
other means. It is therefore essential to implement change
control mechanisms to ensure that any modifications related
to a zone do not alter the security levels required for it.
Figure 4 - Example of zones.

Source: ISA99/IEC 62443-1-1
3.2. CONDUITS
“Conduits” are particular zones that are applied to specific Upon finalising the technological risk analysis proposed by IEC
communication processes, providing security functions that 62443, the optimal grouping of zones and conduits will have
enable two zones to communicate securely. All communication been established in such a way that the system can be secured
between different zones must be carried out via a conduit. by design, achieving target security levels and tolerable risk
for the organisation, without spending too much or investing
As with a zone, conduits constitute a logical and/or physical too little. This approach is valid for existing systems, usually
grouping of assets (communication assets in this case). A referred to as the “installed base”, or for new systems that
“security conduit” protects the security of the channels must comply with their different engineering stages (basic
which the conduit contains, in the same way as a physical engineering, detailed engineering, design, procurement,
conduit protects cables from physical damage. construction, testing, launch, operation, maintenance, until
Conduits can be thought of as the “tubes” that join different retirement or decommissioning).
zones, or which are used to bind components within the
same zone. Whether they are internal (within a zone) or
external (outside of a zone), conduits protect the channels
that provide communication links between industrial assets.
In industrial systems, conduits usually constitute the network
devices (switches, routers, firewalls, etc.) that form part
of their architecture, but in some cases they may also be
servers or communications gateways used for the conversion
of different protocols.
Conduits are used as one of the main inputs to determine
the threats to which a zone is exposed. Clearly identifying the
conduits will enable us to identify the points of access that the
zone possesses, and analyse whether they may be converted
into potential attack vectors. A detailed risk analysis must
include both the zones and their associated conduits to obtain
the best results.
As they are a particular type of zone, each conduit, like zones,
possesses a set of characteristics and security requirements
that constitute their attributes.
› Security policies and security levels
› Asset inventory
› Access requirements and controls
› Threats and vulnerabilities
› Consequences of a security breach
› Authorised technology
› Change management process
› Zones that interconnect
› Communications protocols (highly varied due to the nature
of each industry and manufacturer)
Unlike zones, conduits must include details of the different
zones to which they interconnect, ensuring that the technology
used for the creation of communication channels complies with
the fundamental security requirements specified according
to the associated security level. The definition of the different
security levels and their specific requirements is developed in
greater depth in “Section 4 – Security Levels”.
3.3. DEFINITION OF ZONE AND CONDUIT REQUIREMENTS

3.3.1. System under Consideration (SuC)
As a first step, the organisation must clearly define the “System under Consideration” (SuC), including a precise identification
of its limits and all access points to the SuC. This definition is essential as it constitutes the specification of the scope on which
work will be carried out, setting the level of granularity that will directly impact the results obtained. The same level of detail will
not be obtained by selecting a complex process involving multiple systems, locations and technologies, as would be obtained by
segmenting such process into sub-processes and analysing each of them separately, without neglecting the interdependencies
that may exist between them.
Once the SuC has been determined, the necessary zones and conduits must be established, grouping their assets based on their
functionality, location, organisation, supervisors, risk analysis results, etc. The grouping of these assets should clearly reflect the
common security requirements for each zone and conduit identified.
3.3.2. Diagram of zones and conduits

Each organisation must generate diagrams that illustrate the segmentation of zones and conduits adopted for the SuC, which must
ensure that all industrial assets of the system in question are allocated to a zone or a conduit.
To comply with this requirement, the ISA99/IEC 62443 standard suggests using, as a starting point, the reference model proposed
in “ANSI/ISA95.00.01-2000 Enterprise-Control System Integration Part 1: Models and Terminology”, which consists of a high-
level model that reflects the integration of corporate and industrial systems.
ENTERPRISE SYSTEMS
LEVEL 4 (BUSINESS PLANNING AND LOGISTICS)
Systems/operations
LEVEL 3 management
Supervisory control
LEVEL 2 Site monitoring and Automation and

local display control systems
LEVEL 1 Basic control

Safety and protection
LEVEL 0 CORPORATE SYSTEMS

(CONTROLLED EQUIPMENT)
Figure 5. High-level ISA999/IEC 62443-1-1 model.

The aforementioned model includes five levels, which are 3.3.3. Initial criteria for the separation of
specified below;
zones & conduits
› Level 4: Covers functions related to the corporate systems I. The assets of business information systems (IT) and
that support the management needs of each organisation. industrial control systems (OT) should be grouped
› Level 3: Covers functions related to the management of into separate zones.
workflows required for the manufacture of end products or
resulting from the industrial process. Under normal conditions, information systems and industrial
control systems should be placed in different zones based
› Level 2: Covers functions related to the supervision and
on their functionality, as different areas of the organisation
operation of the different production areas involved in an
are responsible for them, determined by the results of the
industrial process.
prior risk analysis, and usually because they are in different
› Level 1: Covers functions related to automation and basic locations. It is important to understand that the main
control of the industrial process. (E.g. Discrete, batch, difference between these types of systems is that industrial
continuous). control systems have a direct impact on human health and
› Level 0: Constitutes the process in question. Includes the the environment, in addition to the fact that they may affect
sensors and actuators that are directly connected to the production and corporate image in the event of an incident.
process or its associated equipment.
II. The assets identified as Safety Instrumented
When initiating the task of documenting the zones and conduits,
Systems (SIS) must be placed in separate zones.
all industrial assets involved must be located within the SuC,
as specified in the reference model. This first approximation Safety Instrumented Systems (SIS) by nature have different
enables rapid and practical visualisation of the flow of data and security requirements to the other components of an
information from the lowest levels (sensors and actuators) to the industrial control system.
services that the OT environment shares with the IT environment.
Once the SuC has been modelled, the grouping of industrial III. The assets or devices that are temporarily
assets in zones and conduits should be a consequence of the connected to the SuC must be placed in separate
aforementioned criteria (functionality, location, organisation, zones.
supervisors and results of the risk analysis, etc.), without Devices that may connect to the SuC, such as maintenance
losing sight of the fact that the main focus of this process is to staff laptops, portable cybersecurity analysis devices
contribute to the implementation of a cybersecurity programme. (performance analysis tools based on network traffic capture)
As such, the result of the segmentation into zones and conduits and USB storage devices, among others, are often exposed
must be primarily based on the identification of those assets to a much greater number of threats than those which are
that have common cybersecurity requirements. permanently located within a zone. For that reason, these
The following attributes should be documented for each zone devices must be modelled in a separate zone. The main
and conduit: reason for this is that, as they are temporarily-connected
devices, it is likely that they also connect to other networks
1. Name and unique identifier. outside of the zone whose cybersecurity requirements are
2. Logical limits. less stringent than those established for the zone.
3. Physical limits. IV. Wireless communications should be located in one
4. List of all points of access to the system associated with or more zones, separate from wired communications.
the limits and devices.
Wireless communications are not controlled by fences, walls
5. List of data flows in access points.
or cabinets, and therefore have a higher level of exposure
6. Connected zones and conduits. than wired communications.
7. List of associated assets and consequences (if a prior risk
analysis has already been carried out).
8. Target security levels.
9. Applicable security policies.
10. External dependencies hypothesis.
ENTERPRISE
WLAN Web server
Interprise firewall
Internet
Date Historian Mainternace Workstation PLANT DMZ

Domain controller
CONTROL CENTER
Domain controller
SIS BPCS Enginnering

BPCS
workstation IAMS
SIS-HMI
SIS Enginnering
workstation
IAMS
Domain controller
Handhold programmer
Serial or
Ethermet
FS-PLC Control-PLC BPCS HMI
Discrete
24 VCD 24 VCD
Block valve 4-20 mA 4-20 mA
Control valve
Pump controller
Transmiter Transmiter
Figure 6 - High-level model for industrial processes.

Source: ISA99/IEC 62443-1-1
3.4. REFERENCE MODELS

The following are included as an example, and to assist in an initial definition of zones and conduits, the high-level reference
models proposed by different sources are provided below:
3.4.1. DuPont reference architecture
Figure 7. Dupont high-level model.

3.4.2. Example of a refinery according to Tofino Security (a Belden Company)
Figure 8. Tofino Security high-level model.
3.4.3. Honeywell reference architecture
Figure 9. Honeywell high-level model.

3.4.4. Rockwell reference architecture
Figure 10. Rockwell high-level model.

3.4.5. Siemens reference architecture
Figure 11. Siemens high-level model.

4
Security Levels
4.1. WHAT ARE SECURITY 4.2. TYPES OF SECURITY

LEVELS? LEVELS
The ISA99/IEC 62443 standard defines security levels as According to this standard, three types of security levels can
follows: be identified:
“Security levels (SL) provide a qualitative approach for › Target security level (SL-T): The desired security level
cybersecurity in a specific zone. As it is a qualitative method, for a particular system. This is usually specified through
the definition of security levels serves to compare and manage the performance of risk assessments which determine the
security for different zones within an organisation.” required security level to ensure correct operation.
› Achieved security level (SL-A): The current security
level for a particular system. This is measured once the
system design is available or when a system has already
been installed. It is used to establish whether the system’s
security reaches the defined levels according to the SL-T.
› Capability security level (SL-C): The security levels
that the components or systems are able to provide when
they are configured correctly. These levels enable us
to determine whether a particular system is capable of
reaching the target security level (SL-T) natively, without
compensating measures or additional countermeasures,
when it is configured and integrated correctly.
4.3. HOW TO USE SECURITY The following figure outlines this process:
LEVELS? PLANT ENVIRONMENT

When designing a new system or analysing the cybersecurity
of an existing system, the first step is to segment the system
into different zones and define the conduits that link them. REQUIRED
RISK ASSESSMENT
PROTECTION LEVEL
Once the zone and conduit model has been established, an
SL-T (target security level) must be assigned to each zone and
conduit. Once the SL-T has been determined, the system can
be designed or redesigned to achieve that level. ZONES AND CONDUITS
SYSTEM ARCHITECTURE
During the design process or adaptation, it is necessary to SOLUTION
Target SLs
assess the security capabilities of each component or Achieved SLs
sub-system. The product suppliers or integrators will provide

this information as part of their tasks. This information is
extremely useful because it enables us to determine whether a
component or system is capable of reaching the desired target CAPABILITY SLs
CONTROL SYSTEM CONTROL SYSTEM
security level (SL-T). It is likely that, in a particular design, there CHARACTERISTICS
are some components or systems that cannot reach the SL-T.

In cases in which the capability security level (SL-C) of these
components or systems is lower than the SL-T, compensating INDEPENDENT FROM PLANT ENVIRONMENT
measures or countermeasures must be considered to reduce
this gap. Such countermeasures may require changes in design Figure 12 - How to use security levels?
and even the selection of additional components. Each time a Source: ISA99/IEC 62443-3-3
modification is introduced in industrial systems, their security
level must be assessed, thus obtaining the achieved security
level (SL-A), which can then be compared with the SL-T.
4.4. SECURITY LEVEL VECTOR 4.4.3. 4.4.3 Security levels vector format
A vector can be used to depict the cybersecurity requirements
for a zone, conduit or system in a more representative way
4.4.1. Fundamental cybersecurity than a single value. The vector contains a specific value
requirements for the security levels defined for each of the fundamental
Security levels are based on the seven fundamental requirements requirements. (See 4.4.1)
defined in the ISA-62443-1-1 document.
The format used is as follows:
These requirements are:
SL-?([FR,]domain) = { IAC UC SI DC RDF TRE RA }
1. Identification and authentication control (IAC)
Where:
2. Use control (UC)
3. System integrity (SI) SL-? = (Required) Represents the type of SL (see 4.2). The
possible values are:
4. Data confidentiality (DC)
5. Restricted data flow (RDF) › SL-T = Target security level
6. Timely response to events (TRE) › SL-A = Achieved security level
7. Resource availability (RA) › SL-C = Capability security level
[FR] = (Optional) Field that indicates the fundamental
Instead of representing the assigned security level with a single
requirements (FRs) that each SL represents. The FRs are
value, it is possible to use a security level vector which
represented by abbreviations in accordance with the acronyms
represents the security levels defined for each of the seven
provided in point 4.4.1 to facilitate their interpretation.
fundamental requirements.
Domain = (Required) Represents the domain to which the SLs
4.4.2. Definition of security levels are applied. A domain can be a particular zone, a conduit, a
control system or a specific component. Some examples of
The ISA99/IEC 62443 standard defines security levels on a different domains in “Figure 6 - High-level model for industrial
five-point scale (0, 1, 2, 3 and 4), each of which represents an processes” may include: “SIS zone”, “BPCS zone”, BPCS HMI”,
incremental level in terms of cybersecurity measures. “Plant DMZ”, etc.
The defined security levels are as follows: › Example 1 – SL-T(BPCS Zone) = { 2 2 0 1 3 1 3 }
› SL 0: Does not set specific requirements or specify › Example 2 – SL-C(SIS Zone) = { 3 3 2 3 0 0 1 }
cybersecurity protections. › Example 3 – SL-C(RA, BPCS HMI) = 4
› SL 1: Requires protection against casual violations.
Note: Example 3 only defines security level 4 for the RA
› SL 2: Requires protection against intentional violations (resource availability) fundamental requirement in BPCS HMI.
with low resources, general knowledge and low motivation.
› SL 3: Requires protection against intentional violations with
sophisticated resources, specific knowledge of automation
and control systems, and moderate motivation.
› SL 4: Requires protection against intentional violations
with sophisticated resources, advanced knowledge of
automation and control systems, and high motivation.
5
Guide for the
Definition of
Security Levels
The ISA99/IEC 62443 standard establishes a practical guide on

how to implement protective measures against cybersecurity
incidents based on the previously-defined security levels for
each zone and/or conduit, grouped into seven fundamental
“technical” cybersecurity requirements, which, as has been
mentioned, are as follows:
1. Identification and authentication control (IAC)
2. Use control (UC)
3. System integrity (SI)
4. Data confidentiality (DC)
5. Restricted data flow (RDF)
6. Timely response to events (TRE)
7. Resource Availability (RA)
The following seven tables show the controls proposed by

the standard for each of the seven fundamental cybersecurity
requirements. The tables are composed of “Security
Requirements (SR)” and “Requirement Enhancements (RE)”:
SRs and REs SL-1 SL-2 SL-3 SL-4

FR 1 - IDENTIFICATION AND AUTHENTICATION CONTROL (IAC)
SR 1.1 - Human users identification and authentication
RE (1) Unique identification and authentication
RE (2) Multifactor authentication for untrusted networks
RE (3) Multifactor authentication for all networks
SR 1.2 - Software process and device identification and authentication
SR 1.3 - Account management
RE (1) Unified account management
SR 1.4 - Identifier management
SR 1.5 - Authenticator management
RE (1) Hardware Security for software process identity credentials
SR 1.6 - Wireless access management


SR 1.7 - Strength of password-based authentication
RE (1) Password generation and lifetime restrictions for human users
RE (2) Password lifetime restrictions for all users
SR 1.8 - Public key infrastructure certificates
SR 1.9 - Strength of public key authentication
RE (1) Hardware security for public key authentication
SR 1.10 - Authenticator feedback
SR 1.11 - Unsuccessful login attempts
SR 1.12 - System use notification
SR 1.13 - Access via untrusted networks
RE (1) Explicit access request approval
FR 2 - USE CONTROL (UC)

SR 2.1 - Authorization enforcement
RE (1) Authorization enforcement for all users
RE (2) Permissions mapping to roles
RE (3) Supervisor override
RE (4) Dual approval
SR 2.2 - Wireless use control
RE (1) Identify and report unauthorised wireless devices
SR 2.3 - Use control for portable and mobile devices
RE (1) Enforcement of security status of portable and mobile devices
SR 2.4 - Mobile code


RE (1) Mobile code integrity check
SR 2.5 - Session lock
SR 2.6 - Remote session termination
SR 2.7 - Concurrent session control
SR 2.8 - Auditable events
RE (1) Centrally managed, system-wide audit trail
SR 2.9 - Audit storage capacity
RE (1) Warn when audit record storage capacity threshold reached
SR 2.10 - Response to audit processing failures
SR 2.11 - Timestamps
RE (1) Internal time synchronisation
RE (2) Protection of time source integrity
SR 2.12 - Non-repudiation
RE (1) Non-repudiation for all users
FR 3 - SYSTEM INTEGRITY (SI)

SR 3.1 - Communication integrity
RE (1) Cryptographic integrity protection
SR 3.2 - Malicious code protection
RE (1) Malicious code protection on entry and exit points
RE (2) Central management and reporting for malicious code protection
SR 3.3 - Security functionality verification
RE (1) Automated mechanisms for security functionality verification
RE (2) Security functionality verification during normal operation


SR 3.4 - Software and information integrity
RE (1) Automated notification about integrity violations
SR 3.5 - Input validation
SR 3.6 - Deterministic output
SR 3.7 - Error handling
SR 3.8 - Session integrity
RE (1) Invalidation of session IDs after session termination
RE (2) Unique session ID generation
RE (3) Randomness of session IDs
SR 3.9 - Protection of audit information
RE (1) Audit records in single writing media

FR 4 - Data Confidentiality (DC)
SR 4.1 - Information confidentiality

RE (1) Protection of confidentiality at rest or in transit via untrusted
networks
RE (2) Protection of confidentiality across zone boundaries
SR 4.2 - Information persistence
RE (1) Purging of shared memory resources
SR 4.3 - Use of cryptography

FR 5 - Restricted data flow (RDF)
SR 5.1 - Network segmentation
RE (1) Physical network segmentation
RE (2) Independence from non-control system networks
RE (3) Logical and physical isolation of critical networks
SR 5.2 - Zone boundary protection


RE (1) Deny by default, allow by exception
RE (2) Island mode
RE (3) Fault-closing
SR 5.3 - General purpose person-to-person communication restrictions

RE (1) Prohibit all general purpose person-to-person
communications
SR 5.4 - Application partitioning
FR 6 - Timely Response to Events (TRE)
SR 6.1 - Audit log accessibility
RE (1) Programmatic access to audit logs
SR 6.2 - Continuous monitoring

FR 7 - Resource Availability (RA)
SR 7.1 - Denial of service (DoS) protection
RE (1) Manage communications load
RE (1) Limit DoS effects to other systems or networks
SR 7.2 - Resource management
SR 7.3 - Control system backup
RE (1) Backup verification
RE (2) Backup automation
SR 7.4 - Control system recovery and reconstitution
SR 7.5 - Emergency power
SR 7.6 - Network and security configuration settings
RE (1) Machine-readable reporting of current security settings
SR 7.7 - Least functionality
SR 7.8 - Control system component inventory

6
Final Comments
and Conclusion
While seemingly trivial or basic concepts, zones and conduits

constitute a fundamental component to initiate the process of
creating a cybersecurity programme based on the IEC 62443
standard. Correct segmentation into zones and conduits will
enable industrial systems to be analysed in an orderly and
systematic manner from a cybersecurity perspective. Instead
of analysing processes, sub-processes, systems and/or sub-
systems and their corresponding components, we can focus our
efforts on implementing protective measures, targeting these
elements in each zone and/or conduit that is identified. The
standard is very clear in this regard, defining seven fundamental
cybersecurity requirements which become more rigorous as we
progress through the four proposed security levels.
Incorporating the concepts of zones and conduits in the
conception of industrial systems is of great value. The design
of industrial control systems should be based on these
concepts, and manufacturers should specify the capability
security levels (SL-C) for each component and/or system of the
proposed solution. There are currently specialised bodies (such
as ISASecure) that collaborate on this type of specification,
certifying that particular products meet the fundamental
requirements for a certain SL-C when installed correctly
according to the manufacturer’s specifications.
On this basis, the owners of industrial infrastructure can
request that manufacturers and/or integrators adapt their
proposals, or implement additional protective measures to
comply with the necessary requirements to achieve the target
security level (SL-T).
The IEC 62443 standard provides a common language and/
or point of reference from which owners, manufacturers and
integrators can work together in an orderly manner to improve
cybersecurity in industrial environments.
This document aims to clearly identify a starting point to initiate
the continuous process of protecting industrial systems against
cyber threats.
7
Glossary of Terms
and Acronyms
› Zone: A set of logical or physical assets that share

common security requirements. The limits of each zone
must be clearly established. The zones may be organised
hierarchically, i.e. a zone may be the result of a grouping
of sub-zones.
› Conduit: Communication channel between two security
zones. It provides the security functions that enable
two zones to communicate securely. All communication
between different zones must be carried out via a conduit.
› Channel: Communication link established within a conduit.
› SuC: System under Consideration
› SL: Security Level
› SL-T: Target Security Level
› SL-A: Achieved Security Level
› SL-C: Capability Security Level
› IAC: Identification and Authentication Control
› UC: Use Control
› SI: System Integrity
› DC: Data Confidentiality
› RDF: Restricted Data Flow
› TRE: Timely Response to Events
› RA: Resource Availability
› FR: Fundamental Requirements for Cybersecurity
› SR: Security Requirements
› RE: Requirement Enhancement
› SIS: Safety Instrumented System
› BPCS: Basic Process Control System
› HMI: Human Machine Interface
› DMZ: Demilitarised Zone
8
Bibliography
[1] ANSI/ISA 62443 1 1-2007, Security for industrial automation

and control systems: Terminology, concepts and models
[2] ANSI/ISA TR62443 1 2, Security for industrial automation
and control systems: Master glossary of terms and abbreviations
[3] ANSI/ISA 62443 3 2, Security for industrial automation and
control systems: Target security levels for zones and conduits
[4] ANSI/ISA 62443 3 3, Security for industrial automation
and control systems: System security requirements and
security levels
Paseo de las Delicias, 30 · 2º piso
28045 MADRID
+34 910 910 751
info@CCI-es.org
www.CCI-es.org
blog.CCI-es.org
@info_CCI

Establishing Zones and Conduits

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Establishing Zones and Conduits

Caricato da

Copyright:

Formati disponibili

INDUSTRIAL CYBERSECURITY CENTER

ICC working paper series.

Edition: july 2018

3 ZONES AND CONDUITS 15

5 GUIDE FOR THE DEFINITION OF SECURITY LEVELS 31

6 FINAL COMMENTS AND CONCLUSION 37

7 GLOSSARY OF TERMS AND ACRONYMS 39

Expert in industrial cybersecurity with demonstrable

From industry 1.0 to industry 4.0 Degree of complexity

First Industrial Second Industrial Third Industrial Fourth Industrial

First programmable logic

1900 2000 Present

Figure 1. Evolution of industrial automation.

HIGH-LEVEL RISK ASSESSMENT

DETAILED RISK ASSESSMENT

Figure 2. Industrial cybersecurity lifecycle. Figure 3. Assessment phase.

Table 1. Example of a zone asset inventory.

SL-T SL-A SL-C

TELEMONITORING COMPONENT COMMUNICATION COMPONENTS CONTROL COMPONENTS

Name of IP address IP address

When defining a zone, we are clearly delimiting a specific

Figure 4 - Example of zones.

3.3. DEFINITION OF ZONE AND CONDUIT REQUIREMENTS

3.3.2. Diagram of zones and conduits

LEVEL 2 Site monitoring and Automation and

LEVEL 1 Basic control

LEVEL 0 CORPORATE SYSTEMS

Figure 5. High-level ISA999/IEC 62443-1-1 model.

Date Historian Mainternace Workstation PLANT DMZ

SIS BPCS Enginnering

Figure 6 - High-level model for industrial processes.

3.4. REFERENCE MODELS

3.4.1. DuPont reference architecture

Figure 7. Dupont high-level model.

3.4.2. Example of a refinery according to Tofino Security (a Belden Company)

Figure 8. Tofino Security high-level model.

3.4.3. Honeywell reference architecture

Figure 9. Honeywell high-level model.

3.4.4. Rockwell reference architecture

Figure 10. Rockwell high-level model.

3.4.5. Siemens reference architecture

Figure 11. Siemens high-level model.

4.1. WHAT ARE SECURITY 4.2. TYPES OF SECURITY

LEVELS? PLANT ENVIRONMENT

sub-system. The product suppliers or integrators will provide

are some components or systems that cannot reach the SL-T.

The ISA99/IEC 62443 standard establishes a practical guide on

The following seven tables show the controls proposed by

SRs and REs SL-1 SL-2 SL-3 SL-4

SR 1.1 - Human users identification and authentication

RE (1) Unique identification and authentication

RE (2) Multifactor authentication for untrusted networks

RE (3) Multifactor authentication for all networks

SR 1.2 - Software process and device identification and authentication

RE (1) Unique identification and authentication

SR 1.3 - Account management

RE (1) Unified account management

SR 1.4 - Identifier management

SR 1.5 - Authenticator management

RE (1) Hardware Security for software process identity credentials

SR 1.6 - Wireless access management

SRs and REs SL-1 SL-2 SL-3 SL-4

SR 1.7 - Strength of password-based authentication

RE (1) Password generation and lifetime restrictions for human users