nz pids threat and risk assessment workshop report

Customer Logo

KiwiRail AZ6-, Version 30/06/14

Rail Technology System SIG##TES&EDB000

PIDS Threat and Risk Assessment Page 1 of 47

Copyright Siemens AG 2013 All Rights Reserved Restricted

PIDS Threat and Risk Assessment

Workshop Report

KiwiRail

Rail Technology System

Author: Phil Cook (RGB Assurance)

KiwiRail Project Manager:

Project Manager:

Date Issued: 30/06/14

Version: 0.1

Customer Logo





Document Information & Version History

TITLE:

DOCUMENT PURPOSE:

DELIVERABLE NUMBER: / AZ6-

Siemens Approval

NAME DEPARTMENT SIGNATURE DATE

Released by:

Reviewed by:

Prepared by:

KiwiRail Approval

NAME POSITION SIGNATURE DATE

Version Control

VERSION REFERENCE COMMENTS REVISED BY DATE

0.1 Initial draft Phil Cook 30/06/14

Document Distribution

NAME POSITION

References

NO SOURCE / DOCUMENT NUMBER TITLE VERSION

[1] Rail 9000 Project Detailed Business Requirements

0.1

Customer Logo





Transmittal, reproduction, dissemination and/or editing of this document

as well as utilisation of its contents and communication thereof to others

without express authorisation are prohibited. Offenders will be held liable for

payment of damages. All rights created by patent grant or registration of a

utility model or design patent are reserved.

Customer Logo





Table of Contents

1 Introduction ...........................................................................................................................5

1.1 Scope and Purpose of this Document ....................................................................................5

1.2 Abbreviations & Definitions .....................................................................................................5

2 Background ...........................................................................................................................6

3 Workshop Methodology .......................................................................................................7

4 Initial Risk Assessment .......................................................................................................9

4.1 System Overview ....................................................................................................................9

4.2 Assets .....................................................................................................................................9

4.3 Threats and Risk Ratings .................................................................................................... 11

5 Proposed Design and Residual Risk Assessment......................................................... 17

5.1 Mitigation Strategies Considered......................................................................................... 17

5.2 Proposed Design ................................................................................................................. 17

5.3 Residual Risk Ratings ......................................................................................................... 18

6 Business Requirements Relating to Proposed Design ................................................. 20

7 Actions ................................................................................................................................ 27

List of Figures ...................................................................................................................................... 28

List of Tables ....................................................................................................................................... 29

Appendix A Workshop Presentation Slides .................................................................................. 30

Appendix B Workshop Attendance Register ................................................................................. 41

Appendix C Facilitator Notes .......................................................................................................... 43

Customer Logo





1 Introduction

1.1 Scope and Purpose of this Document

This report documents the proceedings and outcomes of a Threat and Risk

Assessment workshop that was facilitated by Siemens for the KiwiRail and

Auckland Transport PIDS project. The workshop took place in Brisbane,

Australia, on the 24th and 25th of June, 2014. The scope of the workshop was

limited to possible ICT security risks that may be created by the introduction of a

connection between the KiwiRail Signalling Network and the KiwiRail Corporate

Network, and in particular on how those risks might impact the safety and/or

operational availability of KiwiRails train control and signalling systems.

1.2 Abbreviations & Definitions

Table 1 Abbreviations

Abbreviation Explanation

ARS Automatic Route Setting

ESB Enterprise Service Bus

ICT Information and Communications Technology

KR KiwiRail

PIDS Passenger Information Display System

REST REpresentational State Transfer

Customer Logo





2 Background

KiwiRail, New Zealands Rail Infrastructure Manager, employ Siemens train

control and signalling technologies to safely manage rolling stock movements

throughout New Zealand. In particular, KiwiRail operate the Rail 9000 system,

which provides train control and Automatic Route Setting (ARS) functionality. The

Rail 9000 system, as well as the interlocking and object controller devices with

which it communicates, are interconnected via a dedicated Signalling Network.

This network currently has no physical connection to any other network, with the

exception of an external connection provided to enable Siemens staff to provide

support services to KiwiRail.

Auckland Transport are interested in obtaining real-time train movement

information from the Rail 9000 system:

to enhance the train movement information provided to their Passenger

Information Display System (PIDS); and

to forward to Transdev as an input to a newly procured performance

measurement system.

The technical solution required to achieve this goal will, necessarily, create a

connection between the KiwiRail Signalling Network and the KiwiRail Corporate

Network. Introducing such a connection has ICT security implications: it could

provide a path for an attacker to access and/or manipulate the data being

communicated on the KiwiRail Signalling Network, which could in turn threaten

the safety and/or operational availability of the railway.

Siemens were asked by KiwiRail to facilitate a Threat and Risk Assessment

Workshop to address this concern. The outcomes of this workshop are the

subject of the current report.

Customer Logo





3 Workshop Methodology

The methodology employed in the workshop was based on a standard Siemens

process for analysis of ICT security threats. The analysis process was as follows.

1. A description of the proposed solution (see Section 4.1) was reviewed by

the workshop facilitators prior to the workshop. From this, the facilitators

identified five assets which required protection. These assets were all

related to critical functions performed by the Rail 9000 and signalling

systems (protecting the functionality of PIDS itself was assumed to be

outside the scope of the workshop).

2. During the workshop, this initial list of assets was reviewed by the

participants, and a number of additional assets were proposed. The list of

