t mu sy 10013 pr cybersecurity for iacs – cyber risk ... · t mu sy 10013 pr cybersecurity for...

Cybersecurity for IACS – Cyber Risk Management Procedure

T MU SY 10013 PR

Procedure

Version 1.0

Issue date: 21 June 2018

Effective date: 01 July 2018

© State of NSW through Transport for NSW 2018

T MU SY 10013 PR Cybersecurity for IACS – Cyber Risk Management Procedure

Version 1.0 Effective date: 01 July 2018

Important message This document is one of a set of standards developed solely and specifically for use on

Transport Assets (as defined in the Asset Standards Authority Charter). It is not suitable for any

other purpose.

The copyright and any other intellectual property in this document will at all times remain the

property of the State of New South Wales (Transport for NSW).

You must not use or adapt this document or rely upon it in any way unless you are providing

products or services to a NSW Government agency and that agency has expressly authorised

you in writing to do so. If this document forms part of a contract with, or is a condition of

approval by a NSW Government agency, use of the document is subject to the terms of the

contract or approval. To be clear, the content of this document is not licensed under any

Creative Commons Licence.

This document may contain third party material. The inclusion of third party material is for

illustrative purposes only and does not represent an endorsement by NSW Government of any

third party product or service.

If you use this document or rely upon it without authorisation under these terms, the State of

New South Wales (including Transport for NSW) and its personnel does not accept any liability

to you or any other person for any loss, damage, costs and expenses that you or anyone else

may suffer or incur from your use and reliance on the content contained in this document. Users

should exercise their own skill and care in the use of the document.

This document may not be current and is uncontrolled when printed or downloaded. Standards

may be accessed from the Transport for NSW website at www.transport.nsw.gov.au

For queries regarding this document, please email the ASA at [email protected] or visit www.transport.nsw.gov.au © State of NSW through Transport for NSW 2018



Standard governance

Owner: Lead Telecommunications Engineer, Asset Standards Authority

Authoriser: Chief Engineer, Asset Standards Authority

Approver: Executive Director, Asset Standards Authority on behalf of the ASA Configuration Control Board

Document history

Version Summary of changes

1.0 First issue.

© State of NSW through Transport for NSW 2018 of 50



Preface

The Asset Standards Authority (ASA) is a key strategic branch of Transport for NSW (TfNSW).

As the network design and standards authority for NSW Transport Assets, as specified in the

ASA Charter, the ASA identifies, selects, develops, publishes, maintains and controls a suite of

requirements documents on behalf of TfNSW, the asset owner.

The ASA deploys TfNSW requirements for asset and safety assurance by creating and

managing TfNSW's governance models, documents and processes. To achieve this, the ASA

focuses on four primary tasks:

• publishing and managing TfNSW's process and requirements documents including TfNSW

plans, standards, manuals and guides

• deploying TfNSW's Authorised Engineering Organisation (AEO) framework

• continuously improving TfNSW’s Asset Management Framework

• collaborating with the Transport cluster and industry through open engagement

The AEO framework authorises engineering organisations to supply and provide asset related

products and services to TfNSW. It works to assure the safety, quality and fitness for purpose of

those products and services over the asset's whole-of-life. AEOs are expected to demonstrate

how they have applied the requirements of ASA documents, including TfNSW plans, standards

and guides, when delivering assets and related services for TfNSW.

Compliance with ASA requirements by itself is not sufficient to ensure satisfactory outcomes for

NSW Transport Assets. The ASA expects that professional judgement be used by competent

personnel when using ASA requirements to produce those outcomes.

About this document

This document forms part of a series of cybersecurity for industrial automation and control

systems (IACS) standards.

This document covers cyber risk management for IACS within the TfNSW Transport Network

across the asset life cycle.

This document has been prepared by the ASA in consultation with TfNSW agencies and

industry representatives.

This document has been informed by concepts contained in IEC/TS 62443-1-1 Industrial

communication networks - Network and system security - Part 1-1: Terminology, concepts and

models and includes extracts from that standard.

The ASA thanks the International Electrotechnical Commission (IEC) for permission to

reproduce information from its international standards. All such extracts are copyright of IEC,

Geneva, Switzerland. All rights reserved.




Further information on the IEC is available from www.iec.ch.

IEC has no responsibility for the placement and context in which the extracts and contents are

reproduced by the author, nor is IEC in any way responsible for the other content or accuracy

therein.

This document is a first issue.




Table of contents 1. Introduction .............................................................................................................................................. 7

2. Purpose .................................................................................................................................................... 7 2.1. Scope ..................................................................................................................................................... 7 2.2. Application ............................................................................................................................................. 7

3. Reference documents ............................................................................................................................. 8

4. Terms and definitions ............................................................................................................................. 9

5. Cyber risk management procedure ..................................................................................................... 11

6. High-level risk assessment .................................................................................................................. 13 6.1. Identify system under consideration .................................................................................................... 14 6.2. Perform criticality assessment ............................................................................................................. 15 6.3. Partition SuC into security zones and conduits ................................................................................... 16 6.4. Assign initial security level targets ....................................................................................................... 18

7. Detailed risk assessment ...................................................................................................................... 20 7.1. Identify threats ..................................................................................................................................... 21 7.2. Identify vulnerabilities .......................................................................................................................... 22 7.3. Determine unmitigated cyber risk ........................................................................................................ 24 7.4. Determine security level targets .......................................................................................................... 26 7.5. Identify and evaluate existing countermeasures ................................................................................. 27 7.6. Determine residual cyber risk .............................................................................................................. 28 7.7. Determine risk acceptance .................................................................................................................. 29 7.8. Apply additional cybersecurity countermeasures ................................................................................ 30

8. Continuous monitoring and reviewing ................................................................................................ 31 8.1. Monitor and review threats .................................................................................................................. 31 8.2. Monitor and review vulnerabilities ....................................................................................................... 32

Appendix A Responsibility assignment matrix ................................................................................... 35

Appendix B Overview of IDEF0 syntax ................................................................................................. 37

Appendix C Implementation examples ................................................................................................. 38 C.1. Digital train radio system ..................................................................................................................... 38




1. Introduction The application of baseline cybersecurity countermeasures to protect against casual and

coincidental violations and intentional violation using simple means is explained in

T MU SY 10012 ST Cybersecurity for IACS - Baseline Cybersecurity System Requirements and

Countermeasures.

However, compliance with the baseline requirements of T MU SY 10012 ST may not be

sufficient to ensure that the security objectives of TfNSW are achieved.

Cyber risk should be managed using a procedure that is suitable for industrial automation and

control systems (IACS). This procedure is based on draft ISA committee work products for

IEC 62443 Part 3-2 and has been tailored for the TfNSW Transport Network.

2. Purpose This document specifies the procedure for consistent and effective management of cyber risks

for IACS across the TfNSW Transport Network.

This document aligns with the IEC 62443 series and is considered suitable for the management

of cyber risks in IACS.

2.1. Scope This document explains the tailored procedures, processes and steps to manage cyber risk in

alignment with IEC 62443 series. The scope of this document covers all systems that comprise

a single integrated ‘automation solution’.

Note: Policies and procedures are the responsibility of the ‘asset owner’ which is not

addressed in this document. Refer to IEC 62443-2-1 Industrial communication

networks - Network and system security - Part 2-1: Establishing an industrial

automation and control system security program and IEC 62443-2-4 Security for

industrial automation and control systems - Part 2-4: Security program requirements

for IACS service providers for further information.

2.2. Application This document applies to the asset owners and system integrators of IACS.

This document does not apply to product suppliers.

The roles of asset owner, system integrator and product supplier have been adopted from IEC

