Ahead of our upcoming rolling stock cyber security webinar with Cyber Senate on the 28th August, we would like to explore some of the attack vectors that are affecting rolling stock today, and how you may not have considered them.
One key element that many operators do not consider with rolling stock is the number of systems that are onboard a modern digital train. There are the obvious systems like the mobile communications gateway, driver HMI and CCTV NVR/DVR. With up to a hundred systems onboard a train, it represents a target rich environment for a determined attacker.
When we look at a data centre, most companies have tens of servers. In data rich, or large service companies, this can increase to hundreds, thousands or tens of thousands, but typically this is servicing large populations of concurrent users. For a train operator, they are managing ticketing, marketing, information flow and support for their customers.
It is no wonder that train operating companies struggle to scale up from tens of servers to dealing with thousands of digital systems. Why thousands? Well a train fleet is potentially a hundred train units with a hundred systems, so there are potentially ten thousand systems that need protecting! The train operators typically don’t have a cyber security programme that is taking into consideration that size of challenge.
Potential attack vectors
The more ‘digital’ and connected the systems within rail networks become, the more vulnerable the critical systems are to cyber threats. Typically, the onboard network is viewed as a closed network, however this is usually not the case when analysing potential attack vectors.
Physical
Starting with the hardest to protect against; physical attacks are relatively easy in a rail environment. Cabinets are secured with simple t-keys that are available commonly on eBay or substituted with a flat head screwdriver. In trackside environments a similar challenge exists, with better keys used but likely still pick-able with off-the-shelf tools. This major risk is physical access to maintenance ports on the network, this could allow an attacker to leave behind a remote access tool device or other device to bridge the network with the internet. The challenge in rail is that these could be left undetected for long periods of time.
Insider
Most cyber risk frameworks only focus on malicious attackers, meaning it isn’t deemed an attack unless it is malicious. However, in our view, protection and detection should also be considered for unintentional vulnerabilities left by maintenance staff. We have seen many cases where this has happened, from testing code being left behind, to configuration changes to debug an issue not being reverted. There are also cases where maintenance devices/laptops could be left connected to a network, which are also vectors for potential malware. Without proper consideration in your risk management process, these vulnerabilities would be undocumented and undetected.
Mobile Communication Gateways
The next vector to consider is more obvious, the mobile communications gateway (MCG) that bridges your train with the internet. Passenger-facing MCGs have been the focus of a lot of security work and have generally very good protection in place. Where work is needed is on the detection of cyber-attacks on these devices, they run a plethora of services and software that may be relied on for the function of the train.
The good news is that many risks have been addressed, MCGs will almost always encrypt traffic between the train and the wayside. They will include a firewall and will have been through OS hardening after a penetration test. We would always recommend a penetration test because every use case is unique.
In this instance we will consider a generalised case for onboard MCGs because in many cases, a separate TCMS/Operational MCG is included. We have worked across MCGs produced by train builders, system integrators and system suppliers. In each case they use a similar architecture.
The MCG sits in a privileged position in the network, controlling traffic flow and key services like DNS. Access to these devices could allow for traffic to be re-routed transparently if an attacker gains a foothold on the operating system.
It is important to realise that an MCG also acts as a key point of aggregation within a network, and includes at least two network interfaces, a LAN (local) network connection and a WAN (internet-facing) network connection. A misconfigured WAN interface can allow for internet traffic to be bridged into the onboard local network.
Generally, the vectors to consider are:
Passenger connectivity to the MCG LAN
Passenger connectivity via the MCG to the Operational LAN (if misconfigured)
External connectivity to the MCG WAN
Services and software on the MCG including the core OS and virtualised services
The wayside gateway
A key question to consider is whether your onboard network is really closed if it features an MCG. The answer is more complicated than the security design may have considered.
A note about homologation and vulnerabilities:
Operational MCGs are subject to homologation so any vulnerabilities that existed when they are commissioned will remain over the life of the asset. This makes detection on these devices even more crucial because these vulnerabilities will not be addressed.
Wayside Gateways
The wayside gateway is used for two functions; it is both the route for traffic out from the MCG to the internet and also the route in for remote maintenance activities. Typically, a wayside gateway exists in a cloud environment and may have access to multiple trains across a fleet.
Wayside gateways can be patched and are easier to manage than most onboard systems. Good cyber hygiene is vital as these systems can bridge a significant number of train units.
Onboard devices including switches, wireless access points, passenger information screens etc. Other onboard devices should be considered on a case-by-case basis including appropriate zoning, monitoring and update procedures. It is important to recognise that network equipment sits in a privileged position because it can control the traffic routing and is highly vulnerable to misconfiguration or reconfiguration.
Most onboard systems have been designed to exist in a closed network. Whilst this article focuses on a simplistic view of onboard train networks, designers of onboard systems typically have to consider thousands of requirements and standards when developing systems. If they can reduce complexity by defining a device as only ever existing in a closed network, they will take that option.
These design considerations have real implications, encryption is generally not included because of latency risks, authentication may be compromised in favour of ease of maintenance etc.
Anything connected to the IP network onboard should be looked at with a critical eye when reviewing cyber risk and potential attack vectors. Security should be considered over the likely long lifespan of the system, and not just considered at a single point in time.
We recently partnered with Icomera to provide protection of onboard connectivity systems, including passenger WiFi.
A special note about video surveillance cameras
There are many different manufacturers of IP-enabled cameras. We previously wrote an article about the cyber security risks with these cameras used within rail, which covers some of the key risks that we have seen in these systems.
Commercial Off-The-Shelf (COTS) Software
Many systems onboard use COTS software (including open source), generally we consider this to be good practice because it avoids re-inventing the wheel and helps prevent attempts at security through obscurity (an approach that is doomed to fail).
It also means that vulnerabilities are more likely to be found and addressed. The important question is how those vulnerabilities are managed over time.
COTS software will be found in every device that runs a Linux operating system including network devices, CCTV cameras, MCGs and most other key onboard systems.
Addressing these attack vectors
Rolling stock networks may not be unique in their vulnerability to cyber attacks, but their infrastructure and sub-systems do stand apart when creating solutions for safety and security. The upcoming CENELEC TS-50701 standard puts the case forward that rail networks are more complex than conventional networks, and therefore require a cyber security programme that considers, and covers, the distinctive challenges seen within rolling stock.
In most cases, protection measures that are possible have already been put in place. The challenge in the railway industry is that these protection measures must remain effective for a long period of time, what happens in reality is that over time these measures are more likely to fail.
We would always recommend a strategy that includes detection and a layered approach to securing the onboard systems. Secure today is not secure tomorrow, and a modern train is a complex beast with a significant number of devices and software components.
RazorSecure works with train builders, system integrators, system suppliers, train owners and train operators to help them design and implement appropriate, cost-effective measures to protect their rolling stock and infrastructure systems over the life of the asset. Get in touch for more information.
