Training - Day 2 v1.3

Day 2
Introduction of ISA/IEC 62443-3-2

Functional Safety and Cyber Security co-engineering
(IEC 63069)
Case Study
You should have received Day Two materials via email yesterday.
CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 1

Day 2 Agenda
RISK ASSESSMENT METHODOLOGY, PROCESS AND CASE STUDY (PART 3-2)
Time Topic and Content Time Topic and Content

09:00 am – Introduction of ISA/IEC 1 hour Lunch Break
10:30 am 62443-3-2 13:00 pm – Functional Safety and Cyber
- Zone and Conduit
14:30 pm Security co-engineering (IEC
Requirements (ZCRs)
63069)
15 mins Break - Framework for functional
10:45 am – Introduction of ISA/IEC safety and cybersecurity
- How to conduct cybersecurity-
12:00 pm 62443-3-2 (cont’d)
- related analysis during the
Information gathering
development of safety-related
process
- systems
Risk assessment
methodologies for Industrial 15 mins Break
Control Systems
- Reporting and documentation
14:45 pm – Case Study
16:00 pm - Mock risk assessment on a
scale down/modular RTS
system
CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL

16:00 pm – Case Study 2
17:00 pm - Cyber Risk Scenario leads to
Recap of Day One

High Level Objectives and Scope
Objectives
• Provide an understanding of the guiding principles of the IEC 62443 standard and how it
can be applied to secure Operational Technology (OT) systems; and
• Ensure that the participants are equipped with the standard’s applicable and relevant
knowledge for securing their respective projects during the planning, design and
implementation phases.
Scope
• 62443-1-1 – Concepts and Models
• 62443-3-2 – Security Risk Assessment and System Design
• 62443-3-3 – System Security Requirements and Security Levels
• 62443-4-2 – Technical Security Requirements for IACS Components
4
Overview of ISA/IEC
62443 Standards Family
In
Published Developme
nt
(status)
In In
Under
Developme Published Published Developme
revision
nt nt
Published Published Published
Published Published

IEC 62443 – Security Level and Maturity Level
Evaluation of processes (Maturity Level) Evaluation of Technology (Security Level)
Improving: Using suitable process metrics, product suppliers control the effectiveness and
ML 4 performance of the product and demonstrate continuous improvement in these areas. Protection against intentional violation using sophisticated means with
SL 4 extended resources, IACS specific skills and high motivation.
Defined (Practiced): The process is repeatable across the supplier’s organization. The processes Protection against intentional violation using sophisticated means with
ML 3 have been practiced, and evidence exists to demonstrate that this has occurred. SL 3 moderate resources, IACS specific skills and moderate motivation.
Managed: The product supplier has the capability to manage the Protection against intentional violation using simple means with low
ML 2 development of a product according to written policies. Evidence to show that personnel who will SL 2 resources, generic skills and low motivation.
perform the process have the expertise, are trained and/or follow written procedures. Processes are
repeatable.
SL 1 Protection against casual or coincidental violation.

Initial: Product suppliers typically perform product development in an adhoc
ML 1 and often undocumented (or not fully documented) manner.
Quality Resilience
IEC 62443- IEC 62443- IEC 62443- IEC 62443- IEC 62443-
2-1 2-4 4-1 3-3 4-2
Edition 2

Foundational Requirements (FR)
• CIA model is not adequate for a full understanding of the requirements for IACS.
•Foundational Requirements (FRs) form the basis for technical requirements throughout the ISA/IEC
62443 Series.
Identification and
Control access to selected devices, information or both to protect
FR 1 Authentication
against unauthorized interrogation of the device or information.
Control (IAC)
Control use of selected devices, information or both to protect against
FR 2 Use Control (UC)*
unauthorized operation of the device or use of information.
Ensure the integrity of data on selected communication channels to
FR 3 Data Integrity (DI)
protect against unauthorized changes.
Data Confidentiality Ensure the confidentiality of data on selected communication channels
FR 4
(DC) to protect against eavesdropping.
Restrict Data Flow Restrict the flow of data on communication channels to protect against
FR 5
(RDF) the publication of information to unauthorized sources.
Respond to security violations by notifying the proper authority, reporting
Timely Response to
FR 6 needed forensic evidence of the violation, and automatically taking
Event (TRE)
timely corrective action in mission-critical or safety-critical situations.
Resource Availability Ensure the availability of all network resources to protect against denial
FR 7 \\ ENSIGN INFOSECURITY | CONFIDENTIAL
CONSULTING 7
(RA) of service attacks.
Risk
Risk: Expectation of loss expressed as the probability that a particular threat will exploit
a particular vulnerability with a particular consequence.
Severity: Loss of Availability and/or Data Integrity has direct impact and loss of
Confidentiality has indirect impact on Functional safety. (SAIC)
Probability: Likelihood of an event occurring takes into account both the