62443-3-3 Industrial communication networks - Network and system security - Part 3-3: System

security requirements and security levels.

Within the context of this document, TfNSW is the asset owner.




The AEOs can undertake one or more of the following roles:

• operator on behalf of asset owner

• maintainer on behalf of asset owner

• system integrator

This process applies across the plan, acquire and operate/maintain stages of the asset life

cycle.

This document applies to parties in accordance with the responsibility assignment matrix as

given in Appendix A.

This document shall be read in conjunction with the Cybersecurity for IACS series of standards

and IEC 62443 series of standards.

3. Reference documents The following documents are cited in the text. For dated references, only the cited edition

applies. For undated references, the latest edition of the referenced document applies.

International standards

IEC 62280 Railway applications - Communication, signalling and processing systems - Safety

related communication in transmission systems

IEC/TS 62443-1-1 Industrial communication networks - Network and system security - Part 1-1:

Terminology, concepts and models

IEC 62443-2-1 Industrial communication networks - Network and system security - Part 2-1:

Establishing an industrial automation and control system security program

IEC 62443-2-4 Security for industrial automation and control systems - Part 2-4: Security

program requirements for IACS service providers

IEC 62443-3-3 Industrial communication networks - Network and system security - Part 3-3:

System security requirements and security levels

IEC/ISO 31010 Risk management - Risk assessment techniques

ISA TR84.00.09:2017 Cybersecurity Related to the Functional Safety Lifecycle

ISO/IEC/IEEE 31320-1 Information technology - Modeling Languages - Part 1: Syntax and

Semantics for IDEF0

Australian standards

AS/NZS ISO 31000 Risk management – Principles and guidelines

HB 167:2006 Security risk management

HB 327:2010 Communicating and consulting about risk © State of NSW through Transport for NSW 2018 of 50



SA/SNZ HB 436:2013 Risk management guidelines

Transport for NSW standards

T MU AM 02001 ST Asset Information and Register Requirements

T MU MD 20002 ST Risk Criteria for Use by Organisations Providing Engineering Services

T MU SY 10010 ST Cybersecurity for IACS - Series Overview

T MU SY 10012 ST Cybersecurity for IACS - Baseline Technical Cybersecurity System

Requirements and Countermeasures

Legislation

Rail Safety National Law 2012 (NSW)

Work Health and Safety Regulation 2011

Other reference documents

Forum of Incident Response and Security Teams (FIRST) 2017, Common Vulnerability Scoring

System

The MITRE Corporation 2017, Common Attack Pattern Enumeration and Classification

(CAPEC™)

The MITRE Corporation 2017, Common Vulnerabilities and Exposures (CVE®)

The MITRE Corporation 2017, Common Weaknesses Enumeration (CWE™)

4. Terms and definitions The following terms and definitions apply in this document:

AEO authorised engineering organisation

ASD Australian Signals Directorate

asset owner individual or company responsible for one or more IACS (IEC 62443-3-3 ed.1.0)

attack assault on a system that derives from an intelligent threat — i.e., an intelligent act that is

a deliberate attempt (especially in the sense of a method or technique) to evade security

services and violate the security policy of a system (IEC/TS 62443-1-1 ed.1.0)

attack tree formal, methodical way of finding ways to attack the security of a system

(IEC/TS 62443-1-1 ed.1.0)

automation solution control system and any complementary hardware and software

components that have been installed and configured to operate in an IACS (IEC 62443-2-4

ed.1.0)

conduit logical grouping of communication channels, connecting two or more zones, that share

common security requirements (IEC 62443-3-3 ed.1.0) © State of NSW through Transport for NSW 2018 of 50



countermeasure action, device, procedure, or technique that reduces a threat, a vulnerability,

or an attack by eliminating or preventing it, by minimizing the harm it can cause, or by

discovering and reporting it so that corrective action can be taken (IEC/TS 62443-1-1 ed.1.0)

cybersecurity actions required to preclude unauthorized use of, denial of service to,

modifications to, disclosure of, loss of revenue from, or destruction of critical systems or

informational assets (IEC/TS 62443-1-1 ed.1.0)

cyber risk the potential for unauthorised use, disclosure, damage or disruption to assets

through the use of technology

enterprise system collection of information technology elements (i.e., hardware, software and

services) installed with the intent to facilitate an organization’s business process or processes

(administrative or project) (IEC/TS 62443-1-1 ed.1.0)

IACS industrial automation and control systems

IDEF0 box a rectangle containing a box name, a box number, and possibly a box detail

reference and representing a function in a diagram (ISO/IEC/IEEE 31320-1:2012)

IDEF0 control a condition or set of conditions required for a function to produce correct output

(ISO/IEC/IEEE 31320-1:2012)

IDEF0 function a transformation of inputs to outputs, by means of some mechanisms, and

subject to certain controls, that is identified by a function name and modelled by a box

(ISO/IEC/IEEE 31320-1:2012)

IDEF0 input that which is transformed by a function into output (ISO/IEC/IEEE 31320-1:2012)

IDEF0 mechanism the means used by a function to transform input into output

(ISO/IEC/IEEE 31320-1:2012)

IDEF0 output that which is produced by a function (ISO/IEC/IEEE 31320-1:2012)

IACS industrial automation and control systems; collection of personnel, hardware, and

software that can affect or influence the safe, secure, and reliable operation of an industrial

process (IEC/TS 62443-1-1 ed.1.0)

product supplier manufacturer of hardware and/or software product (IEC 62443-3-3 ed.1.0)

risk expectation of loss expressed as the probability that a particular threat will exploit a

particular vulnerability with a particular consequence (IEC/TS 62443-1-1 ed.1.0)

risk assessment process that systematically identifies potential vulnerabilities to valuable

system resources and threats to those resources, quantifies loss exposures and consequences

based on probability of occurrence, and (optionally) recommends how to allocate resources to

countermeasures to minimize total exposure (IEC/TS 62443-1-1 ed.1.0)

risk management process of identifying and applying countermeasures commensurate with the

value of the assets protected, based on a risk assessment (IEC/TS 62443-1-1 ed.1.0)




security event occurrence in a system that is relevant to the security of the system

(IEC/TS 62443-1-1 ed.1.0)

security level level corresponding to the required effectiveness of countermeasures and

inherent security properties of devices and systems for a zone or conduit based on assessment

of risk for the zone or conduit (IEC/TS 62443-1-1 ed.1.0)

security zone grouping of logical or physical assets that share common security requirements

(IEC/TS 62443-1-1 ed.1.0)

SuC system under consideration

system integrator person or company that specializes in bringing together component

subsystems into a whole and ensuring that those subsystems perform in accordance with

project specifications (IEC 62443-3-3 ed.1.0)

TfNSW Transport Network the transport system owned and operated by TfNSW or its

operating agencies upon which TfNSW has power to exercise its functions as conferred by the

Transport Administration Act or any other Act

threat potential for violation of security, which exists when there is a circumstance, capability,

action, or event that could breach security and cause harm (IEC/TS 62443-1-1 ed.1.0)

threat action assault on system security (IEC/TS 62443-1-1 ed.1.0)

threat agent causative agent of a threat action (IEC/TS 62443-1-1 ed.1.0)

vulnerability flaw or weakness in a system's design, implementation, or operation and

management that could be exploited to violate the system's integrity or security policy

(IEC/TS 62443-1-1)

All definitions from IEC/TS 62443-1-1 ed.1.0 are Copyright © 2009 IEC Geneva,

Switzerland. www.iec.ch

All definitions from IEC 62443-2-4 ed.1.0 are Copyright © 2017 IEC Geneva,


All definitions from IEC 62443-3-3 ed.1.0 are Copyright © 2013 IEC Geneva,


