NZ PIDS Threat and Risk Assessment Workshop Report

Customer Logo
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
KiwiRail
AZ6-, Version
SIG##TES&EDB000
<Project document No RT>
Copyright Siemens AG 2013 All Rights Reserved
Restricted
30/06/14
Page 1 of 47
Customer Logo
Document Information & Version History

TITLE:
DOCUMENT PURPOSE:
<Project document No RT> / AZ6-
DELIVERABLE NUMBER:
Siemens Approval
NAME
DEPARTMENT
SIGNATURE
DATE
POSITION
SIGNATURE
DATE
COMMENTS
REVISED BY
DATE
Initial draft
Phil Cook
30/06/14
Released by:
Reviewed by:
Prepared by:
KiwiRail Approval
NAME
Version Control
VERSION
REFERENCE
0.1
Document Distribution
NAME
POSITION
References
NO
SOURCE / DOCUMENT NUMBER
[1]
TITLE
VERSION
Rail 9000 Project Detailed Business

Requirements
0.1
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 2 of 47
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.
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 3 of 47
Customer Logo
Table of Contents
1
1.1
1.2
Introduction ...........................................................................................................................5
Scope and Purpose of this Document ....................................................................................5
Abbreviations & Definitions.....................................................................................................5
Background ...........................................................................................................................6
Workshop Methodology.......................................................................................................7
4
4.1
4.2
4.3
Initial Risk Assessment .......................................................................................................9

System Overview ....................................................................................................................9
Assets .....................................................................................................................................9
Threats and Risk Ratings .................................................................................................... 11
5
5.1
5.2
5.3
Proposed Design and Residual Risk Assessment......................................................... 17

Mitigation Strategies Considered......................................................................................... 17
Proposed Design ................................................................................................................. 17
Residual Risk Ratings ......................................................................................................... 18
Business Requirements Relating to Proposed Design ................................................. 20
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
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 4 of 47
Customer Logo
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
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 5 of 47
Customer Logo
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.
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 6 of 47
Customer Logo
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.
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 7 of 47
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.
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 8 of 47
Customer Logo
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.
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 9 of 47
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
Safety of routes
Provides train separation.

Proposed by facilitators prior to workshop.
Efficiency of routes
Keeps rail services running on time.

Requires that routes be set:
- correctly / optimally; and
- on time.
Axle counter reset

management
Supports above.
Track block management
Protects track workers.

Train location information
Provides situational awareness to Train Controllers

to support above.
Working timetable
Fundamental to ARS operation; supports

"Efficiency of routes".
Proposed by participants during workshop.
Reputation / public
confidence
Abstract asset that may be affected by safety

incidents or service disruptions.
Level crossing operation
Protects general public at road-rail interfaces.

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).
10
Operational confidence
Related to system users' confidence.

Abstract asset that may be affected by safety
incidents.
11
Control of operator workload Relied upon to ensure operational staff are able to
effectively discharge their safe-working duties.
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
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 10 of 47
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.
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 11 of 47
Customer Logo
Table 3
#
Initial Risk Assessment
Asset
Threat Explanation
Threat Source
Likelihood of a Successful Attack

Comment
Rating
Impact
Comment
Risk
Rating
Safety of routes
Skilled Hacker
Attacker accesses
signalling network from
outside KR corporate
network (or inject
malware) and manipulates
vital protocol between
interlocking sites to
manipulate routes.
Existing mitigations:
Knowledge of vital
protocol required
Firewall(s) around KR
corporate network
Core switches logically
separate networks
Possible
Could cause injury /

Disastrous
loss of life
Would also lead to
significant downtime to
investigate
Intermediate
Safety of routes
KR corporate network
administrator infiltrates
signalling network and
manipulates vital protocol
between interlocking sites
to manipulate routes.
Knowledge of vital
protocol required
separate networks
Possible

Disastrous
loss of life
Would also lead to
investigate
Intermediate
Safety of routes
Attacker accesses
Skilled Hacker
signalling network from
outside KR corporate
network (or inject
malware) and manipulates
ATP telegrams
transmitted from LEUs
Knowledge of vital
protocol required
corporate network
separate networks
Two proprietary
protocols would need to
be hijacked
Driver would notice
discrepancy betwee incab and lineside
signalling
Possible

Disastrous
loss of life
Would also lead to
investigate
Intermediate
Administrator
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
Comments
30/06/14
Page 12 of 47
Customer Logo
Asset
Threat Explanation
Threat Source