likelihood that a threat that could cause an action will be realized and the
likelihood that a vulnerability that allows the action will in fact be exploited by
the threat.
𝑅𝑖𝑠𝑘=𝑆𝑒𝑣𝑒𝑟𝑖𝑡𝑦 × 𝐿𝑖𝑘𝑒𝑙𝑖h𝑜𝑜𝑑𝑇h𝑟𝑒𝑎𝑡 𝑅𝑒𝑎𝑙𝑖𝑧𝑒𝑑

× 𝐿𝑖𝑘𝑒𝑙𝑖h𝑜𝑜𝑑𝑉𝑢𝑙𝑛𝑒𝑟𝑎𝑏𝑖𝑙𝑖𝑡𝑦 𝐸𝑥𝑝𝑙𝑜𝑖𝑡𝑒𝑑

Risk Tolerance and Residual Risk
Residual Acceptabl Original

Risk e Risk Risk
Risk = Severity x LikelihoodThreat x
LikelihoodVulnerability
Risk
k
is
Necessary risk
R
reduction
Actual risk
reduction
Severity
Risk reduction
re at
Th
Residual Risk
 The risk exposure after risk mitigating controls are Residual Risk Acceptable Risk
considered Likelihood
Acceptable Risk Vul

n era
bili
ty
 Level of residual risk that is acceptable to an
organization

Zones and Conduits
Zone is defined as groupings of logical or physical assets based upon risk or other criteria
such as criticality of assets, operational function, physical or logical location, required
access, or responsible organization.
Conduit is defined as logical groupings of communication channels that share common
security requirements connecting two or more zones.
Control Center
C1 C2
Industrial Control The intent is to identify those
Systems C3 assets which share common
security characteristics in
order to establish a set of
S1 R1 R2 ICS1 common security requirements
that reduce cybersecurity risk.
Zone 1 Conduit Zone 2, Safety functions

Business-related activities needed
to manage a manufacturing
organization.
Reference Model (Purdue Model) e.g. production scheduling,
operational management,
maintenance management
Managing the work flows to
produce the desired end product.
e.g. dispatching production,
detailed production scheduling,
reliability assurance, site-wide
control optimization.
Monitoring and controlling the
physical process.
e.g. operator human-machine
interface, operator alarms and
alerts, process history collection,
supervisory control functions.
Sensing and manipulating the
physical process.
e.g. DCS controllers, PLCs, RTUs
Actual physical process
e.g. sensors and actuators.
Models for Zones and Conduits
Reference models: overall conceptual basis
Asset models: relationships between assets

within an IACS
A reference architecture: the configuration

of assets. It is unique for each situation
depending on the scope of the IACS under
review.
Zone and Conduit Model: groups reference

architecture elements according to defined
characteristics. This provides a context for
the definition of policies, procedures, and
guidelines, which in turn are applied to the
assets.

Introduction of
ISA/IEC 62443-3-2

Why risk assessment is important?
There is no simple recipe for how

to secure an IACS therefore
security is a matter of Risk
Management.
Every IACS presents a different

risk to the organization
depending upon:
• the threats it is exposed to,
• the likelihood of those threats
arising,
• the inherent vulnerabilities in
the system,
• The consequences if the
system were to be
compromised.
Every organisation has a different

tolerance for risk.

Relevance to Cybersecurity Act
The Cybersecurity Bill was passed on 5 Feb 2018 and received the President’s assent on 2 Mar 2018 to become the Cybersecurity
Act:
1. Strengthen the protection of Critical Information Infrastructure (CII) against cyber-attacks.
2. Authorise CSA to prevent and respond to cybersecurity threats and incidents.
3. Establish a framework for sharing cybersecurity information.
4. Establish a light-touch licensing framework for cybersecurity service providers.
CCOP is a list of Codes of Practice or Standards of Performance issued by the Commissioner of Cybersecurity for the regulation
of owners of Critical Information Infrastructure (CII) in accordance to the Cybersecurity Act.
https://www.csa.gov.sg/Legislation/Cybersecurity-Act

