Video Surveillance cameras are often discussed when we review cyber risks present on rolling-stock networks with Train Operators. A typical train may have up to 8 cameras per car, so total numbers in the 1000s for a large fleet is not uncommon, potentially making them the most widespread network device on-board.
Video surveillance has been widely deployed to help keep both passengers and staff safe but now attackers have turned the tables on those who operate the cameras. Cameras connected to on-board operational networks expand the cyber attack surface. Connected systems are only as secure as their weakest link, and attacking these cameras may just be a step behind a larger-scale attack on the train.
Cameras are interesting to attackers because they are generally trusted, are connected deep inside the operational networks on-board, and may be assumed to be limited in both their function and their communication patterns. A common misconception is that a camera is only communicating with a Network Video Recorder but is this really the case? When we have analysed this in practice on real trains in service, we have found some surprising results.
When considering cyber risk, it is important to understand what a network connected camera actually contains. It is not just a lens, storage and a network connection; it is a fully functioning server complete with a Linux operating system.
So what? Well even a basic Linux install can contain hundreds of software components and libraries that rely on internet services to operate. A camera functions like a server and this creates a lot of exploitable opportunities for a skilled attacker.
New cyber security threats within the railway industry are raised frequently, but whether they pose a critical risk to assets can depend on two factors.
1. What is the prospect that a vulnerability can be easily exploited?
2. What is the impact that its exploitation could have on the rest of the system?
In the past, CCTV camera systems were closed and used analogue technology. This started to change in 2010 with the adoption of the new digital technology bringing a new wave of IP-connected cameras to the market. As these IP-enabled devices gained in popularity, unfortunately cyber security was frequently an afterthought. System owners wrongly relied solely on perimeter wall defences to secure their devices, including cameras, within their networks.
This threat landscape was exposed in 2016, when we saw increased reporting of high-profile cyber security incidents, such as the Mirai botnet, in which thousands of IP-enabled cameras and NVRs were infected. Poor system design and implementation were the root causes of the Mirai botnet. The Mirai botnet was built from elements, which included IP-enabled cameras and NVRs that were exposed to the internet unintentionally. It was able to create terabits of traffic per second and shut down some well-known internet services and websites worldwide..
While a DOS attack against train systems is a risk, the broader issue is that these devices were compromised allowing an attacker to have a widespread foothold in the network. This is a significant step along the cyber kill chain - an attacker is potentially then able to move laterally, accessing other subnets and attacking other systems.
Cameras are often white labelled and re-badged from leading manufacturers. They trust the suppliers that they receive the cameras from, but they are built to a strict cost: the software may not be a leading concern for those suppliers; security update processes over the lifetime of the camera may not have been fully considered or costed in.
The firmware on these units may contain software that is years out of date when it is shipped, with no update plan or mechanism in place. Even if the firmware is fully patched, misconfiguration may leave you exposed, which is especially a risk when dealing with a large number of cameras without a central management tool – it just takes one misconfigured camera to compromise the entire network.
If you fall into this situation, you can be left with cameras that cannot be adequately supported from a cyber security perspective and exposed vulnerabilities that are difficult to manage over the life of the asset.
Cameras should only be talking to a restricted set of systems required for them to function correctly. We have analysed network traffic on-board in-service trains and seen cameras that talk to tens of different cloud services in high-risk countries. These can be for relatively innocuous services like NTP but who can say they are not command and control nodes for those devices?
These kinds of services should be configurable within the camera to ensure consistency across the fleet and that there are no outside services that can influence the secure operation of your cameras. If nothing else, if those services are no longer available then will the cameras continue to function?
We recommend implementing a cyber security framework and, at a minimum, perform regular penetration testing to identify threats, protect networks using firewalls and zoning (limiting the ability of video surveillance components to communicate freely with the internet or other local subnets), ensure systems are patched and configurations are hardened and consistent across the estate.
Most importantly, operators should have the means to detect any unusual behaviour, whether this is in terms of unexpected network traffic, changes in configurations, or abnormal system behaviour. These could all be indicative of either a cyber attack or simply a non-malicious mistake that could nevertheless open up the network to an attacker at a future date.