assets is presented in Section 4.2.

3. A standard list of attackers was used (see Slide 10 in Appendix A). This

list was presented to the participants in the workshop and used to guide

the analysis.

4. The assets and attackers (or threat sources) were used to identify

potential threats. This exercise was carried out during the workshop, with

all participants present. For the purposes of this exercise, it was assumed

that no design controls were in place to manage the security of the

connection between the KiwiRail Signalling Network and KiwiRail

Corporate Network.

5. The likelihood and impact of each threat were rated according to the

tables on slides 13, 16, and 17 in Appendix A, resulting in an initial risk

rating, according to the risk matrix shown on slide 20 in Appendix A.

Again, it was assumed that no design controls were in place during this

exercise. However, existing mitigations (e.g., existing firewalls employed

on the KiwiRail corporate network) were taken into account. The results of

this phase of the workshop are documented in Section 4.3.

6. The participants discussed a number of potential mitigations that could be

introduced to reduce risk. These potential mitigations were noted on a

whiteboard and each was given a rough score in terms of its cost impact

and anticipated effectiveness in reducing risk. Some of the mitigations

were competing alternatives, whereas others were mitigations that could

or should be used in concert with others.

7. From this discussion, a single mitigation technique stood out as being

highly effective and of moderate cost. The likelihood and risk ratings

associated with each threat were re-assessed taking this mitigation into

account to confirm its effectiveness. This mitigation and its resulting effect

on the risk ratings are presented in Section 5.

Customer Logo





8. Once this mitigation was settled on, the participants discussed potential

business requirements that could be applied to adequately characterise a

solution based on this mitigation. The results of this discussion are

captured in Section 6.

As the workshop included participants from all the key stakeholders of the project

(Siemens, KiwiRail, Auckland Transport, and Transdev), there were a number of

topics discussed that were not strictly related to the security of the design.

Actions resulting from these discussions, as well as actions following the security

assessment itself, are captured in Section 7.

Slides presented during the workshop describing this methodology are shown in

Appendix A.

Appendix B lists the attendees at the workshop.

Detailed notes capturing what was discussed during the workshop are presented

in Appendix C.

Customer Logo





4 Initial Risk Assessment

4.1 System Overview

The following figure illustrates the conceptual architecture that was considered

during the initial risk assessment. The blocks in this figure are primarily functional

in nature physical servers, network switches, etc. are not shown.

Figure 1 Initial Conceptual Architecture for Risk Assessment

Note: This architecture differs slightly from that shown in the presentation slides

in Appendix A the figure above represents the architecture following discussion

with the workshop participants.

4.2 Assets

The main security concern in the workshop was protecting operation of the train

control and signalling systems. As such, the assets considered in the assessment

primarily relate to the functions of these systems, rather than to concrete data,

software, or hardware assets.

Customer Logo





The following table lists the assets considered in the risk assessment. Items 1

through 5 were identified by the facilitators prior to the workshop. Items 6 through

11 were proposed as additional assets to consider by the workshop participants.

Table 2 Assets Considered in Risk Assessment

# Asset Description

1 Safety of routes Provides train separation. Proposed by facilitators prior to workshop.

2 Efficiency of routes Keeps rail services running on time. Requires that routes be set: - correctly / optimally; and - on time. Proposed by facilitators prior to workshop.

3 Axle counter reset management

Supports above. Proposed by facilitators prior to workshop.

4 Track block management Protects track workers. Proposed by facilitators prior to workshop.

5 Train location information Provides situational awareness to Train Controllers to support above. Proposed by facilitators prior to workshop.

6 Working timetable Fundamental to ARS operation; supports "Efficiency of routes". Proposed by participants during workshop.

7 Reputation / public confidence

Abstract asset that may be affected by safety incidents or service disruptions. Proposed by participants during workshop.

8 Level crossing operation Protects general public at road-rail interfaces. Proposed by participants during workshop.

9 Obscurity of design Relied on for some aspects of the security of the KiwiRail Signalling Network (e.g., physical location of some key servers are known to only a few KiwiRail staff). Proposed by participants during workshop.

10 Operational confidence Related to system users' confidence. Abstract asset that may be affected by safety incidents. Proposed by participants during workshop.

11 Control of operator workload Relied upon to ensure operational staff are able to effectively discharge their safe-working duties. Proposed by participants during workshop.

The additional six assets identified by workshop participants were considered in

the threat assessment, but none were shown to identify new threats (e.g., threats

Customer Logo





relating to the Working timetable asset were all equivalent to threats relating to

the Efficiency of routes asset).

4.3 Threats and Risk Ratings

A total of thirteen threats were identified during the workshop. Two of these

threats were given a risk rating of Major, two a risk rating of Minor, and the

remainder a risk rating of Intermediate.

The details of the threats and their initial risk ratings are presented in the

following table.

Customer Logo





Table 3 Initial Risk Assessment

# Asset Threat Explanation Threat Source Likelihood of a Successful Attack Impact Risk Comments

Comment Rating Comment Rating

1 Safety of routes Attacker accesses signalling network from outside KR corporate network (or inject malware) and manipulates vital protocol between interlocking sites to manipulate routes.

Skilled Hacker Existing mitigations: Knowledge of vital protocol required Firewall(s) around KR corporate network Core switches logically separate networks

Possible Could cause injury / loss of life Would also lead to significant downtime to investigate

Disastrous Intermediate