5. Cyber risk management procedure This procedure standardises the management of cyber risks across the TfNSW Transport

Network.

The procedure aligns with the IEC 62443 series and is considered suitable for the management

of cyber risks in IACS.

This procedure has been based on the draft ISA committee work products for

IEC 62443 Part 3-2 to minimise future work. © State of NSW through Transport for NSW 2018 of 50



Note: ASA intends to tailor the conformance of IEC 62443 Part: 3-2 following

publication by the IEC.

This procedure requires an established risk management framework and process to be in place

that complies with AS/NZS ISO 31000 Risk management – Principles and guidelines.

The procedure has been tailored to TfNSW risk criteria defined in T MU MD 20002 ST Risk

Criteria for Use by Organisations Providing Engineering Services.

This procedure is divided into the following three sub-procedures that align with the TfNSW

asset life cycle:

• high-level risk assessment procedure performed in the ‘plan’ stage of the asset life cycle,

detailed in Section 6

• detailed risk assessment procedure performed in the ‘acquire’ stage of the asset life cycle,

detailed in Section 7

• continuous monitoring and reviewing procedure performed in the ‘operate/maintain’ stage

of the asset life cycle, detailed in Section 8

This procedure is depicted by diagrams, which uses the Integration Definition (IDEF0) modelling

language. An overview of the IDEF0 syntax is provided in Appendix B.

Refer to ISO/IEC/IEEE 31320-1 Information technology - Modeling Languages - Part 1: Syntax

and Semantics for IDEF0 for further information on IDEF0.

Examples of selected process outputs have been provided to assist in the implementation of

this procedure in Appendix C.

Refer to the following for further supplementary information:

• ISA TR84.00.09:2017 Cybersecurity Related to the Functional Safety Lifecycle

• IEC/ISO 31010 Risk management - Risk assessment techniques

• HB 167:2006 Security risk management

• HB 327:2010 Communicating and consulting about risk

• SA/SNZ HB 436:2013 Risk management guidelines




6. High-level risk assessment The high-level risk assessment is performed during the ‘plan’ stage of the asset life cycle in support of submissions to configuration management (CM) gate 1 unless a tailored application has been approved as defined in T MU AM 04001 PL

TfNSW Configuration Management Plan.

An overview of the high-level risk assessment procedure is shown in Figure 1. Each of the processes within the high-level risk assessment procedure is explained in Section 6.1 through to Section 6.4.

6.1

Identify SuC

6.2

Perform criticality assessment

6.3

Partition SuC into security

zones & conduits

Operations concept

Maintenance concept

Asset owner(A,R)

Safety impactassessment

T MU MD 20002 ST

Asset owner(A,R)

IEC/TS 62443-1-1

Preferred &alternate options

IEC/TS62443-1-1

System integrator

(C)

System integrator

(C)

Product supplier

(C)

Asset owner(A,R)

System integrator

(C)

Boundaries &points of access

Criticalityratings

6.4

Assign initial security level

targets

Security zones& conduits

Security classified information

Public security advisories

Threat agents

Minimum SL-Ts for security zones & conduits

Asset owner(A,R)

System integrator

(C)

IEC 62443-3-3

Business requirements specification


Figure 1 – Overview of the high-level risk assessment



6.1. Identify system under consideration The first step in the high-level risk assessment procedure, the system under consideration

(SuC), its boundaries and points of access shall be identified.

The inputs, outputs, controls and mechanisms for identifying the SuC are shown in Figure 2.

6.1

Identify SuCOperations concept

Maintenance concept

Asset owner(A,R)

IEC/TS 62443-1-1


System integrator

(C)


Figure 2 - Identify SuC IDEF0

6.1.1. Inputs for identifying SuC The inputs to identify the SuC include the following:

• The operations concept, as defined in T MU AM 06008 ST Operations Concept Definition

that describes how the system is intended to be operated over the asset life cycle. The

operations concept contributes to the definition of the SuC boundaries and points of

access.

• The maintenance concept, as defined in T MU AM 06009 ST Maintenance Concept

Definition that describes how the system is intended to be maintained over the asset life

cycle. The maintenance concept contributes to the definition of the SuC boundaries and

points of access.

• The preferred and alternate options. These options describe the process or utility areas of

the SuC.

6.1.2. Process for identifying SuC The steps for identifying the SuC are as follows:

a. Identify all physical and logical boundaries of the SuC and each process or utility area.

b. Identify all physical and logical points of access to the SuC and each process or utility area.




6.1.3. Output from identifying SuC

The output from identifying the SuC is the records of the boundaries and points of access to the

SuC, and each process or utility area.

6.2. Perform criticality assessment After the SuC is identified, the criticality assessment shall be performed. This process identifies

and prioritises specific processes or utility areas of the SuC by their relative importance to the

asset owners’ business.

The criticality assessment is an initial high-level risk assessment where the likelihood of the

security event is assumed ‘almost certain’ as defined in T MU MD 20002 ST.

Note: This is consistent with the discussion on calibrating likelihood contained within

IEC 62443-2-1 Annex A, which states that one method to calibrate likelihood is to use

a probability of 100%.

The inputs, outputs, controls and mechanisms for performing the criticality assessment are

shown in Figure 3.

6.2

Perform criticality assessment

Safety impactassessment

T MU MD 20002 ST

Asset owner(A,R)

System integrator

(C)

Product supplier

(C)

Business requirements specification


Criticality ratings

Figure 3 - Perform criticality assessment IDEF0

6.2.1. Inputs for performing criticality assessment The inputs to perform the criticality assessment include the following:

• records of the boundaries and points of access to the SuC and each process or utility area

• business requirements specification as explained in T MU AM 06010 GU Business

Requirements Specification

• safety impact assessment as described in T MU MD 20001 ST System Safety Standard for

New or Altered Assets




6.2.2. Process for performing criticality assessment

The steps for performing the criticality assessment are as follows:

a. Identify risk scenarios and credible worst case consequences for the risk events of loss of

confidentiality, integrity and availability for each process or utility area and the SuC.

Note: The high-level security objectives of confidentiality, integrity and availability are

commonly used within information security and are further developed into seven

foundational requirements by the IEC 62443 series.

The worst case consequence is limited to a span of one calendar day.

Note: In addition, impacts that continue beyond one calendar day should be

considered within business continuity and resilience plans.

b. Assess the consequence descriptor and rating for each consequence impact area using

the TfNSW consequence criteria as defined in T MU MD 20002 ST.

The TfNSW likelihood criteria defined in T MU MD 20002 ST shall be fixed as descriptor

‘almost certain’ and rating L1.

Note: The likelihood is assumed fixed in the planning stage of the asset life cycle to

overcome difficulties in agreement as discussed in IEC 62443-2-1 Annex A. The

detailed risk assessment process does not assume a fixed likelihood.

c. Assess the risk descriptor and rating for each identified risk.

Note: Risk ranking D ‘low – broadly acceptable’ does not apply where likelihood is

descriptor ‘almost certain’ and rating L1.

d. Determine the highest risk rating for each process or utility area and the SuC.

e. Assign the highest risk rating for each process or utility area and the SuC as the criticality

rating.

Note: As likelihood is assumed fixed, this document refers to this high-level risk rating

simply as the criticality rating.

6.2.3. Output from performing criticality assessment The output from preforming the criticality process is the records of criticality ratings for each

process or utility area and the SuC.

6.3. Partition SuC into security zones and conduits After the criticality assessment is performed, the SuC shall be partitioned into security zones

and conduits.

The inputs, outputs, controls and mechanisms for partitioning the SuC are shown in Figure 4.




Criticality ratings

6.3

Partition SuC into security