Comment
Rating
Impact
Risk
Comment
Rating
Efficiency of
routes
Denial of service of JBoss

server which would stop
ARS
Hacker
(curious)
Skilled Hacker
Competitor
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
Efficiency of
routes
Attacker accesses R9K

and acts as operator.
Skilled Hacker
Competitor
corporate network
Passwords
Possible
Could reset all signals;

could cause
emergency braking by
ATP
Disruption of 1-4 hr
Critical
Intermediate
Efficiency of
routes
Attacker logs into

Skilled Hacker
Competitor
server(s) and
resets/reconfigures
network devices and/or
virtual machines, resetting
all signals.
corporate network
Passwords
Possible
Disruption of up to 12
hrs
May not have ready
access to pristine
configuration data
Disastrous
Intermediate
Denial of service against

network devices - could
cause devices to
shutdown and require
hard reset
corporate network
Passwords
Possible
hrs
Disastrous
Intermediate
Efficiency of
routes
Skilled Hacker
Competitor
Password management
on R9K side is not up to
same standard as KR
corporate network
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
Comments
30/06/14
Page 13 of 47
Customer Logo
Asset
Threat Explanation
Threat Source

Comment
Impact
Rating
Comment
Risk
Rating
Efficiency of
routes
Attacker logs into

Administrator
server(s) and
resets/reconfigures
network devices and/or
virtual machines, resetting
all signals.
Likely
hrs
May not have ready
access to pristine
configuration data
Disastrous
Major
Efficiency of
routes

and acts as operator.
Likely
hrs
May not have ready
access to pristine
configuration data
Disastrous
Major
Axle counter
reset
management
n/a
n/a
10
Track block
management
Administrator
n/a

and acts as operator,
lifting block.
Skilled Hacker
Competitor
corporate network
Passwords
Safe-working
procedures followed by
track workers, Hi-Rail
operators, train drivers,
etc.
Train Controller
situational awareness
Possible

Disastrous
loss of life
Would also lead to
investigate
Very unlikely to cause
multiple deaths
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
Comments
No specific
threats were
identified for this
asset - covered
by other assets
above.
Intermediate
30/06/14
Page 14 of 47
Customer Logo
Asset
Threat Explanation
Threat Source

Comment
Rating
Impact
Comment
Risk
Rating
11
Track block
management

and acts as operator,
lifting block.
Administrator
Safe-working
procedures followed by
track workers, Hi-Rail
operators, train drivers,
etc.
Train Controller
situational awareness
Possible

Disastrous
loss of life
Would also lead to
investigate
Very unlikely to cause
multiple deaths
12
Train location
information

and changes train IDs
and/or train location
information.
Skilled Hacker
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

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
n/a
n/a
n/a
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
Comments
Intermediate
No specific
threats were
identified for this
asset - covered
by other assets
above.
30/06/14
Page 15 of 47
Customer Logo
Asset
Threat Explanation
Threat Source

Comment
Rating
Impact
Comment
Risk
Comments
Rating
Reputation /
public confidence
n/a
n/a
n/a
No specific
threats were
identified for this
asset - covered
by other assets
above.
Level crossing
operation
n/a
n/a
n/a
No specific
threats were
identified for this
asset - covered
by other assets
above.
Obscurity of
design
n/a
n/a
n/a
No specific
threats were
identified for this
asset - covered
by other assets
above.
Operational
confidence
n/a
n/a
n/a
No specific
threats were
identified for this
asset - covered
by other assets
above.
Control of
operator
workload
n/a
n/a
n/a
No specific
threats were
identified for this
asset - covered
by other assets
above.
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 16 of 47
Customer Logo
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
5.2
Mitigations Considered
Mitigation
Effectiveness
(1 to 5)
Cost
(1 to 5)
Two firewalls with proxy device in between
Secure protocols between PIDS Interface and KiwiRail

Corporate Network
Unidirectional SOAP
Unidirectional, non-IP interconnect (e.g., serial)
PIDS Interface on separate Layer 2 network
PIDS Interface on separate Layer 2 network and External