2 Safety of routes KR corporate network administrator infiltrates signalling network and manipulates vital protocol between interlocking sites to manipulate routes.

Administrator Existing mitigations: Knowledge of vital protocol required Core switches logically separate networks



3 Safety of routes Attacker accesses signalling network from outside KR corporate network (or inject malware) and manipulates ATP telegrams transmitted from LEUs

Skilled Hacker Existing mitigations: Knowledge of vital protocol required Firewall(s) around KR corporate network Core switches logically separate networks Two proprietary protocols would need to be hijacked Driver would notice discrepancy betwee in-cab and lineside signalling



Customer Logo







4 Efficiency of routes

Denial of service of JBoss server which would stop ARS

Hacker (curious) Skilled Hacker Competitor

Existing mitigations: Firewall(s) around KR corporate network Passwords Web Service only operates over HTTPS to AT network Firewall monitoring and malware protection on KR corporate network

Possible Disruption of 1-4 hr Critical Intermediate


Attacker accesses R9K and acts as operator.

Skilled Hacker Competitor

Existing mitigations: Firewall(s) around KR corporate network Passwords

Possible Could reset all signals; could cause emergency braking by ATP Disruption of 1-4 hr

Critical Intermediate


Attacker logs into server(s) and resets/reconfigures network devices and/or virtual machines, resetting all signals.


Existing mitigations: Firewall(s) around KR corporate network Passwords Password management on R9K side is not up to same standard as KR corporate network

Possible Disruption of up to 12 hrs May not have ready access to pristine configuration data



Denial of service against network devices - could cause devices to shutdown and require hard reset


Existing mitigations: Firewall(s) around KR corporate network Passwords

Possible Disruption of up to 12 hrs


Customer Logo








Attacker logs into server(s) and resets/reconfigures network devices and/or virtual machines, resetting all signals.

Administrator Likely Disruption of up to 12 hrs May not have ready access to pristine configuration data

Disastrous Major


Attacker accesses R9K and acts as operator.

Administrator Likely Disruption of up to 12 hrs May not have ready access to pristine configuration data

Disastrous Major

- Axle counter reset management

n/a n/a n/a No specific threats were identified for this asset - covered by other assets above.

10 Track block management

Attacker accesses R9K and acts as operator, lifting block.


Existing mitigations: Firewall(s) around KR corporate network Passwords Safe-working procedures followed by track workers, Hi-Rail operators, train drivers, etc. Train Controller situational awareness

Possible Could cause injury / loss of life Would also lead to significant downtime to investigate Very unlikely to cause multiple deaths


Customer Logo







11 Track block management

Attacker accesses R9K and acts as operator, lifting block.

Administrator Existing mitigations: Safe-working procedures followed by track workers, Hi-Rail operators, train drivers, etc. Train Controller situational awareness

Possible Could cause injury / loss of life Would also lead to significant downtime to investigate Very unlikely to cause multiple deaths


12 Train location information

Attacker accesses R9K and changes train IDs and/or train location information.

Skilled Hacker Existing mitigations: Firewall(s) around KR corporate network Passwords

Possible Could disrupt ARS Disruption on order of 1/2 hour Could affect passenger information presented to customers

Moderate Minor

13 Train location information

Attacker accesses R9K and changes train IDs and/or train location information.

Administrator Possible Could disrupt ARS Disruption on order of 1/2 hour Could affect passenger information presented to customers

Moderate Minor

- Working timetable


Customer Logo







- Reputation / public confidence


- Level crossing operation


- Obscurity of design


- Operational confidence


- Control of operator workload


Customer Logo





5 Proposed Design and Residual Risk Assessment

5.1 Mitigation Strategies Considered

A number of potential mitigation strategies were discussed during the workshop.

These were noted on a whiteboard and each was given a rough score in terms

of its cost impact and anticipated effectiveness in reducing risk. Some of the

mitigations were competing alternatives, whereas others were mitigations that

could or should be used in concert with others. The following table summarises

these mitigations and the rough scoring applied, with lower numbered scores

representing a less expensive/more effective option.

Table 4 Mitigations Considered

Mitigation Effectiveness (1 to 5)

Cost (1 to 5)

Two firewalls with proxy device in between 2 2

Secure protocols between PIDS Interface and KiwiRail Corporate Network

3 -

Unidirectional SOAP 3 1

Unidirectional, non-IP interconnect (e.g., serial) 1 2

PIDS Interface on separate Layer 2 network 4 1

PIDS Interface on separate Layer 2 network and External Interface on separate server

3 4

Three firewalls with PIDS Interface in between two of them 2 2

Diverse firewalls 5 -

Unidirectional UDP 2 3

Intrusion detection 3 4

Separate administrative zones 3 -

5.2 Proposed Design

Of the mitigation strategies discussed in the previous section, the option that

provided the most effective risk reduction was the Unidirectional, non-IP

interconnect option. This is depicted in the following figure.

Customer Logo





Figure 2 Proposed Design

The key element of this design is the use of a unidirectional serial link to

interconnect the two networks. The serial link could be either copper (e.g., RS-

422) or optical fibre. In either case, however, the design rests upon the

assumption that the receive line(s) are physically severed to prevent any

possibility of communication from the KiwiRail Corporate Network to the KiwiRail

Signalling Network.

The PIDS Interface and Listener Server elements consist of software

developed by Siemens to translate messages from the Rail 9000 External