zones & conduits

IEC/TS62443-1-1

Asset owner(A,R)

System integrator

(C)

Security zones & conduits

Figure 4- Partition SuC into security zones and conduits IDEF 0

6.3.1. Input for partitioning SuC The input to partition the SuC is the records of criticality ratings for each process or utility area

and the SuC.

6.3.2. Process for partitioning SuC To partition the SuC, adapt the security zones and conduits reference model described in

T MU SY 10010 ST Cybersecurity for IACS - Series Overview to suit the SuC.

Refer to T MU SY 10012 ST Cybersecurity for IACS - Baseline Technical Cybersecurity System

Requirements and Countermeasures for the criteria pertaining to trust of portable and mobile

devices and networks.

Notes:

1. In railway applications, IEC 62280 Railway applications - Communication, signalling

and processing systems - Safety related communication in transmission systems is

commonly applied.

2. Conduits that meet the criteria for trust defined in T MU SY 10012 ST can be

considered a category 1 or category 2 transmission system as defined in IEC 62280,

subject to fulfilment and maintenance of the preconditions over the design life of the

SuC.

3. Conduits that do not meet the criteria for trust defined in T MU SY 10012 ST can be

considered a category 3 transmission system as defined in IEC 62280.

6.3.3. Output from partitioning SuC The output from partitioning the SuC is the records of security zones and conduits for the SuC




6.4. Assign initial security level targets After partitioning the SuC, the threat agents shall be identified and assigned an initial minimum

security level target (SL-T) to each security zone within the SuC.

Note: The detailed risk assessment may revise the SL-T to a higher level.

The inputs, outputs, controls and mechanisms for assigning initial security level targets are

shown in Figure 5.

6.4

Assign initial security level

targetsSensitive/security classified

informationPublished security

advisories

Threat agents

Minimum SL-Ts

Asset owner(A,R)

System integrator

(C)

IEC 62443-3-3

Security zones & conduits

Figure 5 - Assign initial security level targets IDEF0

6.4.1. Inputs for assigning initial SL-T The inputs to assign the initial SL-T include the following:

• records of security zones and conduits for the SuC

• sensitive or security classified information from Australian Cyber Security Centre (ACSC)

agencies, such as Australian Signals Directorate (ASD), Australian Security Intelligence

Organisation (ASIO) and CERT Australia

Note: Information should be classified, labelled and handled in accordance with

TfNSW policies and procedures.

• published security advisories, such as from ASD OnSecure or CERT Australia portals

6.4.2. Process for assigning initial SL-T The steps for assigning the initial SL-T are as follows:

a. Determine whether specific threat agents that intend to target the SuC, or similar IACS,

automation solutions and products, exist over the design life of the SuC.

b. If no specific threat agents exist, then categorise general threat agents as either ‘internal’

or ‘external’.




Note: In conventional security risk management, a threat is a function of intent and

capability. In respect to cyber risk management, the threat environment is continually

and rapidly changing to the point where the attribution or characterisation of threat

agents to a specific entity is of limited benefit.

c. Assess the means, resources, skills and motivation of threat agents over the design life of

the SuC. Refer to IEC 62443-3-3 Annex A for further information.

d. Assign a minimum security level target (SL-T) to each security zone.

Security level targets SL-T 0 or 1 shall not be assigned to security zones within the SuC.

6.4.3. Outputs from assigning initial SL-T The outputs from assigning the initial SL-T include the following:

• records of threat agents

• records of minimum SL-T for each security zone




7. Detailed risk assessment The detailed risk assessment is performed in the ‘acquire’ stage of the asset life cycle and supports submissions to CM gates, unless a tailored application has been approved as defined in T MU AM 04001 PL.

An overview of the detailed risk assessment process is shown in Figure 6. Each of the processes within the high-level risk assessment procedure is explained in Section 7.1 through to Section 7.8.

7.1

Identify threats

Criticality ratingsThreat agents

Asset owner(A,C)

T MU AM 02001 ST

Supplier security advisories

System integrator

(R)

MITRE CAPEC

Historical data

Threat agents & actions

7.2

Identify vulnerabilitiesCriticality ratings

Asset owner(A,C)

MITRE CVE


Product supplier

(C)

MITRE CWE


Vulnerabilities

System integrator

(R)

Fault/attack tree

Fault/attack tree

7.3

Determine inherent cyber risk

rating


Product supplier

(C)

Professional review

Asset owner(A,C)

Product supplier

(C)

System integrator

(R)

T MU MD 20002 ST

7.4

Determine security level

targets

Asset owner(A,C)

System integrator

(R)

IEC 62443-3-3

Minimum SL-Ts

Professional review

7.5

Identify and evaluate existing coutermeasures

IEC62443-3-3

SL-Tvectors

Asset owner(A,C)

Product supplier

(C)

System integrator

(R)

7.6

Determine residual cyber risk

Riskregister

Asset owner(A,C)

Product supplier

(C)

System integrator

(R)

T MU MD 20002 ST

7.7

Determine risk acceptance

Riskregister

Asset owner(A,C)

T MU MD 20002 ST

7.8

Apply additional cybersecurity

coutermeasures

IEC62443-3-3Risk register

Asset owner(A,C)

Product supplier

(C)

System integrator

(R)

Repeat 7.6

System integrator

(R)

Risk register

Riskregister

Riskregister


Figure 6 - Overview of detailed risk assessment



7.1. Identify threats The threat agents and threat actions shall be identified in the detailed risk assessment.

The inputs, outputs, controls and mechanisms for identifying threats are shown in Figure 7.

Figure 7 – Identify threats IDEF0

7.1.1. Inputs for identifying threats

The inputs to identify threats include the following:

• records of criticality ratings for each process or utility area and the SuC

• records of threat agents

• published security advisories; such as from ASD OnSecure or CERT Australia portals

• security advisories from product suppliers

• historical data of security events

7.1.2. Process for identifying threats The steps for identifying threats are as follows:

a. Record all assets within each process or utility area within the SuC in an asset register in

accordance with T MU AM 02001 ST Asset Information and Register Requirements.

b. Record all physically accessible data communication and peripheral interfaces of assets as

attributes in the asset register.

c. Prior to final design, obtain an independent professional review of credible threats using

competent persons, certified in threat intelligence or threat analysis who have an

appropriate degree of independence.

7.1

Identify threats


Asset owner(A,C)

T MU AM 02001 ST


System integrator

(R)

MITRE CAPEC

Historical data

Threat agents & actionsPublic security advisories

Product supplier

(C)

Professional review

Fault/attack tree




Notes:

1. Recognised certifications in threat intelligence include: CREST Threat Intelligence

Analyst (CC TIA), GIAC Cyber Threat Intelligence (GCTI), McAfee Institute Certified

Cyber Intelligence Professional (CCIP).

2. The review should address credible threats to the SuC and to similar IACS,

automation solutions and products over the design life of the SuC.

3. An appropriate degree of independence is considered:

i. different person within a different organisation, for criticality rating A

ii. different person within the same organisation, for criticality rating B and C

d. List the credible threats, including threat agents and threat actions, over the design life of

the SuC.

e. Describe the threat actions of a threat agent in accordance with the domains of attack and

mechanisms of attack views as defined in The MITRE Corporation Common Attack Pattern

Enumeration and Classification (CAPEC™) dictionary of known attacks.

f. Develop fault trees or attack trees to model the threat actions used by threat actors for

each of the following general security events within the context of the SuC:

o loss of confidentiality – disclosure of information assets

o loss of integrity – unauthorised use of IACS functions

o loss of integrity – modifications to IACS or information assets

o loss of availability – disruption to IACS functions

o loss of availability – destruction of IACS or information assets