Interface on separate server
Three firewalls with PIDS Interface in between two of them
Diverse firewalls
Unidirectional UDP
Intrusion detection
Separate administrative zones
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.
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 17 of 47
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., RS422) 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
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 18 of 47
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.
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 19 of 47
Customer Logo
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
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
The Rail 9000 Data Feed shall enable software executing within Mandatory
the Auckland Transport Network to detect and isolate loss of the
Rail 9000 Feed within two (2) minutes.
The PIDS interface software could potentially execute within the existing Rail 9000
virtualisation platform.
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 20 of 47
Customer Logo
Requirement
Priority
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
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
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
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
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
The Rail 9000 Data Feed shall provide sufficient throughput and Mandatory
latency to transmit events for eighty (80) trains within five (5)
seconds.
The Rail 9000 Data Feed shall support a Mean Time to Restore Mandatory
no greater than four (4) hours.
10
The Rail 9000 Data Feed shall have an Operational Availability

no less than 99.93%.
11
The Rail 9000 Data Feed shall enable software executing within Desirable
the Auckland Transport Network to detect if events are lost
between the PIDS Interface and the Auckland Transport
Network.
12
The Listener Server and Terminal Server #2 shall be installed at Desirable

a major KiwiRail site.
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
Mandatory
The following table traces the requirements documented in the Rail 9000 Project
Detailed Business Requirements [1] to the requirements in Table 5.
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 21 of 47
Customer Logo
Table 6
Business Requirements Traceability
Requirement from Rail 9000 Project Detailed Business

Requirements [1]
Trace to Table 5
Requirement Text
Requirement Text
1.1
KiwiRail Rail 9000 schedule information must be sent

from KiwiRail to Auckland Transport
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.
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

ESB system.
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

ESB system.
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).
KiwiRail
AZ6-, Version
SIG##TES&EDB000

Restricted
Remarks
30/06/14
Page 22 of 47
Customer Logo

Requirements [1]
Trace to Table 5
Requirement Text
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.

Requirement Text

ESB system.
KiwiRail
AZ6-, Version
SIG##TES&EDB000

Restricted
Remarks
30/06/14
Page 23 of 47
Customer Logo

Requirements [1]
Trace to Table 5
Requirement Text
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.
3.1
The Train Control environment is secure and cannot

1
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.
Requirement Text
The Rail 9000 Data Feed shall provide sufficient

throughput and latency to transmit events for eighty
(80) trains within five (5) seconds.
AZ6-, Version
SIG##TES&EDB000

Restricted
Requirement 8 from Table 5 is a stricter

requirement than requirement 2.3 from
Rail 9000 Project Detailed Business
Requirements [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.
KiwiRail
Remarks
30/06/14
Page 24 of 47
Customer Logo

Requirements [1]
Trace to Table 5
Requirement Text
Requirement Text
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
The Rail 9000 Data Feed shall connect the KiwiRail

Signalling Network to the KiwiRail Corporate Network
via physically unidirectional, non-IP-based serial
interface.
4.1
The Rail 9000 schedule information is extracted from

the Rail 9000 system using the Rail 9000 API
4.2
The KiwiRail existing infrastructure is re-used where

possible to interface with Auckland transport
- KiwiRail ESB (Enterprise Service Bus)
4.3

- KiwiRail Mule web services

not precluded by the proposed solution.
4.4

- KiwiRail to Auckland Transport, private circuit

not precluded by the proposed solution.

software on the Siemens side).
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
AZ6-, Version
SIG##TES&EDB000

Restricted
Remarks
30/06/14
Page 25 of 47
Customer Logo

Requirements [1]
Trace to Table 5
Requirement Text
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 Text
Requirement 15 in Table 5 contradicts
this statement.
KiwiRail
AZ6-, Version
SIG##TES&EDB000

Restricted
Remarks
30/06/14
Page 26 of 47
Customer Logo
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
Check if KiwiRails administration of the Rail 9000 system KiwiRail

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

is adhering to the KiwiRail Security Policy and implement
corrective action if not.
Determine if duplication of the Rail 9000 Data Feed is

necessary and, if so, when such functionality should be
implemented.
Auckland Transport
Review throughput and latency requirements for the Rail

9000 Data Feed and confirm or correct them.
Auckland Transport
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 27 of 47
Customer Logo
List of Figures
Figure 1
Figure 2
Initial Conceptual Architecture for Risk Assessment .........................................9