ISA/IEC 62443-3-2: Security risk assessment for system design
• Defines a set of engineering measures that will guide an organization through the process of
assessing the risk of a particular IACS, identifying and applying security countermeasures to
reduce the risk to tolerable levels.
• Audience: Asset Owner, System Integrator, Product Supplier, Service Provider, and Compliance
Authority.
• Primary Steps:
Establishi
Defining a
ng the
system Partitionin Assessing Documenti
target
under g the SUC risk for ng the
security
considerat into Zones each security
level (SL-
ion (SUC) and zones and requireme
T) for each
for an Conduits conduits nts
zone and
IACS
conduit

What is the relevance of CCOP to Security Risk Assessments (IEC
62443-3-2)?
DISCUSSION How mature is your organisation in Security Risk Assessment?
What are the risk assessment activities in your organisation?

Zone, conduit and requirements (ZCR) Workflow
The requirements introduced in ISA/IEC 62443-3-2 are referred to as zone and conduit requirements
(ZCR).

ZCR Workflow (cont.)

ZCR 1: Identify the SUC
Requirement: Clearly identify the SUC including clear delineation of the security perimeter and
identification of all access points to the SUC.
• SUC is often defined using a combination of illustrations and text.

• System Architecture diagrams
• Network diagrams
• Asset inventory
• Dataflows
• Criticality assessment, etc.
• Clearly identify the assets that are in-scope.
• Identify the perimeter and access point.
• SUC can include multiple subsystems, including emerging technologies like IIoT or cloud-based solutions.
(Instead of Process Unit, look at the device individually)

System Architecture
Illustrate the components of the system.
Illustrate connectivity.
Illustrate physical location.
Present the information following Purdue Model.

Network Diagram
• Detail how the network is physically and logically constructed.
• Individual routers, switches, firewalls are shown symbolically.
• Switch port assignments are identified.
• VLANs are documented
CISCO Network Icons

Examples of Network Diagram
Using different colours • Detail how network is physical and

to identify segmented logically constructed Network
networks • Provide configuration settings and segments by
access control list switches
• Provide legend

Asset Inventory
• Complied through documentation and site survey.
• Maintain a list or database of all hardware (physical and virtual) and software.
• Hardware: computers, network equipment, automation devices, Virtual Machines (VMs)
• Software: operation systems, applications, databases, firmware.
• Automated tools can be used but should be carefully tested.

• Network management tools: to provision, discover, monitor and maintain computer networks.
• Software Asset Management (SAM) tools: to discover software installed across the computer network and
collect software information.
• Configuration management tools.

Asset Inventory Documentation
Hardware Virtual Hardware Software

• Device or System name • VM name • Software name
• Asset ID • VM type • Software type
• Device type • Function • Function
• Function • Network interface • Hostname
• Network interface(s) • Network address • Host type
• Network address(es) • Host name / ID • Vendor
• Manufacturer • Host type • Version
• Model • Operating system and version • Responsible organisation /
• Serial Number • Responsible organisation / individual
• Operating system individual • License information
• Firmware version • Other notes • Number of license
• Responsible organisation / • License expiry

individual • Update / Patch Process
• Physical location
• Other notes

ZCR 2: Initial Cyber Security Risk Assessment
Requirement: to identify the worst case

unmitigated cyber security risk that could • Worst-case
result from the interference with, breach or Proces consequence for
disruption of, or disablement of mission critical s Unit 1 PU 1
IACS operations.
• Typically evaluated in terms of impacts to
health, safety, environmental and business
interruption, production loss, product quality,
financial, legal, regulatory, reputation, etc. • Worst-case
Proces consequence for
• Assist with the prioritization of detailed risk s Unit 2 PU 2
assessments and facilitates the zones and
conduits grouping.
• Process hazard analysis (PHA) should be
reviewed to help identify potential
consequences. Security after Safety
• Worst-case
• Scope is the entire SUC Proces consequence for
s Unit n PU n
• Results are rated using a consequence scale
(next slide)

ZCR 2: Initial Cyber Security Risk Assessment

ZCR 3: Partition the SUC into Zones and Conduits
ZCR 3.1 Establish zones and conduits

• Requirement: The organization shall establish zones and conduits by grouping related assets based upon
• the results of the initial cybersecurity risk assessment,
• criticality of assets, operational function,
• physical or logical location,
• require access, or
• responsible organization.
• To facilitate detailed cybersecurity risk assessment.
• Zones and conduits maybe adjusted.
• Special attention should be given to: SIS, wireless systems, system managed by other entities, mobile device.
ZCR 3.2 Separate business and IACS assets

