Railway security: OT security for rail operators and suppliers
We test signalling and control technology, the ETCS environment and vehicles within the timetable window, build the detection for it, and rehearse the real thing on our own train model. For infrastructure managers, railway undertakings and suppliers.
Interlocking technology with lifecycles measured in decades, ETCS components and modern diagnostic platforms all work in the same system. For security testing that means availability and safety come first, and testing happens inside the timetable window.
Four incidents, and none of them hit the signalling
In August 2023 around twenty trains came to a stop in Poland because someone sent the radio-stop signal over the analogue train radio. Three tones on a known frequency are enough. There is no authentication, because the method comes from a time when the transmitting equipment itself was the barrier to entry.
In 2022, display boards at Taiwanese stations were filled with foreign content; a year earlier an attack on the Iranian railway disrupted passenger information and operations. At the end of 2023 it became public that the control software of one vehicle class contained logic that disabled vehicles after maintenance in a third-party workshop.
The lesson is not that interlockings are insecure. None of these incidents touched the type-approved signalling. What was hit was the radio, the passenger information and the supply chain, which is to say exactly the areas that play no part in the approval process and in which digitalisation is moving fastest.
What has been added in recent years
The signalling is tightly regulated. Everything beside it is not, and that is where the networking has grown.
IP in the control technology
Electronic interlockings are being replaced by digital ones, and communication increasingly runs over IP rather than point-to-point links. RaSTA secures the transmission, but it does not replace network segmentation.
Remote maintenance and the workshop
Manufacturers need access for diagnostics and updates, and maintenance works with mobile devices. Today the shortest way into a vehicle runs through the workshop, not along the track.
Radio between vehicle and track
ETCS brings a permanent radio link while the analogue train radio keeps running alongside it. Two generations of transmission technology side by side, with very different security properties.
What we have done in the rail sector
We tested an interlocking landscape over six months without intervening in live traffic. The result was a risk assessment with a zone and conduit model, not a list of scanner findings. There is an example of it further down this page.
We have also built several security operations centres for rail. They have been running since 2019, with use case development as a team of its own and with data sources from IT and OT in the same analysis.
The protocol knowledge that requires does not come from standards documents alone. We have carried out network analysis and data recording on real trains, among them a research train of DB Systemtechnik and an ICE TD of class 605.
How testing works in a rail environment
A vulnerability scan that passes unnoticed in an office network can cause a fault in a signalling environment. Availability and safety come before confidentiality, and approval states must not be touched.
Tests therefore run passively, or in clearly delimited network areas that have been released for the purpose. Test windows follow the timetable, not the project plan, and abort criteria are agreed beforehand. Where a finding could only be obtained by intervening, we reproduce it on our own rig.
What gets tested: the signalling and control technology with its SCI interfaces and RaSTA transmission, the ETCS environment with radio block centre, balises and radio link, the operations control centre with dispatching and fault management, and on the vehicle side the buses including the diagnostic access.
Intrusion detection on the vehicle bus
The Multifunction Vehicle Bus is standardised in IEC 61375, but manufacturers implement it differently. Monitoring that understands only one variant is worthless in a mixed fleet. So we built vendor-neutral detection for it: recordings from systems of different origin and a virtual environment of our own run through thin adapters into a common, standard-conformant data model.
Detection is hybrid, rule-based for known patterns and learning-based for statistical deviation. The bus has no sender check; whoever may transmit on it can pose as any component. That is exactly what we reproduced on our own rig: a compromised display unit that forges safety telegrams and with them triggers an unplanned emergency brake and a false fire alarm.
Trialled under real operating conditions on a research train. That is where the constraints a train brings show up: limited mobile coverage, which is why the sensors pre-filter, and dropped connections, which is why data is buffered on board.
Training on the train model
You cannot practise on a train in service. So we keep a model carrying the systems that make up a real vehicle: traction control, climate control, door control and displays, connected over the buses actually used in rail vehicles.
Technical teams work on it at protocol analysis, anomaly detection and writing their own detection rules. For managers and maintenance it is about understanding, and about the judgement that has to be made under time pressure on the day: restrict operations or keep running, contain or observe, and when to report.
An attack taxonomy that covers rail
Assessing threats in a structured way needs a shared vocabulary. In classic IT, MITRE ATT&CK provides it. For vehicles and rail it falls short: it knows no field buses, no balises and no train radio, and it does not represent the fact that an attack here has immediate physical consequences.
So in a funded joint project we developed a taxonomy of our own and presented it at an ACM symposium in 2023. It sorts adversary behaviour into fourteen tactic classes, from manipulating the environment through initial access to impact, and describes the concrete techniques beneath them. Attacks over radio are a technique of their own in it, because they do not fit sensibly into any IT category.
In practice it serves in three places: as the grid against which an assessment checks its own completeness, as a source for detection rules, and as a common language when a finding has to be placed between operator, manufacturer and tester.
Several rule books at once, asking different questions
In rail, several rule books meet. The CENELEC standards EN 50126, 50128 and 50129 govern reliability, software and safety in signalling and control technology. TS 50701 brings cybersecurity into that world. Beside them stand IEC 62443, the reporting duties under the BSIG, the German act on the federal information security office, and the requirements from NIS2.
The practical conflict rarely lies in the text of the standards but in their simultaneity. Evidence under TS 50701 does not automatically answer the reporting duties under the BSIG, and a NIS2 registration says nothing about whether an interlocking landscape is technically segmented.
At the start we set out which requirement is covered by which piece of evidence, and which remains open.
What a way in actually looks like
The usual start is a delimited architecture and segmentation review, not a large programme.
First conversation, about an hour
The architecture, the approval states, the regulatory position and the question of which test windows are available at all.
What you provide
Network plans and plant documentation, contacts from signalling and from IT, and the opportunity to capture passively at a released transition point.
Delimited test
Architecture, segmentation and real communication paths on a defined section, passive during operation, active only inside the released window.
Result and priorities
A zone and conduit model, documented findings with technical context, and an order of work that separates immediate, next maintenance window, and accepted residual risk.
What operators and suppliers ask us beforehand
Yes, passively. Architecture review, configuration review and analysis of communication relationships all run without intervening. Active tests belong in a released window, a delimited network area, or on a lab rig.
No. We change no approved configuration. Where a test would only be possible by intervening, we reproduce it on our own rig.
One of the best. Before a digitalisation project is accepted, or while new remote maintenance paths are being connected, the zone concept can still be shaped rather than corrected afterwards.
Yes. Vehicle-side communication is a focus of its own, including detection on the vehicle bus. We have built a train model for exactly that.
The question of reach comes first: what was actually reachable from there. We work out the real communication paths and delimit which areas could have been affected and which could not.