Proposed Design..............................................................................................18
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 28 of 47
Customer Logo
List of Tables
Table 1
Table 2
Table 3
Table 4
Table 5
Table 6
Table 7
Abbreviations .....................................................................................................5
Assets Considered in Risk Assessment ..........................................................10
Initial Risk Assessment ....................................................................................12
Mitigations Considered ....................................................................................17
Business Requirements ...................................................................................20
Business Requirements Traceability................................................................22
Actions .............................................................................................................27
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 29 of 47
Customer Logo
Appendix A Workshop Presentation Slides
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 30 of 47
Customer Logo
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
Restricted Siemens AG 2014 All rights reserved.

Page 3
24-25 June 2014
TRA - PIDS
Griffiths, Cook / CT RTC ITS
TRA - PIDS
PIDS Architecture

Page 4
24-25 June 2014
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 31 of 47
Customer Logo
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 32 of 47
Customer Logo
PIDS Assets
The main thing we want to protect is

operation of the signalling system
Page 7
24-25 June 2014
TRA - PIDS
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

Page 8
24-25 June 2014
TRA - PIDS
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 33 of 47
Customer Logo
Attackers
Attacker
Capabilities
Adversary Goals
Level of Access
Basic knowledge. Requires

automatical tools
no targeted attack
just "looking around"
Skilled Hacker
High knowledge. Can create his own

tools
wanting to prove information insecurity

Internet
wanting to have publicity
unprotected physical interfaces
getting paid by someone
Administrator
High 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
Little technical knowledge but internal

knowledge
wanting more access than he is

authorized to
just playing around
low privileged access to the

system
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)

knowledge
wanting to enhance or unlock

functionality for free

system
KiwiRail / Siemens Insider

knowledge
revenge
hired by someone else

system
Hacker (curious)
User
Competitor
Internet
unprotected physical interfaces

Page 10
24-25 June 2014
TRA - PIDS
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 34 of 47
Customer Logo
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

Page 11
24-25 June 2014
TRA - PIDS

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

Page 12
24-25 June 2014
TRA - PIDS
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 35 of 47
Customer Logo
Likelihood of Successful Attack

Rating (Text)
Very likely
Likely
Possible
Attackers
Vulnerability, Exploitability
Unintentional attack by regular users
No security measures, e.g.

Unpatched OS
No malware protection
Known network protocols without security measures
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
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 the
system
Network protocol without integrity protection, but
protocol is complex
Good security measures, or
Attack is very complex, e.g.
Network protocol without integrity protection, but
protocol is very complex, e.g. series of protocol steps
Improbable

Page 13
24-25 June 2014
TRA - PIDS

Step 1:
Step 2:
Step 3:
Step 4:
System Inventory and Asset Identification

Attacker and Threat Identification
Threat Evaluation
Impact Identification and Evaluation
What could happen?
Threat analysis
System
inventory
and Asset
identification
Attacker
and
Threat
Identification
Threat
Evaluation
Impact
Identification
and
Evaluation

Page 14
24-25 June 2014
TRA - PIDS
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 36 of 47
Customer Logo
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

Page 15
24-25 June 2014
TRA - PIDS
High Level Impact (Amount of Damage)
Impact
Rating (Text)
Disastrous
Critical
I MO RA specific rating aspects

Injury to persons
Severe adverse effects to safety
KF-Bedienung (Command Release)
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

Page 16
24-25 June 2014
TRA - PIDS
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 37 of 47
Customer Logo
Impact (Amount of Damage)

Impact areas
Rating
Rating (Text)
Costs
Impact Rating
Cost in Euros for

single occurrence
Remark: This column
is only used for
alignment of the
impacts. Impact
estimation is NOT
done using this
column
Disruption of
customer
service
Duration
Unavailability of
systems or
components
Duration
Physical damage
Costs to restore
functionality
including loss of
income
May be direct
description of
damage is
easier to map to
a threat
Train damaged
Safety impact
possible yes/no
Disastrous
> NZ $7.5 million
> 12h
Critical
> NZ $1.5 million
> 1/2 h
> 12 h
No
Moderate
> NZ $150,000
<= 1/2 h
<= 12h
No
Negligible
<= NZ $150,000
Minor component
damaged
Loss of
Reputation
Legal
Impacts
Public
attention
Potential
for future
business
loss
Violation
of laws
Violation
of
standards
Bad world
wide
press
Personal
liability,
jail, or
fines > NZ
$7.5
million
Hazard
Yes
Fines >
NZ $1.5
million
known by
insiders
Fines >
NZ
$150,000
Fines <=
NZ
$150,000
no

