Recently I was invited to deliver a talk at the Young Rail Professionals Forum at SNC Lavalin in Derby. I took this as a great opportunity to research the industry and fathom where the weaknesses exist, and what the worst-case rail scenarios for a cyber breach could be. Most of my career has been spent as a cybersecurity senior lecturer, so I approached the topic with the same research rigour as I would pursuing academic journal publications. During this process, I was fortunate to get an audience (2 coffees and a couple of hours) with a leading practitioner involved in the management of rail signalling system projects (he wishes to remain anonymous). I learnt that many of the current systems in the UK for controlling rail traffic is analogue and uses fixed block signalling to detect a train is on a specific “block” of the track, this can be performed in a couple of ways, either using track circuits or axle counting. This information is then fed back to a signal controller who, with the assistance of various software tools, can respond and manage the trains. However, over the next 25 years (things move very slowly it seems in rail), the plan is to introduce the European Rail Traffic Management System (ERTMS), which amongst other items includes a new signal, control and train protection system, namely, the European Train Control System (ETCS). This system incorporates a new radio system called GSM-r; which is essentially the same as vanilla GSM that all our mobile phones used in the previous decade, except it is used for the rail industry (hence the -r).
In a nutshell, the track circuits detect the train’s position, which is reported to the train via the balise. The train then shares its positional data via the onboard computer ETCS over GSM-r to the Radio Block Centre (RBC). In response, the RBC issues signal status data informing the driver if the path ahead is clear or otherwise.
Unsurprisingly, my initial line of disaster enquiry focused around the GSM-r signalling between the RBC and the onboard ECTS and the radio communication via the balise and balise receiver. Even though this was only my “first pass” at possible technology flaws it was relatively easy to present a scenario that could cause large delays for customers and general stress inducing stoppages. A cheap GSM-r signal disruptor (I found one for £13.83 on e-bay) positioned correctly would prevent communication between onboard ECTS and the Radio Block Centre. In this scenario, I was informed, an expected communication between train and radio block centre would not be received, and default instruction would be to stop the train, and no other trains would be sanctioned to use the “block” of track the train was on. Of course, this would cause serious delays until the cause of the fault had been established, which in this scenario could prove extremely difficult.
While this would be an extremely expensive and time-consuming attack, seriously disrupting the rail network, it is not devastating in the way 2 trains colliding would be. The following is a couple of worrying hypotheses of how that could be achieved: –
The documentation for the GSM-r standard is open and available online, I found it with a Google search in under a minute. Worryingly the words “encryption” and “authentication” do not exist once in the 112-page GSM-r standard document. Using the freely available information in the standard, and easily accessible GSM-r transmitters, it would be possible to mimic the communication between the RBC and the trains on-board ECTS. Thus, it should be possible to not only block a signal but also to perform a man-in-the-middle (MITM) attack. This would involve intercepting the signal and sitting between the RBC and on-board ECTS impersonating both to each other. In this scenario, the train could be falsely instructed to stop by a malefactor impersonating the RBC, and then falsely inform the RBC that the train had continued en route by impersonating the on-board ECTS. Any train following would be entirely unaware of the stationary train ahead. There is a little more to it than that as GPS, and onward GSM-r need to be addressed, but that is the essence of it.
As an alternate, less technical route, consider the following: –
Let’s reflect upon the Alton Towers Smiler disaster, bear with me, I am going somewhere with this. At around 1 pm the ride reported a fault, possibly due to it being operated while the wind speed was too high. The ride was stopped everyone was removed from the ride and the engineers were called. As the ride had been so busy, the astute operators took the opportunity to add another carriage while the ride was closed. They tested it by trying to send a carriage around, but it never made it and stalled on the track. The engineers arrived and fixed the ride, retrieving the stalled carriage. However, crucially, they were not told a 5th carriage had been added. The ride was restarted, and another carriage is sent around, this one also stalls part way round, the engineers never noticed, and handed control back to the staff. Staff open the ride, riders board the carriage and off it goes. However, it stops at the top of the first drop with a warning to staff that the track ahead was occupied. The engineers were asked to advise, they noted 4 carriages on the track and assuming they were all accounted for, they advised the carriage to be released, resulting in the horrific collision with the stalled carriage. So, we know how it happened, but why? Put simply, staff bonuses were affected by ride downtime and targets had been set to keep the ride operational. It’s well documented that stress affects decision making, making us less risk-averse and causing a tendency to look at the positive outcome of a decision and ignoring the negative. History is littered with examples of poor decisions made under target induced stress, for example, the decision to launch the Challenger space shuttle on Jan 28th 1986 despite the temperature being unusually low and at a, in the words of accident investigator Richard Feynman, “shouldn’t be run” level for fuel O-rings.
So, to put this in the context of rail. From a malefactor’s viewpoint, we know error conditions can be generated via GSM-r manipulation. This combined with the stress and pressures on rail operators created through targets and fines provides a perfect storm for poor decisions. Ponder this: –
A stealthy hidden GSM-r disrupter, as previously ascertained, very cheap and freely available, is used on a section of rail to disrupt the signal of a passing train to the RBC, disrupting GSM-r communication at the timetabled arrival of a train at that block of track. This would cause a fault condition and the train would stop. The GSM-r disruptor is instructed to stop blocking the signal after a random period between 5 and 15 minutes. The train would resume with significant delays. Let’s say this repeated at random train times. Maybe 4 days later, then 3 months later, then a week after that and so on; and let’s also say it occurs at random times of the day and night for various timetabled trains. It would very much appear to be a random fault, hard to pin down and impossible to find or predict. Isn’t it likely that at some point, under increasing pressure and with the section of track in question visually confirmed to be free, that the train is permitted through, and the error ignored? Were this to happen, the malicious party would not change behaviour, they want to build the gambler’s fallacy, “there was no problem last time I ignored the warning, so this time will be fine too”. Except on one fateful day, a train is stopped on that block of track. This could be achieved via a stop signal being sent to the train via malicious GSM-r communication. Easier would be someone pulling the stop cord and while this usually now involves the driver responding via intercom to the individual pulling the cord, statistically they tend to do so, assuming a plausible reason is offered. Of course, the perpetrator would need to accept their fate. Alternatively, a trolley or other large object could be placed on the tracks to cause the train to stop. The following train would not stop under error condition, because both the controller and driver have been conditioned to ignore it.
The problem is not solely with the technology, but our financial dependency upon it, and functionality taking precedence over security
N.B. Please take that as an open invite to Siemens or other relevant parties to please share with us in the interest making of making rail safer, through fixing the communication protocols and standards being adopted for the digital railway project.
Samurai Digital Security is an elite team of cyber security specialists, uniquely qualified to manage all aspects of cyber security within the rail sector. For information on how Samurai can help your business avoid cyberattack, please visit our web site www.samuriasecurity.co.uk or email us at [email protected].