7.1.3. Outputs from identifying threats

The outputs from identifying threats include the following:

• asset register

• report of credible threats from independent professional reviewer

• records of threat agents and actions

• fault or attack tree drawings

7.2. Identify vulnerabilities After identifying the threats, the vulnerabilities in assets and countermeasures shall be

identified.




The inputs, outputs, controls and mechanisms for identifying vulnerabilities are shown in

Figure 8.

7.2

Identify vulnerabilitiesCriticality ratings

Asset owner(A,C)

MITRE CVE


Product supplier

(C)

MITRE CWE


Vulnerabilities

System integrator

(R)

Professional review

Fault/attack tree

Fault/attack tree

Figure 8 – Identify vulnerabilities IDEF0

7.2.1. Inputs for identifying vulnerabilities The inputs to identify vulnerabilities include the following:


• fault or attack tree drawings



7.2.2. Process for identifying vulnerabilities

The steps for identifying vulnerabilities are as follows:

a. Prior to final design, obtain an independent professional review of credible vulnerabilities

using competent persons, certified in simulated target attack and response who have an

appropriate degree of independence.

Notes:

1. Recognised certifications in threat intelligence include: CREST Registered

Penetration Tester (CRT Pen), GIAC Penetration Tester (GPEN), Offensive Security

Certified Professional (OSCP).

2. The review should be supported by dynamic testing performed on a representative

model of the SuC using techniques such as vulnerability scanning, penetration testing

and red teaming.




3. An appropriate degree of independence is considered:

i. different person within a different organisation, for criticality rating A

ii. different person within the same organisation, for criticality rating B and C

b. List the credible vulnerabilities.

Credible vulnerabilities shall include the following:

o all relevant published vulnerabilities and exposures from The MITRE Corporation

Common Vulnerabilities and Exposures (CVE®) list of entries

o for assets within security zones and conduits of criticality rating A, all credible

weaknesses for which at the time of analysis a known vulnerability or exposure has

not yet been discovered

These vulnerabilities shall be expressed in accordance with The MITRE Corporation

Common Weaknesses Enumeration (CWE™) list of common software security

weaknesses.

Note: The relative distribution of types of vulnerabilities should be used to inform

credible weaknesses. The National Institute of Standards and Technology (NIST)

National Vulnerability Database has a visualisation of ‘relative vulnerability type totals

by year’ located at https://nvd.nist.gov.

c. Revise the fault or attack trees to indicate credible vulnerabilities in the branches.

7.2.3. Outputs from identifying vulnerabilities The outputs from identifying vulnerabilities include the following:

• report of credible vulnerabilities from independent professional reviewer

• records of vulnerabilities

• fault or attack tree drawings with vulnerabilities

7.3. Determine unmitigated cyber risk After identifying vulnerabilities, the unmitigated cyber risk shall be determined.

The inputs, outputs, controls and mechanisms for determining unmitigated cyber risk are shown

in Figure 9.




7.3

Determine unmitigated cyber

risk

Asset owner(A,C)

Product supplier

(C)

System integrator

(R)

T MU MD 20002 ST

Fault/attack tree Risk register

Figure 9 – Determine unmitigated cyber risk IDEF0

7.3.1. Inputs for determining unmitigated cyber risk The input to determine unmitigated cyber risk is fault or attack tree drawings.

7.3.2. Process for determining unmitigated cyber risk The steps for determining unmitigated cyber risk are as follows:

a. Record the risks corresponding to the branches from the fault or attack tree in a risk

register.

Note: The top event of the tree relates to the ‘risk event’, and threat agents, actions

and vulnerabilities relate to ‘causes’.

b. Estimate the credible worst case consequences and likelihood descriptors in accordance

with T MU MD 20002 ST for each risk prior to assessing the application or effectiveness of

existing cybersecurity countermeasures that are not enabled by default.

Note: The effect of countermeasures that are not vulnerable to threats through the use

of technology may be considered, such as physical, mechanical, electric and

electronic independent protection layers.

The worst case consequence is limited to a span of one calendar day.

c. Determine the unmitigated cyber risk rating for each risk in accordance with

T MU MD 20002 ST.

d. Record the unmitigated cyber risk in the risk register.

Note: The unmitigated cyber risk relates to the ‘inherent risk rating’.

7.3.3. Output from determining unmitigated cyber risk The output from determining unmitigated cyber risk includes the risk register.




7.4. Determine security level targets After determining the unmitigated cyber risk, the security level targets (SL-T) shall be

determined.

The inputs, outputs, controls and mechanisms for determining the SL-T are shown in Figure 10.

Risk register

SL-T vectors

Minimum SL-Ts7.4

Determine security level

targets

Asset owner(A,C)

System integrator

(R)

IEC 62443-3-3

Figure 10 - Determine security level targets IDEF0

7.4.1. Inputs for determining SL-T The inputs to determine the SL-T include the following:

• risk register

• records of minimum SL-T for each security zone

7.4.2. Process for determining SL-T The steps for determining the SL-T are as follows:

a. Determine the applicable foundational requirements as defined in IEC 62443-3-3 for each

risk.

b. Determine the SL-T of applicable foundational requirements, expressed as a SL-T vector,

for each security zone and conduit.

Note: If a foundational requirement does not apply to the security zone or conduit, a

SL-T of 0 may be assigned.

7.4.3. Output from determining SL-T The output from determining SL-T includes records of SL-T vector for each security zone.




7.5. Identify and evaluate existing countermeasures After determining security level targets, the existing countermeasures shall be identified and

evaluated.

The inputs, outputs, controls and mechanisms for identifying and evaluating existing

countermeasures are shown in Figure 11.

7.5

Identify and evaluate existing coutermeasures

IEC62443-3-3

Asset owner(A,C)

Product supplier

(C)

System integrator

(R)

Risk register

SL-T vectors

Risk register

Figure 11 - Identify and evaluate existing countermeasures IDEF0

7.5.1. Inputs for identifying and evaluating existing countermeasures The inputs to identify and evaluate existing countermeasures include the following:

• records of SL-T vector for each security zone

• risk register

7.5.2. Process for identifying and evaluating existing countermeasures The steps for identifying and evaluating existing countermeasures are as follows:

a. Identify the existing countermeasures.

b. Identify the applicable system requirements from IEC 62443-3-3 that provide technical

security capabilities and meet the target security levels expressed by the SL-T vector.

c. Evaluate the effectiveness of technical countermeasures against the identified system

requirements.

Note: Countermeasures may be considered ‘effective’ if they provide technical security

capabilities that address all applicable system requirements, ‘partially effective’ if they

address some, and ‘not effective’ if they do not address any.

d. Record the existing countermeasures and their effectiveness in the risk register.

Note: The existing countermeasures relate to the ‘current controls’. © State of NSW through Transport for NSW 2018 of 50



7.5.3. Output from identifying and evaluating existing

countermeasures The output from identifying and evaluating existing countermeasures includes the risk register

with countermeasures and effectiveness.

7.6. Determine residual cyber risk After identifying and evaluating existing countermeasures, the residual cyber risk rating with

consideration of existing countermeasures shall be determined.

The inputs, outputs, controls and mechanisms for determining residual cyber risk are shown in

Figure 12.

7.6

Determine residual cyber risk

Asset owner(A,C)

Product supplier

(C)

System integrator

(R)

T MU MD 20002 ST

Risk registerRisk register

Figure 12 – Determine residual cyber risk IDEF0

7.6.1. Input for determining residual cyber risk rating The input to determine the residual cyber risk rating includes the risk register.

7.6.2. Process for determining residual cyber risk rating The steps for determining residual cyber risk rating are as follows:

a. Estimate the credible worst case consequences and likelihood descriptors in accordance

with T MU MD 20002 ST.

b. Determine the residual cyber risk in accordance with T MU MD 20002 ST.

c. Record the residual consequence and likelihood descriptors and residual cyber risk in the

risk register.

Note: The residual cyber risk relates to the ‘residual current risk’.




7.6.3. Output from determining residual cyber risk rating

The output from determining residual cyber risk rating includes the risk register with residual

consequence and likelihood descriptors and residual cyber risk.

7.7. Determine risk acceptance After determining the residual risk, the risk acceptance by TfNSW as the asset owner shall be

determined.

Note: The Rail Safety National Law 2012 (NSW) requires that risks to safety are

eliminated so far as is reasonably practicable (SFAIRP), or otherwise minimised to

SFAIRP.

The inputs, outputs, controls and mechanisms for determining risk acceptance are shown in

Figure 13.

7.7

Determine risk acceptance

Asset owner(A,C)

T MU MD 20002 ST

System integrator

(R)

Risk register Risk register

Figure 13 – Determine risk acceptance IDEF0

7.7.1. Inputs for determining risk acceptance The input to determine risk acceptance is the risk register.

7.7.2. Process for determining risk acceptance The steps for determining risk acceptance are as follows:

a. Evaluate the risk and determine whether the residual current cyber risk is acceptable to

TfNSW in accordance with T MU MD 20002 ST.

b. Record the risk acceptance determination in the risk register.

Note: The risk acceptance relates to the ‘risk evaluation’.

c. If the residual current cyber risk is not acceptable, then apply additional cybersecurity

countermeasures as explained in Section 7.8 to further treat the risk.




7.7.3. Output from determining risk acceptance

The output from determining risk acceptance includes the risk register with risk acceptance

determination.

7.8. Apply additional cybersecurity countermeasures After determining the risk acceptance, additional cybersecurity countermeasures shall be

applied to further treat the risk.

This process only applies where the residual current cyber risk was determined to be not

acceptable by TfNSW and further treatment is required.

The inputs, outputs, controls and mechanisms for applying additional cybersecurity

countermeasures are shown in Figure 14.

Risk register

7.8

Apply additional cybersecurity

coutermeasures

IEC62443-3-3

Asset owner(A,C)

Product supplier

(C)

System integrator

(R)

Repeat 7.6

Risk register

Figure 14 – Apply additional cybersecurity countermeasures IDEF0

7.8.1. Input for applying additional cybersecurity countermeasures The input to apply additional cybersecurity countermeasures is the risk register.

7.8.2. Process for applying additional cybersecurity countermeasures The steps for applying additional cybersecurity countermeasures are as follows:

a. Identify the applicable system requirements from IEC 62443-3-3 that provide technical

security capabilities to further treat risks.

b. Identify additional technical countermeasures. Refer to T MU SY 10012 ST for technical

countermeasures requirements.

c. Evaluate the effectiveness of additional technical countermeasures against the identified

system requirements.




Note: Countermeasures may be considered ‘effective’ if they provide technical security

capabilities that address all applicable system requirements, ‘partially effective’ if they

address some, and ‘not effective’ if they do not address any.

d. Evaluate procedural requirements from IEC 62443-2-1 to further treat risks.

Work Health and Safety Regulation 2011 contains a hierarchy of control measures. In

particular, administrative controls shall only be implemented where engineering controls

are not reasonably practicable.

e. Record the additional countermeasures and their effectiveness in the risk register.

Note: The additional countermeasures relate to the ‘planned controls’.

f. Determine the residual planned cyber risk rating by repeating the process from Section 7.6.

7.8.3. Output from applying additional cybersecurity countermeasures

The output from applying additional cybersecurity countermeasures is the risk register with

additional cybersecurity countermeasures.

8. Continuous monitoring and reviewing The continuous monitoring and reviewing is performed in the ‘operate/maintain’ stage of the

asset life cycle and supports submissions to configuration management (CM) gates, unless a

tailored application has been approved as defined in T MU AM 04001 PL.

Each of the processes within continuous monitoring and reviewing is explained in Section 8.1

through Section 8.2.

8.1. Monitor and review threats The new and changed threats shall be monitored and reviewed in continuous monitoring and

reviewing.

The inputs, outputs, controls and mechanisms for monitoring and reviewing threats are shown in

Figure 15.




8.1

Monitor and review threats


Asset owner(A,R,C)


MITRE CAPEC

Historical data

Maintenance schedulePublic security advisories

Product supplier

(C)

Figure 15 – Monitor and review threats IDEF0

8.1.1. Inputs for monitoring and reviewing threats The inputs to monitor and review threats include the following:


• records of threat agents and actions




8.1.2. Process for monitoring and reviewing of threats The steps for monitoring and reviewing threats are as follows:

a. Monitor advisories and historical data for new and changed threats at least every day.

b. Review threats and schedule maintenance activities to treat new and changed threats.

c. Repeat the detailed risk assessment explained in Section 7.1 for each new or changed

threat and at least annually.

8.1.3. Output from monitoring and reviewing of threats

The output from monitoring and reviewing threats is the schedule of maintenance activities.

8.2. Monitor and review vulnerabilities The final process in continuous monitoring and reviewing is monitoring and reviewing new and

changed vulnerabilities.

The inputs, outputs, controls and mechanisms for monitoring and reviewing vulnerabilities are

shown in Figure 16.




8.2

Monitor and review vulnerabilities

Criticality ratings

Asset owner(A,R,C)

MITRE CVE


Product supplier

(C)

MITRE CWE


Maintenance schedule

Figure 16– Monitor and review vulnerabilities IDEF0

8.2.1. Inputs for monitoring and reviewing vulnerabilties The inputs to monitor and review vulnerabilities include the following:


• records of vulnerabilities




8.2.2. Process for monitoring and reviewing vulnerabilties The steps for monitoring and reviewing vulnerabilities are as follows:

a. Monitor advisories and historical data for new and changed vulnerabilities at least every

day.

b. Review vulnerabilities based on their Common Vulnerability Scoring System (CVSS)

severity and schedule maintenance activities to treat new and changed vulnerabilities

within the period shown in Table 1.

Table 1 - Period for remediation of vulnerabilities

Criticality rating Critical or high severity

Medium severity Low severity

A 1 week 1 month 2 months

B 1 month 2 months 3 months

C 2 months 3 months 3 months

c. Repeat the detailed risk assessment explained in Section 7.2, for new or changed

vulnerability and at least annually.




8.2.3. Output from monitoring and reviewing vulnerabilties

The output from monitoring and reviewing vulnerabilities is the schedule of maintenance

activities.




Appendix A Responsibility assignment matrix Table 2 shows the responsibility assignment matrix for each process described in this document. It shows the parties accountable (A), responsible (R), consulted (C)

and informed (I) for each process that is carried out at different stages of the asset life cycle.

Table 2 – Responsibility assignment matrix

Asset life cycle stage Process Asset owner Asset owner (operator)

Asset owner (maintainer)

System integrator

Product supplier

Plan Identify system under consideration

A, R C

Plan Perform criticality assessment A, R C C

Plan Partition SuC into security zones and conduits

A, R C

Plan Assign initial security level targets A, R C

Acquire Identify threats A, C C C R C

Acquire Identify vulnerabilities A, C C C R C

Acquire Determine unmitigated cyber risk A, C C C R C

Acquire Determine security level targets A, C C C R

Acquire Identify and evaluate existing countermeasures

A, C C C R C

Acquire Determine residual cyber risk A, C C C R

Acquire Determine risk acceptance A, C C C R

Acquire Apply additional cybersecurity countermeasures