• IACS assets shall be separated from business or enterprise system assets due to different functionalities,
responsible organizations, locations and results of risk assessment.
ZCR 3.2 Separate business and IACS assets

• IACS assets shall be separated from business or enterprise system assets due to different functionalities,
responsible organizations, locations and results of risk assessment.
ZCR 3: Partition the SUC into Zones and Conduits
ZCR 3.3 Separate safety related assets

• Safety related IACS assets shall be grouped into zones that are logically or physically separated from zones with
non-safety related assets.
• However, if they cannot be separated, the entire zone shall be identified as a safety related zone.
• Typically require a higher-level of security protection.
ZCR 3.4 Separate temporarily connected devices

• Devices that are temporarily connected to SUC (i.e. maintenance laptops, USB devices, etc.) are more likely
exposed to different and wider variety of threats.
ZCR 3.5 Separate wireless devices

• Wireless signals are not controlled by fences or cabinets, therefore more accessible than normal wired
networks.
ZCR 3.6 Separate devices connected via external networks

• Remote access is outside the physical boundary of the SUC.

ZCR 4: Risk Comparison
ZCR 5: Perform a Detailed Cyber Security Risk Assessment
ZCR 4.1 Compare initial risk with tolerable
• Compare initial risk to tolerable risk to determine if the initial risk is tolerable or requires further mitigation.
• ZCR 5 Requirement:
• Apply to every zone and conduit;
• Allow grouping of zones and conduits if share similar threats, consequences and/or similar assets.
• Any related Risk Assessment Methodology (ISO31000, NIST-SP800-39, ISO/IEC27005) are satisfied by the
methodology selected. The initial and detailed risk assessment methodologies should be derived from the
same framework, standard or source and has to use a consistent risk ranking scale in order to produce
consistent and coherent results.

ZCR 5.1-Identify Threats
• A list of threats that could affect the assets.
• It is important to prepare a comprehensive and realistic list of
threats in order to perform a security risk assessment.
• A threat description should include:
• A description of threat source
• A description of the capability or skill-level of the threat source
• A description of possible threat vectors
• An identification of the potentially affected assets.
• Example:
• A non-malicious employee opens a phishing email
compromising their access credentials.
ZCR 5.2-Identify Vulnerabilities

• Identify and document the known vulnerability in the assets
• In order for threats to be successful, they exploit one or more
vulnerabilities in an asset.
• A general accepted approach is to perform a vulnerability
assessment.
• Additional sources: ICS-CERT, IACS vendors, etc.
ZCR 5.3-Determine Consequence and impact

• Evaluate each threat scenario to determine the consequence and
the impact.
• Consequences should be documented in terms of the worst-case
impact on risk areas such as personnel safety, financial loss,
business interruption and environment.
• It is important input in performing the cost/benefit analysis of
security controls.*
• Existing PHA and other related risk assessments should be
reviewed to assist in determining consequences and impact.
• Consequence scale defined by the organization as part of their risk
CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL management system. 31
Example Consequence Scale
Each category will be scored but only the highest will be used in risk ranking.
Consequence
Risk Areas
Environmental
Biz Continuity Planning Information Security Process Safety
Safety
Mfg.Outage-
Mfg.Outage- Public People-
Category multiple Cost Legal People-on site Environment
one site Confidence off site
sites
Citation by
Fatality
Regional/national
or Major
> $500 Criminal Loss of Agency or long-
High > 7days > 1day Fatality Commun
million Offense-Felony Brand Image term, significant
ity
damage over
Incident
large area
Complai
nts or
Criminal Loss of
>$5 Lost workday or Local Citation by Local
Medium < 2days > 1hour Offense- Customer
million major injury Commun Agency
Misdemeanor Confidence
ity
Impact
No Small, contained
CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL <$5 First Aid or 32
Low < 1 day < 1hour None None Complai release below
million recordable injury
ZCR5.4-Determine unmitigated likelihood (UTL)
• Evaluate each threat and vulnerability pair to determine the
unmitigated likelihood that the threat will be realized.
• The measure of likelihood may be qualitative or quantitative. One
method is to use a likelihood scale that is defined by the
organization as part of their risk management system.
• Factors considered:
• Motivation and capability of the threat source,
• History of similar threats
• Known vulnerabilities
• Attractiveness of the target
• Existing cybersecurity countermeasures should NOT be considered
when determining unmitigated likelihood. However, the likelihood
determination recognizes any non-cyber independent protection
layers (IPLs)* such as physical security or mechanical safeguards
that are in place to reduce the likelihood.
• Example of likelihood scale
ZCR 5.5-Determine unmitigated cybersecurity risk