Page 17
24-25 June 2014
TRA - PIDS

Step 1:
Step 2:
Step 3:
Step 4:
Step 5:
System Inventory and Asset Identification

Attacker and Threat Identification
Threat Evaluation
Impact Identification and Evaluation
Calculation of the resulting Risk
Threat analysis
System
inventory
and Asset
identification
Attacker
and
Threat
Identification
Risk analysis
Threat
Evaluation
Impact
Identification
and
Evaluation
Risk
Calculation
Risk Mitigation
Page 18
24-25 June 2014
TRA - PIDS
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 38 of 47
Customer Logo
Risk Rating
Within the workshop, we use a predefined risk management metric to calculate the
risk:
Risk
Risk Rating (Text)
Critical
Major
Intermediate
Minor
Description
Controls for critical risks are required with highest priority.
Controls for major risks must be implemented.
Controls for risks should be discussed and a decision for or against

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

Page 19
24-25 June 2014
TRA - PIDS
Risk Matrix
The threat & risk analysis results are displayed in the following risk matrix:
Risk Mapping
Impact
Overall Likelihood
Improbable
Possible
Likely
Very likely
Negligible
Minor
Minor
Minor
Minor
Moderate
Minor
Minor
Intermediate
Intermediate
Critical
Minor
Intermediate
Major
Major
Disastrous
Minor
Intermediate
Major
Critical

Page 20
24-25 June 2014
TRA - PIDS
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 39 of 47
Customer Logo
Threat and Risk Assessment

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

Page 22
24-25 June 2014
TRA - PIDS
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 40 of 47
Customer Logo
Appendix B Workshop Attendance Register

Day 1
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 41 of 47
Customer Logo
Day 2
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 42 of 47
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.
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 43 of 47
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 <ref to place in the report where the
assessment lives>.
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.
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 44 of 47
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
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 45 of 47
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.
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.
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 46 of 47
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.
KiwiRail
AZ6-, Version
SIG##TES&EDB000
Restricted
30/06/14
Page 47 of 47

NZ PIDS Threat and Risk Assessment Workshop Report

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

NZ PIDS Threat and Risk Assessment Workshop Report

Uploaded by

Copyright:

Available Formats

Customer Logo

PIDS Threat and Risk Assessment

Phil Cook (RGB Assurance)

KiwiRail Project Manager:

Copyright Siemens AG 2013 All Rights Reserved

Document Information & Version History

SOURCE / DOCUMENT NUMBER

Rail 9000 Project Detailed Business

Copyright Siemens AG 2013 All Rights Reserved

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

Copyright Siemens AG 2013 All Rights Reserved

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

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

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

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

Copyright Siemens AG 2013 All Rights Reserved

Scope and Purpose of this Document

Abbreviations & Definitions

Automatic Route Setting

Enterprise Service Bus

Information and Communications Technology

Passenger Information Display System

REpresentational State Transfer

Copyright Siemens AG 2013 All Rights Reserved

to enhance the train movement information provided to their Passenger

Copyright Siemens AG 2013 All Rights Reserved

Copyright Siemens AG 2013 All Rights Reserved

Copyright Siemens AG 2013 All Rights Reserved

Initial Risk Assessment

Initial Conceptual Architecture for Risk Assessment

Copyright Siemens AG 2013 All Rights Reserved

Assets Considered in Risk Assessment

Provides train separation.

Keeps rail services running on time.

Axle counter reset

Track block management

Protects track workers.

Train location information

Provides situational awareness to Train Controllers

Fundamental to ARS operation; supports

Abstract asset that may be affected by safety

Level crossing operation

Protects general public at road-rail interfaces.

Relied on for some aspects of the security of the

Related to system users' confidence.

The additional six assets identified by workshop participants were considered in

Copyright Siemens AG 2013 All Rights Reserved

Threats and Risk Ratings

Copyright Siemens AG 2013 All Rights Reserved

Initial Risk Assessment

Likelihood of a Successful Attack

Could cause injury /

Could cause injury /

Could cause injury /

Rail Technology System

PIDS Threat and Risk Assessment

<Project document No RT>

Copyright Siemens AG 2013 All Rights Reserved

Likelihood of a Successful Attack

Denial of service of JBoss

Attacker accesses R9K

Could reset all signals;

Attacker logs into

Denial of service against