Interface (JMS) to a form that can be consumed by the Mule ESB and, ultimately,

Auckland Transport. COTS Terminal Servers would be used to form the serial

interconnect in order to ease implementation (e.g., by removing the need to

specialised serial interfaces on the rack mounted servers hosting the PIDS

Interface and Listener Server elements.

5.3 Residual Risk Ratings

The threats described in Section 4.3 were re-rated taking this design into

consideration. The likelihood of each risk was reduced to Improbable (though, in

Customer Logo





actuality, each risk is no longer credible under the proposed design) and, as a

result, the overall rating of each risk was reduced to Minor.

Customer Logo





6 Business Requirements Relating to Proposed

Design

Following initial discussion of the proposed design presented in the previous

section, the workshop participants a number of business requirements that could

be used to constrain the solution sufficiently to allow cost estimation to proceed.

This section documents the outcomes of that discussion.

The focus of these business requirements is on the new elements to be provided

by Siemens these are referred to as the Rail 9000 Data Feed below, which is

defined to consist of:

- the PIDS Interface software and, if necessary1, hardware;

- Terminal Servers #1 and #2; and

- the Listener Server software and hardware.

The following key assumption underpins the proposed design:

Key Assumption Auckland Transport Systems can tolerate reception of

duplicate events from the Rail 9000 Data Feed.

The following table documents the business requirements discussed during the

workshop. Although the majority of them are related to the Rail 9000 Data Feed

itself, two of them (requirements 3 and 15) are related to other parts of the overall

solution. These two requirements are included here in order to completely

represent what was discussed in the workshop, but they are not related to the

subject of the workshop, nor to the scope of estimation for Siemens.

Table 5 Business Requirements

# Requirement Priority

1 The Rail 9000 Data Feed shall connect the KiwiRail Signalling Network to the KiwiRail Corporate Network via physically unidirectional, non-IP-based serial interface.

Mandatory

2 The Rail 9000 Data Feed shall enable software executing within the Auckland Transport Network to detect and isolate loss of the Rail 9000 Feed within two (2) minutes.

Mandatory

1 The PIDS interface software could potentially execute within the existing Rail 9000

virtualisation platform.

Customer Logo





# Requirement Priority

3 The KiwiRail Mule ESB system shall enable software executing within the Auckland Transport Network to detect and isolate loss of the KiwiRail Mule ESB system within two (2) minutes.

N/A

4 The Rail 9000 Data Feed shall transmit event data to the KiwiRail Mule ESB system in REST format with the KiwiRail Mule ESB system acting as the RESTful service.

Mandatory

5 The Rail 9000 Data Feed shall transmit event data to the RESTful service provided by the KiwiRail Mule ESB system via an HTTPS transport with Basic Authentication.

Mandatory

6 The Rail 9000 Data Feed shall transmit event data detailed in requirements 1.1, 1.2, 1.3, and 1.6 of Rail 9000 Project Detailed Business Requirements [1] to the RESTful service provided by the KiwiRail Mule ESB system.

Mandatory

7 The Rail 9000 Data Feed shall provide sufficient throughput to support at least four (4) times growth in the number of events transmitted relative to the current timetable.

Mandatory

8 The Rail 9000 Data Feed shall provide sufficient throughput and latency to transmit events for eighty (80) trains within five (5) seconds.

Mandatory

9 The Rail 9000 Data Feed shall support a Mean Time to Restore no greater than four (4) hours.

Mandatory

10 The Rail 9000 Data Feed shall have an Operational Availability no less than 99.93%.

Mandatory

11 The Rail 9000 Data Feed shall enable software executing within the Auckland Transport Network to detect if events are lost between the PIDS Interface and the Auckland Transport Network.

Desirable

12 The Listener Server and Terminal Server #2 shall be installed at a major KiwiRail site.

Desirable

13 The Rail 9000 Data Feed shall be supplied with a Maintenance Manual.

Mandatory

14 The Rail 9000 Data Feed shall be supplied in accordance with existing provisions for supply of equipment and software to KiwiRail by Siemens.

Mandatory

15 The KiwiRail Mule ESB system shall transmit event data supplied by the Rail 9000 Data Feed to Auckland Transport only.

N/A

The following table traces the requirements documented in the Rail 9000 Project

Detailed Business Requirements [1] to the requirements in Table 5.

Customer Logo





Table 6 Business Requirements Traceability

Requirement from Rail 9000 Project Detailed Business Requirements [1]

Trace to Table 5 Remarks

# Requirement Text # Requirement Text

1.1 KiwiRail Rail 9000 schedule information must be sent from KiwiRail to Auckland Transport


1.2 KiwiRail Rail 9000 schedule information includes all train stations in the Rail 9000 system. This spans as far south as Papakura Station to as far north as Waitakere Station


1.3 KiwiRail Rail 9000 schedule information includes all train types that may stop at or pass through a train station including non-passenger trains


1.4 The solution must send current Rail 9000 schedule information to Auckland Transport when requested by Auckland Transport. Current information covers a time frame from 30 minutes before the current time, until 60 minutes after the current time

Table 5 contains no requirement equivalent to this. However, implementation of this requirement is not precluded by the proposed solution (it would need to be implemented by software on the KiwiRail side).

Customer Logo








1.5 The solution must send historical Rail 9000 schedule information to Auckland Transport when requested by Auckland Transport. Historical information covers a time frame from up to 2 days ago, up to the present time. (eg: Following communication restoration after a period of communications failure between KiwiRail and Auckland Transport)


1.6 The Rail 9000 schedule information must contain the following data fields

See APPENDIX C Data Tables


1.7 Data used from tables Is copied into the historical information and is not referenced back to the tables. This is so the historical data does not change if the tables are changed


2.1 The solution must retain 7 days of historical data outside of the Rail 9000 system.


Customer Logo








2.2 The solution must handle information requests from Auckland Transport at a maximum rate of 1 request every 10 seconds.


2.3 The maximum data latency is 10 seconds.

The latency is measured from the time an Auckland Transport information request is received through the KiwiRail outer firewall, until the requested information is transmitted back to the KiwiRail outer firewall.

a) The data response must be transmitted back to the KiwiRail outer firewall within 10 seconds (inclusive) from the time the information request was received through the KiwiRail outer firewall