A, C C C R C

Operate/maintain Monitor and review threats A, C C R C

Operate/maintain Monitor and review vulnerabilities A, C C R C




The description of each party responsible is provided in Table 3.

Table 3 – Description of responsible parties

Responsibility Description

Responsible The person or persons who are actively expected to engage in the activity.

Accountable The person who is ultimately accountable for the results. Has the authority to make decisions.

Consulted The person who has relevant expertise / information to contribute to the risk analysis and evaluation. This person is involved prior to decisions.

Informed The person who does not need to participate in the risk management but needs to be kept informed. This person needs to know of the decision or action.




Appendix B Overview of IDEF0 syntax The IDEF0 box and arrow syntax is shown in Figure 17.

A0

Process or function nameInput Output

Control

Mechanism

Figure 17- IDEF0 box and arrow semantics

An example IDEF0 diagram is shown in Figure 18. The diagram shows the following elements:

• IDEF0 process or function name - ‘identify SuC’

• IDEF0 inputs - operations concept, maintenance concept, preferred and alternate options

• IDEF0 outputs - boundaries and points of access

• IDEF0 controls - IEC/TS 62443-1-1

• IDEF0 mechanisms - asset owner (shown as accountable and responsible) and system

integrator (shown as consulted)

6.1

Identify SuCOperations concept

Maintenance concept

Asset owner(A,R)

IEC/TS 62443-1-1


System integrator

(C)



Figure 18 - Example IDEF0



Appendix C Implementation examples Examples of selected process outputs have been provided to assist in the implementation of

this procedure and are informative only.

The examples are not exhaustive.

Some of the workbooks contained in Appendix F of HB 167:2006 have been adapted for these

examples.

C.1. Digital train radio system A digital train radio system (DTRS) is a digital radio system that facilitates voice and data

communications throughout the metropolitan railway networks (inclusive of yards and sidings),

train control and signalling facilities as well as rolling stock.

A DTRS is chosen as the SuC for this example.

Note: This implementation example is fictitious and no identification should be made

or relate to the DTRS operated by Sydney Trains.




C.1.1 Boundaries and points of access – SuC Figure 19 shows an example context drawing of logical points of access between DTRS SuC and other enterprise systems.

Digital train radio system(DTRS)

Train location system

Faultmanagement

system

Operations PABX

Assetmanagement

system

Configuration management

system

Enterprise systems System under consideration (SuC)

Recordsmanagement

system

Industrial automation and control systems

(IACS)


Figure 19 - Example DTRS context drawing



C.1.2 Boundaries and points of access – SuC process and utility areas Figure 20 shows an example context drawing of physical and logical points of access.

The boundaries of physical access are represented as ‘sites’ and depicted using round-edged rectangles with solid lines.

Logical access is represented as wide area networks (WAN) and local area networks (LAN).

In this example, LANs are trusted and are depicted as white conduits, while WANs are untrusted and are depicted as dark grey conduits.

DTRS Core (Primary Site)

DTRS BTS Site A

DTRS LAN

Portable HMI terminal BTS

DTRS LAN

Operations DMZ (Primary Site)

MSC GGSNSGSNMMSC HLRSMSC

Router(Primary)

Router (Secondary)

Core Router

Patchserver

Network services

Security servicesNMS HistorianVRS

Corporate DMZ (Primary Site)

Site not developed in this example.Site not developed in this example.

WAN conduit to DTRS Core (Secondary Site)– not developed in this example.

VMSBSCMGWSoftswitch

Mobile station(MS)

Mobile station(MS)

BTS

GSM air interface

UPS

WAN conduit to DTRS Core (Secondary Site)– not developed in this example.


Figure 20 - Example DTRS context areas drawing



C.1.3 Criticality ratings An example table for the DTRS SuC is shown in Table 4.

Table 4 - Example criticality / high-level risk assessment table for DTRS SuC – by risk events and scenarios

Process or utility area

Risk event Risk scenario Consequence impact area

Consequence descriptor and rating

Risk descriptor & rating

SuC Loss of availability

Core router fails at all core network sites. Network-wide use of backup radio system (degraded operations) with delays in responding to emergencies.

Health and safety (injury and disease)

Moderate (rating – C4) High (B)

SuC Loss of availability

Core router fails at all core network sites. Network-wide use of backup radio system (degraded operations) with major operational impacts.

Customer experience and operational reliability

Major (rating – C3) Very high (A)

An example table for the ‘core network site’ utility area of a digital train radio system (DTRS) SuC is shown in Table 5.

Table 5 - Example criticality / high-level risk assessment table for DTRS ‘core network site’ – by risk events and scenarios





Core network site Loss of availability

Core router fails at one core network site. Switchover to alternate core router with delays in responding to emergencies. Failure to switchover to alternate core router with network-wide use of backup radio system (degraded operations) with delays in responding to emergencies.

Health and safety (injury and disease)

Insignificant (rating – C6)

Medium (C)








Core network site Loss of availability

Core router fails at one core network site. Switchover to alternate core router with minor operational impacts. Failure to switchover to alternate core router with network-wide use of backup radio system (degraded operations) with major operational impacts.

Customer experience and operational reliability

Minor (rating – C5) High (B)

An example criticality rating for the processes and utility areas within the DTRS SuC is shown in Table 6.

Table 6 - Example criticality ranking of process and utility areas and DTRS SuC

Criticality rating Process and utility areas

A DTRS SuC

B Core network site

C Mobile Station (MS), Base Transceiver Station (BTS) Site




C.1.4 Security zones and conduits An example of zones and conduits drawing is shown in Figure 21.

The security zones and conduits model has been adapted to suit the SuC and differs from the reference model described in T MU SY 10010 ST.

The zones are based on physical sites and are depicted using rounded-edged rectangles with solid lines.

The zones that are based on logical principles are depicted using round-edged rectangles with dotted lines.

LANs are under the direct control of DTRS and are considered trusted, while WANs are considered untrusted.

Trusted conduits are depicted as white conduits, while untrusted conduits are depicted as grey conduits.

DTRS Core (Primary Site)

DTRS DMZ

DTRS Services DMZ

DTRS BTS Site A

DTRS LAN

DTRS Core Network

Portable HMI terminal BTS

DTRS LAN

Operations DMZ (Primary Site)

MSC GGSNSGSNMMSC HLRSMSC

Router(Primary)

Router (Secondary)

Core Router

Patchserver

Network services

Security servicesNMS HistorianVRS

Corporate DMZ (Primary Site)

Zone not developed in this example.Zone not developed in this example.

WAN conduit to DTRS DMZ (Secondary) – not developed in this example.

VMSBSCMGWSoftswitch

Mobile station(MS)

Mobile station(MS)

BTS

GSM air interface

UPS

WAN conduit to DTRS DMZ (Secondary) – not developed in this example.


Figure 21 - Example DTRS zones and conduits drawing



C.1.5 Threats register An example of a threats register with select threats to the core router asset is shown in Table 7.

Table 7 - Example DTRS threats register

ID Zone affected Asset affected Threat agent Threat actions – CAPEC™ category

Threat actions – CAPEC™ attack pattern

Threat actions – Attack description

Security event

THR-01 DTRS DMZ Core router External 403 Social engineering

410 Information elicitation

Obtain information about the core router

Loss of availability – disruption to IACS functions

THR-05 DTRS DMZ Core router External 437 Supply chain 439 Modification during distribution

Modification or manipulation of the core router during distribution


THR-10 DTRS DMZ Core router Internal 513 Software 112 Brute force Brute force using password recovery tool to obtain privileged credentials for core router


THR-10 DTRS DMZ Core router Internal 513 Software 114 Authentication abuse

