This website uses cookies, including third party ones, to allow for analysis of how people use our website in order to improve your experience and our services. By continuing to use our website, you agree to the use of such cookies. Click here for more information on our and .
From station, to track-side, to train, the IoT (internet of things) revolution is fast gaining momentum within rail.
Applications such as smart ticketing, predictive maintenance, and real-time visibility are enabling a host of benefits, including improved passenger mobility, increased ridership and reduced operational expenditure.
However, with all the excitement that connected infrastructure brings to the industry, comes equal measures of concern. The reliance on open networks, leaves physical – as well as virtual – assets exposed to cyber invasion, if they are not implemented and maintained securely.
With human lives and significant dollar values worth of damage at stake, KiwiRail is enhancing its cyber security efforts and engineering a secure centralized platform to host its existing real-time systems.
“Rather than having separate, discreet systems that lurk in railway sheds, we are working towards a formalised IT environment to host everything. An environment in which security is ‘baked-in’, not just ‘bolted-on’”, says Chris Draper, Signalling & Telecommunications Engineer at KiwiRail.
In pioneering this project, KiwiRail has taken a novel approach, augmenting its Engineering team with several IT specialists and educating them about rail, as opposed to upskilling its existing rail experts on specialist IT subjects – an approach which Chris admits has caused both laughter and tears along the way.
Ahead of the RISSB Rail Cyber Security Conference, Chris shares with us some of the key challenges he and his team have encountered throughout the project.
Safety versus security
Chris makes a distinction between physical safety and network security and highlights instances in which a tradeoff exists between the two.
“Not all machines can be fitted with anti-virus (AV) software, for example”, says Chris. “If the AV perceives a threat then it could alter the way the system operates. When it comes to train control systems, we cannot afford to take that risk. We have had to find alternative ways of preventing viruses on the system that do not allow automated modifications to a safety critical system”.
“Another example is a PC lock-screen. This is a common security requirement for computers, requiring the user to log back in if they have stepped away from their desk for x amount of time. However, train control systems can’t be protected in such a way. Train controllers need the flexibility to be able to access their systems at any time in case of giving an urgent signal. Having to fumble around with a login screen because you’ve been inactive on the system for five minutes would pose too much of a safety risk”.
Chris adds, “We have had to be creative in terms of how we balance this tradeoff, by enhacing the physical security at train control so that only authorised personnel are permitted near the safety critical machines”.
IT versus Engineering: A clash of the cultures
Chris tells us that while IT and Engineering teams may appear similar on the surface, the project has exposed some key differences in terms of how each department operates.
“Rail is regulated by specific acts of Parliament. The burden of liability is much higher with safety systems than other system types an IT vendor may deal with”, says Chris. “We’ve had a couple of IT vendors decline to be involved when they realise this”.
“Many aren’t used to the pedantic nature of engineering design documents. Obviously our documents need to be this way in case they are called as evidence, sometimes decades after installation. It’s been a challenge getting IT folk to deal with aspects of the detail not normally required for business systems”.
Another notable difference is the use of terminology between the two teams.
“The project has unveiled some real challenges in terms of industry-specific language. In an IT context, the word ‘incident’ tends to mean a ‘logged possible fault’, for example. In rail, it usually means someone has been hurt or could have been hurt and we need to launch an internal inquiry. We’ve had to make sure that everyone is singing from the same hymnbook. This is especially important when it comes to creating design documentation. We’ve had to choose words which aren’t overloaded in meaning. Also, to make sure we are not using the same word interchangeably”.
Proving a negative
When it comes to testing and commissioning, Chris highlights the inherent difficulties of proving a negative, as opposed to a positive.
“If you give a competent rail tester a circuit diagram of say a level crossing, he or she can trace every wire and mark it all off a plan. That would be proof positive that the circuit as built matches the design exactly”, says Chris.
“For cyber security – you set up your security defenses to best practice, and have to prove that someone cannot break through the sophisticated detection systems undetected – i.e. you are testing a negative. This is a new dimension our IT colleagues are contributing to our engineering practices”.
Audits, audits and more audits
Chris admits that KiwiRail’s decision to undertake such an innovative project has meant the firm is having to undergo more than its usual number of external audits.
“We’re welcoming scrutiny a lot more than normal”, says Chris. “This is a necessary part of the journey to ensure any novel aspects of the design are sound and based on best practice.”
“However, when operating in new terrain like this, ensuring we have covered all of our bases prior to auditing becomes more of a challenge”.
Chris Draper will discuss how KiwiRail has dealt with these challenges at the RISSB Rail Cyber Security Conference – taking place 11-12 September in Brisbane.