b) The data in the response must be no older than 10 seconds old at the time it is transmitted back.

8 The Rail 9000 Data Feed shall provide sufficient throughput and latency to transmit events for eighty (80) trains within five (5) seconds.

Requirement 8 from Table 5 is a stricter requirement than requirement 2.3 from Rail 9000 Project Detailed Business Requirements [1].

3.1 The Train Control environment is secure and cannot be accessed from outside the environment. The R9000 solution design must not reduce the security level currently in place for the Train Control environment.

Eg: Data within the Train Control environment must be pushed out of the Train Control environment. Request for the data cannot come from outside the environment to inside the environment.


Customer Logo








3.2 There must be no ability for a software failure at Auckland Transport to be able to affect the performance of the Rail 9000 system.

Ie: Create a flood of requests into the Rail 9000 system inducing a denial of service effect on the Rail 9000 system


4.1 The Rail 9000 schedule information is extracted from the Rail 9000 system using the Rail 9000 API

Table 5 contains no requirement equivalent to this. However, implementation of this requirement is not precluded by the proposed solution (it would need to be implemented by software on the Siemens side).

4.2 The KiwiRail existing infrastructure is re-used where possible to interface with Auckland transport

- KiwiRail ESB (Enterprise Service Bus)

4 The Rail 9000 Data Feed shall transmit event data to the KiwiRail Mule ESB system in REST format with the KiwiRail Mule ESB system acting as the RESTful service.


- KiwiRail Mule web services

Table 5 contains no requirement equivalent to this. However, implementation of this requirement is not precluded by the proposed solution.


- KiwiRail to Auckland Transport, private circuit

Table 5 contains no requirement equivalent to this. However, implementation of this requirement is not precluded by the proposed solution.

Customer Logo








4.5 The Rail 9000 schedule information is publicly available information. There is no security or encryption requirement over the content of this information during its transmission

Requirement 15 in Table 5 contradicts this statement.

Customer Logo





7 Actions

The following table summarises actions raised during the workshop (some of

which were incidental to the subject of the workshop).

Table 7 Actions

# Action Party Responsible

1 Check if KiwiRails administration of the Rail 9000 system is adhering to the KiwiRail Security Policy and implement corrective action if not.

KiwiRail

2 Check if password management for the Rail 9000 system is adhering to the KiwiRail Security Policy and implement corrective action if not.

KiwiRail

3 Determine if duplication of the Rail 9000 Data Feed is necessary and, if so, when such functionality should be implemented.

Auckland Transport

4 Review throughput and latency requirements for the Rail 9000 Data Feed and confirm or correct them.

Auckland Transport

Customer Logo





List of Figures

Figure 1 Initial Conceptual Architecture for Risk Assessment ......................................... 9

Figure 2 Proposed Design..............................................................................................18

Customer Logo





List of Tables

Table 1 Abbreviations ..................................................................................................... 5

Table 2 Assets Considered in Risk Assessment ..........................................................10

Table 3 Initial Risk Assessment ....................................................................................12

Table 4 Mitigations Considered ....................................................................................17

Table 5 Business Requirements ...................................................................................20

Table 6 Business Requirements Traceability................................................................22

Table 7 Actions .............................................................................................................27

Customer Logo





Appendix A Workshop Presentation Slides

Customer Logo





24-25 June 2014

Restricted Siemens AG 2014 All rights reserved.

Page 3 TRA - PIDS Griffiths, Cook / CT RTC ITS

TRA Workshop Process Day 1

Threat and Risk Assessment (Morning)

Identify assets we want to protect

Identify threats to those assets

Identify existing mitigations

Rate level of risk associated with each threat

Vulnerability Assessment (Afternoon)

Identify vulnerabilities associated with each component /

interface in design

Relate vulnerabilities to attacks

Identify new mitigations that could be applied to address the

vulnerabilities

Re-rate the level of risk associated with each threat, taking

proposed new mitigations into account

24-25 June 2014



PIDS Architecture

Customer Logo





Customer Logo





24-25 June 2014



PIDS Assets

The main thing we want to protect is

operation of the signalling system

24-25 June 2014



PIDS Assets

For discussion.

Safety of routes

Provides train separation

Efficiency of routes

Keeps rail services running on time

Requires that routes be set:

Correctly / optimally

On time

Axle counter reset management

Supports above

Track block management

Protect track workers

Train location information

Provides situational awareness to Train Controllers to support above

Customer Logo





24-25 June 2014



Attackers

Attacker Capabilities Adversary Goals Level of Access