• For each threat, the unmitigated cybersecurity risk shall be
determined by combining the impact measure and unmitigated
likelihood measure.
• Risk matrix establishes the relationship between likelihood, impact
CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL and risk. 33
Risk Matrices (Annex B)
• Risk is the combination of likelihood and impact.

• Typically “calculated”/”look-up” using a Risk Matrix.

ZCR 5.6-Determine target security level (SL-T)
• A SL-T shall be established for each security zone and conduit.
• Clearly communicate the desired level of security to those
responsible for designing, implementing, operating and maintaining
cybersecurity.
• There is no prescribed method for establishing SL-T.
• Some organizations chose to establish SL-T based upon the
difference between the unmitigated cyber security risk and
tolerable risk.
• Cyber Risk Reduction Factor (CRRF)= Unmitigated
Risk/Tolerable Risk
• Others elect to establish SL-T based on the SL definitions.
• OR, if a risk matrix is used, the cyber security risk is
evaluated by the risk matrix taking into account the
countermeasures implied by the SL. If the risk is not
acceptable, then the SL is raised (more countermeasures in
place) until the cyber security risk is acceptable. The SL
derived from this analysis becomes SL-T.
• SL-T may be expressed as a single value or a vector. (Refer to Part
ZCR 5.7-Compare unmitigated risk with tolerable risk
3-3)
• To determine if the unmitigated risk is tolerable or requires further
evaluation.
ZCR 5.8-Identify and evaluate existing countermeasures

• To determine the effectiveness of the countermeasures to reduce
the likelihood or impact.
• Part 3-3 provides guidance on types of countermeasures and their
effectiveness by assigning a security level capability (SL-C) to
each system requirement.

ZCR5.9-Reevaluate likelihood and impact
• Reevaluate likelihood (MTL: mitigated likelihood) and impact
considering the countermeasures and their effectiveness.
ZCR5.10-Determine residual risk

• The residual risk for each threat shall be determined by combining
the mitigated likelihood measure and mitigated impact values.
• Provides a measure of the current level of risk as well as a
measure of the effectiveness of existing countermeasures.
UTL
ZCR 5.11-Compare residual risk with tolerable risk
• Residual risk shall be compared to the organization’s tolerable risk.
If the residual risk exceeds the tolerable risk, the organization shall
determine if the residual risk will be accepted, transferred or
mitigated based upon the organization’s policy.
ZCR5.12-Identify additional cybersecurity countermeasures

Likelihood
• Additional cybersecurity countermeasures such as technical,
and impact
are evaluated administrative or procedural controls shall be identified to mitigate
twice the risks.
• Unless the organization has elected to tolerant or transfer the risk
MTL • Part 3-3 can be used as a guide to select appropriate technical
countermeasures.
• Users may also want to evaluate the cost and complexity of
countermeasures as part of design process.
ZCR5.13-Document and communicate results

• The results of the risk assessment shall be documented, reported
and made available to appropriate stakeholders in the organization.
• Made available to the appropriate personnel in the organization
• Living documents for multiple purposes (testing, auditing and
future risk assessments)
• However, it is also important to properly protect this information.
UTL: unmitigated
likelihood
MTL: mitigated
Example of Detailed Risk Assessment S: Safety likelihood
E:
for Existing System Environment
ATL: achieved
likelihood
al
F: Finance
R: Reputation
Prepare a list of threat and vulnerabilities
Can be prepared before enter a risk assessment

ZCR 6: Cyber Security Requirements Specification (CRS)
• Requirement: for documenting cyber security requirements, assumptions and constraints within
the SUC as needed to achieve the SL-T and provides rationale and supplemental guidance for each
requirement.
• A CRS shall be created to document mandatory security countermeasures ofGrouping of

the SUC based on the outcome
Requirements:
of the detailed risk assessment as well as general security requirements based upon company or site-
specific policies, standards and relevant regulations. • Access Control
requirements
• At a minimum, A CRS shall include:
• Identification and
authentication of
• SUC description
users
• Zone and Conduit drawings
• User roles and
• Zone and conduit characteristics
privileged
• Operating environment assumptions: where SUC is located or planned to be located. • User
• Threat environment Administration
• Organizational security policies • Confidentiality,
• Tolerable risk Integrity and
• Regulatory requirements Availability
requirements
CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL • Monitoring and 38
ZCR 7: Asset Owner Approval
• Requirement: asset owner

