Ken Munro, Partner at PenTestPartners, talks to Grant Powell MBCS about the security of connected transport systems.
The connectivity of transport systems brings huge benefits — but at what cost to our privacy and online security? Ken Munro, security writer, speaker, and Partner at PenTestPartners, shares his experiences and considers the key measures that need to be put in place to safeguard data and ensure the highest levels of cybersecurity across all transport services.
How does the increased connectivity of transport networks present security challenges?
There have been huge efforts to connect our global transport systems and start collecting meaningful data. If you can get data, you can start looking proactively at fault prediction and preventative maintenance. You can have a replacement engine lined up long before you get to a point of catastrophic failure, for example. Due to its many benefits, the connectivity of these systems has been done in something of a rush, which has led to many issues. If you think about ships, we’ve moved very swiftly from vessels where connectivity didn't matter, to suddenly having hyper-connectivity with very little thought given to cybersecurity concerns.
It's that acceleration of connectivity that's caused problems, and we’re seeing similar issues in rail with onboard networks. We put Wi-Fi on trains and then put telematics — on a cold morning you can now tell a train to start heating up an hour before it is needed without having to send a driver. That’s great, but as with the connectivity of ships, we’ve taken something that was once physically secure because its systems were effectively isolated and created a whole series of new challenges, primarily related to the use of insecure networks.
What are some of the considerations when it comes to securing these systems?
The first thing to consider is the importance of understanding exactly what it is that you're connecting, and taking a decision as to whether that connectivity is really essential. Is it essential to a train control and management system that could affect the brakes or acceleration, for example? Or a ship's safety control and management system that could be used to disable the main engines at a critical point?
If we make mistakes as a result of trying to connect things too quickly without really thinking about what we're connecting and why, we run a huge risk. If we get security wrong, the consequences as a result of someone taking remote control of a train, ship or plane could be catastrophic. The Jeep hack by Charlie Miller and Chris Valasek back in 2015 was a seminal moment for vehicle security, where a demonstration using the public internet showed that it was possible to take control of the steering and engine of a vehicle on the road. That happened because in the rush for connectivity there had not been sufficient time, thought or planning around connecting the car to a telematics unit and a 4G modem, so the various segregations that were required to stop hackers taking control of steering and engine controls were not in place.
A second point of consideration is the age of the components and systems in use. If there are things that you can't secure properly because they're 20 years old, then it’s important to isolate them, separate them from the core network, and make absolutely certain that there's no way to reconnect them.
We’ve seen stories in the news about flight security and the potential for jamming GPS signals. What are your thoughts on this?
I'm a pilot myself, and looking at the cyber security of aeroplanes is an area that I spend a lot of time working in. Aeroplanes are generally safe and secure; there isn't a particular risk from hacking to the travelling public.
Where it gets interesting is in relation to the information that's fed to pilots, and a good example is GPS. We're seeing a lot of GPS spoofing and jamming going on right now that is starting to cause some consequential issues. For example, imagine you are a pilot and on approach to the airport a proximity warning alert sounds. Even though the plane’s radio instruments and the landing system are all aligned, the GPS thinks the plane is somewhere else and tells the pilot to pull up, go around and start the landing procedure again. So, the pilot will have to take action, such as disabling safety systems, in order to approach an area of GPS jamming or spoofing.
One particular example of this is Tartu Airport in Estonia, which experienced such significant GPS jamming that planes couldn't approach safely — so they didn't, for a period of time. This is why we don't have autonomous passenger planes! Autonomous systems are too exposed to jamming and spoofing. This is why we have two pilots upfront who are incredibly well trained, so that if certain systems are behaving strangely, they know which ones to ignore and which to concentrate on. It’s about having access to multiple sources of data and knowing which ones to discard and which ones are accurate, and that's why flying is safe — because of the experience and knowledge of the pilots. In more modern aeroplanes, GPS receivers are fortunately more resistant to these types of attacks. For older planes, an interim solution is what is called Hybrid GPS, which correlates what pilots see from up in the sky with what air traffic controllers see down on the ground. Hybrid GPS uses conventional ground-based navigational aids to correlate position, and if there's a discrepancy then the pilots can take appropriate action.
How do you begin to test the security of transport systems?
The first thing is to establish what we call a ‘threat model’. Then we start working out what the consequences would be of a vehicle being compromised, and the controls and defences around that — so very much like the layers of an onion that we always talk about in security.
For you
Be part of something bigger, join BCS, The Chartered Institute for IT.
Let's say I'm through the first layer, what can I do? I'll go to the next layer, and the next all the way down to the point where, perhaps, I finally find a layer that’s compromised. It could be on one of the connectivity systems, typically what we call a telematics unit. We have found bugs and connectivity issues in the past that have allowed not just the reading of data, but also tampering with that information. That's how, for example, the Jeep hack was done. They realised that they could send information and compromise certain systems. And we find those sorts of bugs all the time when we're working on vehicles. Assuming there is a bug, what are our remaining layers of defence? What's next in line? What do I have to compromise next? It is very much about that layered approach and how important penetration testing is for ensuring the security of connected transport systems.
What are the challenges when conducting these tests on more complex infrastructures?
Part of the exercise in carrying out a penetration test is that you challenge what you're presented with by your technology provider, scrutinising architectural drawings and diagrams to prove that what you're being told is reality: who has access to which systems? What are the privileges and access controls? What are the defences, and do they work? It’s really about ‘kicking the tyres’ to make sure that what you've been told, what you believe, and what your paper audits and your threat model have shown are all accurate. There have been a number of times where we've worked on new-build vessels where the technology provider in the yard has said ‘it looks like this’, and in actuality it looks like something completely different.
In addition, a key element of the challenge lies in making sure we are very careful with transport systems in particular because their digital networks are not especially well protected against unusual traffic. A penetration test is about asking systems to behave in an unusual way. Systems that may have been in place for 10 to 20 years are often not very resistant against unusual scenarios, and that's what a penetration test is about: I'm not going to do what the system expects, I'm going to do something different and see how it responds. Maybe it's a buffer overflow, or a vulnerability, or an exploit that works. We need to be careful when we’re doing that because we run the risk of, in some cases, breaking technology that simply wasn't designed with today's attacks in mind.
Unlike testing at a fixed address, vehicles are always on the move. How do you manage this?
The fact that we can be effectively chasing technology around the world can present challenges logistically. Trains, ships, cars, planes, their very job is to go around the world, and as the penetration tester you are often chasing technology so that you can get to it and test it properly. The job of each of these modes of transport is to generate revenue, so taking a train offline, for example, can be massively inconvenient for the travelling public. Often, what we'll try to do is synchronise our work with maintenance windows. So, when a ship is in dry dock, for example, when it's being refitted, that's a really good time to gain access. It’s the same with trains. Often just before launch of a new train series they will get us involved, as well as during maintenance windows. It can be quite complicated scheduling the right people in the right place at the right time, in the right part of the world or the country. So that's a real challenge for us.
And how do you find working with maintenance teams? Is it a smooth process?
In honesty, there certainly used to be a perception from maintenance engineers that we were just there to cause some problems. Now, because awareness of cyber has evolved, we find that maintenance engineers are really quite interested, and we often work with them collaboratively. We might end up finding new vulnerabilities just by having a really good conversation. Sometimes the ‘coffee and doughnuts approach’ is the best way to start a test, taking time to actually sit down with the engineers and talk to them. They know the systems, so it makes sense to have a discussion about exactly what we’re going to be doing and why. And certainly, in the shipping world, operators have started to hire people to deal with cybersecurity onboard. This is great because we can have a very productive conversation, and we're seeing similar moves with rail manufacturers and vehicle manufacturers too. It’s often these people who bring us in nice and early to their design lifecycles. In those cases we can really make a difference, because the opposite situation, where something is about to go live and there are still a bunch of critical security flaws, can be an absolute nightmare.
How do you see the future of transport security evolving?
One of the significant things we’re seeing is that regulation is starting to catch up. The government is always behind the curve when it comes to regulation because industry wants to move fast and break things! But regulation is there to pick up on this. We've seen it in automotive with the arrival of UNECE R155 which has really driven behaviour in a good way. We've also seen some new cybersecurity regulations starting to drive things further in relation to the building of new ships, including IACS UR E26 & E27. In addition, the United States Coast Guard (USCG) has very recently announced some new measures of its own. In rail, there is a new cybersecurity standard coming.
They’ve taken a long time, but they're with us now and they're starting to come into force, which can only be a good thing. It all serves to empower cyber teams at various transport operators to be able to justify the time and money that needs to be spent on getting cybersecurity right. In transport and cyber I think regulation is really important because the consequences of getting it wrong are so serious — it can potentially affect people’s lives. Sometimes regulation is the leverage you need to persuade the company board that cybersecurity measures are the right way to go.