Hacker (curious)Basic knowledge. Requires automatical tools

no targeted attack just "looking around"

Internet unprotected physical interfaces

Skilled HackerHigh knowledge. Can create his own tools

wanting to prove information insecurity wanting to have publicity getting paid by someone

Internet unprotected physical interfaces

AdministratorHigh technical skills and internal knowledge

acting for someone else for financial benefit

revenge

privileged access to the hardware and software of the system

but has written agreements

UserLittle technical knowledge but internal knowledge

wanting more access than he is authorized to

just playing around

low privileged access to the hardware and software of the system


Competitor Can buy capabilities

paying someone else to attack the system to destroy the providers reputation or to get access to confidential data

pays other internal or external attackers

Customer (operator)High technical skills and internal knowledge

wanting to enhance or unlock functionality for free



KiwiRail / Siemens InsiderHigh technical skills and internal knowledge

revenge hired by someone else



Customer Logo





24-25 June 2014



Steps towards a Threat and Risk Analysis

Step 1: System Inventory and Asset Identification

Step 2: Attacker and Threat Identification

Step 3: Threat Evaluation

What is the likelihood that the threat takes place?

Threat analysis

System inventory and Asset

identification

Attacker and

Threat Identification

Threat Evaluation

24-25 June 2014



Likelihood of a Successful Attack

Depends on multiple factors

Number of potential attackers

Skills of attackers

Motivation of attackers (depends on chances)

. . .

Hardly quantifiable

No reliable statistics exist

Classification

Mostly, a qualitative approach is being used

For the workshop we will use predefined categories

Customer Logo





24-25 June 2014



Likelihood of a Successful Attack

Likelihood of Successful Attack

Rating (Text) Attackers Vulnerability, Exploitability

Very likely Unintentional attack by regular users

No security measures, e.g. Unpatched OS No malware protection Known network protocols without security measures

Likely

Operating errors by persons with network access Intentional attacks by persons having network access

using simple to perform attacks (script kiddy level attacks)

Few security measures, e.g. Unpatched OS Weak malware protection Known network protocols with weak security measures

Possible

Severe operating errors by persons with network access Intentional attacks by persons having network access

using advanced attack schemes (skilled hacker) (e.g. injection attack, using advanced tools)

Some security measures, or Attack is complex, e.g.

OS weakness, but physical access protection to thesystem

Network protocol without integrity protection, butprotocol is complex

Improbable

Good security measures, or Attack is very complex, e.g.

Network protocol without integrity protection, butprotocol is very complex, e.g. series of protocol steps

24-25 June 2014



Steps towards a Threat and Risk Analysis

Step 1: System Inventory and Asset Identification

Step 2: Attacker and Threat Identification

Step 3: Threat Evaluation

Step 4: Impact Identification and Evaluation

What could happen?

Threat analysis

System inventory and Asset

identification

Attacker and

Threat Identification

Threat Evaluation

Impact Identification

and Evaluation

Customer Logo





24-25 June 2014



Impact (Amount of Damage)

Depends on multiple factors

Financial loss

Costs for recovery of system

Immaterial damages

. . .

Hardly quantifiable

Value of Information?

Depends on object, document or data

Classification

Mostly, a qualitative approach is being used

For the workshop we will use 4 predefined categories

24-25 June 2014



High Level Impact (Amount of Damage)

Impact

Rating (Text) I MO RA specific rating aspects

Disastrous Injury to persons Severe adverse effects to safety KF-Bedienung (Command Release)

Critical Disruption of operation for long period (the actual value depends on the product) Damage to reputation

Moderate Disruption of operation at customer site for short period (the actual value depends on the product) Breakdown of several systems, also for a short period of time

Negligible No adverse effects to the system as effects are compensated by safety mechanisms, e.g. one channel of

two parallel breaks down

Customer Logo





24-25 June 2014



Impact (Amount of Damage)

Imp

ac

t R

ati

ng

Impact areas

Rating Rating (Text) CostsDisruption of

customer service

Unavailability of systems or

componentsPhysical damage Hazard

Loss of Reputation

Legal Impacts

Cost in Euros for single occurrenceRemark: This column is only used for alignment of the impacts. Impact estimation is NOT done using this column

Duration Duration

Costs to restore functionality including loss of income

May be direct description of damage is easier to map to a threat

Safety impact possible yes/no

Public attention

Potential for future business loss

Violation of laws

Violation of standards

4 Disastrous > NZ $7.5 million > 12h Train damaged YesBad world wide press

Personal liability, jail, or fines > NZ $7.5 million

3 Critical > NZ $1.5 million > 1/2 h > 12 h NoFines > NZ $1.5 million

2 Moderate > NZ $150,000

Customer Logo





24-25 June 2014



Risk Rating

Within the workshop, we use a predefined risk management metric to calculate the

risk:

Risk

Risk Rating (Text) Description

Critical Controls for critical risks are required with highest priority.

Major Controls for major risks must be implemented.

IntermediateControls for risks should be discussed and a decision for or against implementation of controls should be made.

MinorThreats causing minor risk do not generally need controls but should be listed to be able to evaluate them in future releases.

24-25 June 2014



Risk Matrix

The threat & risk analysis results are displayed in the following risk matrix:

Risk Mapping

Overall Likelihood

Improbable Possible Likely Very likely

Imp

ac

t

Negligible Minor Minor Minor Minor

Moderate Minor Minor Intermediate Intermediate