management who are
accountable for the safety,
integrity and reliability of the
process controlled by the SUC
shall review and approve the
results of the risk assessment.
• Personnel who perform the

risk assessment typically do
not have the authority to
make decisions to accepts
risk.

How are ZCR activities carried out in your organisation?
DISCUSSION
How are the ZCR outputs accepted in your organisation?

Functional Safety and
Cyber Security co-
Engineering (IEC
63069)

Industry 4.0 – Smart Factory Automation (IIoT)

OT & IT Worlds
OT
Value IT
(M/Bln $)
Value
(k/M $)
Service Life
(20-30 years) Service Life
(..10 years ?)
New Tech
Legacy (short/medium lifecycle,
Technologies 3-5 yrs)
(long lifecycle)
1980… 2000…2010
2000..2010...2020 (IIoT)...2020

OT
Value IT
(M/Bln $)
Service Life
Value
(k/M $)
(20-30 years) Distance between OT(Safety) and IT(Security) domains

Service Life
(..10 years ?)
Years
Legacy Priorities New Tech
Technologies Mindset (short/medium lifecycle,
Work style 3-5 yrs)

(long lifecycle) ……
Disconnected!
Availability
Confidentiality
Integrity
Integrity Confidentialit
Availability y
Physical Safety!

Need to integrate Safety and Security

OT We should be at
least here!
Value IT
(M/Bln $)
Value
Service Life (k/M $)
(20-30 years) Service Life

(..10 years ?)
Legacy New Tech

(short/medium lifecycle,
Technologies 3-5 yrs)
(long lifecycle)
Availability
Confidentiality Integrity
Confidentialit
Integrity
y
Availability
Physical Safety!
Functional Safety & Industrial Cyber Security Co-Engineering
Purdue Reference Model Cyber Threats
(intentional, unintentional)
(days)
IT World
Cyber Threats
(unintentional, intentional)
(hrs)
OT World (secs / mins)
(μs / ms)
(0 / μs)
Basic Process Control System Safety Instrumented
(BPCS) System
CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL (SIS) 47
“Functional Safety” refers to the “OT Security” refers to the

operational safety of a system protection of Operational
with respect to: Technology against losses caused
1) Safety (physical) by cyber threats.
2) Health Losses (intentional, or
3) Environment unintentional):
4) Availability of system for user 1) Business
2) Financial
3) Operational
4) Brand image
CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 5) Safety 48
6) …

IEC TR 63069: Industrial-process measurement, control and automation – Framework for
functional safety and security
Purpose
Terms "safety" and "security" are sometimes used for different meanings in these documents. As a result, it can be difficult to apply them holistically at the
same.
Background
Considerable concerns arose with respect to the impacts of security incidents to safety functions in IACS
(industrial automation and control systems). Many complex systems of that kind are becoming connected systems
(particularly by interaction based on wireless connectivity from sensors/actuators to complete plants, grids, etc.)
for maintenance and operations. The overall question was: "How to design and manage safety and security – in
cooperation, integrated, or separate system?"
Issues on the terminology

IACS assets shall be separated from business or enterprise system assets due to different functionalities,
responsible organisations, locations and results of risk assessment. Definitions of some terms, such as "safety",
"security" and "risk", are sometimes different in different documents. Although they are consistent in a set of
documents in each area of safety and security, they can be inconsistent when both standards are applied at the
same time. From these reasons, the terminology is carefully used in IEC 63609.

DEFINITIONS
OT+IT
OT+IT

DEFINITIONS

DEFINITIONS

Security Environment

Essential functions
=> defined in IEC 62443 (not in functional safety std. IEC
61508)
_

Functional Safety & Industrial Cyber Security Co-Engineering IEC 62443-3-3

ICS Protection Layers
Safety
Functions

Guiding Principles
Security =>Safety
Threat 1
Basic Process Control System

BPCS
Threat 2
Safety => Security
Threat 3
Threat 4

Lifecycle recommendations for co-

engineering

Life-cycle Recommendations for co-engineering

Life-cycle Recommendations for co-engineering (cont’d)

Life-cycle Recommendations for co-engineering (cont’d)

Safety and Security Risk Assessments as part of a High-Level Risk Assessment