Log on to core router using valid privileged credentials obtained using illegitimate means


THR-17 DTRS DMZ Core router Internal External

514 Physical security

390 Bypassing physical security

Use previously issued key to obtain physical access to core router

Loss of availability – disruption to IACS functions Loss of availability – destruction of IACS or information assets




C.1.6 Vulnerabilities register An example of a vulnerabilities register with select vulnerabilities to the core router asset is shown in Table 8.

Table 8 - Example DTRS vulnerabilities register

ID Zone affected Asset affected Vulnerability – CVE® entry

Severity – CVSS score

Weakness – CWE™ category

Vulnerability description

Security event

VUN-01 DTRS DMZ Core router XYZ CVE-YYYY-XXXX 6.5 (Medium) 310 Cryptographic issues

Weak cryptographic algorithm for stored passwords

Loss of confidentiality – disclosure of information assets Loss of availability – disruption to IACS functions




C.1.7 Fault tree analysis An example of a fault tree with select branches to a core router is shown in Figure 22.

Obtain privileged credentials for

Core Router

Brute force attack using recovery tool

(CAPEC 112)

Core Router XYZ vulnerable

Core Router exploitable

Log on using valid privileged

credentials (CAPEC 114)

Alter configuration of Core Router

Use previously issued physical key

(CAPEC 390)

Obtain physical access to

Core Router

Physically destroy device

(CAPEC 547)

Core Router fails at one Core Network

site

Password recovery tool

Unauthorised employee (internal threat)

Core Router XYZ

Weak cryptographic algorithm for

stored passwords

Disgruntled former

employee (external threat)

Switchover to alternate Core Router with minor operational impact

Failure to switchover to alternate Core Router with network-wide use of backup radio system (degraded

operations) with major operational impact


Figure 22 - Example DTRS fault tree analysis



C.1.8 Risk register An example of a risk register with select risks to the core router asset is shown in Table 9, Table 10, Table 11, Table 12 and Table 13.

Table 9 - Example risk register – risk identification

Risk name Risk event Causes Consequences

DTRS_SuC-01 Core router fails at all core network sites

Unauthorised employee (threat agent) uses weak cryptographic algorithm for stored passwords in all core routers (vulnerability) to exploit core routers, obtain privileged access and alter configuration (threat actions)

Failure to switchover to alternate core router with network-wide use of backup radio system (degraded operations) with delays in responding to emergencies and major operational impacts.

DTRS_DMZ-01 Core router fails at one core network site

Unauthorised employee (threat agent) uses weak cryptographic algorithm for stored passwords in core router (vulnerability) to exploit core router, obtain privileged access and alter configuration (threat actions)

Switchover to alternate core router with delays in responding to emergencies and minor operational impacts. Failure to switchover to alternate core router with network-wide use of backup radio system (degraded operations) with delays in responding to emergencies and major operational impacts.

DTRS_DMZ-02 Core router fails at one core network site

Disgruntled former employee (threat agent) obtains physical access to core router and destroys it (threat actions)

Switchover to alternate core router with delays in responding to emergencies and minor operational impacts. Failure to switchover to alternate core router with network-wide use of backup radio system (degraded operations) with delays in responding to emergencies and major operational impacts.




Table 10 - Example risk register – risk analysis – inherent risk

Risk name Inherent controls Control effectiveness Likelihood rating Consequence rating Inherent risk rating

DTRS_SuC-01 By default, passwords are stored on core router using a reversible encryption algorithm (DES, AES)

Ineffective Unlikely Major C

DTRS_DMZ-01 By default, passwords are stored on core router using a reversible encryption algorithm (DES, AES)

Ineffective Unlikely Minor D

DTRS_DMZ-02 HR Separations Policy Physical keys

Ineffective Unlikely Minor D

Table 11 - Example risk register – risk analysis – residual current risk

Risk name IEC 62443-3-3 foundational requirements

IEC 62443-3-3 system requirements

Current controls Control effectiveness

Likelihood rating

Consequence rating

Residual current risk rating

DTRS_SuC-01 Identification and authentication control (IAC) Use control (UC) Data confidentiality (DC) Timely response to events (TRE) Resource availability (RA)

SR 1.5 - Authenticator management SR 4.3 - Use of cryptography SR 6.2 - Continuous monitoring SR 7.4 - Control system recovery and reconstitution

Use irreversible hashing algorithm for stored passwords (SR 1.5, SR 4.3) Central monitoring of access control and configuration changes (SR 6.2) Device configuration files stored in configuration management system (SR 7.4)

Effective Very unlikely Minor D




Risk name IEC 62443-3-3

foundational requirements


Current controls Control effectiveness

Likelihood rating

Consequence rating

Residual current risk rating

DTRS_DMZ-01 Identification and authentication control (IAC) Use control (UC) Data confidentiality (DC) Timely response to events (TRE) Resource availability (RA)


Use irreversible hashing algorithm for stored passwords (SR 1.5, SR 4.3) Central monitoring of access control and configuration changes (SR 6.2) Device configuration files stored in configuration management system (SR 7.4)

Effective Very unlikely Insignificant D

DTRS_DMZ-02 Identification and authentication control (IAC) Resource availability (RA)


HR Separations Policy Physical keys (SR 1.5) Central monitoring of access control and configuration changes (SR 6.2) Device configuration files stored in configuration management system (SR 7.4)

Effective Unlikely Insignificant D

Table 12 - Example risk register – risk classification and evaluation

Risk name Risk owner Risk category Risk evaluation

DTRS_SuC-01 TfNSW Customer experience and operational reliability ‘Broadly acceptable’ to TfNSW, ‘tolerable’ to operator and maintainer, but risk is able to be reduced further. Apply additional controls.

DTRS_DMZ-01 TfNSW Customer experience and operational reliability ‘Broadly acceptable’ to TfNSW, ‘tolerable’ to operator and maintainer, but risk is able to be reduced further. Apply additional controls.

DTRS_DMZ-02 TfNSW Customer experience and operational reliability ‘Broadly acceptable’ to TfNSW, ‘tolerable’ to operator and maintainer, but risk is able to be reduced further. Apply additional controls.




Table 13 - Example risk register – risk analysis – residual planned risk

Risk name IEC 62443-3-3 foundational requirements


Planned controls Control effectiveness

Likelihood rating

Consequence rating

Residual planned risk rating

DTRS_SuC-01 Identification and authentication control (IAC) Use control (UC) Data confidentiality (DC) Timely response to events (TRE) Resource availability (RA)

SR 1.1 RE 2 - Multifactor authentication for untrusted networks SR 2.8 RE 1 - Centrally managed, system-wide audit trail SR 7.3 RE 2 - Backup automation

SR 1.1 RE 2 - Multifactor authentication for privileged access Central monitoring of access control and configuration changes (SR 2.8 RE 1) Device configuration files stored in configuration management system (SR 7.3 RE 2)

Effective Almost unprecedented

Minor D

DTRS_DMZ-01 Identification and authentication control (IAC) Use control (UC) Data confidentiality (DC) Timely response to events (TRE) Resource availability (RA)

SR 1.1 RE 2 - Multifactor authentication for untrusted networks SR 2.8 RE 1 - Centrally managed, system-wide audit trail SR 7.3 RE 2 - Backup automation


Effective Almost unprecedented

Insignificant D

DTRS_DMZ-02 Identification and authentication control (IAC) Resource availability (RA)

SR 2.8 RE 1 - Centrally managed, system-wide audit trail SR 7.3 RE 2 - Backup automation


Effective Very unlikely Insignificant D


t mu sy 10013 pr cybersecurity for iacs – cyber risk ... · t mu sy 10013 pr cybersecurity for...

Documents