Critical Minor Intermediate Major Major

Disastrous Minor Intermediate Major Critical

Customer Logo





24-25 June 2014



Threat and Risk Assessment

We will now work through the Threat & Risk List worksheet as a

group

Customer Logo





Appendix B Workshop Attendance Register

Day 1

Customer Logo





Day 2

Customer Logo





Appendix C Facilitator Notes

Day 1

Workshop commenced at approximately 9am.

1. All participants introduced themselves. Refer attendance sheet. There were representatives from Siemens Rail Automation, KiwiRail, Auckland Transport and TransDev.

2. The Project Manager from KiwiRail Brett Sumner kicked off the meeting. He outlined the history of this issue (i.e. obtaining a live data feed from the Rail 9000 (R9K) system for Auckland Transport to driver their PIDS and perform other KPI monitoring, without compromising the security, safety or reliability of the R9K system). He emphasized that from his perspective, while

safety was clearly of paramount importance, railway reliability was also critical.

3. Brett handed over to Carlos Dias (Solution Architect KiwiRail) to discuss their working understanding of what the system architecture would look like.

Refer attached slides from Carlos. 4. Karl Howard from Auckland Transport then spoke. He re-inforced many of

Bretts points and emphasised how important it was for AT to be able to access this data.

5. Luke Wildman from Siemens then spoke. He reminded all that the R9K system used protocols that were demonstrated to be safe enough for a Class 5 Open System, however all should remember that a Class 5 Open System by definition meant that there was no risk of unauthorised access, and therefore no possibility of a masquerade threat.

6. He explained that, with most modern communications systems, although protocols might claim to be uni-directional, in fact most involved receive acknowledgement and other handshaking and so, at the lower levels of the

protocol stack, were almost always bi-directional. 7. He said he was therefore keen to start with an assessment of the threats that

might exist, before analysing architectural vulnerabilities. 8. LW mentioned some workshop KPIs, that had been agreed with Brett

Sumners. These are: a. By the workshops end we want to have understood the full extent of

possible threats, and documented and risk assessed them; b. We want a detailed design that mitigates identified threats to an extent

considered acceptable from firstly a safety, but secondly a railway operational availability, perspective.

c. We want enough information so that workshop participants can return to their organisation and estimate resources (both time and cost) to deliver a working solution.

9. Phil Cook (RGB Assurance consultant working for Siemens Rail Automation) then commenced the formal part of the workshop. He spoke to the attached slides.

Customer Logo





10. The following comments were mentioned as the discussion around the slides ensued:

a. Phil Cook explained the concept of a clean architecture, and how it

was important to perform the initial assessment without assuming the existence of firewalls and the like (other than those that already exist).

b. It was pointed out that there was already a link between Siemens and KiwiRail, because Siemens support personnel could remotely dial in to the R9K network for support purposes. However, this connection is stand-alone, limited, and outside the scope of this workshop.

c. A question was raised as to whether the workshop should consider threats in the reverse direction, e.g. risk that an R9K operator or rogue software process could inadvertently push bad data or malware back onto the KiwiRail that could result in outcomes such as displaying inappropriate content on passenger displayed. It was agreed that this was outside the scope of the workshop.

d. Given that the methodology involved considering the risk delta involved in the introduction of a live data feed from R9K to KiwiRail, the question was asked about whether there was a security assessment of the original R9K system that could be leveraged for

this workshop? It was explained that while security was closely considered during R9K deployment, the consideration took a different form (i.e. assess the Class of system; agree it is a Class 5 Open System; check the compliance of the communications protocols and infrastructure against requirements for that Class of system).

e. Consideration turned to the identification of assets. A number of new assets were identified (refer main body of this report).

f. Consideration then turned to the threat assessment. The results of this are in general captured in .

g. A number of recommendations / follow-up actions were noted throughout the workshop. These are noted here for convenience:

i. Need to check that KiwiRails administration of the R9K system is adhering to the KiwiRail Security Policy (audit requirement), and implement corrective action if not.

ii. Need to check on password management for the R9K system

(may be covered by previous point) iii. Need to acknowledge that there are two different administrator

groups one for R9K and one for KiwiRail similar administrative procedures/protocols should apply to all?

h. In considering the threat assessment, a number of factors influencing the findings and assessments were made. These included:

i. At present, none of Siemens competitors have access to the R9K network. Siemens may want to consider applying a caveat to their security/safety guarantees. Permitting competitor access to this network would create a new vulnerability that is currently not present.

Customer Logo





ii. In discussing the issue of track worker protection and blocking, it was stated that for any significant exposure, it is KiwiRails practice to use Lock-out Zones in addition to blocking,

removing trackworker vulnerability to an accidental block removal. In fact, blocking alone, with no other protection, is only used in practice for short periods (e.g. for workers crossing track without adequate sighting distance).

iii. A recommendation was nevertheless made to ensure that block removal commands are not something that can be sent from ARS (or received remotely by the R9K system, except via the Train Controller workstation).

iv. General disaster recovery was discussed and it was stated that KiwiRail do have security responses planned for various scenarios that could arise.

11. By this stage, a first-pass threat assessment had been performed, and so the

meeting proceeded to consider vulnerabilities. 12. The original plan had been to perform a vulnerability assessment utilising an

interface hazard analysis (IHA) style of directed search. However, since the area of design vulnerability was so clearly characterised, it was agreed that