Risk Assessment Case Study
In this exercise, we have identified an SUC for which we will conduct a risk assessment to walk through the pertinent component of the
risk assessment methodology described in IEC/ISA 62443-3-2.
Read through case study and work through the activities / questions provided in the slides. You will be given approximately 45 minutes
work through the activity. Thereafter, we will discuss the solutions as group. You will be invited to comment and share your solution /
perspectives during the discussion.
You may consider to use MS PowerPoint to draft your solutions, which may include tables or diagrams required as part of risk
assessment activities. You may share screen during the discussion.
Case Study - Introduction

Future railway systems should bring convenience to people’s lives. In fact, due to the move away from bespoke standalone systems to
open-platform, standardized equipment and increasing use of networked control and automation systems and connected technologies,
the efficiency and the safety of railway services are improving. However, this dependence of automation, control and communication
technologies makes railway systems becoming increasingly vulnerable to cyber-attacks and security threats which affects the overall
performance.
Due to time limitation, in this case study, we focus on the External Door Control (EDC) system from TCMS domain.

Risk Assessment Case Study (cont’d)
System Under Consideration – TCMS & EDC
Train Control and Monitoring System (TCMS)
The TCMS of a train is mainly responsible for providing basic train control functions, such as inaugurating the train network, determining train topology and
configuration, providing orientation information for coupled elements, managing leading vehicle information, distributing train topology and configuration,
confirming train configuration, managing train network operation, managing train network access and transmitting data. Nevertheless, with the integration of
advanced ICT in the railway industry, the TCMS is expected to manage a set of sophisticated applications not only for a more reliable train control, but also for
operator oriented services and customer comfort purposes. For operational and security purposes, control system ICT should be separated from comfort ICT,
as such the TCMS is clustered into 3 functional domains:
• Train Control and Monitoring System (TCMS) domain includes both safety related and non-safety
related TCMS functions. The functions of this domain are mandatory to ensure safe train
Task (30min):
movement and to ensure carrying the payload, such as : main control, train radio, air conditioning,
propulsion, brakes, electricity, lavatories, lighting, supporting systems, passenger announcement
system, external doors and internal doors, European Train Control System (ETCS), Automatic Based on your domain knowledge,
Train Protection (ATP), On-board Driving Data Recording System (ODDRS), passenger alarm • Draw the architecture diagram
system and Closed-circuit television (CCTV) for rear view purposes. for the three components. (Hint:
• Operator Oriented Services (OOS) domain is where all auxiliary services for proper train Zones & Conduits)
operation are considered, such as : priority logic, CCTV for video surveillance purposes,
• Identify any communications
infotainment in train embedded devices, mobile phone amplifiers, automatic passenger counting,
vehicle positioning, fare management or ticketing, driver assistance system, E-schedule, required to support the stated
diagnostics and Condition Based Maintenance (CBM) systems and Passenger Information functions or services given the in
System (PIS) (including automatic announcements). the case study
• Customer Oriented Services (COS) domain includes the functions executed by passenger • State any assumptions
devices such as: access for the passenger’s devices (e.g. Wi-Fi access points), Access to the
public internet and passenger info-portal.
This three-level modelization aims to increase the system flexibility, scalability, and adaptability for
future evolutions.

System Under Consideration – TCMS & EDC
External Door Control (EDC)
A distributed train functionality is accomplished using several function interfaces
installed within the train in an hierarchical way aiming to remotely control
processes
• one Function Leader (FL) which is responsible to control the function by
stimulation of the Function Followers (FFs) (sending commands) and to
receive the reactions from the FFs (receiving status);
• one or more Function Follower(s) (FF), at most one per consist network, which
is responsible to receive the commands from the FL and to stimulate the
Function Devices (FDs). The received reactions from the FDs are cumulated
by the FF and provided as function status of the consist to the FL;
• one or more Function Device(s) (FD), which are receiving the commands from
the FF, execute the function operations and report the results to the FF.
These parts of the application are distributed over the consists of the train.
Different parts of the application in different consists can communicate only via
the Train Control Network (TCN).
Likewise, EDC, being a distributed train application, has the same architecture
defined above. As presented in the figure, the EDC system is controlled by the
TCMS through interfaces provided by the Train Door Control Unit (DCU). The
Train DCU is then the function leader, it is the controlling part for all doors in the
train. The Consist DCU is the function follower, it is the agent for one consist.
The DCU is the function device, it is responsible for the physical door. The Door
is the physical device dedicated to the DCU. In addition to automatic control
interfaces, EDC system parts can be manipulated manually using crew
interfaces for maintenance purposes or in case of malfunctioning problems.