there would be little value in an IHA style approach and instead the meeting agreed to table proposed mitigations to the design vulnerability. Just to be clear, the identified design vulnerability was the interface point between the two networks, i.e. from the PIDS interface across to the KiwiRail receiving component.

13. A range of design mitigations were suggested. These are enumerated in Section 5.1.

14. These design mitigations were rated on two scales one for their level of effectiveness, in protecting against a threat (scale of 15 with 1 being best and 5 being worst); and another for their cost and complexity (scale of 15 with 1 being the simplest and easiest and 5 being the most complex and costly).

15. It was decided to examine the impact of these mitigations by taking a number of mitigations and, one by one, considering the impact on the overall risk assessment if one assumed that each mitigation was implemented.

16. This process was performed for the mitigation that had ranked highest on the

scale referred to above (i.e. uni-directional communications either serial or fibre with return wire snipped). It quickly became clear that such a protection would move all identified risks to the green or acceptable zone, because in all cases the likelihood of the attack went to improbable.

17. The process was then repeated for the second most highly ranked mitigation. This process produced a similar result, except for two cases where the likelihood did not move all the way to the Improbable zone and remained in the Unlikely zone. It was also agreed that there were other cases where, while the likelihood rating had moved into the Improbable zone, it was still considered by workshop participants to be more likely than the equivalent

Customer Logo





likelihood consideration for the first mitigation (i.e. the likelihood ranking scale is relatively coarse).

18. Based on this outcome, there was general consensus that the solution

involving uni-directional communications (either serial or fibre with return wire snipped), was the solution that should be adopted.

19. There followed a general discussion around this solution space, with the following points being noted:

a. Options for duplication should be considered. It was agreed that KiwiRail/Auckland Transport were prepared to take care of merging two streams of messages (and removing duplicates if necessary). Based on this, a design comprising an interface involving the A version of R9K talking to one instance of the PIDS Interface, and the B version talking to a second instance, was conceived.

b. It was agreed that during times when no trigger events were received by the PIDS interface, heartbeat message should still be sent.

c. It was agreed that if the two terminal servers in the solution were physically proximate, copper could be used, but for longer distances fibre would be needed.

20. At this point, the workshop broke for the day.

Day 2

1. The second day of the workshop commenced at 9am, Wednesday 25th June.

All participants from the previous day were in attendance. 2. Brett Sumner opened the meeting stating that his desires for the workshop

were to find a solution that (i) solved our problem; and (ii) was sufficiently well specified so that contributors to the solution had enough information to estimate a cost and a delivery date.

3. Brett mentioned that from KiwiRails perspective, they had hoped to have the PIDS interface in place and working by the 28th September, implying that a delivery from Siemens in the latter half of August was needed.

4. Other aspirations for the day were mentioned. One participant said that it would be good to have a RACI2 established for the tasks that need to happen to enable a solution to go live.

5. Another participant said it would be good to perform a schedule risk assessment on the various tasks.

6. It was agreed by all that the first task should be to specify a set of requirements.

2 A RACI is a tool that shows, for each particular activity or task, who is to be

Responsible for the task, Accountable for it, Consulted about it, or Informed about it.

Customer Logo





7. Phil Cook facilitated a requirements capture exercise. The requirements capture exercise included both a conceptual architecture, and a set of user requirements. These are documented in Section 6 of this report.

8. There was considerable debate about the amount of data and rate of data throughput that was required to be supported. The meeting consensus was captured, however a follow-up action on the part of KiwiRail/Auckland Transport was to review this requirement and either confirm or correct it.

9. Note was also taken of a set of original business requirements [1]. It was agreed that these should be traced to the user requirements to demonstrate partial completeness of the user requirements.

10. A detailed discussion between Karl Howard from Auckland Transport and Ben Carlyle from Siemens was held. This discussion went through the data fields in the XML packets produced by the PIDS interface. It quickly became apparent that source data for all of the data fields was not necessarily available yet for the R9K system, and so while the packet would be

transmitted there was either no data in that field or default data. At times, it was not always clear what the default data was. For example, if no arrival time was scheduled, then the packet transmitted the departure time. In general, there were two sources of data incompleteness. These were:

a. Not all of the necessary event triggers had yet been configured in the system; and,

b. Not all of the necessary data had been populated within the timetable. 11. There was discussion over the physical location of the system components. It

emerged from this discussion that a number of options were possible, with the option chosen impacting at once:

a. The cost to provide the infrastructure, on the KiwiRail side; and, b. The cost to provide the solution, on the Siemens side.

12. Finally a discussion was held regarding the individual activities required to deploy a solution, commencing from when participants left the workshop.

13. A draft Gantt chart was drawn on the white board (with time oriented vertically instead of horizontally). It quickly became apparent that taking into account

the commercial realities involve in issuing an order (not the least of which was agreeing whether a fixed price or a time and materials quote was called for), along with the resource constraints facing Siemens, that the target date would be in jeopardy. Nevertheless, actions over the following two weeks were

agreed. 14. As the meeting drew to a close, the original KPIs were reviewed. It was

agreed by all that these had been achieved. 15. The workshop concluded at approximate 3.10pm on Wednesday 25th June,

2014.

nz pids threat and risk assessment workshop report

Documents

risk assessment page

initial risk assessment

rail technology system

residual risk assessment

tesedb000 pids threat

restricted pids threat

risk ratings

copyright siemens ag