Tasks:
(1)Conduct a Threat Assessment against TCMS. Identify at least three different threat actors and describe how they may target TMCS.
Example:
Physical attacks - This type of threats is caused by intentional offensive actions aiming to achieve maximum distraction, disruption,
destruction, exposure, alteration, theft or unauthorized accessing of assets such as hardware or ICT connections.
(2) Conduct a Vulnerability Assessment for TCMS. Identify at least two vulnerabilities that the threats (identified in (1)) could exploit to
target TCMS.
Example:
USB ports to the operator workstation are not disabled - allowing personnel to introduce malware via USB
(3) Conduct Risk Assessment. Based on (1) and (2), carry out a risk assessment. You may use the Detailed Risk Assessment Template
provided (be careful not to overwrite the formula provided in the cells). Complete at least 3 rows.
* Do not be concerned about how the formula in the cells works
(4) Discussion.

Cyber Risk Scenario Case Study
Scenario:
Compromising a signalling system leading to a train accident

Cyber Risk Scenario Case Study (cont’d)
Tasks:
(1)Identification of Impacted Assets: Identify at least three different assets that could be exploited during this attack.
Example:
Interlocking system: - It is a set of signal apparatus placed on track in order to prevent conflicting movements among trains. In order to
make attack successful, attacker would like to malfunction interlocking system so it should not prevent an accident.
(2)Analysing the Impact: Identify at least four different impact areas and describe how they may be important for management/public.
Example:
Human casualties: - This type of threat is caused by state sponsored/terrorist offensive actions aiming to achieve maximum
destruction.
(3) Identification of Threat Vector:. Identify at least two paths that attackers could have taken to make this attack successful.
Hint: It could be physical and/or logical route to make it happen.
(4) Implement Security Measures:. Based on (1), (2) and (3), identify the possible high level security measure and how it can
implemented to prevent these types of cyberattacks.
(5) Discussion.

Thank you
© 2021 ENSIGN
©2023 ENSIGNINFOSECURITY
INFOSECURITY| CONFIDENTIAL
| CONFIDENTIAL 70

Training - Day 2 v1.3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Training - Day 2 v1.3

Uploaded by

Copyright:

Available Formats

Day 2

Introduction of ISA/IEC 62443-3-2

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 1

RISK ASSESSMENT METHODOLOGY, PROCESS AND CASE STUDY (PART 3-2)

Time Topic and Content Time Topic and Content

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 3

Published Published Published

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 5

Evaluation of processes (Maturity Level) Evaluation of Technology (Security Level)

SL 1 Protection against casual or coincidental violation.

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 6

Probability: Likelihood of an event occurring takes into account both the

𝑅𝑖𝑠𝑘=𝑆𝑒𝑣𝑒𝑟𝑖𝑡𝑦 × 𝐿𝑖𝑘𝑒𝑙𝑖h𝑜𝑜𝑑𝑇h𝑟𝑒𝑎𝑡 𝑅𝑒𝑎𝑙𝑖𝑧𝑒𝑑

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 8

Residual Acceptabl Original

Acceptable Risk Vul

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 9

Zone 1 Conduit Zone 2, Safety functions

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 10

Reference models: overall conceptual basis

Asset models: relationships between assets

A reference architecture: the configuration

Zone and Conduit Model: groups reference

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 12

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 13

There is no simple recipe for how

Every IACS presents a different

Every organisation has a different

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 14

1. Strengthen the protection of Critical Information Infrastructure (CII) against cyber-attacks.

2. Authorise CSA to prevent and respond to cybersecurity threats and incidents.

3. Establish a framework for sharing cybersecurity information.

4. Establish a light-touch licensing framework for cybersecurity service providers.

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 15

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 16

What are the risk assessment activities in your organisation?

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 17

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 18

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 19

• SUC is often defined using a combination of illustrations and text.

• Clearly identify the assets that are in-scope.

• Identify the perimeter and access point.

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 20

Illustrate the components of the system.

Illustrate physical location.

Present the information following Purdue Model.

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 21

• Detail how the network is physically and logically constructed.

• Individual routers, switches, firewalls are shown symbolically.

• Switch port assignments are identified.

• VLANs are documented

CISCO Network Icons

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 22

Using different colours • Detail how network is physical and

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 23

• Complied through documentation and site survey.

• Automated tools can be used but should be carefully tested.

CONSULTING \\ ENSIGN INFOSECURITY | CONFIDENTIAL 24

Hardware Virtual Hardware Software

• Operating system individual • License information

• Firmware version • Other notes • Number of license

• Responsible organisation / • License expiry